I wanted to consult with the sages here regarding Qt and skinning, get your opinion and chart a path for my development. My requirements are as follows:
My Qt/C++ application (cross platform with Mac, Windows and Linux versions) needs to have modular skins.
A skin is defined as a set of one or more elements: - Window background texture - Look/feel of UI controls such as edit boxes, drop down, radio buttons, buttons etc. - Look/feel of window "caption", resize grips etc.
Skins will be installed with the application installer, allowing the user to choose which one he/she wants to use. Users should be able to change skins on the fly.
Can I go the QML route? should this be custom and based on simple resources which are built into the application? Any design advice will be appreciated.
Thanks.
If I understood you correctly then stylesheet is the best way forward. You can create stylesheets similar to CSS and then pass them as command line option to your application or load on invocation to style your application at runtime. That way you can create multiple stylesheets each having a different look and feel and allow user to load them at will. Since its CSS it doesn't need any new learning and you can keep all your styling outside your source code.
Here are a list of resources that can get you up and running quickly:
http://blog.qt.io/blog/2007/11/27/theming-qt-for-fun-and-profit/
http://doc.qt.io/qt-5/stylesheet.html
I haven't played with QML yet, but you could also create a custom QStyle implementation that supports your resource format. Note that you'd lose style sheet support if you went this route.
Changing window captions is a little trickier if you want portability.
QML, if I understand correctly, doesn't really skin the widgets, it mainly deals with GUI layout etc etc.
QStyle is used to change the looks. It is a bit low-level though, and requires programming, so if you want to load different user-created skins (from an XML or so) it might be tricky to support extensive skinning. Chaining colors and a few items are easy enough though. (There might be someone else who've done something you could re-use.. not sure.)
For modifying widgets, use QStyle::polish(). You could use that to change the background picture (if it's a top-level window, or of a certain class). There are numerous repaint method to change almost every part of every widget.
Store/load the style using QSettings, by reading and setting the desired Style just after QApplication but before your main window is constructed.
Related
I'm new to Qt and it's quite a learning curve!
I've been search/reading/hacking and learning for most of the day on this one.
I'm working on an app that will have a image in a scroll area as it's main purpose. The image viewer example is where I started. This example appears to be "laid out by hand" if you will - i.e. there are no .ui form files for it (it's trivial so why not).
So here is the rub - I want to use designer to build a much more sophisticated app. If I start fresh with a new project and use designer the resizing doesn't work unless I add layout (used vertical, all appear to fix the resize issue) to the .ui form.
Designer creates a lot more code to do the same thing - I don't care, it is after all an IDE / code generation tool.
However it's not clear to me why the layout is required when I use designer and not if I code it by hand. I searched the code for the image viewer example and there doesn't seem to be ANY layout involved at all, just 3 or 4 nested widgits (Main/Scroll/Label).
Is the default layout basically built in?
The example you linked to uses a QMainWindow. This widget has its own layout because it has built-in support for menubars, toolbars, dock widgets and a statusbar:
Main Window Framework:
Normally, the widget set as the central-widget would need to have a layout explicitly set on it in order to layout its own child widgets. However, in your linked example, the central-widget is a QScrollArea, which also happens to have a built-in layout. This is all just coincidental, though. The large majority of widgets don't have a built-in layout, so most GUIs will need to explictly add at least one layout, and several will usually be needed for more complex applications.
I would say Qt Designer is absolutely essential when it comes to experimenting with layouts (especially when you start learning Qt). Even if you don't actually use the ui file, it's still very helpful to just view the code that would be generated from it.
When it comes to designing a GUI in Qt, I am hesitating between using the designer in Qt Creator, or doing everything in source code. I'm using Qt widgets and not QML.
If I use the designer I can easily create a GUI using qt standard widgets. But as soon as I need to subclass a widget to extend its functionality I have to build a Designer plugin to support my new widget. Is that correct? Or is there another way to it?
You can build all the GUI in Designer including custom widgets, and you can also build your custom widgets in Designer.
Designer does not need to interpret your custom widgets. Just use the promote functionality. With promote, you start with a plain widget within Designer and then tell the "real" class of it (your custom one) and the header file where it is decleared. The only drawback is that within Designer, it will stay looking like an empty widget.
In my experience, it is much better to use Designer for the GUI than writing source code yourself. You can easily change all the properties afterwards etc., and it is helpful even if you rely on custom widgets. Source code is not a good declarative language for GUI objects, with all the properties etc. Also you cannot play around, you would need to compile all the time just to tell "Is it better to have this text label in bold font?".
Sometimes I edit the XML files that are created by Designer by hand. For example, if I want to put a widget somewhere else in the object tree. If you don't mess up the XML, Designer will still read it and not destroy your changes. The only reason I see for writing GUI in source code is when you have repetitive elements, or dynamic changes based on data input, e.g. a for()-loop that produces elements. In my project I have some Selector Boxes that are filled with options in the source code.
And btw: If you prefer to write your GUI in code instead of using Designer, maybe you are not the right person to craft the GUI. Most programmers don't understand that while they are technically able to design a GUI, they are not always also competent in doing it.
http://hallofshame.gp.co.at/index.php?file=shame.htm&mode=original
It is a bit of a shortcut, but I often use a simple QWidget as a container for my custom widget. This way, I can setup sizing policies, put the whole thing in the layout I want before my custom widget is even in. Then, in C++, I add the custom widget as a child of the container widget.
edit: As ypnos mentioned you can promote the placeholder directly. You can find guidelines here
Every time I start a project with some graphical toolkit, one of the first conflicts happen with the decision of how to deal with the visual design and the widget layout: A graphical tool or handcoding?
This is a quite tricky/subjective question because most people will decide based on personal preference. It also depends greatly on the quality of the graphical tool. In this case I would like to focus just on the latest version of the QT library. I do not intend to discuss which method is better. I am convinced that the best answer is: depends on the project.
What I want is a reference to a good non biased article, based on experience after several projects. The article should just describe the tradeoffs of both choices
I started with doing everything hand-coded, and of late have been switching to using Qt Designer for most forms. Here are some benefits for each position:
Using Qt Designer
The biggest time saver for me is managing complex layouts; it saves a lot of tedious coding. Simply (very roughly) arrange your widgets, select them, right-click, and put them in the correct type of layout. Especially as layouts become nested, this is so much easier.
It tends to keep your implementation files cleaner instead of filling them with all the boilerplate layout code. I'm type-A, so I like that.
If you are translating your application, it is possible to send your translators the .ui files so they can see on your GUI where the text they are translating will be. (Assuming they are using Qt Linguist.)
Hand-coding
Control. If you have a layout where you need to instantiate / initialize the controls in a very particular order, or dynamically create the controls based on other criteria (database lookup, etc.), this is the easiest way.
If you have custom widgets, you can kind-of-sort-of use the Designer, adding the closest built-in QWidget from which your class derived and then "upgrading" it. But you won't see a preview of your widget unless you make it a designer plugin in a separate project, which is way too much work for most use cases.
If you have custom widgets that take parameters in their constructor beyond the optional QWidget parent, Designer can't handle it. You have no choice but to add that control manually.
Miscellaneous
I don't use the auto-connect SLOTS and SIGNALS feature (based on naming convention such as "on_my_button_clicked".) I have found that I almost invariably have to set up this connection at a determinate time, not whenever Qt does it for me.
For QWizard forms, I have found that I need to use a different UI file for each page. You can do it all in one, but it becomes very awkward to communicate between pages in any kind of custom way.
In summary, I start with Qt Designer and let it take me as far as it can, then hand-code it from there. That's one nice thing about what Qt Designer generates--it is just another class that becomes a member of your class, and you can access it and manipulate it as you need.
My answer is based on two years developing biochemistry applications using PyQt4 (Python bindings to Qt 4) and OpenGL. I have not done C++ Qt, because we only used C++ for performance-critical algorithms. That said, the PyQt4 API greatly resembles Qt4, so much here still applies.
Qt Designer
Good
Exploration. Discover what widgets are available, the names for those widgets, what properties you can set for each, etc.
Enforces separation of UI logic from application logic.
Bad
If you need to add or remove widgets at run-time, you have to have that logic in code. I think it's a bad idea to put your UI logic in two places.
Making changes to nested layouts. When a layout has no widgets in it, it collapses, and it can be really hard to drag and drop a widget in to the location you want.
Hand coding
Good
Fast if you are very familiar with Qt.
Best choice if you need to add or remove widgets at run-time.
Easier than Qt Designer if you have your own custom widgets.
With discipline, you can still separate UI layout from behavior. Just put your code to create and layout widgets in one place, and your code to set signals and slots in another place.
Bad
Slow if you are new to Qt.
Does not enforce separation of layout from behavior.
Tips
Don't just jump into creating your windows. Start by quickly sketching several possible designs, either on paper or using a tool like Balsamiq Mockups. Though you could do this in Qt Designer, I think it is too tempting to spend a lot of time trying to get your windows to look just right before you've even decided if it is the best design.
If you use Qt Designer for PyQt, you have the extra step of running pyuic4 to compile your *.ui files to Python source files. I found it easy to forget this step and scratch my head for a second why my changes didn't work.
If you code your UI by hand, I suggest putting your layout code in one place and your signals and slots in another place. Doing this makes it easier to change the way your widgets are arranged on a window without affecting any of your application logic. Or you can change some behavior without having to wade through all the layout code.
Enjoy Qt! Now that I am using Java Swing for work, I miss it.
I tend to layout dialogs using the designer but I do all the event handling stuff in the main code. I also do all the main windows, toolbars, menus in direct code.
The designer is just frustrating - a pity since decent drag and drop sizer based designers have been around for more than a decade
It depends on the number of different windows/panels you need for your application. If the number is small, use a graphical tool. It is much faster to get a few windows designed perfectly. If the number is large, the graphical tool can (and should) only be used for prototypes. You need to code the layout to be able to make application-wide changes at acceptable cost.
That includes creating a model of how the UI of the application works and dynamically adding and removing widgets at runtime. For an excellent example of such a model (in a different environment), take a look at the glamour model for creating object browsers.
I object to the suggestion that it is tricky/subjective (at least more than other development choices). It is easy to come up with criteria to decide on. Personal experience and preference are important for that, as they decide when the number of different windows should be considered small. The same goes for tool quality.
My personal opinion (just personal), all GUI based development distracts me too much, my imagination or my mind works very bad when i'm seeing gui objects, i prefer to hand-coding most the time because my imagination works better, you know, is like you were reading a book with no images... when i see nothing else than code its looks like i finish faster...
Second reason, i like c++ so much, so I see the good side of hand-coding, is that I keep my c++ practice no matter if I'm writing something redundant... Coding skill is improved when you only use text... Indeed, i could use nano or vim, but that is too far slow for debuging.
Hand-coding here ++vote
I use a combination of both:
I find for x,y coordinates, Designer is the way to go.
A lot of the other UI properties etc can be set in your code.
I think trying to do UI completely by hand-coding would be a very time consuming project. It's not as simple as setting up HTML tables.
Yes version 4 is bad, but people at work who have used version 3 said it was REALLY bad. Lots of crashing.
I, along with my fellow QTers, are truly hoping that version 5 will be an improvement.
I know this is an old question, but I hope this helps! One man's experience.
Also, where do you start if you want to create a complete Flex 4 skin? Is there a list of all the "pieces" (component parts) you need to create graphics for somewhere, or some complete, example skins out there to use as a template? And do your skins render correctly in Flash Builder Design View? (including embedded fonts)
Most people will point you to Flash Catalyst, but the last time I looked it was not all-inclusive in terms of creating a complete skin/theme, not to mention other issues inherent to 1.0 software. I start by copying the default skin files and modifying them, as well as creating a new CSS file based on the defaults.css file that comes with the SDK. The trickier part is that not all components (Tree, DataGrid, DateChooser, ColorPicker, etc) are available as Spark components, which means to have a complete skin/theme you need to create a bunch of mx skins as well. Bottom line: If you are serious about doing this properly, you'll need to spend a lot of time understanding defaults.css and the skin classes it refers to.
To answer your original question, my personal workflow is to create a mockup of the skin in OmniGraffle, then use that as a guide to modify copies of the default skin files (look in spark.skins, and mx.spark.skins) by manipulating the mxml directly (as opposed to using a graphical tool such as Illustrator or Catalyst.)
Hope that helps.
Basically, you have many options when skinning Flex 4 apps :
Using "general" styles (chromeColor, selectionColor, focusColor, ...). This is usually called "Styling" instead of Skinning because you only change the overall look of the application. It's by far the easiest way to change the appareance of your application quickly without knowing anything about FXG, MXMLG, ... The drawback is it will still look like a Flex app, but with different colors/fonts
Using Adobe tools to produce FXG files. These tools can be Illustrator, Photoshop, Flash CS5. You design each of the spark component with these tools and export the result in .fxg format. FXG is great because it's optimized, but you can't use things such as Data Binding in it
Write your skin in MXMLG , by hand (starting from scratch or copying the default spark skin) or with the help of Flash Catalyst. Catalyst can take your Illustrator or Photoshop design and convert it to MXMLG. Experience shows it's still painfull, even with the last version. And you often end up doing things like this.
In our team, there is no such thing like designer/developer workflow with Flash Catalyst. The next version looks better but it's still far from what Microsoft is doing with Visual Studio/Blend.
That being said, the new Spark architecture is awesome. Skinning is much easier, flexible and readable. With this architecture, a developer codes the component and the designer skins it only by knowing the contract (skinparts, skinstates, data)
This also true for views if you use the Presentation Model pattern.
There is no "template" skins as the one available in Flex 3 because skinning doesn't use symbol anymore. What could be done though is a Flex 4 style explorer.
A final word, it has already been said here, but don't forget that with the current version (4.1), there is no spark equivalent for all of the components, so you will still use Flex 3 skinning techniques for components such as DataGrid, Tree, ...
This is where I normally "start"
http://examples.adobe.com/flex2/inproduct/sdk/explorer/explorer.html
Once I figure out what components I have to skin, and I can't change what I want to change in Flex with CSS, then I go into Flash and start breaking the components apart and tweaking them.
http://www.adobe.com/devnet/flex/articles/skins_styles.html
(Also, I've never had anything render "correctly" in design view)
Has anybody experience in building a custom style in Qt? What I have in my mind is a complete new style that affects all kind of widgets. I have seen some examples in the web for a custom combo box. But I have no idea how much time and code it takes to build a "complete" new custom style ... maybe someone can give me a hint.
We think of using Qt 4.3 (or even newer) ...
Check out the Stylesheets facility in Qt 4. While it's still a hassle, it's way easier than doing a full-on custom style. You can just adjust one visual facet at a time and try it out.
It pays attention to inheritance. So if you style the font in QWidget, then every visual widget will also use that font. And so on.
I have developed a "new" style that changed the appearance of much of an application. It did take some time, and quite a bit of experimentation. I also derived my style from the generic windows style, to allow it to handle some of the stuff I didn't want to mess with. All told, I think it took me a week to get most of what I wanted, with practically no prior exposure to the styles.
In order to actually develop one, I would get into the source for their styles example, which has a "wood" style. I put my own style in place of the example style, and started changing things while using the example program to check how it looked. Depending on how you are developing it, you might want to have a configuration file so you can easily change some of the values without recompiling.
You might want to look at existing styles. You can find quite a few of them on kde-look.org, in the Styles / 4.0 section.
We've done it in the past (in Qt 3), and it's extremely time-consuming. We had a lot of problems with flickering, redraws not working the way we expected, sluggish behavior, bugs in the Qt implementation. It a lot less straight-forward than it seems, and there's little support or user experience too. Unless you need something really particular (as we did), I'd say it's not worth the trouble.
Other frameworks are supposed to make it easier (some Java-based?), but I don't have first hand experience.
If you don't need to radically change the widget style, you might want to try using widget style sheets:
http://doc.qt.digia.com/4.4/stylesheet.html