unity-design team mailing list archive
-
unity-design team
-
Mailing list archive
-
Message #01416
Re: Farewell to the notification area
Specifically concerning the idea of a constant place to minimize windows
too, on a parallel fork of the original email run, we've been discussing
this. I don't know if anyone likes my idea as of yet, but I'm going to keep
repeating it anyway. :D
The beginning of the discussion centered on an idea of tabbing workspaces to
the top. I, honestly, don't like that idea. Rather, I think a more practical
option would be to add an ability to create tabbed 'widget' overlay
workspaces, that are the same between 2, 4, or a hundred workspaces. so on
workspace one, the first tab is the standard workspace tab, the second is
the first widget layer, the third is a second widget layer. on workspace 2,
the first tab is workspace 2, the second is the first widget layer which is
identical to the first widget layer that was on the first, and the third,
the third. So the tabs are layers which exist seperately from the standard
desktops, and are accessible from each of them.
In use, this would turn into the user being able to click to either of these
layers (or more, however many you want) and open up long running
applications, like email or IM or music. These would be, presumably, still
controlled from the messenging menu and upcoming sound menus, but the user
can click to the layer to access the full program. This would prevent
clutter in several ways.
First of all, the user doesn't have to devote whole workspaces to always on
apps. I don't like that if i'm working on a lot of documents, evolution
sticks out like a sore thumb on expo. It takes up a whole workspace. I don't
like that if i start a IM conversation, i have to cycle around to find where
i left it.
second, it cuts down on need for so many workspaces. With this added
feature, i'd go from 4 to 2. I wouldn't need so many, because i'm devoting
whole workspaces to programs that could be hidden away better.
This whole idea doesn't necessarily have to be on tabs on the panel. I'm
just thinking that it would be great to make stackable widget layers, not
just one, that can be on the fly assigned any application that you can open
and put in it. As default, this would benefit the user far more then
multiple desktops, as it is much easier to visualize, and I think is what
more people use multiple desktops for. Eventually, power users will use
multiple desktops in addition to it.
This is long. ha.
In practical sense, think of the desktop as a binder open on a table. You're
working on it, you have multiple documents, happiness. But say you want to
pull out a totally unrelated thing. Do you want to scoot down the table to a
new spot? Or is just a quick task? A new desktop is good for sometasks, but
for just quick access, it makes much more sense to just set a whole new
binder on top of the current one, completely covering it. You can open other
documents, email, whatever. Its seperate, its contained. You have a paper
that you want to bring back. So pull it out, put that binder away, and take
the document back to your binder on the table, and set it down with
everything else you're working on. Quick, easy, and makes total sense in
real work flow.
On Thu, Apr 22, 2010 at 6:02 AM, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dylan McCall wrote on 22/04/10 04:50:
> >...
> > First of all, I think it would be worth investigating sound effects
> > attached to indicators. Doing it through the indicator applet means we
> > can (if desired) use Canberra's awesome ca_gtk_play_for_widget function
> > (which means beautiful positional audio).
>
> I don't understand why sound effects would be attached to individual
> menus. Can you give an example or two?
>
> > Secondly, I think it's really important to explore the window list at
> > this point. As others have mentioned, this is all doing a nice job of
> > establishing what certain APIs are for and making sure they don't get
> > misused. However, we're lacking a replacement for one of the more
> > popular misuses: notification icons for minimization.
>
> Yes.
>
> > One thing that occurs to me is to change the window list into a more
> > physical place that you can move windows to. So, "minimized" windows
> > appear there, and are available there, no matter what workspace you're
> > on. It would no longer list windows unless they are minimized. Pretty
> > substantial change, but maybe I can do a mockup or something if
> > anyone's interested :)
>
> I'm interested. :-)
>
> >...
> > I was a bit worried upon reading “And further, everything is becoming a
> > single set of menus.” I could be interpreting it wrong, but this sounds
> > like everything is going to be stuck in the same space at the top right
> > even though they are all neatly categorized. I think there should be
> > separation between these different categories of indicators in some
> > form. For example, substantial whitespace between app indicators
> > (including indicator-messages) and system-related indicators (battery,
> > session). Are we on the same page?
> >...
>
> The history of operating systems is a history of applications getting
> sucked in to the base system. The clock used to be a separate
> application; now it's a standard part of the environment. Connecting to
> the Internet used to be a separate utility; now it's a standard part of
> the environment. IM status used to be in application-specific widgets;
> with the me menu we're attempting to make it a standard part of the
> environment.
>
> I expect this slow trend to continue. A simple example is the battery
> status menu, which is currently a custom one (a patch to
> gnome-power-manager) but will soon migrate to the system area. So custom
> to systemic is a continuum, and I don't think it's useful to have a
> visual barrier between them. The system ones will be grouped at the end
> of the panel, and in a fixed order, and that's probably enough.
>
> Cheers
> - --
> Matthew Paul Thomas
> http://mpt.net.nz/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkvQSMkACgkQ6PUxNfU6ecpgRQCguUKxP/o9IV3MxJ6GhLV/7l6W
> aVAAoMOqttNpXkULuEOCTGFa6NjJHmUO
> =t0wq
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References