7 ms·

GTK invented its own bespoke Object Oriented Programming system for C, called GObject: https://docs.gtk.org/gobject/ https://docs.gtk.org/gobject/ Naturally, i

by arjvik 4y ago

GTK invented its own bespoke Object Oriented Programming system for C, called GObject: https://docs.gtk.org/gobject/ https://docs.gtk.org/gobject/ Naturally, it's very annoying to use this C-based OOP API in any other language, especially languages that have their own incompatible OOP type system like Java or C++. One of the biggest reasons to use Vala is that it's OO system is GObject, making interacting with GTK and GLib code significantly more painless.

pavlov 4y ago
GObject is a real tragedy of the NIH syndrome in open source. In the late 1990s there already was Objective-C. It already had open source compiler support, a battle-tested runtime, a free software desktop environment, and a corporate sponsor that became the world’s most valuable corporation. Instead of using what was already there, the Linux GUI community extracted a poor shadow of Obj-C out of the GIMP image processing program (itself a poor shadow of a commercial market leader).
- tannhaeuser 4y ago
  I've always wondered why GNUstep didn't work out; would've been a fantastic way of porting Mac OS apps, in theory at least. I guess that is what you're saying as well.
- PaulDavisThe1st 4y ago
  GIMP development started in 1995. The GNU Objective C frontend (the one that has stayed in use) started in 1993. I would hardly consider the GIMP developers (who became the early developers of GTK) to be rash in their option not to adopt a language that had only been available for a couple of years in the open source world. And all these years later, at a time when Apple has essentially abandoned Objective C, GTK and Glib continue to provide bindings for dozens of languages to create cross-platform GUI applications, and even if many of us don't agree with the direction(s) it has taken, GTK itself has continued to evolve, whereas UI libraries that came with Objective C have become frozen in time. So in short, not really a tragedy at all.
  - kennywinker 4y ago
    Apple has not abandoned Objective C. It still has first class support on all their platforms, and the vast majority of their OS frameworks and applications are developed in ObjC. Swift is growing as an internal tool, but it’s nowhere near even 50% of the 1st party code on a mac or iphone. Improvements have slowed on ObjC, as Apple’s focus switched to swift - ObjC 2.0 in 2014 was the last major change.
    - pavlov 4y ago
      Also the most popular iOS third-party apps are all Obj-C[++]. The C++ interop is very important for companies like Meta. They have no incentive to rewrite anything in Swift. If you look at minutes spent by end users on the iOS platform, I’m guessing it’s at least 95% inside Obj-C apps today.
      - pjmlp 4y ago
        Which is exactly why Apple showed the following at WWDC 2022, just to make it clear that the time for Objective-C is done. https://developer.apple.com/videos/play/wwdc2022/102/ https://developer.apple.com/videos/play/wwdc2022/102/ > The Objective-C language, AppKit & UIKit frameworks, and Interface Builder have empowered generations of developers. These technologies were built for each other, and will continue to serve us well for a long time to come, but over time new abstractions become necessary. For a while now, you've seen us hard at work defining the next generation of integrated language, frameworks, and tools: Swift, SwiftUI, and Xcode Previews. > Tight integration in a development platform like this requires that all three pieces be designed and evolved together, both driving and driven by one another. Swift result builders were inspired by SwiftUI's compositional structure. SwiftUI's declarative views were enabled by Swift value types. And Xcode Previews was specifically designed for, and enabled by, both. Now, the result is the best development platform that we have ever built. And this year, Swift, SwiftUI, and Xcode all have fantastic updates that take this vision further, and make it even easier for you to build great apps for all of our platforms. And it all starts with Swift.
        4y ago
