Re: When UI Enhancements go bad...

[Cliff Resnick]

That fixes everything. Thanks!

-Cliff

On 02/28/2011 01:48 PM, Marcel wrote:
I know, I know, some of you will desperately want a GUI for that, but 
this is just to help Cliff Getting Things Done (tm) ;)


You can disable pinning of modal dialogs in gconf. Set
/desktop/gnome/shell/windows/attach_modal_dialogs to false (uncheck) 
and you should be fine. I haven't tested it myself, I just know that 
the option is there.


Marcel

Am 28.02.2011 03:54, schrieb Cliff Resnick:

I'll submit a bug, assuming inhibiting resizing dialogs is
unintentional. But there are other issues. For instance, with pinned
modal dialogs you can no longer move a stacked dialog window to
reference the one behind it. This is clearly part of the imposed
behavior, and consequently another headache when I use Eclipse. I don't
mean to rant about this, but it pains me that I may not use something as
good as Gnome-Shell because design decisions start to actually get in
the way of me getting work done!

-Cliff

On Sat, Feb 26, 2011 at 3:42 PM, Milan Bouchet-Valat mailto:nalimi...@club.fr>> wrote:

On sam., 2011-02-26 at 21:11 +0100, Fabian A. Scherschel wrote:
> On Sat, Feb 26, 2011 at 8:32 PM, Gendre Sebastien
mailto:ko...@romandie.com>>
> wrote:
>
>
> If I undestand, Eclipse use pop-up windows instead of simple
> shilde windows?
>




>
> If it has always worked in every other DE and Gnome Shell breaks it
> now? To say that is the app's problem would be a bit arrogant, don't
> you think?
No, that's a fair question. The Shell radicalknowly changes the 
behavior

of dialogs, thus it may unveil small issues in apps that weren't
experienced with other window managers because they behave very
similarly in that regard. It's possible that the windows that 
don't work
with the new design should be set up differently by Eclipse. Of 
course,

it may also be a problem with the Shell, but you cannot be sure in
advance.

I think some of the Shell's developers are using Eclipse, so they 
should
be able to debug this problem. Else, you'll have to provide 
screenshots

and run 'xprop' on the incriminated dialogs so that they have enough
information. Anyway, a bug report is probably a better place for 
this

kind of thing.

Regards


___
gnome-shell-list mailing list
gnome-shell-list@gnome.org 
http://mail.gnome.org/mailman/listinfo/gnome-shell-list




___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list


___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Robert Park]

On Tue, Mar 1, 2011 at 7:35 PM, Ryan Peters  wrote:
> Last I checked, virtually every device with a trackpad has some sort of
> physical mouse button for this very purpose (laptops and whatnot).

O RLY?

http://www.google.ca/images?q=buttonless%20trackpad&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&um=1&ie=UTF-8&source=og&sa=N&hl=en&tab=wi&biw=1671&bih=945


-- 
http://exolucere.ca
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Gnome Shell Build Error - libmozjs.so

[Antono Vasiljev]

On Sat, 2011-02-26 at 13:36 -0800, bsquared wrote:

> Gnome-shell doesn't build, Error:
> 
> (mutter:19746): mutter-WARNING **: Could not load library
> [/usr/src/gnome/gnome-shell/src/libgnome-shell.la (libmozjs.so: cannot
> open shared object file: No such file or directory)]

Same problem here. Any help?


-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

On the use of keyboard

[Nguyen Thai Ngoc Duy]

Hi,

I upgraded gnome-shell and found Ctrl-Alt- are now gone.
The automatic workspace is fantastic, I like it. But I'm on laptop
with only touchpad so switching workspace is a bit slower for me. Is
there a plan to put keyboard support back some time?

On the workspace switching, I think C-A- are good ones,
unless you intend to keep the combinations for something else. Then
C- in overview mode for selecting window? Shortcuts for
resizing window to one half of the screen would also be nice.
-- 
Duy
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Ryan Peters]

On 03/01/2011 03:52 PM, Alberto Ruiz wrote:

2011/3/1 John Stowers:

Admittedly it is usually windows users who I observe doing this, but I
think it is wrong to assume that users;

a) know that double click exists
b) can actually distinguish that it is different from single click

Not to mention, trackpads are double click unfriendly.

Last I checked, virtually every device with a trackpad has some sort of 
physical mouse button for this very purpose (laptops and whatnot).

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Alberto Ruiz]

2011/3/1 John Stowers :
> Admittedly it is usually windows users who I observe doing this, but I
> think it is wrong to assume that users;
>
> a) know that double click exists
> b) can actually distinguish that it is different from single click

Not to mention, trackpads are double click unfriendly.

