[Novalug] Process intercommunication
Fri Dec 30 16:54:42 EST 2016
On 12/30/2016 04:01 PM, Gary Knott via Novalug wrote:
> Dear Peter, I looked at the DBUS "tutorial" you cited. Thanks.
> (I object to the term object - and also method. Linux, and
> Linux Documentation, should be kept at the C programmer
> level in my opinion.)
Heh - sorry about that. After I sent the message, I wondered if I should
just have linked the WikiPedia article instead
(https://en.wikipedia.org/wiki/D-Bus). The difference is, that the link
I gave here was the developer resource - "begin here" guide. WikiPedia
tends to be more administrative and theory.
That said, everything we do in Linux eventually invokes a C-library
(stdlib, glibc etc) feature. That's the nature of the beast here. As
you'll see in a moment, even the File Chooser dialog is a C function.
However, as you move up the abstraction layers to languages like Python
or Java, you'll find these platforms have their own libraries which you
use. These libraries will in turn call the C libraries for you - but
you have an easier way to do things. That said, core functionality is
defined at the C level - so if the goal is to understand "what can I do
in Linux" that's really where you have to be looking.
I'm no longer fluent in C - I don't program on a daily basis so I think
I lost my right to wear the "programmer" badge. I can read a program but
it's not just a second language anymore. If you speak to developers
you'll find that they see programming languages as a real language -
they don't really think about "how" the program works - it's very clear
from just a glance. To me, it takes "a bit" longer to see what it does
these days. But I just consider myself a slow-reader :)
> Anyway, I see that DBUS is kinda like the Windows "message queue"
> system with callbacks being used for receiving "messages".
Right - the difference is how dbus is implemented behind the scene; to
you as a user of it it's simple call-back functions you register.
That's a very basic programming principle when it comes to event based
programming; I doubt we could think of better ways than a call back - it
worked 30 years ago, and it works now :)
> What I did not find was any list of pre-defined "events" that I, as a
> programmer, could request a call-back for. It seems likely that some process that implements the "file-selection" window is getting a callback notifying it that a file owned by user "X" has been closed, but that's just a guess.
Hang on - I think we have a bit of a misunderstand here. There's a basic
UI (gtk) library function for File Choosers. I cannot recall ever
programming to a UI that didn't have such a function/feature. It allowed
user code to use a standard UI for users to pick files. Windows has it,
OS/2 has it - X11 has it etc. So when you need a user to pick a file
from the OS, you'll simple call the function. In gtk you can find the
spec here (yes, it's C):
This is what Firefox calls. It's pretty basic and Firefox/Chrome really
isn't involved here. As you can see, all it does is return a file name
string - so there's no magic here. There's no need to know how the File
Chooser works - except it comes with a billion options so reading about
those options is helpful (ie. should the user be able to pick more than
one file, which file types should be accepted etc).
What I thought your question was about, was how the File Chooser dialog
knew you'd changed a file elsewhere. That's where DBUS comes in. But in
THIS case, you don't need to know how it does it - it's just doing it
for you :)
But if you were to program your own file chooser, or had a similar need,
you would need to know what events to listen for. This is where reading
the fine print around dbus is important. There's a ton of options here,
but in the end you'll need to know what you're looking for. There's an
easy way to find out: use dbus-monitor and execute the events you want
to be notified on - and well, you have all the options/names you need to
be looking for right there. There's qdbus too of course to look for the
Here's a few more links to guides:
> (Surely, it does not just get a "file-closed" notification and then have to check the dates and times of all files it is displaying? - Or maybe it just redoes its entire display, accessing the entire directory and formatting its contents without worrying about what file got closed?
So this is why I choose to show what's actually being sent. Note it's
the complete file name and action. Ie. there's no need to "refresh" or
read the directory or anything - you can simply change the data
structure directly based on the data you're getting. In my case it
"move" so the file was moved from a source to a destination. My dialogue
would see that the file was part of the directory it was displaying and
simply remove the file from the view. Likewise, had I created a file it
would have been told so, and it could simply display it. Now, in that
case getting owner, size etc. would most likely require a check of the
file system. A lazy programmer would simply refresh from the file system
regardless of the event, as long as it involved the directory it was
displaying. As long as there's only a "few" files that would work great,
but if it's thousands of files a refresh could remove the current focus,
move a lot of files around or even worse take a long time if there are
10K+ files to sort through. Anyway - messaging systems like this,
allows programmers to make short-cuts and improve performance.
> By the way, is the "file-selection" window that pops-up i a specific
> utility program provide3d as part of a Linux distro that is run when I do a thing like click on the "paperclip" in a gmail window being displayed by Firefox?
It should be the exact same dialog regardless of what software you use.
Firefox, Chrome, Thunderbird, Evolution, Evince etc. should all present
you with the exact same dialog when-ever you're accessing a function
where you have to pick a file.
> [One of the issues that makes understanding "modern"
> computing daunting , is that understanding the list of programs that
> run and what they do when you take some action - click or hit a key -
> is extremely hard (in fact, often practically impossible!)
> - it is not just "take an action" => a specific
> program receives the "action" and acts simply and on its own.]
Other than the word "modern" would agree that event based programming
can be tough. Hint - just take a look at NodeJS and let's have a talk
about "having to twist your head around event programming" :) NodeJS is
nothing but call-back functions. It's a hard concept to get through
for sure. But once understood it's actually beautifully simple in concept.
Btw. I'm sure you know this - but as it's a library function, there's no
More information about the Novalug