Are modeless configuration dialogs useful in EventGhost?

[Bitmonster]

In the 0.3.6.995 beta version all configuration dialogs for plugins and actions are now modeless. So you can even open more than one dialog at once. I will add an option to turn this off in the future, because I'm not sure if this behaviour is really useful.

But I would like to hear your opinions about this modeless-feature. So let me know them here.

[Barf]

This is an issue I feel very strongly about.

First, I will discuss it from an abstract standpoint, without any references to EG.

I have been using early windowing systems, in particular the X-Windows system (with Xt/Athena Widget tools etc). These worked quite well, without resorting to modal popups. Then Windows started to spread, and with it, the usage of modal popups. I was immediately repelled by the restrictions these meant. Unfortunately, the usage of modal popups has spread outside of the Windows world, for example to Java, KDE, Gnome (unsure about the details).

A modal popup prohibits the user from any interaction with the application, except for that popup window. This often feels like an insult to the user, who may have other ideas of what he wants to do with the program, and the order in which he wants to do it. In many cases, they simply constitute a usability catastrophe: Assume an error messege, to which the user is expected to react ("cannot write file..."). In order to analyse the problem (why could the file not be written?), the user want to utilize other parts of the program, like the help facility. He can't. Because the modal popup is blocking the application. Or he want to look up "Error E6553-6633-995A2" in the documentation. Problem is that he has to destroy the information (contained in the modal popup) before he can access the documentation...

In some cases, modal popups are justified. (fatal errors, ending dialogs,...) In most cases not. The are just a way of unnecessarily restricting (and annoying) the user. In general, the more complex a program is, the harder it is for the programmer to anticipate the user's (sensible) wishes, and the more modal popups should be avoided.

So why are modal popups so widely used? Even by "Microsoft-criticals"? I do not know; possibly because people are used to being forced and do not question?

It should also be said that allowing non-modal popups in some cases makes it harder to write correct programs.

There is also an issue with program robustness: If a complex application somehow goes haywire, like generating "many" error popups, possibly in an infinite loop, the modal-popupper in general must be killed from the OS; a non-modal popupper can more easily be recovered.

The similarities between modal popups and UOP on DVDs is striking: It is like disabling the Audio-key; "no need to use it, the user can go to the menu and there select his audio track".

So the appropriate question is IMHO not "is modeless a cool thing?", but "is it really necessary to restrict the user's freedom with modal popups?"

Returning to EG, it is clear that not all of the above applies to EG. Nevertheless, why let a popup disable the Help-menu? (BTW, there are, in .995 still modal popups, e.g. Configuraton -> Add Plugin.)

I do not see any reason to "turn off this feature" (i.e. disabling the rest but the popup): the user who exclusively wants to work with the popup can do so also without being forced.

Now stepping down from the soapbox . Sorry if everything did not concern EG in a strict sense.

[Bitmonster]

These are interesting thoughts. Thanks for taking the time to write them down.

Yes, some dialogs are still modal, but I guess I could convert them quite easily to modeless now. Normally modal routines are much easier to write, because you don't need to write them in an event-based fashion. But through the usage of this coroutine-concept that greenlets allow, the programmer doesn't need to use event-based approaches and can still write in a modal fashion to achieve modeless behaviour.

Luckily error dialogs are not a big problem for EG, because it uses this log-window approach and therefore even a chain of errors don't produce a chain of popups. Some care I will have to take for the saving of a configuration while some configuration dialogs are open (that are possibly modified by the user). But I guess the tree will always be in a consistent state regardless of that.