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