More Planning Details For GTK4 & Beyond

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Luke
    replied
    Originally posted by dkasak View Post
    I wonder how many posts above are from people who actually develop with GTK+3. I've been developing with GTK+2 since about 15 years ago, and with GTK+3 since about 3 years ago, and I've *never* *EVER* had issues with API stability. I've written 'form' and 'datasheet' classes using both GTK+2 and GTK+3, and written a bunch of database-centric apps, including an ETL framework with a nice GTK+3 GUI. I use quite a bit of the functionality available, and create custom cell renderers in the datasheet class.

    What I *think* people are whinging about is the theming subsystem, which admittedly is changing quite rapidly. But theming is not a core part of GTK+3, and not a part of the "API". Maybe someone would like to share some examples of API changes that they've actually encountered?
    Try the huge mess that GTK 3.21.3 made out of the Nemo and Caja desktop icon. I spend more than a month hacking code to fix this in Caja until a Nemo dev tracked down the old commit that made Nautilus work to between Nautilus 3.7.90 and 3.7.91. From there I was able to find the exact change needed, but to use it required porting all the Nemo/Nautilus transparent desktop code to caja, and it worked only in the composited case. Finally a Nautilus dev wrote code to draw the background in non-composited fallback sessions for nautilus-desktop, and I ported that to caja with good results. Still, we now have three different build cases for Caja: GTK2, GTK 3.20 and earlier, and GTK 3.21 or later.

    Leave a comment:


  • oleid
    replied
    Originally posted by boxie View Post

    Somewhat. if we look at the kernel and their "Don't Break User Space" mantra we see a completely different side of the coin.

    There are many things that can be done to stop a constant churn in ABI breakage, "Not working on it anymore" is just one
    To be fair : procfs and sysfs entries change all the time. I don't know how often I had to adapt scripts.

    Leave a comment:


  • Stoatally
    replied
    My comment is still "awaiting moderation", what a surprise.

    Leave a comment:


  • Hamsterkill
    replied
    Will this new expected fragmentation lead to an increase in resource usage due to having potentially several different versions of GTK loaded for different applications?

    Leave a comment:


  • boxie
    replied
    Originally posted by MaxToTheMax View Post
    This is a problem why? It's exactly the appropriate course of action for anyone who maintains a popular dependency but also wants to do significant new development.
    Somewhat. if we look at the kernel and their "Don't Break User Space" mantra we see a completely different side of the coin.

    There are many things that can be done to stop a constant churn in ABI breakage, "Not working on it anymore" is just one

    Leave a comment:


  • BwackNinja
    replied
    Originally posted by Stoatally View Post
    I left this comment on the blog (it's in moderation):



    Maybe I come off as an arse, but really, that versioning scheme is awful.
    The versioning is intended for unstable api versions to be releasable and included in distributions because Gnome software will inevitably be depending on these changes. There isn't much point in making changes if you can only depend on them two years after they've been made. Everything about this is the best possible situation for Gnome, and the rest of the stakeholders get a GTK that they can rely on at the expense of trying to make incompatible changes with a 2-year cadence to avoid a proliferation of GTK versions installed.

    Using new features available in the current unstable version is largely just asking for pain, so 3rd-party apps will always lag behind. If Gnome has its way, this won't just be a proliferation of GTK versions, but a proliferation of runtimes installed for sandboxed flatpak apps.

    Gnome has interpreted "we want a stable api" as "give us a version you'll stop breaki --ahem-- fixing in ways that stop our code from working" rather than "let us use new features without having to deal with unrelated code breaking". I can understand the other side though. It's not fun being restricted from improving your code because people depend on things remaining exactly the same. The GTK2 to GTK3 move was great in that regard especially because of the struct hiding. Struct members were no longer part of the api, so things can change behind the scenes without applications breaking and needing to be recompiled.

    It'd probably be rather interesting to see what api changes (rather than just additions) are planned that would make such a transition in development process make sense in the long term. I'd also wonder how hard porting applications would be for each major release.

    Leave a comment:


  • bug77
    replied
    Originally posted by dkasak View Post

    What themes have you built and what changes did you get burned by? Just curious ...

    I'm also still waiting to hear about *API* breakages that people have encountered.
    I'm a KDE guy. The only thing that bites me it breakages in breeze-gtk. The KDE guys work hard to keep that up to date (the Gnome guys don't do that for Qt), but occasionally some changes slip by.

    Leave a comment:


  • dkasak
    replied
    Originally posted by bug77 View Post

    Oh, good. So theming can continue being the mess that it currently is. I'm glad we got that out of the way.
    What themes have you built and what changes did you get burned by? Just curious ...

    I'm also still waiting to hear about *API* breakages that people have encountered.

    Leave a comment:


  • bug77
    replied
    Originally posted by Stoatally View Post
    I left this comment on the blog (it's in moderation):



    Maybe I come off as an arse, but really, that versioning scheme is awful.
    Ha, developers that understand software is not about them, but the end user... Good luck finding those.

    Leave a comment:


  • Stoatally
    replied
    I left this comment on the blog (it's in moderation):

    As a software developer I believe that if we want to be considered a profession, we have to actually be professional in what we do. A small part of this is versioning our software in an intuitive way and not being afraid to make our lives and the lives of the people who interact with our software (developers, packagers, people reporting bugs and end users) better “just for the sake of it”.

    You, I and many others here understand this versioning scheme as it at least has its roots in how other GNOME software is versioned. However it is more complicated and as a result worse than semantic versioning which has clear guidelines on this exact situation.

    Please do not make us live with more esoteric versioning.
    Maybe I come off as an arse, but really, that versioning scheme is awful.

    Leave a comment:

Working...
X