1. Portable GUIs
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).
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.
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.
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).
This is clearly a feasible - take a look at StarOffice, for example. All the
controls (including the window controls such as the titlebar, close button,
and so on) are rendered by the StarOffice application, not the native OS.
The result is an application that has an identical look and feel on both the
Windows and Linux platforms. Even Microsoft uses emulated controls - witness
older version of Word render dialog controls with a 3.1 look and feel under
Windows 95.
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.
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
2. 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
3. Re: Portable GUIs
>
> 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.
>
In order to get the one button mouse to be possible, one could consider using
one of the modifier keys and mouse click together, to simulate the right mouse
click and right mouse double click. The modifier keys are: Control, Shift,
Option, and Command. The most common way is to use Option-click for the right
mouse click. While right mouse double click is very rare, but one can still use
Option-double-click to get it done.
==
Want to get paid while surfing the Web? It's free!!
Go to http://www.alladvantage.com/go.asp?refid=GIW867
Electronic Kid Stories: http://www.genesis.mb.ca/bible/
Home: http://www.idrive.com/phed/web/
_____________________________________________________________
Add web search or discussion boards to your home page today!
----------------- http://www.everyone.net ------------------
4. Re: Portable GUIs
Everett Williams wrote:
> 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.
My point remains the same: any portability would be coincidental of Delphi
being ported, not of the code being intrinsically portable.
> Depends on how low that LCD is. Sometimes there can
> be a lot of utility in such an approach, especially
> for business oriented code.
I agree in principle. In practice, users demand a fairly rich API, and will
prefer to use a larger and non-portable API over a smaller and portable API.
> Only functional equivalence is required here.
I think you miss my point. There are points where toolkits may initially
appear to have equivalent functionality, but in practice the actual
implementation of the controls makes them virtually incompatible.
> An emulation on top of a simulation is how I
> have heard Star office described. Definitely
> high overhead.
But the GUI is not part of that high overhead and sluggishness. Once
StarOffice is actually loaded, the response time and behavior of the
controls is indistinguishable from a native control.
> Sounds wonderful. If I can help, I will.
Thanks. I'll need all the help I can get.
> Will these perform with sufficient speed to be usable
> in ordinary machines like 200 mhz Pentium-class machines?
So now my P200 is merely 'ordinary?'
The answer is 'yes.' I used to have a demo supplied with Win32Lib called
CUSTOM.EXW that emulated the following controls:
- command button
- toggle button
- picture button
- radio button
- check box
I don't think the demo is still included, since it used some API calls that
are now obsolete. These controls had an identical look and feel to the Win32
controls, and as far as I could tell, were indistinguishable from the real
things.
Admittedly, those controls are the simplest to emulate. A more complex
emulated control is the editor in the Win32Lib IDE. I use an emulated
control there so I have full control over the syntax coloring. It's a little
bit sluggish, because it recalculates (and redraws) each line with each
keystroke, so you have dynamic syntax coloring. Even VB waits until the end
of the line before recoloring the line.
> If DOS works, this should be a sure thing.
DOS portability is a low priority for me. All the features that are already
supplied by window managers (clipping, fonts, window management) all have to
be emulated in DOS. That makes is a real resource sink of the project, and I
don't think that there's that much demand for a DOS version anyway. I've got
enough code lying around from other projects that I'll probably code it up
eventually.
> Speaking of events...how does one code up asynchronous
> functions within Euphoria's base, portable paradigm?
Real window managers queue up events, so this is only a problem under DOS.
For Dos32Lib (a partial port of Win32Lib to DOS), I polled the mouse state,
rather than waiting for mouse events. That way, if a mouse event (button
release, button pressed, mouse moved) occured while an event was being
processed, the state would be re-synched when the code entered back into the
polling loop.
-- David Cuny
5. Re: Portable GUIs
Everett Williams replied:
> 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.
My point is that Damien is not *intrinsically* portable. Portability would
be based on a coincidental port of Delphi to another target environment.
> Depends on how low that LCD is. Sometimes there can
> be a lot of utility in such an approach, especially for business
> oriented code.
I agree conceptually. In practice, users tend to demand a fairly rich
toolkit to compete with the bloated, feature-rich applications.
> An emulation on top of a simulation is how I have heard
> StarOffice described. Definitely high overhead.
The response time of the widgets and windows (once the mess is finally
loaded) is indistinguishable from native speed. It's not the GUI toolkit
that slows things down.
> Will these perform with sufficient speed to be
> usable in ordinary machines like 200 mhz
> Pentium-class machines?
So my P200 is now 'ordinary'? *sigh*
The short answer is, yes.
There was a program called 'custom.exw' that was distributed with Win32Lib
(it may not be in the current version, because some routines are obsolete)
that displayed emulated:
- radio buttons
- checkboxes
- command buttons
- toggle buttons
- picture buttons
The response time is fine.
Perhaps the most complex control that would need to be emulated would be the
MLE widget. For a fairly unoptimized example, take a look at the editor in
the Win32Lib's IDE. The response time is a bit sluggish, primainly because
it performs syntax coloring on every character keystroke (you might notice
that VB puts off syntax coloring until the line is completed).
> If DOS works, this should be a sure thing.
Coding to DOS has actually been a mistake for me in the past, because I'd
get hung up on writing window managers, text display and metrics, line
clipping - something already provided by all window managers (Win32, XLib)
in the first place. It would be a nice benefit to have a DOS version of the
code, but I'm not going to concentrate on it.
> 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?
Again, all the real windowing environments manage this automatically for
you. It's only working with DOS where it becomes problematic. In DOS, you
end up in a tight event loop:
while True do
-- look for a keystroke
-- look for a mouse event
end while
and hope that the event handlers don't take too long. Take a look at
Dos32Lib for an example. You might notice that it polls that *state* of the
mouse, so the state of the mouse (move/button up/button down) stays in
synch, even if the actual event happened while an event was being handled.
-- David Cuny
6. Re: Portable GUIs
Someone wrote:
> > Depends on how low that LCD is. Sometimes there can
> > be a lot of utility in such an approach, especially
> > for business oriented code.
>
> I agree in principle. In practice, users demand a fairly rich API, and
will
> prefer to use a larger and non-portable API over a smaller and portable
API.
>
True. I think GraphApp is about the lowest-common-denominator, working
on Win/Linux/MAC, and iirc, one or two of the controls had to be emulated
even then.
There really are a lot more controls/widgets/whatever you choose to call
them,
that should be added to get from the LCD to a point where most people will
be
satisfied. We're spoiled, I guess.
Regards,
Irv
7. Re: Portable GUIs
I think that there is a distintion between a portable GUI and a portable
graphics library. My understanding of a GUI ( graphical user interface )
is to interface to the the user in a form that has the same look and feel
no matter what system is being used. The GUI does not have to be a speed
demon but must appear and function in the same way on any OS. The GUI of
course uses a graphic library but the GUI should be emulated in the
graphics library (whether it's portable or not) that is running on that
OS. My main point is that if Euphoria needs a portable GUI then the
discription and definition of the GUI has to be established. Then it
would be easier to emulated a GUI on each OS.
Bernie
8. Re: Portable GUIs
Bernie Ryan wrote:
> I think that there is a distinction between a
> portable GUI and a portable graphics library.
Yes; they are two seperate layers.
In my prior attempts, there was no clear demarcation where the library left
off and where the GUI began. This caused problems when the library and the
user shared the same calls. I don't intend to repeat this mistake.
Note that this sort of toolkit doesn't solve issues like printing.
PostScript in Linux is probably the easiest solution here.
-- David Cuny
9. Re: Portable GUIs
Phed wrote:
>>
>> 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.
>>
>
>
>In order to get the one button mouse to be possible, one could consider using
>one of the modifier keys and mouse click together, to simulate the right mouse
>click and right mouse double click. The modifier keys are: Control, Shift,
>Option, and Command. The most common way is to use Option-click for the right
>mouse click. While right mouse double click is very rare, but one can still use
>Option-double-click to get it done.
>
Thanks for making my point for me. It doesn't work the same and it requires
various techniques to bypass the difference. These techniques make the
functional equivalence rather than the complete equivalence.
Everett L.(Rett) Williams
rett at gvtc.com
10. Re: Portable GUIs
On Mon, 6 Dec 1999 12:49:52 -0800, Cuny, David at DSS <David.Cuny at DSS.CA.GOV>
wrote:
>Bernie Ryan wrote:
>
>> I think that there is a distinction between a
>> portable GUI and a portable graphics library.
>
>Yes; they are two seperate layers.
>
>In my prior attempts, there was no clear demarcation where the library left
>off and where the GUI began. This caused problems when the library and the
>user shared the same calls. I don't intend to repeat this mistake.
>
>Note that this sort of toolkit doesn't solve issues like printing.
>PostScript in Linux is probably the easiest solution here.
>
>-- David Cuny
How about ghostscript instead...it is both portable and free.
Everett L.(Rett) Williams
rett at gvtc.com
11. Re: Portable GUIs
> >>Note that this sort of toolkit doesn't solve issues like printing.
> >>PostScript in Linux is probably the easiest solution here.
> >
> >>-- David Cuny
>
> >How about ghostscript instead...it is both portable and free.
>
> >Everett L.(Rett) Williams
> >rett at gvtc.com
>
> It's not the same. PostScript is the file format (in reality, a complete
> programming language that is embedded in some printers or graphic
> displays).
> ghostscript is a translater that takes a PostScript file and translates it
> in a readable format for a printer (or screen).
> it also works in console mode, as a PostScript interpreter.
> Ghostview and GV are graphical front-ends built on top of ghostscript to
> make a PostScript (and PDF) viewer.
>
> Riwal Raude
> rauder at thmulti.com
12. Re: Portable GUIs
Raude Riwal wrote:
>> >>Note that this sort of toolkit doesn't solve issues like printing.
>> >>PostScript in Linux is probably the easiest solution here.
>> >
>> >>-- David Cuny
>>
>> >How about ghostscript instead...it is both portable and free.
>>
>> >Everett L.(Rett) Williams
>> >rett at gvtc.com
>>
>> It's not the same. PostScript is the file format (in reality, a complete
>> programming language that is embedded in some printers or graphic
>> displays).
>> ghostscript is a translater that takes a PostScript file and translates it
>> in a readable format for a printer (or screen).
>> it also works in console mode, as a PostScript interpreter.
>> Ghostview and GV are graphical front-ends built on top of ghostscript to
>> make a PostScript (and PDF) viewer.
>>
>> Riwal Raude
>> rauder at thmulti.com
I believe that you are absolutely right on this one...did not think thru before
opening trap. Ghostscript will however make use of postscript output on
any available printer workable. I have also seen some free text to
postscript converters on the various platforms.
Everett L.(Rett) Williams
rett at gvtc.com
