Re: Dream GUI toolkit (Was: GUI programming.)

From: Chris Sonnack (Chris_at_Sonnack.com)
Date: 05/11/04 

Date: Tue, 11 May 2004 13:56:27 -0500

"MSCHAEF.COM" wrote:

>>> makes for 1,310,720 possible window sizes. Are you going to
>>> design a nice layout for each of those?
>>
>> Yes. In exactly the same way--only better, because it's done
>> by hand--as your auto-layout stuff does.
>
> lol... didn't we recently debate this, Chris? :-)

Heh. I think you're right. And I wanna make clear I'm pretty
mellow about this.... re-reading my post..... might have been
a little over the top is spots.... no angst intended, ya?

>> More importantly, I can set limits,
>
> Limits aren't unique to custom authored layout code. Automatic
> layout engines can incorporate quite sophisticated absolute
> limiting mechanisms.

This might be a fruitful path to explore. I'd like to know a bit
more about some of these capabilities.

* At some point, if the window gets too small, what strategy?
* Proportional sizing for some elements (e.g. textboxes), but
  not others. They should be proportionally *spaced* though.
* To what degree can you impose layout rules? For example,
  maybe I don't want related controls "spreading out" when
  the window gets bigger--I want their distances kept. But I
  may want other elements to change.

Might be interesting to define a basic GUI and explore various
ways of doing it....

>> so the re-sizing code doesn't make a hash of things if the size
>> is too small.
>
> This was a problem with early auto layout systems. [...] The
> situation has gotten much better over the last 15 years.

Hmmmm.... "much better" isn't good enough for a visual control
freque like me! Nothing less than total control will do! (-:

>> There are two basic types of window: sizable and non-sizable. In
>> the case of many dialogs, what's there is there and there is no
>> need for the window to be sizable.
>
> Why? Unless you're writing full screen software like your testing
> app below, it's pretty presumptious, IMO, to tell users of software
> that "there's no need for the dialog to be resizable."

What possible value is there in having a simple dialog sizable?
Sizable windows exist for a reason, and if no such reason exists?

I don't subscribe to the unicy theory of total user control. The
GUI of my apps is part of *my* art, and you WILL see it as *I*
designed it. If you don't like it, tough, use something else. (-:

More seriously, try to think like an average user. The less "other"
stuff (meaning stuff not directly connected with what they are doing)
you throw at them, the better.

> Just for perspective, It wasn't that long ago that dialogs were
> fixed in location, too.

There are logical reasons for being able to move a window. I can see
no *logical* reason for making all windows sizable. I just can't.

> Those rules are pretty easy to incorporate in most any auto-layout
> tool. In fact, having done it both ways, I can safely say that
> it's much easier to code this behavior with auto layout than
> without.

In the case in question, I believe you! (It's about a page of code.)

>> As I hope I've shown you, I get the exact same thing, PLUS the
>> chance to see my design as I work on it. I consider that a huge
>> win (obviously, YMV :-).
>
> As I've said before, automatic layout does not preclude a visual
> editor.

I would consider that an even bigger win! This thread started over
the idea that visual==bad, and that's my reason for speaking up.

In fact, that's worth emphasizing: I don't have that much issue
with auto-layout (given sufficient tweak/rule control by ME :-),
but creating a complex layout without seeing it? Why?!?!

> In a broader sense, any WYSIWYG word processor is a visual editor
> with automatic layout (and a couple different layout algorithms),
> too.

Heh, good one! So is a browser rendering HTML.

>> The only real difference I see is that I have to write the resizing
>> code myself, but (personal style!!!!) I prefer having that level of
>> control.
>
> What productivity do you gain by writing the code yourself?

It's not about productivity, it's about control of my art! (-:

Perhaps a quote from my website says it best:

        Like many long-time programmers, I write my web pages
        "from scratch." It's as much art as science, and I
        think it's good to be close to the material. Like
        baking bread from scratch, it's something you chose
        to do because you like it, not because you don't know
        any better. ...

(In a work setting I'm more prone to automate.)

>> See: http://www.sonnack.com/Chris/Software/BigScreen.png
>
> That looks like a perfect application for automatic layout tools,
> although, I would pick one that has a GUI editor to specify the
> design.

To be honest, I can't conceive of how an auto-layout could even
begin to work on that page. May be my lack of experience with
modern layout tools, but every control there is carefully placed
(often to the pixel!).

> Okay, insert a new combobox between the Respirator and Protocol
> combo boxes in the upper left corner of your Big window. From
> what I can tell, that would involve the following operations:
>
> - Move the graph window down
> - Move the left spread*** down
> - Move Protocol and Subject conrols down
> - Enlarge the Test Info group box
> - Insert the new controls
> - Ensure that the new combo box is evenly spaced with the others,
> and that the spacing matches the user interface standards

I don't think so. I think (off the top of my head here) it's:

- make the left spread*** smaller
- enlarge the Test Info frame
- drop the Protocol & Subject combos
- insert new combo
- do something with the Challenge & Detector frames

(Spacing happens automagically--the designer has "snap to grid" as
well as various alignment and spacing selections. (Which I rarely
use, preferring to DO IT MYSELF, DAMNIT! :-))

The thing is, the whole look is "destroyed" now. With a single
new combo, it *might* work to just open the three group boxen to
the right of Test Info, but it might not look right to my eye.
I might determine a new layout is required.

A better solution might involve finding a new place for the ID box.
That wouldn't require any shifts outside Test Info. [In fact, in
reviewing before sending, I think what I'd do is compress the
labels a few pixels so I could get Test Date and ID on the same
line. This would require no other changes. And it's not something
an auto-layout could come up with (AFAIK).]

> And then, you have to go through the rest of the dialog box,
> ensuring that all of the other controls expand or move to
> accomodate the new location of the controls we've already moved.
> That could mean an adjustment to every other control on the dialog.
>
> Or... you could add a line of code to add the new control and let
> the computer recompute the layout.

Frankly, I would be astonished if it could do the job anywhere near
my requirements. I'm not kidding, I am REALLY anal about this stuff!

> From my point of view, if I had spent a couple days designing the
> layout of a dialog box, I'd want it to be more robust in the face
> of what should be a relatively minor change.

Actually, in terms of the app, it's probably not a minor change,
but that's a side issue. I'd say I'm more concerned with the
final look and usability than I am my time re-designing it. The
latter is a one-time cost. "Look and feel" is forever.

>> The design I showed you is particularly built around how the
>> client uses the product (this is the main work screen they will
>> use most of the time they use the app). The location of the
>> controls and readouts is VERY carefully planned.
>
> All the more reason to be easily able to modify during acceptance
> testing and usability studies it to meet customer designs.

I understand your point, I really do. I just can't believe I
would be even slightly satisfied with an auto-layout changing
most of the form because of a single insertion. Nothing I've
*ever* encountered along those lines suggests it would.

But,... just to hammer the point, you're talking to someone who
considers GUI design an *art*. You'll find very few artists who
would agree that auto-layout meets their artistic needs.

>> But, bottom line, as I said, it may have to do with my sense of
>> design (or my sense of control! :-).
>
> Like the time we last discussed this, your position reminds me of
> the folks who resisted compilers in favor of "retaining control"
> by coding entirely in assembly. :-)

Ouch! :-) I think (or wanna believe?) there's a difference. It's
not control for the sake of control (well, maybe a little bit :-).

It's really about getting it artistically perfect. 

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|