between a window and its title and
menus. It avoids showing one window's title in two places.
The downside is that menus for non-maximised windows are no longer at
the screen edge, so take longer to acquire and click. This is *not* a
regression versus Ubuntu 10.10's Gnome 2 desktop.
--
☮♥☯
Greg K
* consistent, and that's confusing.
--
☮♥☯
Greg K Nicholson
http://gkn.me.uk
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help : https://help.launchpad.net
are
slightly faded out and fades in on mouse over would look good on top of
being functional.
Once again, I'll take the opportunity to reiterate this solution to
that problem: https://lists.launchpad.net/ayatana/msg04555.html
--
☮♥☯
Greg K Nicholson
http://gkn.me.uk
This is already implemented in Compiz's Scale Addons plugin.
Another, complementary approach would be to have a lower limit for the
zoom factor when scaling—say, around 2/3—and clip windows if necessary
to only show the top-left corner (top-right in RTL locales).
On this subject I'd like to reiterate and support a suggestion
previously made on this list:
https://lists.launchpad.net/ayatana/msg04555.html
☮♥☯
Greg K Nicholson
http://gkn.me.uk
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana
Why not integrate (and hide) the menu bar in the title bar instead for
ummaximized windows?
This makes sense logically.
For maximised windows, the panel takes over the function of a title
bar. So it seems sensible that if the active window is unmaximised,
the title bar should behave in the
Gnome Shell currently uses the grave as shorthand for whichever key appears
above Tab on your keyboard layout. So presumably this would be localised
for each keyboard layout.
On 29 Oct 2010 12:39, Barry Warsaw ba...@canonical.com wrote:
On Oct 29, 2010, at 10:37 AM, Philipp Wendler wrote:
Using
I don't think it's useful to enforce one account per service. It has to be a
common use case to have, for example, a personal Twitter account and a
business one.
This should even make the UI design simpler: rather than having a fixed,
finite, unscalable list of empty accounts - one per service -
not a goal), this design would enable users who really
care to deliberately queue notices while they're away.
--
Greg K Nicholson
On 17 Sep 2010 09:12, Diego Moya turi...@gmail.com wrote:
On 17 September 2010 09:03, Conscious User wrote:
To be more clear, I think this goal is *alread...
Maybe
Mozilla's approach to community-driven design is exactly the same as
Ubuntu's: solicit ideas and implementations from all and sundry, then
take an opinionated decision on which to include by default.
Where Mozilla succeed better is that:
1. They solicit ideas more actively using their
OK, I didn't express myself clearly here:
So when should the window manager switch from assuming
you want a new window focused, to assuming you don't?
When you deliberately focus another window.
That's assuming the question. Whether you deliberately focus another
window is what the window
This doesn't work very well if an application in one workspace opens a
modal dialog under a long living application in another workspace.
Yes. If an application wants to open a dialogue, it really ought to
throw focus to that dialogue. If it's opening a modal dialogue, surely
it *must* throw
That is precisely what it does, and has done for years. But it will
always be guessing. If you're watching a video and it mentions an
unfamiliar word, and you launch the Dictionary to look it up, and it
takes two seconds to launch, you want it to take focus. But if you
launch OpenOffice.org
On 4 May 2010 05:48, Tyler Brainerd tylerbrain...@gmail.com wrote:
Actually I believe Mark gave some pretty clear reasons why. They want the
upper right to have a particular analogy, just like they want the upper
left. Right is for notifications, volume, brightness, and similar controls,
the
14 matches
Mail list logo
