8 ms·

> Now time for gtk4 :( Hopefully easier? Unsure however. > But I think having that compatibility is one of the reasons of Linux's success, the rule of "Do not

by orra 4y ago

> Now time for gtk4 :( Hopefully easier? Unsure however. > But I think having that compatibility is one of the reasons of Linux's success, the rule of "Do not break user space". Quite. Of course, it's a sometimes repeated joke that the Linux GUI toolkit with the most binary compatibility is the Win32 API (via Wine).

pjmlp 4y ago
Depends if they use Glade, or any of the removed APIs.
- orra 4y ago
  I don't understand the Glade problem. I thought both GTK+ 3 and GTK+ 4 had a GtkBuilder class which loads .ui files? And as for creating .ui files, Cambalache is a replacement for Glade?
  - pjmlp 4y ago
    Sure if you like to write XML by hand. Cambalache is years away to reach feature parity with Glade. Then there is the whole of using Web to render the designer.
    - stuaxo 4y ago
      This sort of long slog work is where proper funding is needed. I'm sure all the distros are busy, but it sure would be nice if one of them would fund get a developer they pay to do this.
    - llothar 3y ago
      Their idea of GUI building is just too bad and backward. You define the GUI by dragging things on a Canvas and some things that are specified in text. What you never want is going through thousands of widgets in a sidebar and a bit here and a bit there. It suffers from we don't think about UI but only about technology. GUI Builder the old way stink (only XCode stinks like a perfume). There is also a reason why Microsoft does not offer a GUI Builder for their new WinUI 3
  - zorr 4y ago
    From what I've seen the .ui format for Gtk3 and Gtk4 are different and Glade does not support Gtk4 Widgets or its additional libraries like libadwaita. Cambalache is a successor for Glade but it also has issues. It uses its own storage format and you have to export to a .ui file for use in your Gtk4 project, and if you make changes to the UI file it's very difficult or even impossible to use those changes in Cambalache again. The general consensus on a few of the GNOME-related Matrix channels seems to be writing .ui files by hand.
  - rleigh 4y ago
    The XML isn't upgraded and there are no tools or XSLT to do it. You end up hand-editing the ui files by hand. Not fun or productive. There are good reasons why professional developers abandoned GTK+, and this is just one of them.
  - marcodiego 4y ago
    This is something that I unfortunately have a "reasonable" explanation. It involves some historic idiosyncrasies and GNOME devs' decisions along time. If you want to listen to some (read an) interesting story here's some of it: * First: GNOME was born without an IDE. But, there was an interesting little project (by Naba Kumar) which started in mid to late 90's called Anjuta. IIRC, Anjuta 0.x to 1.x was what was called a "monolithic" IDE; that is: it didn't had any plugins and its features were "hard-coded". The 2.0 rewrite allowed it to have plugins, but they didn't covered (at first) all of the features of Anjuta 1.x. It was only around 2.4 or 2.6 that Anjuta finally got feature-rich and reasonably stable enough to become part of the GNOME project and the "IDE of the GNOME project" although most GNOME devs didn't use it. * Second: GNOME was born without a GUI Builder. The most successful one was Glade. At first, glade generated C source code for the UI using GTK. Then people thought it was bad and someone created libglade. The 'project libglade' was two things: a XML format specifying an UI description and a library that could dynamically (at runtime) load it and build a GTK interface from that description. It could even connect signals without a single line of C source code. Since libglade seemed like a good idea it was eventually incorporated into GTK in a format that is now called GtkBuilder. Parallel to this, many events happened. Glade changed hands a few times and eventually its main developer became Chema Celorio. Celorio was a skydiver and one day he had a problem with his parachute and died. Glade development became dormant until it was picked up again by Tristan Van Berkom. Tristan modernized it, 'resurrected' it, improved its UI, rewrote many parts of it and eventually removed its code generation back-end to use only the GtkBuilder format. * Third: At the same time, Anjuta development also changed hands. I remember Johannes Schimidt and a few others. At some point, there was an integration between Glade and Anjuta, but it was not very different from running the two tools separated except for the fact that they shared the same window. There was some hope when, during the selection for Google Summer of code an interesting project was chosen: improve the integration by Pavel Kostyuchenko. The project was successful and the integration between Glade and Anjuta improved because of it. I was happy and hopeful for these facts when one day I saw that (part of) the integration code was chopped off. I was so intrigued by this fact that I decided to ask Anjuta devs personally (on IRC) what had happened. The answer was something like: "it was not as good as we'd like, fixing it would be much more work than rewriting it." That was when I decided to join the project to fix it myself. I improved the integration between Glade and Anjuta. Rewrote how it created functions inside the C source code, how it discovered automatically which .c and .h files were associated with the .ui file. Implemented automatic creation of members on the C struct that corresponded to the UI elements, fixed some bugs, wrote a documentation which was a good tutorial on how to use these features... I even implemented the preview feature in Glade. I really made the integration work to my liking. It was the workflow I dreamed. The future seemed bright: there were new developers, frequent commits, new features were implemented frequently... But GTK evolved faster than Glade. Tristan eventually abandoned it and it was picked up by Juan Pablo Ugarte. By around this time, Glade became something of a monstrosity of technical debt, slow, crash-prone and buggy but it worked. Implementing support for modern GTK features (like bindings and css) seemed too much work and too hard to do. * Fourth: Around 2013 Christian Hergert started developing a modern IDE for GNOME: GNOME Builder. He left his job, started a campaign to get money to back him up during first versions and quickly showed a lot of progress. It was said at the time that it was going to have Glade integration (it eventually did have, but it was never a decent one). The project thrived and Redhat hired him. Development of Anjuta slowly became dormant after this. It is now archived. Hergert started another project, Drafting, to replace Glade but it was de-prioritized. Ugarte basically abandoned Glade and started Cambalache. Cambalache seems like a good idea, works but has no IDE integration and is still mostly a "one man show". And that is how we arrived at where we are. GNOME still lacks a good UI builder with IDE integration and no current plans to fill this gap.
  - TingPing 4y ago
    Glade can’t render both GTK3 and GTK4 in the same process and wasn’t actively maintained. Cambalanche was a replacement supporting both.
robinsonb5 4y ago
It's not even a joke - OK, not GUI-related, but a few years ago I tried to replay Return to Castle Wolfenstein on Linux - the official Linux port would run but with no audio. The Windows version worked fine under WINE!
- p_j_w 4y ago
  Was it a Windows version or DOS version?
  - miffe 4y ago
    Return to Castle Wolfenstein is Windows. Using the Quake 3 engine.
    - p_j_w 4y ago
      Oh boy, I don't know how I missed that detail. Sorry!
    - robinsonb5 4y ago
      And there was an official Linux port. Which no longer works properly.
- erk__ 4y ago
  The multiplayer version got open sourced and there exist a contemporary project to keep it updated, but also as backwards compatible as is possible. https://www.etlegacy.com/ https://www.etlegacy.com/
- LaLaLand122 4y ago
  - https://man.archlinux.org/man/aoss.1.en https://man.archlinux.org/man/aoss.1.en - https://man.archlinux.org/man/padsp.1.en https://man.archlinux.org/man/padsp.1.en
- seba_dos1 4y ago
  Many old games work better under Wine than under modern Windows though.
kristopolous 4y ago
Windows backwards compatibility is also pretty phenomenal if you know what you're doing. There was an article a couple of years ago about taking binaries from either windows 1 or 2, changing a few bits of the header and it would run fine. Edit: actually it's covered in the Wikipedia article https://en.m.wikipedia.org/wiki/Windows_1.0x https://en.m.wikipedia.org/wiki/Windows_1.0x It's an old citation but here's the snippet: "Due to Microsoft's extensive support for backward compatibility, it is not only possible to execute Windows 1.0 binary programs on current versions of Windows to a large extent but also to recompile their source code into an equally functional "modern" application with just limited modifications" I haven't touched windows in probably 15 years though so I can't speak for any of this. Funny, I was a Windows software developer for a decade and now I know nothing about it. I don't even know if the debug tools I used to use made the leap to 64 bit
- RedShift1 4y ago
  IMO it's not phenomenal, it's the job of an operating system! Something seemingly lost to many new devs. I'm pretty convinced by now the reason the win32 API is so stable because no developer is interested in "the old stuff", so nobody tinkers with it, hence stuff doesn't break. I'm fully with Linus Torvalds on this one, DON'T break userspace!!!
  - kristopolous 4y ago
    It's actually work IIRC. Again, out of the game for 15 years but they used to be subsystems - these ABI compatibility layers Windows had one for DOS, Windows 16, "posix" and "os/2" with the last two in air quotes because it was only a subsection and they claimed mission accomplished - I think it was specifically to satisfy some government requirement but don't use me as a reference here. I don't think it could do os/2 "Presentation Manager" for instance. And there was a reason that cygwin was still a thing. I used it for an actual production project maybe 22 years ago. Wow, you've never seen slow until you run cygwin bash scripts on windows 2000. Regardless, it didn't come free - there's people up in Redmond who had that as part (or maybe all) of their job. I would have done that - maintain an esoteric part of Windows for a Microsoft salary? That's the kind of job where you have almost no boss. Sign me up. They had a bunch of weird projects like that. IE for Unix which ran on Solaris and HPUX (evolt has them: https://browsers.evolt.org/browsers/archive/ie https://browsers.evolt.org/browsers/archive/ie you can probably QEMU that if you want). They also had Alpha, MIPS and I believe PPC versions of windows. There were a lot of other things that never got done. Like Windows for Intergraph Clipper, a fact that someone somewhere has decided to vouch for me on 12 years ago over yonder: https://www.cpushack.com/2011/01/16/cpu-of-the-week-intergraph-clipper-c4-mcm/ https://www.cpushack.com/2011/01/16/cpu-of-the-week-intergra... Again, all this shit I know? totally useless.
creshal 4y ago
It hasn't been a joke for a while.
aninteger 4y ago
> Of course, it's a sometimes repeated joke that the Linux GUI toolkit with the most binary compatibility is the Win32 API (via Wine). Motif is pretty good here too.
llothar 3y ago
No definitely not easier at all. Especially because all the drawing code has changed. But Gtk5 port will be total madness. No more modal windows and no more traditional tree view. I can agree that it removes a lot of problems and maintenance from the Gtk Team, but the cost for the application developers is huge. But just as Win32API we can all still use Gtk2

by orra 4y ago

pjmlp 4y ago

Depends if they use Glade, or any of the removed APIs.

orra 4y ago
I don't understand the Glade problem. I thought both GTK+ 3 and GTK+ 4 had a GtkBuilder class which loads .ui files? And as for creating .ui files, Cambalache is a replacement for Glade?
- pjmlp 4y ago
  Sure if you like to write XML by hand. Cambalache is years away to reach feature parity with Glade. Then there is the whole of using Web to render the designer.
  - stuaxo 4y ago
    This sort of long slog work is where proper funding is needed. I'm sure all the distros are busy, but it sure would be nice if one of them would fund get a developer they pay to do this.
  - llothar 3y ago
    Their idea of GUI building is just too bad and backward. You define the GUI by dragging things on a Canvas and some things that are specified in text. What you never want is going through thousands of widgets in a sidebar and a bit here and a bit there. It suffers from we don't think about UI but only about technology. GUI Builder the old way stink (only XCode stinks like a perfume). There is also a reason why Microsoft does not offer a GUI Builder for their new WinUI 3
- zorr 4y ago
  From what I've seen the .ui format for Gtk3 and Gtk4 are different and Glade does not support Gtk4 Widgets or its additional libraries like libadwaita. Cambalache is a successor for Glade but it also has issues. It uses its own storage format and you have to export to a .ui file for use in your Gtk4 project, and if you make changes to the UI file it's very difficult or even impossible to use those changes in Cambalache again. The general consensus on a few of the GNOME-related Matrix channels seems to be writing .ui files by hand.
- rleigh 4y ago
  The XML isn't upgraded and there are no tools or XSLT to do it. You end up hand-editing the ui files by hand. Not fun or productive. There are good reasons why professional developers abandoned GTK+, and this is just one of them.
- marcodiego 4y ago
  This is something that I unfortunately have a "reasonable" explanation. It involves some historic idiosyncrasies and GNOME devs' decisions along time. If you want to listen to some (read an) interesting story here's some of it: * First: GNOME was born without an IDE. But, there was an interesting little project (by Naba Kumar) which started in mid to late 90's called Anjuta. IIRC, Anjuta 0.x to 1.x was what was called a "monolithic" IDE; that is: it didn't had any plugins and its features were "hard-coded". The 2.0 rewrite allowed it to have plugins, but they didn't covered (at first) all of the features of Anjuta 1.x. It was only around 2.4 or 2.6 that Anjuta finally got feature-rich and reasonably stable enough to become part of the GNOME project and the "IDE of the GNOME project" although most GNOME devs didn't use it. * Second: GNOME was born without a GUI Builder. The most successful one was Glade. At first, glade generated C source code for the UI using GTK. Then people thought it was bad and someone created libglade. The 'project libglade' was two things: a XML format specifying an UI description and a library that could dynamically (at runtime) load it and build a GTK interface from that description. It could even connect signals without a single line of C source code. Since libglade seemed like a good idea it was eventually incorporated into GTK in a format that is now called GtkBuilder. Parallel to this, many events happened. Glade changed hands a few times and eventually its main developer became Chema Celorio. Celorio was a skydiver and one day he had a problem with his parachute and died. Glade development became dormant until it was picked up again by Tristan Van Berkom. Tristan modernized it, 'resurrected' it, improved its UI, rewrote many parts of it and eventually removed its code generation back-end to use only the GtkBuilder format. * Third: At the same time, Anjuta development also changed hands. I remember Johannes Schimidt and a few others. At some point, there was an integration between Glade and Anjuta, but it was not very different from running the two tools separated except for the fact that they shared the same window. There was some hope when, during the selection for Google Summer of code an interesting project was chosen: improve the integration by Pavel Kostyuchenko. The project was successful and the integration between Glade and Anjuta improved because of it. I was happy and hopeful for these facts when one day I saw that (part of) the integration code was chopped off. I was so intrigued by this fact that I decided to ask Anjuta devs personally (on IRC) what had happened. The answer was something like: "it was not as good as we'd like, fixing it would be much more work than rewriting it." That was when I decided to join the project to fix it myself. I improved the integration between Glade and Anjuta. Rewrote how it created functions inside the C source code, how it discovered automatically which .c and .h files were associated with the .ui file. Implemented automatic creation of members on the C struct that corresponded to the UI elements, fixed some bugs, wrote a documentation which was a good tutorial on how to use these features... I even implemented the preview feature in Glade. I really made the integration work to my liking. It was the workflow I dreamed. The future seemed bright: there were new developers, frequent commits, new features were implemented frequently... But GTK evolved faster than Glade. Tristan eventually abandoned it and it was picked up by Juan Pablo Ugarte. By around this time, Glade became something of a monstrosity of technical debt, slow, crash-prone and buggy but it worked. Implementing support for modern GTK features (like bindings and css) seemed too much work and too hard to do. * Fourth: Around 2013 Christian Hergert started developing a modern IDE for GNOME: GNOME Builder. He left his job, started a campaign to get money to back him up during first versions and quickly showed a lot of progress. It was said at the time that it was going to have Glade integration (it eventually did have, but it was never a decent one). The project thrived and Redhat hired him. Development of Anjuta slowly became dormant after this. It is now archived. Hergert started another project, Drafting, to replace Glade but it was de-prioritized. Ugarte basically abandoned Glade and started Cambalache. Cambalache seems like a good idea, works but has no IDE integration and is still mostly a "one man show". And that is how we arrived at where we are. GNOME still lacks a good UI builder with IDE integration and no current plans to fill this gap.
- TingPing 4y ago
  Glade can’t render both GTK3 and GTK4 in the same process and wasn’t actively maintained. Cambalanche was a replacement supporting both.

robinsonb5 4y ago

It's not even a joke - OK, not GUI-related, but a few years ago I tried to replay Return to Castle Wolfenstein on Linux - the official Linux port would run but with no audio. The Windows version worked fine under WINE!

p_j_w 4y ago
Was it a Windows version or DOS version?
- miffe 4y ago
  Return to Castle Wolfenstein is Windows. Using the Quake 3 engine.
  - p_j_w 4y ago
    Oh boy, I don't know how I missed that detail. Sorry!
  - robinsonb5 4y ago
    And there was an official Linux port. Which no longer works properly.
erk__ 4y ago
The multiplayer version got open sourced and there exist a contemporary project to keep it updated, but also as backwards compatible as is possible. https://www.etlegacy.com/ https://www.etlegacy.com/
LaLaLand122 4y ago
- https://man.archlinux.org/man/aoss.1.en https://man.archlinux.org/man/aoss.1.en - https://man.archlinux.org/man/padsp.1.en https://man.archlinux.org/man/padsp.1.en
seba_dos1 4y ago
Many old games work better under Wine than under modern Windows though.

kristopolous 4y ago

Windows backwards compatibility is also pretty phenomenal if you know what you're doing. There was an article a couple of years ago about taking binaries from either windows 1 or 2, changing a few bits of the header and it would run fine. Edit: actually it's covered in the Wikipedia article https://en.m.wikipedia.org/wiki/Windows_1.0x https://en.m.wikipedia.org/wiki/Windows_1.0x It's an old citation but here's the snippet: "Due to Microsoft's extensive support for backward compatibility, it is not only possible to execute Windows 1.0 binary programs on current versions of Windows to a large extent but also to recompile their source code into an equally functional "modern" application with just limited modifications" I haven't touched windows in probably 15 years though so I can't speak for any of this. Funny, I was a Windows software developer for a decade and now I know nothing about it. I don't even know if the debug tools I used to use made the leap to 64 bit

RedShift1 4y ago
IMO it's not phenomenal, it's the job of an operating system! Something seemingly lost to many new devs. I'm pretty convinced by now the reason the win32 API is so stable because no developer is interested in "the old stuff", so nobody tinkers with it, hence stuff doesn't break. I'm fully with Linus Torvalds on this one, DON'T break userspace!!!
- kristopolous 4y ago
  It's actually work IIRC. Again, out of the game for 15 years but they used to be subsystems - these ABI compatibility layers Windows had one for DOS, Windows 16, "posix" and "os/2" with the last two in air quotes because it was only a subsection and they claimed mission accomplished - I think it was specifically to satisfy some government requirement but don't use me as a reference here. I don't think it could do os/2 "Presentation Manager" for instance. And there was a reason that cygwin was still a thing. I used it for an actual production project maybe 22 years ago. Wow, you've never seen slow until you run cygwin bash scripts on windows 2000. Regardless, it didn't come free - there's people up in Redmond who had that as part (or maybe all) of their job. I would have done that - maintain an esoteric part of Windows for a Microsoft salary? That's the kind of job where you have almost no boss. Sign me up. They had a bunch of weird projects like that. IE for Unix which ran on Solaris and HPUX (evolt has them: https://browsers.evolt.org/browsers/archive/ie https://browsers.evolt.org/browsers/archive/ie you can probably QEMU that if you want). They also had Alpha, MIPS and I believe PPC versions of windows. There were a lot of other things that never got done. Like Windows for Intergraph Clipper, a fact that someone somewhere has decided to vouch for me on 12 years ago over yonder: https://www.cpushack.com/2011/01/16/cpu-of-the-week-intergraph-clipper-c4-mcm/ https://www.cpushack.com/2011/01/16/cpu-of-the-week-intergra... Again, all this shit I know? totally useless.

creshal 4y ago

It hasn't been a joke for a while.

aninteger 4y ago

> Of course, it's a sometimes repeated joke that the Linux GUI toolkit with the most binary compatibility is the Win32 API (via Wine). Motif is pretty good here too.

llothar 3y ago

No definitely not easier at all. Especially because all the drawing code has changed. But Gtk5 port will be total madness. No more modal windows and no more traditional tree view. I can agree that it removes a lot of problems and maintenance from the Gtk Team, but the cost for the application developers is huge. But just as Win32API we can all still use Gtk2