- vkazanov 4y ago
  How so? You probably don't understand the context of mid-90s free and open software. Nothing is free, nothing open, relevant business models do not yet exist. Few things that are open barely work: linux takes hours to compile-tweak-recompile, all the tools are half-baked and semi-broken. You had to fix most things yourself. Anyways, the only tools that do work reliably and have no license issues are coming from FSF: Emacs, gcc, unix utils, etc. Note that objC was not free, and the free version sucked most of the time. GCC did have world-class support for C though. C was and still is a good choice for a core portable cross-language library. But UIs are probably the only programming context where OOP fits well. So people came with Gobject. It all makes total sense, and that's why the whole thing survives to this very day.
  - pavlov 4y ago
    > “C was and still is a good choice for a core portable cross-language library. But UIs are probably the only programming context where OOP fits well. So people came with Gobject.” That’s my exact criticism: they came up with GObject instead of using the C-based solution that already existed, had open source compiler support, and was actively developed by Apple. The GTK community made a huge mistake in trying to turn GIMP’s poor design into a generic GUI framework rather than collaborating with GNUstep on creating a next-generation framework.
    - pjmlp 4y ago
      Apple would never collaborated with GNUStep, first of all, when GNUStep started NeXT was still around. Secondly, Steve Jobs wasn't an happy fellow about the whole story regarding GCC request to get back the frontend changes into upstream. Gtk OOP is actually a clone of Motif OOP, which Gtk was cloning in first place.
      - pavlov 4y ago
        They wouldn’t have needed Apple’s collaboration to build a new UI framework on Obj-C, just like nobody needed SCO’s permission to build Linux. GTK’s two original sins were 1) cloning Motif in the first place, 2) doubling down on that design instead of throwing away GIMP as the prototype that it was. They’ve been forever reliving the 1990s due to these bad choices.
- sampo 4y ago
  > In the late 1990s there already was Objective-C. Objective-C is closer to the original, or at least early, Alan Kay and Smalltalk flavor of object oriented languages. In the late 1990s, we had already had 10 years of C++, so the C++ flavor "C with classes" type of object oriented programming was more familiar to most people. I'd guess already then, the Smalltalk flavor of Objective-C felt a bit alien to many, who had grown familiar with the C++ flavor.
- mhd 4y ago
  > GObject is a real tragedy of the NIH syndrome in open source. It is, but I wouldn't look at Objective-C as the previous invention. X11 already hat the Toolkit Intrinsics (Xt), and it's not like they were unknown to the developers, the first version of Gimp having been written in Motif. A new toolkit in the vein of Xaw/Motif/OLIT would've been a more immediate choice, but then again, no two persons seem to have the same preferences when it comes to object-orientation. (I'm sitting in the proverbial glasshouse here, having switched my own "let's make some widgets for Qt 0.x" project to "let's reinvent X11 toolkits" in the mid to late 90s)
PaulDavisThe1st 4y ago
I've been writing C++ GUI apps with gtkmm for more than 22 years. I rarely notice GObject, other than in a few minor cases where the gtkmm wrapper didn't fully provide everything from the C level. In almost all those cases, the only reason I am still aware of them is because I use an ancient version of both gtk and gtkmm. I would say that it is essentially completely painless to interact with GTK and Glib via gtkmm and glibmm.
- nurettin 4y ago
  > I've been writing C++ GUI apps with gtkmm for more than 22 years How did you resist Qt?
  - gsliepen 4y ago
    I did the same as PaulDavisThe1st; gtkmm is an excellent C++ interface for Gtk, such that I wonder why they even bothered to create Vala except for NIH syndrome. Qt had similar issues in the past: it wasn't pure C++, it was C++ "with extensions"; you had to use a custom compiler (moc), and you had to use Q-versions of everything the STL provides (QString, QVector, and so on). Of course things were different more than a decade ago: C++11 did not exist yet or compiler support was lacking, and Gtk and Qt couldn't wait for it to catch up.
    - nurettin 4y ago
      Yes you had to use qmake. 99% of the developers never even touched moc, it was baked into the build system and gave you things like signals and slots. I remember doing this https://github.com/nurettin/trendline_analysis_qt/blob/master/csvgraphicspathitem.hpp https://github.com/nurettin/trendline_analysis_qt/blob/maste... (Qt gave me graphicspathitems that I could do rubberband select on an accelerated qgraphicsview more than 15 years ago. I loved gtkmm and standard c++, but Qt was simply amazing. And nobody forced you to use Q*containers. I always found that argument a bit moot. And it had none of these "problems" after 2012.
  - PaulDavisThe1st 4y ago
    When I started, Qt required a preprocessor (moc) for the build process. Gtkmm did not do, and use libsigc++. This seemed like a clear sign to me that it was technically superior. 22+ years later I would say that both Qt and Gtkmm have their own pros and cons. They have both run into pretty deep issues with integrating their own drawing model into the windows, macOS and X11 models. They both provide things that the other does not. At this point, I don't see one as better than the other, and for a long established application like mine, the idea of switching is essentially unthinkable.
