|
|
Subscribe / Log in / New account

MATE 1.10 released

Version 1.10 of the MATE Desktop has been released. Perhaps the most notable new feature is that all MATE components can now be built with GTK+2 or GTK+3, although GTK+3 support is still labeled "experimental." Also new in this update are ePub support in the Atril document viewer and a new audio-mixing library named libmatemixer.


to post comments

Thanks, MATE!

Posted Jun 13, 2015 16:36 UTC (Sat) by oldtomas (guest, #72579) [Link] (34 responses)

You saved my life. Having just finished a Jessie install for my SO, she was about to kill me after having seen the "new" Gnome (I prepared her for "some changes" and tried to not infect her with my prejudices).

MATE, and she's now a happy Debian camper again. All is well.

Thanks, MATE!

Posted Jun 15, 2015 3:36 UTC (Mon) by voltagex (guest, #86296) [Link] (33 responses)

Just on a slight side-note, Debian has 1.8.2 in Jessie and 1.10 in Experimental. I wonder if the packages can be built for Jessie from the Experimental dsc safely.

Thanks, MATE!

Posted Jun 15, 2015 5:53 UTC (Mon) by ncm (guest, #165) [Link] (32 responses)

I am finding 1.8.2 entirely satisfactory. You will too unless you need epub support in atril.

Last I heard, gtk3 was way too unstable to link anything non-Gnome against. "Unstable", meaning they would happily break anything downstream at a whim. Has that changed? I guess Cinnamon uses it.

Thanks, MATE!

Posted Jun 15, 2015 8:50 UTC (Mon) by wander_homer (guest, #103150) [Link] (2 responses)

In my experience GTK+3 has been pretty stable. Our software is linked against GTK 3.4 and the binaries work without any issues on systems with 3.16 and so on.

Thanks, MATE!

Posted Jun 17, 2015 3:52 UTC (Wed) by zenaan (guest, #3778) [Link] (1 responses)

Without "our software" being defined, your anecdote is struggling even for anecdoctal status.

Thanks, MATE!

Posted Jun 17, 2015 10:26 UTC (Wed) by wander_homer (guest, #103150) [Link]

Probably won't tell you much but the software is an audio player called DeaDBeeF (to be more precise, various plugins for it).

Thanks, MATE!

Posted Jun 15, 2015 16:44 UTC (Mon) by darkshram (guest, #58643) [Link] (23 responses)

GTK3 is not exactly desktop neutral. I use MATE since day 1 in a custom systemd-less and gnome3-less distro. The funny thing is: to make MATE (and any other desktop environment different from GNOME3) to coexist in peace with gtk3 applications (gthumb for example) and stop spamming ~/.xsession-errors, gtk3 has to be patched to stop it from 'forcing' some gtk3 apps to look for org.gnome.SessionManager.

Thanks, MATE!

Posted Jun 15, 2015 19:37 UTC (Mon) by tetromino (guest, #33846) [Link]

See https://bugzilla.gnome.org/show_bug.cgi?id=693203

GtkApplication needs some sort of a session manager that allows clients to register over dbus. At the moment, the only such session manager is gnome-session (both xfce and kde session managers currently require registration over xsmp), so that's the only one that GtkApplication supports.

If you want a minimalistic, desktop-neutral session manager for a non-gnome, non-systemd environment - please write one and submit a patch for GtkApplication to use it. It would help out lots of other people using a minimalistic distro!

Thanks, MATE!

Posted Jun 15, 2015 19:45 UTC (Mon) by dowdle (subscriber, #659) [Link] (11 responses)

As I understand it, Plasma 5 requires SDDM to be installed. More and more desktop environments seem to need their preferred graphical login managers present... even if they aren't running... and GNOME isn't the only culprit. I'm not saying they do so for the same reasons.

Thanks, MATE!

Posted Jun 15, 2015 21:42 UTC (Mon) by ajmacleod (guest, #1729) [Link] (8 responses)

Yet more reason to just ditch them and their badly thought out megalomaniac clutter. In the 3.x series KDE got to a high point of usefulness, stability and manageability (almost completely neglected by all desktops these days in the desperate rush to "be Windows") Gnome 2, ditto.

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...

Thanks, MATE!

Posted Jun 16, 2015 6:19 UTC (Tue) by epa (subscriber, #39769) [Link] (2 responses)

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!

Posted Jun 16, 2015 17:17 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

Which they don't, because it can be impractically difficult to build older libs within a distro shipping, say, the latest GNOME. E.g. gnomemmui has disappeared in Fedora because the build-dependencies became impossibly unwieldy. With the loss of that library, so have perfectly functional, useful applications such as referencer.

This kind of thing doesn't help advance the Linux desktop.

Thanks, MATE!

Posted Jun 19, 2015 12:14 UTC (Fri) by epa (subscriber, #39769) [Link]

I guess part of the problem is that the distribution considers there to be a single upstream for GNOME. So when upstream goes 'ooh, shiny!' and moves on to GNOME 3, you pull down the latest version. But GNOME 3 is not necessarily a compatible replacement for older versions, nor does it necessarily have a smooth migration path (where applications will, at worst, go through a deprecation and warning cycle).

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.

Thanks, MATE!

Posted Jun 21, 2015 13:59 UTC (Sun) by Richard_J_Neill (subscriber, #23093) [Link] (4 responses)

Btw, KDE3 is still being maintained by the Trinity Desktop Project. (Ubuntu packages exist, so easy to try it).
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!

Posted Jun 21, 2015 15:36 UTC (Sun) by flussence (guest, #85566) [Link] (3 responses)

From what I've heard about the likes of kmail2 from many, many people who tried to use it, that's no downside at all...

Thanks, MATE!

Posted Jun 21, 2015 21:54 UTC (Sun) by BlueLightning (subscriber, #38978) [Link] (2 responses)

I don't know about that. I use kmail2 daily - it still has its issues, that is true; however it's probably at almost the same level as kmail1 was in terms of stability and things working - kmail1 was by no means perfect (I also used it for years prior). Honestly I think what it really needs is a few more people working on it.

Thanks, MATE!

Posted Jun 22, 2015 23:44 UTC (Mon) by efitton (guest, #93063) [Link] (1 responses)

2007. The official switch from kmail1 to kmail2 was 2007. So that it is nearly the same level as eight year old code (in your opinion, others deeply entrenched in the KDE project have removed kmail2 from their systems) is hardly encouraging.

Thanks, MATE!

Posted Jun 23, 2015 8:08 UTC (Tue) by BlueLightning (subscriber, #38978) [Link]

It's a large application with a lot of functionality.

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!

Posted Jun 16, 2015 12:43 UTC (Tue) by Mannigfaltigkeit (guest, #103163) [Link]

That is simply wrong. I know for a fact that Plasma5 will work fine with KDM,LightDM,GDM and XDM, without any SDDM package installed.

Thanks, MATE!

Posted Jun 16, 2015 17:30 UTC (Tue) by ovitters (guest, #27950) [Link]

GNOME(-shell) doesn't need GDM to be running. It does want GDM to be installed, but that could be avoidable (IIRC some gschema that should've been put into gsettings-desktop-schemas instead of the GDM one). GDM is used for the lock screen, so if you don't use GDM you'll not be able to lock it.

Needing to have GDM installed is unfortunate, but "meh". I help out in a distribution where at the same time everything should work perfectly out of the box, but at the same time get complains about too many dependencies.

In this case GDM is installed while it isn't strictly needed. Oh well.

Thanks, MATE!

Posted Jun 16, 2015 1:56 UTC (Tue) by ncm (guest, #165) [Link] (9 responses)

For the record, I have had no complaints about systemd. Unlike pulseaudio, it just worked from the first day. Pulseaudio, too, works, nowadays, which I gather is mainly a consequence of downstream apps no longer depending on optional features of ALSA that it could not emulate.

Dbus strikes me as fundamentally flawed. I feel sure that once Lennart gets a good look at it he will roll up his sleeves and supplant the heck out of it with a soundly engineered system.

Thanks, MATE!

Posted Jun 16, 2015 11:43 UTC (Tue) by Wol (subscriber, #4433) [Link]

PulseAudio pretty much "just worked" from day 1 too ... it's just that its dependencies didn't ... (says me who, gentoo user, still hasn't configured/setup PA - if it isn't set up by default it isn't on my system ...)

Following the dbus mess, I get the impression it's a complicated use mess, made worse by the fact a lot of people don't want to install its dependencies for one reason or another ... (systemd for example ...).

Cheers,
Wol

Thanks, MATE!

Posted Jun 16, 2015 17:34 UTC (Tue) by drag (guest, #31333) [Link] (7 responses)

A large part of Pulseaudio's early nastiness can be contributed to Ubuntu's implementation of Pulseaudio was poorly executed and Alsa drivers themselves were in a really bad state.

In the bad old days any system I had I know I would have to work around alsa bugs. Usually this meant, minimally, setting up a asoundrc file and setting the PCM format, rate, and buffer sizes because the drivers themselves choose poor defaults. Unless I did this then poor sound quality, stuttering video playback, and other things was the normal consequence. Pulseaudio devs refused to implement work arounds and 'tweak' configuration knobs to work around broken drivers and this forced a lot of good fixes to happen... unfortunately for end users the turn around time for driver enhancements in Linux is about 1-2 years. So they were plagued with continuous problems until Distros picked up more modern kernels.

And by the time Pulseaudio came out I was already switching away from Ubuntu. I didn't understand at the time why people had so many issues using Pulseaudio. When I went back to trying to use Ubuntu and Debian on my desktop I found out that they really just did a bad job. Debian required a significant amount of effort to get Pulseaudio running since it wasn't the default... just installing the deb package without putting a lot of effort in reconfiguration the system manually would yield a almost completely broken audio system. Ubuntu tried to integrate it, but some of the configuration choices they made were bad and caused problems for end users.

Nowadays it seems most of these issues have been resolved and, generally speaking, the issues people run into are either actual Pulseaudio issues (probably most of them) or related to the fact that they have been hamfisted with their system and are doing things like insisting on using alsamixer (which was fundamentally broken prior to Pulseaudio, would regularly configure hardware is terrible ways without any fault on the end user, and hasn't gotten any better) or are trying to use 'minimalistic' desktops that require a great deal of configuration to work correctly and they have missed something important audio-related.

Thanks, MATE!

Posted Jun 16, 2015 20:53 UTC (Tue) by paulj (subscriber, #341) [Link] (6 responses)

These rationalisations of "The users must suffer so the code can be redeemed" have almost religious parallels. It's not good user-experience engineering though, is it? I personally don't think it has helped further the reach of the Linux desktop at all. At least, amongst my peer group, the mid-90s and early 00s Linux enthusiasts, many have abandoned it on the desktop.

Thanks, MATE!

Posted Jun 17, 2015 0:46 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

That's true, this wasn't the best user experience but the ultimate responsibility falls on the distributor otherwise what are they for? No one had to ship PA if they didn't want to, they could have kept ESD or patched PA to make the experience anything they wanted, it's Free software. Of course no one had then or has now a test environment sufficient to discover all these integration issues, even on common hardware and not every distribution has the best experts capable of integrating every software adequately.

Thanks, MATE!

Posted Jun 17, 2015 7:27 UTC (Wed) by paulj (subscriber, #341) [Link]

This is Linux. Responsibility is distributed and diffuse. The distributors are not always well resourced, it may not be possible to do major integration work, and it may not be possible to swim against upstream tides. Upstreams set the tone and have responsibilities too, in addition to the distributors. This seems a collective failure.

Thanks, MATE!

Posted Jun 17, 2015 1:49 UTC (Wed) by rwhogg (guest, #103069) [Link] (3 responses)

They're not the only ones: <http://tirania.org/blog/archive/2013/Mar-05.html>.

What's more important, the code or its users? I'd argue it's the users. Programs exist to support users, not the other way around.

We haven't always sacrificed users for the sake of code though. We still maintain X11 and make sure it works nicely with different hardware, for example. That's the right choice, even if it causes us some pain, because otherwise we'd break every graphical application ever. I'll cheer when Wayland fixes everything, but forcing a buggy Wayland onto the world would be a disaster. Let's wait until it's ready. It sounds like with ALSA/PulseAudio we made the wrong choice. Ditto with GTK+ 3.

Transitioning takes time; Python 2/3, Perl 5/6, and IPv4/6 proved that. In the meantime, the best experience we can muster comes from helping users make the most of the imperfect software they have. If Microsoft can do it, so can we - it might just mean reallocating some developers away from the next exciting rewrite.

Thanks, MATE!

Posted Jun 17, 2015 12:06 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> If Microsoft can do it, so can we - it might just mean reallocating some developers away from the next exciting rewrite.

Microsoft has the advantage of (literally) multi-billion R&D budgets and many thousands of developers that can be explicitly told what to do, in a top-down manner.

And even with that huge advantage, Microsoft can't do it most of the time.

Thanks, MATE!

Posted Jun 17, 2015 13:29 UTC (Wed) by rwhogg (guest, #103069) [Link]

> Microsoft has the advantage of (literally) multi-billion R&D budgets and many thousands of developers that can be explicitly told what to do, in a top-down manner.

It's true that we can't pay everyone to do exactly what we want, but we can change the incentive structures of open source so that huge rewrites and unnecessary new projects are less rewarded than maintaining existing widely used software. You don't have to employ someone to influence their actions. (You're right that it certainly helps though!)

I'm not saying it's going to be easy. But all sorts of techniques can make this easier:

* Large organizations like Intel, Red Hat, etc. could shift from funding GNOME to funding MATE (for example)
* Promote the less prominent but nonetheless productive and important developers in existing projects more heavily than they are currently. Social capital goes a long way in the volunteer case. This would discourage starting unnecessary brand-new projects just to get the desired attention.
* Make it easier to package software for different distributions so there's less incentive to go it alone. This will also make integration issues and the upstream/packager divide less problematic.
* In the case of people who ARE employed in open source, the Microsoft tactic works quite nicely.

We don't have to, and can't, support every piece of software this way. But we should be able to support enough to have a viable desktop environment.

Thanks, MATE!

Posted Jun 24, 2015 12:50 UTC (Wed) by epa (subscriber, #39769) [Link]

I think the point is more that Microsoft *don't* have developers who can be told what to do, top-down. There are, even today, hundreds of thousands of developers writing for the Windows desktop, far more than the total employees of Microsoft. And the existing applications that work today must continue to work tomorrow. The Linux approach of moving on to a new version of the desktop libraries and stranding older applications is simply not an option. This forces Microsoft to be disciplined about compatibility, whether they like it or not. Sure, things do go away in the end: Win16 applications don't run on 64-bit Windows, but that is at least a decade after Win32 became common. And of course there are the anecdotes about my beloved application which worked fine on Windows 95 but won't run on Windows 7. But on the whole, their record of not breaking stuff is enviable, and so far away from current Linux practice it's not even funny.

If distributions put their foot down and said: all binary applications which currently work must continue to work in future releases, then upstreams would have to start taking compatibility seriously. Of course this will never happen, and I am not even seriously advocating it. But perhaps there is some middle ground.

Thanks, Cinnamon!

Posted Jun 15, 2015 23:42 UTC (Mon) by dashesy (guest, #74652) [Link] (4 responses)

I am running Cinnamon now for 2 years, the latest versions seem to be pretty stable, in fact it is so fine I wonder why anyone uses anything else :)

Thanks, Cinnamon!

Posted Jun 16, 2015 15:10 UTC (Tue) by madscientist (subscriber, #16861) [Link] (2 responses)

Well, I ran Linux Mint Cinnamon for over a year (until I loaded Ubuntu GNOME 15.04 in April) and I didn't have such a rosy experience. As a design it was fine, but it was not stable for me. For example, changing the volume slider would cause the entire desktop to crash fairly regularly. I filed a bug and got zero response, for months: https://bugs.launchpad.net/linuxmint/+bug/1274802 even though a number of other people reported the same issue.

I find the GNOME 3 desktop, with the addition of the "System monitor" and "Frippery panel favorites" add-on extensions and a few settings using Tweak Tool (focus follows mouse, convert CapsLock to CTRL) to be very satisfactory... and stable.

YMMV, of course, but that was mine.

Thanks, Cinnamon!

Posted Jun 16, 2015 15:27 UTC (Tue) by dashesy (guest, #74652) [Link] (1 responses)

Yes that looks embarrassing! I use Cinnamon in Fedora, I guess maybe that has something to do with it.

Thanks, Cinnamon!

Posted Jun 17, 2015 10:17 UTC (Wed) by marcel.oliver (subscriber, #5441) [Link]

I am also using Cinnamon on Fedora. Right now, it's in pretty good shape, but its history of distro-integration is not that great. In particular, its history of bugs does not make it a straightforward recommendation for users not able to deal with problems. For about a hear up until fairly recently, bluetooth integration was borked (in fact, I could only use it via the KDE Control Center) and only started working again with the upgrade to version 2.6. Earlier, there were problems with the network configuration (VPN setup, PEAP/MSCHSAP authentication) and probably a bunch of other things that I don't recall. Updates get pushed at random times, which is good when they fix something, but all of the above problems also appeared at random times via regular updates.

I am still very grateful that Cinnamon exists because it is better than Gnome classic in many little details that matter for daily work; unfortunately, Gnome classic is treated like the bastard child of Gnome and it does not give the impression that a lot of thought goes into what it should provide and how it should evolve.

I noticed that a Fedora Cinnomon Spin is under development and may provide some stability guarantees to Cinnamon on Fedora.

Mate is great on old hardware and fills an important niche. Generally, however, I am concerned about the breaking up of the entire linux desktop into a large number of niche developments with none of them sufficiently strong and well-managed to provide the relative stability and quality of the Linux desktop of 5-7 years ago.

Thanks, Cinnamon!

Posted Jun 17, 2015 14:27 UTC (Wed) by tjc (guest, #137) [Link]

I use it too (for a couple of years now), but not because I like it all that much -- I just happen to like it better than the current alternatives. It's been very stable for me, but I'm running it on the distro on which it was developed, so that's not unexpected.

I have a couple minor complaints -- it's a bit heavy for one -- but overall its pretty good. I should try MATE again, and Xfce 4.12. I'm looking forward to LXQt and Lumina. Especially Lumina.


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