Awn

Bug #189836
Comment #1

Comment 1 for bug 189836

Revision history for this message

moonbeam (rcryderman) wrote on 2008-02-07:

A few comments.

1) You might want to try out the taskmand/standalone-launcher implementation in testing. It more or less implements a variation on what you describe. I'll note the reality of implementation is messier than the theory.

The rest of the comments refer to the awn-core implementation. I may have a couple details wrong... it's been a little bit since I looked at it:
2) The essential problem is this. Is the icon provided by the desktop file to be used or is the icon provided by libwnck to be used? You have definite preferred behaviour... strangely others might disagree.
3) I actually tend to believe that libwnck more or less uses the method that you describe regarding using the window's class name(I could be wrong).
4) The awn core behaviour is to use libwnck to provide the icon (I think we need to bow the wisdom of the libwnck devs on this) if the process is not launched from an awn launcher (unless it's restarted of course...). If it is launched from a launcher it tries to use the icon specified in the desktop file. I think this is where you'd like to try and reassociate with launcher (see point 1 above :-) ). The core is basically just missing the attempt to associate a process launched outside of awn with a launcher.
5) Some applications make it difficult to even associate a process started from an awn launcher with the window that appears (I'm looking at you firefox).
6) Most people want the icon associated with the desktop file to be used. Some don't.
7) Applications don't necessarily really know about the desktop file spec.
7) Given a process that is launched from outside awn it is non-trivial to associate the process with the correct desktop file. Yes, it is possible to get good results. It is difficult to get good enough. See point 1 :-).
8) You are basically correct.

Summary:
The core implementation in 0.2 doesn't work as well as most people want. However, I don't think anyone has the heart to mess with the core 0.2 implementation as that code has proven to be fragile in the past... and it is at least stable at this point.

My preference would be to move all the task management out of core - and I have such an implementation available as applets and a dbus server in testing - I'm not sure how njpatel ultimately feels about the direction I have taken with my implementation :-) as there are real advantages and disadvantages. But it works, some of the applet code is currently messy(see notes above about theory/practice + different viewpoints on behaviour) but seems to be relatively stable. And you would probably find it gets closer to what you want in terms of behaviour (though you might need to use the regex whitelisting feature on a few things to get the awn restart working the way you would like).

A few comments.

1)   You might want to try out the taskmand/standalone-launcher implementation in testing.  It more or less implements a variation on what you describe.  I'll note the reality of implementation is messier than the theory.

The rest of the comments refer to the awn-core implementation.  I may have a couple details wrong... it's been a little bit since I looked at it:
2)   The essential problem is this.  Is the icon provided by  the desktop file to be used or is the icon provided by libwnck to be used?  You have definite preferred behaviour... strangely others might disagree.
3)   I actually tend to believe that libwnck more or less uses the method that you describe regarding using the window's class name(I could be wrong).
4)  The awn core behaviour is to use libwnck to provide the icon (I think we need to bow the wisdom of the libwnck devs on this) if the process is not launched from an awn launcher (unless it's restarted of course...).  If it is launched from a launcher it tries to use the icon specified in the desktop file.   I think this is where you'd like to try and reassociate with launcher (see point 1 above :-)  ).  The core is basically just missing the attempt to associate a process launched outside of awn with a launcher.
5)  Some applications make it difficult to even associate a process started from an awn launcher with the window that appears (I'm looking at you firefox).
6)  Most people want the icon associated with the desktop file to be used.  Some don't. 
7)  Applications don't necessarily really know about the desktop file spec.
7)  Given a process that is launched from outside awn it is non-trivial to associate the process with the correct desktop file.  Yes, it is possible to get good results.  It is difficult to get good enough.  See point 1 :-).
8)  You are basically correct.

Summary:
The core implementation in 0.2 doesn't work as well as most people want.  However, I don't think anyone has the heart to mess with the core 0.2 implementation as that code has proven to be fragile in the past... and it is at least stable at this point.

My preference would be to move all the task management out of core - and I have such an implementation available as applets and a dbus server in testing - I'm not sure how njpatel ultimately feels about the direction I have taken with my implementation :-) as there are real advantages and disadvantages.  But it works, some of the applet code is currently messy(see notes above about theory/practice + different viewpoints on behaviour) but seems to be relatively stable.    And you would probably find it gets closer to what you want in terms of behaviour (though you might need to use the regex whitelisting feature on a few things to get the awn restart working the way you would like).