4 ms·

Please don't assume bad faith. Glade was not "killed," there are technical reasons why Glade cannot be used for GTK4 (I can give more detail if you want). There

by zxzax 5y ago

Please don't assume bad faith. Glade was not "killed," there are technical reasons why Glade cannot be used for GTK4 (I can give more detail if you want). There is currently a new tool being developed by a Glade maintainer, catch this guadec talk later this month if you want to know more: https://events.gnome.org/event/9/contributions/191/ https://events.gnome.org/event/9/contributions/191/ Nobody is particularly happy about having to edit the XML directly but it's the best option right now until the new tools stabilize.

shock 5y ago
> Nobody is particularly happy about having to edit the XML directly but it's the best option right now until the new tools stabilize. You are proving GP's point for him: > So I rather waste my time on Earth on platforms that value good UI/UX tooling. The fact that that Glade was deprecated without a replacement being ready means exactly that GNOME does not "value good UI/UX tooling".
- zxzax 5y ago
  What you've said is really not correct, at all. For one, Glade is not deprecated in the sense that it doesn't work any more, it still works okay with GTK3, however it has a number of limitations that may make it difficult to use (which it always had, nothing has changed here). Two, a replacement is being worked on, I'm really not sure what your criticism is besides "go faster" which, I'm sure we all wish we could write code faster and have it work perfectly and do everything the first time, but that's not realistic. Edit: Just to be clear here, in my opinion the new tools will likely end up being a large improvement on Glade. Glade is a pretty old application that by design does a number of weird things that don't match current best practices, you can see some of them if you read the blog post that was posted above.
- freedomben 5y ago
  > The fact that that Glade was deprecated without a replacement being ready means exactly that GNOME does not "value good UI/UX tooling". That's a false dichotomy. It could be (and I believe is) that things are a tradeoff. They obviously value good tooling (what developer doesn't? and look at the docs), but they value other things too and had to make a decision. With limited resources you can't do it all.
mumblemumble 5y ago
I think that this might speak to the deeper problem that a lot of people have experienced with GTK: stability. The project isn't a huge well-funded company with lots of vendor-lock in like Microsoft is; it can't afford to be rethinking how the GUI toolkit should work every few years like Microsoft does. (Or continuing to support and maintain all the old no-longer-favored GUI frameworks like Microsoft does.) It's great that GTK4 has decided to commit to API stability, but, at this point, it may be too little, too late as far as the project's reputation among many developers is concerned. Having to lose a venerable tool like Glade to get to the API-stable version doesn't exactly take the edge off.
- zxzax 5y ago
  I've posted about this before, but if you want GTK and you believe API stability is the most important thing then you should just use GTK3. The API there is frozen. I'm not sure what "reputation" you're referring to but if GTK does not meet your needs, and Qt (or something else) does, then I think that's great for you, you should just use that.
  - badsectoracula 5y ago
    > if you want GTK and you believe API stability is the most important thing then you should just use GTK3. The API there is frozen That is certainly not a solution, you just postpone the problem. The real solution would be the Gtk4 to be 100% backwards compatible at both the API and ABI level with Gtk3 and similarly with Gtk5, Gtk6, etc. Otherwise you're just subscribing to wasting your time - it might be now or it might be 5 years from now, it doesn't matter however as it will happen unless the Gtk developers finally decide to stop breaking their library every few years. (of course don't get me wrong, it is their library and they can do whatever they please with it, they are giving it for free and they are not beholden to anyone - however that doesn't mean others like to have their code broken and waste time that they could use to improve their applications instead)
    - mumblemumble 5y ago
      Alternatively GTK3 could get a higher level of ongoing support. That was what I was alluding to when I referenced Microsoft. For example, WinForms has technically been superseded for ages now, but, while it's not necessarily getting any big new features, WinForms apps still look decent on newer versions of Windows, benefit from things like updates to the common dialog boxes, and continue to be well-supported in new versions of the developer tools. So one doesn't necessarily have to have a lot of anxiety about leaving an old WinForms app on WinForms. With GTK3, on the other hand, I would guess that it's going to get the absolute bare minimum of love, and probably become a liability rather sooner than I might like, because the project simply doesn't have the resources to maintain a higher level of support. And yeah, you're right, the GTK team isn't beholden to anyone. But... GUI code is expensive to write and expensive to maintain. So a GUI toolkit can have an outsize impact on the health of projects that use it. There's value in talking about things like this publicly, so that anyone who's shopping for a GUI toolkit can have a better understanding of what they might be getting into.
pjmlp 5y ago
Thanks for the link, I will watch it when the opportunity comes. However it is like the sibling comments mention, this hasn't been properly managed as message to the UI/UX community. So when someone used to Forms, WPF/Blend, Qt Designer, Interface Builder, Delphi, C++ Builder, Swift UI, Flutter, JetPack Composer,... sees blogs and tutorials where .ui files are written by hand and direct use of GtkBuilder is praised, eventually all interest is gone. Anyway, thanks for the link and for jumping in
- zxzax 5y ago
  That blog is just one developer's opinion, not an official statement. Although I will say I share the opinion, Glade messes up my ui files and I can't recommend using it if you want to use any newer widgets. It has always had those problems, but now with GTK4 it's no longer really worth it to try to work around them. Also, Glade is not really even used by GNOME designers that much, what they do is make mockups in some other tool (usually Inkscape) and then have the developers implement it. I don't know about other GTK based desktops, though I think some Elementary developers are working on this: https://github.com/akiraux/Akira https://github.com/akiraux/Akira
qwerty456127 5y ago
> Nobody is particularly happy about having to edit the XML directly I wouldn't mind editing a concise XML dialect (XML really doesn't have to be monstrous, a dialect it can be designed with humans in mind). A visual designer producing XML files as its output doesn't actually solve the problem. VisualStudio's developer experience (where you can change everything on the fly, go to the relevant piece of code in a click or two, refactor something and get it also changed in the designer etc) feels really seamless and fluent while PyQt with PyCharm+QtDesigner seems nice but not nearly like that. It seems to me nothing can be considered a serious and worthy improvement until we have an actual integrated visual RAD IDE. I would immediately buy the paid version of PyCharm (I'm using the community edition if they built a good and well-integrated visual designer in it, for whatever a desktop toolkit they prefer).

by zxzax 5y ago

shock 5y ago

> Nobody is particularly happy about having to edit the XML directly but it's the best option right now until the new tools stabilize. You are proving GP's point for him: > So I rather waste my time on Earth on platforms that value good UI/UX tooling. The fact that that Glade was deprecated without a replacement being ready means exactly that GNOME does not "value good UI/UX tooling".

zxzax 5y ago
What you've said is really not correct, at all. For one, Glade is not deprecated in the sense that it doesn't work any more, it still works okay with GTK3, however it has a number of limitations that may make it difficult to use (which it always had, nothing has changed here). Two, a replacement is being worked on, I'm really not sure what your criticism is besides "go faster" which, I'm sure we all wish we could write code faster and have it work perfectly and do everything the first time, but that's not realistic. Edit: Just to be clear here, in my opinion the new tools will likely end up being a large improvement on Glade. Glade is a pretty old application that by design does a number of weird things that don't match current best practices, you can see some of them if you read the blog post that was posted above.
freedomben 5y ago
> The fact that that Glade was deprecated without a replacement being ready means exactly that GNOME does not "value good UI/UX tooling". That's a false dichotomy. It could be (and I believe is) that things are a tradeoff. They obviously value good tooling (what developer doesn't? and look at the docs), but they value other things too and had to make a decision. With limited resources you can't do it all.

mumblemumble 5y ago

I think that this might speak to the deeper problem that a lot of people have experienced with GTK: stability. The project isn't a huge well-funded company with lots of vendor-lock in like Microsoft is; it can't afford to be rethinking how the GUI toolkit should work every few years like Microsoft does. (Or continuing to support and maintain all the old no-longer-favored GUI frameworks like Microsoft does.) It's great that GTK4 has decided to commit to API stability, but, at this point, it may be too little, too late as far as the project's reputation among many developers is concerned. Having to lose a venerable tool like Glade to get to the API-stable version doesn't exactly take the edge off.

