Re: Linux/X Windows
Monty wrote:
>How about a small animated symbol, like an e rotating in the upper left =
hand
>corner.
If someone wanted to write a spinning icon that ran during the "dead =
air" events, that's fine with me.
>The actual windows buttons, etc, could be chosen from a drop down,
>no?
Technically, it *is* possible. Practically, it's more trouble than it's =
worth. You increase the size of the code, decrease the speed and don't =
really add to the functionality, since you are only changing visual =
appearance.
>One thing I liked about something I saw on Linux, was that users of a
>particular x-windows front end that I saw, had total creativity as to =
how
>their windowing was displayed. It was COOL looking.
X Windows takes a much different approach to controls than Win32. In the =
X Windows world, there are several different layers. The base layer is =
XLib, a set of graphic routines. These can be considered graphic and I/O =
primitives.
The next layer is the toolkit layer. This level defines widgets (what =
DOS folk call controls) using xlib commands. Different toolkits define =
different widgets, and different look and feels. Motif is the "standard" =
look and feel, although there are a number of other libraries out there, =
including a number that adopt a Win95 look. (This is the layer I'm =
currently coding for WinMan.)
The top layer is the window manager. This implements the "window frame" =
that the applications run in. Note that the window manager only defines =
what the window frame looks like - the look of the controls inside of =
the window is entirely dependant on the toolkit. (The demo of WinMan is =
a demo of this layer).
As a result of this organization, an X Windows application depends on =
the toolkit that the user chose to compile with as to how the widgets =
will look, and the window manager the user runs the application under =
for how the window frame looks. It possible to be running several =
different windows, each with different "flavor" controls, because they =
were compiled under different toolkits.
This can also be done in Windows. For example, instead of calling the =
native toolkit, versions of Microsoft Word draw their own controls using =
graphic primitives - essentially emulating the controls. When this code =
is run under Win95, it retains the Window 3.1 look and feel, giving away =
the trick.
If and when Robert decides to port Euphoria to Linux, he'll also have to =
decide which of the X Windows toolkits to include in Euphoria, it any.
If he only includes XLib, someone would have to write a GUI toolkit with =
XLib if they wanted X Windows applications. Since the graphic kernel of =
WinMan only assumes the existance of two graphic primitives (getPixel =
and setPixel), and emulates everything else, a port of this type =
*should* be fairly straightforward.
-- David Cuny
|
Not Categorized, Please Help
|
|
