Re: Portable GUIs
On Fri, 3 Dec 1999 17:28:58 -0800, David Cuny <dcuny at LANSET.COM> wrote:
>Everett WIlliams wrote:
>
>> Damien looks as if it has the potential to be the
>> most important, portable tool that we have available
>> to us for development other than the base language itself.
>
>It's not clear to me that Damien is a portable tool. Any portability would
>be reliant on the base library (Delphi). For that matter, Win32Lib is hardly
>cross-platform either.
>
>In fact, it's not clear to me how portability to platforms such as the BeOS
>or Macintosh can be achieved by third parties, since neither seem to support
>DLLs. For these operating systems, it would be up to Robert to supply the
>hooks. (The Mac might be an exception, in that Robert could possibly give
>hooks to calling the toolbox directly).
Yes, but Delphi on Linux is bound to have very similar calling sequences
to Delphi on Win32. The distance might be short enough to be masked
by some simple code based on the platform variable.
>In any event, it seems to me that a truly portable toolkit would not be
>reliant on native widgets at all. The problem with using native widgets is
>that you can only support the controls that are common to each platform,
>leading to a least-common-denominiator sort of solution.
Depends on how low that LCD is. Sometimes there can be a lot of
utility in such an approach, especially for business oriented code.
>Another problem with native widgets is that each platform may implement
>features just differently enough to be incompatible with the other platform.
>For example, in Win32, any menu item can be checked. By way of contrast,
>GTK+ and Swing require that the menu item be 'checkable', and display an
>checkbox (appropriately checked/unchecked) next to each to menu items so
>designated.
Only functional equivalence is required here. Complete equivalence where
the mouse has only one button instead of two or three(for example) is
never going to be possible, even in an emulated GUI.
>The most portable library (it seems to me) would be an emulated GUI. All the
>controls (pushbuttons, checkboxes, radio buttons, menus, scrollbars, lists,
>status lines, tooltips, etc.) would be drawn by the library. The native OS
>layer would provide a relatively small number of services, such as:
>
> - create windows
> - graphic methods for drawing controls
> - report events such as mouse clicks, key presses, etc.
>
>One nice thing about this sort of approach is that the native OS layer is
>typically fairly thin, since the OS already provides these sorts of routines
>(DOS is an exception).
>
snip
>
>An identical look and feel is also not a requirement of emulated GUIs. Qt
>can emulate both the Windows and Motif look and feel, and Java's Swing
>supports Metal (it's own), Windows and the Macintosh Platinum look and
>feels.
>
>The sluggish response of StarOffice is *not* the fault of using an emulate
>GUI. In fact, emulated GUIs are often the fastest cross-platform toolkits,
>because they involve less layers.
An emulation on top of a simulation is how I have heard Star office
described. Definitely high overhead.
>In any event, at the risk of tipping my hand, this is the sort of thing that
>I've been experimenting with lately. I don't have anything presentable yet,
>but the results have been encouraging. I've been able to run the same
>emulated controls in three different platforms (Dos, Win32 and X Windows).
>The application is sort of a cross between my WinMan library (which emulated
>controls) and Llama (which is makes it easy to extend the library without
>hacking the core routines.
>
>If and when I'm convinced I have something workable, I'll post the complete
>source and hope I can convince other people to work on it with me. Unlike
>Dos32Lib, I no longer have the urge to write the complete system myself.
>
>-- David Cuny
Sounds wonderful. If I can help, I will. Now for some operant questions that
I am sure that you have already asked yourself, but just for the record...
Performance - You build a set of well defined, callable Euphoria routines
that represent the GUI and the events that you wish to manage. Then you
build that "thin" set of Euphoria routines that use highly machine
dependent code. Will these perform with sufficient speed to be usable
in ordinary machines like 200 mhz Pentium-class machines? If not, at
what level do they become usable, and is that level representative of
enough machines to make it a "generally" usable tool. If DOS works, this
should be a sure thing.
Speaking of events...how does one code up asynchronous functions within
Euphoria's base, portable paradigm? The only legitimate event that one
can wait on is a keypress, any keypress. Otherwise?
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
