[GUI] CGA Proposal

[Axel Simon]

On Sunday, Aug 17, 2003, at 14:44 Europe/Paris, Krasimir Angelov wrote:

>    Hi Axel
>
> In the GIO, wxHaskell and Yahu libraries doesn't have
> distinction between readonly and read-write arguments.
> I don't advocate the usage of different types for
> readonly and read-write arguments.

I think we should make another distinction between
"mandatory" and "read-only" arguments. We said
that mandatory elements have to be given as
explicit argument as you do in the "newControlApp"
function for the ApplicationVersion or DocumentInterface.
Both are read-only, but I doubt that they should be
mandatory. The interface should be simple. A
programmer shouldn't need to supply the
appMDIHint attribute since it can default to
something (say SDI).

>  The usage of then
> single Attribute type makes thing more simpler. In
> order to make 'appClass' and 'appMDIHint' attributes
> readonly the following functions should be changed:
>
> newControlApp :: ApplicationName
>               -> ApplicationVersion
>               -> DocumentInterface    -- mdi hint
>               -> [Prop ControlApp]
>               -> IO ControlApp
Ops, no DocumentInterface parameter for ControlApp. The point is
that ControlApp are not centered around documents and that there
is only one main window.

>     The main function will like:
>
> main = do
>   initCGA
>   app <- newControlApp "test" "1.0" SDI []
>   ...
>   ... create another widgets
>   ...
>   startCGA app
>   doneCGA
>
>     The disadvantage is that the application should
> pass the 'app' value to all functions which need to
> create windows, dialogs or utility windows. Why don't
> use simple function like this:
>
> main = start "test" "1.0" SDI [] $ do
>   ...
>   ... create widgets
>   ...
>
> In this proposal the application instance is created
> implicitly. The access to the instance is possible
> through the global function.
>
> app :: Application

One argument for the first approach is that it an application
is treated similar to widgets. But since there is only one
application, your solution is a way to simplify things. How
do others think about this?

>
> There isn't distinction between Document based and
> Control based application. When the programmer defines
> the first document template then the library will
> automatically create and manage the required
> predefined menus. If there isn't defined any document
> template then the programmer is free to create its own
> menus.

Wow, I haven't thought about making the distinction
between control and document based application on
the fly. Maybe that's the way to go. I wonder if it is
more difficult to understand.

BTW, your "DocumentTemplate" shouldn't contain
callbacks. Callbacks should be installed by
calling functions "onBlah :: (data -> IO ret) -> GUIElement -> IO 
CallbackId"
so that they can be detached with the CallbackId if needs be.

>
> --- Axel Simon <A.Simon@kent.ac.uk> wrote:
>>>    - The primary window is explicitly created.
>> That
>>> means that the application can have many primary
>>> windows and each of them owns the menu bar. This
>> is
>>> possible under Windows and GNOME but is impossible
>>> under MacOS where the menu bar owned from the
>>> application. What will happen if the programmer
>>> forgets to create the primary window and try to
>> create
>>> a menu bar? Under MacOS this is OK but under
>> Windows
>>> and GNOME this will cause runtime error. My
>> proposal
>>> is to have primary window only under Windows and
>>> GNOME. The primary window is implicitly created
>> and in
>>> SDI and MDI mode it is owner of all windows (with
>>> exception for dialogs and utility windows). In
>>> controled SDI mode each window will be top level
>> and
>>> the primary window will own only the menu bar and
>> the
>>> utility windows. An example for application with
>>> controled SDI interface under Windows is the
>> Delphi
>>> environment and the GIMP under Linux. The MacOS
>>> application doesn't have a primary window because
>> the
>>> menu bar is owned from the application and all
>> windows
>>> there should be top level.
>>
>> The user should either create one ControlApp or one
>> DocumentApp and
>> nothing more.
>
> Ok. But this leaves open the question for primary
> window. Why the programmer need to explicitly create
> it? The MacOS applications doesn't have primary
> window. I think that the primary window should be
> internal for the library implementation and should
> exist only under Windows and GNOME. That means that
> the 'newPrimaryWindow' function should be removed.

How is the CGA under Windows and GNOME supposed to
know which window will take the menu bar in case the
user uses the ControlApp variant?

>
>> A comment on your implementation:
>> One thing which we discussed in spring is that the
>> CGA should not
>> manage state whatsoever. As such having "Document a"
>> where "a" is the
>> type variable taking on the state is not right. To
>> be type safe you
>> need to thread this type variable through all CGA
>> functions that might
>> handle the state, especially functions to register
>> callbacks.
>
> Why do you think that this is type unsafe? The
> Document type is much like IORef type.
>

Not quite. IORefs do not use existential types.
I think it is possible and cleaner not to model any
state. At least this will leave the organization of
the application's state space up to the programmer.
I don't feel too strongly about this.

Cheers,
Axel.