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.
Posted Jun 13, 2015 16:36 UTC (Sat)
by oldtomas (guest, #72579)
[Link] (34 responses)
MATE, and she's now a happy Debian camper again. All is well.
Posted Jun 15, 2015 3:36 UTC (Mon)
by voltagex (guest, #86296)
[Link] (33 responses)
Posted Jun 15, 2015 5:53 UTC (Mon)
by ncm (guest, #165)
[Link] (32 responses)
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.
Posted Jun 15, 2015 8:50 UTC (Mon)
by wander_homer (guest, #103150)
[Link] (2 responses)
Posted Jun 17, 2015 3:52 UTC (Wed)
by zenaan (guest, #3778)
[Link] (1 responses)
Posted Jun 17, 2015 10:26 UTC (Wed)
by wander_homer (guest, #103150)
[Link]
Posted Jun 15, 2015 16:44 UTC (Mon)
by darkshram (guest, #58643)
[Link] (23 responses)
Posted Jun 15, 2015 19:37 UTC (Mon)
by tetromino (guest, #33846)
[Link]
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!
Posted Jun 15, 2015 19:45 UTC (Mon)
by dowdle (subscriber, #659)
[Link] (11 responses)
Posted Jun 15, 2015 21:42 UTC (Mon)
by ajmacleod (guest, #1729)
[Link] (8 responses)
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.
Posted Jun 16, 2015 12:43 UTC (Tue)
by Mannigfaltigkeit (guest, #103163)
[Link]
Posted Jun 16, 2015 17:30 UTC (Tue)
by ovitters (guest, #27950)
[Link]
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.
Posted Jun 16, 2015 1:56 UTC (Tue)
by ncm (guest, #165)
[Link] (9 responses)
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.
Posted Jun 16, 2015 11:43 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
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,
Posted Jun 16, 2015 17:34 UTC (Tue)
by drag (guest, #31333)
[Link] (7 responses)
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.
Posted Jun 16, 2015 20:53 UTC (Tue)
by paulj (subscriber, #341)
[Link] (6 responses)
Posted Jun 17, 2015 0:46 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Jun 17, 2015 7:27 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Posted Jun 17, 2015 1:49 UTC (Wed)
by rwhogg (guest, #103069)
[Link] (3 responses)
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.
Posted Jun 17, 2015 12:06 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
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.
Posted Jun 17, 2015 13:29 UTC (Wed)
by rwhogg (guest, #103069)
[Link]
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)
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.
Posted Jun 24, 2015 12:50 UTC (Wed)
by epa (subscriber, #39769)
[Link]
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.
Posted Jun 15, 2015 23:42 UTC (Mon)
by dashesy (guest, #74652)
[Link] (4 responses)
Posted Jun 16, 2015 15:10 UTC (Tue)
by madscientist (subscriber, #16861)
[Link] (2 responses)
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.
Posted Jun 16, 2015 15:27 UTC (Tue)
by dashesy (guest, #74652)
[Link] (1 responses)
Posted Jun 17, 2015 10:17 UTC (Wed)
by marcel.oliver (subscriber, #5441)
[Link]
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.
Posted Jun 17, 2015 14:27 UTC (Wed)
by tjc (guest, #137)
[Link]
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.
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
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!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Wol
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
Thanks, MATE!
* 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.
Thanks, MATE!
Thanks, Cinnamon!
Thanks, Cinnamon!
Thanks, Cinnamon!
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.
Thanks, Cinnamon!
Thanks, Cinnamon!