> I have thought a bit about this, and perhaps we should switch to the
> more generally accepted term: "Dialog".
> Popups are really something else...

I'm not sure if Allan already did this renaming, but I strongly agree
that we should use the term "dialog".

>       - work on the painter
>         (get asger to tell be what the painter/painterbase lack to
>            work on more platforms/toolkits)

Basically, we should reduce the painter tremendously.
The old painter had methods for drawing lines, cirlces, arcs, and what
not.  Those were used for three things:

1) Drawing our own accents when we lack the screen fonts
2) Drawing math characters
3) Drawing table frames, inset-frames, vfills, hfills and so on

Now, 1) and 2) should not be done in client code, but rather in the
painter itself.  The painter should export a Unicode draw-string interface
and internally use whatever means to draw the characters on the screen.

So, what we are left with is 3).  For this, we only need lines and
dotted lines, and those lines are horizontal or vertical.

So I propose that this is what we provide. Not general lines.
If we restrict ourselves, the task of porting the painter is
made much easier. In particular, an ncurses port is suddenly
not completely insane.

--

For Allan:

Regarding the abstract dialog base class:

Normally, we distuingish between these different things:

1) Create dialog and destroy dialog
2) Show and hide dialog

These things are not the same thing and should be kept separate,
when we consider the issues.
The lifetime of a dialog could go like this:

Create
Show
Hide
Show
Hide
Destroy

Create
Show
Hide
Destroy

Now, consider modal dialogs.  Modal dialogs are special.
On Windows it's not possible to show/hide modal dialogs
as you want to. In effect, for modal dialogs, create and
show are one operation, as is hide and destroy unified
to one operation.

The best solution for this problem is to only provide
a create+show call, and a hide+destroy call.
Then it's up to the individual dialog to preserve and
reuse any dialog if possible.
But the interface should not provide separate create and
show methods, because this is not (easily) possible with
some toolkits.

Greets,

Asger

Reply via email to