4 ms·

> That said, if Gtk3 has only been considered stable since 3.20, then more appropriate versioning/communication might have been useful, but I doubt that's what

> That said, if Gtk3 has only been considered stable since 3.20, then more appropriate versioning/communication might have been useful, but I doubt that's what you're saying. The theming API is what I was regarding as stable come 3.20. (CSS elements are finally documented, for example). And you are right, we could have done a better job of communicating it. It was obvious to those of us who work with GTK every day, (and theming has been unstable since gtk2 was released as it required C code), but it wasn't stated in large block print anywhere. We could have done better. To help with this we started, a few weeks ago, a new GTK blog to help people stay up to date. (blog.gtk.org) > Also, I know I have too little domain knowledge to judge what it takes to support HiDPI and Wayland, but what do object is focusing on too many things for a major release. What works better are time based releases where, if one feature branch misses the time window, it'll arrive in a later point release. Full rewrite kinda efforts seldom work out. Gtk3 has been large parts of rewrites done in short 6 month increments. That said, writing things like a full CSS 3 implementation that themers asked for is no small task. And making a modern toolkit that ships in 5 years does not do Free Software a service if it's too late to be useful. We've been trying to strike the right balance, but it takes developers testing things during the development cycle to really make that possible. Unfortunately, GNOME is pretty much the only project doing thate. > Finally, I just tried to use Raleigh as the 3.20 theme again and it's still totally borked compared to 3.18, but it's unsurprising if it's not the default. We should probably remove it from the list, to be honest. Adwaita "is the GTK theme", not Raleigh. I can add this to tomorrows topics at the hackfest. > But what's more important is that Gtk2's Raleigh looks really nice, whereas 3.20's Raleigh looks like it's deliberately made to look worse, which is hard to understand, given that the drawing code is supposed to be 99% unchanged, if I look at Gtk2 to Gtk3 porting guides. The drawing model of gtk2 and gtk3 are completely different. The themes are CSS now so the Raleigh theme, at minimum, has been ported from C code to CSS.

cm3 10y ago
One thing regarding theming: I quite like theme engines that implement the drawing code in C because there's a lot more flexibility and room for performance. It's also how proper emulations of other operating systems' looks was achieved without an unresponsive set of bitmaps. The general purpose'ness of CSS will inevitably have limitations that either restrict what can be drawn or how efficient it can be made.
- audidude 10y ago
  > One thing regarding theming: I quite like theme engines that implement the drawing code in C because there's a lot more flexibility and room for performance. As a long time C and assembly hacker, I certainly know the feeling. However, with were we are going, we have evidence we can do faster on the GPU with various shaders than any of us can do with hand written assembler these days. I anticipate gtk 4.x rendering to vaguely look like webrender (which if you squint hard enough, looks similar to clutter 2.0 design). > It's also how proper emulations of other operating systems' looks was achieved without an unresponsive set of bitmaps. The general purpose'ness of CSS will inevitably have limitations that either restrict what can be drawn or how efficient it can be made. Our CSS engine does support SVG for scalability just fine with "bitmaps". The most difficult part of the current win32 theme work (partially landed in 3.20) is that we have lots of widgets that there is simply no analogous in win32. So making a "on|off" toggle look like win32 isn't exactly clear. I haven't tested the new theme on win32, but I do think a bunch of it is improved (note that running the win32 theme on Linux is not the same as running the win32 theme on win32, it requires some internal windows API for some of its features).
  - cm3 10y ago
    > we have evidence we can do faster on the GPU with various shaders than any of us can do with hand written assembler these days While true, the same shader can be written and incorporated in an engine written in C. The most important feature is API stability so that good themes can be created. For example, some Gtk2 scrollbar settings like the arrow buttons seem to be gone in Gtk3. Is the idea that scrollbars should be drawn and callbacks implemented in JavaScript for arrow buttons?
    - audidude 10y ago
      >> we have evidence we can do faster on the GPU with various shaders than any of us can do with hand written assembler these days > While true, the same shader can be written and incorporated in an engine written in C. This is not true, unless you do all the same plumbing. We have two major pieces of evidence for this: 1) gtk-theme-engines from 2.x days almost universally caused crashes in applications when the did stuff wrong (and they all did) 2) You can't hide the details of the GPU pipeline behind a theme. it really changes the entire model of the application, how you store and cache state, how you pass it to the GPU, when you deliver that information, etc. > The most important feature is API stability so that good themes can be created. This is exactly why we want to have a stable release that wont be getting breaking changes. We think, practically, that most application developers will target the stable release (and therefore the stable themes). We think the primary users of unstable will be GNOME applications or other desktops that choose to align themselves with the GTK unstable cycle. > For example, some Gtk2 scrollbar settings like the arrow buttons seem to be gone in Gtk3. Is the idea that scrollbars should be drawn and callbacks implemented in JavaScript for arrow buttons? I'm not totally up to date on context here, bugzilla would be the best place to discuss this further.

