GTK3 Theming modGTK3 Resolves layout corruption under ALL Linux Distros

I’ve been releasing Linux versions of RB/RS/Xojo apps since the ability was first introduced. Throughout the “variegations” of Linux’s desktop platforms, we’ve always had a reasonable idea that the app we released would look close tio correct on 95% of the systems it was installed onto.

And then along comes GTK3, CSS Theming, and Xojo 2018r1.

My apps are now appearing with gigantic buttons, oversize stretched icons, non-standard fonts, and all sorts of other nightmarish mashups. And, setting HiDPI just adds to the Dali-esque results.

I have learned that using “env GTK_THEME=Adwaita:light /opt/MyApp” at least stabilizes the color issues so I don’t end up with black text on back windpws, but there must be a way to stop things like button, scrollbar, progressbar, and similar from being resize from our designed layout.

Is anyone attacking this to come up with a way to say “HALT!” to the GTK3 theme free-for-all?

Under Qt I can design buttons etc. with css and it looks like I want it.

Maybe Xojo should have something like that too in Linux.

I’ve always been fan of GNOME and GTK, but this one is a real issue if we can’t override the GTK theming for our cross-platform apps. Unfortunately, jumping to QT isn’t the answer as both Xojo and we developers would need to purchase QT commercial licenses to use it in this commercial environment.

Since apps like Ardour, Audacity, The GIMP, and Lives all depend on relatively static interface design, I’m pretty sure that there is a way to prevent GTK themes from affecting your app. I’ve submitted inquiries to a couple of dev sites to see what we can find out about this.

I think the real problem is that Xojo isn’t able to handle the way the new theming free-for-all works. The other platforms don’t really have the same feature; so I don’t think it’s a Xojo problem - it’s a Linux problem. The goal of CSS theming is to allow users to design a theme they like and the defaults are just huge compared to the other current commercial operating systems.

Consumer level customers would complain just as much if they have a custom theme and for some odd reason your app is locked into whatever design you did.

Maybe you could create a theme that matches control sizing to what the other platforms use. In a managed environment where the IT department sets these things you’d probably be able to get away with that.

Not necessarily - again with Ardour, Audacity, and similar having static layouts and control themes, it will depend on what you app is used for. In the Linux world, commercial-level users are far more interested in getting the task done, than how it looks while doing it. Granted, an ugly app would not cut it, but as long as the appearance is professional, they’re happy with it.

I’d happily create a theme if I knew what the Xojo Framework elements matched in CSS. This is what was asked for in another thread.

Do you have a link to where you asked that? I feel like that kind of question wouldn’t get ignored. Also try pinging William, he might have an answer for you.

you could specify the sizes by code?, like this

dim theCtrl as Control for i as integer = 0 to mainwin.ControlCount-1 theCtrl = mainwin.Control(i) if theCtrl isa PushButton then PushButton(theCtrl).Height = 26 PushButton(theCtrl).Width = 100 PushButton(theCtrl).TextFont = "System" PushButton(theCtrl).TextSize = 10 end if next

Nope - the GTK+ themes override those. I have custom control classes that do just those things so that I can keep things looking good on all three platforms. I’ve even tried obfuscating the class’ names, but the Xojo Framework is still identifying them as Button, Label, etc. and the Adwaita theme that is applied as the default creates much havoc at run time. The themes get applied to the controls no matter what unless you have your own CSS to override the user-selected CSS theme settings.

Apparently, William had a session during XDC that both discussed this and provided examples, but having not attended XDC, I have no access to that information through normal Xojo documentation and examples.

I know I can pay for access to the XDC sessions, but this type of information should be public, not locked behind a pay-wall, since it affects default Xojo application operations.

I also submitted a bug that discussed this and asked for direct CSS definitions, I was referred to docs that I’d already looked into that did not answer the questions about the Xojo framework names as a CSS style would see and apply to them. The report was then closed.

A few new discoveries when using JUST Xojo on GTK3 - tested with Ubuntu 16.04, CentOS 7.5, SLED 12r3, AND MINT 18.2.

  • If you use a BevelButton instead of a PushButton, you’re safe
  • If you turn off the border on a TextField and use “SmallSystem” and Border = False, the text will display properly without the need for a 30px high control.
  • If you set the font in a PopupMenu to SmallSystem, it will work as expected without forced resizing.

More as I progress.

Thanks - that helps to get Control sizes a bit more in a “cross platform size”.

That works for me if I set “SmallSize, 0” in the IDE’s LayoutEditor.
Why doesn’t it work when assigning that in the Open Event?

IDE LayoutEditor: System, 0

Sub Open() Handles Open
  #if TargetLinux then
    me.TextFont = "SmallSystem"
    me.Border = false
  #endif
End Sub

I obviously don’t want to change every TextField in the LayoutEditor… Especially since every Control is subclassed - so I’m looking for a way to assign that “style” in the TextField subclass - so that I only need to adjust it in one place, one and most important: for all.

