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

List:       kde-usability
Subject:    Re: Tab-Modal Dialogs
From:       Allan Fields <kde () afields ! ca>
Date:       2004-05-09 5:55:11
Message-ID: 20040509055511.GC54734 () afields ! ca
[Download RAW message or body]

On Fri, May 07, 2004 at 11:01:17PM -0400, Jamethiel Knorth wrote:
> The issue is that, in Konqueror, a dialog may need to be modal to only part 
> of Konqueror. For example, if I get a security warning from a tab where I 
> am browsing the web, this is modal for that tab, but it should not 
> interfere with my using another tab devoted to file-browsing. However, as 
> it is a separate window, I can't have it be forced to be on top of the 
> Konqueror window and keeping focus from the Konqueror window, yet still 
> allow motion in the Konqueror window.

I previously took some time to describe a potential solution to the
dialog-focus issues and suggested it might be best to implement a
configurable/generalized user-messaging system: 

http://lists.kde.org/?l=kde-usability&m=107319974715513&w=2
http://lists.kde.org/?l=kde-usability&m=107327489603557&w=2

This wouldn't be a replacement for all dialogs but could rather help
reduce the number of unnecessary dialogs requiring immediate user
attention/interaction.

Blocking on a dialog/error message should be orthogonal to the display
of a dialog window in my opinion and only occur when it makes sense from
the perspective of that thread of execution. I've yet to determine
how much would need to be done in kdelibs and what QT supports/doesn't
support wrt dialog behaviour, before I would proceed with implementation
of said system.

> My suggestion is that we use dialogs in the style of the OS-X modal dialogs 
> as tab-level modal dialogs. That is, rather than being a separate window, 
> it is a slide-down window from part of that window. This would 
> theoretically make it possible to switch tabs and manipulate the rest of 
> Konqueror, yet still have a dialog modal to that tab.

Again, I didn't draw the comparison to OS X or other specific
platforms/software products.  All though the temptation might be
there, I would suggest we stay away from looking to other desktops
for the answer even if they seem to provide any easy "carrying-handle"
by which to pick-up/characterize desired features and behaviours.

Some times they will get it right, other times their implementations
may impose undue design restrictions, when considered anew.  The
problem with doing this is people might assume: "OK, so we should
implement OS-X-style dialog behaviour" and implement based on those
requirements with-out looking at the larger problem.

>From a technical standpoint and in some respects legal perspective,
I'd rather stay away from that all, especially when IP claims and
software patents get involved.  Maybe my concerns are an over-blown?

As far as I'm concerned, my idea is too general to be associated
with existing products/projects though some outlandish claims might
exist (fork-and-knife software patents).  So I would feel relatively
confident in proceeding with implementation.

> There are currently two levels that a dialog could be modal to: the entire 
> environment, or just one window. I don't know of any environment-wide modal 
> dialogs, but there are quite a few window-level modal dialogs.

Some times I'll have Konq windows on one desktop with error dialogs
on another desktop.  That's kind of a mess cause you have to search
for them and the window seemingly stops responding until the error
is dismissed.  Some times I also have many windows and an error gets
buried.  I don't like being interrupted while I work in separate
windows/tabs: so I try to prevent focus stealing.  Yet, I don't
want a dialog to not be brought to my attention at all or for some
dialogs like File open/save to not come to the front when they
should.

Other times I see no reason why some dialogs should stop me from
interaction with the applications window.  These are issues needing
resolution in applications.

> I'm certain that is an enormous change, as the windowing system doesn't 
> support that sort of window, but I think it could be quite useful in that 
> case.

Given the opportunity these would be fun coding projects for
the GUI experimenter.  If you have the time this: it's on my wish
list/todo queue med-pri.  GUI's don't have to suck by spamming users
with dialogs.  What I call the "OK Computer" syndrome.

-- 
 Allan Fields
 AFRSL - http://afields.ca
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]