apps: launching/switching/adding to activities

[Marco Martin]

On Wednesday 22 June 2011, Aaron J. Seigo wrote:
> On Thursday, June 16, 2011 23:27:10 Marco Martin wrote:
> > Hi all,
> > 
> > there is a pretty big area of the ui that has been just flat out ignored
> > right now:
> > * switching running applications
> > * browsing/launching applications
> > and, as connected thing, browsing application launchers is the way to
> > connect lauchers to the current activity.
> > 
> > at tokamak we already had a design session about all of this, the idea
> > was basically to put the window switcher and the launcher in the panel,
> > that can be pulled down to reveal the hidden parts.
> > 
> > I gave a try with a slightly different approach:
> > instead of pulling the panel (with its icons that would move, and would
> > seem strange)
> 
> why is that strange? if you pull something down, the things in it follow.
> millions of years of evolution have ingrained this expectation into us.
> 
> if you go to the app switcher or launcher, chances are you aren't doing
> that to interact with the system tray. so it's position is not critical at
> that point.
> 
> the nice thing about having it all in one place is that it can give
> everything a very "solid" feel to the user. the app switcher is just "off
> the screen" and "above" the system tray .. opening it and dismissing it is
> a similarly symmetrical action.
> 
> in terms of "naturalness", assuming that's still part of our goal here in
> plasmaland:
> 
> * things that spontaneously appear are "magic" and therefore not good
> * things that fade in are nomically better due to transition
> * things that slide in from a known, anchored location are even better as
> they allow one to use pre-existing mental model such as drawers and other
> hide/reveal items
> * things that connected to a smaller shown bit and pulled out as a part of
> those items are probably even better as it uses the even simpler "this is a
> single item, i just can't see all of it right now" model
> 
> i also don't like how in the example shown it doesn't use the whole screen.
> that seems like a waste of space, and on these screens that isn't something
> we have a lot of.

basically, user interaction wise the rationale was that all the launchers (or 
things searched with krunner) can then be connectedwith share-like connect 
with the current activity (or done all the other action with..)
so moving the share-like-connect icons would be strange... 
even tough we could end up using the long press context menu with the same 
info for the icon grid so that problem wouldn't sussist that much


now, for technical problems (hopefully solvable):
* i decided in the end to do a real panel in the plasma shell and not having 
it controlled by qml, that seemed a bit too much freedom from the qml side. so 
i don't have any way to move the panel from qml (since the root qml object is 
not available to the outside classes, like the corona, i can't even expose a 
property, giving a pointer of the panel in the qml context is even worse)
my soluton for that would be the systray applet  becomes a c++ applet (still 
with qml graphics) so it could expose a property or doing nasty things with 
its panel view, ugly but the least of the uglys i think.

* the drag could even be done by the plasmaapp itself, but to me sounds even 
more wrong, because is the plasma app that assumes panels behaves this way 
(and forking the plasmaapp again just to do a new behavior hmm, meh ;)

the panel is well, a panel window, so doesn't accept focus, while i would have 
a search field there.. i guess that would be easily solvable by changing the 
window type when is fully slided




what about still having a single window, but instead of the systray moving, 
progressively uncovering the things under the systray?

> > you pull a window *from* the panel:
> > http://i.imgur.com/37ESf.png
> 
> ok, so aside from the mechanics of show/hide ...
> 
> i do like putting launching with switching together. i agree with you that
> these are related items and it covers the use case of checking to see if
> something is running and if not launching it: "i'll switch to the web
> browser .. oh, it isn't open, i must have closed it .. so i'll just launch
> one."
> 
> i'm not sure about the thing (tag cloud?) on the left .. it makes the whole
> thing look messy and rather horrible.

yup it does...
but i would really like something to filter out application categories ( and i 
don't really like the old categories where an item is in a single one, it 
really doesn't work but this is another story)

so yeah, maybe some way to make this hidden and show it maybe with scrolling, 
dunno..
i could just not use it in the first merged version since in the target 
installation there shouldn't be a billion of menu items as i have now in the 
desktop here.

> putting the running windows above the launchers may make more sense from a
> number of angles:
> 
> * lets me see if something is already running before launching
> * since the contents of the launchers may change due to search, it will
> keep all the content snug and more consistently laid out if the
> non-changing (window list) is above the changing (launchers)

putting the tasks under the rest was decided at tokamak for a reason: peeking 
trough the task.
is now possible by dragging just a little bit to uncover just the tasks and 
not the rest to have a small taskbar that doesn't cover the whole screen.

if that is not important, ok for swapping, but while testing this reduced 
tasks peek on an actual touchscreen looked and behaved sooo nice ;)

Cheers,
Marco Martin