Weekly Edition
Return to the Development page
| |||||||||||||
A look at GNOME ShellIt's been more than a year since LWN looked at GNOME Shell in what was still a primitive state. With only a few months left until the scheduled release of GNOME 3.0 at the end of September, and after more than a year's development, it seemed like a good time to take another look. GNOME Shell is a compositing manager that works on top of Mutter — a branch of the Metacity window manager. With GNOME 3.0 Metacity will be in maintenance mode only, and Mutter will be GNOME's window manager going forward. Mutter uses the Clutter toolkit for rendering. In practical terms, GNOME Shell provides the actual desktop environment for GNOME 3.0. It displays and manages windows, provides a panel for displaying system notifiers, launches applications, and shows recently used files. Getting GNOME Shell is relatively easy, if you're running a very current Linux distribution and have the right graphics card and setup. Ubuntu 10.04, Fedora 13, Debian testing and unstable, and openSUSE 11.2 all include gnome-shell packages for testing. I tried running GNOME Shell with the packages supplied for Ubuntu 10.04, but Mutter failed to start. Fedora 13 provided slightly better results. After installing the gnome-shell package, Fedora adds a new option to the Desktop Effects dialog for GNOME Shell. Checking that should automatically start GNOME Shell if the graphics system supports it. Mutter requires 3D acceleration, but Nouveau and GNOME Shell do not play well together. This was a bit of a surprise, as Nouveau does just fine with Compiz on Fedora 13. Finally, I tried GNOME Shell on a machine with Intel graphics on Fedora 13. GNOME Shell worked well on this machine and had good performance. It showed itself to be stable and feature-complete enough for everyday use, though not all features have been implemented yet. For example, the GNOME Shell design document [PDF] calls for a message tray that will display events and messages, but this is not present in the implementation shipped with Fedora 13. Matt Novenstern provided an update recently on his progress but it's still under heavy development. What happens if you don't have supported 3D hardware? No GNOME Shell for you, though the GNOME Project will still make it possible to run the GNOME 2 shell with GNOME 3 applications and libraries. ![[workspaces]](/images/2010/gnome_shell_workspaces_sm.png)
Shell replaces the GNOME Panel, taking over the job of managing the desktop from Nautilus and providing some new ways to manage windows. The concept of switching between windows using a menu or toolbar buttons (as is the norm in GNOME 2.x) is gone. Instead, users can use Alt-Tab to switch between windows or move the mouse cursor to the top of the window and select between windows and/or workspaces. Users can also see all open windows and the GNOME menus by clicking the Activities button or pressing the System (Windows) key. New workspaces can be added (or removed) by clicking a button in the lower left-hand corner of the screen. Alt-Tab works slightly differently with GNOME Shell than with Metacity. Instead of switching between all active windows, it displays all active applications, with a drop-down menu for windows owned by each application. For instance, if Firefox has three open windows, it will display one thumbnail for Firefox and a triangle at the bottom that indicates there's more than one window to choose from. The GNOME Shell panel is not planned to support GNOME applets, so users that have applets they depend on (like GNOME Time Tracker) are going to be out of luck. Owen Taylor laid out the rationale in April 2009 for omitting applets. The panel also doesn't make the best use of space in the current implementation. The panel is a flat black bar that displays system tray notifiers, date and time, a logout menu, a button that displays the active application (and does little else), and the Activities menu. ![[application menu]](/images/2010/gnome_shell_application_menu_sm.png)
Aside from missing applets, though, GNOME Shell worked fine with all of my day-to-day applications. In its current state, GNOME Shell is slightly less functional than Metacity and the GNOME Panel. The Applications menu could use some work, as it just displays all the applications GNOME knows about in a flat grid. This is a work in progress, though. The usability trade-off may be worth it in the long run when some of these problems are addressed. Even on a relatively small screen (1280x800 resolution) GNOME Shell makes it easier to manage a lot of open windows. GNOME Shell and AccessibilityOne of the concerns with any major revamp like GNOME Shell is the impact it will have on GNOME accessibility (a11y). The GNOME accessibility team has been working hard on GNOME 3.0. Alejandro Piñeiro Iglesias, maintainer of the Cally accessibility implementation library for clutter, says that there's room for improvement but Cally is in good shape at the moment. Piñeiro says that, ultimately, he wants to see Cally become part of Clutter rather than a standalone library. This isn't the case at the moment, and is unlikely to happen by GNOME 3.0. Piñeiro says that when using Cally patches to Clutter he's been able to use Orca screen reader with GNOME Shell, though "the functionality is limited." Presumably this will be improved by the final release. Taylor said in March that he'd like to see accessibility "held to the same high standards as everything else in GNOME" with accessibility features on by default and a user experience that "just works." But it won't happen by GNOME 3.0: Getting accessibility fully to that standard isn't going to happen for GNOME 3.0... we've never been there for GNOME 2, we aren't going to be there in 4-5 months even if it was the only thing we worked on. But where I definitely want to be for GNOME 3.0 - in the next 4-5 months is to make sure we've laid the groundwork properly so that we can get there in follow-on releases, both on a technical level and on a user-experience level. Piñeiro says he'll continue working towards full integration of Cally with GNOME Shell, and points out that there are a number of other features to implement such as keyboard navigation and theming. GNOME Shell provides the ability to create new themes, though it only ships with one at the moment, and work will need to be done to ensure that GNOME Shell has a selection of accessibility-friendly themes. It's clear that GNOME Shell will need to continue to mature after the GNOME 3.0 release. What's less clear is exactly how it will proceed. As discussed on the gnome-shell-list, various design documents and roadmaps are spread out a bit. The most authoritative are the design document and the roadmap on the GNOME wiki. One area that is wide-open is the "social dimension / collaboration" mentioned in the design document. This is left open for version 2.0 of the Shell, but the basic components are in view now. The (not yet implemented) message menu is meant to work hand in hand with the Telepathy communications framework and the applications it supports, like the Empathy instant messaging client and Gwibber social client. Eventually the message menu should be used to show instant messages, system notification, etc. — though the user should be able to block this by setting their status as busy. The GNOME Shell plan also calls for the ability to create extensions using JavaScript and CSS. The extensions are intended to add functionality to GNOME Shell, but not to replace applets. Extensions are meant to be a way to make changes to the way GNOME Shell handles things like window management or application launching without having to actually hack the Shell itself. GNOME Shell already has a functioning debugger called Looking Glass for prospective extension authors, but there are no extensions in the wild yet. GNOME 3.0 is more than GNOME Shell![[sidebar]](/images/2010/gnome_shell_sidebar_sm.png)
Because GNOME Shell is the most visible major change to GNOME, it has drawn the most attention. However, GNOME 3.0 is more than just GNOME Shell. In addition to the work that's gone into GNOME accessibility, GNOME 3.0 should inherit multitouch support from GTK+ 3.0, along with major improvements in the help system via Yelp. Users thinking about trying out the GNOME Shell should check out the GNOME Shell Cheat Sheet, which includes a list of built-in features and instructions on using them. Even in its unfinished state, the GNOME Shell should be stable enough for most LWN readers to use. Interested contributors should join the gnome-shell-list mailing list and see the GNOME 2.31.x development series page, contributor guide, and the GNOME Shell Todo for further information. Though GNOME 3.0 is due to be released by the end of September, GNOME Shell may not land on many GNOME users' desktops until 2011. Mark Shuttleworth has already indicated that GNOME Shell won't ship as the default with Maverick Meerkat (Ubuntu 10.10). GNOME 3.0 will miss the 11.3 release of openSUSE, and Debian Squeeze is currently planned to ship with GNOME 2.30. The first major distribution to ship GNOME 3.0 with GNOME Shell will likely be Fedora, as Fedora 14 is due to hit about a month after the GNOME 3.0 release. (Log in to post comments)
A look at GNOME Shell Posted Jun 10, 2010 3:54 UTC (Thu) by k8to (subscriber, #15413) [Link]
Gnome 3 won't work on four year old computers? Gnome 3 likely work well if you have nvidia hardware?
I sure hope Gnome 2 is going to get real maintenance!
A look at GNOME Shell Posted Jun 10, 2010 4:59 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
In Fedora 14, GNOME Shell with have the classic GNOME Panel as fallback and that has been getting revamped recently.
http://carlosgc.linups.org/gnome/libpanel-applet3
More discussions at
http://lists.fedoraproject.org/pipermail/desktop/2010-May...
A look at GNOME Shell Posted Jun 10, 2010 9:43 UTC (Thu) by kragil (guest, #34373) [Link]
Making Gnome-shell the default is pure insanity (based on my experience with the F13 version)
I 100% agree with all of drags complains(especially the "Open Offi..."-crap), but I would add:
1. All the movement when you hit the windows key is highly annoying and to this extent unnecessary. It needs to be tuned and toned down a lot.
2. Scaling of windows is totally borked. My big Firefox windows should be the biggest in the overview, but atm my small terminal windows are. Stupid. It should scale more proportionally.
3. Add application icons so you tell apart your standard blank white windows.
4. Add speed. Gnome-shell feels really slow compared to Compiz or Kwin.
5. What's up with the two overview modes? Again the default one sucks. Stick to the original idea.
If I could stand using it more I would probably have a much longer list.
A look at GNOME Shell Posted Jun 10, 2010 17:11 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
"Making Gnome-shell the default is pure insanity (based on my experience with the F13 version)"
That's rather outdated. You should try the latest git HEAD if you want to form opinions based on the current state.
A look at GNOME Shell Posted Jun 11, 2010 2:29 UTC (Fri) by k8to (subscriber, #15413) [Link]
Wow, reading this post, it soudns even worse.
Dconf using a binary format... (registry sickness deepens)
A look at GNOME Shell Posted Jun 11, 2010 2:43 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
It is actually a key based configuration. The binary format is merely a method to avoid slow reads.
A look at GNOME Shell Posted Jun 11, 2010 2:55 UTC (Fri) by k8to (subscriber, #15413) [Link]
I read that link. It caused my comment.
Let me introduce you to another key-based configuration with binary format:
They, too, introduced it for performance rationales. Funny that the performance issues are drastically less than that point in time, 17 years ago.
A look at GNOME Shell Posted Jun 11, 2010 3:01 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
It is well known that binary formats have the advantage of better performance regardless of whether Microsoft is using it or not. D-Bus has benefited from one and that is used throughout the freedesktop stack. ksycoca in KDE does something very similar as well. Get over it.
A look at GNOME Shell Posted Jun 11, 2010 3:18 UTC (Fri) by k8to (subscriber, #15413) [Link]
And it is well known that binary formats have disadvantages for automation, recovery, and investigation. Conf keys are not a heavyweight activity, so playing up performance at the expense of these other conscerns for this domain is just foolish.
The article I linked was notable not because it is a Microsoft document, but it is a Microsoft document communicating how to try to recover from a corruption issue common enough to require a knowledge base entry. This should make the problems with binary format config hives understandable to everyone.
A look at GNOME Shell Posted Jun 11, 2010 3:56 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Performance has certainly been a concern with Gconf. We will see how it goes. The developers certainly think it is a valid trade off and you are free to opinionate that it is foolish but since they are doing the work, that is what ultimately counts.
A look at GNOME Shell Posted Jun 11, 2010 7:45 UTC (Fri) by k8to (subscriber, #15413) [Link]
No, ultimately what counts is whether it works, and works well.
Certainly, I'm not going to make it work well. But those who will not learn the lessons of history won't either.
A look at GNOME Shell Posted Jun 11, 2010 9:56 UTC (Fri) by dgm (subscriber, #49227) [Link]
You forgot to explain what "works well" means. For dconf's developers it seems to be "runs fast", while "works realiably" seems to be yours.
A look at GNOME Shell Posted Jun 11, 2010 12:16 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
We have no scarcity of opinions. We do certainly have a problem of getting people to do the work involved unfortunately. If it doesn't work well, it will fail on its own terms. I rather reserve judgement till that point.
A look at GNOME Shell Posted Jun 11, 2010 14:12 UTC (Fri) by jond (subscriber, #37669) [Link]
The thing is, sticking with our current non-binary system requires no work.
A look at GNOME Shell Posted Jun 11, 2010 15:36 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
No work involved for maintainers or users doesn't make a system ideal if the current characteristics are not right for the next major version of a desktop environment. GNOME has been thinking about a replacement for Gconf for quite sometime. With the opportunity now, they have. One could argue, the previous system was perfect but that isn't reality.
A look at GNOME Shell Posted Jun 11, 2010 9:49 UTC (Fri) by farnz (guest, #17727) [Link] That link raises concerns for me that ksyscoca does not. In particular, if I get a random bitflip in my ksyscoca database that renders it unusable, I can recover easily - I just erase the ksyscoca database, and let it rebuild from the configuration files. Similarly, if I end up with a corrupt configuration that I cannot fix through the GUI, I can recover by hand-editing the configuration files, or deleting the bad configuration file, logging out and back in, and reconfiguring that component through the GUI. With the exception of recovering a corrupt ksyscoca database (which can be detected programmatically and handled without user intervention), these are operations at the level of smart geek, not ordinary user; however, as someone who fixes "computer problems" for ordinary users, being able to say "I've kept most of your personal settings, but you'll need to reset the wallpaper/check your bookmarks/whatever bit was damaged" is a much nicer position than I'm in with Windows systems, where all I can say is "you've lost all your settings."
A look at GNOME Shell Posted Jun 11, 2010 12:23 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Here are more details
http://lists.fedoraproject.org/pipermail/devel/2010-May/1...
You should be able to rebuild your schemas if necessary.
A look at GNOME Shell Posted Jun 11, 2010 13:13 UTC (Fri) by farnz (guest, #17727) [Link] That doesn't reassure me any, I'm afraid. ksyscoca takes a bunch of text files under ${HOME}/.kde, and parses them into an efficient binary blob form that lives in /var/tmp. The KDE API for handling configurations keeps the binary blob and the text files in sync; if I edit the text files outside of the KDE API, I've invalidated the ksyscoca binary blob, and need to recreate it. KDE will do this automatically when I log in (based on mtimes, I assume), or I can blow away the binary blob, and still keep my settings unchanged. The link you've given suggests that if I rebuilt my schemas, I'd lose my custom settings. That's a distinct retrograde step from ksyscoca, where if I wipe out my binary blob, I can rebuild with my existing settings from the text files; further, I can edit my settings with tools such as "vi" (useful in a broken-the-world scenario), blow away the binary blob, and have KDE rebuild the binary blob for me.
A look at GNOME Shell Posted Jun 10, 2010 8:37 UTC (Thu) by drag (subscriber, #31333) [Link]
Things I don't like:
1) The Alt-tab behavior sucks. I am a heavy user of alt-tab since most of my windows stay maximized most of the time.
* You should be able to alt-tab your way through avialable windows. Having to use the arrow keys to choose the window is irritating and slow. Pick something else that goes faster. You've turned something that is quick and one-handed into something that is slow and requires both hands.
* Quickly hitting alt-tab should switch you to the last used window. That way if I am reading something in one window while typing in another I can alt-tab back and forth quickly. The way it is now screws up the flow and I have to search through applications and use the arrow keys to just find the window I just used. Instead of something that took a split second to do now will take upwards to 20-30 seconds depending how much is open and ruins the concentration.
2) The application menu sucks.
* The names used in open source software are not descriptive. The menu needs to include the description of the application's purpose. Right now I get a huge icon and a few letters.
"Ekiga Soft..." and a huge orange icon is _NOT_ useful information.
* All the applications are stuck in one massive grid layout. This makes it almost impossible to choose applications rendering the application chooser menu worthless. I understand Search is nice, but it's only useful if I already know what I am looking for.
For example:
However if I want to change the default fonts settings then when I search for 'font' I get 'xfontsel', which is just about the most worthless and misleading application a user could possibly run across.
If I want to change fonts I have to already know that the fonts are via clicking on the apperiances section, and the only way I can get to appearences icon is by openning up gnome-control-center. Unless I am already a very experience Gnome 3.x user I would have zero idea that gnome-control-center even exists. There is no practical way I would be able to find it or know what it is when I found it.
I have to scroll down 1/4 the way in the applications menu and find the icon of a blurry screwdriver with the description of 'Gnome Co..."
To hae a useful application menu the items need to be catagorized, I need to be able to find what I need without scrolling up and down, and I need to have the full name of the application with the icon small.
3) If your going to eliminate applets your going to have to replace their functionality.
For example there is no longer any easy way for me to set the cpu speed on my system or tell the system that I want the cpu to be set to 'performance' when I am on AC power.
There is no longer a easy way to see the weather. There is no longer a quick way to change resolutions or select video outputs, nor is there any easy way to do desktop search.
-----------------
Besides that stuff, though, I like it.
A look at GNOME Shell Posted Jun 10, 2010 10:42 UTC (Thu) by salimma (subscriber, #34460) [Link]
Speaking as someone who has used OS X quite heavily in the past, I *love* the new Alt-Tab cycling behavior. You can still get to the window you want with one hand -- Alt-Tab to the right app, and then cycle between windows of the same app (I rebound mine to Alt-`, but on my netbook which does not have a separate ` key it's Sys-Tab, like in OS X)
You get most of the benefits of a tabbed applications, even in apps that do not support tabs. And it makes Alt-Tab usable when having lots of GIMP windows open (before that I used to curse MDI apps incessantly)
A look at GNOME Shell Posted Jun 11, 2010 4:27 UTC (Fri) by mfedyk (guest, #55303) [Link]
I have to agree with everything and add a few things.
--- Does it finally fix the problem with pressing alt+tab while dragging something between maximized windows? I used to do this all the time in windows and can't see why it doesn't work in gnome.
--- Here are some applets I always use:
- System Monitor - top, middle (CPU, Mem, Net, Swap, Load Avg and Disk Activity all at a glance. Because the system is not expressive enough to show what is really happening most of the time.)
- Window Selector - top, right (shows all apps on all virtual desktops. Great for when going to someone else's desktop or finding a lost window for someone or yourself)
- CPU Freq Mon - top, middle (because I want to know when and how often my cpu has to speed up to do what processes want to do -- usually correlated with system monitor...)
- Force Quit - top, middle, left (a better name for it might be "button for memory sanity in firefox". It's simpler than any session manager firefox extensions and has been easy to teach to several users who share my habbit of using lots of tabs. but now I use chrome and only use it very seldom now but it does come in handy sometimes. Mozilla if only you liberated libgecko (freeze the API now, make a release and then do normal release version number bumps when you make API changes, though libgecko might be up to version 15.3.5 by now...), made a browser that uses multiple processes. I might switch back to firefox once FF 4 comes out with multiple processes split per tab or security domain)
- Lock Screen - top, middle, left (sometimes you want to step away without having to wait N minutes for the screensaver and autolock to kick in. --could be replaced with bluetooth proximity detection possibly)
- Weather - top, middle, right (because I like knowing the outside temp at a glance with just information and without the commercialized fluff to get in the way)
- 8 Desktops - bottom, right (because like to use different desktops for different categories of tasks I am performing (browsing/chatting, image editing, screen full of gterms for one set of systems, etc.)
I don't think gnome 2 is pretty by any definition, but it is functional and whenever I have to use a windows system I find so many warts (middle click on a scroll bar, scroll wheel focus doesn't follow pointer, and on and on or even try turning on compiz. Gnome is functional, it's a workhorse.
Finally they're getting more sane by not making spatial nautilus the default anymore (you can compile it out IMO).
Gnome 3 needs to be a parallel install to Gnome 2. Let it experiment and mature and actually deliver on its vision instead of moving over to it before the benefits are available and usable. Learn from the mistakes of KDE, not repeat them. IMO between the time of gnome 2.30 .. 2.34 .. 2.40 should be the time to let Gnome 3 mature and become feature complete.
IOW, Gnome2 should live until Gnome3 proves itself, not when it's not cool anymore.
A look at GNOME Shell Posted Jun 10, 2010 10:21 UTC (Thu) by liljencrantz (guest, #28458) [Link]
Not to be too negative, but the Gnome 3 release really seems to be shaping up to be the KDE4 of Gnome releases. Much potential, interesting new ideas, much needed code clean ups and cruft removal, but the first few Gnome 3 releases are going to be more or less useless. I hope the Gnome Panel and other fall backs will keep working at least at their current level for the next 2 years.
A look at GNOME Shell Posted Jun 10, 2010 12:28 UTC (Thu) by MisterIO (guest, #36192) [Link]
If performances are going to drop with this thing, I'm gonna switch to xfce as soon as I can, because I don't give a s... about fancy effects or semantic-something, etc. I just want a light system that can stay out of my way as much as it can, doesn't uselessly eats reasources and just works without the need for long sessions of settings tuning.
And, by the way, I hope the colors of gnome-shell(that panel at the top in particular) can be changed, because that's too dark. I prefer the current gray of the panel(not esthetically, but it seems more relaxing for the eyes).
A look at GNOME Shell Posted Jun 10, 2010 13:52 UTC (Thu) by sorpigal (subscriber, #36106) [Link]
I love cool new UIs as much as anyone (probably more) but I don't like this GNOME Shell business very much. The GNOME project should not be in the business of changing the way I use my computer, not even if it's "better" that way. They've tried it before (hello spatial nautilus) and I didn't like it then, either. GNOME should be in the business of letting me use the computer my way; that is, it should adapt to me and not the other way around.
Can the top-of-the-screen bar be moved to a different screen edge? Can it be resized? Can the layout of the overview be altered? Can I change the shortcut keybindings? Can I revert to 'classic' alt+tab behavior? Is there way to show a pager at all times? These are just a few non-starters that effect my own workflow.
Why can't we just add GNOME panel apps to the 'new' top-of-the-screen panel? The argument against them seems to be "well they aren't that useful are they." In that case just leave them out by default but give me the option of adding them and if they're really not useful no one will add them. Some of us *like* dockapps and won't ever be persuaded by arguments like "It's really not the best user interface for that kind of task." Rethink the underlying paradigms all you like but don't remove the ones I use just because you've found your UI religion.
A look at GNOME Shell Posted Jun 10, 2010 14:13 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
I've complained about this before in other places, but what effects does GNOME Shell actually use that require an accelerated 3D graphics card? I don't have hardware I can use it on without installing a proprietary driver (which I haven't yet bothered doing), but it looks to me from the videos I saw as if most of the time things are running with all windows at their normal size at their normal angle relative to the viewer, and from time to time they are zoomed in and out. I really don't see why that needs accelerated hardware. I do understand that they are using a generic engine (Clutter) for this which can do lots of other fancy things that won't work as well without acceleration, but surely this sort of edge case could be detected somewhere in the stack and fall back and work nicely even without acceleration.
A look at GNOME Shell Posted Jun 10, 2010 15:06 UTC (Thu) by MisterIO (guest, #36192) [Link]
I heard(more like "read", actually) people talking about using Gallivm3D's llvmpipe as a fallback option in case your gpu can't do adequate acceleration(for whatever reason), but, at the moment, it doesn't work and you'd still need a rather powerful cpu, I guess. As for what exactly needs acceleration, I don't really know. I hope just a few effects that can be disabled. I mean, come on, even Windows lets you disable its stupid visual effects, but gnome doesn't? That'd be ridiculous!
A look at GNOME Shell Posted Jun 10, 2010 18:26 UTC (Thu) by drag (subscriber, #31333) [Link]
> I do understand that they are using a generic engine (Clutter) for this which can do lots of other fancy things that won't work as well without acceleration, but surely this sort of edge case could be detected somewhere in the stack and fall back and work nicely even without acceleration.
I don't think it's worth it for a forward looking project to care about stuff like that.
The GPU is part of modern PC architectures. Just as much as your processor, memory controller, Sata controller, and so on and so forth. For Gnome shell to take advantage of it to accomplish it's goals just means that they are writing efficient software.
For fall-backs you will need to use software rendering pretty much no matter what. It's still somewhat common to have real 2D acceleration and that was used for composition in the pre-mutter version of Metacity, but that is rapidly going the the way of the dodo. GPU is the only 'acceleration' that is available going forward and it's easier/better to use a standard API to take advantage of it.
Software rendering of OpenGL should technically be OK, but the Mesa software rasterizer is really shitty and gives extremely poor performance. the LLVMpipe-based software rendering should be sufficient (even getting games like Unreal Tournament 2004 playable on very fast processors), but the API not complete enough yet to support clutter.
A look at GNOME Shell Posted Jun 11, 2010 2:36 UTC (Fri) by k8to (subscriber, #15413) [Link]
It's worth limiting compatability if there's either no need or huge wins.
For an infrastructure product, there is need. And I don't see any huge wins.
A look at GNOME Shell Posted Jun 11, 2010 14:22 UTC (Fri) by jond (subscriber, #37669) [Link]
This is a good rationale if the objective is to only target modern systems and that modern systems are correctly described as having a supported GPU. Unfortunately, I frequently make use of virtual machines these days, or systems where the GPU is not supported well (many modern GPUs, nvidia stuff, older ATIs, intel poulsbo, etc.), so these axioms do not apply to me. Which means that the future of GNOME is not my future, and that's unfortunate.
I can't really see many end-user wins, either.
A look at GNOME Shell Posted Jun 14, 2010 21:50 UTC (Mon) by aigarius (subscriber, #7329) [Link]
Could, maybe, working over a VNC connection or on a remote X terminal be a good reason?
VNC connections are very, very common for remote administrative assitance and remote X terminals are what largest school deployments use to allow dozens of students to connect to one powerful X terminal server.
If GNOME Shell becomes unusable over a remote X of VNC connection, then it will be of a very limited use and likely fail as a generic replacement for Gnome panel.
Seems like CADT all over again Posted Jun 11, 2010 4:30 UTC (Fri) by mhm (subscriber, #45669) [Link] http://www.jwz.org/doc/cadt.html
Seems like CADT all over again Posted Jun 11, 2010 12:59 UTC (Fri) by MisterIO (guest, #36192) [Link]
Interesting read.
Seems like CADT all over again Posted Jun 11, 2010 15:36 UTC (Fri) by k8to (subscriber, #15413) [Link]
It's really freedesktop in a nutshell.
Seems like CADT all over again Posted Aug 12, 2010 9:57 UTC (Thu) by bockman (guest, #3650) [Link]
And so what?
Of course people that contribute for fun will prefer re-writing to fixing bugs (*). Then it is expected that people making a profit of it - from simply using it to packaging and distributing it - will do the most boring parts.
It is a system far from perfect, but the important thing is that in many (most?) cases IT WORKS. The proof is that many people make use of open source software with no more troubles than using close source software owned by some company.
(*) Although as a developer (not of OSS) I think that hunting and fixing bugs _is_ fun. The non-fun part is dealing with people that believes a particular behavior is a bug only because they don't like it.
Seems like CADT all over again Posted Aug 12, 2010 15:30 UTC (Thu) by paulj (subscriber, #341) [Link]
It's not fun if you're a user. Every developer of packages is the user of a much, *much* greater number of packages.
I'm a relatively long time user of free software desktops, and I have to say the regular breakage due to rewrites isn't fun. Indeed, my anecdotal view of things, based on other people in my local LUG who've been around quite a while, is that this breakage of important existing functionality (sometimes for little to no functional gain) is driving users away from Free Software desktops (typically to OS-X).
It's kind of a tragedy of the interests of the individual hacker over that of the community. While the individual hacker obviously feels much happier working on new and exciting code, the community at large and over time suffers from the fact the system never converges on stability (0.8 followed by 0.8, just buggy in different ways, as per JWZ).
Seems like CADT all over again Posted Aug 12, 2010 20:55 UTC (Thu) by boudewijn (subscriber, #14185) [Link]
And at the very same time people are complaining that KDE 4.5 hasn't moved away from HAL yet...
|
|||||||||||||