Thanks, MATE!
Thanks, MATE!
Posted Jun 15, 2015 21:42 UTC (Mon) by ajmacleod (guest, #1729)In reply to: Thanks, MATE! by dowdle
Parent article: MATE 1.10 released
What have we gained with KDE 4,5 / Gnome 3? Nothing useful, in my estimation. Tools and important features that were just maturing nicely were thrown out the window and never replaced with anything but talk and ideas.
It's nice therefore to see MATE keeping the Gnome2 codebase from rotting into insignificance; my production desktop servers are still CentOS 6 and Gnome 2 for the time being but they sure as anything won't be going CentOS 7 / Gnome 3, ever!
On my personal machine I ditched full blown desktop environments when KDE self-destructed with the semantic desktop disaster and have been fairly happy with Enlightenment (17,18, now 19). It's no replacement for KDE 3 / Gnome2 / MATE on a system requiring central management though...
Posted Jun 16, 2015 6:19 UTC (Tue)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Jun 16, 2015 17:17 UTC (Tue)
by paulj (subscriber, #341)
[Link] (1 responses)
This kind of thing doesn't help advance the Linux desktop.
Posted Jun 19, 2015 12:14 UTC (Fri)
by epa (subscriber, #39769)
[Link]
It might be better to pick a set (or several sets) of desktop libraries and bless each set as 'supported'. At that point the upstream for that particular set of libraries becomes GNOME 2.x or KDE 5.x or whatever. So if GNOME 3 comes out you then have to make an explicit decision whether this is the upstream applicable to the currently supported 'GNOME 2.x' environment. When KDE 6 is out, the distribution must decide whether this is the upstream for the existing 'KDE 5.x' package set. In some cases it may be, because there is backwards compatibility. In some cases an alternative project such as MATE may be chosen as the upstream for the older package set. And in some cases the distribution may decide that despite some loss of compatibility they are still going to adopt the new upstream, and replace the existing set of libraries, because it's close enough or they don't have the resources to do otherwise. Which is fine, but the point is it must be an explicit decision. Not just "hey, 3 is a bigger number than 2 so it's obviously the replacement".
If you really wanted to do things properly then the next step would be to restrict third-party access to only these supported sets of desktop libraries. So nothing which isn't packaged as a part of GNOME itself is allowed to link against libgnomefrozzle, because libgnomefrozzle hasn't been picked by the distribution as something it commits to maintaining compatibility for in the future. It shouldn't even be in the global library path. This sounds extreme coming from the freewheeling Linux way, and particularly so if GNOME's own documentation tells you that libgnomefrozzle is a public API. But I suggest it is the only way to avoid the problem of apps breaking in the future: once you expose a library to third party apps you then have to maintain it. If you're not certain you can do that, don't expose it. This is analogous to kernel development where exposing a feature to userspace constrains the future flexibility to change it.
Posted Jun 21, 2015 13:59 UTC (Sun)
by Richard_J_Neill (subscriber, #23093)
[Link] (4 responses)
Posted Jun 21, 2015 15:36 UTC (Sun)
by flussence (guest, #85566)
[Link] (3 responses)
Posted Jun 21, 2015 21:54 UTC (Sun)
by BlueLightning (subscriber, #38978)
[Link] (2 responses)
Posted Jun 22, 2015 23:44 UTC (Mon)
by efitton (guest, #93063)
[Link] (1 responses)
Posted Jun 23, 2015 8:08 UTC (Tue)
by BlueLightning (subscriber, #38978)
[Link]
I am well aware there are people who have given up on kmail. I just wanted to say for balance that not everyone has. Continuing to evaluate the state of it as it was several years ago is disingenuous at best.
Thanks, MATE!
Tools and important features that were just maturing nicely were thrown out the window and never replaced with anything but talk and ideas.
I think the worst of it may be breaking compatibility with third party programs written against older GNOME and KDE frameworks. Unless the distributions carefully keep around versioned libraries all the way back...
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
It works really well, and still looks prettier than the later versions. The only downside is that the KDE apps are mostly frozen.
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!