An object-oriented program usually contains different types of objects, each corresponding to a particular kind of complex data to manage, or perhaps to a rea
Your modules can be implemented as classes, that is indeed correct. However, modules are meant to be logically separate pieces of the programs and as such it doesn't make sense to have them as classes, as you can have many different objects of a class. If I was to write a modular system and use classes for modules, I'd make them all singletons.
In your example, object-oriented programming you would have classes defining the input fields and buttons, or maybe a class that is used as a calculator. You could even go to greater depths and define a Calculator interface that could be implemented as SumCalculator, ProductCalculator etc, and maybe even throw in some factories so the user can choose between different calculations performed by your program. Yes, you could have singleton classes such as LayoutModule (which would keep track of objects of InputField and Button type) and LogicModule (which would keep track of the Calculator implementations).
Modular programming just implies you have these two (or more) modules, but says nothing of how they achieve what they achieve. The modules can use object-oriented approaches or not at all and use procedural C-style programming. The way you described modular programming via classes is just a way of separating modules. You can separate them as classes, or you can separate them as functions across multiple compilation units, for example. It's your choice.
Object-oriented programming implies that your program is, well, oriented towards objects. It says nothing about modules within your application but demands that logical pieces that represent some ideas within the application are modeled via classes and objects.
As such, the two approaches can be used together, and when you decide to be modular, the object-oriented choice usually imposes on you that these modules are defined via classes and their relationships.