User: Password:
|
|
Subscribe / Log in / New account

Reitter: Answering the question: "How do I develop an app for GNOME?"

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 14:46 UTC (Wed) by ovitters (subscriber, #27950)
In reply to: Reitter: Answering the question: "How do I develop an app for GNOME?" by epa
Parent article: Reitter: Answering the question: "How do I develop an app for GNOME?"

Please show that we broke backwards compatibility. We have loads of experience in API and ABI stability. Suggest at least providing some data when you make claims.


(Log in to post comments)

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 15:17 UTC (Wed) by epa (subscriber, #39769) [Link]

It's out of date now but I was thinking of Miguel's blog post where he points out that many third parties (ISVs) develop against Qt but few against KDE; many against GTK+ but few against GNOME; and that lack of backward compatibility is the main reason for this.

While there are programs written against GTK+ 1.x which needed porting work to 2.x, and some (such as my former preferred web browser, Dillo) which were 'lost' to the GTK+ world in this way, that's not really a fair point to make in a comparison against Qt because Qt 1.x is equally obsolete.

So I take back what I wrote; I really meant to defend Qt as having a good backwards-compatibility track record, rather than denigrate GTK+ and GNOME.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 15:33 UTC (Wed) by pboddie (guest, #50784) [Link]

I thought the lack of permissive licensing was the principal reason given by De Icaza for a lack of ISV support for Desktop Linux, although there was a much more recent blog post that also mentioned backwards-compatibility as well, as I recall (and to which you are probably referring).

Certainly, lots of people still seem to develop against Qt (despite Nokia trying to eliminate the business of supporting and developing it sustainably), and backwards-compatibility has a lot to do with that, alongside a long track-record of support for the technology actually being available.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 6, 2013 19:33 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

It's not GNOME exactly (AFAIK), but webkitgtk removed the "enable-default-context-menu" property on the WebKitWebViewSettings class in 1.9.0 (I track webkitgtk fairly closely for uzbl's benefit). Not to mention that things get deprecated all the time and the replacements do not necessarily match features of the deprecated ways. Not to mention that webkit2 is missing some support for things webkit1 supports (though I understand that webkit2 isn't "ready" yet, I don't know if it will be before these differences are addressed).

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 9:17 UTC (Thu) by ovitters (subscriber, #27950) [Link]

We deprecate things and then change it during a major version only. All libraries should be parallel installable though. Not sure what the problem is here.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 6:29 UTC (Thu) by paulj (subscriber, #341) [Link]

The rather useful and good, but not maintained, "Referencer" programme is no longer runnable on modern distros like Fedora 16. This is because it depends on a GNOME library whose functionality was deprecated and replaced with additions to GLib. GNOME doesn't ship that library anymore I think. Further, even building the library on a modern system is hard, at least using the distro based SRPM functionality on Fedora.

I mentioned it before here: https://lwn.net/Articles/526428/

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 9:16 UTC (Thu) by ovitters (subscriber, #27950) [Link]

We deprecated those libraries ages ago. Your comment actually proves my point exactly, we deprecated that library and still kept it around and maintain it.

We then changed the major version many years later.

Only *now* you're having difficulties only because your distribution does not ship the library anymore. In your other comment you suggest that somehow there are conflicts between the 2.x libraries and the 3.x. That is not the case, please show where it is.

From what I can gather, you're only running into difficulties building libraries. That your distribution does not ship this library anymore (mainly because all maintained programs did move over to gvfs) does not imply backwards compatibility was broken.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 9:32 UTC (Thu) by paulj (subscriber, #341) [Link]

The reason it's hard to build, at least using the distro SRPMs, is because it depends on other, older GNOME libraries. I'd effectively have to rebuild a whole slew of old libraries and install them somewhere, before I could build this library, before I could run my app. These slew of dependencies across a set of libraries possibly were also a significant factor in the distro no longer shipping them.

I mention this not to dispute your point that GNOME maintains binary compatibility in libraries, but to provide a data-point that suggests that this is not sufficient for functional compatibility from the users' point of view. GNOME developers could look into that and see if anything could be done, if they felt it important.

Reitter: Answering the question: "How do I develop an app for GNOME?"

Posted Feb 7, 2013 15:58 UTC (Thu) by raven667 (subscriber, #5198) [Link]

This whole thread is indicative of a real problem and I would look to the kernel for guidance. The kernel deprecates APIs but maintains and ships the old ABI, usually by having it be a shim layer to the new API. If GNOME 3 were to do the same thing then they would ship all of the GNOME 2 libraries or at least compatible stubs and consider them all part of the ABI, indefinitely. They wouldn't rely on the downstream distributors to individually package the pieces and parts and would make it easy for them to maintain ABI compatibility.

That's not the world we live in though, user space, long term compatibility isn't the biggest priority.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds