On Tue, Aug 01, 2000 at 06:06:14AM -0600, Mitch Chapman wrote:
> Well-put, but my customer wants mode*less* dialogs.
> They want to be able to continue working with the main
> application after the dialog appears.
Oops :-)
> Here's the problem scenario: The user has clicked on a
> thumbnail and gotten a larger view. Now the user wants to
> go back to the main window and click on another thumbnail
> to get another larger image to compare to the first. As soon
> as they click on the new thumbnail the main window comes
> forward, obscuring the original thumbnail.
I'd really suggest to configure the window manager in this
way:
- Don't bring a window to the front when you click into it.
- Bring it to the front when you click on the border
(especially the title).
You should be able to configure every window manager
in this way. I'm cursing M$ every day for their fucking
and un-changeable default to raise a window by clicking
into it :-( And I swear even more every time I try to
send a window to the *back* on Windows :-((
> The most obvious solution is to make the zoomed views transients
> for the main window, so they always stay in front of it. But
> this would force the user to keep dragging the zoomed views out of
> the way, so they could see enough of the main window to get at
> other thumbnails. Hence (I think) the request to make the zoomed
> views stay in front of, but be separately iconifiable from,
> the main window.
Not really; transient windows are meant for dialogs. You should
not "abuse" them like M$ for Help Windows and things like that.
What irritates the user is that the computer is "too smart":
It does something that the user doesn't want and the user
has no way to prevent it.
> We need to look at the usage scenarios in more detail. For
> instance, if the users tend to view only two or three zoomed
> views at a time, then it might not be so annoying to make
> them transients for the main window. Screen real estate being
> what it is, I can't imagine them trying to look at very many
> zoomed views at once.
The last solution would be to add a "preview" to the main window.
When the user clicks on a thumbnail, it will displayed inside
the main window. That can cause other problems but maybe
you could offer a configurable main window with three
"modes":
- Create zoomed views in different windows (as it is now)
- Replace the contents of the main window by the zoomed view
plus a "Back" button
- Add a widget to the main window which will contain the
zoomed view. You might want to try with a "hidden" view,
that is one which is show()n, when the user clicks on
the preview and hidden when he's done. But that causes
resizing of the main window and that also anoys users :-)
> But a completely different solution might be much better. This
> is what you're saying, and is also what I meant by "solving the
> wrong problem."
How about somethink like the exporer: List of previews
to the left and a large view on the right ?
> For instance, since users seem to be trying to compare zoomed images,
> it might make sense to grid the views into a zoom "dock", one which
> comes forward every time its content changes, but is not a transient
> for the main window. This would let the user create comparative
> views without manually dragging modeless dialogs into position, and
> would also get around the problem of screen-blocking transients.
When they have to compare the windows, then the app should provide
a window which contains two images because otherwise, users will
always have to move windows around and be less productive.
If drag&drop wasn't so complicated in Gtk (=not much docs), I'd
suggest a band of previews which you can drag into two view
areas. If there are lots of previews, the app should provide
a "Hide Large View" toggle so they can switch between "band
of previews with two large views" and "large window with
lots of previews".
--
==============================================
Sowatec AG, CH-8330 Pf�ffikon (ZH)
Witzbergstr. 7, http://www.sowatec.com
Tel: +41-(0)1-952 55 55
Fax: +41-(0)1-952 55 66
----------------------------------------------
Aaron "Optimizer" Digulla, [EMAIL PROTECTED]
==============================================
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
