Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 04/25/2011 04:03 PM, Tom Metro wrote: > David Kramer wrote: >> I also took great offense at some of his statements. For instance, I >> talked about the problem of needing several apps that do similar jobs >> because they each have their strengths. His answer was "We'll >> just have to work to get one application that can do all of that". That >> is a ridiculous statement, since all of them are put out by different >> people... > > I took that as a statement of an ideal. I'm sure you too would rather > have one tool that did the complete job rather than combining 3. > > He didn't clarify the point, but I didn't interpret what he was saying > as "you can't do that." It was more like, "we want to avoid this kind of > a situation for typical users." > > If what you are trying to do is a common need, and it logically makes > sense to meet all those needs with one tool, then that's what the > community should be striving for. Yes, but how does making it harder to tell one app from another solve that problem? It doesn't. It just makes it harder to deal with. Having a configuration setting in an advanced tab somewhere to turn on showing the names/icons/both in app links does NOT make anything harder for the beginners, and enables the power user. This is just one thing that should be configurable of many, so please take this statement as addressing the larger "design pattern" of making things simpler by removing functionality instead of reorganizing functionality. The same goes for only running one instance of any app, only one dock bar, automaximizing windows that happen to touch the edge of the screen, ... > This doesn't always make sense. Sometimes features are better > implemented as a chain of separate tools (classic Unix philosophy), or > your use case may be odd-ball enough not to warrant integrating, or some > features may not fit the philosophy of a program. > > Does any one of the programs stand out as coming the closest to meeting > your needs? Have you filed feature requests? Yes, Rhythmbox. Like I said in my last post, it crashes when working with my iPod and I filed a bug report and cooperated with them every step and they say they're not fixing it. The short summary of the problem is it can't handle a collection with metadata over a certain physical size because they got cheap on field sizes. I have a 120GB Classic with about 6800 songs on it, and it worked fine. Then I started adding album art, and before you know it I was over the limit. They understand and acknowledge it, but won't fix it. >> ...how am I going to be able to tell these programs apart if I can't >> see their names? > > There seemed to be some misunderstanding over the UI elements. > > If you're familiar with GNOME 2, then the bar on the left side is a > combination of the Window List and Application Launcher applets (or in > (pre-7) Window terms, task bar and quick launch icons). I don't know > what GNOME 3 calls this, but dock bar seems to be the common term for > this combined functionality. (I use one called DockbarX on GNOME 2.) > Dock bars let you see what applications are currently running, and allow > you to "pin" a small subset of applications that you use most frequently > so they can be launched from the bar. OK, that makes more sense, especially in the context of them considering the Windows 7 interface to be Holy Doctrine Of All That Is Good. It doesn't actually make the problem less severe, but at least I understand their choice better (while still disagreeing with it) > While the application list that appeared in the main part of the screen > is the equivalent to the Applications menu. ...which you ALSO can't adjust the look and feel of. > Your complaint was that you couldn't distinguish multiple applications > with similar looking icons when they appeared on the dock bar. Is this a > situation you see happening when you go to launch the application, or do > you anticipate having all 3 running simultaneously? How does either option make the problem more or less severe. If I launch one of three (or five) programs that have very similar icons, whether the applications do the same thing or not, I still kinda need to know which is which ;) Look at the current icon for "CD/DVD Creator" (if you search REAL HARD you can find out that that's Brasero, but you wouldn't know it without a lot of work). The icon is a folder, like File Manager, but it has a mouse pointer on it. HOW THE F*CK is that the icon of a DVD burning program? The icon for ARK, archiving software, is a 3D cube. You see my point? Just like the huge argument years ago on this list with He Who Must Not Be Named about his proposed encryption algorithm that could fit gigabytes of data in a few KB, it's provably not possible to represent the hundreds of programs available in the repository with icons that are meaningful to the purpose of the program and instantly distinguishable from all other such icons. This will actually be more harmful to the beginners they are attempting to coddle than us old hands. (punchline: After several days of arguing he finally admitted his algorithm was not lossless. Minor detail). > If you use the Applications menu, then there doesn't seem to be much > difference between 2 and 3. The application listing they showed in the > demo showed both icons and program names. The biggest down side I heard > was that they didn't yet provide a tool for manually reorganizing the list. Given that an Ubuntu install, unlike most, does not involve package selection, that could be a rather large problem. >> The other thing that really has me worried is when he was talking about >> the plugin architecture, and how that might be used to get around some >> of the problems we were all complaining about. > > The ability to reprogram the UI in a main stream language (JavaScript), > without having to recompile the whole desktop, sounds rather promising. Again, I agree this is technically very impressive and could be a good solution, but I have learned the hard way not to rely too heavy on features the author admits to hating themselves ;) > Anyone know if this is how Ubuntu's Unity UI is implemented on top of > GNOME 3, or did they get more invasive? > > >> "We know how the the interface should look and work, so we don't >> really like this feature, because people are going to muck up the >> look and feel. This just so totally smacks of Microsoft's stance >> ("We know what you need"). Very arrogant, and very much not the open >> source way and attitude. > > I think desktop UI designers face some of the toughest challenges of any > UI designers, because users inevitably resist change and want a new > desktop that works the way the old one did. That makes it pretty hard to > innovate. I hear what you are saying. I embrace change. I live Agile and deliver code every two weeks and at the end of those two weeks the priorities and designs have changed. I'm 47 and still keep up with the latest technologies. I am not asking for no change. I am asking for no removal of functionality. Make it default to however they think it should look, but let the power user change it if they want. If they don't have the time to write configuration programs, then read the config from a file we can tweak if we dare. > Ideally you want a "soft" introduction to the new features where you can > try them out after an upgrade, and if you find you just can't live with > them, you can revert the problematic ones, while keeping others. Yes. That. > I'm pretty sure if the capability is there in the plugin architecture, > we'll see plugins to revert most behaviors to be GNOME 2-like. That used to be the way in Linux. If there was a need, it would be filled, If a product was cool, it would get loved. but there are so many products out there now, the talent (and energy!) is spread thinner. I am no longer confident in Adam Smith's Invisible Hand guiding the energy and resources to the most needed and deserving projects. Then again I'm not known for my optimism. > I wouldn't fault the GNOME 3 developers for not putting in hundreds of > configuration options to support GNOME 2 behaviors. But I do think it > would be wise to have GNOME 2 compatibility plugins available in time > for the first non-beta Linux distribution that ships with GNOME 3. I agree that putting in that many configuration options would be a burden and testing nightmare. But a few dozen to start out with would cover a lot of territory, and be indicative of a philosophy of supporting all levels of users. I think about this as being similar to adding localization to a program. If, as you are writing the program you retrieve user-facing messages by resource key in a config file, the burden is actually pretty light. If you go back and try to add localization to an existing app by looking for said messages and extracting them, well that onerous task has lead to the insanity of many a worthy developer. The key is to start working with configurability in mind from the start, even if it's not complete, and it never becomes this behemoth burden. >> He danced around some other long-standing issues that were not >> addressed, like when you automatically autostart/restore applications >> after a reboot, they should restart into the virtual desktop they were >> on at shutdown. > > Agreed. Session persistence has been a long standing problem in GNOME. The new design seals its fate as never being solved though, because you no longer even have a fixed number of virtual desktops. They're created as needed. Both at work (yes, I use virtual desktops under Windows too) and at home, I use four virtual desktops each for a different purpose (mail/web, devel, admin, etc) and have different apps always on the same desktop. In the New World Order, it could take quite a lot of work to recreate that after startup.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |