Re: Fonts in .gorm files

[David Ayers]

Marcus Müller wrote:

> I wonder how those UI's will look if your system font is 100pt. ... 

That depends on whether the UI design took into account that users with 
impaired vision and large fonts may also be using thier application.

> Personally, I don't think that a box layout system is a guarantee for 
> good looking UIs under all circumstances.

I most likely isn't, I was just stating that it would meet the stated 
requirement to guarrentee the text fits into the controls. (even if it 
turns out, that it wasn't an actual requirement.) It doesn't gurarantee 
that the resluting window can be displayed on a 800x600 display. :-)

> Also, UI's done with box layout systems in my experience are way 
> (much!) harder to design than with Interface Builder/Gorm - and 
> usually even experienced UI designers had their troubles with it (I 
> know it from Swing, personally). This is contrary to what most people 
> do believe. Usually the argument is along the lines that because boxes 
> are a clean and well structured approach it's much easier for 
> programmers to design such UIs. Also, it seems to be widely believed, 
> that programmers have no design skills and with box layout systems 
> wouldn't be required to have such talent - so it's obviously a better 
> approach. In my experience the constraints imposed by each box/layout 
> styles have lots of subtle interactions that are at times very hard to 
> understand - not to mention to solve. I've spent several hours solving 
> issues in Swing that never occured to me in Interface Builder on 
> OPENSTEP/Mac OS X. On the contrary, I never felt I could have designed 
> something easier using a box layout system. 

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.

> Interestingly, the whole problem is hard to notice at first, because 
> box layout systems appear to be easier to understand as they are 
> 'cleaner' structured. Go design a complex UI with both approaches and 
> see for yourself. 

I must admit, that don't have nearly as much experience in maintaining 
autolayouted UI.  Yet we had our own autolayout engine within another 
project, and the reusults were very usable.  HTML also can produce good 
results for the right content type.

It all depends on what you are trying to do.  I'm not saying Renaissance 
solves all thinkable UI design issues.  It does solve the "make control 
big enough to fit the text" issue.  (And after I sent my mail yesterday 
I realized that I believe Renaissance /could/ also produce a WYSIWYG 
layout, if the coordinates are made explicit in the gsmarkup file 
(losing the the "make it fit"-effect), but Gorm seems to be the better 
tool to accomplish this.) And loading .gorm files should generally be 
faster that gsmarkup.  (Eventhough that also depends on how complex the 
gsmarkup is, as those files can omit a lot of information that .gorm 
must store.)

> 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.

> There is one real advantage of Renaissance over Interface 
> Builder/Gorm, however: Renaissance interfaces are truly cross platform.

It's not so much "plattform" as base/Foundation and gui/AppKit 
indpendant, but yes, I know what you mean and this is another 
requirement that Renaissance fullfills.

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

Cheer,
David