These items were on the ThreePointZero page, but were not really 3.0 kind of things- i.e., there was no reason they couldn't be tackled in a 2.x timeframe, since they did not break API/ABI/UI compatibility.
- Rich Cut/Paste/Drag:
- Rich dnd and copy/paste - Currently these are in a woeful state. I can't paste emails into anything. I can't drop emails or conversations or webpages onto printers. The drag icons for almost everything is the useless stock document. Our apps simply do not handle external integration.
ThiagoSayao: Something like ms office does with cut and paste would be nice. A notification area or an applet would make it easy to navigate throught cutted text/objects. So multiple objects could be copied/cutted and the user could select what and where to paste.
FedericoMenaQuintero: RTF is pretty sophisticated these days; we can probably use that for rich selections that travel over the clipboard or drag-and-drop. I don't know if it has a provision to embed image data or if we would need to define a chunky format. Also, our drag-and-drop APIs could make things easier in general... (MarcMaurer: AbiWord uses RTF internally for ALL its internal copy&pasting, so yes indeed, RTF is pretty sophisticated. Note that writing a *good* RTF importer/exporter takes a massive amount of time. There are some limitations to RTF though, such as bad support for RtL, and Unicode (especially everything above 64K. UTF8 can be used in RTF to solve this issue, but there aren't to many RTF readers that support this fully). Furthermore, AbiWord and Gnumeric communicate using XHTML on the clipboard (try copy&pasting some cells from Gnumeric into AbiWord for example) so XHTML might be a good candidate as well.
PatrizioBruno : What you think about having a configurable format, so to be compatible with the host's platform? This would make GTK applications compatible with QT applications, IE, OpenOffice, MS Office, Safari, etc.
AlexGraveley: Its not so much the format I'm worried about, though an image-rich format would be great. I'm more upset by the lack of application support, polish, and documentation for DND.
FedericoMenaQuintero: GTK+ 2.6 has nice functions to set/get pixbufs from a GtkSelectionData. As for DnD, yeah, the documentation sucks. I'll start rewriting the DnD tutorial that I started once; I accidentally (and painfully!) wiped it out in a bout of "let's free up space by deleting cvs checkouts I don't need..."
AlexGraveley: Great! In addition to nicer docs I would really like to see a wiki dedicated to documenting what DND targets apps support and generate, with protocol and usage descriptions. I've been compiling this stuff locally for Tomboy. I should put it up someplace probably.
FedericoMenaQuintero: Could you put it somewhere here on live.gnome.org? We can then get people to contribute with the stuff from their own apps, and later move it to developer.gnome.org when appropriate.
- Undo/Redo - Support this in every application that allows changing data. Use the HIG to specify how this should work for text widgets; currently gedit, evolution, mozilla, openoffice all have completely different semantics for Undo/Redo (undo a single character at a time, or a phrase, or a word, etc). Evolution doesn't support undoing email deletes/moves.
FedericoMenaQuintero: Do we need an API to make this relatively easy for applications to implement? As a pie-in-the-sky, related thought, would having such an API pave the way towards having version control for everything?
FedericoMenaQuintero: Can't we steal something pretty much wholesale from GEdit or Scintilla?
PaoloMaggi: Have you rewritten it in C? Which are the additional features you have added?
AlexGraveley: Nope, C#. I needed to support applying/removing tags as undoable operations, blocks of undoable operations grouped together, and undoing object insertion (pixbufs/widgets) (doesn't work yet).
- Trashcan to delete anything - This should work for everything. Emails, gaim buddies, bookmarks, etc. And everything I delete should show up in the trash.
- Non-ASCII Searching - Most apps seem to handle searching for anything other than ASCII in completely different ways. E.g. some match 'è' when searching for 'e', some don't.
FedericoMenaQuintero: Maybe we just need some guidelines on which magic Unicode-related functions to use to make this work.
AlexGraveley: I'd rather have a well spec'd description. Apps which don't use the C api won't be helped by magic functions. And textual searching has too big a spectrum for any API be suitable, really.
FedericoMenaQuintero: Hmm, yeah. Have to dig in the Unicode spec to see how that is done.
DanWinship: Some people complained when evo used to do this. People in different locales may have different expectations. Quoting Wikipedia, "It's not an 'O' with a slash, it's an 'Ø'."
PaoloMaggi: the only problematic aspect of Non-ASCII searching is caseless mapping. The Unicode Standard Version 4.0 contains a lot of info about how to implement it (also if, from our experience with GtkSourceView, I can say it is not so easy to implement). You can see the following sections in the Unicode Standard Version 4.0:
Debouncing - Newbies and non-techies double-click everything. Gnome doesn't support this at all. Double-clicking on menus in the panel or apps flashes the menu, leaving people confused. Double-clicking a launcher spawns two instances of an app, annoying people and leaving them thinking Gnome is buggy. Raymond Chen talks about how they did this in Windows. Jwz talks about how he did this with Gnome for his nightclub (near the end, Multi-clicks section).
FedericoMenaQuintero: See the proposed gtk_button_set_ignore_double_click(), which would work for the panel lanuchers. We could probably abstract this with a little object into which you feed mouse events, and it sets up timers and everything. See also the patch I put in for panel launchers in Novell's gnome-panel package.
AdonikamVirgo: As always, this is a great idea, although education is better - as long as one can turn this on and off, everyone will be happy. A related point is that everyone I know will not click a launcher a second time if it uses startup notification, which is not universally used.
RaphaelBosshard: Fileselector inconsistency: Currently nautilus applies (per default) a spatial mode. This works good a long as you just want to view/edit things. But as soon as you want to create something, you have to drop "back" into navigational mode; the fileselector. Maybe save trough drag and drop could be implemented somehow? (ROX has implemented something like that.)
DanielBorgmann: The most logical way to create something in an object oriented (spatial) environment is to create the document first, then edit it. You can do this easily with text files in Nautilus, but it would be nice if you could create more types of documents without knowing the (technical and often obsolete) file extension. For example, right now there is no way to create a document and then edit it with the Gimp as an image, without knowing the cryptical ".xcf" extension. Of course this doesn't mean that drag and drop saving would be useless, I'd still love to see this feature myself. Especially for exporting it would be a great help. Our screenshot tool already does it quite nicely and I use it all the time.
MartinEbourne: Although creating a document first and then editing it works for some use cases, it doesn't work for all. eg. If you load a document, make some changes & want to save it as a new document; if you load a document in one format and want to save it in another; if you start without a saved document, using a 'scratch' space, and want to save it later. Freedesktop.org has the Direct Save Protocol (XDS) for doing drag & drop saves, and this is what ROX uses. It would be great if Gnome would support this. I'm even up for helping with the coding for this one.
DesktopNotifications - MikeHearn and ChristianHammond have done some work on this, there is a notification server that uses DBUS and a client side library. [LuisVilla4: I moved this to the 2.x roadmap because I don't believe that, fundamentally, this is a massive change for users; however, if doing it 'right' involves, say, killing all applets, or if specing the behavior involves two different paths depending on whether we are document-oriented or application-oriented, then I could see it moving back to ThreePointZero.]
Easy file sharing - Ability to share file metadata with remote friends. For example a friend could request to see my new music. A list of new music is presented to them and they then choose what to download. This could be implemented over IM over galago. A mockup of this type of idea is here - easy file sharing mockup [As above: I think this is 2.x material, but if the model changes radically based on document-oriented or application-oriented, then it could be reconsidered for the ThreePointZero page.
PaoloMaggi: (On spell checking) We are writing a library based on the gedit code we hope to release in the next months. The library we are working on contains standard dialogs for spell checking and selecting the current language. We are using enchant as backend (actually we work with aspell too). We have a nice gobject-based class wrapping enchant (and aspell). And we have ported libgtkspell to use our gobject wrapper too.
RaphaelBosshard: Redo the "resize window" widget in the standard GNOME statusbar. Resizing is not really an application action, it's a window manager action. Maybe if Metacity just would display a "resize" button in the lower left edge, similar to what OSX does?
Include Paths: I'd like to see general includes (like <glib.h>) in one top-level (read as: /usr/include/glib-3.0 where this path is included in the search path by pkg-config) include file and when you only need specific stuff you can include them with a path like <glib/gslist.h>. Not all libraries have this yet. SvenHerzberg.
Just file bugs/patches - this is not API/ABI-breaking. MurrayCumming.
Application Improvements and Features
In order to improve the user experience throught gnome 3.0 some new applications should be developed and the current ones improved in terms of features
ThiagoSayao: Easy Cd-burning. The current cd burning on gnome is far from feature complete. Of course the user should not be presented with a big list of options he can't understand, but some options and features are required, like burning music cds, choosing some writing options, ... These could be implemented on separated apps, for example, sound-juicer could be extended to do the reverse operation of burning music cds, nautilus-cd-burner could be improved. Perhaps using libburn would be a nice idead (it should be more mature by the time of gnome 3) because forking processes to burn cds seems ugly and easy-to-fail.
ThiagoSayao: Download manager. Many users still uses dialup and slow connection. A way to pause and continue the download would be very nice for everyone. Of course it should be on a centralized place, like a download notification area or a download applet. Its not just the case of a slow connection, sometimes files can be really big, like a distro iso or something. Imagine downloading it on a laptop for example, the user will not let it turned on for many hours as required to the download to complete. Or better, imagine if the connection goes down, which is very common to happen. So an application that listens to download requests would be super, so epiphany, gaim, music applications and others could use it to download files from http://, ftp:// and all other kind of remote networks supported by gnome-vfs. Download Complete, Download failed and other messages would be displayed as notifications.. very nice
RaphaelBosshard: Maybe this download manager could be used as a general target for gnome-vfs operations: currently, all applications have to create their own download managers. But what if gnome-vfs would implement a download manager as default callback for file operations?
JamesAscroftLeigh: I normally download files to my desktop. What if the nautilus desktop was the download manager UI - showing the file at the download location with a progress bar decorating the icon and a tab in the properties box showing the download status (and maybe even upload status for completed bittorrent downloads).
GeertSchuring: Audio/video handling: I don't know how you guys think about this, but i really don't understand why my system has 6 differend ways to play audio (Oss, alsa, e.a.). This should be centralised. Also, i am constantly trying 4 differend apps when playing video because no single app will just play it all (no, vlc aint *that* good). When i think of Gnome3 i expect it to handle all audio and video with a single app. At least let it seem that way.
RonaldBultje: don't we already have GStreamer (http://gstreamer.freedesktop.org/) for this? It seems to me like this is merely a matter of implementation bugs, and not so much a lack in design or anything. We are trying to unify the desktop multimedia experience as hard as we can. GNOME is actively promoting and supporting Totem (http://gnome.org/projects/totem) as the one and only video player. Through GStreamer, subsystems are hidden from the user (such as OSS, ALSA, SunAudio, ...). If there's bugs, file them.
Performance and Optimization
Optimize various pieces of the GNOME desktop to improve performance on both high-end and low-end machines.
Starting point: http://developer.gnome.org/doc/guides/optimisation/
- Memory usage
- Disk access
- Invent "tricks" to improve apparent performance (remove foot menu click lag by somehow keeping that data in memory, for instance)
- Fix the last gnome-terminal issues
The performance characteristics of CPUs from this point on will be different, we must adapt to that. See Herb Sutters article on the importance of concurrency.
Two techniques we should explore to improve that ever important startup time:
- Develop a working set optimiser. Nat did something like this with Grope but it never gained traction (and was designed to be an end user tool, iirc)
- Develop techniques that allow for aggressively parallel startup. For instance, one thread can be loading and creating the GUIs from Glade, another can be loading the document, another can be reading icons from the icon theme. The key point is to minimize the amount of time you spend blocked on disk IO or synch with other processes.
MikeHearn: it keeps coming up from time to time, people say GTK2 based apps take a long time to redraw. Rendering the Evolution main window can take up to a second of full CPU usage on my Athlon 1200, yet for some reason KMail renders much faster. This isn't an Evo specific thing, other GTK2 apps show the same issues. It's been widely reported by users but we're no closer to understanding what's going on - is it a real problem or purely perception? Is it due to lack of flickering from the double buffering? Given the imminent arrival of Composite, do we even care?