Re: Babble about Win32Lib
>Personally I won't bother with platform independence... raise your hand
>those that are using MacOs (2 or 3), those using Linux (10 to 15), those
>using Windows (500 or more). Anyway I hope you succeed supporting all those
>platform.
Hmm.. I would like platform independence for the reason of 'elegance' and the
'compatibility' with future versions of windows,
and simply the different type of design. And actually for many more reasons.
Including program design.
Actually, there are many issues with 'so-called' portable GUI's.
Color issues, when the standard colors are changed, the size of every line, etc.
are all handled by the OS.
A portable GUI would only work if it gave in at one of these points:
- platform 'adaptence' .. force the precise same look... (or somewhere in
that direction) .. on both the Mac and Win32 it
will look 100% the same, for each pixel. However of 99/100 tools that they use,
your tool's buttons will look
slightly different. Your tool's menu bar.. slightly different. People don't like
that, or at least I don't.
- precise planning of controls .. if the interface handles the exact layout
of the window, and is only given an 'estimate'
of what it should look like, and how it should operate.. it will 'adapt'. This
has the advantage that it will look correctly
everywhere.. regardless of the screen-font size (Color Draw's tutor for example
wouldn't work with my font-size.. which was
'large' at the time) .. regardless of the size of the window, the resolution,
etc. However, a programmer no longer has the
'freedom' to be able to precisely plan its layout pixel-perfectly.
The last is type of 'sacrifice' I do want to make, although I will only rely
upon very elegant 'layout-generators'.
David's WinMan for example, is much more the direction where I would like to see
Win32Lib head.
No more precise layout. The layout is measured and setup by the library,
possibly using preferences of the end-user.
An example of a different type of layout: Docking Vs Windowed. (I personally
hate multiple windows, but love dock-bars,
especially when they can collapse, etc.) Dock-bar type of windows have an even
huge advantage that currently only some 'huge'
packages have discovered. It allows the end-user to modify and setup its working
space as it likes.
And the layout of say 'Data-forms' or 'Input-forms' ... (you can't have
everything as a separate moveable docking bar, can you)
could be
defined it the way 'HTML' defines its layout. The use of virtual percentage.
Surely the design of certain forms are more work
than the design of an exact layout like, for example, Visual Basic offers, but
the future and platform portability, and the
freedom for the end user to modify its 'windows-look' should be convincing. Not
to mention visually disabled persons, that use
extra large fonts, etc. For them the layout is *either* wrong, or when its
partly adaptive (a typical case with VB programs) its
unusable. How many of you have never used a program that was designed for a
different font-size or different screen-size ,
meaning you couldn't see part of the program and it became unusable ?
Here is, as an inspiration, a GUI design I, as an programmer and end-user of
many windows-tools, would love.
On the top level, you'll need some form of 'container' control. The only allowed
control at the top-level. (it defines the look
of the window/etc)
It can either (and optionally) float, dock or pop-up (= disappear when a
'default' action occurs)
Even on the top-level it should be able to dock, however then at the
screen-edges, similar to a toolbar, or Icq docks.
A pop-up would be like a window, without title-bar etc. that would disappear
after the 'default' action. (say, pressing enter).
A program can spawn child 'containers', you can dock these to any other
container (including of another Eu-program .. 
or to
the screen edges if docking is allowed. When its a pop-up, docking nor moving is
allowed. A titelbar is lacking as well with
pop-ups as well.
In other words, containers do *not* contain other containers. Containers are the
primal block, and all of them are on the
*top-level*.
However, they _are_ called containers, what do they contain ?
They contain a layout-file .. which is a piece of text (optionally a text-file
thus) which contents is shows. The idea behind
such a file-specification should be 'inspired' by both Pdf/Adobe's Portable
Document File and by Html/Hyper Text Markup
Language. HTML files, like Pdf, resize and adjust their layout when you resize
the window, or want to print a pdf-document using
a non-standard paper-size. In a similar way, I would like a
'layout-specification'. It may sound weird, several different files
for each part of the interface of your program, but during development (hmm.. a
special convert to include file tool would be
handy?) something like that is extremely handy.
Buttons, check-boxes, radio-boxes, etc. are examples of the controls offered in
such a language. Off course controls should be
easy to add.
Not into the layout-file though. In the layout-file the name of the control
would be specified and an error message would occur,
when a control is missing. Off course NotePad or TextPad is not ideal for layout
development, but such a file-specification
would at least make the layout independent of the editor. WYSIWYG editors could
off course still, maybe even easier, be made.
Notice though that WYSIWYG also means what-others-see-is-what-they-get.. ... but
editors like DreamWeaver and HotMetal prove
that dynamic layout and 'WYSIWYG" can be united.
Now, people, please tell me what you think ? Wouldn't this be the idea basis for
a 100% easy to setup and use interface
library/tool/standard/specification that offers portability, yet also offers a
great and useful, customizable interface ?
Ralf
|
Not Categorized, Please Help
|
|
