[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: While were making controversial suggestions... ;)
From:       Kurt Granroth <granroth () kde ! org>
Date:       2000-04-28 19:07:45
[Download RAW message or body]

Michael Matz wrote:
> > Say you have to windows that slightly overlap each other.  If the one
> > on the left has focus, then the titlebar of the second app is totally
> > obscured... if you want to move that window, it's a pain.
> 
> With click to focus you can click into the menu bar or the window itself,
> with focus follow mouse you have no problem at all.

Back to my example, say I want to move the second window.  Let's also
assume that my second window is an editor.  Now let's look at your two
cases:

Click to focus:
I move the cursor over the window and click on it.  Oop, this just
moved the cursor in the editor to a place where I did *not* want it.
I then move the x cursor back to the left and up and slowly find the
titlebar.  I finally move the window where I want it.  Now I move down
to my editor and move the editor cursor back to where I want it.  What
a pain.

Focus follows mouse:
I move my x cursor over the window and wait until the window comes to
front.  The amount of time is, of course, configurable.. but it is
always noticable.  I move the cursor back to the left and up and
slowly find the titlebar.  I click on the titlebar and drag to move.

Let's contrast this with ANY of the other styles with a full titlebar.

Any other style with any focus policy:
I move the x cursor over to the titlebar.  I click on the bar and drag
it where I want it.

LOT'S faster.

And yes, I do know that you can move windows with ALT-LMB... but this
is about titlebars, not shortcuts.  And besides, only hard-core KDE
geeks know about ALT-LBM... newbies definitely won't.

> Now guess, why you can move the title bars. Exactly because, that if
> windows overlap (even if they overlap totally), you can see and
> access more than one title bar. It is a feature. Note that with
> unmovable title bars and overlapping windows you have no simple
> mechanism to show the obscured title bar.
> 
> It is not just a thing which is "fun to show".

Hey, if the movable titlebars where automatic, then I would think it
was a really cool feature.  That is, if the titlebar always moved to
where it was visible.  But the fact that you have to move the titlebar
*before* doing anything else just slows things down.

Besides, that's another geek feature.  New users won't know anything
about it.

> > Also, the BeOS style titlebars do a terrible job of Fitts law :-)
> 
> You seem to be a great lover of fitts "law" ;-)

Yes.  You are not?
 
> Please try to use that style some time before saying its doing a terrible
> job, if your statements are true and if any law is applicable here. Or
> simply say what your prefered style is, without bashing others.

*sigh*

I used B II extensively for a while back.. but it was simply to
inconvenient to keep using.  And my email was in response to the
suggestion that B II be the new default... my opinion on my preferred
style is secondary to the fact that I think that B II should NOT be
the default.

In other words, the entire point of my email was to "bash" B II, not
to promote my favorites.

For the record, I think *any* of the other styles should be preferred
as the default over B II.

> > Laptop should have a smaller size grip (like the size of
> > MondernSystem) and should allow you to resize the window on all of the
> 
> I think mosfet designed it in this way, because it's a _laptop_ style,
> where this large handle makes sense.
 
Yes, I know the rationale.  I don't "get" it personally, since I use a
laptop for 99% of my work (I'm on it now) and I've never needed a
bigger size grip or longer buttons or anything.  Whatever.  I like
laptop as it's a cool looking style.
-- 
Kurt Granroth            | http://www.granroth.org
KDE Developer/Evangelist | SuSE Labs Open Source Developer
granroth@kde.org         | granroth@suse.com
           KDE -- Putting a Friendly Face on Unix

[prev in list] [next in list] [prev in thread] [next in thread]