unity-design team mailing list archive

[shane lee <shaneymail@xxxxxxxxx>]

It makes sense to me and there are times when I have wanted to pin a
document to the launcher that I'm working on.

More than anything, I would love to be able to drag a tab from chromium to
the launcher and it would turn it into a web app or something.

On 12 May 2012 22:34, Alex Smith <ais523@xxxxxxxxxx> wrote:

> 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
>
>
> --
> Mailing list: https://launchpad.net/~unity-design
> Post to     : unity-design@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~unity-design
> More help   : https://help.launchpad.net/ListHelp
>