( no avatar )
Note that the description in this has been superseded in some areas by later posts. It's a good idea to browse the whole thread.
![Click to quote this passage; Click again to jump to bottom [Q]](engine/grafts/newdefault/images/qq.png)
PLEASE NOTE dev work has moved back to trunk. Please replace references to testing etc with awn-extras (trunk).
![Click to quote this passage; Click again to jump to bottom [Q]](engine/grafts/newdefault/images/qq.png)
The Last few days I've been working on a implementation of standalone launchers with a separate taskmanager.
![Click to quote this passage; Click again to jump to bottom [Q]](engine/grafts/newdefault/images/qq.png)
The work is incomplete but it is getting to the point of being usable. For those who are interested in trying it out, at the moment it requires desktop-agnostic, vala and my awn-extras branch (EDIT) OR the recommended option is awn-extras-testing and awn-core-testing. And probably some other things I'm neglecting to mention. My suggestion would be to drop by the irc channel if you want to get it up and running.
![Click to quote this passage; Click again to jump to bottom [Q]](engine/grafts/newdefault/images/qq.png)
-it is in development. Not remotely stable. Too many things to mention basically. The taskmand is fairly stable the launchers are not.
![Click to quote this passage; Click again to jump to bottom [Q]](engine/grafts/newdefault/images/qq.png)
Implementation details.
-taskmand is a dbus daemon. All it does is sits there and talks to the launcher applets and starts a new one if necessary. It does a few other things but that is about it. The taskmanager daemon is meant to be very simple. As of this writing the source file is 389 lines of C code. I anticipate with configuration support and the possibility of adding 1 or 2 additional dbus interfaces that it might climb ot 500 lines. It is designed so that it is possible to swap in different launchers.. as desired.
-taskmand is a dbus daemon. All it does is sits there and talks to the launcher applets and starts a new one if necessary. It does a few other things but that is about it. The taskmanager daemon is meant to be very simple. As of this writing the source file is 389 lines of C code. I anticipate with configuration support and the possibility of adding 1 or 2 additional dbus interfaces that it might climb ot 500 lines. It is designed so that it is possible to swap in different launchers.. as desired.
![Click to quote this passage; Click again to jump to bottom [Q]](engine/grafts/newdefault/images/qq.png)
-launchers... This is were the intelligence is meant to be. In essence a launcher is meant to be a minimal taskmanager. In essence it's up to the dev of the launcher to make it do as little or as much as they like. The launcher I am writing are meant to be relatively full features with the ability to manage more than one associated task in a single icon (all the email client windows under one icon, all the terminal windows etc) or to run in one icon per window mode. The launcher code is still in a state of flux... but it is coming along nice. The launchers will also have a mode where the taskmand for those who want to use a non-awn taskmanager.
![Click to quote this passage; Click again to jump to bottom [Q]](engine/grafts/newdefault/images/qq.png)
-Once the configuration backend is done for taskmand it will be possible to choose what launcher applet is used. This will allow the creation of different launchers (say experimental stacks style) as long as they follow the specs on how the taskmand functions. There is a document in the top level of my branch (in the Documents dir) that is _relatively_ up to date. The most up to date documentation of course is the source code :-)
![Click to quote this passage; Click again to jump to bottom [Q]](engine/grafts/newdefault/images/qq.png)
-This is(will be) a dropin replacement for the existing awn taskmanager/launcher. Just disable the awn taskmanager and startup this one.
![Click to quote this passage; Click again to jump to bottom [Q]](engine/grafts/newdefault/images/qq.png)
-Ability to solve the issue the of icons flashing in and out of the bar... and moving around. Most of that issue has just went away on it's own by the nature of the design.
![Click to quote this passage; Click again to jump to bottom [Q]](engine/grafts/newdefault/images/qq.png)
-stability of design.
-The core management is done by taskmand (approx 400 lines of C code) running as it's own separate process. If it does crash it should restart when needed through the dbus services process.
-Each launcher is its own applet and therefore it's own process.
-If a launcher or taskmand acts up it should not effect awn itself (see separate processes).
-flexibility (see the ability to use different launchers). Also note that launchers as I'm using the term here can mean something a bit more than is normally indicated by the term (see the document).
Some Issues:
-note the requirements mentioned above... Vala is needed for the launcher applet. There is nothing stopping development of launchers in python or C that can interact with taskmand though.
-awn-manager. awn-manager has this unfortunate tendency to think that it is the sole ruler of the awn-configuration. Which causes some bad interactions... In the pursuit of KISS taskmand and the launcher start and stop applets by modifications of applets_list key... they let awn do the real work. There is an addition to Desktop-Agnostics Configuration API that allows the use of advisory locking on configuration keys. Ultimately I hope this will filter down and any processes accessing/changing keys that might be touched/changed by other processes will use them when necessary.
-The core management is done by taskmand (approx 400 lines of C code) running as it's own separate process. If it does crash it should restart when needed through the dbus services process.
-Each launcher is its own applet and therefore it's own process.
-If a launcher or taskmand acts up it should not effect awn itself (see separate processes).
-flexibility (see the ability to use different launchers). Also note that launchers as I'm using the term here can mean something a bit more than is normally indicated by the term (see the document).
Some Issues:
-note the requirements mentioned above... Vala is needed for the launcher applet. There is nothing stopping development of launchers in python or C that can interact with taskmand though.
-awn-manager. awn-manager has this unfortunate tendency to think that it is the sole ruler of the awn-configuration. Which causes some bad interactions... In the pursuit of KISS taskmand and the launcher start and stop applets by modifications of applets_list key... they let awn do the real work. There is an addition to Desktop-Agnostics Configuration API that allows the use of advisory locking on configuration keys. Ultimately I hope this will filter down and any processes accessing/changing keys that might be touched/changed by other processes will use them when necessary.
![Click to quote this passage; Click again to jump to bottom [Q]](engine/grafts/newdefault/images/qq.png)
Anyway, I'm hoping that this will get a look over and receive some input. I'm particularly interested in any thoughts on taskmand behaviour and the dbus interface - as the launchers themselves are meant to be replaceable. I am mulling the possible need for a couple more interfaces... simplicity is desired.
![Click to quote this passage; Click again to jump to bottom [Q]](engine/grafts/newdefault/images/qq.png)





