Summary of NWI -- the page

[macias]

Hi,

  I don't like big steps, so for now only the creation of the page
itself:
http://techbase.kde.org/Projects/Usability/NWI

  Just to test if I will be killed by some admin ;-D

  Of course I intend to add content to the page, but as I wrote, I
will do it rather slowly, to avoid mistakes, and to clear my head.

Cheers,

PS. Please set the page as watched one (and write too at any time of
course, as you like).
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:
> http://techbase.kde.org/Projects/Usability/NWI

I've now done a proofreading pass as well as some (hopefully
non-controversial :-) ) changes. You probably want to check the diffs
and/or re-read the page.

I've added some possible discussion points as green text, following the
convention in the FAI summary. I've also replaced "application" with
"window" in a number of places. Maybe I'm being technically pedantic
(i.e. imposing correct-as-according-to-a-coder), but to me "application"
is a synonym either for "process" or "binary" (and in this case, more
the latter than the former), both of which are supersets of "window". Of
course, one of the goals of NWI is to make "process" much closer to a
synonym for "window" :-). (Especially for Konsole, which IMO most
desperately needs it.)

> You can configure each container type (+ desktop separately) to show
> shared menu per whole container — menu of the active application
> pane. Shared menu goes "up" as it can (as far container accepts
> shared menu).

Parse error :-). (IOW I didn't understand what this sentence is supposed
to mean.)

Hmm, and we should probably write a glossary :-).

> The task bar shows the first-class windows ...

I changed the stuff about "first-class windows" quite a bit. It's more
technical but also more correct (and I'm not much on the term
"first-class window" :-) ). Is this okay or should we try for better
wording?

Aaaand... should containers every group in the task bar? If so, how?

> Arranging windows as container

Okay, I'd have to go digging for the discussion on this. You list
'select windows' and 'create group' as separate steps; is there a reason
not to combine them?

> Please note that moving embedded windows within a container and
> tearing them off are two distinct actions

Okay, I think I hate that ;-). I don't think it is important except for
FAI, and if we say you can't move window outside visible area, is it
even needed? (I'd be fine if the distinction was 'cursor must be outside
container border by at least X pixels'.)

> Default options for non-FAI containers:

I have some comments here, need to re-check the thread. More later.
(Hopefully not too /much/ later ;-).)

> Closing a entire container means each application quits, not just
> closes its "pane".

This to me makes no sense. How would you enforce it? Why should it be
any different from closing all windows in the container? (I don't get
the systray example either. Right now I have kopete; if I close the
contact list, kopete is still running. Why should this change if the
contact list is in an NWI container?)

> Default key bindings > Adding applications

Konsole will hate you for 'hollow'. Actually, none of these can be
global keys, but I think they need application support anyway, so it's a
moot point for 'empty copy' and 'duplicate'. Why does dragging need
ctrl? If it is a WM handle (i.e. tab, title bar), why do I need ctrl? If
I want it to work anywhere, why not use alt+LMB which is the current
binding?

> why [meta] couldn't be mod key

Did I ever say it couldn't? If so, don't know what I was thinking. It
can be any key X allows to be used as a modifier. (I'd even say allow
ctrl/shift; or is putting a safety on the gun that important? ;-) )
Anyway, wiki updated accordingly.

> Keyboard shortcut actions (switching, under exchange)

Need separate mail for this also.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"Please remain calm... I may be mad, but I am a professional."
   -- Mad Scientist (actual author unknown)

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Matthew Woehlke wrote:
> Maciej Pilichowski wrote:
>> http://techbase.kde.org/Projects/Usability/NWI
>> Default options for non-FAI containers:
>
> I have some comments here, need to re-check the thread. More later.
> (Hopefully not too /much/ later ;-).)

Oy. On re-reading the thread, I think the problem here is just that
"app" is really confusing (unfortunately) in this context :-(.

I rewrote this in a way that I can understand it; I don't think I
changed any of your intent (with one exception), but...

The one change I did make is to remove the "not-FAI" part. Any reason
FAI should behave differently? (Do we need this configurable
per-container? I think my preference is to not do that.)

Okay... from a technical standpoint the WM and app have to cooperate for
'close document' (it may be possible for the WM to accept the key combo
and decide if it should send the app a close document or close window
signal, which would be ideal; better integration with non-KDE apps, less
  app code needs to change), but then ctrl-w can't be used :-(. I think
I'd rather have something like win-w for WM and NWI-integrated apps can
still use ctrl-w (and non-well-integrated just ignore the NWI options
what to do on ctrl-w).

What about quit app? I rewrote it as almost 'killall <app name>'.
Currently it's up to the app to implement this, but come to think of it,
it may be possible for the WM to do it, which might make it more
consistent (but I think wouldn't actually quit apps that don't go away
when all their windows are closed, e.g. systray apps). I think it might
be better to declare this out of scope of the WM.

>> [ ] closing document closes "its" application if there are sibling
>> instances of that application within the container<br>

Okay... this makes no sense. Why would I want the application to quit
because I have more than one window open? I can't figure out any way to
interpret this that isn't confusing and/or unexpected/undesired.

>> * close topmost container (not counting desktop)

Isn't that "log off"? ;-)

(Sorry, couldn't resist.)

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"Please remain calm... I may be mad, but I am a professional."
   -- Mad Scientist (actual author unknown)

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Saturday 16 May 2009 03:21:24 Matthew Woehlke wrote:

> I've now done a proofreading pass as well as some (hopefully
> non-controversial :-) ) changes. You probably want to check the
> diffs and/or re-read the page.

Sure, thanks.

> I've added some possible discussion points as green text, following
> the convention in the FAI summary. I've also replaced "application"
> with "window" in a number of places. Maybe I'm being technically
> pedantic (i.e. imposing correct-as-according-to-a-coder), but to me
> "application" is a synonym either for "process" or "binary" (and in
> this case, more the latter than the former), both of which are
> supersets of "window". Of course, one of the goals of NWI is to
> make "process" much closer to a synonym for "window" :-).
> (Especially for Konsole, which IMO most desperately needs it.)

I was focusing on adding all information from ML to summary, thus the
terminology mess :-))

> > You can configure each container type (+ desktop separately) to
> > show shared menu per whole container — menu of the active
> > application pane. Shared menu goes "up" as it can (as far
> > container accepts shared menu).
>
> Parse error :-). (IOW I didn't understand what this sentence is
> supposed to mean.)

Remember the discussion if the menu in GAI should be shown per each
pane or only single menu for entire container (shared menu)? The
latter means, the menu goes from pane to container. But since
container can be pane, it goes "up" again, if the parent-container
has also shared menu.

> Hmm, and we should probably write a glossary :-).

Added section, I add some content there later.

> > The task bar shows the first-class windows ...
>
> I changed the stuff about "first-class windows" quite a bit. It's
> more technical but also more correct (and I'm not much on the term
> "first-class window" :-) ). Is this okay or should we try for
> better wording?

Yes, it is much better. I only have problem with my English "be they
leaves or containers", is this really correct? I know what it means,
because I know what we talk about.

