[GUI] CGA Proposal

[Axel Simon]

On Thursday, Aug 21, 2003, at 10:35 Europe/Paris, Krasimir Angelov 
wrote:

>
>>> 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 current HToolkit implementation still doesn't
> support abstraction for documents, but the
> DocumentInterface is necessary. Maybe the type should
> be renamed to ApplicationInterface. The interface
> specifies a way in which the windows are created. For
> example the SDI permits only zero or one created
> windows while the MDI permits many openned windows.

I think this is a misconception. SDI and MDI are just ways to
present multiple documents. If you open another document
in an SDI application, you get a new window. An example of
this is the Internet Explorer where each web document is
displayed in a separate window. I consider the SDI/MDI
distinction to be about presentation, nothing else.

>
>> 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.
>
> The advantage of this approach is that in that way the
> programmer doesn't need to be responsible for the
> creation of predefined menus.

How is this different from the setup where the programmer
specifies the type of application in the beginning?

>
>> 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.
>
> I don't understand this.
>

We discussed on this list that the programmer needs to be
able to disconnect callbacks. Thus giving the callback
functions as attributes

set [onClicked := putStrLn "I'm clicked", onCllicked := putStrLn "Here, 
too"]

doesn't work since there is no way to disconnect just the second
callback. The same holds for supplying callbacks in your
DocumentTemplate data structure.

>>> --- Axel Simon <A.Simon@kent.ac.uk> wrote:
>
>>> 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?
>
> In both ControlApp and DocumentApp the library is
> responsible to create the primary window and only it
> knows the primary window handle. The menus are always
> placed in the primary window.

Well, then I guess you have some magic function by which
the user can actually access the primary window and fill it
with content.

It seems that you tend to automate a lot. IMHO the
programmer should be in charge of what happens
and how it happens. If too much happens by
magic, it will be hard to learn how to use the GUI API
and where to change things if they don't fit the
programmer's idea of presentation. I think the
programmer should initiate everything. If (s)he
wishes to apply magic and create everything in one
step, (s)he should call a function for that. Otherwise
(s)he should call functions to create the individual
user items bit by bit.

>> 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.
>
> I think that the documents model which I propose is
> the most simple way to handle documents. The
> programmer is always free to use other state
> representations.

Hm, maybe, maybe not. I will raise the state issue next week.

Cheers,
Axel.