Re: Why initialize the menubar without Interface Builder
Re: Why initialize the menubar without Interface Builder
- Subject: Re: Why initialize the menubar without Interface Builder
- From: Erik Buck <email@hidden>
- Date: Sat, 3 Nov 2007 17:55:56 -0700 (PDT)
--- Robert Nikander <email@hidden> wrote:
[Deleted]
> The two things I need are:
>
> 1. "Layout managers", or whatever you want to call
> them.
> 2. A way to use declarative language.
>
[Deleted]
> For #2, I mean that you do not use "imperative" code
> to specify the
> exact order of building the GUI, like I did in the
> example above.
> Instead, the code looks more like HTML, where you
> simply declare the
> structure of the GUI. You could use XML, but I
> prefer Lisp/Scheme,
> so it looks something like this:
>
> (vertical-panel
> (border 5)
> (button (text "OK") (on-click
> do-such-and-such))
> (button (image "/a/b/thing.png"))
> (drop-down-list
> (items "Apple" "Banana" "Orange")))
>
> Now, if I decide that I want a fatter border, I find
> it just as easy
> to change the "5" to an "8" as it is to open IB and
> drag something
> around.
>
> Going further, I can use variables in the definition
> of the GUI, and
> make things more abstract than is possible with IB.
> For example, I
> could define a variable 'dialog-border-width' and
> use it in the
> definitions of all the dialogs.
>
> (define dialog1
> (vertical-panel
> (border dialog-border-width)
> ...
>
> Then I can change "dialog-border-width" in one place
> and change all
> the dialogs.
I am sympathetic to what you want. Your approach is
sometimes used to create cross-platform GUIs. I would
say your argument is analogous to the argument between
Tex users and WYSIWYG editor users.
There are strengths to your approach: Comments can be
included in the code. Syntax and consistency checkers
are possible. Quick preview applications can provide
rapid WYSIWYG feedback for the edit-test-edit cycle.
Version control and merging are both possible and
obvious.
However, several shortcomings of your approach are
common: Magic numbers inevitably appear frequently.
Incomprehensible spaghetti code is too easy to create:
see HTML code sometime. A great many lines of GUI
code often have structure (nesting) that may not be
obvious. Constant text strings are difficult to
localize. Automatically growing and shrinking GUI
components that resize to fit text create a new realm
of unexpected behaviors (menus already do this). Most
layout manager schemes suck, and even when they work
they take layout details out of your control.
Programmers have to spend a lot of time analyzing and
searching in the code to change anything. It is easy
to inappropriately couple GUI components to underlying
application logic. It is difficult to conform to user
interface standards, and every application ends up
looking different even when they are all produced by
the same team. Nobody likes a 10,000 line file...
There isn't a right answer, and just like I respect
(but don't understand) people who write documents with
Tex, I respect your choice to of GUI technology. In
fact, I admire your willingness... To the extent that
you are able to make good compliant Mac OS X
applications, I applaud your effort. Users don't
really care HOW applications are developed. They just
want functioning applications that are a pleasure to
use. Tools like Interface Builder exist to make
programmers more productive. If they don't make you
more productive, I guess I understand why you don't
want to use them. I just think you have to be a very
special person if IB doesn't make you a more
productive GUI developer.
[Deleted rest]
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden