How to write a dialog in C for RP3 running LXPanel 0.9.3 ?

Lew,

Yes, *every* OS does.

The question now is if I need to add it, or if its already delivered as part of the OS.

And if its already delivered as part of the OS, how do I determine which one is/ones are installed, and which one of them is activily used (I assume its not a good idea to just use several at the same time - if only to keep a consistant look-and-feel theme wise)

And than going back to my origional question:

"How to write a dialog in C for RP3 running LXPanel 0.9.3 ?"

... and forgive me the superfluous/non-relevant info in the above please.

By the way, I found many folders with GTK and QT in its name, just one gtkcompat.h file, and quite a few qtgl*.h (GL -> 3D graphics?) ones.

Regards, Rudy Wieser

Reply to
R.Wieser
Loading thread data ...

Eli,

I can imagine, the same here. Though I remember bresenham's algorithm fondly, both figuring out how it worked as well as implementing it.

Comparable to the draw event and the event handling in Windows I guess.

:-) I take it it sounded like that.

But in fact I have no problem with using an high(er) level API, provided the API is delivered as part of the basic OS. Its just that a) I'm a stickler for portability, and b) I first want to explore what the OS can do for my by itself. When I've done that there is time enough to explore what all I can add to it.

To me that does not sound odd at all. You just have to send the correct command-codes and arguments. Alike you did not need to have a terminal in front of you to be able to send ANSI cursor-control codes to it and have it respond accordingly.

Regards, Rudy Wieser

Reply to
R.Wieser

Richard,

Thats what I though too. So, I challenged the people who told me I should download a "framework", and got nowhere fast ... :-\

How can I pick something when I have no clue what I'm looking at/for ?

It still feels like just picking a random door (which all look the same to me), stepping into a dark room beyond it and than absorb whatever will happen. Which is not really what I like. :-\

Regards, Rudy Wieser

Reply to
R.Wieser

Dennis,

...

Exactly. So there is *no* need to download a framework, as the neccessary libraries are already there.

Thanks, thats worthwhile to know.

and that too. :-)

Now *that* makes sense. The libaries making up the framework are already there, I just need a few things to make the compiler happy.

That means I think I will start with GTK, and have a look at Tx later.

I did the same for Windows, until I realized that only the *posted* messages went thru the message-pump loop (the "send" ones do not).

Regards, Rudy Wieser

Reply to
R.Wieser

Lew,

Thanks for those links. Will follow them after I've replied to everyone here.

Regards, Rudy Wieser

Reply to
R.Wieser

Several suggestions have been made in this thread, at least some of them with arguments for/against particular choices. You will have to evaluate those suggestions using whatever strategy you feel most comfortable with, same as if you were making any other choice. If I was an expert on GUI programming then I might be able to tell you to make a particular choice with some confidence, but in fact of the sensible options I?ve only used one (GTK+).

--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

Martin,

Yup. My very first program is such a console-based one: flipping a gpio bit (using 'sysfs') to drive a LED.

I've already taken a peek at the latter.

Remember ANSI.SYS for DOS ? I do. :-)

Thats why I was specific in mentioning which environment I was aiming at (see the subject line) -- even though I did not name the OS itself.

Thats going to take me a bit more than a few days I'm afraid (first program on the RP3 last sunday, first encounter with this newsgroup yesterday).

Hmmm... Thats exactly what I'm trying to do here. :-)

Regards, Rudy Wieser

Reply to
R.Wieser

Jack,

If its in the basic installation of the RP3 I will most likely, at some time in the future, take a look at it. But why do you prefer it above the other two (pros and cons) ?

If it where *my* choice I would have started in Assembly. Does that tell you enough ? :-)

But as the OS offers C/C++ as the lowest I have to make do with it. Besides, I don't think there are many people who still program Assembly, and thus very few people here who could aid me in my first steps ...

And yes, I've seen that Python offers a lot of stuf outof the box. But to be honest ? I would feel like I would be taken for a ride, not having much control over what happens. But yes, I will most likely take a look at it too.

Regards, Rudy Wieser

Reply to
R.Wieser

there will already be at least 1 framework installed which is used by the DE/DM in use IIRC LXDE as used by the py uses the GTK framework

Tat is Exactly what it Does

There are no standard/original controls as you think of the term Linux is not a grapical operating system the GUI is a program running on top of the OS (to the user this is not visible) & gives various advantages

--
You canna change the laws of physics, Captain; I've got to have thirty  
minutes!
Reply to
alister

