Gnome 3 Ideas
转自：http://ryanthiessen.com/static/gnome-3-ideas.htmlMon, 11 Apr 2005
Gnome 3 Ideas
Gnome has been plugging away with its 2.X series from quite some time now, updating every 6 months on a predictable schedule making incremental improvements with each release. During this period they have kept their API stable and have refrained from making fundamental changes to the project. The developers have acknowledged that at some point in the somewhat near future, they will break from this series and begin work on a new series that removes some of the old cruft and changes some fundamental approaches in how people use Gnome. The following are a few of my suggestions for what would help Gnome 3 a revolutionary leap forward.
File Storage
One of the most interesting and well-discussed topics in Gnome is the idea of how to handle file storage. The idea is that users do not care where their data is stored, they just want to be able to find what they want in a simple and quick manner. They don't care about filesystem hierarchies and find file browser interfaces and spatial interfaces to be annoying. The idea is that the "folder" metaphor be replaced by heuristical categories that allow for easily searchable files.
One prominent example early on was the Storage Project, an ambitious plan to replace the traditional filesystem with a new document store. Unfortunately that project lost traction and little development work has gone on with it, at least publicly. A similar but different project, Beagle, accomplishes much of the same purpose but works on top of the existing filesystem amongst other data stores like your mail history, calendar, and instant messaging logs.
One problem with the idea of storage is that it is truly revolutionary. It doesn't build upon the past and requires substantial changes to how nearly every Gnome application operates in fundamental ways. It is perhaps related to this ambition that the project has gained little traction thus far, because for it to work every gnome application would have to be rewritten, it would be a massive effort by the entire community. This is not to say it is impossible, just that such revolutionary ideas need a lot of support behind them.
Instead of this complete revolution, I propose that a Beagle-like project be implemented as the only "open" dialog for Gnome 3, while the current filesystem be retained for the time being. When the user is in a spreadsheet application and selects "open", they are given a list of recent and/or frequently used spreadsheets that are available to the system, with a search dialog that allows them to perform queries as they are used to doing on Google (for example). The only filesystem characteristic that would ever be presented to the user is the physical volume -- is it on the hard drive, floppy, USB storage, camera, network share, CDRW, etc? This method would not have any metadata available to it except from what was inside the file, for example "author" and "keyword" fields for OpenOffice files.
When saving, the only choice the user would have to make would be which physical device to save to. However, regardless of if the device's filesystem whether local or remote, Gnome applications would use a basic heuristical method for organization. Some basic categories would be used by all applications, such as "Pictures", "Videos", "Documents", "Spreadsheets", "Music", "Presentations", and so forth. So, when you backup music in Sound Juicer, it would automatically save the files to "Music" on whatever physical volume the user wanted. The filesystem change would trigger the gnome-filestorage daemon and it would add that information to the database just as you see with gnome today. The metadata being stored would be that appropriate to the filename and nothing more, in the case on music the metadata would be the ID3 tag information and the bitrate metadata stored with the .ogg, but nothing more.
As you can see from my examples, this would be a fairly simple approach with no metadata that wasn't contained in the files themselves. What this allows for is that when a new volume is connected to the system, like a USB key or a CDRW, the data on those drives are treated like first class citizens to the open dialog. That is to say that they are not "missing" any important metadata because they weren't saved by the system or originated from another operating system or desktop environment. When the volume is connected, the device is scanned and the appropriate metadata is extracted from the files and inserted into the database of available files, and when a user hits "open" those files are available until the device is disconnected.
It seems to me that much of this work has already been done with the excellent tool of Beagle. One can easily imagine a specialized form of the beagle search tool with few modifications to replace the open dialog already. And for saving, it just needs to be simplified to limit the choices to physical volume being saved to that could replace the existing "places" chooser. The final step would be to create tools that duplication file management tasks performed in nautilus today like creating backups and copying information to USB keys, CDs and DVDs, and saving to the network (ie uploading).
Unlike the ambitious storage project, this proposal is something that can be layered onto Gnome and builds on the existing work that the Beagle team has already done. While I am not a Gnome developer, it seems to me that this project is easily doable in the timeframe of Gnome 3, and it accomplishes the purpose of a simple and searchable filesystem that can compete with the next generation Apple and Microsoft
offerings while still being backwards compatible for old applications.
Mono/gjc/Java
Right now the three primary corporate contributors to the Gnome project are in three distinct but similar camps. Novell is pushing Mono, Red Hat is pushing gjc (a free implementation of Java), and Sun is pushing Java. As such, neither has been able to agree on which of these languages deserves to be included as a mainline programming language in Gnome. As such, fragmentation has occurred and much of the new interesting features that target the Gnome platform by these three companies are ineligible for distribution as part of the Gnome project. In the interim, the Gnome project has accepted python as a mainline language, but none of these companies are actively writing new tools for Gnome in python, as far as I know.
This C#/Java fragmentation cannot continue unchecked. Novell is writing great apps in Mono, and Red Hat and Sun with their Java implementations. By not including any of these apps into mainline Gnome everyone loses: each of the companies trying to push for their particular language implementation, the Gnome project, and above all the Gnome users lose from the fragmentation. Ironically the only winners from this battle in the short-term will be third party distributors who have the ability to package programs written in both C# and java, not any of the companies trying to push for just one successor.
People on each "side" talk about patent worries. What if Microsoft decides to stop Mono by enforcing vague software patents? What if Sun decides to do the same to gcj? These fears are valid in this time of legal threats to open source software around the world, but we cannot be allowed to hold us back from moving forward. Our saving grace is perhaps the fact that Java and C# arne't that fundamentally different. While each language has important differences they have a lot of similarities and it is conceivable that code written for one platform could be ported to another.
If the worst-case scenario unfolds and Microsoft or Sun is successful in enforcing such a patent, surely the community could move the important software from one platform to the other. It would no doubt be a herculean task to do this, but compared to the difficulty of creating the language implementations of gjc or mono it is certainly not unthinkable. Just ponder for a second: if Novell was unable to ship mono or Red Hat unable to ship gjc, they would be forced to adapt their software to the other platform in order to satisfy their customers. There is no worst-case scenario in which the Gnome project is stuck with useless code that cannot be shipped because of Microsoft or Sun.
So instead of debating which of these languages is the biggest software patent threat, for Gnome 3 let's support both C# and Java implementations (so long as the java code executes on both gjc and sun's Java). This would allow all Gnome 3 users to embrace some of the new best-of-breed applications like Tomboy, F-Spot, Eclipse, Beagle, Muine, and many more. Gnome could then work on becoming a superior platform offering a variety of quality software for many users instead of fragmenting into a fork and only sharing a limited subset of effort. It really can work!
HIG
The Gnome Human Interface Guidelines (HIG) is a wonderful tool and has helped shaped the Gnome project into the wonderful software that it is today. For Gnome 3, it is time to revisit the HIG and see what changes if any need to be made. A full usability study should be undertaken to assess what deficiencies a variety of users find with the Gnome desktop and application interfaces. Based on their experiences and how they are interpreted by the Gnome Usability team, the HIG should be revamped to reflect a new mode of human computer interaction.
The developers and users have discussed a lot of neat ideas like making the entire panel a notification area, putting the menus into the panel like MacOSX does, and lots of other interesting ideas. This interface designer in particular makes some interesting points about Ubuntu but most of them relate to Gnome in general that deserve serious consideration for inclusion with the next generation of the Gnome HIG. I don't think any such major changes ought to be considered within the Gnome 2.x series, but with Gnome 3 on the horizon that may be an appropriate time frame.
Window Selection
Another idea that needs reinvestigation is how best to switch between active applications. Right now Gnome uses Alt-Tab, a Window list, a Window selector, and the workspaces metaphor. None of these is currently adequate for the simple task of switching between active tasks. Apple has done some work in this area with their Expos茅, and I think the Gnome team should devote more attention to this fundamentally important way in which people interact with their desktop. Moving from one application to another is perhaps the most common task that people perform on the Gnome desktop. Hacks like implementing workspaces on different sides of a cube in opengl are really neat, but they fail to address the underlying issue.
In particular is the problem acute when multiple windows are open for a single application. If you've got multiple browser or terminal windows open, trying to move between them is quite annoying. Each of those have the ability for multiple tabs, can be on one of multiple workspaces -- hunting for the right workspace, window, and tab to find what you are working on can be very frustrating. Unlike most of my suggestions, for this task I don't really have a good suggestion or potential solution. Is Expos茅 the best way to do it, or can we find something different-but-equal or even better? I think this topic deserves serious attention and should be a priority for Gnome 3.
Advanced Users
The Gnome Project has a reputation for trying to embrace and accommodate inexperienced and new users, but at the same time for alienating more advanced users. It doesn't have to be that way, I for one derive a lot of benefit from the simplified and consistent interfaces that Gnome has encouraged. However, there are some areas in which advanced users need to be catered to as well in order to stop these users from moving to competitive projects or to spend time attempting to fork Gnome for their own purposes.
One way to do this is to implement a system much like the Quicksilver application does on OSX. There is a similar program for Gnome in the early stages called Gnome Launch Box, but it is still in a very early beta. These applications allow for an advanced user to quickly launch applications and perform varied actions on files using a clever combination of autocompleting text and informative graphics. The application resides dormant until a keystroke combination is entered, and then from that they can launch common applications. A friend who is used to Quicksilver has described traditional methods of opening dialogs as being like a caveman pointing and grunting in comparison.
I propose than an application like this be included in Gnome. The inexperienced users will not be affected by this "invisible" feature, but advanced users can use it be very productive. An added benefit is that this tool would likely integrate nicely with the beagle-like filestorage tool I had previously mentioned, giving an advanced user quick access to their files and applications with a few quick keystrokes, never needing to access the command line. If we can get this integrated we can boast that Gnome 3 is the most friendly desktop for inexperienced and experienced users alike.
Conclusion
These are just some ideas, for other ideas see the developer discussion on the same topic from the people who unlike me actually contribute code.
-rt- 17:26 有人愿意翻译吗？ 有人愿意翻译吗？
随便了一下提纲（翻译太难了）http://www.gnome-cn.org/newsitems/distribution/ryan-gnome3-ideas/view 对它将要采用的编程语言，有些不理解
是说要用mono/gcj/java来代替现在所使用的C吗?
我可没精力再去重新学习一门新的语言
页:
[1]