Last week I obtained a RP3 (running LXPanel 0.9.3), and would now like to write my first linux-based dialog/window for it*, using C (or C++).
*I've been writing dialog-based programs on windows for some time now, though not in C(something).
I've been googeling for some time, but can't seem to find a site clearly describing what needs to be done together with a reasoning for it. As such I get the feeling I willl mistakingly take the wrong path (for instance, I have no intention in installing another window manager).
tl;dr: Does somebody know of a site and/or example code outlining how to write a dialog/window on RP3 running LXPanel 0.9.3 ?
On Mon, 20 Nov 2017 15:04:39 +0100, "R.Wieser" declaimed the following:
The display manager shouldn't matter, except in terms of look&feel disconnects.
You'll have to decide on which GUI framework you intend to use -- for example: QT, GTK(+), wX. From some comments found via Google, LXDE is based upon GTK, so for best match to look&feel, GTK may be the target.
GTK
formatting link
wX (C++)
formatting link
wX (Python)
formatting link
QT
formatting link
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
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.
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 ?
... though the need(?) for a framework would explain why I could find nothing when I googled for LXPanel.
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 ?
I've seen that name a couple of times, but always assumed it was (yet) another window manager bringing its own junk along (and possibly clashing with the one already present).
[snip links]
Thanks, I'll take a look at them as soon as I've send this post off.
The framework provides a lot of the tedious code already done for you.
When you draw a window on the screen, say, 400 pixels wide by 300 pixels tall, with the words "Hello, click my button" and a button 70 pixels wide by 50 pixels tall that says "HERE", do you want to think about all
12,000 pixels that were just drawn? Do you want do deal with re-drawing the parts that get covered and then uncovered by another program? Do you want to parse font files yourself for drawing the letters? Do you want to draw the curve of the button corners and the shadow, and design the look of clicking on the button?
Chance are, no. You want an interface that says "draw me a 400x300 window, give it the text "Hello, click my button" in the main text area, and put a button in the usual location with the word "HERE". When someone clicks the button, call this function. That's what a framework gives you, and different frameworks will have different looks and libraries of basic windows. Plus widgets for making non-basic windows with more sophisticated interfaces.
Use the Xt interface for a very basic way in. The X11 source code has examples. Things like xclock, xeyes, xcalc, xev, those sorts of programs.
It's a strange world down there. It's object oriented code written in C, and predating C++. Learning that makes it very easy to see how C++ evolved from a C preprocessor.
Windows was designed to support a GUI, so the DLLs provided with Windows have those functions. Linux wasn't, so you need to install extra DLLs to get the GUI functions. I haven't tried many of the available packages. wxWidgets seems to follow the Windows programming style very closely, except (?) that it's designed to be called from C++.
On Mon, 20 Nov 2017 18:17:01 +0100, "R.Wieser" declaimed the following:
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 (
formatting link
). 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.
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
formatting link
the normal "window manager" for LXDE is OpenBox.
Which set? Windows has the base win32 api
formatting link
, but for C++ it provided MFC (microsoft foundation classes
formatting link
). Newer stuff focuses on the .NET framework
formatting link
. There are also other less known:
formatting link
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
formatting link
formatting link
formatting link
formatting link
formatting link
If you really want the lowest common denominator, you are looking at pure xt (X-Toolkit) on top of xlib
formatting link
and
formatting link
(which used to be documented in something like 7 O'Reilly books, each of about 900 pages
formatting link
). 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
formatting link
-- 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/
On Mon, 20 Nov 2017 18:43:40 +0000 (UTC), Eli the Bearded declaimed the following:
Has anyone?
It was near 30 years ago that I ended up writing about 2500 lines of C for DEC's variant of X -- DECWindows -- with GKS embedded!, another 2500 lines of user interface language describing the application, and about 500 lines of F77.
The requirement was to replace a RAMTEK 9300 graphics engine -- but the original applications[s] could not be rewritten; the F77 was to mock up all the RAMTEK primitive calls into messages sent via VMS mailboxes to the C program which interpreted the messages. GKS was needed for the display list feature, as one could not ask the operator to rerun a 30-minute application to refresh the display -- and the F77 application consisted of some 30-odd dedicated programs which connected to the graphics engine to display [plot axis and labels were handled by one program, then another program would fill in the plot, another program would be run to define a rubber-band region, etc.]; GKS display lists allowed rapid replay of the sequence that rendered the image.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
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 ?
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.
One vote for GTX, and now yours for Xt. Pros and cons ?
:-) Tell me about it. My preferred language is Assembly, and I've disassembled enough programs to amaze myself about whats going on below the surface.
Same answer to you (as to Eli): If Linux does not have/expose them (by default), how the heck can its own programs display themselves ? No, something definitily does not compute there ... :-|
The only thing I can conclude is that either those controls are available without a framework being present, *or* that such a (minimal?) framework has already been installed (by the OS). In that last case, how do I figure out which one it is ? And in the first case, where are they ?
Just be aware that there are far more options for a GUI framework than that. The granddaddy of them all is the Athena widget set distributed with X11, there's also SDL, fltk and a bunch of others - and you can even go down to the Xt library but you'll be doing a lot more work that way building widgets from scratch.
None of this is special to Raspberry Pi though, it's all portable stuff.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Linux (the kernel) does not have and, therefore, cannot "expose" a GUI API.
The kernel, if compiled with the appropriate options, does, however, expose an API to an optional in-kernel "direct rendering infrastructure" that gives appropriately-permissioned user-space processes the ability to draw pixels on a display device.
User-space libraries (DLLs, to the Microsoft crowd) provide a number of abstraction levels that builds on the kernel DRI "draw a single pixel" facility to provide line-drawing, polygon drawing, colour-fill-polygon drawing, fonts, boxes, inputboxes, messageboxes, windows, icons, and the rest of the "GUI" that you are looking for.
There are a variety of these libraries; The X Window system includes a number of (line draw/polygon draw) primitives ("Xlib"), as do the other windowing platforms. On top of these primitives, other user space libraries have built boxes and windows (a couple of names include "QT" and the GIMP ToolKit ("GTK" and "GTK+") .
Nope. They need a framework.
If, by "minimal", you mean "draw a pixel", then yes. If you mean something more complex than that, then no.
Mu. Your questions assume facts not in evidence.
To answer you, pick a framework. You probably already have QT and GTK installed, but if they aren't sufficient, try the Enlightenment Foundation Libraries ("EFL"), or (the old-school) Xlib.
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
As someone whose first GUI was written in assembly on an Apple ][e, I'm very happy to not deal with pixel placement anymore.
Under X, there are no "original" styles. But the Athena widgets in Xt provide a baseline style. X11 provides an interface for drawing "windows" and receiving "events" related to those windows. A button is a window. And a mouse pointer moving onto the button is an event. (Probably lots of events, the enter window event being first, then lots of mouse movement events. Clicking the button will be two events, a mouse button down and a mouse button up. But because of all those mouse motion events, you can create "buttons" without using subwindows.)
Xt is very basic. It seemed like that's what you wanted. GTX is much more modern, and will probably have native code for things like "put a PNG image on a button" and support for modern fonts.
You can, and I have, do X11 interfaces entirely over sockets with no direct linking to X11 code. When I did it, I used a "Pure Perl" (no compiled parts) X11 module. I tried, but could not squeeze it into a four line sig, instead needing five:
use X11::Protocol;$X=new X11::Protocol;END{$X->FreeGC($G);undef$X}map{$$_=$X-> new_rsrc}(W,F,G);$X->event_handler('queue');$X->CreateWindow($W,$X->root,'Inp' .'utOutput',$D=$X->root_depth,'CopyFromParent',(0,0),300,30,4,'event_mask',01, background_pixel=>2**$D-1);$X->CreateGC($G,$W);$X->MapWindow($W);$X->PolyText8 ($W,$G,25,28,[0,'Eli the Bearded:Just Another Perl Hacker']);$X->handle_input;
That was a long time ago, and I seem to recall newer versions of X11 were unhappy with that code, but I don't recall why.
Elijah
------ had a little bit of fudge room to change code length for margin line up
And again: If that library is needed to be able to create a window, how come Linux can already display its own dialogs (filebrowser, console window)
*without* having such framework libraries installed ?
Logic dictates that there either is already a basic set of windows/controls available, or such a framework is already installed. In either of both cases, how do find out and I access it ?
I'm open to any other explanation though.
Its not about who handles whom, but where the controls come from. Its stands to reason they come from the same spot, as having everything double is silly/stupid, and having it all in one spot makes sure a change to the general style will than be reflected in both the desktop as well as the programs running on it.
The one you get without installing anything extra ofcourse (which I'm also talking about here). And yes, thats reflected in that first link you posted.
On Mon, 20 Nov 2017 21:43:43 +0100, "R.Wieser" declaimed the following:
I suspect we are overlapping comments
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.
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).
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/
LXPanel uses the GTK+ GUI toolkit[1], so I'd recommend writing your code to use GTK+[2]. Read the API documentation and Howto Guide[3] to see what you need to do.
HTH
[1]
formatting link
"lxpanel is a lightweight GTK+ based panel for the LXDE Desktop."
[2]
formatting link
[3]
formatting link
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
Many UNIX/Linux programs do not use a GUI -they are command-line programs. The next step up from there is termcap/terminfo and curses.
termcap makes programs running on 24x80 greenscreen terminals independent of the actual terminal in use. There were very many terminal makes and models, each with its own escape code sequences used to control the cursor and keypress sequences for Fn keys etc. Termcap/terminfo support databases of the codes used by each type of terminal, thus making your program independent of the terminal type its user is logged in from.
This was never visible on a PC because IBM supplied the PC keyboards and screens and later, when PCs began to be supplied by third parties, they continued to use IBM terminal control codes. That's why you've seem to have never seen this type of software before.
Those of us who were using microcomputers before the IBM PC was released were aware of differing types of terminals because, even if a program could be run under, say DR-DOS, on several types on microcomputer, it had to have some way of being configured to use the terminal attached to the machine.
Stepping on up, the UNIX world also had curses, a function library that sat on top of termcap/terminfo and made it easy to draw menus, boxes, and pop-up windows on 24x80 greenscreen terminals.
After graphical terminals became common some time in the mid/late '80s, i.e. somewhat before the Apple Lisa and Mackintosh with monochrome GUIs appeared and well before Windows 3.1 was dropped on top of MS-DOS, UNIX grew the X-terminal package.
As others have said, everything with a GUI interface uses roughly the same component hierarchy to interface programs to graphical screens. The only difference is that Windows and Apple don't really admit that it exists or explain how it works, while UNIX has always made this explicit and so has Linux, which was initially written by Linus Torvalds as a cleanroom reimplementation of UNIX, has naturally done the same.
The great thing about Linux is that there is almost never a single 'thing' implementation. Different distros use different windows managers (i.e. desktops) and there are several GUI toolkits. At least one is favoured by each programming language and most of these support more than one GUI toolkit (wx, gtk for C), AWT, Swing and fx for Java, Python has its own toolkit, COBOL will use something else,....
So grin and get used to it and get stuck in: this is how life works outside the Windows mothership.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
I'm not sure how "cleanroom" Linus' Linux was or is now, but that doesn't matter. X11 was not "cleanroom" reimplemented for Linux, it was one of several existing Unix GUIs that was ported to Linux. (I've also "used" MGR on Linux, an alternative to X11 that predates Linux. I used it for a couple of days, and never tried it again.)
X11 is vastly different from the windowing systems of the time it was created. Under X Windows there's explicit support for:
multiple users on multiple screens on one system (tricky to do under Linux, because of separating keyboard / mouse inputs). But if you want to, you can to a new virtual console and start a new server (it will be :1 instead of :0)
window server and applications running on different hardware -> different from mirroring a desktop, you could run just an xterm from a remote host, with everything else local -> I recall a guy in the mid-90s who ran a screen full of load monitors, each one running on a different system -> it also explains how systems like Xquartz can manage windows when it doesn't control the "desktop"
complete separation windowing server from window manager
All this stuff makes X11 a complex environment and much different from Windows or Apple's GUI.
Oh god, DON'T use either of them. If if something for personal use QT are the way to go. Also if C/C++ are not mandatory I suggest something easier: Python.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.