Any idea what’s going on with TextField’s here? Why does it only work via LayoutEditor - and more important: How to achieve this via Code?

Nice, thanks for the updates! However, the workarounds you’re using are the parts that aren’t system native. BevelButton is the wrong control on macOS, and Small System is for small controls. I am very glad you are making progress and that you’re finding solutions, but they’re not cross platform!

We’re now responsible for

#if TargetLinux then UseCorrectHeightSettings #endif
which, as I mentioned in another thread is the last thing I want to be doing with a tool sold as a cross-platform write once and deploy tool.

While I wish you the best in getting your needs fulfilled, I won’t consider this issue closed until we get the information about how to properly theme using CSS.

I didn’t mean that they were “solutions”, just examples of how I’ve made things look normal.

I’m working on the behind the scenes aspect of the CSS to Xojo naming.

Xojo has recently posted a blog: GTK3 Can Be a Pain in the Themes
Has anyone tried to load a “built-in theme”? I tried, but…
I see some changes when running on Ubuntu. Text position is not quite right then.
I tried to run the examples on Debian 9 (with both provided and some downloaded themes). The Controls (Buttons, TextFields, …) are still way too high - always.

So I wonder… does anyone know how to get the Controls “reasonably sized” with a standard Debian 9 installation?
What kind of “theme” do I need for Debian? Is there a theme that works on both standard Ubuntu and Debian installations (and allows Controls to be sized similar to GTK2 or macOS)?

You can declare into GTKWidget which has NaturalWidth and NaturalHeight as Integer properties.
Still, GTK raises the wish for a constraint-based or RubberControls-like behavior, because changing the sizes of controls obviously isn’t enough for a good-looking layout.

Sure, that will tell me 29 or so.
Our Windows and Dialog Layouts are “30 pt” spaced. That looks appropriate on all Windows, macOS, Linux (GTK2).
And we don’t intend to re-layout every single dialog for GTK-3… Why? Because a grid of 35 might be fine, but that would look wrong on all other platforms. And I don’t want to count the number of dialogs and hours of work required…
So I was hoping that the “themes” would allow to have a theme with Controls that are sized similar to GTK-2 (or macOS).
That seems to work on Ubuntu, but I can’t get it to work on Debian 9. And I still wonder why - and how to make it work on Debian 9.

Currently I cannot even make my Parallels Ubuntu installation accept my Mac keyboard …
Loading a default theme is somewhat against the user’s preferences, I guess, but yes: Without a floating layout GTK3 design is really a pain. I’ll give the theme demo a try the next days.

EDIT: I wonder if a GTKGrid would be something useful to have …

[quote=396705:@Tim Jones]
I didn’t mean that they were “solutions”, just examples of how I’ve made things look normal.
I’m working on the behind the scenes aspect of the CSS to Xojo naming.[/quote]

Yes, they are only workarounds, and the bad news, is that the problem is not only Theming. It is the GTK implementation itself.

For example, the controls (labels and textfields) are contained inside a GtkHBox (Which it is DEPRECATED) instead of being in the window, also really LOTS of UI bugs and you can say, Xojo changed GTK version, but did not implement the GTK3 standars :frowning:

I still use Xojo With GTK2 For Linux distributing Linux Apps.

Also, The base container for widgets in xojo is a GtkFixed widget, and this is the documentation:

The GtkFixed widget is a container which can place child widgets at fixed positions and with fixed sizes, given in pixels. GtkFixed performs no automatic layout management.

For most applications, you should not use this container! It keeps you from having to learn about the other GTK+ containers, but it results in broken applications. With GtkFixed, the following things will result in truncated text, overlapping widgets, and other display bugs:

  • Themes, which may change widget sizes.

  • Fonts other than the one you used to write the app will of course change the size of widgets containing text; keep in mind that users may use a larger font because of difficulty reading the default, or they may be using a different OS that provides different fonts.

  • Translation of text into other languages changes its size. Also, display of non-English text will use a different font in many cases.

In addition, GtkFixed does not pay attention to text direction and thus may produce unwanted results if your app is run under right-to-left languages such as Hebrew or Arabic. That is: normally GTK+ will order containers appropriately for the text direction, e.g. to put labels to the right of the thing they label when using an RTL language, but it can’t do that with GtkFixed. So if you need to reorder widgets depending on the text direction, you would need to manually detect it and adjust child positions accordingly.

Finally, fixed positioning makes it kind of annoying to add/remove GUI elements, since you have to reposition all the other elements. This is a long-term maintenance problem for your application.

If you know none of these things are an issue for your application, and prefer the simplicity of GtkFixed, by all means use the widget. But you should be aware of the tradeoffs.

Have you created a Feedback with the GTK-3-implementation issues you’re seeing?
That allows Xojo to have an official task to implement it correctly… and let’s hope that allows Themes to work properly.
Let us know the Feedback Case Number, so that we can add it to our top cases.