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?
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.
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.
Related
I am attempting to come up with a "big picture" outline for a picture manipulation desktop application I would like to make, but due to my lack of extensive experience with implementing UI design patterns - I am struggling to find an appropriate one for my needs.
Most of my experience with UI design patterns was a few school projects utilizing the Model-View-Presenter (MVP) design pattern with Java Swing. Since Java Swing is on the way out, I am trying to use JavaFx for my UI needs moving forwards.
With a couple projects recently I attempted to use MVP with JavaFX with little success as I was stuck with the longest time connecting the user actions from the View (a JavaFX application) to the Model. I kept running into roadblocks where any attempt to connect an instance of the View to a Presenter (which would then give the logic for which Model methods, details here aren't important) would fail since the View would create another instance of itself (separate application thread from start()) with no reference to the Presenter or Model methods.
So in my rush to complete the project, I implemented a very ugly work basically hooking up the Model methods directly with their related View components. The projects works, but violates many fundamental design principles.
Going forward with this next project I would like to avoid making that mistake from the get go with a better overall design that can adequately deal with the issue I face (described above) while still maintaining fundamental design principles.
Any solution I think of involves having the View (the JavaFx Application) be where the program runs from, but that appears the violate the whole idea of having interchangeable Views. Is JavaFX just not meant to be flexible for what I'm looking for? Does anyone have any potential solutions to my problem here, both on the design pattern and JavaFX front?
The MVP pattern in JavaFX is implemented as an FXML View connected to a controller class as the Presenter that launches separate Model threads as needed for various computations/tasks that feed into the View controls. In JavaFX you create the FXML view with SceneBuilder. SceneBuilder creates the visual part of the GUI in a FXML file that is a passive file containing all of the visual attributes. Then you attach a controller class that handles all of the events from the GUI controls. This implements the Presenter aspect of MVP. Then the Model is a separate thread running various computations in the background and interacting with the JavaFX thread as needed. If the computations are not too intensive, you can just run them in the JavaFX thread itself. If they take a lot of CPU cycles, you must run then in a separate thread so you don't lock up the GUI.
yesterday I stumbled across the Haxe NME project, which is a very promising idea. However, it is still not possible to build sophisticated UIs with this framework. In my opinion it seems to be a intimidating task to build a UI framework that targets so many different platforms, hence I think that this isn't a viable approach, because even old and mature UI frameworks like Qt and wxWidgets don't support so many platforms.
However, it could make sense to build a platform specific UI with help of some pretty UI designer tool and then connect the UI code to the UI agnostic code that has been written in Haxe. I don't know if this could work, because I couldn't find any example, but maybe someone who has already written some MVC Haxe code, that could be successfully connected to different platform specific UIs, would like to share his experiences. Thanks.
You say:
However, it is still not possible to build sophisticated UIs
Just because you haven't yet figured out how to do it doesn't mean it's not possible ;)
The reason it is possible is that in the Haxe ecosystem, the language and compiler is extremely consistent cross platform, NME/OpenFL provides a fairly strong cross platform rendering environment (HTML 5 has some quirks, but the others seem fairly strong) and so anything you build on top of these is going to cover a lot of platforms out-of-the-box. It's about being fairly high level - letting the compiler and the libraries take care of the platform quirks.
In MVC, the UI stuff is usually the "View". For View / UI frameworks, check out these libraries:
Stablex UI
NME/OpenFL, Cross Platform. Draws components using NME API. This is
the only one I've played with, but the demo works consistently on android,
flash, html5, native linux. Pretty impressive.
HaxeUI
NME, Cross Platform. Again, draws components on the stage.
Prime
Drawn using Flash API. Not sure if it has been ported cross platform yet.
See also Talk/Video from WWX conference and Slides
Guise
A really innovative way of being able to either draw the UI, or use native if available. Check out the blog post.
Basis
Another attempt at wrapping native components - has iOS and Android libraries so far. Pretty cool, but I haven't played with it yet.
For MVC, there are lots of options:
PrimeVC, mentioned above.
MMVC, based on the RobotLegs framework, but tailored for Haxe.
Lots of small options BBMVC PureMVC etc
The advantage of the MVC frameworks is that they separate your views from your application data (model) and logic (controller). Try to spend some time familiarising yourself with one of the MVC frameworks, and you'll see how you can write your apps in a way where you could use one of these, and then any of the various view engines - either native or NME-rendered. It can be a fairly steep learning curve, but this is how you build apps that are easily portable between different UI frameworks, and easily testable so you know they will scale as the app grows in complexity.
The main problem you seem to face is that there is no out of the box option that is complete and ready for you to use. The multitudes of project people are suggesting do what you want. You need to be willing to use them. A small project on github may be dropped. If so it will be dropped because jo one uses it so its up to people who would like to use it (ie: you) to keep it going.
Everyone can't siphon of others completed projects or nothing would ever be created. Participation is what opensource is about.
Doesn't make sense to have a unified UI for all platforms, every platform have diferent workflow, have you tryed to use a IOS listbox on windows , is simply ridiculous. On the other hand a good design could separate the view from the bussines logic and you can share the bussiness logic with all targets and tweak the views for every target. look at PureMVC
for a mvc example in Haxe
I know that MVC design pattern is popular, mainly in the web based apps. I'm curios to know how the MVC design pattern can be used in desktop applications environment.
To be more specific, let's consider the VLC media player. Can the VLC be written accordingly to MVC pattern? Who is M, V, C and who is the "dispatcher"?
Maybe the VLC isn't the perfect example, but I think it is a popular application. VLC isn't only about playing a video it has built in codecs and also some video effects adjustment support.
I think MVC doesn't get mentioned with desktop applications so much because a desktop app already follows the MVC approach. You have a GUI (your view) which has a series of interactivity points that cause events (call a controller).
Sticking with a simpler app:winamp.
Controller-Initiation Points:
Menu options
Buttons
View Points:
Total GUI
Track information panel (artist/track etc)
Visualization panel (graphic eq)
You certainly can use the MVC pattern for a desktop app - and will realize the same benefits as a web-app.
I've used the MVC pattern for non-web applications before. It's actually a really good approach for implementing a variety of interfaces to one application. In my experience:
The Models are pretty obvious; they don't change. In the VLC example, they could be things like input files.
The Controllers don't really have to change much either (if they're well written). Controllers should be basically agnostic to the interface-type (web, cli, etc.). A given controller action should be thought of as saying, "here is where you __ with the data."
The Views are where significant refactoring comes in. Simply re-create the views with input/output appropriate to the medium (e.g. windowing instructions, rather than HTML resources).
Finally, the "dispatching" in this case would be done by the application executable which would effectively be communicating messages -- translating user input (and other input) into calls to the controller (just as in a web app).
Check out Wikipedia's article on the MVC pattern for more info.
There are many more technologies and tools available to build the front end for an application.
Which is the best technology/tool/platform available using which I can build a better GUI, by which I'll be able to build a nice looking as well as an efficient GUI?
Definition of "better" includes factors such as efficiency,user friendliness,better content control mechanism, navigation and many more.
I know this is a question about which GUI toolkit you should use, but your first technology for producing a user-friendly UI is pen and paper. Sketch out some mock-ups. Draw buttons and menus on construction paper, cut them out, and glue them together. Then try your mockups on about a half-dozen people. You'll quickly find out what makes a good UI.
It doesn't matter how good the UI looks or whether it uses the latest snazzy effects -- if your users can't figure out how to use it, they'll go elsewhere. You need to learn what works for your target audience before you write a single line of code.
Read Don't Make Me Think to learn how to make mock-ups and do user testing.
If' you're tracking an IP address, you'll definitely want to create your GUI Interface in Visual Basic.
Use the .NET framework in Visual Studio 2005/2008/2010 Studio. I haven't developed in any other environment, but I have been able to create nice looking apps in this IDE / Framework.
"Best" depends on what your evaluation function is.
For ease of development, and high quality UI, in a non-web based app it's hard to beat C#/VB or any other .NET language and environment for a windows-based app. Depending on the quality of the UI, MPF will give you greater flexibility and control, whereas windows form will make it easier to develop.
Having used Windows Presentation Foundation for a while now i would highly recommend it. There is a pretty big learning curve and, to be honest, MSFT should have included some controls (the datagrid being the biggest one) that were not included by default (but will be in .NET 4.0). Where WPF and XAML exceed is providing a foundation from which you can build just about anything. You can style ANY part of ANY control and build your own composite controls from scratch. A lot of thought went into binding and value converters and once you get used to the declarative nature of XAML you wont want to turn back. The company I work for has been using it for a couple of years now and the difference between the GUIs we used to develop (mainly winforms and asp.net) and what we develop now are night and day in terms of both look-and-feel and functionality. My two cents anyway...
It depends.
What device will the GUI be used on, hand held, PC, Mac?
What platform Windows, Linux, Web?
What kind of application will it be, accounting, email client, web application?
What audience will be using the application (a GUI aimed at a child may be different than one aimed at an adult)?
All of these things must be taken into account before even starting to formulate an answer to your question.
You have several choices for developing a GUI.
first, if cross platform is an issue consider using Java or Python.
you can also use Adobe AIR and develop the gui in Flex.
If you direct the product to windows only users .NET WPF is the best solution, with a very rich set of control and examples.
You can also use .NET with mono for cross platform compatibility, but WPF isn't currently supported.
Desktop, Mobile, Windows, Linux, Database, OpenGL: Nokia Qt. Wiht Python - PyQt development process is shortest and easy. Application containing all required python & qt libraries and modules is around 30MB with Inno Setup installation is 8MB and will work on Windows 2000 and newer for Python 2.6.x, Python 2.5.x based application will run from Windows 95 to Windows 7.
I think all the attributes you list -- efficiency, user friendliness, etc -- are attributes of a good design rather than a good toolkit. Just about any toolkit can be used to meet those goals. I think the question might be different if you were asking about eye candy, fancy multi-media, etc. There are definitely some toolkits that do that better than others.
If you're interested in usability first (and it sounds like you are), focus on the design then pick whatever toolkit meets your current abilities and can handle your design. For example, if you require 3D images that might narrow your choices; likewise if you need to show videos, that will influence which toolkits you can choose from.
So, start with a good design. From that, create a list of requires for the toolkit -- rich editing controls, video, 3D, etc. And then look for a toolkit that provides what you need.
The best toolkit in the world won't make up for poor design.
Personally after having used Win32, Forms and WPF then going to Mac/iPhone GUI development, I very much prefer the flexibility and high quality of visuals in the Mac/iPhone GUI.
One of the most useful examples is the fact that in NSTable/UITable controls (ListViews or similar in Windows), every cell is a fully customisable View (a Control in Windows).
Where in a ListView you have very little customisation for each cell/item in the view since you only provide details, not an actual control, an NSTable/UITable asks you for a table cell which you can add anything to, such as buttons, switches and image views.
Mac OS GUI development to me is a LOT more flexible and more consistently flexible in that regard. Everything is a View so I can my own contents to anything.
Have you considered Silverlight?
It can be used to create internet applications, but it can also be run out of browser to create desktop applications. It's has significant overlap with WPF though there are differences which might catch you out when swapping from one to the other.
Expression Blend 3 is a very good visual designer and the code it produces is quite efficient.
I've done plenty of programming before for CLI and the web, however recently I am getting into desktop GUI programming.
Most of the tutorials for GUI programming I found just explain the different controls you can use and leave it at that. Some of the better ones also skim over a few usability issues.
However, my problem is not with the APIs, or the theory but with my code.
How are you supposed to organise different views your application might have (e.g. a IM application has a login view, a contacts list view, a conversation view etc.).
Are these supposed to be different classes or different methods on one class?
Different panels that are hidden and revealed, or different windows altogether?
I'm hoping for answers as language agnostic as possible, but in case that's not possible, the languages/frameworks I am considering are Java/Swing or C#/WPF. However, if there's another language/framework that is significantly better for learning from, I would consider using that.
Normally each view will be a seperate class in a seperate file. The class will then most likely implement some base class like Window or Control.
As far as organization, if it's a simple app, put them in the root or in a UI folder. Or perhaps a Window folder and Controls folder.
If it's a large app with several views, than break them out into functionality, i.e. an IM folder.
I would say go with what Joshua said and as far as using different panels that are hidden and revealed, i've worked on old code and it's a nightmare to re-use (8000+ lines of Delphi 6!) so stick with different windows as much as possible!
The generally recommended overall structure of the program is the model-view-controller (MVC) type of structure. So, first off, don't make the actual data part of the views, it goes into the model. From here, since the only data in each view window is now almost entirely just layout information and what to do on an action (click, data display, etc), if these are different, they should probably be different classes. If there's some general functionality that can be factored out, you can make this a base class and inherit from it, but in the end, windows with different functionalities should be different classes.
If you are going to be using one of the mainstream IDEs it will handle some of this work for you. The default will be a different class for each form. Hidden panels and tabbed interfaces are nice features but do yourself a favor and learn the ins and outs of embedding groups of controls into form. Some frameworks allow you to directly embed one form into another. Others have special containers that can be be embedded.
The point of these is to break up your functionality so you don't wind up with a bloated form class that's difficult to wade through.
I would also spend some time looking at some of the architectural patterns for keeping your business logic separate from your UI. Check out this link for a good starting point.