On Wednesday 14 January 2009, Gilbert wrote: > 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
libdockapp is a completely different project written by someone else. it has no relation with WINGs. You have to ask its authors. > 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 -- Dan -- To unsubscribe, send mail to [email protected].
