On Mon, 20 Nov 2017 21:43:43 +0100, "R.Wieser" 
declaimed the following:

 I suspect we are overlapping comments 

>
>Hmm ...  And than how do the programs currently present on RP draw their
>windows and buttons -- without such a framework already being present (as I
>seem to need to download and install it before being able to do anything) ?
>I don't think each program will carry its own
>draw-a-button-one-pixel-at-a-time -code, do you ?
>
 Typically, not as part of the program itself. The equivalent of a
Windows DLL is a Linux SO (shared object) library.

 The program(s) include references to the libraries that they link to at
run-time. Typically, if you install a program/application using the
distribution's package manager, it should also result in installing the
appropriate libraries if they don't already exist.

>But granted, a framework might take some tedious work outof a programmers
>(my) hands.  But I do not think for a minute that that framework is
>responsible for low-level stuff like drawing and handling a window and/or
>button.
>
>... unless that framework wishes to create its *own* style of windows and
>other controls.   But than the question remains: where are the
>standard/origional controls kept.
>

 As one of my recent posts (buried in URLs) points out:

 xlib provides operations for drawing lines, boxes, and maybe defining
regions which are to respond to mouse events.

 X11/xlib  does NOT HAVE "standard/original" controls -- it only handles
connecting to a display server and transmitting very low level graphics
commands.

 Xt (X Toolkit) defined an API for the behavior of things like menus,
buttons, text boxes... But it too does not implement the drawing of those
controls as a "standard" -- that responsibility is passed to the higher
level framework (Motif being a common one); Xt just handles responding to
events passed up from xlib as defined when the widget instance was created
(that is, it knows that a mouse click "in this region" maps to "some widget
instance" and passes on a configured event identifying the widget).

 Also mentioned, most of the newer frameworks do not make use of Xt --
which means they are not limited to the widget set for which Xt provides an
API -- instead going directly to the xlib layer. In all cases, the
framework library is responsible for telling xlib how to draw each widget
using simple "fill box", "draw line vector", etc. The framework is also
responsible for taking "mouse button 1 down @ x, y" and determining which
widget is at that location (that's the functionality that Xt provided).

 Also, each application only knows that it has a drawing region of X/Y
size -- the "window" itself is handled by the window manager program
running on the display server. It is the window manager that "knows"
application A is located at position x1/y1 and translates application
drawing instructions into x1+x/y1+y. The window manager doesn't really know
anything about window widgets/contents -- it only cares about which window
is on top, and sending redraw requests to applications if a window is
uncovered by changing focus or moving an upper layer window.

 Since LXDE is based upon the GTK+ framework, the requisite libraries
are probably already installed -- but you might have to install the GTK
development header files (compiled applications don't need access to the
header files, only the shared libraries).

>> Use the Xt interface for a very basic way in.
>
>One vote for GTX, and now yours for Xt.  Pros and cons ?

 As described, Xt/xlib is the very basic library set -- and you will
have to provide the needed information for how to draw widgets since Xt
only provides a standard widget API.

 Xt widgets, as I recall, rely upon the use of call-backs (with a
framework provided event-loop function). Some frameworks may rely upon the
user coding an event-loop/dispatch function (I tend to "think" in
event-loop mode, but that is due to my experience with the Amiga).
--
 Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

--- SoupGate-Win32 v1.05