-- 
Un saludo,
Alberto Ruiz
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[William Jon McCann]

Hey Sandy,

On Tue, Mar 1, 2011 at 10:54 AM, Sandy Armstrong
 wrote:
> (What happened to your mail client line-wrapping settings?)
>
> On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor  wrote:
>> The maximize button
>> ===
>>
>> The above was about minimization - but the request was also to remove the 
>> maximize button. This is a little different since there are more obvious 
>> ways to maximize a window - the drag to the top gesture or double-clicking 
>> on the title bar - we're not really talking about removing the feature of 
>> maximization but just the button.
>
> I generally applaud the bold changes happening in the shell, but I
> disagree with removing the maximize/restore button.  I'll paste here a
> comment I wrote on Allan's blog:
>
> 1) Drag-and-drop is very difficult on touchpads, and most people these
> days are buying laptops. Drag-and-drop is also undiscoverable.

That depends a lot on the quality of the touchpad too... With a crappy
touchpad (and there are a lot of them) it is arguably harder to aim
precisely to hit a small button than dragging a large object
(titlebar) to a Fittsian infinite edge (top of screen).  This is made
worse when the maximize button is immediately adjacent to a button
that is as opposite in effect as you can get.  Two bits of badness
converge here.

The first is that the cost of a slip in aiming and clicking is
unreasonably large.  There is no undo for window close.  It is
definitely not what you wanted to happen.  It is relatively difficult
to recover from.  And in some cases may result in data loss.  In every
case it results in intense frustration (argh-ing).  We don't want the
user to ever feel that.

The second is the stress involved in aiming at a small target which is
intensified by a known cost of a slip.  It makes you think.  The
interface ideally should not interrupt you and draw that kind of
attention to itself.

These issues were always present in classic window management but
become highly problematic with many touch interfaces and especially so
with low precision pointing devices.

There are three other things that should help in these cases:

 * using the entire titlebar as a double click target to maximize
 * using keyboard shortcuts for maximization
 * in some cases maximizing certain sovereign apps by default
(particularly on smaller screens)

> 2) Double-clicking the title-bar is undiscoverable.

Honestly, I think "discoverability" is one of the more misused
critiques of user interface design.  There are a lot of reasons for
this and I won't cover them.  I don't think that discoverability is a
prerequisite for a successful interface.  Surely, in many cases it
helps.  But it is just one factor.  Gestures (especially touch) aren't
discoverable and yet they are extremely useful and powerful.  Context
menus aren't discoverable and yet they provide a way to access lots of
functionality that couldn't otherwise be presented in the visible and
discoverable interface.  Keyboard shortcuts obviously aren't
discoverable most of the time.  As you mention above, drag and drop of
any kind is not discoverable and yet it has formed the basis of many
very successful designs.  Discoverability almost always involves
learning.  You are not born knowing what the "_" icon in every window
means.  Nor do you intrinsically know what "maximize" means.  You
learned it at some point.

Another trend you are seeing is a bit of a drift away from symbolic
representation and indirect action to more tactile direct
manipulation.  I think this is natural.  It feels better somehow.  And
if it just does that thing I don't need to know the name for that
thing.  When I throw a window at the top of the screen it gets bigger.
 I wanted it to get bigger.  Cool.  I don't have to even know the word
for it in tech speak is maximize or know that it is symbolically
represented by a square.

I don't have any plans to drop the symbolic close button but some
successful designs have done this already.  WebOS uses a close gesture
and no on screen explicit controls.  iOS on iPad mostly does away will
all forms of window management but in some cases (secondary windows)
uses a "Done" button instead of the symbolic version.

To summarize, discoverability is only one of the considerations in
designing a successful interface.  In this case, it wasn't the most
important factor.  But if you simply cannot get used to life without
the maximize button, despite the benefits, or using one of the other
approaches mentioned above, feel free to add the button back using the
settings.

Hope that helps a bit.

Jon
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[John Stowers]

On Tue, 2011-03-01 at 07:54 -0800, Sandy Armstrong wrote:
> (What happened to your mail client line-wrapping settings?)
> 
> On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor  wrote:
> > The maximize button
> > ===
> >
> > The above was about minimization - but the request was also to remove the 
> > maximize button. This is a little different since there are more obvious 
> > ways to maximize a window - the drag to the top gesture or double-clicking 
> > on the title bar - we're not really talking about removing the feature of 
> > maximization but just the button.
> 
> I generally applaud the bold changes happening in the shell, but I
> disagree with removing the maximize/restore button.  I'll paste here a
> comment I wrote on Allan's blog:
> 
> 1) Drag-and-drop is very difficult on touchpads, and most people these
> days are buying laptops. Drag-and-drop is also undiscoverable.
> 2) Double-clicking the title-bar is undiscoverable.

