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

List:       kwin
Subject:    [Kwin] Re: kwin - Window placement
From:       Roland Seuhs <roland () hasos ! com>
Date:       2002-05-18 12:07:13
[Download RAW message or body]

Am Samstag, 18. Mai 2002 03:39 schrieb Cristian Tibirna:
> On Friday, 17 May 2002 13:48, Roland Seuhs wrote:
> > The problems with all 3 currently available policies are discussed in the
> > usability-thread; Summarized, the main problem I have is that all 3
> > policies feel random, that means you never know where the next window
> > will appear.
>
> It is your personal feeling.

It's a fact.

For "cascade" you would have to memorize where the last window popped up. 
(Still the window can be too big and pop up at the top-left corner)

For "smart" you would have to memorize the positions and sizes of ALL windows 
currently on this desktop, to make an educated guess at where the next window 
will appear.

I can't and don't want to memorize window positions.

> You and Shane are the only two users that
> complained in 5 years of existance of the smart placement.

That's maybe true, but

- you don't know how many % of users want some feature unless you ask them.
- even if some users don't request/want some feature, they may like it when 
they try it out.
- 2 users actively complaining on mailing-lists is actually quite a lot.

> > I think that both "centered" and "top-left" would be nice additions as
> > they are both predictable and useful.
>
> I don't want to be rude, but any placement policy that stacks windows at
> the same position on the desktop is brain-dead

So you are not rude, but call it brain-dead. That's nice.

> and a big step backwards
> from cascade or smart placement.

You assume that "smart" or "cascade" puts all windows exactly where the user 
wants them, which is very unlikely. In most cases the user will have to move 
the window to a preferred position before working with it, and having the 
window in a predictable place makes it easier to move it afterwards.

To put it in other words:

In the majority of cases having a window in a predictable position is an 
advantage.

You also assume that windows don't overlap and you can work with several 
windows at a time, which is also wrong for most resolutions today with smart 
behaviour and always wrong with "cascaded".

I *CAN* work with serveral windows on the same desktop at the same time, but 
rearranging windows is *ALWAYS* required for it, so the so-called smart 
placement *NEVER* helps me doing it because I have to rearrange anyway, so 
they overlap the right way.

Also, I like to cycle through windows with the middle mouse button. (The 
middle mouse button puts the top window in the background, so the next window 
appears, etc.) So I regularily end up moving the windows to the top.
If you know a faster and more convenient method of cycle through windows, let 
me know.

> Not even windows or dos or mac, [..]

You would change your mind if Windows includes this feature?

I did not know that, maybe we should add to the FAQ:

"Please send all feature requests for KDE to Microsoft. Unless a feature is in 
Windows nobody will consider it useful."

> > So I write you this mail so that you know he's not the only one unhappy
> > about the currently available policies.
> > Since added policies don't disturb or remove any other features, it
> > should hurt nobody.
> >
> > Is applying the patch OK with you?
>
> No, it is not OK with me.
>
> As a maintainer of a free software project, I have a duty to the users and
> the fellow developers, especially when they submit patches, to pay
> attention to (and include) the features or functionalities they want.
>
> As you very well observe, adding this (dis)functionality in kwin wouldn't
> probably hurt anybody too much.
>
> Problem is, again as a maintainer of free software project, I have another
> important duty: to make sure that the application doesn't become a
> collection of functionalities useful each only for a minimum number of
> users. 

I've got 2 points against that:

- First you ASSUME that only a minimum number of users would like this. You 
could equally assume that a lot of users want this feature and/or a lot would 
like it when they try it out. Fact is that we both don't know.

- Secondly, it is important to take care of small groups of users, too. Every 
user is different and is likely to have the "minorities" tastes/needs in one 
app or another.
As an example look at MS Word. It includes thousands of features "nobody" (by 
your standards) uses. However, if you remove all those features you would 
lose a lot of users because all those small groups that use the different 
features add up to a lot.

> We can't afford to bloat applications in order to introduce barely
> used features. We usually consider that at this point competition
> intervenes.
> I'm sure you could find a window manager (other than kwin) that
> offers the kind of window placement you require. If you don't then you
> might want to think there is a problem with your requirement.