> Aaaand... should containers every group in the task bar? If so,
> how?

You mean -- should containers _list_ every group? Every = every direct
desktop child? For me, yes. Normally. Every = every group. In
submenu, in submenu of the submenu etc. So it would reflect the
hierarchy.

> > Arranging windows as container
>
> Okay, I'd have to go digging for the discussion on this. You list
> 'select windows' and 'create group' as separate steps; is there a
> reason not to combine them?

a) "combine" means -- with every selected window it is immediately
groupped, if yes, we discussed this and you agreed that two modes are
possible, this one (not combined) and combined (incrementally
adding).
b) if yes -- this workflow, select and then group, lets user work in
his/her own pace, think about windows, _de_select something (very
easily done)

> > Please note that moving embedded windows within a container and
> > tearing them off are two distinct actions
>
> Okay, I think I hate that ;-). I don't think it is important except
> for FAI, and if we say you can't move window outside visible area,
> is it even needed? (I'd be fine if the distinction was 'cursor must
> be outside container border by at least X pixels'.)

It is safer for the user if she/he wants to move, not tear. With such
difference you can move outside and the window still be moved -- this
means we have infinitive space (see Mac menu case), which is good
because you can safely (more safely) arrange the container.

So if you really hate it I would suggest option, because not that I
hate opposite, but I work too many hours at computer and I appreciate
UI safety (doing X I like to do it safely, and when I do Y, I would
like to make explicit action for Y).

> > Default options for non-FAI containers:
>
> I have some comments here, need to re-check the thread. More later.
> (Hopefully not too /much/ later ;-).)

ok :-)

> > Closing a entire container means each application quits, not just
> > closes its "pane".
>
> This to me makes no sense. How would you enforce it? Why should it
> be any different from closing all windows in the container? (I
> don't get the systray example either. Right now I have kopete; if I
> close the contact list, kopete is still running. Why should this
> change if the contact list is in an NWI container?)

I don't use Kontact and what you said is for me quite surprising. Here
is the principle of the least surprise. I put into GAI let's say 17
applications. I close then entire GAI and all of the sudden (for me)
10 of them were closed as I would expect but 7 of them kept running.
This means:
* 7 of them were not closed (quit) -- surprising
* 7 of them were automatically tear off despite I didn't say anything
anything about tearing off -- surprising

Grouping meant to "act as one". It is hard to think of a group if on
close each app is on its own.

After all closing container means closing _parent_. Why child should
survive?

To extreme you can think of grouping all systray apps (no other kind),
closing container which lead to just ungrouping.

> > Default key bindings > Adding applications
>
> Konsole will hate you for 'hollow'.

:-) This is just a suggestion rather, not a final version :-D.

> Why does
> dragging need ctrl? If it is a WM handle (i.e. tab, title bar), why
> do I need ctrl? If I want it to work anywhere, why not use alt+LMB
> which is the current binding?

You mean alt+LMB should be direct dragging? Current binding of alt
means resize.

Direct dragging (not just dragging) requires some mod key to make the
difference between just dragging (moving).

> > why [meta] couldn't be mod key
>
> Did I ever say it couldn't? If so, don't know what I was thinking.
> It can be any key X allows to be used as a modifier. (I'd even say
> allow ctrl/shift; or is putting a safety on the gun that important?
> ;-) ) Anyway, wiki updated accordingly.

I was unsure that's why I was asking, you have much greater expertise
so it is safer to ask :-)

> > Keyboard shortcut actions (switching, under exchange)
>
> Need separate mail for this also.

Ok :-).

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Saturday 16 May 2009 04:04:11 Matthew Woehlke wrote:

> Matthew Woehlke wrote:
> > Maciej Pilichowski wrote:
> >> http://techbase.kde.org/Projects/Usability/NWI
> >> Default options for non-FAI containers:
> >
> > I have some comments here, need to re-check the thread. More
> > later. (Hopefully not too /much/ later ;-).)
>
> Oy. On re-reading the thread, I think the problem here is just that
> "app" is really confusing (unfortunately) in this context :-(.
>
> I rewrote this in a way that I can understand it; I don't think I
> changed any of your intent (with one exception), but...
>
> The one change I did make is to remove the "not-FAI" part. Any
> reason FAI should behave differently? (Do we need this configurable
> per-container? I think my preference is to not do that.)

I cannot tell because I didn't find any reference to "default options
for non-FAI containers" phrase or any similar. The only similar
section is about SAI not FAI, and it is justified because SAI is not
container per se, and those options does not make any sense for SAI.

> Okay... from a technical standpoint the WM and app have to
> cooperate for 'close document' (it may be possible for the WM to
> accept the key combo and decide if it should send the app a close
> document or close window signal, which would be ideal; better
> integration with non-KDE apps, less app code needs to change), but
> then ctrl-w can't be used :-(.

Why?

> What about quit app? I rewrote it as almost 'killall <app name>'.

Ok.

> Currently it's up to the app to implement this, but come to think
> of it, it may be possible for the WM to do it, which might make it
> more consistent (but I think wouldn't actually quit apps that don't
> go away when all their windows are closed, e.g. systray apps).

But you can close such app (and then it stays), quit means quit (like
today).

> >> [ ] closing document closes "its" application if there are
> >> sibling instances of that application within the container<br>
>
> Okay... this makes no sense. Why would I want the application to
> quit because I have more than one window open?

:-DDDDDDDDDDDDD It is your idea, so I assumed you have a reason for
such behaviour :-))))))))) I only understood it as a gesture for Mac
users.

About month ago you wrote:
"What about a policy that close doc will close the application also if
there are sibling instances of that app? I think I would be okay
implementing it that way."

Since you confirmed it should be an option I added it as an
option :-)) So... should I remove it?

> >> * close topmost container (not counting desktop)
>
> Isn't that "log off"? ;-)
> (Sorry, couldn't resist.)

:-)))) Yes it is, that's why it is not counting desktop :-)))

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:

> On Saturday 16 May 2009 03:21:24 Matthew Woehlke wrote:
>>> You can configure each container type (+ desktop separately) to
>>> show shared menu per whole container — menu of the active
>>> application pane. Shared menu goes "up" as it can (as far
>>> container accepts shared menu).
>> Parse error :-). (IOW I didn't understand what this sentence is
>> supposed to mean.)
>
> Remember the discussion if the menu in GAI should be shown per each
> pane or only single menu for entire container (shared menu)? The
> latter means, the menu goes from pane to container. But since
> container can be pane, it goes "up" again, if the parent-container
> has also shared menu.

Ah, yes, much better; thanks.

/me makes note to re-write this part of the wiki into something
understandable, if you don't do it first

>>> The task bar shows the first-class windows ...
>> I changed the stuff about "first-class windows" quite a bit. It's
>> more technical but also more correct (and I'm not much on the term
>> "first-class window" :-) ). Is this okay or should we try for
>> better wording?
>
> Yes, it is much better. I only have problem with my English "be they
> leaves or containers", is this really correct? I know what it means,
> because I know what we talk about.

Well, I think it does, but I also don't have a doctorate in English, so
what do I know? ;-)

