[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Menu (Was: Re: Unimplemented AppKit classes)
From: |
thomas |
Subject: |
Re: Menu (Was: Re: Unimplemented AppKit classes) |
Date: |
Thu, 23 Jan 2003 06:31:08 -0600 |
User-agent: |
Internet Messaging Program (IMP) 4.0-cvs |
I apologise for the previous message. I wrote while in a hostile mood. Please
disregard my emotional context.
I am keeping a cooler head from now on.
-Thom
Quoting Thomas Cherryhomes <thomas@openminds.tv>:
> 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
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep
- Re: Menu (Was: Re: Unimplemented AppKit classes), (continued)
- Re: Menu (Was: Re: Unimplemented AppKit classes), Stefan Urbanek, 2003/01/23
- Re: Menu (Was: Re: Unimplemented AppKit classes), Pete French, 2003/01/23
- Re: Menu (Was: Re: Unimplemented AppKit classes), Nicola Pero, 2003/01/23
- Re: Menu (Was: Re: Unimplemented AppKit classes), Stefan Urbanek, 2003/01/23
- Re: Menu (Was: Re: Unimplemented AppKit classes), Pete French, 2003/01/23
- Re: Menu (Was: Re: Unimplemented AppKit classes), Nicola Pero, 2003/01/23
- Re: Menu (Was: Re: Unimplemented AppKit classes), Helge Hess, 2003/01/24
- Re: Menu (Was: Re: Unimplemented AppKit classes), Nicola Pero, 2003/01/24
- Re: Menu (Was: Re: Unimplemented AppKit classes), Nicola Pero, 2003/01/23
- Re: Menu (Was: Re: Unimplemented AppKit classes), Thomas Cherryhomes, 2003/01/23
- Re: Menu (Was: Re: Unimplemented AppKit classes),
thomas <=
- Re: Menu (Was: Re: Unimplemented AppKit classes), Pete French, 2003/01/23
- Re: Menu (Was: Re: Unimplemented AppKit classes), Nicola Pero, 2003/01/24
- Re: Menu (Was: Re: Unimplemented AppKit classes), Thomas Cherryhomes, 2003/01/24
- Re: Menu (Was: Re: Unimplemented AppKit classes), Nicola Pero, 2003/01/24
- Re: Menu (Was: Re: Unimplemented AppKit classes), Helge Hess, 2003/01/24
- Re: Menu (Was: Re: Unimplemented AppKit classes), Nicola Pero, 2003/01/24
- Re: Menu (Was: Re: Unimplemented AppKit classes), Alexander Malmberg, 2003/01/23
Re: Unimplemented AppKit classes, Nicola Pero, 2003/01/21