I have been building small "proof of principle" programs to learn about GTK3, and now that GTK4 has limited availability, I have been attempting to learn about this version as well. In attempting to migrate to GTK4, I took a program I wrote for GTK3 that displays two progress bars with different attributes using CSS providers and rebuilt it under GTK4. When I ran the GTK4 version of the program, the CSS overrides in the program are ignored unless I introduce the CSS provider context to the display level for one of the progress bars. But that then results in having both progress bars exhibiting the same behavior instead of having unique behavior for each progress bar. Just as a further test, I added CSS providers and context for a label widget and that override worked. So some CSS overrides in GTK4 work as before, but some do not. It is as though some CSS provider overrides are ignored at the display level. Reviewing documentation about priorities (e.g. GTK_STYLE_PROVIDER_PRIORITY_APPLICATION) and testing out various priority constants did not make a difference.
Displaying the content of the code would be too long in this narrative, so I have uploaded the GTK3 and GTK4 versions of the code to my Github repositories along with a "pdf" file visually illustrating the different behavior between GTK3 and GTK4. If you want to review and test out the code yourself, the link is:
https://github.com/cschuls/GTK4_Mystery
I would suppose that widget-specific CSS customization could be added at the display level with an "id#" attribute, but that seems like that would just be adding unnecessary complexity when this practice works fine with GTK3. Thanks in advance for any answers and suggestions.
Additional comment.
Experimenting with various scenarios, I came up with a work-around that provides the desired result of having distinct style properties applied to each progress bar widget. For those widgets, I added their respective CSS provider data to the display style context instead of attempting to add the CSS provider to each widget's context. If you wish to view this work-around, I added a "work-around" folder with the source code to my Github repository.
This provides a decent solution to this problem, but it does not answer my underlying question as to why the CSS provider information for each progress bar widget is not enacted upon during the application's execution; whereas, CSS provider information associated with widgets such as labels and buttons do behave as they did with GTK3. If anyone can answer my core question, I would be very happy.
Regards,
Craig
Related
Bootstrap 3 CSS is typically used site-wide or application-wide. Knowing this, I designed a tool that HAPPENS to use Bootstrap in a sample application. This is after going through requirements processes. The explicit design was "It happens to use Bootstrap in this example, but the target user would likely provide their own styling rules."
However, the results looked great and the powers that be have asked, "can this tool be included on any arbitrary page and still look like this?"
The short answer of course is "no". Bootstrap's styles do all kinds of things like using border-sizing: border-box on a wildcard (*) selector. This is going to mess with people's existing CSS if it's not already built on Bootstrap.
Is there a way to encapsulate Bootstrap styles so that they're restricted only within that particular tool/widget? So in the div <div class="bootstrappy">, everything is affected by Bootstrap classes and outside of there, nothing is? The goal is to be able to include my Bootstrap-styled widget on a page that didn't previously include Bootstrap, without modifying what was there previously.
It's OK if I have to do this as part of a build process (I am using Grunt right now, so that'd be the best option for me); what I'm looking to avoid is manually combing through Bootstrap in order to cull or modify element-level rules so that they don't stomp over a whole page.
I'm having an issue with the "browse for items" overlay for the default widget for z3c.relationfield, which I believe is using plone.formwidget.contenttree. I've created a custom field using this but get the same problem using the IRelatedItems behavior - the overlay has no browsable content. I am still able to use the autocomplete component of this widget, and can set relations programmatically with no problem, so I don't believe there is a problem with the intids utility. I've also tested on my local machine and on a dev server and everything works perfectly, just not in production (of course).
I apologize for the vague nature of this question, but I'm stumped. Are there any common pitfalls I could look for here? Any configuration step I might be overlooking?
Take a look at the Dexterity documentation and note the following:
Relation support no longer included by default
Content tree and Autocomplete widgets no longer included by default
So maybe you need to install the widget packages manually.
I imagine changing the styling is a common requirement. Say a user wishes to change the background colour and the font style. I'm looking for a component fit into any flex application and edit the style sheets.
I know I can build one from scratch using the (get/set)Style methods and using the StyleManager class, however I didn't want to "reinvent the wheel." I assume there is a component that someone has already written - google hasn't thrown up a suitable candidate.
There's no such base component. Setting styles is very personal, so there's no common solution.
BTW, look up here
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.
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