4 ms·
> Plenty parts of GTK 2 were unstable during it's lifetime. I've written a Raleigh theme more than 12 years ago, and that one still works as it did back then.
by cm3 10y ago
> Plenty parts of GTK 2 were unstable during it's lifetime.
I've written a Raleigh theme more than 12 years ago, and that one still works as it did back then.
I believe you when you say not all parts of Gtk2 were stable and some stuff was surely evolving, but the overall I've seen no regression in Gtk2 as I did in Gtk3.
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.
Also, I know I have too little domain knowledge to judge what it takes to support HiDPI and Wayland, but what I 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 release, it'll arrive in a later version. Full rewrite efforts seldom work out.
You said Raleigh should work in 3.20, I just tried to use it as the 3.20 theme again and it's still borked compared to 3.18, but it's unsurprising if it's not the default and probably untested.
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.
- audidude 10y ago> 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 agoOne 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?