Been there, done that. Its functionally equivalent to termcap, but without the indirection through a library of terminal capabilities and without the line drawing and windowing abstractions of curses.

IIRC (its been a long time) when using ANSI.SYS your program had to assemble the (VT100-like) command strings to, e.g. set inverse video or move the cursor while with termcap/terminfo there are functions which accept a capability plus parameters and send the completed command string to the terminal. The 'capability' is the two-character ID of a parameterised command string used by the terminal. The $TERM environment variable identifies the terminal type, and for example, the 'cm' capability is the cursor control string.

If you like having reference books, you may find a copy of 'Linux in a nutshell' or 'UNIX in a nutshell' useful.

It assumes you have working knowledge of working with command-lines in another OS, so is a fairly condensed guide to using the Bourne (sh) or Bourne-Again (bash) command shells and the more common utility programs.

bash is now the de-facto standard command shell and there are a shedload of utilities which are written using the UNIX principle that a utility program should do just one thing and do it well. Beyond that, we have shell scripts and the structures they implement (conditionals, loops, pipelines, functions) and use them to assemble specific task-oriented programs from one or more of the utilities.

Example: if you consider that a reasonable estimate of the number of statements in a C program can be made by counting the lines that contain semicolons, then here's a script that counts statements in a C source file:

#!/bin/bash grep ';' $1 | wc | awk '{ printf("%d statements\n", $1) }'

The first line says that it is to be executed by the bash shell. The second line is a pipeline:

- grep reads the file whose name is the first parameter of the script and outputs only the lines containing a semicolon

- wc reads lines received from grep and outputs a line containing line, word and character counts in its input

- awk reads the line output by wc and prints the first value in it as a line that shows "99 statements".

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