zxzax 5y ago
I've posted about this before, but if you want GTK and you believe API stability is the most important thing then you should just use GTK3. The API there is frozen. I'm not sure what "reputation" you're referring to but if GTK does not meet your needs, and Qt (or something else) does, then I think that's great for you, you should just use that.
- badsectoracula 5y ago
  > if you want GTK and you believe API stability is the most important thing then you should just use GTK3. The API there is frozen That is certainly not a solution, you just postpone the problem. The real solution would be the Gtk4 to be 100% backwards compatible at both the API and ABI level with Gtk3 and similarly with Gtk5, Gtk6, etc. Otherwise you're just subscribing to wasting your time - it might be now or it might be 5 years from now, it doesn't matter however as it will happen unless the Gtk developers finally decide to stop breaking their library every few years. (of course don't get me wrong, it is their library and they can do whatever they please with it, they are giving it for free and they are not beholden to anyone - however that doesn't mean others like to have their code broken and waste time that they could use to improve their applications instead)
  - mumblemumble 5y ago
    Alternatively GTK3 could get a higher level of ongoing support. That was what I was alluding to when I referenced Microsoft. For example, WinForms has technically been superseded for ages now, but, while it's not necessarily getting any big new features, WinForms apps still look decent on newer versions of Windows, benefit from things like updates to the common dialog boxes, and continue to be well-supported in new versions of the developer tools. So one doesn't necessarily have to have a lot of anxiety about leaving an old WinForms app on WinForms. With GTK3, on the other hand, I would guess that it's going to get the absolute bare minimum of love, and probably become a liability rather sooner than I might like, because the project simply doesn't have the resources to maintain a higher level of support. And yeah, you're right, the GTK team isn't beholden to anyone. But... GUI code is expensive to write and expensive to maintain. So a GUI toolkit can have an outsize impact on the health of projects that use it. There's value in talking about things like this publicly, so that anyone who's shopping for a GUI toolkit can have a better understanding of what they might be getting into.

pjmlp 5y ago

Thanks for the link, I will watch it when the opportunity comes. However it is like the sibling comments mention, this hasn't been properly managed as message to the UI/UX community. So when someone used to Forms, WPF/Blend, Qt Designer, Interface Builder, Delphi, C++ Builder, Swift UI, Flutter, JetPack Composer,... sees blogs and tutorials where .ui files are written by hand and direct use of GtkBuilder is praised, eventually all interest is gone. Anyway, thanks for the link and for jumping in

zxzax 5y ago
That blog is just one developer's opinion, not an official statement. Although I will say I share the opinion, Glade messes up my ui files and I can't recommend using it if you want to use any newer widgets. It has always had those problems, but now with GTK4 it's no longer really worth it to try to work around them. Also, Glade is not really even used by GNOME designers that much, what they do is make mockups in some other tool (usually Inkscape) and then have the developers implement it. I don't know about other GTK based desktops, though I think some Elementary developers are working on this: https://github.com/akiraux/Akira https://github.com/akiraux/Akira

qwerty456127 5y ago

> Nobody is particularly happy about having to edit the XML directly I wouldn't mind editing a concise XML dialect (XML really doesn't have to be monstrous, a dialect it can be designed with humans in mind). A visual designer producing XML files as its output doesn't actually solve the problem. VisualStudio's developer experience (where you can change everything on the fly, go to the relevant piece of code in a click or two, refactor something and get it also changed in the designer etc) feels really seamless and fluent while PyQt with PyCharm+QtDesigner seems nice but not nearly like that. It seems to me nothing can be considered a serious and worthy improvement until we have an actual integrated visual RAD IDE. I would immediately buy the paid version of PyCharm (I'm using the community edition if they built a good and well-integrated visual designer in it, for whatever a desktop toolkit they prefer).