I want to develop an application which has a graphical user interface that could be developed by using different widget toolkits. For example I want to use Qt, GTK+ or even ncurses as a building block for my user interface for the same application. Moreover users could choose which GUI implementation will be used during the next startup of the application without recompiling it first. I wonder what are possible design strategies and design patterns used in the implementation of this design?
+3
A:
The classic design pattern for multiple GUIs is MVC.
You have one model (application data and rules), the controllers (one per view) - these control UI interactions and mediate between the UI (views) and the model.
You can have different views talk to the controllers - one view can be Qt, another GTK+ or even a console application.
Oded
2010-06-06 18:27:37
+1
A:
Why would you want that?
Each toolkit has its own strong points and weaknesses. If you want to design something that will work with them all, you will be limited by the cumulative sum of all of the weaknesses and gain none of the strong points.
For instance if you're using Qt then you won't be able to use QT's signals and slots. that will make writing the GUI and the interaction with it quite painful. You'll basically need to write a whole wrapper layer around something that is already a wrapper layer (to the native APIs)
I see no possible reason why a user would care to choose between Qt or GTK+ or ncourses. just select one thing and stick with it.
shoosh
2010-06-06 18:28:01
I agree. While in theory described approach sounds fine, in practice it rarely produces good results. I'd say such UI-agnostic stuff shouldn't try to use MVC. Instead they should provide the M part (the model) and let UI handle _everything_ interface-related, to not reduce their ability to leverage the strong aspects of their GUI toolkit. E.g. that's the way that libpurple and Pidgin follows (as I understand).
doublep
2010-06-06 18:33:09
shoosh: I think practically you are right. I tried to make a wrapper (an abstract widget/container) which cause new problems. After a short time developing new custom widgets (by using wrapper) became more complex and harder. Different main development languages (C - C++), differences between property and signal systems of different toolkits force me to push more toolkit specific detail into the wrapper which makes the development phase harder.
Deniz
2010-06-06 21:22:57
doublep: I think the easiest way of doing this is separating business logic from presentation. It may be a library or a component based approach, but you can write a new GUI by using the same library/component. UI can delegate required functionality to another layer may be.
Deniz
2010-06-06 21:24:39
A:
A commercial solution you might find interesting, that does decouple the user interface from the system logic and is both OS and render technology agnostic is Crank Software's Storyboard Suite.
One of the principle differences with this UI designer and runtime is that you build the user interface out of images/graphics and not widgets. This makes it easier to move your UI model between rendering technologies (ie fbdev, directFB, X11, SDL/QT/GTK). You tie the user interface elements to the system logic with Lua scripts, or custom C plugins if you need something very specific.
Of course a curses implementation might be a bit of a stretch, but there is always ascii art!
Thomas
Thomas
2010-06-09 14:29:50