captainmuon 4y ago
It's very pleasant to use in Python, though. The object model is very close to C++ and Java, and I wonder if they could have made the memory layouts slightly different so that they were compatibile with C++, like in COM. But anyway gtkmm for C++ seems to work well.

by arjvik 4y ago

pavlov 4y ago

GObject is a real tragedy of the NIH syndrome in open source. In the late 1990s there already was Objective-C. It already had open source compiler support, a battle-tested runtime, a free software desktop environment, and a corporate sponsor that became the world’s most valuable corporation. Instead of using what was already there, the Linux GUI community extracted a poor shadow of Obj-C out of the GIMP image processing program (itself a poor shadow of a commercial market leader).

tannhaeuser 4y ago
I've always wondered why GNUstep didn't work out; would've been a fantastic way of porting Mac OS apps, in theory at least. I guess that is what you're saying as well.
PaulDavisThe1st 4y ago
GIMP development started in 1995. The GNU Objective C frontend (the one that has stayed in use) started in 1993. I would hardly consider the GIMP developers (who became the early developers of GTK) to be rash in their option not to adopt a language that had only been available for a couple of years in the open source world. And all these years later, at a time when Apple has essentially abandoned Objective C, GTK and Glib continue to provide bindings for dozens of languages to create cross-platform GUI applications, and even if many of us don't agree with the direction(s) it has taken, GTK itself has continued to evolve, whereas UI libraries that came with Objective C have become frozen in time. So in short, not really a tragedy at all.
- kennywinker 4y ago
  Apple has not abandoned Objective C. It still has first class support on all their platforms, and the vast majority of their OS frameworks and applications are developed in ObjC. Swift is growing as an internal tool, but it’s nowhere near even 50% of the 1st party code on a mac or iphone. Improvements have slowed on ObjC, as Apple’s focus switched to swift - ObjC 2.0 in 2014 was the last major change.
  - pavlov 4y ago
    Also the most popular iOS third-party apps are all Obj-C[++]. The C++ interop is very important for companies like Meta. They have no incentive to rewrite anything in Swift. If you look at minutes spent by end users on the iOS platform, I’m guessing it’s at least 95% inside Obj-C apps today.
    - pjmlp 4y ago
      Which is exactly why Apple showed the following at WWDC 2022, just to make it clear that the time for Objective-C is done. https://developer.apple.com/videos/play/wwdc2022/102/ https://developer.apple.com/videos/play/wwdc2022/102/ > The Objective-C language, AppKit & UIKit frameworks, and Interface Builder have empowered generations of developers. These technologies were built for each other, and will continue to serve us well for a long time to come, but over time new abstractions become necessary. For a while now, you've seen us hard at work defining the next generation of integrated language, frameworks, and tools: Swift, SwiftUI, and Xcode Previews. > Tight integration in a development platform like this requires that all three pieces be designed and evolved together, both driving and driven by one another. Swift result builders were inspired by SwiftUI's compositional structure. SwiftUI's declarative views were enabled by Swift value types. And Xcode Previews was specifically designed for, and enabled by, both. Now, the result is the best development platform that we have ever built. And this year, Swift, SwiftUI, and Xcode all have fantastic updates that take this vision further, and make it even easier for you to build great apps for all of our platforms. And it all starts with Swift.
      - 4y ago
vkazanov 4y ago
How so? You probably don't understand the context of mid-90s free and open software. Nothing is free, nothing open, relevant business models do not yet exist. Few things that are open barely work: linux takes hours to compile-tweak-recompile, all the tools are half-baked and semi-broken. You had to fix most things yourself. Anyways, the only tools that do work reliably and have no license issues are coming from FSF: Emacs, gcc, unix utils, etc. Note that objC was not free, and the free version sucked most of the time. GCC did have world-class support for C though. C was and still is a good choice for a core portable cross-language library. But UIs are probably the only programming context where OOP fits well. So people came with Gobject. It all makes total sense, and that's why the whole thing survives to this very day.
- pavlov 4y ago
  > “C was and still is a good choice for a core portable cross-language library. But UIs are probably the only programming context where OOP fits well. So people came with Gobject.” That’s my exact criticism: they came up with GObject instead of using the C-based solution that already existed, had open source compiler support, and was actively developed by Apple. The GTK community made a huge mistake in trying to turn GIMP’s poor design into a generic GUI framework rather than collaborating with GNUstep on creating a next-generation framework.
  - pjmlp 4y ago
    Apple would never collaborated with GNUStep, first of all, when GNUStep started NeXT was still around. Secondly, Steve Jobs wasn't an happy fellow about the whole story regarding GCC request to get back the frontend changes into upstream. Gtk OOP is actually a clone of Motif OOP, which Gtk was cloning in first place.
    - pavlov 4y ago
      They wouldn’t have needed Apple’s collaboration to build a new UI framework on Obj-C, just like nobody needed SCO’s permission to build Linux. GTK’s two original sins were 1) cloning Motif in the first place, 2) doubling down on that design instead of throwing away GIMP as the prototype that it was. They’ve been forever reliving the 1990s due to these bad choices.
