Question

I'm now with a idea to start the development of a bare bones Qt/GTK+-like framework, but I want to know some things before I start the creation of this project:

  • What is the structure of GTK+ and Qt?
  • Do I need to develop a window manager to build my own framework?
  • Some resources to start?
Was it helpful?

Solution

That sounds like a major undertaking, at least as a starting project.

Not sure what you mean by "the structure" of e.g. GTK+. You can see the object hierarchy for GTK+, that tells you at least how the implemented objects (GTK+ is an object-oriented API) relate to each other. You can guess how the code can be structured, from that information.

And no, you don't need to write your own window manager; the toolkits mainly concern themselves with what happens inside windows, not with the window management itself. Of course you could decide that your "platform" should have a wider scope, and include a WM.

OTHER TIPS

Developing a GUI/Application framework is a significant undertaking. You might want to be very clear about why you need to write yet an other framework.

Both projects you mention are open source. Why not start there?

  1. GTK: git clone git://git.gnome.org/gtk+
  2. Qt: git clone git://gitorious.org/qt/qt.git

Ed You ask what the structure of GTK and Qt are, whether you need to write your own widow manager (answer: no) and how to get started. Answers to at least the first two are in the source code. Don't forget, great practitioners in any field learn by watching others. Reading code is no different.

Writing a GUI/app framework would be a great learning experience, but even a fairly small app framework would be a very big job, and not something you really should tackle until you're fairly expert in writing applications using several other frameworks and widget toolkits.

I did something like this once, back in the early years of this decade. That was after I'd been programming for the Mac for over 15 years, Windows over 10, and had programmed both directly to their native graphics, event, and widget APIs, as well as various object-oriented toolkits for them including PowerPlant, MFC, and MacApp. When I started working on a PalmOS application, I spent a couple of weeks writing a very small app framework modeled on PowerPlant. But I could not have succeeded at all without those decades of broad and deep experience with so many GUI systems.

Doing this for Linux/X11 is even more work. That's because, unlike Mac OS and Windows, neither X11 nor Linux supply built-in user interface widgets, or much in the way of graphics primitives or text layout capabilities. GTK+ is part of the GNOME ecosystem; it provides the widgets, gets its message queue and internal communications from GObject, relies on GDK to abstract and simplify its graphics and event communications with X11, and uses Pango and Cairo for text rendering and layout. I work all through that system, and it probably represents many dozens of person-years of hard work by a lot of really smart people. And I'm sure Qt is very similar.

So if you really want to do this, I would recommend you:

  1. Write programs with a lot of different app and widget toolkits, on multiple operating systems. That will help you learn not just how such systems work, but why they are designed as they are. And it will give you some feeling for what works well, and what works poorly.
  2. Contribute bug fixes or new features to one or more of the various open-source frameworks. GTK+ has a list of tasks for beginners to work on. Another great open-source framework is wxWidgets.
  3. Become an expert-level C/C++ programmer.

When you've done that for a few years, you will have the expertise suitable for tackling your own framework.

I think some of the answers here might exaggerate a bit. Obviously making something of the same quality, width and depth as Qt and Gtk is a huge untertaking. But you can make simpler stuff and still learn a lot about how it works. I suggest doing like I did in university. Use OpenGL with Glut. Then you got basic drawing functionality and event system in place already. You then need to create classes for buttons, text fields etc.

If you want to make it really simple then each component just needs to know where it is drawn and have some sort of bounding box where you check whether mouse click are inside or not. You also needs to create some system which makes it possible for buttons, check boxes etc to tell the rest of your code that they were clicked.

This isn't really the rocket science people here make it out to be. Games have made their own very simple GUI toolkits for years. You can try that approach as well. I have modeled a simple GUI tookit on top of a game engine before. Your buttons and textfield could be simply be sprites.

But yeah, if you want to make something that will compete with Gtk+ and Qt, forget about it. That is a team effort over many years.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top