Looking again, it's a bit obtuse. I'll reword it if I think of something
better, or let me know if you have ideas.

>
>> Aaaand... should containers every group in the task bar? If so,
>> how?
>
> You mean [snip]

Oops, no, that should have been "ever". Should the panel be permitted to
collapse what would otherwise be multiple top-level entries when those
entries are containers? If so, what criteria would make sense for
deciding what to merge?

Right now it's easy; same application is merged. For containers, is
hard; do you merge all TDI containers? Only containers with "similar"
contents? (How do you define "similar"?)

>>> Arranging windows as container
>> Okay, I'd have to go digging for the discussion on this. You list
>> 'select windows' and 'create group' as separate steps; is there a
>> reason not to combine them?
>
> a) "combine" means -- with every selected window it is immediately
> groupped, if yes, we discussed this and you agreed that two modes are
> possible, this one (not combined) and combined (incrementally
> adding).

Wait, did the text change or was I smoking something when I wrote that? ;-)

Let me try again. Do we need a context menu step to say "done selecting
windows", or can we do this:

- decide to create a {T,F,G}AI container
- select windows mode started by previous action
- select windows as described
- click 'okay' button in corner of screen or hit enter*
- container is created with windows

(* ...or anything else that doesn't involve a popup menu ;-); the fewer
keys/clicks, the better.)

It wasn't my intent to imply I don't like the selection method; sorry
for that.

>>> Please note that moving embedded windows within a container and
>>> tearing them off are two distinct actions
>> Okay, I think I hate that ;-). I don't think it is important except
>> for FAI, and if we say you can't move window outside visible area,
>> is it even needed? (I'd be fine if the distinction was 'cursor must
>> be outside container border by at least X pixels'.)
>
> It is safer for the user if she/he wants to move, not tear. With such
> difference you can move outside and the window still be moved -- this
> means we have infinitive space (see Mac menu case), which is good
> because you can safely (more safely) arrange the container.
>
> So if you really hate it I would suggest option, because not that I
> hate opposite, but I work too many hours at computer and I appreciate
> UI safety (doing X I like to do it safely, and when I do Y, I would
> like to make explicit action for Y).

Okay. Option is fine, I can understand wanting tearing to be more
explicit. (Personally I want it to be less effort :-).)

>>> Closing a entire container means each application quits, not just
>>> closes its "pane".
>> This to me makes no sense. How would you enforce it? Why should it
>> be any different from closing all windows in the container? (I
>> don't get the systray example either. Right now I have kopete; if I
>> close the contact list, kopete is still running. Why should this
>> change if the contact list is in an NWI container?)
>
> I don't use Kontact and what you said is for me quite surprising. Here
> is the principle of the least surprise. I put into GAI let's say 17
> applications. I close then entire GAI and all of the sudden (for me)
> 10 of them were closed as I would expect but 7 of them kept running.
> This means:
> * 7 of them were not closed (quit) -- surprising

Well, complain to Kontact, but I don't think at the WM level we should
be trying to change what happens when you close a window ;-). Anyway,
there is no change here from how things work at present.

> * 7 of them were automatically tear off despite I didn't say anything
> anything about tearing off -- surprising

Ah... no? The windows close, there is no "tearing off" (which I agree,
would be very surprising). Apps that run without any windows (e.g.
Kontact, KMixer, also I think Amarok) will still be running.

Also, apps with windows in other containers will still be running. Why
shouldn't they?

> To extreme you can think of grouping all systray apps (no other kind),
> closing container which lead to just ungrouping.

Well... yes? (But the windows are closed.)

I suppose it would be good if we could remember if windows should be in
a container, same way we remember e.g. if they should be maximized, but
that problem exists regardless.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"For UNIX thou art, and to UNIX thou shalt return"
The voice of Freedom speaks to the Internet

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:

> On Saturday 16 May 2009 04:04:11 Matthew Woehlke wrote:
>> Maciej Pilichowski wrote:
>>> [ ] closing document closes "its" application if there are
>>> sibling instances of that application within the container<br>
>>
>> Okay... this makes no sense. Why would I want the application to
>> quit because I have more than one window open?
>
> :-DDDDDDDDDDDDD It is your idea, so I assumed you have a reason for
> such behaviour :-))))))))) I only understood it as a gesture for Mac
> users.

That was my idea? I thought the options you have ticked as default...

> About month ago you wrote:
> "What about a policy that close doc will close the application also if
> there are sibling instances of that app? I think I would be okay
> implementing it that way."

...are what this is talking about. I am confused :-).

Maybe an example will help. Let's say I have four kwrite windows in TAI,
two each belonging to one process (which is something that should stop
IMO, but for now we'll use this as the example). Call them A, B, C, D,
with {A, B} belonging to process 1, and {C, D} belonging to process 2.

I do 'close document' to A. For the three possible options, what
happens? What would happen if B, C, D were in a different container?

As I read it currently...

A, B, C, D in container:
1 - process 1 is exited; A and B windows close
2 - not last instance, so window A is closed
3 - same as 2

A only window in container:
1 - document is closed, don't know what happens to window???
2 - action is denied
3 - document is closed, leaving "empty application"*

(I'm numbering the options as they are in the wiki, so 1 is the one
quoted above, and the default is 3.)

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"For UNIX thou art, and to UNIX thou shalt return"
The voice of Freedom speaks to the Internet

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:

> On Saturday 16 May 2009 04:04:11 Matthew Woehlke wrote:
>> Matthew Woehlke wrote:
>>> Maciej Pilichowski wrote:
>>>> http://techbase.kde.org/Projects/Usability/NWI
>>>> Default options for non-FAI containers:
>>> I have some comments here, need to re-check the thread. More
>>> later. (Hopefully not too /much/ later ;-).)
>> Oy. On re-reading the thread, I think the problem here is just that
>> "app" is really confusing (unfortunately) in this context :-(.
>>
>> I rewrote this in a way that I can understand it; I don't think I
>> changed any of your intent (with one exception), but...
>>
>> The one change I did make is to remove the "not-FAI" part. Any
>> reason FAI should behave differently? (Do we need this configurable
>> per-container? I think my preference is to not do that.)
>
> I cannot tell because I didn't find any reference to "default options
> for non-FAI containers" phrase or any similar. The only similar
> section is about SAI not FAI, and it is justified because SAI is not
> container per se, and those options does not make any sense for SAI.

Maybe that's why I am confused. There really isn't even such thing as
SAI, you're just talking about only one window. (I've been reading SAI
as being more-or-less FAI.)

Well, right now the only "SAI" reference is at the beginning. From my
end, the current wording is okay.

>> Okay... from a technical standpoint the WM and app have to
>> cooperate for 'close document' (it may be possible for the WM to
>> accept the key combo and decide if it should send the app a close
>> document or close window signal, which would be ideal; better
>> integration with non-KDE apps, less app code needs to change), but
>> then ctrl-w can't be used :-(.
>
> Why?

ctrl-<anything> can't be used as global shortcuts; they break terminal
emulators. You must either implement it at application level and let the
application work with the WM, or else add another modifier.

