I'm interested to know if gtkmm w/ ATK (or whatever) works with MSAA like Qt does. We're looking right now at switching toolkit from WX and it turns out that our testing software relies on MSAA to do it's thing (something I wish I'd known 3 years ago when we picked WX to begin with). Of all the GUI toolkits, I prefer GTKmm mainly due to it's use of signals and slots but in a way much more expressive and generic than Qt's....and without the need for the extra build step that requires the Qt VS plugin. The designer is much better too.
So I'd like to use GTKmm but the only discussions and google stuff I can find on the topic are 3+ years old. They lead me to believe the answer is no, it doesn't support it and if it does it's really shoddy. But a lot can change in 3 years.
So, anyone that uses GTK or GTKmm on win32 know if it supports the windows accessibility framework?
I can’t say for sure but I would lean toward very little to no support. I use the Jaws screen reader SOFTWARE SINCE I’m blind. It uses MSAA quite heavily and GTK applications such as Pidgin are almost completely inaccessible. While I can read some of the text on a screen figuring out weather I’m in an edit field or weather a button is selected is impossible. If my screen reader can’t deal with GTK applications I assume your testing software will have major issues as well.
I don't know if this is still being tracked but I will second this assessment as another windows screen reader user. gnuCash was the app I tried and it was pretty rough going. Worked like a dream in Gnome with Orca though. Apparently, it's like this, if you want windows accessibility, use QT and WxWidgets. If you want Linux, use gtk+. QT is going to be accessible in Linux apparently though this is yet to be (not till gnome 3, I think). Pity you had to abandon WxWidgets. I personally like their widgets since it has those sizers which take much of the guess work out of placement of controls. Important when you can't see and you want to build a gui. Looks like about the only cross-platform accessibility solutions right now are Xul and SWT (Java, you know). Sad thing about WxWidgets is that this sort of thing was reported to them two years ago but nothing seems to have been done about it.
http://trac.wxwidgets.org/ticket/9785
I would be delighted to know that I am wrong about this. I doubt it, though.
Related
I'm developing my first Windows desktop application and I'm trying to figure out what the best approach would be to create the program's GUI.
I know, I know... I feel stupid for asking considering the amount of data on the subject on SO. However most answers seem outdated and I'm not sure if they fit my specific project. Also tutorials for Windows 8 'metro apps' are clogging my Google search results, which is NOT what I'm looking for.
I use Visual Studio. I've followed tutorials. I have basic knowledge of C and Java and extensive experience with PHP. I'm excited to learn C++, so I'm not looking for GUIs to create a GUI (like WinForms). I also don't care about managed code and portability for now, especially since I'm trying to avoid dependencies (i.e. users having to install .NET). As long as it runs smoothly on Vista and up, I'm happy.
The application
The software will teach basic physics to kids. I'd like to create a main area and a sidebar. The main area will feature a physics animation, say a bouncing ball, along with some Q&A. Users can zoom in to the animation to measure some stuff and answer the question. Users can track their progress in the sidebar. That's pretty much it.
What I've found so far
I'm getting a bit frustrated with MSDN. Most of their examples are given in four different languages (C#, C++, etc). I can't seem to get more than a bit of Hello World code from them.
I found a GDI API on MSDN and it seems like a good start for me. However I've read quite a few answers on SO saying creating layouts in pure C++ is really hard, that we're better of using frameworks like ATL and WTL. Since I'm also going to create (somewhat interactive) animations, I've wondered whether I should use gaming-targeted APIs like Direct2D.
Since all of this is new to me, and there are a lot of options, I don't know where to start for my particular application. Any tips would be greatly appreciated!
Using the raw Win32 API (no additional downloads or third-party helpers):
Here's a good primer (introduces dialog boxes, text boxes, buttons, etc): theForger's Win32 API Tutorial
And here's where you go from there (numeric up-downs, list boxes, combo boxes, tooltips, and more): Common Controls on MSDN. Most of these require you to #include <commctrl.h>.
I also found this to be a good resource that covered what the other two didn't: Win32 Developer - Window Assets
But the Win32 API doesn't seem like it does exactly what you want. A physics app for kids should have a more visual GUI than the API can provide. Good luck, though!
If you're ok with adding additional Frameworks, I'd suggest looking at Qt.
It allows to create the GUI from code only, has a good structure, and has an Interface for 2D drawing, if required.
If you are concerned about dependencies, you only have to include the Qt DLLs to your executables; no installation is required for the user.
To get started, see my (old) tutorial "Lessons in Windows API Programming".
But you really need a good book, such as edition 5 or earlier of Charles Petzold's classic "Programming Windows".
The problem with latest edition is that it's for C# and .NET, with Charles grabbing the tail of the "new way" at just the wrong time…
Disclaimer: I haven't checked the details of edition numbers.
Using the Windows API is the simplest, but producing advanced GUIs can take a very long time. Microsoft Foundation Class is a way to make the Windows API more user friendly and OOP. Does anyone have any experience with MFC?
Why not use some 2D C++ game engine, like HGE: http://hge.relishgames.com/overview.html.
Is it a good idea to use gtkmm gui toolkit for some desktop client application ?
Is this toolkit stable and is there enough documentation online ?
I used gtkmm to write professional applications and yes you can use it for real world software development.
But I also used C/GTK+ and C++/Qt and my opinion is that using Gtkmm you have the feeling that the original toolkit was meant to be used in C and the porting to C++ is ok but in many cases you feel that C++ features could have been used better.
For Comparison:
If you have to choose between Gtk and Gtkmm go for Gtkmm even though you might find yourself stuck in some not well documented or supported function. Eventually you always manage to find a solution (you can check the source code) and c++ is way better then c.
If you have to choose between Gtkmm and Qt, go for Qt. There is a HUGE gap between the two. Not only in the toolkit itself but in the documentation and all the other classes that you need when writing an application.
I started two month ago with gtkmm. I actually port a tcl/tk application and it feels very hard for my to get the things run. The only useful documentation I found is the https://developer.gnome.org/gtkmm-tutorial/3.4/
But many things described in the manual are not working! I actually run into trouble while overriding signal handlers which should work but didn't. Maybe you will take a look in gtkmm-list#gnome.org to find out what kind of problems yo will maybe run in :-)
The docs derived from the doxygen input seems useless for me, because the functions are mostly not described and the parameter names or often not very clear to me.
In comparison to tcl/tk the interface looks inconsistent. Sometimes a parameter must be provided by a text, sometimes by a pointer and sometimes by the native value itself. Especially the menus are very "mysterious" with the string based configuration. The need of having parameters as text is very unhandy! You have to convert the parameter with ostrstream into a text and parse the parameters sometimes yourself from text to real values.
I decided to give gtk+ a chance is the existence of the c++ interface. I thought it would be helpful to get the errors in compile time and not while running the app like with tcl/tk. But this is not the always true with gtkmm. With gtkmm you are also able to run into run time errors because all string parameters will be parsed during run time! This makes the things error prone!
Maybe I will start again and give Qt a chance. But a first view on it shows, that this seems not really better :-)
Writing a gui application still is a really annoying job!
gtkmm is a official supported binding of GTK (gtk.org/language-bindings.php).
"inkscape" and "ardour" are notable applications written in gtkmm
The bindings that are official GNOME Bindings follow the GNOME release schedule which guarantees API stability and time-based releases.
If you want to write your Application in C, go with GTK+ (and the GLib).
You can find a link to the documentation at http://www.gtkmm.org/ (https://developer.gnome.org/gtkmm-tutorial/).
With Glade (and ie. PyGTK) you could rapid prototype your application.
Building a GUI with Glade is easy and the resulting UI is a xml file, that is not bound to a programming language.
I'm not very familiar with Linux, but have some experience with C and C++. I would like to get in touch with some Visual FX and/or UI development (either C or C++). I was wondering if there is a possibility to access the GUI elements of the Desktop on Ubuntu's Unity UI.
What I especially would like to do, is to render animations on the desktop or windows or all over the screen. (particle effects when clicking with the mouse or so).
Can anyone point me in the right direction? (Libraries, Documents, ...)
I think Desktop Effects have to be designed specific for the corresponding Window Manager.
I think unity uses (some sort of) compiz, so you should look into compiz plugin development.
A lot of "i thinks" so i am not really sure if that'll help you, but good luck.
You want to learn a lot more about GTK. There are lot of documentation on line (and some books also). You might code in C++ using GtkMM (but you could consider Qt also). GTK itself is coded in C, with well designed coding style and convention. Looking inside its source code is worthwhile.
Is Qt an interesting platform for business apps development, outside of Nokia phones ?
Why ? Strong points ?
Thanks
I like Qt because:
Very well-designed framework, e.g. signal-slot, model-view, graphics view/scene/item/proxy, painter/paint device/paint engine..., too many to be listed here!
Excellent documentation!
Cross platform language/API, as well as tools like UI designer, creator, and so on.
Rich features, e.g. graphics framework, network library, database engine, and so on.
Active community, and active development.
There should be more. If you have ever used it, you'll find it's easy to build your framework upon Qt.
I didn't have any complain to Qt. If I have to say at least one disadvantage here, "convention". You must adopt the convention of Qt, e.g. You have to use moc to make the meta object of your objects, and it's easier for developers to use Qt's vector, list, auto_ptr than STL, tr1. But I never found any issue caused by that. On the contrary, it works very well.
In my opinion, Qt is the state-of-the-art C++ framework in this modern world!
P.S. There are a lot of commercial applications built on Qt. You can find it under Qt's official website. But I'd like add one more here: Perforce, one of the top commercial source code management tools, built its client tool on Qt for Windows/Linux/Mac.
yes it is .. just look at kde apps :)
or see more applications made by qt
and it has alot of bindings in many languages
Documentation
cross-Platform IDE
further reading
may be this is not so related to the question ... but my first deal with qt was just great starting from their well organized Documentation to their great widgets
the GraphicsView is just ammazing ! :)
It's about the only current/modern C++ gui library on Windows.
MFC is so old you have to write comments in Latin
WTL would be nice if they had finished it before abandoning it.
Winforms/WPF + managed C++/CLR - all the fun of several incompatible new technologies at once.
Bad points:
To fit on lots of platforms they have invented their own solutions to things that are now in the STL/Boost
The signal/slot mechanism - tricky to debug and silently fails (with no error) with simple typos.
Although everything is possible it's sometimes a lot of effort to do simple things (they do love MVC) compared to Winforms.
Qt is simple
Qt is powerful
Qt is NATIVELY-CROSS-PLATFORM
Qt is REALLY-CROSS-PLATFORM
Qt is comprehensive (but the Media side of it still needs to grow)
Qt doesn't require Garbage Collection, but it embeds a GREAT model of memory management that makes you forget about memory deallocation
Qt is solid
Qt is modern
Qt proposes some new paradigm of programming that are really good (Signals-Slots)
Qt runs a lot of VERY successful software: (Skype, Google Earth...)
Are those points strong enough?
Maybe you have heard about Google Earth which happens to be programmed in Qt too.
That aside, I like Qt for my in-house development because it
is very well supported and documented,
allows me to write simple and decent-looking apps that are
works cross-platform for Windows and Linux with little effort, and
contains nice to have components for database access, regexps, guis, xml, ...
I also use the Qwt widgets for easy real-time plotting on top of Qt.
I really dont understand whats the point in underestimating tools/frameworks which makes things easy for programmers. Qt is too good for GUI development, I would say its much better than any current existing crossplatform app development suite.
So many advantages, I have been using it for more than three years now for a product to be deployed in Linux/Win environments. The app is thread intensive and initially we had a tough time using pthreads and its conterpart for windows. Then we switched to Qt(and QThreads eventually) and things were a breeze...
Backed by active development, a highly helpful and supportive community along with excellent documentation, training, certification programs, videos, forums... its easy, fast and effective to develop in Qt. You should see the video which they create a web browser in just five mins!
Its really 'cross platform', and it doesnt have a software wrapper(like Java does) to enable this which makes it faster. Cmon, we all know java apps have buttons which takes a second to respond to even a simple 'click'.
I hope Qt will someday do a take on Java. :D
after all, 350000 developers cant be wrong when they chose Qt.
Pixar uses Qt (or at least, used, as of 2005) internally for certain parts of their tool suite (called "Marionette" in the marketing) collectively called Menv, ("men-vee" for Modelling ENVironment)---at least for their lighting sub-tool Lumos.
We currently maintain a suit of MFC applications that are fairly well designed, however the user interface is beginning to look tired and a lot of the code is in need quite a bit of refactoring to tidy up some duplication and/or performance problems. We make use of quite a few custom controls that handle all their own drawing (all written using MFC).
Recently I've been doing more research into Qt and the benefits it provides (cross-platform and supports what you might call a more "professional" looking framework for UI development).
My question is - what would be the best approach to perhaps moving to the Qt framework? Does Qt play nice with MFC? Would it be better to start porting some of our custom controls to Qt and gradually integrate more and more into our existing MFC apps? (is this possible?).
Any advice or previous experience is appreciated.
In my company, we are currently using Qt and are very happy with it.
I personnally never had to move a MFC-app into using the Qt framework, but here is something which might be of some interest for you :
Qt/MFC Migration Framework
Qt/MFC Migration Framework
It's part of Qt-Solutions, so this means you'll have to buy a Qt license along with a Qt-Solutions license. (edit: not any more)
I hope this helps !
(This doesn't really answer your specific questions but...)
I haven't personally used Qt, but it's not free for commercial Windows development.
Have you looked at wxWindows which is free? Nice article here. Just as an aside, if you wanted a single code base for all platforms, then you may have to migrate away from MFC - I am pretty sure (someone will correct if wrong) that MFC only targets Windows.
One other option would be to look at the Feature Pack update to MFC in SP1 of VS2008 - it includes access to new controls, including the Office style ribbon controls.
It's a tricky problem, and I suspect that the answer depends on how much time you have. You will get a much better result if you port your custom controls to Qt - if you use the QStyle classes to do the actual drawing then you'll end up with theme-able code right out of the box.
In general, my advice would be to bite the bullet and go the whole way at once. Sure, it might take longer, but the alternative is to spend an age trying to debug code that doesn't quite play ball, and end up writing more code to deal with minor incompatibilities between the two systems (been there, done that).
So, to summarise, my advice is to start a branch and rip out all your old MFC code and replace it with Qt. You'll get platform independence (almost) for free, and while it will take a while, you'll end up with a much nicer product at the end of it.
One final word of warning: make sure you take the time to understand the "Qt way of doing things" - in some cases it can be quite different to the MFC approach - the last thing you want to do is to end up with MFC-style Qt code.
I have lead a team doing this kind of thing before (not MFC to QT but the principles should work).
First we documented the dialogs and what their inputs, controls and outputs were. Also, we create several test cases especially for any clever logic inside the GUI.
Sometimes we had to refactor some business logic to provide a clean interface the GUIs but this is the way it should have been done in the first place tbh.
Now we had a list of GUIs, inputs, outputs, tests and an interface that the encapsulated GUI had to match.
We began, project by project, to create equivilant GUIs to the old ones. Once we did that we could slot the GUI in where the old one was, rebuild and test it. At first we tripped a lot but we soon worked out the common errors and fixed them. We navigated (I think) 612 dialogs although there was a team of about a dozen of us working on it.