And such a 'runtime library' is not part of the "neccessary libraries" I mentioned ... How exactly ?
Look at the subject line. I think I made abundantly clear what environment I was talking about / working in.
And thus stand the chance of having one program in one visual style (as defined by its used framework), and the next in another (as defined by the other framework) ? I can imagine that that would look rather messy. :-(
Funny. I just responded to someone who even had a problem whith me referring to what is running on my RP as an OS, and here you are, referring to the kernel *and* supporting (userland) programs (which that CLI most likely is) as being "Linux".
But the same to you: I think I've made abundantly clear in which environment I'm working. And that environment most definitily includes a GUI.
Just two problems: I have no idea what a "package manager" looks like and/or where to look for it, and neither do I know how to entice it to divulge such information.
A quick peek just now in the menus under the raspberry at the top-left does not show any such (related) entry.
On what basis ? Or should I just put my hand infront of my eyes, spin around a couple of times and make it the luck of the draw ?
Would *you* find that an acceptable way of doing things ? Especially when there are complex and/or low-level ones, and others which would make life a bit easier for a novice ?
That bit of info you gave there might not be important to you, but it is to me. It gives me a direction where I had none.*
... and its pretty-much exactly why I provided mine.
*other than others having mentioned the same I mean. :-)
I wish I could. I just tried to "sudo apt-get --download-only install libgtk2.0-dev"* (to get the libraries and header files the compiler needs I guess), but it ended with a "some files failed to download" - which, I guess, makes the whole download worthless. :-\
*matching the numbers I found when looking for *GTK* files/folders.
Yeah. The biggest one of them being that I specifically mentioned that I'm a novice in this regard, but nobody thought of clarifying what the terms where they used ment. So I used my own guestimates for it. And with this one I was rather close. :-)
Not quite that anymore. As GTK is appearantly the one also used by the OS I think I will start with that one.
.. than again, I just tried to apt-get a libgtk2.0-dev package, and got a "not all files are downloaded" error message. Which I have no idea yet to how to deal with it. :-(
True. But I prefer to use something thats part of the installation, instead of just blindly add more stuff -- whithout knowing how - or even *if* it will co-exist with whats already there.
On Tue, 21 Nov 2017 19:42:19 +0100, "R.Wieser" declaimed the following:
The runtime will allow programs that have been built using SO library references to run ... It is not sufficient for you to build programs. For that you will need to have the development files (headers defining what is in the library) and possibly even non-shared libraries if some components are hard-linked into the executable.
You ARE running Linux (if you used a NOOBS install, the default is for "Raspbian", which is a customized version of the Debian Linux distribution, and uses "Pixel" which is a customized version of LXDE.
LXPanel is a component program of LXDE running under Linux which ONLY handles the display of the basic "applications" menu, and icons representing active windows, network connectivity, etc. -- it is not, of itself, a GUI environment or desktop. It most definitely is not an OS.
That's life in UNIX/Linux land. Not even the command line interpreter (aka: shell) is standard: Bourne, BASH, CSH, ZSH, TCSH, KSH (although most distributions have collected about BASH, when I had a dial-up internet shell account I was configured for tcsh).
Be glad no one has mentioned TCL/Tk -- which is partly standard for Python as Tkinter is standard, and is used by the IDLE IDE (I don't use IDLE, every time I open it I find an ugly layout with ugly widgets; both in Linux and Windows). The only Tkinter feature I've used more than as an experiment is the file-requester dialog.
The window manager, again, only handles the passing of events to applications, and the display ordering (refresh) of top-level windows (the rectangular region belonging to an application). What gets drawn within those regions is up to the applications, not the window manager -- that includes application specific widgets (menus, buttons, scroll bars, text boxes) and the application developer is free to use whatever framework they are most comfortable with. Linux desktop environments are just someone's collection of window manager, desktop/panel manager, and minimal set of applications (terminal/console window, text editors, image viewers, maybe web browser, graphical package manager) -- which the environment architect built using a single common widget framework.
Wulfraed Dennis Lee Bieber AF6VN
Thanks for the warning. It means that I will most likely take a look at Xt too (I like longlivity in my programs. Some of them are already 20 years old. :-) )
Than again, as long as I keep the version of GTK at hand I've been programming against, there should be no reason why I should not be able to keep using it for quite some while - I just have to (re-)install it on the new OS.
On Tue, 21 Nov 2017 20:35:13 +0100, "R.Wieser" declaimed the following:
This reveals that you should consider studying some guide to using /and administrating/ a Linux system -- though to simplify things: focus on Debian based distributions -- you are probably not running a red-hat distribution which uses a whole different package manager...
Possibly because they consider it a specialized administration tool, and hence don't list it in the common user applications. (I don't have time to connect my RPi-3 to the upstairs TV in order to get to the desktop -- I normally SSH in from my Windows machine and use the resulting command line).
If you don't want to take the time to study tutorials for each of the major ones, that is just as reasonable a choice as any other.
I'd likely base it upon what documentation I could find and study, map the widget set to what I feel I need (things like an expandable tree display may not be part of a framework and would require the user to write there own "macro widget" and all event handling for it), consider how difficult it is to do background processing (work routine that only runs when the rest of the event loop is empty -- and has to be written to only do a few steps with a saved environment before returning to check for events... vs being able to spawn a thread with a means for the thread to communication back to the event loop as needed; pretty much all of the frameworks are not happy if a thread attempts to process events in parallel with the running "app" object).
Didn't you say you don't know what a package manager is?
"apt" is the Debian-based command line package manager. (and graphical ones tend to have "apt" somewhere in their name -- but you may have to first install them )
And what else did the command display? Problems with repositories? Network connection glitch?
I've never used the "download-only" option so don't know what type of effects that could have.
Also, did you do an "apt-get update" first to make sure the package list is up-to-date?
Wulfraed Dennis Lee Bieber AF6VN
Indeed, so as this is built with the GTK toolkit, that is the obvious toolkit to use when defining your application's GUI interface.
Less so that you might imagine, as in practise many of the more recently developed toolkits tend to pick up at least part of their look&feel from the window manager at run time. Some do this better than others, but most use the same colour and appearance for application window frames as the window manager and do the same for text and background colours used inside the window.
A lot of window managers make this stuff configurable and so any application that didn't automatically use the configured settings would stand out like a sunset at midnight.
martin@ | Martin Gregorie
gregorie. | Essex, UK
What I was thinking there was that, when I encountered wxWidgets (through wxPython) all the class names that I was using seemed very familiar from my days writing switch-statement-from-hell C programs for Windows 3.1. The same catch-all wx.Windows class from which almost everything else descended, etc. I sound more disparaging than I really am. I got some good stuff done, and most of what I knew from before adapted very easily to wxWidgets. My example of non-Windows style would have been Borland TurboVision, and its descendant Object Windows Library. Breaking down the huge Window class into View and Group made things much simpler. Too bad that style didn't prevail.
No. It means that I need a bit of help to do my first steps, so I have (an) anchor point(s) to work from.
Also, I do not expect such tools to be the same on the different distributions, which would make reading about tools which are not present / do not work the same as on the distribution I have *now* a pure waste of time.
Which makes it difficult to find, especially as, in my case, you do not exactly know (filename wise) what you are looking for. Do you recognise you are effectivily condemning me to doing a "wild goose hunt" ? Not funny.
Just two things:
1) What are those "major ones" you are talking about there ? Remember, I still have no way of discovering whats actually available on my machine (see above).
2) Exactly *what* would I be studying ? I have no idea whats important about them and thus no way to compare them against each other.
Nope mate, you are most likely looking at this with a 20-20 vision, not able (anymore?) to put yourself into the position of a novice, who just sees a big forrest and does not even recognise the paths going in-and-out of it.
No. I said that I have no clue wat you guys refer to when you say "package manager", and asked for specifics.
I however did recognise (while googeling) the name apt-get as *a* (CLI) package manager.
I saw at least a 404 roll by. I take that as a problem at their side. I will try again today though, just to see if the problem persists.
Are you telling me you didn't take your own advice and studied all of that program before using it ? I'm disappointed.
And I was supposed to now to do that first .. how exactly ?
And no, neither of the webpages which suggested that apt-get and the "store locally" method mentioned it.
But, as you have mentioned it I will put that in my "what to do when installing a package" documentation and execute it before I try te re-obtain the package. So thank you.
I toggled a GPIO pin a few times ("blink" said the LED) using the build-in "sysfs" method (only later I saw that "wiringPi" is already installed too). I even add a SIGINT handler, so the pin would also be "unexported" when I would choose to abort the program. :-)
I did choose (at least for the moment) to go with "geany", as it was adviced on the
website and was readily available thru the desktops menu. It takes al the nitty-gritty outof my hands, which currently suits me just fine when doing my first steps.
I know of them, and have read enough about them to think they are overly complex beasts for a single-user environment. My (longtime) method-of-choice is to manually save versions, with the current date appended to the(ir folders) name.
But I guess it could not hurt to take a look at (at least) one of them. Especially not when, in the case of a calamity, re-installing de RP OS is as painless as they made it with NOOBS. :-)
I will probably designate a folder for program development, and only copy/move the program rom there to its final destination when I think its finished. A kind of development- versus production environment idea I guess.