contact-lookup-applet
Contact lookup applet for GNOME is an applet to quickly search your Evolution address book from the GNOME panel. INSTALL
file-browser-applet
Browse and open files on your computer from the GNOME panel with an applet for the GNOME Panel that lets you browse and open files in your home directory from your panel, without having to open a file manager. INSTALL
gtodo-applet
GTodo applet for the GNOME panel contains the applet of the GNOME "to do" list manager (GTodo) for the GNOME panel, that provides you with ways to easily open GTodo, or even check some of your to do items that are due the current day without opening it. INSTALL
quick-lounge-applet
GNOME panel applet to organise preferred applications can organise all preferred applications in a single place. When the applet size exceeds the available space a menu containing the remaining launchers is created. The menu can be accessed pressing the arrow button located at the end of the applet. INSTALL
service-discovery-applet
The service discovery applet, based on avahi for the GNOME panel, lists all available services which are published through avahi/Rendezvous/Bonjour/ZeroConf and allows to run actions on that service. INSTALL
sshmenu-gnome
ThisGNOME panel applet for connecting to hosts using SSH puts all your most frequently used SSH connections on a menu in your GNOME panel. Click on a host name to open a new gnome-terminal window with an ssh connection to the selected host. Set up options for port forwarding, etc. using the preferences dialog. INSTALL
The service discovery applet is one of my favorites.
When I started using Free software umpteen years ago, the standard response to a complaint about a bug that wasn't being fixed fast enough or a feature that the developer didn't deem important was "You have the code. You can fix it yourself if you want to."
That answer took a lot of flack with the Linux evangelists because it wasn't very user friendly. It "represents everything that's wrong with FOSS." Maybe. The unfriendliness doesn't change the accuracy. You do have the code. You can make a difference.
Sure. You may not be able to code. I couldn't. There's documentation to write, though, and if you speak a language out of the mainstream, there's plenty of translation work to do. That's how I got started: when Thai wasn't really supprted in early KDE, my name was on some of the translation work. I wrote some documentation. I supported the early FOSS movement in Thailand. I even gave several seminars about implemeting FOSS in schools there. Sometimes it was as simple as editing a definition file to get some hardware working and identified properly.
Could I code? No. Could I help? Of course. It didn't mean that I had to sit in chat rooms or on forums, either. There was (and still is) plenty of work to go around. We should still be able to say "If it's really important to you, you can do it" once in a while.
In addition to being an out-of-date filesystem which Microsoft is suing companies over left and right, FAT has some other serious limitations, one of which is a 4GB file size limit. I'm sure at some point, Bill Gates said "4GB ought to be enough for anybody." ;) Other filesystems which are similarly limited include HFS and ReiserFS.
If you try to use Nautilus or even cp to transfer more than 4GB to a VFAT fileystem, the transfer fails and leaves a large (4GB) pile of poo which you need a damn big pooper scooper to pick up. The bug relating to file transfer failures is years old and shows no signs of being resolved, other than just closing it and marking as "invalid." O_o A better man than I says:
No, no, no, don't close it, fix it! There's 19 duplicates and something like 50 people watching this bug. I've finished my education, had two kids and changed jobs three times since I opened this bug in 2005. Can we please not just close it, but fix it instead by issuing an error message? Trying to do something that will never work should be considered a bug.
It's got to be less than five lines of code the right place:
if( targetdir.fstype == "FAT32" && file.size > 4GB ) {
echo "Error: You are trying to copy a file larger than 4GB to a FAT32 formatted filesystem. FAT32 doesn't support file sizes larger than 4GB.";
return 1;
}
This bug, like many, is too difficult to solve unless we stop using VFAT altogether. Ahem.
Once you've upgraded to Jaunty and done the mandatory reboot, you're likely in for a big surprise -- Flash stops working in Firefox. This is related to a bug in Network Manager which drops the connection during the upgrade. Since Flashplugin-nonfree is really a dummy package which downloads the Flash player from Adobe, the download fails and the package shows as installed when there really isn't anything there.
The solution? There are two, one significantly better than the other.
Reinstalling flashplugin-nonfree will solve the problem short-term, but you're still stuck with this wonky download behavior which also breaks the package whenever Adobe updates Flash and creates a binary which doesn't match the package's checksum.
The better solution is to uninstall flashplugin-nonfree, enable the Partner repository, and install adobe-flashplugin instead. Flash is actually in that package, so you won't have any strange failures.
Of course, you could always install the plugin manually into your $HOME/.mozilla/plugins directory, but then you'd have to manually upgrade Flash, and it being the security nightmare that it is, there's almost no circumstance in which you want to do that.
If you are planning to upgrade your 8.04LTS machine up to 9.04 in order to get extra functionality, but depend on Avahi-based services like local chat in Pidgin or Empathy, Gnome User Share, or a DAAP server for music, you're in for quite a shock. Avahi fails to start for many machines due to either:
A router DNS cache system that's improperly configured (D-Link has one of these), or
An ISP which has its DNS system improperly configured.
When one of these returns a lookup for the .local domain, Avahi is shut down ... whether you have such a domain on your local network or not. You'll get an error like this:
avahi-daemon disabled because there is a unicast .local domain
What's the solution? Edit /etc/default/avahi-daemon and set
AVAHI_DAEMON_DETECT_LOCAL=0
to keep Avahi from making this check. Of course, you need to make sure that there isn't really a valid .local domain on your network, but if you're running a home network, that's unlikely to be the case. If you are sure the problem is with your ISP, you can change your router's DNS lookup to OpenDNS to solve the problem, too.
Last summer, I wrote about Vala, Gnome's C#-alike language that pre-compiles into straight C, with bindings to just about every good library you'd need to write Gnome apps. While Mono offers rapid application development, it carries the huge burden of the Mono runtime with it. A simple 125KB Mono app needs many MBs of runtime libraries. This is a constant discussion point on the Ubuntu front because Mono takes up space on the live CD for Tomboy and F-Spot that many people would rather see used for more features. Vala apps, however, don't need a runtime since they convert to C and then compile to standard binaries. You get almost all the benefits of Mono (sans cross-platform), but you don't get the pain. Vala also silences the Mono critics. Yay!
That's all great for the C# and Java programmers, but what about Python lovers who don't want their apps to need a runtime and the slowness of an interpreted language? Well, I recently discovered Genie, a language modeled on Python which uses the same valac compiler to create binaries, making all the same features available in Genie as are in Vala. Collaborators can even mix and match Vala and Genie in the same project since valac can handle both.
Genie still needs some serious love, though, especially in the documentation arena, which is almost non-existent outside of a few tutorials.
Lots of peoplelove Gnome Do. Why is that? It gives them power at their fingertips. More importantly, it takes the filesystem out of the picture. It gives you the power to open a file or take action without seven clicks.
Gnome 2 does what it can to keep you from thinking about the file hierarchy, with Nautilus supplying your devices and bookmarks. The Deskbar applet lets you search using Tracker or Beagle. The filesystem is downplayed, but it should completely disappear. Why? Geeks may not understand, but the filesystem, even in $HOME, can easily become a giant mess where nothing can be found.
There are great attempts to make this situation simpler. Zeitgeist combines your files, bookmarks, and browsing history into a time line instead of a hierarchy. In a similar way, the People Project tries to combine your e-mail, IM, and social network contacts into one interface and not worry you about having multiple applications running. Soylent is also working in this direction, and seems to have recently joined forces with People.
Where do I think we need to look for answers?
Look to Beagle. Well, not actually Beagle, but any full-featured full-text search client. Beagle has a good number of features that are needed (like SPARQL and embedding tag info in the file or filesystem itself using Extended Attributes when possible), so I point there, but the Mono connectiion may keep it performing well enough. Most likely, a new one will need to be developed. It will need word stemming.
Look to Deskbar. Well, not actually deskbar, but a similar search aggregator that focuses on search and not things like updating your Twitter account. It needs a new interface, too. That interface will look a lot little Nautilus does now.
Look to F-Spot. "Whaaat?" I hear you say. F-Spot has a great interface for dealing with pictures without worrying about the underlying file hiearchy.
It has tags on the left, representing both intrinsic and assigned values. They are hierarchical.
It has a timeline on the top, and files are ordered by time, meaning that your most recently worked on files are right there at the top.
The browser doubles as a viewer. Double-click on the picture and you change from browse mode to view mode. Click the browse mode to go back to multi-file view.
It has an "Edit" button to edit the picture.
We then have full-text and tag search (Beagle-ng) using multiple plug-ins (Deskbar-ng) with a Naultilus-like interface (with the addition of a timeline) which doubles as the viewer. Double-click a video or music file and get an embedded Totem. A document will embed a document viewer. Click "Edit" to open OO.o, The Gimp, PiTiVi, or whatever. The People Project can be integrated into the tags. Here's a quick and ugly mock-up.
What about your Nautilus bookmarks? Those become saved searches, and appear in the Places menu just as before. The standard XDG locations come as reserved tags. Speaking of the menu, Applications are just .desktop files, now aren't they? Index /usr/share/applications and $HOME, and you've got your menu. Put something on your Desktop just by tagging it "Desktop." Share something just by tagging it "Public."
So where do the files really go? What about the Open dialog? The default location for files needs to be handled for the user according to XDG specs and the MIME-type. Videos automatically go in ~/Videos, images go in ~/Pictures, audio files go in ~/Music, etc with names assigned by the user, not meaningless strings. In case of emergency or migration, files hierarchies are in reasonable shape.
Where should Gnome 3.0 go? Search, that's where. Gnome added a wiki page about 3.0 in the last couple of days. Apparently, they have similar ideas for the base fuctionality, though the interface isn't really discussed.