[GUI] Dynamic ... something

[Axel Simon]

On Sat, Apr 12, 2003 at 04:25:35PM +0100, Glynn Clements wrote:
> 
> > Something like:
> > nib <- loadAppleNibFile_MAC "foo.nib" -- a nib file is a document 
> > created by Apple's Interface Builder and contains one or more dialogs
> > dialog <- createDialogFromNib_MAC nib "MyDialog"
> > If "MyDialog" doesn't refer to a dialog in the file, a runtime error 
> > occurs...
> 
> For UIL, you also have to provide definitions for any attribute values
> which can't be specified inside a UIL file (e.g. pointers, callbacks). 
...so you're saying you cannot connect to widgets in the UIL files if you
haven't specified a correspoinding attribute for the callback? We have
to find some common ground for resource files and I doubt that Apple's
NIB and Windows resource files can contain callback attributes. Is it
not possible to retrieve a widget from the resource file and then add
a callback to it? 

> Allowing fixed-coordinate layouts is an open invitation for people to
> write code which only works correctly on their system; they will just
> tweak the numbers until it looks correct with their preferences.
I agree with that. On the other hand it would be nice to provide some
simple layout mechanism which people can use for prototyping or in
case they don't care. It would be brilliant if this layout could then
later be overridden by resource files.

Maybe we could stead the algebraic data description of the layout
structure from ObjectIO:

  dia <- createDialog "ApplicationClose" (...the layout in terms of Haskell code...)
  case dia of
    (Dia d (VerCon [_,HorCon [buOk,buCancel]])) -> do
      onActivated buOk quitMain
      onActivated buOk (destroy d)

And if the user bothered to supply an external resource file, the layout of
the "ApplicationClose" dialog would come from there.

> Of course, people may ultimately decide that native l&f is just too
> much work, and abandon it. It's certainly an option. But, if native
> l&f is abandoned, it should be a conscious decision, rather than a
> accidental consequence of not realising what's involved until too
> late. Also, it makes it less likely that the end result will actually
> be the one-and-only UI library; if Haskell is around long enough,
> eventually someone may want native l&f badly enough to implement a
> library which provides it.
Well, if it is possible, we should aim at having native l&f right now.

Wolfgang wrote:
> 5.) some conversion of platform-specific formats to Haskell code
> (frankly, I fail to see the point)
Was that my point? Well I think it might be important for commercial
products to hide the user interface in the code, the application might
be quicker to start and last but not least every resource is resolved
statically at compile time.
But maybe this can be up to each individual toolkit.

Axel.