My suggestion if you want to keep it simple, is to expect a couple rounds of refactoring. Then, instead of splitting your head trying to devise the perfiect design, create a first, simple and "obvious" design. The process of organizing will help you decide, eventually, how best to go.

Because of this, you don't want to invest in any unneccessary, or heavy technology up front. You also want to limit variables or things that can change easily. Data that can be changed on the fly tends to introduce more instability than "flexibility" into a new system. You even alluded to this by asking how to control the data. So don't bother, just hard code it into your classes. If the data rarely changes, then who cares if it is hard coded? It will run faster anyway.

As to haveing a ton of itty-bitty classes, don't worry about it. It's not that big a deal. Especially if they are simple. It will actually make coding/debugging easier because you won't have a bunch of hyper-creative, dynamic class construction going on. If there is a problem, there will be a very definitive and easy code path to follow. And again, if the classes don't change often, who cares how many there are?

Keep in mind, object oriented programming does not necessarily reduce the amount of code you have, it just re-arranges it into something easier to follow. Object oriented DESIGN can lead to code reduction simply because it reduces complexity and redundancy.

If you keep it simple, hard code everything rather than using config files or databases at first, you will actually get a clearer view of what you have. Going through this process will probably give you a view of the system different from what you currently have. Once THAT happens, and the system is stable, THEN look into more clever solutions such as config files, databases, super-spiffy-class-on-the-fly designs and such.

Keep in mind, if you are going to take an OO approach, make sure you use OO Design, not just OO syntax. An Object Oriented system must be oriented around the "things" of a system, NOT what those things do or have done to them. So when I hear you talk about event classes I get a little concerned. You don't give enough information for me to decide whether event classes are appropriate or not, but it does seem a little close to being nothing more than procedural programming in OO clothing. eg. "Copy" is not an object. "File" is an object that has a "copy" method.

I also worry when you say that events are triggered based on the widget properties. Again, not very OO-ish (or was this in reference to the current, not future system?) OO allows for some change in behaviour based on parameters, but this is supposed to be used when a single concept has to be defined differently for different types of parameters. For instance, adding two numbers, two letters, two matricies or two objects are all different, but it is still, in some way, addition. You don't design an OO system to examine the parameters then decide to add, subtract, multiply or just spit back random greek letters.

Turning the problem on its side like this might give you a different view and might offer up a different solution all together. For instance, maybe an OO approach is not really what you want. Maybe what you really want is an event driven system similar to any GUI. Perhaps an Agent based system? Or perhaps what you really want, what this actually sounds more like, is a rules engine. Define the rules, and yes, you'll have a lot of them, but you let the rules engine decide how to manage them.

FWIW, you're stated question seems to be whether or not to use a config file or database to manage the changeable parts of similar classes so as to reduce the number of actual classes you have to code. My response is neither. Either go with a lot of simple, hard coded classes, or research an entirely different approach. If you have the guts for it, I suggest doing something entirely different because based on what you wrote, I think you are headed down the wrong path. But I was wrong once before, so take that advice with a grain of salt :-)