| |||||||||||||
GNOME Shell to support a "classic" modeGNOME Shell to support a "classic" modePosted Nov 21, 2012 19:14 UTC (Wed) by ebassi (subscriber, #54855)In reply to: GNOME Shell to support a "classic" mode by raven667 Parent article: GNOME Shell to support a "classic" mode
I'm not familiar with the internals of GNOME but what about notifications or IPC or VFS plugins? IPC and VFS, and settings, are sitting at the GLib level, our lowest common denominator; GLib's API and ABI were not bumped. a lot of functionality that was in separate libraries was deprecated and moved into GTK+ 3.x and GLib; the symbols are different, and the libraries are still available for applications to use, so you can definitely run a GNOME 2 application in GNOME 3, should you choose to do so. obviously, it would be better to port to non deprecated tech, but it's not mandatory. let me give you a for instance: Banshee is a GTK+ 2.x (and GNOME 2.x) applications, given that only recently Mono has been updated to support GNOME 3 API; I can use it without an hitch under GNOME 3.4 and 3.6, and all its functionality remains untouched. true, some stuff works better when integrated in GNOME 2's panel - but to be fair, it's all inside extensions that can be removed, and I look forward to the point where Banshee will be a proper GNOME application again. the core applications in GNOME are tied pretty much with the rest of the environment, because they are designed to be that way; you can avoid using Nautilus, after all, but you cannot complain that Nautilus 3.6 does not work without the rest of its dependencies, because Nautilus is not meant to be a file manager that can work under every desktop environment under the sun - and it certainly isn't up to you to tell the Nautilus maintainers what they have to spend time on. the whole point of the "GNOME Classic" exercise is to provide a different workflow for some users without shipping a completely separate set of dependencies (which we cannot maintain, and that nobody stepped up to maintain in the past 3 years, even after repeated calls for it).
(Log in to post comments)
GNOME Shell to support a "classic" mode Posted Nov 21, 2012 19:23 UTC (Wed) by Zizzle (guest, #67739) [Link]
> true, some stuff works better when integrated in GNOME 2's panel
And what do we users gain from all this application breakage?
Less "API cruft" for the devs?
Wow sounds like a good reason for my music player to break. Thanks guys keep up the good work!
GNOME Shell to support a "classic" mode Posted Nov 21, 2012 19:38 UTC (Wed) by ovitters (subscriber, #27950) [Link]
Please be less vague, less accusing and less pointless sarcasm. That or don't complain when you get a response in kind.
As said elsewhere: XMMS still will run fine under GNOME 3. And I do mean the gtk+1.x compiled XMMS, though maybe your distribution doesn't ship it anymore.
GNOME Shell to support a "classic" mode Posted Nov 21, 2012 19:47 UTC (Wed) by Zizzle (guest, #67739) [Link]
So XMMS with gtk+1.x is the official media player for GNOME3?
All the iTunes users will be jealous. This year will surely be the year of the linux desktop.
GNOME Shell to support a "classic" mode Posted Nov 21, 2012 20:02 UTC (Wed) by ovitters (subscriber, #27950) [Link] Ah, the stupid sarcasm again. Anyway, to quote yourself
And what do we users gain from all this application breakage? You said application breakage in some weird relation to the GNOME 2 panel. I responded to that. Now instead it is about some official GNOME 3 media player? Whatever.
GNOME Shell to support a "classic" mode Posted Nov 21, 2012 20:54 UTC (Wed) by Zizzle (guest, #67739) [Link]
> You said application breakage in some weird relation to the GNOME 2 panel
Someone complained about parallel installs of GNOME2 and 3.
ebassi says that the gnome 2 libs are parallel installable so it's all good.
But then later admits that doesn't actually help that much since application functionality is often reduced/broken in GNOME3. HIS example was Banshee. But it's all the user/applications fault, not GNOME3.
I questioned the benefits of the changes that caused that breakage.
Your defense was that OMG! XMMS still works.
A true WTF. I'm not even sure why you would make the leap to XMMS.
XMMS has nothing to do with this conversation.
GNOME Shell to support a "classic" mode Posted Nov 22, 2012 18:01 UTC (Thu) by paulj (subscriber, #341) [Link]
The work done at the library level doesn't always help the end-user though. E.g. "Referencer" is a really nice GTK+ C++ BibTex management app. It used some APIs that moved from a GNOME library (gnomevfsmm? gnomeuimm? I forget which) to Glib (to do with URIs and VFS). Unfortunately, Fedora decided these were crufty old, deprecated libraries and stopped shipping them - and so stopped shipping referencer too.
I tried building the old srpms, but that leads to a huge number of dependencies, including old gnome stuff that conflicts - iirc. So that wasn't practical, is my vague memory.
I got maybe a quarter to a third of the way of converting Referencer over to the GLib equivalents before giving up, and deciding it was easier just to switch to using Zotero - which is a cross-platform web service + Mozilla XUL based app.
GNOME Shell to support a "classic" mode Posted Nov 22, 2012 19:37 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
Great example. Referencer is the _only_ application so far that I've been beaten up about in my family technical support role in the transition from a gnome2 to gnome3 desktop experience on Fedora.
When it went missing I given a very specifically told to get that back on the desktop and laptop systems in use. So I resurrected the necessary bits from Fedora packaging git and rebuilt it and its "longer than I really felt comfortable with" set of dependencies for in-family packages. I'm sure as hell not going to offer to maintain this for anyone outside my household.
We are evaluating replacement applications. So far, the user in question hasn't really liked the other options available. If it were a C application, I could probably seriously take a look at porting it. But the fact that it uses c++ bindings, bindings which themselves are not being ported afaik, porting it is a not starter. I'm not going to put myself on the hook for maintaining low level c++ binding as prereq to port this application. It'd be easier to nuke it from orbit and rebuild it as C or vala using the maintained bindings.
GNOME Shell to support a "classic" mode Posted Nov 22, 2012 19:46 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
WTF? There are no C++ bindings for GTK3?
GNOME Shell to support a "classic" mode Posted Nov 22, 2012 21:05 UTC (Thu) by paulj (subscriber, #341) [Link]
There are. The problem isn't the C++ bindings, it's that some GNOME library got deprecated. Similar, but different functionality, went into a GTK+ library (VFS kind of stuff). The deprecated old GNOME library became difficult to package because of dependencies it seems.
The porting is fairly trivial, but it's not mechanical. Referencer unfortunately uses things like the old URI thingy all over the place. By the 2nd day I got fed up and switched to Zotero.
GNOME Shell to support a "classic" mode Posted Nov 23, 2012 6:49 UTC (Fri) by kigurai (guest, #85475) [Link]
Being slightly off topic, but I would also recommend looking at Mendeley. Not FOSS, but totally awesome.
GNOME Shell to support a "classic" mode Posted Nov 22, 2012 20:42 UTC (Thu) by tuna (guest, #44480) [Link]
Gtkmm3 is available for gtk+3. I had no problems porting my little program (https://github.com/tuna74/TunaAudioExtracter) from gtkmm2.4.
GNOME Shell to support a "classic" mode Posted Nov 22, 2012 20:58 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
was that previously using the libgnomeuimm and libgnomevfsmm and other bindings before the gtk3 port?
If you can point me to any project that has made the jump successfully from using libgnomeuimm to using gtk3mm I'd love to look over their changes as a starting point.
-jef
|
|||||||||||||