Still, I need some basic implentation of a model, right? I've implemented the basics of this, and it really is much easier and cleaner then my last approach, but.. what about the model? Is it really a class like this:

Don't do that. The "Model" can be anything, it depends on your project that uses the window library. Also MVC is not the only pattern for window development. So while developing your windowing framework, you have to care didely squats about the MVC pattern.

Like I gave in the example, for a logfile viewer the model is the logfile reader/writer class. for a map editor, the model is the map. MVC is applied when you use your window framework for a project. Think of the Model as a command line program, the view as a pupped with no idea what to do and the controller as the puppeteer. Putting the position and size in the model makes no sense by definition. A Button isn't a model, a button is a subcomponent of the view.

How would I do that? I can think about it using function pointers, but this whole topic is new to me so I'd rather go with registering the controller directely, unless there is some huge drawback

It is MVC half-assed. The whole idea behind MVC is that the View has no idea about the controller and the controller can be completely changed. In your implementation, the Controller has to have a certain interface to work.
You haven't worked with .Net windows.forms or AWT/SWING, have you? You can do it by function pointers or by event classes. Those are the two messaging systems of .Net and swing respectively.

The main purpose of this is to built a game editor.... I really don't want to do that, as I'd like to get an understanding of how things work under the hood. You may call it a waste of time but I've learned quite a much only the last 24 hours, which might become usefull again later on...

Seriously? Don't do the windowing library yourself. Just don't. Not if you want to do something else for the next few years.
This field is hugely complex, from the posts I read, you don't have enough skill to implement something halfways usable. To be honest, neither have I, nor about 90% of the people here.

You want to know how they work under the hood, you should at least know how the "hood" looks like.
I guess you are fairly new to programming, of course you learned much getting feedback on your design. But it is like you want to be a mechanic and your first job is to dis- and reassemble an ocean liner. It is not a good learning project.
You could as well have been asking how to reimplement the Source engine. You will learn much, yes. But such a project is stupid when you don't know your way around simple 3D problems and algorithms. You might learn more + have more fun implementing a program that starts with simple cubes.

There are better learning projects, for example your game editor. There you can learn how to use the MVC pattern, about messaging and delegating and so on. Then you see what a window library actually is and does.

From there on, there are good articles on how SWING works and their design choices to keep it platform indipendent. Also you might search for an article on Windows.Forms, and WPF.
The important lessons to take from the windowing libraries are their design choices/design patterns.

[quote name='CC Ricers' timestamp='1345582334' post='4971973']
What I don't favor is putting bunch of variables that are sprawling over the place inside the Widget class, when they can be split up and contained in their own classes or structures, which you can then use with more flexibility

While I agree that it makes sense to put that in a structure, I don't agree that it gives you more flexibilty. What should be so more flexible about this approach?
[/quote]

What I meant is that it is easier to manage in the code, by re-using the variables/functions as a structure in other part of your code, instead of copy-pasting the declaration of multiple variables and passing a long list of function parameters. More importantly to me, though, is discovering new ways you can use the structure now that it's in a single unit.

For instance, I had variables for transition times in my screens, plus a transition update function. Each screen has custom times for their entering/exiting transitions, and the transitions are animated according to the time. When I grouped all the related transition code into a structure, I now had something that I can easily use elsewhere for things more than screens. I could apply it to a text object to make moving text, for example.