Not to be rude myself, but if everybody would think that way, we would still 
be in the stone-age.

Innovation and progress is impossible without "doing things differently".

> And yes, adding many features rarely used _do_ hurt other users. In the
> specific case of window placement, adding the new policies to the combo-box
> would be required (in kcontrol) and this will add more to the already
> confusing over-configurability of KDE, a thing that is very often
> criticized.

Yes, by anti-Linux Newsgroup trolls, this is criticized.

But fact is that you don't have to configure that to run KDE, so it can't hurt 
"easyness".

The completely retarded moron, that everybody seems to use as a model for the 
average user (which I strongly disagree on, I see completely retarded clearly 
BELOW average and not worth targetting at, but that's another thread), just 
uses the default AND NEVER KNOWS that there are different ways to do it.

So having this option doesn't make KDE any "harder".

While I agree on optimizing often used dialogues and menus and not let them 
bloat, this is not an often used dialogue. You usually set your preferred 
behaviour only once, if at all.

By default it is set to "smart". You say that "smart" puts the window where 
the user wants it (no moving required), which is IMPOSSIBLE with both cascade 
and random. So if what you say were true, all users would just happily use 
the default and never feel the urge to change the window placement policy, 
therefore would never be harmed by the "bloat" of too many options.

If somebody is unhappy about "smart" he has only 2 options: "cascade" and 
"random", which both don't fullfill the requirements (working with several 
windows at the same time using the windows as they popped up - everything 
else is braindead) you have.

So essentially your point is that "smart" is perfect and that nobody wants to 
change it anyway. 

But yet at the same time you complain that the change dialogue would get too 
crowded if there are more options, which is IRRELEVANT because you already 
assume that nobody wants to move away from "smart", so nobody would need the 
change dialogue anyway, so no matter how bloated it would become, it would 
not matter because nobody would see it.

> I, nevertheless, am open for discussion. If other arguments, by other
> people, or by you, will be brought in favor of adding these
> functionalities, I will reconsider.

Hopefully.

> Two notes:
> 1) random placement is there by tradition.

So tradition is more important than the needs of a group of users that you 
assume (without any proof) is small. 

This makes me actually very sad. I would have never guessed that I would read 
something like this on a KDE-list :-(
A lot of projects get this attitude after some time, but KDE is only 5 years 
old and should still be open for new ideas.

> the father of all window
> managers (twm) offered it, I think. I would really be very surprised to
> find out there is even 1% of kwin users that choose this policy.

Me too.

> 2) smart placement is _very_ far from being random. I can predict with a
> probability of 99% where the next window will end up.

Well, I can't.
While it's possible to maybe guess where the window will open when there is 
only one window on the desktop, at least I have absolutely no idea where it 
will open when there are already 4 or more windows on that desktop. If you 
still know where the next window will popup within a second (otherwise, I 
think you will agree, it's completely useless.) more power to you, but you 
know the code, most users don't.

With "top-left" I could find every window *BLIND*.
I just have to throw the mouse upwards to the border of the screen (Fitt's 
law) and can move it whereever I want it or just leave it there and cycle 
through windows with the middle mouse button.

> That is, there where
> this new window will obscure the least of the other windows already
> existing on the desktop, or, if enough free space is available, in the
> left-uppermost free location that can accomodate that window. And, btw, why
> is it needed for the users to predict where a window will end up?

Because in most cases users will have to move it somewhere anyway, or in case 
of MMB-cycling want to have it stacked.

Let's do a compromise:

Add "top-left" and "center" for KDE 3.0.1 and 3.1.0, then ask the users (on 
kde-users or on some other list) to test the feature and if they want it 
removed or not.

You say for yourself that it doesn't do any harm, so having it in 2 
KDE-releases shouldn't be that much of a problem.

OK?

Roland

-- 
Writing about music is like dancing about architecture.
                -- Frank Zappa


_______________________________________________
Kwin mailing list
Kwin@mail.kde.org
http://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]