I'm looking for some advice and insight on how people approach creating Object-level GUI automation. Technically the type of functionality I am trying to achieve is easily described by Squish software. I want to be able to simulate Key-Press and Mouse Click events without relying on Platform-specific pixel displays, and screen sizes. I've tried to use tools like Sikuli, but unfortunately my application varies too from platform to platform to make reliably re-repeatable tests.
Basically what I am looking for is some advice as to where to look at how 3rd Part (EXTERNAL) programs hook into properties of QT Widgets and other objects. I know a long time ago there was something call QtObjectInspector, but this software required you making Source-Level changes to your Qt code to be compatible on top of being unavailable.
If companies like Squish can do it, how are they doing it? Where do you start? I doubt they are looking at very low level memory interactions, sniffing for "Traffic" that looks like QT on each different system, but I may be wrong.
I'm sorry for such a vague question, but I've been researching for over a day and all I can find now is articles about how amazing Squish is.
Thanks!
EDIT:
I looked into QtTestLib, however this doesn't have the "From the outside" kind of access that I am looking for.
Related
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 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
I have this program in mind that I would like to attempt and create in c++. I am not sure what SDK I should use, Here is the idea:
Basically like Facebooks status' or twitter but strictly for your desktop. Window like AIM or MSN would allow you to view your friends and their current status, allow you to comment on it, etc. When someone changes their status, all of their friends get a little notification on the bottom right of their screen saying what their friends current status is. There would obviously be much more that sets it apart, but this is the basic idea that I'm starting from.
If you plan to release it as OpenSource, the Qt GUI Framework is very much worth considering (you can buy a commercial license too). It is crossplatform (Linux/Win/Mac) - eg. Google Maps desktop app uses it.
It will give you networking support, HTML/XML rendering if necessary, SQL and much more.
As for communication protocols, go with Greg's suggestion.
A good choice for a cross-platform GUI system is wxWidgets. For communication between users, something like XMPP would be a good option, because it is a platform-agnostic open standard with solid support for user "presence".
Qt is a good crossplatform toolkit. Take a look at that.
I have a significant codebase written in MFC and am tasked with creating a port for Mac OS X. I know that I'm going to have to roll up my sleeves at some point and do alot of grunt work to get everything working correctly, but are there any tools out there that might get me partway?
I'm working on one.
From the GUI point of view, the new version of AppMaker is based around an import/generate model. Most of commercial work I've done with AppMaker has been the other way, porting Macintosh applications to Windows. However, there's no reason why the same principles can't be applied in reverse.
AppMaker v2 had a very good importer for PowerPlant UI resources and traditional Mac dialogs. As it is only able to run on Classic, that code base has been discarded (you really don't want to know) and the final generator languge I wrote for AppMaker v2 is an XML exporter which dumps the entire object model to an extended XAML.
I already have a XAML UI generator and am currently working on a Cocoa xib generator - one of the reasons for going to WWDC in June. The focus at this time is on import/generator suites before returning my attention to a GUI editor.
I wrote PP2MFC to allow PowerPlant applications to be compiled for Windows - a cross-platform solution needed because no other framework or cross-platform tool at the time (1997) would perform well enough for the hardware requirements. I've since discussed an opposite program with someone I could chase up and I'm sure an MFC portability layer could be created to map to Cocoa objects. Whilst many developers have a poor opinion of MFC's message-map architecture, the heavily macro-based API sits on top of a reasonably clean OO framework.
This is the kind of project where you need to think about long-term maintainability - do you want something which ends up as large chunks of MFC code working with Cocoa or do you want to migrate to an idiomatic Cocoa program.
Any further discussion should probably be taken off SO - contact me at dent at oofile.com.au but I'm happy to debate technicalities and feasibility on here. The combination of code generation and skinny framework adaptor layers works better than most people expect.
Honestly, the models are so different that I suspect you're going to need to do a nearly complete re-code at least of most of the UI parts.
No, Such a tool would be pretty much impossible to write.
MFC and Cocoa are such fundamentally different platforms there is no easy way to convert between the two.
Depending on how you've written your applications, you will either need to write the GUI portion of your code or even the whole codebase.
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.