The intention behind wxWidgets was always to provide a cross-platform high-level GUI library. The design has clearly been influenced by Windows GUI code (in particular Microsoft's MFC) but I wouldn't say that it follows a Windows programming 'style' ... rather that both wxWidgets and MFC use some of the same C++ language features to provide high-level APIs wrapping built on top of the lower-level toolkits provided by the system.

The main Linux version of wxWidgets is built on GTK+ (wxWidgets uses native controls wherever possible, and implements controls itself in terms of lower-level primitives only where it needs to implement a control that is missing from the low-level toolkit but present in other versions of wxWidgets). As the OP is running "LXPanel" (which is a component of the LXDE desktop environment, which what Raspbian's PIXEL essentially is ... so I guess Rapsbian is his OS) GTK+ will already be installed on his machine, which means that using wxWidgets will not involve changing Window Manager or Desktop Environment, or anything else.

wxWidgets is written in C++, but it has well-established and fully-featured bindings for other languages -- Python, in particular -- so Python is definitely an option (though the OP did express the intention to use C or C++).

[Much the same is also true of Qt, but Qt may not already be installed on the OP's Pi.]
--
Cheers, 
 Daniel.
Reply to
Daniel James

formatting link

Reply to
Rob Morley

Neither.

It is not part of the OS; it is part of the optional userspace programs and libraries that you may choose to install or not, at your convenience.

/You/ don't need to add it. You have already chose to install it, when you chose the GUI environment you use. Clearly, you already have it; LXPanel uses it.

I get a glimmer - for "OS", you mean "whatever distribution of kernel and userspace software I have installed". To me (and to many here), "OS" means "kernel".

That will depend on your "OS". Look for the package manager tool (if you have one), and query it.

FWIW, they /all/ might be "actively used". But, at least you know that GTK+ /is/ actively used.

Consistency issues aside, there is no reason /not/ to have applications that use different GUI toolkits/frameworks.

Pick a toolkit. Read it's API and HOWTO documentation. Follow it's example programs. Write your dialog. Any more detail will depend on what, exactly, you want to do, and which toolkit you select.

Sorry, but I can't make any suggestions here. Perhaps someone else can help.

--
Lew Pitcher 
"In Skills, We Trust" 
PGP public key available upon request
Reply to
Lew Pitcher

On Tue, 21 Nov 2017 11:54:22 +0100, "R.Wieser" declaimed the following:

Not necessarily -- The RPI Raspbian is running a version of LXDE which is based upon GTK+. The development files (C-headers) may not be installed and need to be downloaded; only the runtime library is installed.

Secondly -- some applications may be using a different framework, and hence those runtime libraries had to be downloaded and installed when the application is installed. Again, development headers wouldn't be installed.

Linux does not have a "native" GUI (and embedded Linux tends to have NO GUI of any type). Who ever packages a distribution for a device either selects a default desktop, or makes an installation system from which the user selects a default. It is possible to have two accounts on a Linux box with each account using a different desktop (though if one uses a graphical login, the window manager will tend to favor whatever is "default" for the system, but once logged in all windows/menus may be in the style of the user's selected scheme.

And depending upon the application choice one has installed, one may have libraries for multiple frameworks on the machine.

If you want to use the Xt functions, you will be using a different widget framework (Motif, Athena) -- since GTK, Qt, and likely WxWindow all skip the Xt layer and talk directly to xlib.

I have a Debian Stretch install running in a virtual machine on my Win10 box. Looking at the package manager for it I have packages from the GNOME desktop environment (a PS/PDF viewer, LibreOffice-GTK2), KDE desktop environment (runtime, KATE [editor]), Xfce desktop environment (almost all packages since that is the common desktop being used by Debian). If I were to write a GUI Python application, I'd likely have to install some WxWindow libraries -- as I have a few books on using WxPython, none on using GNOME/GTK or Qt.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

In the most minimal installations of Linux there is no GUI at all just a text mode command line interface.

If the installation includes a GUI along with window manager or desktop environment then there will be at least one framework included in the installation, often there are several pulled in by different applications. The machine I'm currently using has Xaw3D (Athena), fltk, GTK2, GTK3, MESA (OpenGL 3D graphics), Open Motif, QT4, QT5, SDL, SDL2 as well as the low level X-Windows libraries installed and being used by various applications - I might have missed some.

The package manager included with the installation will give you a list of installed packages which will include any and all GUI frameworks installed - there's almost certainly a GUI interface to the package manager installed too.

Pick a framework, read the documentation (there are tutorials for most if not all of them) for that framework and proceed.

The key takeaway here is that RPI-3 and LXPanel are not in the least bit relevant except to note that LXPanel apparently implies GTK so you will certainly have that installed. Once you have written your application it can be compiled and run on any machine with GTK (or whatever).

GTK is a popular framework used by a great many applications so getting to know it is well worthwhile if you intend to write GUI applications, so if I were you I'd go with GTK (whichever version you have), type GTK tutorial into my favourite search engine and work through the hits until I found one I was happy with.

--
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/
Reply to
Ahem A Rivet's Shot

There's a terminology problem here, the reason things like GTK and QT are called frameworks is that they consist of several libraries providing everything from basic widget handling to high level functionality such as UI designer applications or image format support.

I'm afraid it is very much like that, however take some heart from the fact that all of these frameworks provide very similar functionality in broadly similar ways (well OK there are some quirky ones) - get one under your belt and the next is easier. It's a lot like choosing a programming language - you can do most things in most languages so if you don't know any of them and you want to do something it's hard to pick which one to for but in the long run it doesn't matter much because anything will get you started.

--
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/
Reply to
Ahem A Rivet's Shot

Alister,

Exactly. The controls are already there. No 'framework' installation needed. Now its just a question of how to use them in an to-be-written program. :-)

What makes you think I was thinking about the term 'Linux' ?

My POV was-and-is, as mentioned both in the subject line as well as peppered thruout this thread, as the user of an OS, looking at what was installed as part of it - referring to it as standard/original. If only for easyness (during the discussion) sake.

But if you have a better description for the stuff which is delivered as part of an OS distribution package than You're free to mention it.

Fair warning though: if its five words or more (let alone a multi-line one) than I will probably just stick to the above. :-)

Regards, Rudy Wieser

Reply to
R.Wieser

Rob,

Muchos grazias ! (and no I'm Dutch :-) )

I've stored it for later, after I've figured out how to do stuff the "standard" way - using C/C++.

Regards, Rudy Wieser

Reply to
R.Wieser

I'd love to have every application using the same framework, there would be far fewer shared libraries loaded and a lot more memory available for data - unfortunately it is far from feasible.

--
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/
Reply to
Ahem A Rivet's Shot

One more argument from me:

Code written against Xt in 1997 would still compile and run today, and will probably work as long as X11 is a thing.

Code written against GTK in 1998 (when it was released) won't compile and run against GTK2 and GTK2 code won't compile and run against GTK3, and GTK4 is on the horizon.

With great power comes frequent need to update code.

Elijah

------ whatever you pick, it can be a learning experiece without being a commitment

Reply to
Eli the Bearded

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.