On 22/01/11 17:05, Karel Karlitos Macha jr. wrote:
I would like to ask if there is a possibility - for example with appmenu-gtk
API - to let the application menus disappear without the need of starting
indicator applet.
I am developping a Linux based kiosk for older people and the
On 18/01/11 18:09, Conscious User wrote:
They are very different things, and a design that works well for one
will hardly ever work well for the other.
I'm a little bit confused now because Mark's blog post about Unity
clearly stated that some design decisions were motivated by touch
We're experimenting with different uses of the backlight. For example,
we'd like to experiment with using that to show focus in the keyboard
navigation case (Alt-F1). I don't think running is useful, given we
already have the symbolic pips, and I think there are risks to changing
the look of the
Great suggestions all! How about this:
- if no app on the launcher can handle this type, and there is a
default launcher, we put it at the bottom (where it would launch) and
wiggle it to call attention to it
- we also allow drag to the apps place, which would open (on hover)
with the top
I would draw a distinction between touch friendly and touch optimized, and
while I agree with what MPT said about Unity and Ubuntu not being optimized for
touch (mainly because of the applications), there is nothing wrong with making
interfaces touch friendly (usable on, but not optimized for,
I think we should provide a standard collapsing approach for things
which could be window indicators and which are commonly system
indicators too, like volume. When maximised, the window indicator is
embedded in the system indicator (so there's only one volume indicator,
and in there you find
Hi,
Thanks a lot for your answer.
On Firefox for example, there is an extension (Tab Mix Plus) which
allows to put left close button at left side, with this order : Close -
Icon - Name
And when there is only one tab opened, close button is kept :
Using the example of volume control mentioned below, am I the only one who
thinks windicators make little sense and are in fact bad UX. Follow my example.
What is the added benefit of having the per-application volume control as
windicator. Music players already have per application volume
Ah, dammit, how did this end up in…
Sorry about this. :/
I'll move it to the right thread.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help :
Annoyingly, this somehow ended up in a completely different thread due to
the horrors of human error. I'm reposting here.
Sticking with the examples of Banshee and volume, for the sake of argument,
we also recognise two sorts of window indicator:
a) A window indicator that stands alone as
Placing at the bottom will hold challenges for a folded situation,
though placing at the top will slide things that would otherwise be
stationary. However, since we are known to be in a situation where no
icon can possibly resolve the drop (with the exclusion of the trash),
perhaps always placing
On Sun, Feb 20, 2011 at 12:51 PM, Carl Simpson cwd.simp...@gmail.comwrote:
My concern is that the functionality of changing the volume of Banshee
moves about quite a bit. It does this in two ways:
1) It moves from place to place in the interface- namely between the panel
and the window
On 20/02/11 18:39, Mitja Pagon wrote:
Using the example of volume control mentioned below, am I the only one
who thinks windicators make little sense and are in fact bad UX.
No, of course you are not the only person, there's lots of dissent,
which is fine and stimulates discussion to get a
13 matches
Mail list logo
