Oberon/F modal dialogs 
Author Message
 Oberon/F modal dialogs

Quote:


> >    Modes are in our view the hallmark of user-unfriendly systems.

> This is all very true, but I think, that the problem is, that Oberon does'n
> support parallel processes (maybe Oberon/F does?). Imagine a command that
> can't get all it's input at it's start because the input depends on the
> computation, as the autor of the first posting described.
> The command will have to open a Tool/Viewer/Dialog and wait for the input to
> be entered.

I didn't really get what you mean with your example, but let me say
that there are several ways to solve a problem. Good examples of
non-modal Oberon programs that do not get all the input at the start
are the text and picture editors. General technique: if more input is
needed, perhaps a message should be printed, but then just return and
wait. Don't block anything. Can be applied in Oberon as well as
in MS-Windows, on the Macintosh. It is just a little more work for
the programmer, but a real plus for the user.

Hope this helps.

--Roland

-------------------------------------------------------------------


-------------------------------------------------------------------



Fri, 23 Jan 1998 03:00:00 GMT  
 Oberon/F modal dialogs
Regarding the lack of modal dialogs in Oberon/F, here
is the perspective from someone new to the Oberon
scene who is in the process of evaluating the development
system.

Oberon/F vs other Oberon systems
--------------------------------
When Oberon came out years ago, I tried it and rejected it
because the the system forced you to use an environment different
from the host OS GUI. I am not saying it was better or worse,
just different. (I hope this statement does not start another
thread on the merits/demerits of the Oberon GUI. That is _not_
the point.) The language was closely coupled to the system and
its new GUI. The difference represented a cost to the user and
developer that was too steep for me to accept. That was sad,
because I really liked the language and wanted to use it.

When I found out about Oberon/F with its cross-platform development
environment the cost of a different GUI had suddenly disappeared.
I became very e{*filter*}d about using it and am now in the process of
porting a large application to Oberon/F with the purpose of
evaluating the system for use at our University.

But the difference between the charter of Oberon/F and the other
Oberon systems means that the issues are different as well. I
do not care about seeing Oberon/F source code.  I don't _want_
to see Oberon/F source code. I want a company that will maintain
the development environment bug free and will provide commercial
grade documentation.

The need for modal dialogs
--------------------------

Quote:

> After seeing all those messages about Oberon/F and modal dialogs,
> I am wondering if any of you read about the basic concepts of
> System Oberon. E.g., in Project Oberon, chapter 2 (Basic Concepts):

>    Modes are in our view the hallmark of user-unfriendly systems.

> This is directly against modal dialogs.

Being new to the Oberon scene, I did not know about this pronouncement
against modal dialogs. I have two responses.

(1) The environment in which that pronouncement was made was one
in which an entire system was being written from scratch. That is,
it was a principle of a new Oberon GUI. That is not the same charter
as Oberon/F, which attempts to provide a cross-platform development
environment in which code can be ported and run with the host
platform GUI.

(2) The host GUIs under which my application will run frequently use
modal dialogs. One use is to display information on the progress of
a computation. For example, instead of an animated cursor that says
nothing about what is being done (only that the computer is busy
doing something) the dialog can display specific information as to
what is being computed. Another is when input is required from the
user that is impossible to predict in advance. This situation is
common in simulations where different types of input, indeed even
whether input is required at all, depend on the course of the
simulation. Since this thread began, I have been noticing the modal
dialogs in the daily use of my host GUI. I fail to see how any
of them can remotely be considered user-unfriendly. To me, forcing
the absence of nonmodal dialogs _in the established GUI_ appears
to produce the opposite effect of user-unfriendliness.

Lack of a workaround
--------------------
I can live with no primitive enumerated types in the language.
It is simple to use constant identifiers with integers. I can
live with small sets.  It is simple to construct large sets from
small ones.  I can live with no goto statement. Bohm and Jacopini
proved that any unstructured algorithm written with goto's can
be written with only sequence, IF, and WHILE. I can even live with
the lack of multiple inheritance. But there is no workaround for
the absence of programmer designed modal dialogs in host GUIs that
regularly use them. All workarounds proposed in this thread required
the developer to call host-specific routines. Which means that
for a developer to produce a platform-independent application he
must learn a different application program interface for each machine
the application will run under. This is the precise problem I was
looking to Oberon/F to solve. It is a cost I must consider when
choosing my development environment. The suggestions to completely
rework the app to eliminate the need for modal dialogs were
unconvincing. The examples of how to use modeless dialogs seemed
to focus on editing data, not on running simulations.

Quote:
> I understand that some people get e{*filter*}d about creating old
> style Windows programs with the new Oberon language using
> Oberon/F. But by sticking to the old style windows you will
> keep all those problems associated. Anyone has the right to
> use whatever language for whatever you like. But I would be
> sad to see this newsgroup turn into some kind of Windows
> programming support group.

> I am interested in discussions about Oberon, not about Windows,
> Mac or other arcane stuff, for which there are plenty other
> newsgroups.

> The only Windows topic I am vaguely interested about is e.g.,
> if someone could give a reasonable argument why modal stuff is
> better than the Oberon way.

It seems that Oberon/F is a different Oberon way that does not
share all the same preconceptions and goals of the original way.
Issues of how to integrate Oberon with the host GUI are extremely
relevant to me. I know of no other forum to air my concerns.
Perhaps an Oberon/F-specific list is needed.

Stan Warford
Pepperdine University



Sun, 25 Jan 1998 03:00:00 GMT  
 Oberon/F modal dialogs

Quote:

> (2) The host GUIs under which my application will run frequently use
> modal dialogs.

It is widely known that most Windows programmers have not read anything on
user interface design. So this shouldn't come as a surprise.

Quote:
> Lack of a workaround
> --------------------
...
> But there is no workaround for
> the absence of programmer designed modal dialogs in host GUIs that
> regularly use them.

Since a modal dialog box is just a dialog box with restrictions on who
handles events, I don't see a problem. As long as I'm not the one using
the software.

Stephan



Mon, 26 Jan 1998 03:00:00 GMT  
 Oberon/F modal dialogs
OK OK, Reiser says: "the modality of texts has been abolished"

but look in Oberon/F 1.1 beta there are  three different modes
for texts

Why do we need a scholastic discussion of what someone needs
and why he should not need it ?

Bernhard



Tue, 27 Jan 1998 03:00:00 GMT  
 Oberon/F modal dialogs
  I've just skimmed these discussions on modal dialogs so forgive me
if I'm not in synch.
  If by "modal dialog" you mean those popup windows that say
something like "Please confirm your leaving Windows" then I
do have a comment.  You will notice that if you have a clock
icon running (analog) showing seconds that the clock stops when
the dialog pops up.  This is because no cycles are being given to
any other "task".  The programmer who popped up the dialog feels that
the condition is important enough to force the user to make a choice
at this point (a rather arrogant position in my opinion).  So what
you may say.  Well, for my type of work its deadly.  We write
speech recognition systems that can control other applications
"remotely" by sending mouse and keyboard events to other tasks.
The user need only say, "Ok" or "Cancel" to process a standard
pop up dialog, but if it is "modal" (as I have defined it above)
then the speech recognition task is frozen and "Ok" and "Cancel"
does nothing.  The user is forced to use the keyboard or mouse.
Very, very, bad human factors.
  So if my understanding of modal bears any resemblence to the
previous discussions.  Then I'm agin it.

-Doug Danforth

--
(**)
DANforth & WOoTton



Tue, 27 Jan 1998 03:00:00 GMT  
 Oberon/F modal dialogs

Quote:

> OK OK, Reiser says: "the modality of texts has been abolished"

This refers to the original Oberon GUI.

Quote:
> but look in Oberon/F 1.1 beta there are  three different modes
> for texts

That's what this thread is all about. If you don't want the
improvements of the Oberon GUI, but instead want the old
GUIs, Oberon/F is your godsend. This, of course, assumes you
like the old GUIs and their modal stuff.

Quote:
> Why do we need a scholastic discussion of what someone needs
> and why he should not need it ?

Well, if everybody is too busy trying to find workarounds to
implement the good old modal dialog, I mean too busy to
read the basic Oberon literature, then I thought, let's be
nice and trow in this thought that years ago some people started
reasoning that live would be easier without being locked in
modes imposed by a simple-minded computer operating system or GUI,
in the hope that those busy people would wake up and perhaps
realize what they are wasting their time on.

I don't really need to start a discussion on this. I wouldn't
mind it, though, if this thread about modal nonsense could be
laid to rest or moved to a newsgroup on another GUI or OS.
This would eliminate some 80 percent of the postings in c.l.o.
I am more interested in the other 20 percent on real Oberon issues.

-------------------------------------------------------------------

            World-Wide Web: http://www.ee.pdx.edu/~rkwee

-------------------------------------------------------------------



Wed, 28 Jan 1998 03:00:00 GMT  
 Oberon/F modal dialogs
In an apparantly unrelated thread, Wotjek writes of trouble
with System.SetUser.

I had almost identical trouble with System.SetUser some years
ago, and this persisted for months.  The trouble turned out to
be a

        *** mode change ***

For Wotjek, when you execute the System.SetUser command,
the system grabs the keyboard input.  The characters are no
longer sent to a viewer, so that the password can remain
secret from passers by.  After you type the return key, the
mode returns to standard Oberon expectations, and the system
is as it was.

For the Oberon doc managers, this could use a bit more
emphasis for an (impatient) American readership...  Perhaps
an Oberon.Log message to *type return before panicing*
would help.

Similarly, having been bitten so badly by this in times past,
I was very alert to find similar things in the V3Windows net
support stuff by Marais.  Only he spreads it out to several modules:

FTP.SetUser
Mail.SetUser

and their friends, who I almost never can remember names for.
He has good hypertext documentation, so I can drive it when I
am at home.

So to do an anonymous FTP I have to change the passwords one way,
and to go to my own accounts, I have to change things another.
I made the change to the mail panel that was posted a few days
ago.  I notice that I no longer can (easily) control the account
name.  It turns out that I have both a private and a university
internet account.  In my case, the logins are the same.  This would
probably be a source of suprise to someone with different acocunt
names.

Once I *studied* the docs that came with the V3W installation,
I have found it a joy to use, and have had no problems with it( per se).

I do have this little 'beeping oberon' startup problem.  I have learned
to reproduce it by using Winsock 2.0B (Winsock 1.0 works ok), Oberon,
and device=aspi4dos.  As near as I speculate today,
I have an address line and/or memory problem on my mother board.
This has taken months to figure out.  I think Oberon was ultimately
a resource in this...

--
-Aubrey McIntosh
http://ccwf.cc.utexas.edu/~mcintosh/index.html
"I'll bet with my net I can get those things yet!"
   - Dr. Seuss, The Cat in the Hat



Fri, 30 Jan 1998 03:00:00 GMT  
 Oberon/F modal dialogs

Quote:

> In an apparantly unrelated thread, Wotjek writes of trouble
> with System.SetUser.

  Actually, it was the Mail panel SetUser button.

Quote:
> I had almost identical trouble with System.SetUser some years
> ago, and this persisted for months.  The trouble turned out to
> be a

>    *** mode change ***

> For Wotjek, when you execute the System.SetUser command,
> the system grabs the keyboard input.  The characters are no
> longer sent to a viewer, so that the password can remain
> secret from passers by.  After you type the return key, the
> mode returns to standard Oberon expectations, and the system
> is as it was.

> For the Oberon doc managers, this could use a bit more
> emphasis for an (impatient) American readership...  Perhaps
> an Oberon.Log message to *type return before panicing*
> would help.

Though not an American, I admit I am a bit impatient. My approach
with Linux and with VAX has been "read as little as possible
to have things going" (another "as ... as.." rule). Otherwise
how could I read through hundreds of pages of docs, and still retain
my sanity? I appreciate good documentation, I want to pay full
tribute to Hannes and others, but having to solve many problems
in a short time requires _not_ studying all the details. Please note,
that setting up computers is not my main occupation. I know
this is bad. However, I am afraid is has to stay that way, and perhaps
not only in my case. Perhaps this is a reality, which the authors
of docs could somehow acknowledge by writing a simplified Startup.Doc?

Another possible solution is of course to emitt plain, descriptive
messages to System.Log, some of them with loud beeps. Let's dismiss
modal dalogs, but IMHO messages should be there. Useful messages.
Not like this one "non-obj file", which I got when I screwed up
one of .Obj's by copying a bunch of files from ETH. I do not know,
which one, and the message did not tell me.

Let's agree, that System-3 is not simple anymore, and handling
user errors is now needed. It was not so crucial in the original
System, where I knew exactly, which Mod.Proc I just clicked on.
With System-3 this is no longer true. "Mod.Proc" is now hidden beneath
buttons, and confusion is the result. It is not "user-friendly"
at all, when I have to launch Inspectors only to learn, what
error message _should_ be there, but in fact is not there.
Hiding information from the user has its price, and emitting
error messages is a part of it.

Another problem is to know, what System-3 is actually doing, when
it is doing something. There was a "busy" down-arrow some time ago,
but it seems to be gone in WinS3. At least in my case, the pointer
is alive all the time. Both when I click on a WWW connection, and the System
is getting info from Zurich, and when I click on a further link, and
the System should be getting further info (but it does not...), it all
looks the same. Once again, there should be a visual feedback, as advocated
by Gutknecht, Reiser and Wirth. Otherwise I do not know, if it is time
to abort yet??

I am writing all this, because it seems to me, that in spite of all the
spiffy features, System-3 has made some pretty basic mistakes in handling
user psychology. Fortunately, they seem trivial to correct.

Quote:

> Once I *studied* the docs that came with the V3W installation,
> I have found it a joy to use, and have had no problems with it( per se).

Hope I had time to do the same...

Wojtek



Fri, 30 Jan 1998 03:00:00 GMT  
 Oberon/F modal dialogs
On Aug 15, Wojtek wrote (in part):

Quote:
> Another possible solution is of course to emitt plain, descriptive
> messages to System.Log, some of them with loud beeps. Let's dismiss
> modal dalogs, but IMHO messages should be there. Useful messages.
> Not like this one "non-obj file", which I got when I screwed up
> one of .Obj's by copying a bunch of files from ETH. I do not know,
> which one, and the message did not tell me.

> Let's agree, that System-3 is not simple anymore, and handling
> user errors is now needed. It was not so crucial in the original
> System, where I knew exactly, which Mod.Proc I just clicked on.
> With System-3 this is no longer true. "Mod.Proc" is now hidden beneath
> buttons, and confusion is the result. It is not "user-friendly"
> at all, when I have to launch Inspectors only to learn, what
> error message _should_ be there, but in fact is not there.
> Hiding information from the user has its price, and emitting
> error messages is a part of it.

I tend to agree with Wojtek.  Another problem is the Assert messages
which are totally non-standard for different Oberon implementations.
It seems so simple to me to have a standard module of Assert messages
which are output in response to Assert failures.  This is much friendly
than the stack dump and assert number which could mean almost anything.

        Michael

--------------------------------------------------------------

AlliedSignal Aerospace Canada           my opinions are my own



Sat, 31 Jan 1998 03:00:00 GMT  
 Oberon/F modal dialogs
Recently there has been much discussion about modal dialogs versus
non-modal dialogs. First, the facts: currently, Oberon/F doesn't provide a
portable and extensible way to use modal dialogs. There are a few built-in
modal dialogs in Oberon/F, such as the standard file dialogs. The reason
for their existence is compatibility with the underlying platform.

ETH Oberon has shown how elegant and simple a completely non-modal
environment can be. Once you're used to ETH Oberon, I think you'll become
quite aware of how user-unfriendly modal dialogs are. As was mentioned in
one posting, it often happens that you need additional information when
you're stuck in a modal dialog. It's a matter of who is in control, the
user or the computer.

As Larry Tesler has put it: don't mode me in. Unfortunately, at the time
Apple didn't have the courage to go to a fully non-modal user interface.
Since everyone imitated Apple, that's where we are today. Note however,
that modal dialogs in the Mac OS have evolved over time, in order to
somewhat reduce their user-unfriendliness. For example, you really want to
be able to paste the clipboard contents to a text field in a modal dialog,
right? So at least the Edit menu might be enabled. Furthermore, some modal
dialogs have been made moveable, so you can move around the dialog and look
what's underneath. But that's just curing the symptoms, rather than the
cause.

Fortunately, modal dialogs are not mandatory under Mac OS or Windows; in
theory their use is rather discouraged. This meant that we could leave away
a general modal dialog mechanism without violating the standard user
interface guidelines. Moreover, making Oberon/F programs as non-modal as
the underlying user interface permits, would be the technology transfer of
another successful aspect of ETH Oberon.

There are some reasons why modal dialogs may make life easier for a
programmer (but not for the user, I think). One of them is that state can
be held in local variables, i.e. on the stack; rather than extracting it
and managing it explicitly in a separate stack-like data structure. The
other is conversion of old code to Oberon/F. Both problems don't occur for
software which is written explicitly for Oberon/F. But migration of old
code is certainly an issue that shouldn't be neglected. Note however, that
the acceptance of straight ports from command-line environments to GUIs has
been extremely bad in the past.

It shouldn't be overly complex to introduce modal dialogs in Oberon/F, but
it isn't trivial either. The core event handler hasn't been designed as
reentrant, a suitable menu enable/disable strategy would have to be
implemented, and some behavior would have to be changed. For example, drag
& drop from a view in a modal dialog to a location outside of the dialog
would have to be prevented.

Our position in this and similar cases is simple: if enough of our paying
customers demand it, or if someone directly pays for our work, we'll
implement it! However, we haven't yet seen much demand for this particular
feature. There wasn't much more than the suggestion to provide a
Yes/No/Cancel dialog in addition to the existing Yes/No (Dialog.GetOK)
dialog. We have put that on the list of possible new features for the next
release after 1.1.


Oberon microsystems Inc., Zuerich, Switzerland



Sun, 01 Feb 1998 03:00:00 GMT  
 Oberon/F modal dialogs

Quote:

> Recently there has been much discussion about modal dialogs versus
>Recently there has been much discussion about modal dialogs versus
[snip]

>Oberon microsystems Inc., Zuerich, Switzerland

Thanks very much for the clarification of OM's position on modal dialogs.
With the exception of porting old code, IMHO lack of modal dialogs
is resonable -- GUIs are evolving away from modal dialogs anyway, and their
implementation and use involves additional complexity that compromises
the simplicity principle of Oberon.  Oberon/F is not supposed to be
just another app framework; it's supposed to have clear advantages over
existing frameworks -- simplicity being one advantage.

Building in support for converting old code is difficult, but its important
to users. Systems have been ruined by too much backward compatibility, and
others have died from not enough.  It just seems a shame that Stan Warford's
obvious enthusiasm for Oberon/F is being quashed by this one detail.  He
only needs modal dialogs in a few hard-to-rewrite situations and, I think,
would otherwise be satisfied with modeless dialogs.

Perhaps a simple modal view that supported a limited set of controls would
be a good compromise.  It could be implemented independently from Forms and
would only be for when-all-else-fails use.  It would need however, a
procedure like Frame.Inut that would wait for the next *keyboard* event.  
Does such a procedure exist?

Ian Rae



Mon, 02 Feb 1998 03:00:00 GMT  
 Oberon/F modal dialogs


Quote:

>It seems that Oberon/F is a different Oberon way that does not
>share all the same preconceptions and goals of the original way.
>Issues of how to integrate Oberon with the host GUI are extremely
>relevant to me. I know of no other forum to air my concerns.
>Perhaps an Oberon/F-specific list is needed.

A few notes on this:

I agree that there should be sub-forums for oberon, in particular for:
    -  the Oberon System and it's direct derivatives
    - Oberon/F
    - Oberon/Oberon-2, the language
    - anything else that is not of general interest.
There is a strong need for Oberon-2 outside of the Oberon System, let's say as
direct "Competition" for other languages. It should obviously improve the way
programs are written, but I don't see the slightest reason why a properly written
program should not produce a user interface compatible with or similar to other
applications.

It is true that my own system (Amadeus-3, just like Windows'95 promised for
release RealSoonNow) has it's own way of dealing with drag-and-drop and such
stuff, but it DOES support modal dialog boxes, although it does not encourage
their use. I had to add them while developping customer applications. Code
without them would have ended up being more complex, with no visible gain or
any loss for the end user, quite used indeed to modal dialogs.

The unfortunate thing is that some people in the Oberon community tend to be
religious about what should or should not be done with the language. While I am
very dedicated to proper programming practice, I will always prefer to see
someone using Oberon/-2 in a non-orthodox way than using C++.

Therefore, my approach has always been to encapsulate standard stuff in a nice
Oberon-2 OO layer. This way, the standard stuff is supported, the user see what he
likes (or thinks he likes, laking reference to something else/better) and the
programmer is shielded from all the underlying mess (I'll stop here before calling
any names).

Stefan Metzeler, author of the Amadeus suite.



Mon, 02 Feb 1998 03:00:00 GMT  
 Oberon/F modal dialogs

Quote:

> There is a strong need for Oberon-2 outside of the Oberon System,
> let's say as direct "Competition" for other languages. It should
> obviously improve the way programs are written, but I don't see
> the slightest reason why a properly written program should not
> produce a user interface compatible with or similar to other
> applications.

> Stefan Metzeler, author of the Amadeus suite.

Just a reminder: "Oberon-2 outside of the Oberon System" does
exist in the form of the free O2C translator, which you can find on
hades.ethz.ch (when it is back online), or on its mirrors. Commercial
standalone compilers are also available, but this one is free and perhaps
worth giving it a try.

Wojtek



Tue, 03 Feb 1998 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Second Try - Call modal dialog from modal dialog

2. Call modal dialog from modal dialog?

3. Oberon/F modal dialogs

4. modal dialog windows in ENFIN (os/2)

5. Testing MVC application with Modal Dialogs

6. Resizable modal dialogs!

7. How to get a true modal dialog in OS X

8. Menubar not refreshed when closing a modal dialog

9. plainDBox modal dialogs?

10. Proper way to retrieve value from modal dialog?

11. Window-Modal Dialog Boxes

12. Modal dialog boxes

 

 
Powered by phpBB® Forum Software