On Mon, 20 Nov 2017 18:17:01 +0100, "R.Wieser" 
declaimed the following:

>Dennis,
>
>> The display manager shouldn't matter, except in terms of
>> look&feel disconnects.
>
>I hope you ment "window manager" where you said "display manager", otherwise
>I you have just introduced yet another thing I need to investigate. :-\
>
>And I'm sorry, but it is.  My RP3 already has a window manager, and I would
>not like it to spend energy on trying to figure out some API, only to
>discover that LXPanel is using another.
>
>And yes, that is the state of my (lack of) knowledge in this regard I'm
>afraid.  I have no idea what I'm looking at and/or if its important or not.
>
>> You'll have to decide on which GUI framework you intend to use
>
>And thats another.  What does such a framework *do* for me that I can't do
>(read: write) myself ?  I mean, if some already existing program on my PI
>can display a window with a button, whats than the problem with me calling
>the same (library) functions ?    What do I need such a framework for ?
>
 The framework IS the "library" -- but there are different libraries
available which all take different approaches on how to implement
applications and wrap the underlying OS features (for much of its life,
that meant hiding the raw xWindow system calls -- though Linux seems to
phasing away from xWindow (X11 -- was designed to be a network
client/server system where graphical terminals were the server, and clients
running on a main system would connect to send display instructions; the
server ran the window manager locally as clients could be on multiple
computers; But now, the server and client are typically the same computer,
so the network traffic overhead is getting high) to something called
Wayland ( https://wayland.freedesktop.org/ ). Widgets in a framework have a
certain look&feel (though some try to render looking like whatever is
native to the OS). They also have differences in what are directly
available and what the programmer has to create manually.


>... though the need(?) for a framework would explain why I could find
>nothing when I googled for LXPanel.
>

 LXPanel itself is just the program that handles the LXDE "desktop"
"panels" -- the toolbars or whatever at the top and bottom of the display.
LXDE is the entire "desktop environment", and per
https://en.wikipedia.org/wiki/LXDE the normal "window manager" for LXDE is
OpenBox.

>And before you wonder, I've been programming Windows dialogs/windows that
>way.  Without a framework, just calling the - already existing in the basic
>OS - DLL functions.    Doesn't Linux have something comparable ?
>

 Which set? Windows has the base win32 api
https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx
, but for C++ it provided MFC (microsoft foundation classes
https://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library ). Newer
stuff focuses on the .NET framework
https://en.wikipedia.org/wiki/.NET_Framework . There are also other less
known: https://en.wikipedia.org/wiki/Windows_Template_Library for example.

 You've probably been using something like Visual Studio -- with its
drag&drop design of a window layout generating code templates to be filled
in.

 Linux takes its background from UNIX -- and was not a "from the ground
up graphical environment" (unlike the Amiga [in fact, the Amiga had no
"text-only console" -- even the boot-console display was running as a
graphical window], original Macintosh/Lisa, and Atari ST ). Graphics was
built up on top of basic UNIX capability (what became the X-Window System).

 Drag&drop layout isn't native to Linux. There are some GUI designers,
but many work by generating a descriptive file of the window, which has to
be loaded by the application program to generate the run-time structures;
some may generate actual template code in some favored language. These
designers are also framework specific
https://en.wikipedia.org/wiki/Graphical_user_interface_builder
https://en.wikipedia.org/wiki/Glade_Interface_Designer
https://en.wikipedia.org/wiki/Qt_Creator
https://en.wikipedia.org/wiki/WxGlade
https://en.wikipedia.org/wiki/WxFormBuilder

 If you really want the lowest common denominator, you are looking at
pure xt (X-Toolkit) on top of xlib
https://en.wikipedia.org/wiki/X_Toolkit_Intrinsics and
https://en.wikipedia.org/wiki/Xlib (which used to be documented in
something like 7 O'Reilly books, each of about 900 pages
https://www.librarything.com/series/The+Definitive+Guides+to+the+X+Window+Syste
m
). xt provided "standard" advanced widgets above the xlib graphical drawing
operations. Note in the diagram of the Wikipedia article that GTK+ and Qt
both go directly to xlib, while the older Motif goes through xt to get to
xlib. Take notice of the section at
https://en.wikipedia.org/wiki/Xlib#Other_libraries -- xlib does not do
widgets, it is only the low-level drawing and event handling interface; Xt
defines an API for widgets, but leaves the higher level framework (Motif)
to draw them. Also not how window managers are at the bottom tallking with
the display server process -- and not to the applications from the top. The
basics are that any X11 based application (using any of the {red}
frameworks can execute with windows shown by any window manager -- but as
I've mentioned, the look&feel may not be the same (as a simplistic example
-- one framework may use square-corner buttons while another uses rounded
corners; one may change color for a depressed button while another may just
reverse the shadows to make it look sunk inwards. The window manager is
concerned with telling applications when to redraw their window, and
routing keyboard/mouse events to the window with the focus).

 Applications make framework calls to specify widgets; the framework
makes calls to xlib to draw the widget; xlib passes drawing commands to the
display server which updates the display, possibly with the aid of a window
manager.
--
 Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

--- SoupGate-Win32 v1.05