The reason you need the app to cooperate is because otherwise the best
the WM can do when you /don't/ want to close the window is push a
predefined key combination to the app's event queue and hope for the best.

>> Currently it's up to the app to implement this, but come to think
>> of it, it may be possible for the WM to do it, which might make it
>> more consistent (but I think wouldn't actually quit apps that don't
>> go away when all their windows are closed, e.g. systray apps).
>
> But you can close such app (and then it stays), quit means quit (like
> today).

What I mean is there is no way for the WM to get an app to quit; the
best the WM can manage is tell all the app's windows to close (which
doesn't necessarily play nicely with apps that do their own session
management - i.e. Firefox). For "quit" to work, it really needs to be
handled by the app, not the WM.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"For UNIX thou art, and to UNIX thou shalt return"
The voice of Freedom speaks to the Internet

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Monday 18 May 2009 20:18:07 Matthew Woehlke wrote:

> Maciej Pilichowski wrote:
> > On Saturday 16 May 2009 04:04:11 Matthew Woehlke wrote:
> >> Maciej Pilichowski wrote:
> >>> [ ] closing document closes "its" application if there are
> >>> sibling instances of that application within the container<br>
> >>
> >> Okay... this makes no sense. Why would I want the application to
> >> quit because I have more than one window open?
> >>
> > :-DDDDDDDDDDDDD It is your idea, so I assumed you have a reason
> > : for
> >
> > such behaviour :-))))))))) I only understood it as a gesture for
> > Mac users.
>
> That was my idea?

Yes.

> I thought the options you have ticked as
> default...

The option is your idea, the fact it is [ ] or [x] does not indicate
who invented it :-))

> > About month ago you wrote:
> > "What about a policy that close doc will close the application
> > also if there are sibling instances of that app? I think I would
> > be okay implementing it that way."
>
> ...are what this is talking about. I am confused :-).

I am confused about what you are confused. I get this option from your
mail, because I didn't want this feature be hardcoded :-) That's all.

> Maybe an example will help. Let's say I have four kwrite windows in
> TAI, two each belonging to one process

Wait, do we allow that one application instance (process) would have
several windows?

Maybe it is where confusion comes from. I would say no, because
otherwise the whole environment would become more complicated, and
from user POV it is hard to tell if the window A and B are from the
same or different processes.

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Monday 18 May 2009 20:19:13 Matthew Woehlke wrote:

> >> Okay... from a technical standpoint the WM and app have to
> >> cooperate for 'close document' (it may be possible for the WM to
> >> accept the key combo and decide if it should send the app a
> >> close document or close window signal, which would be ideal;
> >> better integration with non-KDE apps, less app code needs to
> >> change), but then ctrl-w can't be used :-(.
> >
> > Why?
>
> ctrl-<anything> can't be used as global shortcuts;

Like ctrl+c for copy?

> they break
> terminal emulators. You must either implement it at application
> level and let the application work with the WM, or else add another
> modifier.

I don't think WM should care about any app specific issues. It should
be quite in reverse -- app should provide means to make other use of
this or that shortcut.

Btw. I use Konsole all the time but I don't think it is _that_
important that shape of DE should be dependant of it. And to speak
more strictly -- it would be unwise to care about this or that app.
DE leads the way, apps follow.

> The reason you need the app to cooperate is because otherwise the
> best the WM can do when you /don't/ want to close the window is
> push a predefined key combination to the app's event queue and hope
> for the best.

That's right. App should cooperate. In games single ctrl is used to
fire, or something but it is not the reason we should not use ctrl
key at DE level.

Btw. ctrl+w is current default shortcut for document close.

> >> Currently it's up to the app to implement this, but come to
> >> think of it, it may be possible for the WM to do it, which might
> >> make it more consistent (but I think wouldn't actually quit apps
> >> that don't go away when all their windows are closed, e.g.
> >> systray apps).
> >
> > But you can close such app (and then it stays), quit means quit
> > (like today).
>
> What I mean is there is no way for the WM to get an app to quit;

Ok, but can WM _ask_ app to quit?
WM: please, quit
app: no
WM: ok, bye bye anyway, you are on your own

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Monday 18 May 2009 20:18:00 Matthew Woehlke wrote:

> >> Aaaand... should containers every group in the task bar? If so,
> >> how?
> >
> > You mean [snip]
>
> Oops, no, that should have been "ever". Should the panel be
> permitted to collapse what would otherwise be multiple top-level
> entries when those entries are containers? If so, what criteria
> would make sense for deciding what to merge?
>
> Right now it's easy; same application is merged. For containers, is
> hard; do you merge all TDI containers? Only containers with
> "similar" contents? (How do you define "similar"?)

Well, here I does not have opinion because I dislike merging, and I
think the need of doing it will vanish with NWI. After all what do
you need collapsed entry? Because you had a lot of instances of the
same app. But why did you have those? Because you couldn't group them
in the first place. So now you can group and as effect you get
taskbar collapse.

So personally I would remove such feature, but on the other hand can
we force users to use NWI? I think not. So auto-collapsing the same
entries should be possible.
( ) collapse SAI only
( ) collapse similar

similar(X1,X2) =

|X1 n X2|>=|X1 u X2 \ (X1 n X2)|

or

there is X3 such that similar(X1,X3) and similar(X2,X3)  

X1, X2, X3 -- sets (containers) of apps
n -- intersection
u -- sum

?

(Konqueror, Kpdf) is similar to (Konqueror, Kate)

but

(Konqueror, Kpdf, OOffice) is not similar to (Konqueror, Kate)

However I am just guessing, as I said I don't use collapsing, so I
don't "feel" it.

> >>> Arranging windows as container
> >>
> >> Okay, I'd have to go digging for the discussion on this. You
> >> list 'select windows' and 'create group' as separate steps; is
> >> there a reason not to combine them?
> >
> > a) "combine" means -- with every selected window it is
> > immediately groupped, if yes, we discussed this and you agreed
> > that two modes are possible, this one (not combined) and combined
> > (incrementally adding).
>
> Wait, did the text change or was I smoking something when I wrote
> that? ;-)

:-DDD

> Let me try again. Do we need a context menu step to say "done
> selecting windows", or can we do this:
>
> - decide to create a {T,F,G}AI container
> - select windows mode started by previous action
> - select windows as described
> - click 'okay' button in corner of screen or hit enter*
> - container is created with windows
>
> (* ...or anything else that doesn't involve a popup menu ;-); the
> fewer keys/clicks, the better.)

Nice, better! I change the summary accordingly.

> >>> Please note that moving embedded windows within a container and
> >>> tearing them off are two distinct actions
>
> Okay. Option is fine, I can understand wanting tearing to be more
> explicit. (Personally I want it to be less effort :-).)

Ok :-))) Option it is.

