On Wed, 14 Jan 2009 11:39:33 +0200 Dan Pascu <[email protected]> wrote:
> On Tuesday 13 January 2009, Nicolas wrote: > > Hello, > > > > >> Bug #149898 has been open for years in Debian BTS. This bug is a > > >> request from someone who would like to hide the application icons. > > > > > > I'd say that is a feature request, not a bug. > > > > I'm sorry if you felt offended, entries in Debian BTS are called > > "Bugs". I wrote "a request from someone who would like", it seems clear > > enough that this is a wish, and not a non-working feature of > > WindowMaker. > > Relax. Nobody is offended. I just made an observation. While debian may > classify it as it sees fit, it's a feature request, not a bug. > > > > > >> Would it be a solution to ignore the no_appicon flag for dockapps? > > >> It seems sensible to do so, > > > > > > Do you know of a way to differentiate between a dockapp and a > > > non-dockapp? > > > > Dockapps are applications with withdrawn windows only (this is the > > criterion used to deactivate the icon sharing for dockapps, see the > > section of the NEWS file about release 0.80.0). > > If things were that simple. Unfortunately there are other reasons an > application may have withdrawn windows than being a dock app. GNUstep > used withdrawn windows for something as well if I recall correctly. > > The point is you already have the mechanism to accomplish what you want, > only that is not automatic and you have to manually configure things, or > use a collapsed clip. Unless there is a clear indication that something > is a dock app (like a unique property set for it), there is no way you > can automate it. The withdrawn window is not such a property, it's just > something that all dockapps have, but that's not what defines them as > dockapps and it's not unique to them. > > -- > Dan > > > -- > To unsubscribe, send mail to [email protected]. Dan, Can you clarify what I was asking about -that some DockApps set the window call to DockApp and others set it to the same as the calls name? Which of these ir supposed to be right? And does this have somthing to do with libdockapp? It seems to me that some DockApps were using one setting for compatibility with libdockapp before it was integrated into libWUtils (or is it libWINGs?). As I mentioned before I use a lot DockApps which I have patched to all set the window class to "DockApp" and I have noticed nothing unusual. In fact, it lets me completely disable the Clip and Dock and disable all miniwindows and AppIcons and still have the DockApps show on the desktop in the area where AppICons would usually show. As far as I can see, this gives the best of both worlds -except that it depends on patching many DockApps to conform to that behaviour. But, I believe that most many, if not most, DockApps are simply outdated -there are still some which try to link directly to libdockapp when they could simply link to the libs include with wmaker. If we knew which is the correct case, we could move ahead more confidently with patching any and all DockApps which are of interest. I think it is in the interests of wmaker itself to encourage(if not directly host), repositories of workign DockApps which have been updated and/or checked for compatibility with recent versions of wmaker. Thanks, Gilbert -- To unsubscribe, send mail to [email protected].