sampo 4y ago
> In the late 1990s there already was Objective-C. Objective-C is closer to the original, or at least early, Alan Kay and Smalltalk flavor of object oriented languages. In the late 1990s, we had already had 10 years of C++, so the C++ flavor "C with classes" type of object oriented programming was more familiar to most people. I'd guess already then, the Smalltalk flavor of Objective-C felt a bit alien to many, who had grown familiar with the C++ flavor.
mhd 4y ago
> GObject is a real tragedy of the NIH syndrome in open source. It is, but I wouldn't look at Objective-C as the previous invention. X11 already hat the Toolkit Intrinsics (Xt), and it's not like they were unknown to the developers, the first version of Gimp having been written in Motif. A new toolkit in the vein of Xaw/Motif/OLIT would've been a more immediate choice, but then again, no two persons seem to have the same preferences when it comes to object-orientation. (I'm sitting in the proverbial glasshouse here, having switched my own "let's make some widgets for Qt 0.x" project to "let's reinvent X11 toolkits" in the mid to late 90s)

PaulDavisThe1st 4y ago

I've been writing C++ GUI apps with gtkmm for more than 22 years. I rarely notice GObject, other than in a few minor cases where the gtkmm wrapper didn't fully provide everything from the C level. In almost all those cases, the only reason I am still aware of them is because I use an ancient version of both gtk and gtkmm. I would say that it is essentially completely painless to interact with GTK and Glib via gtkmm and glibmm.

nurettin 4y ago
> I've been writing C++ GUI apps with gtkmm for more than 22 years How did you resist Qt?
- gsliepen 4y ago
  I did the same as PaulDavisThe1st; gtkmm is an excellent C++ interface for Gtk, such that I wonder why they even bothered to create Vala except for NIH syndrome. Qt had similar issues in the past: it wasn't pure C++, it was C++ "with extensions"; you had to use a custom compiler (moc), and you had to use Q-versions of everything the STL provides (QString, QVector, and so on). Of course things were different more than a decade ago: C++11 did not exist yet or compiler support was lacking, and Gtk and Qt couldn't wait for it to catch up.
  - nurettin 4y ago
    Yes you had to use qmake. 99% of the developers never even touched moc, it was baked into the build system and gave you things like signals and slots. I remember doing this https://github.com/nurettin/trendline_analysis_qt/blob/master/csvgraphicspathitem.hpp https://github.com/nurettin/trendline_analysis_qt/blob/maste... (Qt gave me graphicspathitems that I could do rubberband select on an accelerated qgraphicsview more than 15 years ago. I loved gtkmm and standard c++, but Qt was simply amazing. And nobody forced you to use Q*containers. I always found that argument a bit moot. And it had none of these "problems" after 2012.
- PaulDavisThe1st 4y ago
  When I started, Qt required a preprocessor (moc) for the build process. Gtkmm did not do, and use libsigc++. This seemed like a clear sign to me that it was technically superior. 22+ years later I would say that both Qt and Gtkmm have their own pros and cons. They have both run into pretty deep issues with integrating their own drawing model into the windows, macOS and X11 models. They both provide things that the other does not. At this point, I don't see one as better than the other, and for a long established application like mine, the idea of switching is essentially unthinkable.

captainmuon 4y ago

It's very pleasant to use in Python, though. The object model is very close to C++ and Java, and I wonder if they could have made the memory layouts slightly different so that they were compatibile with C++, like in COM. But anyway gtkmm for C++ seems to work well.