Re: [PATCH] GtkMessageBox should set empty window title by default



On Tue, 21 Feb 2006, Kalle Vahlman wrote:

On 2/21/06, Martyn Russell <martyn imendio com> wrote:

I completely agree with Tim here. What if you have 10 dialogs all pop up
with no title and one of them happens to be an important one from
another application?

If you have 10 dialogs popping all over the place, there's more wrong
in the world than just suggesting empty titles ;)

depends on your application. e.g. mozilla implements modality per browser
window and each such browser window can have multiple tabs. an alert could
be popped up e.g. per tab (say for security relevant information) so you
quite possibly get a bunch of similar alert windows.

It makes it harder to know when cycling through
them as Tim says.

You shouldn't have to cycle through them, that's my point. Either you
cycle the parent windows (where the popup will be on top) or it will
be the only window and then IMO it could have an title (as I stated).

whether cycling goes through window groups or individual windows and
whether windows are placable always-on-top and cenetered-on-parent or
not is completely up to the window manager and the specific behaviour
it implements. you can't assume either.

i outlined that earlier, in particular you can't assume that having no
title does make sense at all with your eindow manager theme, or your
accessibility toolkit.

you can of course implement title-less alerts in a window manager (-theme),
but then you don't need toolkit support for the title-removal, you simply
don't show the title bar for windows flagged as alerts.

but accesibility kits or other window managers (-themes) may need a normal
or emphasized title bar, so unsetting it in the toolkit would actively
interfere with proper window manager operation.

They should be application modal, and kept above their parent so as
not to be lost. They should _not_ be visible in window lists and I
don't really see why should they ever be shaded either...

I disagree, I think modal dialogs have very limited use. Modal dialogs
should ONLY be used when the whole app is waiting for input IMO. That is
rarely the case.

That should be _always_ the case with alerts. If it's not that urgent
and devastating, don't use an alert, notify the user somewhere else.

i really wonder what kind of use case you have in mind for your alerts
then. i'm using graphical user interfaces for some 20 years now, and
i have not come across a dialog yet that seems to meet all of your
requirements. maybe with the exception of a "Core melt down, leave
the building!" alert in a power plant movie.
but then i think that specific case doesn't need generic toolkit support.

You only have to use Microsoft Outlook to understand
why modal dialogs are a bad idea. It means you can't visit information
from other windows/dialogs in the application that might be important in
responding to the modal dialog.

That's bad application design, not fault in modal dialogs.

If you want them to remain on top of their parents, you should make the
window a transient.

Yes, alerts should be transient to their parent _and_ modal.

I think the HIG should be amended here, I think having no title is just
uninformative and just not aesthetic IMO.

The point is not to repeat the message of the dialog, which will
contain more details than the title.

if that was a valid point, it'd apply to general notification or
application toolbox windows as well, i.e. any window that has a title.

in your other email/HIG, you call the alert window title "noise". i don't
think that is proper attribution though. it simply is a biased unbacked
claim, maybe your perception, but nevertheless not a valid technical
or usability argument. (if it was, we could simply end this argument by
me claiming the relevant HIG section to be "noise" ;)

my point stands, if you want title-less alert dialogs, implement a window
manager, or a window manager theme that removes the title bar, not have
the toolkit empty the titlebar text.

--
Kalle Vahlman, zuh iki fi

---
ciaoTJ



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]