This section is about implementation ideas of how to bring all the UNIX power (100s of commands/services/tools) to the GNOME desktop.

For many tasks, power users need still to go to the command line. We should try to get the cases when that happens and try to bring the features to the GNOME desktop, thus making it available, in a nice and GNOMEish way, to all users, whether they are advanced or not.

1. Access to command line tools

As stated before, UNIX systems come with 100s of commands to operate on files, text, images, network sites, etc, for which right now there is no access from GNOME. It would be very nice to provide power user features in the GUI that make use of those commands. Some examples:

• Conversion of formats (convert, db2*, latex, transcode, etc).
• Processing of output from one command as input from another command (pipes).
• Crypt/Decrypt of files.

  • Seahorse provide a nautilus extension to Crypt/Decrypt/Sign any file you right-click on, using gpg

• Synchronization (rsync, opensync, unison).

• Image manipulation (rotate and other simple operations) gthumb does this very well.

• cron/at (see gnome-schedule in GNOME CVS).

• The file command should share the MIME database with GNOME.
• "Open SSH session": in gnome-terminal? a separate application?

  • nautilus-open-terminal is a nautilus extension which implements this

• rename for selected files.

1.1. How to implement it?

• For some things, Nautilus plugins would make a lot of sense, providing extra menu items in Nautilus for powerful features.
• Scripts are a useful way of using UNIX commands. The problem is making scripting accessible to less proficient users, so maybe a graphical scripting interface (think similar to Apple's Automator) would do the job. And if it's just one command you're after, there's no stopping you having a one-command script.
• Maybe we can write up a simple/intelligent Omni Convert application. Which has a registry for possible commands for a filetype. Eg for 'text/x-tex' you get a drop down menu with ['Generate PDF', 'Generate DVI', 'Generate PS']. The only additional field would be the output filename. The entry in the nautilus-menu could then be "Common operation for TeX files".

• See Logical Desktop and OneFinger for GUI ways of using the "command line".

• See Nautilus Actions. This brings a new idea, which is to add a better support for the scripting feature in Nautilus. Nautilus actions could add a plugin that shows a menu item ('New script') only for the script folder, and thus, allow the user to add a script to be shown either in the Scripts submenu or as a normal item in the popup menu. Thus we would offer users with an easy way to add scripts/menu items. So, instead of having a separate applet (as NA does now), I would integrate it better into Nautilus:

  • Provide a 'New script' menu item (only show it for Scripts folder or for all?)
  • The dialog that responds to 'New script' is the nact from NA, with the same GUI but with the addition of the option to add the new tool to the scripts submenu, to the main popup menu or to both.
  • When tools are added via that dialog, the resulting custom items show up in the apropriate menu in Nautilus.

2. Message of the Day (motd)

Message of the Day is a UNIX feature that allows system administrators to have messages be shown to users as they log in. Most distros use a file (/etc/motd) where admins can put any message and which users can read on login.

Bugzilla bug is gnomebug:159604.

2.1. When to display the messages

Ideally, on log in, although we might offer a way to detect changes in the motd file and display notifications in the middle of the user's session.

Also, it is important to note that most distros include not very useful information in that motd file, and in some systems the file never changes, so there should be some way to avoid showing always the same message.

It's important also to note that motd file might contain some sensible information that shouldn't be shown to people without an account just looking at the login GDM screen. So, in the GDM login screen, the contents of /etc/issue might be better used, leaving the contents of /etc/motd to be shown when a user has actually logged into his/her account.

2.2. Where to display the messages?

• On a dialog on log in?
• On GDM login page? This actually already works, although GDM displays an ugly GTK dialog that covers the username entry. A better way might be to add the text somewhere to the theme layout.
• On the splash screen, so that there is something to look at while loading.
• On a notification bubble.
• Dedicated panel applet?
• Notification area on panel

As a suggestion, don't put it in a dialog or anything that requires the user to dismiss it every time you log in. That would be very annoying. The way it is displayed in a terminal is ideal; displayed whenever you open a terminal, but requires no effort to ignore it - you can just start typing as if it isn't there. So maybe a notification bubble that first appears on login but automatically dismisses itself after some period of time would be good. Combine this with a notification tray icon that only appears if /etc/motd has changed and I think you have a pretty good solution. -- MikeGratton

As the person who originally logged the Bugzilla request for this feature, I agree with all of Mike's comments above. We definitely do not want it in a dialogue that requires the user to dismiss it each time. Furthermore, once a user has read it, perhaps it should not appear on subsequent logins until the System Administrator changes the message. There are pros and cons for this but perhaps an option the Administrator could set would allow it to appear each time or only if the message had been changed. Another possibility reagarding where to display the message is on the desktop itself as a semi-transparent layer over the wallpaper. I do ot know if this is currently possible but if it were made readable but the user could still see his or her wallpaper, this could be an unobrusive option. I suggest this as a long message would not fit in a notification bubble or on the panel itself. -- David Le Sage, Hobart, Tasmania

The nature of /etc/motd is not such that a sysadmin will change it and expect current users to notice the change. For information like this there are commands like `wall'. Thus the notification tray icon will only add unecessary complication. -- FlorisBruynooghe

2.3. How to implement it?

• Into GDM itself and the themes, so that they reserve a space for the message.
• In gnome-session, just display the message as soon as the session is loaded.
• As a standalone command, so that it can be called afterwards and can store message history.

3. System messages

To get messages from shutdown, apcupsd, etc and the ability to communicate with other users in the system.

JohnPeterson: My suggestion can be found here under "The Dialog" heading.

3.1. What messages do we care about?

What should the user be told about? What does the user need to know?

• Critical power state messages? shutdown occuring, system running on UPS, battery low
• Root filesystem full/almost full

4. Access Control Lists Support

Linux 2.6 supports POSIX 1003.1e ACLs for most of the common file-systems. Solaris, HP-UX, AIX have ACLs, not POSIX, but they can be easily wrapped. FreeBSD, thanks to the TrustedBSD project has support for POSIX 1003.1e.

Bugzilla bug is gnomebug:62817.

4.1. Where to implement them?

• Nautilus file properties would be a great start. Having a new tab for the ACLs would help.

  • A nautilus extensions seems to exist for this: http://rofi.pinchito.com/eiciel/

    • Well, this seems to need some work. For example, I think it's strange that the ACLs are in a different tab than the standard UNIX permissions. ACLs are just an implementation detail of how the permission system works and should be abstracted as far as possible in the UI. -- SebastianRittau 2005-08-26 17:48:42

• GTK File Chooser/Selector could be next.

4.2. How to implement it?

The SAMBA project has support for POSIX ACLs and for ACLs from different operating systems. That might be a nice start. A special case for GTK would be win32. For win32 a much better choice would be just to bring out the standard windows file properties panel.

5. Regular expression Support

I often end up going to the console for doing advanced searches which also includes altering the files which matched a regular expression. So one have to write a find command, a grep command and a sed command. This is something I would love to have some GUI support for. Maybe the possibility to preview all files the matches a regular expression. The sed part is probably a bit more tricky.

5.1. How to implement it?

• I think the best thing is to add regular expression support in the gnome-search-tool and/or beagle.

  • Could the Nautilus/Extending model be used to implement this?