On Mon, 12 Jan 2009 15:18:18 +0200 Dan Pascu <[email protected]> wrote:
> On Monday 12 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. Why would someone think that > having appicons is a bug? > > > Marcelo Magallon answered "You can open the property inspector for a > > random app, select "Window Specification" from the uppermost menu and > > select "Defaults for all windows" and then select "no application icon" > > from "application specific"." > > But the problem of this solution is that it also disables dockapps. > > you can also set the clip to autoattract icons and leave it collapsed > > > > > 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? > > -- > Dan > > > -- > To unsubscribe, send mail to [email protected]. I've done some work around this subject as I like running wmaker as a completely clean desktop. First, there is a pacth which will completely disable appicons, but I think it should rather be a configurable option. What I do is put this in my ~/GNUstep/Defaults/WMWindowAttributes file: "." = {NoAppIcon = Yes;}; "*" = {NoAppIcon = Yes;}; Here's the complete example I use: { "ROX-Pinboard" = { NoResizebar = Yes; NoBorder = Yes; KeepInsideScreen = Yes; NoHideOthers = Yes; SkipWindowList = Yes; DontSaveSession = Yes; NoCloseButton = Yes; NoTitlebar = Yes; NoMiniaturizeButton = Yes; Omnipresent = Yes; }; groupLeader.WPrefs = { Icon = "/usr/lib/GNUstep/Applications/WPrefs.app/WPrefs.tiff"; }; "ROX-Filer.ROX-Filer" = { NoAppIcon = Yes; SharedAppIcon = No; }; "." = {NoAppIcon = Yes;}; "*" = {NoAppIcon = Yes;}; } If you want certain apps to show appicons, then you need to put them before this: "." = {NoAppIcon = Yes;}; "*" = {NoAppIcon = Yes;}; And, you also need to put that in WMWindowAttributes while *not* running wmaker, otherwise the current state will overwrite your changes. This has the effect of keeping all applications from showing shared icons. What I do is disable the Dock and the Clip both and then put those options in WMWindowAttributes. However, this has the side-effect of making some DockApps invisible! I found it strange that some worked and some didn't, so I started looking at the sources for DockApps that worked and those that didn't. What I found was that DockApps which set the window class to their name would not show, but that those that set their window class to "DockApp" would still show. So, I now patch all the DockApps I use to set the window class hint to DockApp. This makes DockApps run and be shown in the area where the AppIcons would normally show. i really like this behaviour because it means I can orient this "False Dock" in any corner of the dekstop either vertically or horizontally. I have about 50 DockApps with sources and the patches here: http://distro.ibiblio.org/pub/linux/distributions/amigolinux/download/DockApps/ Also in that directory are three example patches which show how to patch most DockApps of the vearious types using GTK or the wmgeneral DockApp templates. I recently ran into a couple of other types, but it'S pretty easy to find where to change the sources by simply grepping for the word 'class' in the sources. Below is the patch which wil completely disable AppIcons: --- ./actions.c.00 2005-07-03 19:25:14.000000000 +0200 +++ ./actions.c 2007-01-24 19:21:48.000000000 +0100 @@ -960,9 +960,9 @@ && !wwin->flags.net_handle_icon #endif ) { - if (!wwin->flags.icon_moved) { - PlaceIcon(wwin->screen_ptr, &wwin->icon_x, &wwin->icon_y, wGetHeadForWindow(wwin)); - } + /* if (!wwin->flags.icon_moved) { */ + /* PlaceIcon(wwin->screen_ptr, &wwin->icon_x, &wwin->icon_y, wGetHeadForWindow(wwin)); */ + /* } */ wwin->icon = wIconCreate(wwin); wwin->icon->mapped = 1; @@ -1109,6 +1109,9 @@ void wDeiconifyWindow(WWindow *wwin) { + + if (!wwin) { return; } + #ifdef NETWM_HINTS /* we're hiding for show_desktop */ int netwm_hidden = wwin->flags.net_show_desktop && --- ./appicon.c.00 2004-10-14 19:31:49.000000000 +0200 +++ ./appicon.c 2007-01-24 19:24:34.000000000 +0100 @@ -159,6 +159,7 @@ aicon->wm_instance = wstrdup(leader_win->wm_instance); aicon->icon = wIconCreate(leader_win); + #ifdef DEMATERIALIZE_ICON { XSetWindowAttributes attribs; --- ./application.c.00 2005-03-11 22:35:36.000000000 +0100 +++ ./application.c 2007-01-24 19:32:56.000000000 +0100 @@ -324,6 +324,7 @@ /* application descriptor */ XSaveContext(dpy, main_window, wAppWinContext, (XPointer)wapp); +#if 0 if (!WFLAGP(wapp->main_window_desc, no_appicon)) { wapp->app_icon = NULL; if (scr->last_dock) @@ -359,6 +360,9 @@ } else { wapp->app_icon = NULL; } +#endif + + wapp->app_icon = NULL; if (wapp->app_icon) { wapp->app_icon->main_window = main_window; I think it is pretty hackish, but I think it would be a good option if it was added to the WPrefs app and made a run-time option. While Dan is here (hopefully still), I really wanted to ask you about that hack that I do to change the window class. From what I gather the fact that some apps already have the class set to DockApp, has to do with some changes in libdockapp, with either earlier or later apps having the behaviour that I want. Are you aware of any problems that this would cause -setting all DockApps to window class DockApp. I have submitted a patch which addresses a side efect of using that with the DockApps. That is, when clicking on any of these DockApps to kill them, the Kill Application dialog shows "DockApp will be forcibly closed" instead of the name(actually the class) of the app. I submitted a patch which changes the KillApplication routine to retrieve the name of the app instead of showing the class. Gilbert Ashely -- To unsubscribe, send mail to [email protected].