> >>> Closing a entire container means each application quits, not
> >>> just closes its "pane".
> >>
> >> This to me makes no sense. How would you enforce it? Why should
> >> it be any different from closing all windows in the container?
> >> (I don't get the systray example either. Right now I have
> >> kopete; if I close the contact list, kopete is still running.
> >> Why should this change if the contact list is in an NWI
> >> container?)
> >
> > I don't use Kontact and what you said is for me quite surprising.
> > Here is the principle of the least surprise. I put into GAI let's
> > say 17 applications. I close then entire GAI and all of the
> > sudden (for me) 10 of them were closed as I would expect but 7 of
> > them kept running. This means:
> > * 7 of them were not closed (quit) -- surprising
>
> Well, complain to Kontact, but I don't think at the WM level we
> should be trying to change what happens when you close a window
> ;-). Anyway, there is no change here from how things work at
> present.

I wrote whole long part of why apps should quite, or more precisely:
"
That's exactly my point -- WM should send "signal" quit. If you don't
send signal "quit" but only "close" how can app tell it was asked to
quit?
"

but! I think systray apps are "odd" anyway so, what the heck... after
container close regular applications quit, systray apps close their
windows (if configured so).

Ok?


Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:

> On Monday 18 May 2009 20:19:13 Matthew Woehlke wrote:
>>>> Okay... from a technical standpoint the WM and app have to
>>>> cooperate for 'close document' (it may be possible for the WM to
>>>> accept the key combo and decide if it should send the app a
>>>> close document or close window signal, which would be ideal;
>>>> better integration with non-KDE apps, less app code needs to
>>>> change), but then ctrl-w can't be used :-(.
>>> Why?
>> ctrl-<anything> can't be used as global shortcuts;
>
> Like ctrl+c for copy?

Yes. Konsole does not use ctrl-c (it uses ctrl-shift-c... and actually
it DOES use ctrl-c for 'send SIGINT', which is the point). ctrl-c is not
a global shortcut, it is an application shortcut. Note that I mean
"global" as in "accepted by a global daemon", not "shared by most
applications".

WM shortcuts are global in this sense because they are being intercepted
above the application level. Ergo, you can't use ctrl-<something> as a
WM shortcut (at least not as a default one... if people choose to shoot
their own feet, that's different).

> I don't think WM should care about any app specific issues. It should
> be quite in reverse -- app should provide means to make other use of
> this or that shortcut.

...except that you're going against something like 20 years of
established convention. You're also assuming that it's even /possible/
to change CLI applications to use something else. (The alternative is to
use ctrl-shift-c to cause Konsole to take the action as if you had
pressed ctrl-c... not good usability IMO.)

> Btw. I use Konsole all the time but I don't think it is _that_
> important that shape of DE should be dependant of it. And to speak
> more strictly -- it would be unwise to care about this or that app.
> DE leads the way, apps follow.

I suppose I disagree with you here. Besides, wasn't there a discussion a
while back on better separation of keyboard shortcut domains? I think
'ctrl' was on the 'for use by applications' list :-).

IMO the DE should try to avoid gratuitously breaking popular applications.

>> The reason you need the app to cooperate is because otherwise the
>> best the WM can do when you /don't/ want to close the window is
>> push a predefined key combination to the app's event queue and hope
>> for the best.
>
> That's right. App should cooperate. In games single ctrl is used to
> fire, or something but it is not the reason we should not use ctrl
> key at DE level.
>
> Btw. ctrl+w is current default shortcut for document close.

Right; an /application/ shortcut. We don't have problems now because
there are currently no global shortcuts (that I know of, anyway) that
use only ctrl.

>> What I mean is there is no way for the WM to get an app to quit;
>
> Ok, but can WM _ask_ app to quit?

It should be possible; it just means the app needs to handle such a
signal. Much is possible an an ideal world, I am just also considering
what will be the problems from adoption lag.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Here endeth the rant... which I realize is not likely to Win Friends or
Influence People, especially the person to whom it was directed.
   -- Charles Wilson (generalized)

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:

> On Monday 18 May 2009 20:18:07 Matthew Woehlke wrote:
>> Maciej Pilichowski wrote:
>> I thought the options you have ticked as
>> default...
>>
>>> About month ago you wrote:
>>> "What about a policy that close doc will close the application
>>> also if there are sibling instances of that app? I think I would
>>> be okay implementing it that way."
>> ...are what this is talking about. I am confused :-).
>
> I am confused about what you are confused. I get this option from your
> mail, because I didn't want this feature be hardcoded :-) That's all.
>
>> Maybe an example will help. Let's say I have four kwrite windows in
>> TAI, two each belonging to one process
>
> Wait, do we allow that one application instance (process) would have
> several windows?

Ideally, no :-). In reality, this already happens. Maybe that's the
problem, I am assuming "application instance" = process.

Okay... if I replace "application instance" with... hmm, "application
window" isn't a great term, but that idea anyway... then it makes a
little more sense, except now options 1 and 3 seem to be identical.

What would be the difference between the two?

Would this make more sense? Does it cover what options you are wanting
to provide?

When closing a document...
   ( ) Never close the window (application changes to "empty" state)
   (X) Close the window if there are sibling windows of the same
application type*.
     [X] Disallow closing the document if there are no such siblings.

* ...with tooltip explaining that 'same application type' does not
include any running on other machines, and probably a description of
what "application type" means


> Maybe it is where confusion comes from. I would say no, because
> otherwise the whole environment would become more complicated, and
> from user POV it is hard to tell if the window A and B are from the
> same or different processes.

It is preferable to hide this from the user as much as possible, yes.
Ideally by making the behavior consistent regardless of if two windows
belong to the same process or not.

This is why careful terminology is important ;-).

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Here endeth the rant... which I realize is not likely to Win Friends or
Influence People, especially the person to whom it was directed.
   -- Charles Wilson (generalized)

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Tuesday 19 May 2009 19:16:59 Matthew Woehlke wrote:

> > Wait, do we allow that one application instance (process) would
> > have several windows?
>
> Ideally, no :-). In reality, this already happens. Maybe that's the
> problem, I am assuming "application instance" = process.
>
> Okay... if I replace "application instance" with... hmm,
> "application window" isn't a great term, but that idea anyway...

This what I was thinking about. There is an application (kind), you
can launch it, and you get one instance of it -- to display
information it uses window (one).

> Would this make more sense? Does it cover what options you are
> wanting to provide?

Errrm, not only me :-))

> When closing a document...

I just realized I made an error while writing, copying&pasting text.
This should be without above intro text.

>    ( ) Never close the window (application changes to "empty"
> state)

Yes.

> (X) Close the window if there are sibling windows of the
> same application type*.

Yes (you for the feature, I opted for making it an option).

>      [X] Disallow closing the document if there are no such
> siblings.

Nope, putting this as negation does not make sense -- there are
siblings and you cannot close the document?

Ok, I corrected this (sorry for previous mess):
[ ] on close of document, close "its" application as well if there are
sibling instances of that application within the container
[x] on close of last application instance in container, keep this
instance (do not close it)
     [x] close the document only instead

> * ...with tooltip explaining that 'same application type' does not
> include any running on other machines, and probably a description
> of what "application type" means

Yes, and this means also within the same container (well, it was the
idea originally AFAIR).