I agree with these reasons.

May I also add one more - double clicking is terrible. Firstly, I always
opt for single click (recovering RSI/OOS). Secondly, how many computer
users *still* have no idea what double clicking does; the kind of people
who double click on *everything*, links in websites, menus, buttons, or
keep double clicking on applications while waiting for them to start.
Admittedly it is usually windows users who I observe doing this, but I
think it is wrong to assume that users;

a) know that double click exists
b) can actually distinguish that it is different from single click

I would prefer the approach of 'one foot in the old and one in the new'.
maximize for the old, dragging for the new. I still know windows 7 users
who don't use aero snap, so keeping maximize not only retains
familiarity for them, but current gnome2 users too. 

John


___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Sandy Armstrong]

(What happened to your mail client line-wrapping settings?)

On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor  wrote:
> The maximize button
> ===
>
> The above was about minimization - but the request was also to remove the 
> maximize button. This is a little different since there are more obvious ways 
> to maximize a window - the drag to the top gesture or double-clicking on the 
> title bar - we're not really talking about removing the feature of 
> maximization but just the button.

I generally applaud the bold changes happening in the shell, but I
disagree with removing the maximize/restore button.  I'll paste here a
comment I wrote on Allan's blog:

1) Drag-and-drop is very difficult on touchpads, and most people these
days are buying laptops. Drag-and-drop is also undiscoverable.
2) Double-clicking the title-bar is undiscoverable.

Conclusion: maximize/restore button should remain.

Too me, it's a simple as that.  I don't think the "cleanliness" of
removing the button is worth the UX trade-off.  Getting rid of the
minimize button is great, though!

Thanks,
Sandy
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Activity Bar Panel Provides Little Utility, Takes Up Space, And is Distracting

[Mystilleef]

On Tue, Mar 1, 2011 at 5:19 AM, Thomas Bouffon  wrote:
> Hi
>>
>> Fair enough. But do we, or users, spend a significant portion of our
>> desktop activity staring at the clock? Isn't the clock in many cases a
>> distraction when we need to get work done?
>
> Actually Much less of a distraction/waste than having my name, a network
> status as I am on a static IP Lan and a volume button as I have no speaker
> plugged in my PC.
> Moreover, needing an action to check the time would change the time spent
> from a blink of an eye to a few seconds.
>
> Actually, I even used to display the time of my next bus in the status area
> (until it was not compatible anymore with the shell and did not spend time
> to fix this).
>
>
> Cheers,
> Thomas
>
>

To be honest, I don't get the clock argument. If you want to
know the time, it's little or no effort to press the
"window" or "super" key. I'd wager it takes less than 250
milliseconds to get the date and time this way. Perhaps a
few milliseconds more than the current method. But that's
hardly perceivable by human cognition.

I think the clock and all the other items are mostly
redundant activities that don't need to be persistently
visible. The top panel belongs in the activities screen
rightfully like all the other shell elements.

At the very least the top panel should have autohide or
intellihide capabilities for users who don't care for
starring at the clock or panel all day. I have no data, but
I'm sure there are many of us.
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Activity Bar Panel Provides Little Utility, Takes Up Space, And is Distracting

[Jasper St. Pierre]

> Hi
>>
>> Fair enough. But do we, or users, spend a significant portion of our
>> desktop activity staring at the clock? Isn't the clock in many cases a
>> distraction when we need to get work done?
>
> Actually Much less of a distraction/waste than having my name, a network
> status as I am on a static IP Lan and a volume button as I have no speaker
> plugged in my PC.
> Moreover, needing an action to check the time would change the time spent
> from a blink of an eye to a few seconds.
>
> Actually, I even used to display the time of my next bus in the status area
> (until it was not compatible anymore with the shell and did not spend time
> to fix this).
>

If you did this with a custom panel applet, it's still possible as a
shell extension, and actually quite easy.

You can set this up as a calendar event in e-d-s too.
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Activity Bar Panel Provides Little Utility, Takes Up Space, And is Distracting

[Thomas Bouffon]

Hi

>
> Fair enough. But do we, or users, spend a significant portion of our
> desktop activity staring at the clock? Isn't the clock in many cases a
> distraction when we need to get work done?
>
Actually Much less of a distraction/waste than having my name, a network
status as I am on a static IP Lan and a volume button as I have no speaker
plugged in my PC.
Moreover, needing an action to check the time would change the time spent
from a blink of an eye to a few seconds.

Actually, I even used to display the time of my next bus in the status area
(until it was not compatible anymore with the shell and did not spend time
to fix this).


Cheers,
Thomas
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list