A program providing access to "its parts" is called IPC -which is what those little xml scripts (SOAP) you send to rox do. IPC is also what glues full desktop environments together -for gnome it's bonobo & Co. KDE has their own protocols also. dbus is the newest common IPC method -which is now used by nearly all DE's. Welcome to Dependency Hell!
Lately I've wondered if one could implement a light IPC using named pipes (fifos) which would be of any use...
I still tend to think that you have too wide a scope for your idea, though. I mean you have an idea which seems to require intervention on several levels. And, above all, cosmetic effects, etc., should be left to the end user. When you try to control every detail of the way an app looks, then you are bound to have headaches. I mean, even using a certain set of icons is not always a good -that's why we have themes so people can customize the final look for themselves.
Idea for a system timer API to replace polling in programs.
So many apps and services, so many protocols. It is quite the nightmare....
Using pipes for this is exactly the type of thing they do best, if they hold together.
You have my mind working on this train of thought...
The idea you refer to is the timer I presume. But it`s not cosmetic... WallPapers app.?
Realistically for time spans in the seconds, sleep is probably the best way.
And for times in the minutes+ cron would be the best method.
# Junction revisited ( Some things just won`t go away, huh.? ).
Need a wrapper app to catch all file system accesses from an app that it runs.
It would use a list of "path pairs" for substitution ( /etc=/path/etc:/usr/share=/path/usr/share ).
Run the Junction app with list argument, which then runs the main app argument.
.
Using pipes for this is exactly the type of thing they do best, if they hold together.
You have my mind working on this train of thought...
The idea you refer to is the timer I presume. But it`s not cosmetic... WallPapers app.?
Realistically for time spans in the seconds, sleep is probably the best way.
And for times in the minutes+ cron would be the best method.
# Junction revisited ( Some things just won`t go away, huh.? ).
Need a wrapper app to catch all file system accesses from an app that it runs.
It would use a list of "path pairs" for substitution ( /etc=/path/etc:/usr/share=/path/usr/share ).
Run the Junction app with list argument, which then runs the main app argument.
.
-
technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
gtkdialog would be one of the easiest programs to have non-polling event triggers
1) start an inotify watch on a directory where gtkdialog xml will go (actually glib has a wrapper that uses kqueue on bsd and something else on windows)
2) when a new gtkdialog xml file appears in said directory the watch will automatically trigger the xml to be parsed and run
The only reason I haven't patched gtkdialog for it is that I think its custom XML is a waste of development and the whole gtkdialog program should be reimplemented using gtkbuilder.
1) start an inotify watch on a directory where gtkdialog xml will go (actually glib has a wrapper that uses kqueue on bsd and something else on windows)
2) when a new gtkdialog xml file appears in said directory the watch will automatically trigger the xml to be parsed and run
The only reason I haven't patched gtkdialog for it is that I think its custom XML is a waste of development and the whole gtkdialog program should be reimplemented using gtkbuilder.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
I thought inotify only did file watches. You say it does dirs.? But only changes I take it.
My need is to catch accesses to given dirs within a shell instance.
So as in my Junction idea above, a "watch" is put on dirs for a child sub process.
GtkDialog needs scrapping, it`s nearly unusable. GtkServer may be a better choice.
Need a Gtk wrapper app that uses Visual Basic syntax to control the widgets.
I wrote a wrapper for GtkServer to do this, maybe I should drag it out and rework it.
Or perhaps if TinyC could be run in a shell wrapper it could do the same thing.
I`m thinking of apps that look for named pipes, then input and output info. and control.
But I think env. variables would be much more reliable than named pipes. Thoughts.?
.
My need is to catch accesses to given dirs within a shell instance.
So as in my Junction idea above, a "watch" is put on dirs for a child sub process.
GtkDialog needs scrapping, it`s nearly unusable. GtkServer may be a better choice.
Need a Gtk wrapper app that uses Visual Basic syntax to control the widgets.
I wrote a wrapper for GtkServer to do this, maybe I should drag it out and rework it.
Or perhaps if TinyC could be run in a shell wrapper it could do the same thing.
I`m thinking of apps that look for named pipes, then input and output info. and control.
But I think env. variables would be much more reliable than named pipes. Thoughts.?
.