unity-design team mailing list archive

[Alex Smith <ais523@xxxxxxxxxx>]

So, I have a Big Idea about how to improve Unity, but it'll be a lot of
work to implement, so I'd like feedback on the idea, and whether it
makes sense or not. (There's a tl;dr lower down, if you don't feel like
reading this entire long email.)

First, I'd like to explain the rationale for the change by explaining
how the Launcher currently acts, and what the strengths of this approach
are. The Launcher is a bar containing a number of icons; some of these
are special-purpose; three in particular (Dash, Workspace Switcher, and
Trash) are always present no matter what. There are also potentially
icons to represent plugged-in devices such as USB sticks, but most of
the icons represent applications. (These are known as BamfLauncherIcons
in the code.)

The current behaviour of the application icons is as follows: there is
one for each application on the system (technically, one per .desktop
file, and extra icons are created if an application is started that
matches no .desktop file), although most of the time most aren't
visible. BAMF is used to work out which windows (if any) belong to the
application; if any do, the icon is visible and shown with extra
indications depending on settings (by default, with an arrowhead on the
left of the screen for each window on the current desktop, or a chevron
if all relevant windows are on a different desktop). If no windows
match, then the icon doesn't appear at all unless it's pinned; if it's
pinned, then it appears with no arrowhead or chevron. Clicking on an
icon lets you switch to or between windows that belong to it if any
exist, or otherwise starts the associated application if none exist (and
the icon is pinned; otherwise it wouldn't be visible to click on it).

So, the advantages of this system are:
      * For non-pinned programs, they have an appropriate launcher entry
        (that can be moved in the launcher, and whose location
        persists). So the user always knows where to go to activate
        their program; and even if it opens a lot of windows, it still
        doesn't swamp any of the other programs.
      * For pinned programs, the persistence of location becomes even
        more important, as it allows switching to and opening that
        program entirely from muscle memory no matter what is happening
        elsewhere on the system. (The abilty to rearrange icons in the
        launcher is even more important here.) There are two separate
        advantages to this; I can always open the program, and I can
        always find a running instance of the program.

The largest issue with the launcher at the moment, from my point of
view, is that "program" is often the wrong level of granularity. For
instance, I can pin Nautilus to the launcher, but if I do that, it
always opens the home directory when I click on it; typically I'd be
trying to open the folder with my music playlists instead, but I can't
do that by clicking a launcher icon, by default (I could create a
wrapper script or wrapper .desktop file instead, but this is a rather
technical thing to do that seems unreasonable to require for end users).
I can (and do) open the folder in question from the quicklist, but this
is one more click than I'd like. So this is a problem with using the
launcher to open "applications"; the problem is that I don't want to
open Nautilus, I want to open a folder!

Likewise, there are problems with using the launcher to locate running
windows. As I write this, I'm writing an email (kind-of obviously). I
have Evolution pinned to my launcher, so that I can quickly look at my
previous emails (I do this a lot, even if I haven't just received an
email). But I have the compose-email window open; that's two windows,
and as such I have to resort to a time-consuming spread or alt-` in
order to pick the one I want, half the time. What I'd want would be to
pin both my email inbox, and the compose-email window, to the launcher;
that way, I'd always be able to click on one or the other to choose
between the windows, rather than having to spread. Composing email and
reading emails are both functions of Evolution; but the way I use them,
they're more like separate applications.

For an example that combines launching and switching: although this
doesn't apply to me, a lot of people will have, say, GMail or Facebook
open in a browser pretty much all the time. They might want to do other
browsing too, and it would be awkward to group the GMail window with the
other browsing they're doing. Tabbed browsing helps avoid the issue to
some extent, but wouldn't it be great if you could put a webapp like
GMail in your launcher the same way you could put native applications
like Evolution there? That way, you can open it easily if it's closed,
and switch to it easily if it's open, regardless of what you're doing
elsewhere in your web browser, which should be irrelevant.

One final example shows this almost as a bugfix rather than as a feature
request. People who use many terminal windows at once find Unity very
hard to use; it's quite common to have one local and one remote terminal
window in several sorts of workflows, for instance, and maybe another
one for something less important (IRC client, games, etc.). In such
cases, spreading windows doesn't really help; terminal windows look
pretty much identical in preview. I've seen advice lying around that
people should style their terminal windows in a range of different
background colors just to make them usable with Unity; it strikes me as
ridiculous that such a workaround is needed. Why can't I pin a commonly
used ssh command to my launcher? Or pin an IRC client that runs in the
terminal? Or a telnet connection to a public NetHack server? Or a root
shell?

This suggests a solution. Pretty much everything that I've described so
far could be fixed by writing a custom .desktop file and always using
that launcher to open the program. The current behaviour is that I can
create a desktop file for, say, "sudo su -" in terminal by hand, and
then if I open a shell via that desktop file (perhaps using a pinned
icon or using the applications lens), it becomes a separate entry on the
launcher as desired. But if I run "sudo su -" inside a terminal, it's
grouped with all my other terminals, and not recognised as part of my
root shell "application".

The solution I suggest is simply to make these two rather
user-unfriendly steps (writing a .desktop file, and always using it to
open the application) unnecessary. In order to avoid the user having to
manually write .desktop files, why not just do it automatically? This
would involve adding a new quicklist entry, "pin <name of file> to
launcher"; if it's chosen, then Unity would from then on (until it was
unpinned, which would undo everything) treat the file in question like
an application of its own, rather than part of its "parent" application.
This includes treating windows as belonging to the file rather than the
application if they're referring to that file; so if I pin a particular
folder to the panel, then open it in Nautilus, the Nautilus icon stops
being marked as active and that folder's icon starts being marked as
active instead. If I navigate to a different folder in that window, it
goes back to counting as part of Nautilus. (If there's no pinned file
icon on the launcher matching a particular open window, it counts as
part of the application as normal.) "file" is to be interpreted
generally here as whatever makes sense for the application; in
Thunderbird or Evolution it would be a particular email folder, the
compose dialog, the calendar, etc; for a terminal, it would be the
command line of the currently running command; for a web browser, it
would be the currently opened page.

Another advantage of this approach is that it would clean up some minor
inconsistencies in the interface. For instance, if you click the Trash
icon on the launcher, it doesn't end up showing as active; rather, if
you have your home folder pinned, that shows as active instead! It leads
to a situation where the feedback shown to the user is really confusing
(and indirectly, to bug #692444; that bug could be fixed with a hacky
workaround at present, but making this change would allow it to be fixed
in a much less hacky way). Treating the Trash as a file within Nautilus
would make it consistent with everything else, from the user's point of
view (it would still need a bit of special-casing in the code to get the
icon right, but it would start acting just like everything else.)

>From the point of view of implementing this, the main challenge would be
getting BAMF to recognise which file is open in a window (anyone got any
tips for this?). Creating appropriate .desktop files for special cases
of an application automatically is very easy if it refers to actual
files or folders (or, more generally, URIs), because all the needed
information is in the .desktop file already (for use with, say,
gnome-open), but that would require knowing what special case we wanted,
first, which again comes down to recognising which file is open in a
window. Still, it shouldn't be too hard beyond that.

Would this sort of change be accepted if I implemented it? Does anyone
have any advice (or is willing to help code, although I'm willing to do
this alone if I have to)? Would this break anything unforeseen, or
complicate things more than they should be?

TL;DR:
Add a "pin <file> to launcher" option to the quicklist as well as "pin
<application> to launcher"; if a file is opened via any means while it's
pinned to the launcher, make that window count as part of the file's
launcher icon, not the application's.

-- 
ais523