kdebase/konqueror

[Datschge]

On Thursday 01 April 2004 11:51, Frans Englich wrote:
> (Replying two similar threads on kfm-devel and kde-usability)
> But that did not bring any new, I could do the same, playing a
> little game:

You are not playing games, you are being childish while you are 
introducing inconsistencies into terminologies you apparently don't 
(want to) understand at all.

> "A window(which can be removed) is not necessarily the same as a
> view(which can be closed), the former makes space for whatever
> other windows is there, the latter disappears completely."
> (and it sounds just as sensible)

If you are serious with this ridiculing of the used metaphor I suggest 
you to no longer commit any changes of terms in the name of usability 
anymore since in that case it's quite apparent that you are either 
not aware of or don't care about the relationship between the used 
metaphors and the thus consequential terms.

> I committed for consistency. A view is just as a tab or window a
> widget/"a thing" which contains stuff(a window). Since it acts and
> is treated as a window it makes sense to use the same word.

While (especially with kmdi) the difference between windows and tabs 
is blurring the definition of view is still that it's a subset of any 
window or tab, i.e. a window or a tab can contain many views at once, 
and adding and removing them doesn't change the nature of the window 
or tab itself. Closing the window or tab however removes all 
contained views at once.

> (In either way, I'm not going to have an endless discussion over
> this. Just do a decision, kfm people)

I'd prefer you to do the discussion and decision finding before 
committing changes instead showing off yourself being reluctant of 
doing that even afterward. How about just attaching your proposed 
changes as patches instead possibly alienating everyone responsible 
for the code you "dare" to touch?

> I just find it excessive. If not "Close View" close the active view
> what does it then close?(An arbitrary view? :) Since nothing else
> make sense I think an implicit agreement works.

Again, a view is removed, not closed. If it were to behave similar 
like closing windows or tab the area of the "close" view would have 
to show whatever is behind it. But it doesn't behave that way, if 
there are multiple views other view take over the space freed up by 
removing the view. The act of "closing" is a metaphor different from 
the act of "removing". If you pretend both to be the same you are 
forcing more confusion than the current state with two different 
terms for two different behaviors, this is not at all better 
usability.

> OTOH, main menus are not context based as RMBs are. That's why
> there's various "... Current Tab".
> I suggest we do either
>
> A: s/View/Current/(consistency with tabs) and also add "Current" to
> the split actions.
> or
> B: Remove all occurrences of "View" and "Current"(view and tab
> actions).

Again, views and tabs are not the same. For tabs and windows the 
current, topmost tab/window is usually clear. For views which don't 
work in a top down leveling topology like tabs and windows do this is 
not true: multiple views can be visible next to each other at the 
same time on a flat level, with an additional indicator which shows 
which one of the views is the active one. Different terms for 
different behaviors.

> Yes, such things occurs as a mystery to so many people. I got some
> usability docs coming up on that and I rather prefer to explain it
> once for all then.

Care to refer to the usability doc instead keeping it a mystery to us? 
How about preferring to first explain changes to us before committing 
them in the future?