> > Maybe it is where confusion comes from. I would say no, because
> > otherwise the whole environment would become more complicated,
> > and from user POV it is hard to tell if the window A and B are
> > from the same or different processes.
>
> It is preferable to hide this from the user as much as possible,
> yes. Ideally by making the behavior consistent regardless of if two
> windows belong to the same process or not.

Well, in the case described above we have to check if there is such
app within the container -- no matter of origin.

> This is why careful terminology is important ;-).

Yes, I just noticed :-D

Matthew, in KDE is it really possible to have two application windows
for one instance? What app is able to pull this out?

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:

> On Monday 18 May 2009 20:18:00 Matthew Woehlke wrote:
>
>>>> Aaaand... should containers every group in the task bar? If so,
>>>> how?
>>> You mean [snip]
>> Oops, no, that should have been "ever". Should the panel be
>> permitted to collapse what would otherwise be multiple top-level
>> entries when those entries are containers? If so, what criteria
>> would make sense for deciding what to merge?
>>
>> Right now it's easy; same application is merged. For containers, is
>> hard; do you merge all TDI containers? Only containers with
>> "similar" contents? (How do you define "similar"?)
>
> Well, here I does not have opinion because I dislike merging, and I
> think the need of doing it will vanish with NWI.

It's... of arguable usefulness. It's somewhat useful if you have a lot
of windows that aren't necessarily related (which happens to me at
times*), but reasonable use of containers can probably eliminate the
need to group containers.

(* I have six right now, none of which would be sufficiently improved by
containerizing to justify the effort. Well, the two Firefox windows are
effectively already TAI ;-), but that would just mean I would have a lot
MORE windows, but many of them in two TAI containers, and still have six
children of root.)

The problem is that our panel is drifting to where about four items is
"full", and you start compressing after that :-).

> So personally I would remove such feature, but on the other hand can
> we force users to use NWI? I think not. So auto-collapsing the same
> entries should be possible.
> ( ) collapse SAI only
> ( ) collapse similar

Okay.

> X1, X2, X3 -- sets (containers) of apps
> n -- intersection
> u -- sum
>
> similar(X1,X2) = [X1 n X2] >= [(X1 u X2) \ (X1 n X2)]

Um. Well, grouping applications is somewhat obvious. For containers I
think I would only want to group them if they have similar semantics...
but that's not a question that can be answered by inspecting the windows.

I've been sort-of assuming we need to be able to name containers (i.e.
user-assigned caption). Maybe there should be a class also; if
non-empty, containers with the same class can group. Otherwise
containers don't group. (And perhaps auto-assign class to certain
containers; for example any TAI created by app request. As a specific
example, the TAI you get from ctrl-t in konq, so TAI containers of
konq's would generally get grouped.)

> or
> there is X3 such that similar(X1,X3) and similar(X2,X3)  

I think that would be too complicated to solve in a reasonable manner ;-).

>>>>> Arranging windows as container
>>>> Okay, I'd have to go digging for the discussion on this. You
>>>> list 'select windows' and 'create group' as separate steps; is
>>>> there a reason not to combine them?
>>> a) "combine" means -- with every selected window it is
>>> immediately groupped, if yes, we discussed this and you agreed
>>> that two modes are possible, this one (not combined) and combined
>>> (incrementally adding).
>> Wait, did the text change or was I smoking something when I wrote
>> that? ;-)
>
> :-DDD
>
>> Let me try again. Do we need a context menu step to say "done
>> selecting windows", or can we do this:
>>
>> - decide to create a {T,F,G}AI container
>> - select windows mode started by previous action
>> - select windows as described
>> - click 'okay' button in corner of screen or hit enter*
>> - container is created with windows
>>
>> [stuff about creating containers]
>
> Nice, better! I change the summary accordingly.

Thanks. I made one further change to the menu text and added a mention
of picking the container type.

Is putting it in the "confirm" dialog okay? It should be the same number
of clicks (maybe more mousing, though) and lets you change your mind any
time before confirming.

>> Okay. Option is fine, I can understand wanting tearing to be more
>> explicit. (Personally I want it to be less effort :-).)
>
> Ok :-))) Option it is.

Thanks :-).

>> Well, complain to Kontact, but I don't think at the WM level we
>> should be trying to change what happens when you close a window
>> ;-). Anyway, there is no change here from how things work at
>> present.
>
> I wrote whole long part of why apps should quite, or more precisely:
> "
> That's exactly my point -- WM should send "signal" quit. If you don't
> send signal "quit" but only "close" how can app tell it was asked to
> quit?
> "
>
> but! I think systray apps are "odd" anyway so, what the heck... after
> container close regular applications quit, systray apps close their
> windows (if configured so).
>
> Ok?

Yes. I'm not sure if I want closing containers to be like "quit"
(especially as I want "quit" to be "this application /kind/ goes away",
when there is such a functionality distinct from closing the window).

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Here endeth the rant... which I realize is not likely to Win Friends or
Influence People, especially the person to whom it was directed.
   -- Charles Wilson (generalized)

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Tuesday 19 May 2009 18:58:53 Matthew Woehlke wrote:

> > I don't think WM should care about any app specific issues. It
> > should be quite in reverse -- app should provide means to make
> > other use of this or that shortcut.
>
> ...except that you're going against something like 20 years of
> established convention.

In such case (like here we have) I try to put history on the side and
the future on the other. Do we really have to walk with this history
on our back for... how long? 10 more years? 20 more years (and then
would be "40 years of established..."). I care about backward
compatibility, but when you build a car you don't put a horse inside
because of the tradition.

Above is about principles in general, because in our case -- it is
history against history :-)

> You're also assuming that it's even
> /possible/ to change CLI applications to use something else.

Sure, see VirtualBox. It uses "send xyz" technique. Nice, efficient.
What's more you should be able to assign your shortcuts for the
actions!

It means I should be able to press F2, it triggers action "send
ctrl+c". Or you could pick up from the menu "send ctrl+c".

> The
> alternative is to use ctrl-shift-c to cause Konsole to take the
> action as if you had pressed ctrl-c... not good usability IMO.)

If this is hardcoded, I agree.

> I suppose I disagree with you here. Besides, wasn't there a
> discussion a while back on better separation of keyboard shortcut
> domains? I think 'ctrl' was on the 'for use by applications' list
> :-).

I opt for flexibility. I have already problem with [alt], it is the
special key, because of the history, etc. In the effect I have
artificial layout, artificial problem, which does not help me working
at all.

I would really would like not to see another "special key". No matter
of the reason. After 20 more years somebody will curse us that we
_helped_ to add such hardcoded mod key :-)))

Think of make syntax, if I didn't scared you already :-DDD

> IMO the DE should try to avoid gratuitously breaking popular
> applications.

Yes and no.
Yes -- because _users_ matter (not apps).
No -- because:
a) authors of such apps should finally provide new means of UI
b) it would be test of the flexibility of the environment

ad.b) you won't know what cracks if you don't try to break "common
wisdom"

ad.yes) case with Win95 and SimCity, great backward compatibility
hack, but it was made for purpose but also, step by step MS forced
everybody to stop thinking "memory is mine"

