Re: Menu (Was: Re: Unimplemented AppKit classes)

[Thomas Cherryhomes]

Ok, this is the last straw, I have to reply to this issue of methods of UI
description.... 

Quoting Pete French <pete@twisted.org.uk>:

> > Yes, it is possible to write and then play ... Have you ever tried
> 
> Umm, yes - it sounded horrible :-)
> 
> > See my previous comments.
> 
> Its a difference in philosophy - see also LaTeX vs Word, which is
> a far better analogy. Interface Builder just encourages people to put
> thought into where precisely the objects should go... when it is the
> relationship of those obejcst to each other which is actually important.
> 

The relationships of the objects ARE important, which is why NeXT went through
GREAT pains to design the InterfaceBuilder to most efficiently describe these
relationships. I mean, how hard is it to connect the dots?

> Obviosuly I dont advocate writing an interface wiuthout seeing what it
> looks like, that would be ridiculous. But is the dragging and shuffling of
> items graphicly that I think is a misatke - because most of the time
> that isnt theproblem you are truying to fix. If you want all yoru text
> fields left aligned then the solution is to represent that cocnept as such
> in the file- not to shuuflle them all over so they happen to line up
> visually ? Thats completely the antithesis of object orientated programming.
> 

Umm... you're equating a programming methodology with a visual design
methodology, these two concepts are orthogonal to each other. You can design a
precise layout application for a non object-oriented environment as well, so
what's your point? 

> Shifting to using Renaissance is the same sort of shift as going from
> a Word processor to using LaTeX. But when you are usedto thinkin about
> the contnet rather than the appearance it is a lot faster... and there
> are big wins in terms of portability; which is where we came in - the
> unportability of IB / Gorm files.
> 

Once again, this is programmer wisdom solving a problem that doesn't need to be
solved. WE HAVE COMPATIBILITY AT THE API LEVEL. Why must we try to describe
interfaces for TWO DIFFERENT platforms that have TWO DIFFERENT user interface
design principles, using the SAME mark-up? 

Let me drive this point home even further:

RENAISSANCE HAS TO DIFFERENTIATE BETWEEN THE TWO DIFFERENT MENU LAYOUTS! What's
the point of a single mark-up when you have to do things twice, anyway? It
simply does not take long to do proper nibs for a given UI...

once more, as you are designing these UIs, you can SEE how they will fit
together, both aesthetically and in the relationships between objects.
 
> What you really want is a graphical editor for Renaissance files which
> allows visuallayout, but using the Renaissance objecst to do it. Then
> thats the perfect soution I feel for both parties.
> 

And this brings up another point...Why do we need to waste time writing ANOTHER
editor? 

It seems the only concrete advantage that can be proven in all cases is the
human readability of the file format. 

I would like to close as saying that as a trained visual designer, I see the
current direction that Renaissance is heading as far as visual layout is
concerned is disturbing. I moved away from other toolkits for their brain-dead
approach to box based layout. I moved to GNUstep and Gorm for its emphasis on
visual correctness in UI layout. I will continue to use Gorm for my UI needs, I
will NOT use Renaissance. 


> -bat. [an old luddite with a VT100]
> 
> 

-Thom [also has a VT100]

--
Thomas Cherryhomes
OpenMINDS Research

> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep