I'm creating one tab based C++ application using GTK+ toolkit and Webkit for learning purpose. I've created following files
Main.cpp => Application entry-point
MainWindow.cpp/.h => MainWindow which creates toolbar object, Notebook, Statusbar
Toolbar.cpp/.h => toolbar items like back, forward, urlbar, stop/refresh,
NotebookContainer.cpp/.h => for creating new tab etc
TabWebView.cpp/.h => for creating tab(label+close button), web-view etc.
Now I want to communicate in between toolbar and TabView class. So when any event occur on toolbar I can do the action in webview.cpp and some event trigger from webview I can do the required on toolbar (like enabling/disabling stop button)
Which design pattern should I need to follow in this scenario?
NOTE: GTK+ is c based library.
I would like to suggest that you are asking the wrong question. Rather than asking what design pattern to follow, I would suggest you ask what the most idiomatic way to solve your problem is.
All too often the wors design failures I have to fix come from a young coder whose approach is "what design pattern can I use here?", or "How can I use more design patterns".
Studying design patterns is useful in providing a vocabulary for discussing your designs, and they are useful in inspiring and informing your design choices, but your design approach should always be "what the simplest, cleanest, most effective, idiomatic approach here". Sometimes the answer to that question will be a design pattern. Sometimes it will a part of a design pattern, and sometimes it will be something much simpler -- typically an idiom in the language or library you are working with.
I don't do a lot of GUI programming, so I can't help much with your concrete question. For the problem you are presenting, it sounds like you want to use GTK's signal/slot framework. Alternatively boost offers similar functionality if you want to get familiar with boost's tools. Both would be idiomatic approaches to what you want to do.
I think what you are looking for is some along the lines of an observer pattern:
http://sourcemaking.com/design_patterns/observer
and more generally something like Model-View-Controller or Presentation-Abstraction-Control models:
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
http://en.wikipedia.org/wiki/Presentation%E2%80%93abstraction%E2%80%93control
You might want to have a look at the Qt Signal/Slot implementation also:
http://qt-project.org/doc/qt-4.8/signalsandslots.html
Related
I want to develop a MFC application in VS2010. I hope to separate GUI from the logic, so that modifying GUI can become much easier. But I don't know how to design the classes to implement this function. Which design pattern should I use? Does MFC have any special way to deal with the problem?
Moreover, I am not familiar with design patterns. So I hope someone can give me samples or detailed articles explaining this. (Also I prefer a less complicated pattern! ^^)
Thank you very much!
The MFC already provide such a separation in their SDI/MDI based templates. For example, you have a CWinApp instance and a CMainFrame for the program itself. For each file in MDI apps you have a CDocument and a CView class.
Note:
The MFC don't use the classic MVC separation, they combine the view and controller into a single UI part.
The MFC are not strict about this, you can also put a button handler into the application/document, not only into the frame/view.
You don't fully separate the model from the MFC, it is still built on that. If you want to achieve this separation, you have to do additional work, but then you have a module that you can test completely separately. This allows you to use test-driven development, which is more difficult when embedded into a GUI.
May be it will be helpful http://martinfowler.com/eaaDev/uiArchs.html . Also try to find MVC (model/view/controller) pattern.
I was looking at MeVisLab and I wondered if anyone knows a good framework for making a user interface similar to the one they use. I like the designing flow with boxes and arrows thing.
What I would really like is to able to integrate with C++ using Qt, and perhaps export the graph to xml of something like that.
There is another example of the interface here:
I hope someone knows something
Qt's Graphics View is a "framework" which does a good bit of the handling for the kind of scenario you describe. It doesn't take much code to get off the ground and within striking range of what you're looking for:
http://doc.qt.nokia.com/latest/graphicsview-diagramscene.html
http://doc.qt.nokia.com/latest/graphicsview-elasticnodes.html
I'm not aware of any open-source Qt-based programs that offer exactly what you want already written. Just noticed IBM did open source "DataExplorer", which is interesting to me...I might go take a look at that myself:
http://www.research.ibm.com/dx/
I have heard that somewhere # web I'll be able to find good C++ example of Mediator working with GUI components. But I menaged to find only that GoF sample or things from sorcemaking and similar that aren't helpful to me.
So... do you know where that mentioned GUI sample can be found?
Sorry for that kind of question, but that can be useful for others too.
How about this one: http://www.andypatterns.com/index.php/design_patterns/model_gui_mediator_pattern/. It appears the author is applying the pattern specifically to the 'view' part of the GUI functionality (as opposed to the data modeling behind it).
Not sure if that's what you were looking for...
I would like to start coding a gtk theme engine, but i'm wondering where i can find some documentation, if any exists.
I know how to have look at someone else engine's code, examples, or torture tests and widget factories etc.., what i want instead is any documentation type, design, references, examples or tutorials possibly from reliable sources such as the Gnome foundation or the like.
You know, when coding for the Win32 platform one can pinpoint reliable references on the subject by following the MSDN and then read a variety of other sources to see how the problem has been tackled, if any.
So, where to find an authoritative, reliable and possibly complete source of documentation about GTK theme engine development? Is there any for real?
Later added:
Also, how to debug such an engine? What's the most sane and painless way to perform testing and debugging on such a delicate os' ui component?
Well, you can look for instance at the source for the gtk smooth engine in Ubuntu most of which is in one fairly enormous C file smooth_gtk2_drawing.c. I don't know if that's an especially good example, but probably finding whichever looks simplest or most actively maintained would be a good idea.
A theme engine is typically used to change the shape of widgets among other things. If you're just trying to change the color scheme and so on, you just need to create a theme.
Just like the theme engines, theres not a whole lot of documentation when it comes to creating a theme either. However, there are a ton of examples at http://www.gnome-look.org
Why should I choose to use one instead of the other and in which cases?
I mainly focus on desktop applications and personally speaking I do find the humble dialog box more easy and natural to use.
In MVC, you would still use your "humble" dialog. Except all the business logic for it would be farmed off to another class somewhere else.
http://en.wikipedia.org/wiki/Model-view-controller
You need to weight up whether the investment in MVC will be worth it - especially if you're only working with a single simple dialog.
One of the best discussions I've found regarding the advantages and disadvantages of the model view controller/presenter patterns was written by Martin Fowler: http://martinfowler.com/eaaDev/uiArchs.html
In short, by choosing to use a MVC variant you are increasing the testability of your view (dialog). Keeping all of your logic in your dialog class on the other hand, can be fine if you do not expect that dialog to be very complex, however as the complexity increases, the benefit of testable code increases.
It really is a judgement call.
"Humble" dialogs themselves are already MVC. You have:
M, The content of the dialog's message.
V, The window and widgets the user can see.
C, How the dialog is displayed and how it responds to user activity.
Your GUI framework or wrapper library can provide MVC for you seamlessly without you having to think about it, but it's still MVC.
There is no simple answer.
You should use whatever will make your life easier.
If dialog is really simple, and you know for sure it is going to stay that way, go with humble dialog.
If you have something more complex, like multiple view presentations of the same data, or you know your simple dialog will become more complex over time, then, by all means, use MVC.
You can also take a look ant MVP pattern as an alternative to MVC.