cm3 10y ago

One thing regarding theming: I quite like theme engines that implement the drawing code in C because there's a lot more flexibility and room for performance. It's also how proper emulations of other operating systems' looks was achieved without an unresponsive set of bitmaps. The general purpose'ness of CSS will inevitably have limitations that either restrict what can be drawn or how efficient it can be made.

audidude 10y ago
> One thing regarding theming: I quite like theme engines that implement the drawing code in C because there's a lot more flexibility and room for performance. As a long time C and assembly hacker, I certainly know the feeling. However, with were we are going, we have evidence we can do faster on the GPU with various shaders than any of us can do with hand written assembler these days. I anticipate gtk 4.x rendering to vaguely look like webrender (which if you squint hard enough, looks similar to clutter 2.0 design). > It's also how proper emulations of other operating systems' looks was achieved without an unresponsive set of bitmaps. The general purpose'ness of CSS will inevitably have limitations that either restrict what can be drawn or how efficient it can be made. Our CSS engine does support SVG for scalability just fine with "bitmaps". The most difficult part of the current win32 theme work (partially landed in 3.20) is that we have lots of widgets that there is simply no analogous in win32. So making a "on|off" toggle look like win32 isn't exactly clear. I haven't tested the new theme on win32, but I do think a bunch of it is improved (note that running the win32 theme on Linux is not the same as running the win32 theme on win32, it requires some internal windows API for some of its features).
- cm3 10y ago
  > we have evidence we can do faster on the GPU with various shaders than any of us can do with hand written assembler these days While true, the same shader can be written and incorporated in an engine written in C. The most important feature is API stability so that good themes can be created. For example, some Gtk2 scrollbar settings like the arrow buttons seem to be gone in Gtk3. Is the idea that scrollbars should be drawn and callbacks implemented in JavaScript for arrow buttons?
  - audidude 10y ago
    >> we have evidence we can do faster on the GPU with various shaders than any of us can do with hand written assembler these days > While true, the same shader can be written and incorporated in an engine written in C. This is not true, unless you do all the same plumbing. We have two major pieces of evidence for this: 1) gtk-theme-engines from 2.x days almost universally caused crashes in applications when the did stuff wrong (and they all did) 2) You can't hide the details of the GPU pipeline behind a theme. it really changes the entire model of the application, how you store and cache state, how you pass it to the GPU, when you deliver that information, etc. > The most important feature is API stability so that good themes can be created. This is exactly why we want to have a stable release that wont be getting breaking changes. We think, practically, that most application developers will target the stable release (and therefore the stable themes). We think the primary users of unstable will be GNOME applications or other desktops that choose to align themselves with the GTK unstable cycle. > For example, some Gtk2 scrollbar settings like the arrow buttons seem to be gone in Gtk3. Is the idea that scrollbars should be drawn and callbacks implemented in JavaScript for arrow buttons? I'm not totally up to date on context here, bugzilla would be the best place to discuss this further.