Re: Fonts in .gorm files

[Marcus Müller]

On Thursday, Jun 12, 2003, at 13:55 Europe/Berlin, David Ayers wrote:

> Well my personal experience of having to maintain an app that has .. 
> (let me count) 336 nibs (and that's just one of the two active 
> versions, I'm maintaining) is that nibs (NSCoding based archives) are 
> harder to maintain.  This is an EOF app where the UI layout consists 
> of texfield, combo boxes and table views grouped and aligned.  And 
> believe me, if other pre conditions where different, porting 
> Renaissance to OS 4.2 and converting 95% of those nibs to gsmarkups 
> would be high on my priorities, because pixel counting for a 
> consistent UI expierence is just far to time consuming.

I agree that EOF applications are pretty hard to maintain, mostly 
because all required associations are usually hidden from view and need 
to be checked by selecting all views. But, usually that's an issue (but 
a big and annoying one) only when porting UIs between platforms (i.e. 
OPENSTEP, Rhapsody and Mac OS X). I did this once for Lamento 
(http://www.mulle-kybernetik.com/software/Lamento) and know how 
troublesome a task that is.

From what you are telling I conclude that the interfaces are probably 
very similar among each others. I agree that building interfaces with 
Gorm is a waste of time considering this repetitive task and 
Renaissance might be a better choice, as the interfaces could be 
constructed on the fly. However, that's a pretty special case.

> > Gorm could be used as a WYSIWYG editor I think. How one would 
> > graphically handle the layout constraints imposed by the box layout 
> > system in Gorm is another question, though. It could be done similar 
> > to the way the 'guiders' work, but probably indicating 'destination 
> > boxes' instead.
>
> This seems like a proposal of an(other) autolayout system independent 
> of Gorm and Renaissance.  Yet both (or one, or another tool) would 
> have to support it.

Ah, I didn't make this clear enough. What I meant is that Gorm could 
well be able to read/write Renaissance files and suit as an editor for 
the autolayout system. You'd need a new palette sporting the special 
layout elements and have a fancy way of visualizing 'layout in advance' 
if you drag an element from a palette and drag it to its intended 
destination. Most likely, you'd also need another window visualizing 
the views' hierarchy etc.

> It's all about choosing the right tool for the task at hand.

I agree. Most of the time people seem to underestimate the complexities 
of autolayout systems, thouh. Because it really annoys me from time to 
time I *had* to raise the issue! ;-)


Cheers,

  Marcus

--
Marcus Mueller  .  .  .  crack-admin/coder ;-)
Mulle kybernetiK  .  http://www.mulle-kybernetik.com
Current projects: finger znek@mulle-kybernetik.com