From kwin Sat May 18 12:07:13 2002 From: Roland Seuhs Date: Sat, 18 May 2002 12:07:13 +0000 To: kwin Subject: [Kwin] Re: kwin - Window placement X-MARC-Message: https://marc.info/?l=kwin&m=102172374608225 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.= =20 (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 win= dows=20 currently on this desktop, to make an educated guess at where the next wi= ndow=20 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 the= m. - even if some users don't request/want some feature, they may like it wh= en=20 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 a= s > > they are both predictable and useful. > > I don't want to be rude, but any placement policy that stacks windows a= t > 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 u= ser=20 wants them, which is very unlikely. In most cases the user will have to m= ove=20 the window to a preferred position before working with it, and having the= =20 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=20 advantage. You also assume that windows don't overlap and you can work with several=20 windows at a time, which is also wrong for most resolutions today with sm= art=20 behaviour and always wrong with "cascaded". I *CAN* work with serveral windows on the same desktop at the same time, = but=20 rearranging windows is *ALWAYS* required for it, so the so-called smart=20 placement *NEVER* helps me doing it because I have to rearrange anyway, s= o=20 they overlap the right way. Also, I like to cycle through windows with the middle mouse button. (The=20 middle mouse button puts the top window in the background, so the next wi= ndow=20 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=20 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=20 Windows nobody will consider it useful." > > So I write you this mail so that you know he's not the only one unhap= py > > 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 anot= her > important duty: to make sure that the application doesn't become a > collection of functionalities useful each only for a minimum number of > users.=20 I've got 2 points against that: - First you ASSUME that only a minimum number of users would like this. Y= ou=20 could equally assume that a lot of users want this feature and/or a lot w= ould=20 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. E= very=20 user is different and is likely to have the "minorities" tastes/needs in = one=20 app or another. As an example look at MS Word. It includes thousands of features "nobody"= (by=20 your standards) uses. However, if you remove all those features you would= =20 lose a lot of users because all those small groups that use the different= =20 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 st= ill=20 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=20 "easyness". The completely retarded moron, that everybody seems to use as a model for= the=20 average user (which I strongly disagree on, I see completely retarded cle= arly=20 BELOW average and not worth targetting at, but that's another thread), ju= st=20 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 th= em=20 bloat, this is not an often used dialogue. You usually set your preferred= =20 behaviour only once, if at all. By default it is set to "smart". You say that "smart" puts the window whe= re=20 the user wants it (no moving required), which is IMPOSSIBLE with both cas= cade=20 and random. So if what you say were true, all users would just happily us= e=20 the default and never feel the urge to change the window placement policy= ,=20 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= =20 "random", which both don't fullfill the requirements (working with severa= l=20 windows at the same time using the windows as they popped up - everything= =20 else is braindead) you have. So essentially your point is that "smart" is perfect and that nobody want= s to=20 change it anyway.=20 But yet at the same time you complain that the change dialogue would get = too=20 crowded if there are more options, which is IRRELEVANT because you alread= y=20 assume that nobody wants to move away from "smart", so nobody would need = the=20 change dialogue anyway, so no matter how bloated it would become, it woul= d=20 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 yo= u=20 assume (without any proof) is small.=20 This makes me actually very sad. I would have never guessed that I would = read=20 something like this on a KDE-list :-( A lot of projects get this attitude after some time, but KDE is only 5 ye= ars=20 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=20 only one window on the desktop, at least I have absolutely no idea where = it=20 will open when there are already 4 or more windows on that desktop. If yo= u=20 still know where the next window will popup within a second (otherwise, I= =20 think you will agree, it's completely useless.) more power to you, but yo= u=20 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=20 law) and can move it whereever I want it or just leave it there and cycle= =20 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=20 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=20 kde-users or on some other list) to test the feature and if they want it=20 removed or not. You say for yourself that it doesn't do any harm, so having it in 2=20 KDE-releases shouldn't be that much of a problem. OK? Roland --=20 Writing about music is like dancing about architecture. -- Frank Zappa _______________________________________________ Kwin mailing list Kwin@mail.kde.org http://mail.kde.org/mailman/listinfo/kwin