discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Proposition for a Gorm feature Was: Gorm too complex ?


From: Pascal Bourguignon
Subject: Proposition for a Gorm feature Was: Gorm too complex ?
Date: Mon, 11 Feb 2002 17:48:08 +0100 (CET)

Right now, Gorm saves .gorm files that are GNUstep archives, therefore
an application developed  with Gorm needs to be compiled  and run on a
GNUstep  system, or  at least,  on a  system where  gorm  file reading
classes are ported to.

That is, it does exactly like InterfaceBuilder.

That's for this  exact same reason that I'd try to  avoid its use, and
prefer to write graphical  user interface building code in Objective-C
in the  sources of my OpenStep  programs. It may be  awkward, (until I
grab or write  some class to do automatic layout),  but at least, it's
portable  : I can  compile my  OpenStep programs  on OPENSTEP  4.2, on
GNUstep and on MacOSX.


Now suggestion:

Instead of writting archives of  user interface objects, why not write
Objective-C source code,  that would build this user  interface net of
objects instead of unarchiving them.



I know  that there  is the difficulty  of reading back  this generated
source, to edit  it from Gorm, because the  programmer may have edited
the source form.  There is no general solution here, but we can find a
good enough solution.



I can think of two broad classes of solutions:

    - read and interpret the source. In this class of solutions, there
      are several possibilities, from a very tight one such as:

          - put delimiting comments  around the source code generated,
            and containing an encoded  form of the user interface with
            a checksum of the  source code generated. When reading, if
            the  source code  has  been edited,  put  big warning  and
            caution   dialogs  asking   whether   changes  should   be
            overwritten (or  may be put  in comments) when  saving the
            Gorm edited version.

      And a more flexible one such as:

          - just  try and  read the  (special comment  delimited) user
            interace  source code,  and reject  only stuff  that's not
            understandable as  user interface building  code.  Harder,
            but  this too  let the  programmer edit  or tune  the user
            interface in its source code form.


    - compile the source and run it to build the user interface on the
      fly and analyse it in Gorm. I think that's about what nib2gmodel
      does.  This solution  would have  the advantage  of  letting the
      programmer edit quite freely  the user interface building source
      code.


More "conventions" may have to be  enforced. Such as : having the user
interface  building code  in specific  methods, or  even in  a special
category  such  as  @implementation  NSApplication(GormGenerated)  (or
whatever class to which the  user interface code can be attached), and
stored in separate files from the normal sources.

Note  that  InterfaceBuilder  enforced  that the  actions  be  written
without any  type. If  you wrote -(id)myAction:(id)sender;  instead of
-myAction:sender;, it would not be recognized as an action.



I would not mind  using any specific tool if I can  use the results of
this tool  in whatever platform  I need to  later port and  compile my
sources.


But never again  will I use a tool such as  Interface Builder, even if
it  can reduce  by  ten the  time  needed, if  I'm  later locked  with
it. That's the reason why  I use freedom-enabled software in the first
place.

I know  that having the sources of  Gorm, I could compile  it on other
OpenStep systems and  use such ports to continue  edit the gorm files,
but I  think it would be  even better with the  proposed generation of
user interface in source code form.




-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]