> > Btw. ctrl+w is current default shortcut for document close.
>
> Right; an /application/ shortcut. We don't have problems now
> because there are currently no global shortcuts (that I know of,
> anyway) that use only ctrl.

Ok, but user uses ctrl+w. She/he is used to it. Why do we use alt+f4?
Because it is ergonomic? No. Because users are used to it. I bet
Konsole is not used by weekend-user so even if there is a problem, it
is easier for power-user to change this than for weekend-user.

Ctrl+c is for niche apps vs. ctrl+w which is used everywhere else.

It can be win+w, sure, or something else, but this would mean two bad
things:
a) we are getting into the history circle and we are allowing that
whole DE is driven by its this or that component
b) the shift would cost users more than it is necessary -- what's
more, that would be a cost for users who would not even use the
features of NWI


Just to be clear, I am the guy who posted a report to make the magic
[alt] key configurable. (Wontfix. Why? Because of the history :-D).

We have a chance to break that kind of thinking in small degree. Why
not use this possibility? Be flexible, expect anything, don't
hardcode shortcuts. So even for sake of this I think it is worth to
_keep_ ctrl+w as it is now (now = KDE3, KDE4).

> >> What I mean is there is no way for the WM to get an app to quit;
> >
> > Ok, but can WM _ask_ app to quit?
>
> It should be possible; it just means the app needs to handle such a
> signal. Much is possible an an ideal world, I am just also
> considering what will be the problems from adoption lag.

I changed the summary so close container means all embedded windows
close as well, so it is up to each app. It is better to test it and
see how it works, instead of changing every piece in one step.

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:

> On Tuesday 19 May 2009 19:16:59 Matthew Woehlke wrote:
>
>>> Wait, do we allow that one application instance (process) would
>>> have several windows?
>> Ideally, no :-). In reality, this already happens. Maybe that's the
>> problem, I am assuming "application instance" = process.
>>
>> Okay... if I replace "application instance" with... hmm,
>> "application window" isn't a great term, but that idea anyway...
>
> This what I was thinking about. There is an application (kind), you
> can launch it, and you get one instance of it -- to display
> information it uses window (one).

Yeah. In the end I kept "instance", with some glossary edits to make it
explicit how this is being used.

I replaced some occurrences of "application instance" with "window"
where either a leaf or container should be permitted.

>> Would this make more sense? Does it cover what options you are
>> wanting to provide?
>
> Errrm, not only me :-))
>
>> When closing a document...
>>   ( ) Never close the window (application changes to "empty"
>>       state)
>>   (X) Close the window if there are sibling windows of the
>>       same application type*.
>>     [X] Disallow closing the document if there are no such
>> siblings.
>
> Nope, putting this as negation does not make sense -- there are
> siblings and you cannot close the document?

Eh? No, you can't close the document if there are /not/ siblings. If
there are siblings, the whole window is closed as per the parent option.
(Suggestion for better wording?)

> Ok, I corrected this (sorry for previous mess):
> [ ] on close of document, close "its" application as well if there are
> sibling instances of that application within the container
> [x] on close of last application instance in container, keep this
> instance (do not close it)
>      [x] close the document only instead

Okay, I think I follow now. Same effect, but your options are worded
quite differently.

What about this?

[ ] Closing a document also closes the window if their are other
instances of the application in the container.
[X] Do not allow the last instance of an application to be closed by
closing the document

The problem is applications that don't have an empty state, yes? I don't
think we need an option to not close the document if we could go to
empty state; if I asked to close the document, that should happen. Only
if the application doesn't have an empty state (i.e. can close window,
can't close document without closing window) should we possibly not do
anything.

>> This is why careful terminology is important ;-).
>
> Yes, I just noticed :-D
>
> Matthew, in KDE is it really possible to have two application windows
> for one instance? What app is able to pull this out?

As "application instance" has been defined now? Well... we basically
defined it as "window". It's a bit fuzzy talking about e.g. a mail/IM
client where you have a "main" window and "documents"/"conversations".
I'm also assuming that dialogs are generally not part of NWI (actually,
that modal dialogs should always float, and probably that non-modal
should be considered as regular leaves).

As I said, my original confusion was that I was reading "instance" as
"process" (which is more correct from a technical standpoint without
having specified otherwise)... and yes. Start KWrite, hit "New" a few
times (you need to type something into the empty documents or it won't
make new windows)... you'll get several windows, but only one kwrite
process.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Here endeth the rant... which I realize is not likely to Win Friends or
Influence People, especially the person to whom it was directed.
   -- Charles Wilson (generalized)

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

Maciej Pilichowski wrote:

> On Tuesday 19 May 2009 18:58:53 Matthew Woehlke wrote:
>>> I don't think WM should care about any app specific issues. It
>>> should be quite in reverse -- app should provide means to make
>>> other use of this or that shortcut.
>> ...except that you're going against something like 20 years of
>> established convention.
>
> In such case (like here we have) I try to put history on the side and
> the future on the other. Do we really have to walk with this history
> on our back for... how long? 10 more years? 20 more years (and then
> would be "40 years of established..."). I care about backward
> compatibility, but when you build a car you don't put a horse inside
> because of the tradition.

...but you still put wheels on it ;-).

>> You're also assuming that it's even
>> /possible/ to change CLI applications to use something else.
>
> Sure, see VirtualBox. It uses "send xyz" technique. Nice, efficient.

Gaah!!! Have you ever had to use that? Efficient it is *NOT*. :-)

> What's more you should be able to assign your shortcuts for the
> actions!
>
> It means I should be able to press F2, it triggers action "send
> ctrl+c". Or you could pick up from the menu "send ctrl+c".

That might work for Konsole, but it means you've made xterm unusable
until the default (WM) keys are changed. Also, do you consider "press X
to send Y" good usability? (Keep in mind that users are going to need to
think of it this way in order to cope with CLI documentation, and
possibly other systems.)

>> I suppose I disagree with you here. Besides, wasn't there a
>> discussion a while back on better separation of keyboard shortcut
>> domains? I think 'ctrl' was on the 'for use by applications' list
>> :-).
>
> I opt for flexibility.

You can /configure/ the keys to anything you want. I just don't think we
should start taking over ctrl-<key> as global shortcuts. That way lies
mass confusion...

> I would really would like not to see another "special key". No matter
> of the reason. After 20 more years somebody will curse us that we
> _helped_ to add such hardcoded mod key :-)))

Um... who is hard-coding anything? I'm just saying don't make the
/defaults/ things that are more likely to add to confusion and possibly
cause problems. Why is it so important to use ctrl-<key> as default
anyway? :-)

>>> Btw. ctrl+w is current default shortcut for document close.
>> Right; an /application/ shortcut. We don't have problems now
>> because there are currently no global shortcuts (that I know of,
>> anyway) that use only ctrl.
>
> Ok, but user uses ctrl+w. She/he is used to it. Why do we use alt+f4?
> Because it is ergonomic? No. Because users are used to it. I bet
> Konsole is not used by weekend-user so even if there is a problem, it
> is easier for power-user to change this than for weekend-user.

...but you've now forced power users to re-learn ctrl-w.

I prefer a solution with neither of these problems. I'm not sure yet
what that is (from a technical standpoint). What I /want/ it to be is,
all apps /except/ those for which it is a problem, accept ctrl-w as
'close document'. "Special" apps use something else (e.g. Konsole uses
ctrl-shift-w).

I hate to say it, but... I think leaving ctrl-w as an application
shortcut might be best. Apps will need to integrate with the WM anyway
for 'new empty sibling' and 'clone', so might as well require that for
'close document' to integrate with NWI also. Meanwhile, for apps that
have their own MDI it is probably better if the WM doesn't try to
second-guess the app; otherwise you end up with ctrl-w closing the whole
window which has multiple documents.

In fact... until NWI is good enough that everyone agrees there is no
need for app-level MDI, I think you're stuck with that. Sure it sucks,
but then so does the alternative.

>>>> What I mean is there is no way for the WM to get an app to quit;
>>> Ok, but can WM _ask_ app to quit?
>> It should be possible; it just means the app needs to handle such a
>> signal. Much is possible an an ideal world, I am just also
>> considering what will be the problems from adoption lag.
>
> I changed the summary so close container means all embedded windows
> close as well, so it is up to each app. It is better to test it and
> see how it works, instead of changing every piece in one step.

Since that seems to be before my last edit, I assume that by "embedded"
you mean "children, grandchildren, great-grandchildren, etc...". Which
is right, of course, because it is recursive. The (sub-)container
doesn't care if it is being closed because the user clicked it's 'x', or
because the parent told it to close.

Hmm... that said, I guess containers should stick around until their
children /actually/ close (or else windows that won't close for whatever
reason will "detach").

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Here endeth the rant... which I realize is not likely to Win Friends or
Influence People, especially the person to whom it was directed.
   -- Charles Wilson (generalized)

_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Tuesday 19 May 2009 22:25:39 Matthew Woehlke wrote:

> > Ok, I corrected this (sorry for previous mess):
> > [ ] on close of document, close "its" application as well if
> > there are sibling instances of that application within the
> > container [x] on close of last application instance in container,
> > keep this instance (do not close it)
> >      [x] close the document only instead
>
> Okay, I think I follow now. Same effect, but your options are
> worded quite differently.
>
> What about this?
>
> [ ] Closing a document also closes the window if their are other
> instances of the application in the container.
> [X] Do not allow the last instance of an application to be closed
> by closing the document

The problem is there were 3 cases, now you have 2.

The first one is ok. The second one is (originally) is not about
closing document, but the fact if the last application can be closed
by user. And there are two cases:
* it cannot be closed
* although it cannot be closed but the the doc is closed instead

But not -- closing doc is the effect, not the reason!

> The problem is applications that don't have an empty state, yes?

No, not at all.

> I
> don't think we need an option to not close the document if we could
> go to empty state;

But it is not an option is up to application how it can handle "clear"
state:
* empty application (no doc)
* blank doc

> if I asked to close the document, that should
> happen.
> Only if the application doesn't have an empty state (i.e.
> can close window, can't close document without closing window)
> should we possibly not do anything.

Not really, such application should close the doc and "open" blank
one. Like Kate in KDE3.

Btw. I would much rather would like to have uniform behaviour -- close
doc is closing doc, app is empty, period. But forcing such behaviour
is beyond scope of NWI (or is it not? :-) ).



> As I said, my original confusion was that I was reading "instance"
> as "process"

That is exactly what I meant :-D

> (which is more correct from a technical standpoint
> without having specified otherwise)... and yes. Start KWrite, hit
> "New" a few times (you need to type something into the empty
> documents or it won't make new windows)... you'll get several
> windows, but only one kwrite process.

Ok, I get it. And in such case (currently) close window means close
this window, and quit app means close all windows and quit the app?

On a bright side...? I hope/guess/think it does not interfere with
NWI?

Except...

Let's say I have TAI with kpdf. I create another tab. In such case I
would really like that this is another tab of the same process,
right? Because otherwise find in one tab would be blind of the things
I entered in find dialog in other tab.

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel

[macias]

On Tuesday 19 May 2009 23:38:23 Matthew Woehlke wrote:

> I hate to say it, but... I think leaving ctrl-w as an application
> shortcut might be best.

Ok. If it is settled, then you can skip the bottom of the mail.

> > I changed the summary so close container means all embedded
> > windows close as well, so it is up to each app. It is better to
> > test it and see how it works, instead of changing every piece in
> > one step.
>
> Since that seems to be before my last edit, I assume that by
> "embedded" you mean "children, grandchildren, great-grandchildren,
> etc...".

Yes.

> The
> (sub-)container doesn't care if it is being closed because the user
> clicked it's 'x', or because the parent told it to close.

Exactly.

> Hmm... that said, I guess containers should stick around until
> their children /actually/ close (or else windows that won't close
> for whatever reason will "detach").

Yes. It would be very strange to have it otherwise.

================= part you can skip, about ctrl+w ===================

> > Sure, see VirtualBox. It uses "send xyz" technique. Nice,
> > efficient.
>
> Gaah!!! Have you ever had to use that? Efficient it is *NOT*. :-)

Sure, when I click on shutdown I have nice options and I don't have to
even remember if this is ctrl+alt+del or ctrl+shift+backspace.

> > It means I should be able to press F2, it triggers action "send
> > ctrl+c". Or you could pick up from the menu "send ctrl+c".
>
> That might work for Konsole, but it means you've made xterm
> unusable until the default (WM) keys are changed.

True.
count (KDE users) - count(xterm users) > 0

though.

> Also, do you
> consider "press X to send Y" good usability? (Keep in mind that
> users are going to need to think of it this way in order to cope
> with CLI documentation, and possibly other systems.)

I think that good usability is having feature "stop program" and
assign "ctrl+F12" shortcut to it, which internall could send ctrl+c
to the program. User is stopping the program, not cltrcing it :-)

But I get your point, I just wrote above as things should be -- they
are not of course. So my answer is -- it is not good usability, but
it is not KDE fault, and KDE user should not be punished for that.

> You can /configure/ the keys to anything you want. I just don't
> think we should start taking over ctrl-<key> as global shortcuts.

Ok, but user does not know if it is global, or local, or anything
else. She/he uses ctrl+w. All of the sudden she/he has to use now
win+w. She/he is puzzled.

> Why is it so important to use ctrl-<key>
> as default anyway? :-)

Ctrl+w. Because it is default key now. I added to summary alt+f4 not
because I like it (I don't) or because I use it (I don't) but because
it is default now.

> > Ok, but user uses ctrl+w. She/he is used to it. Why do we use
> > alt+f4? Because it is ergonomic? No. Because users are used to
> > it. I bet Konsole is not used by weekend-user so even if there is
> > a problem, it is easier for power-user to change this than for
> > weekend-user.
>
> ...but you've now forced power users to re-learn ctrl-w.

Yes. Somebody has to be punished :-DDDDD

Cheers,
_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel