Roman Dubtsov | 1 Nov 07:17 2007
Picon

KDE_NET_SYSTEM_TRAY_WINDOWS root window property

Hi,

I'm writing a standalone tray app (stalonetray) and recently I got an
e-mail from the user asking why stalonetray does not support KDE icons
under Xmonad WM.

After grepping through the sources I have found that Xmonad does not
keep list of KDE icons in KDE_NET_SYSTEM_TRAY_WINDOWS root window
property as expected by stalonetray. As a fallback method (in case
this property does not exist), stalonetray tries to react on MapNotify
events from root window to track KDE icons. However, under Xmonad,
stalonetray never receives such notifies.

So, I have two questions:
1. I have no Haskel experience, so could someone clarify: is it
possible to change Configure.hs so that KDE icons list is kept in
KDE_NET_SYSTEM_TRAY_WINDOWS root window property?
2. Why does not my app receive MapNotifies from root window? Is there
a error at my end?

Thanks,
Roman
Valery V. Vorotyntsev | 1 Nov 09:44 2007
Picon

X11 issues

I think that the following X11 issues relate to xmonad. At least
indirectly. :)

1. There is $USER variable in X11/README commands.
   Is this a typo? Shouldn't $HOME be used instead?

2. cd X11 && Setup.hs configure --help
   Nothing is said about `--without-xinerama' option.

3. There are even more warnings when building without Xinerama:

   $ runhaskell Setup.hs build
!  Setup.hs: Warning: Unknown field 'build-type'

   Preprocessing library X11-1.3.0...
   Building X11-1.3.0...
   [ 1 of 17] Compiling Graphics.X11.Xlib.Types (
Graphics/X11/Xlib/Types.hs, dist/build/Graphics/X11/Xlib/Types.o )
   [ 2 of 17] Compiling Graphics.X11.Types ( Graphics/X11/Types.hs,
dist/build/Graphics/X11/Types.o )
   [ 3 of 17] Compiling Graphics.X11.Xlib.Atom (
Graphics/X11/Xlib/Atom.hs, dist/build/Graphics/X11/Xlib/Atom.o )
   [ 4 of 17] Compiling Graphics.X11.Xlib.Color (
Graphics/X11/Xlib/Color.hs, dist/build/Graphics/X11/Xlib/Color.o )
   [ 5 of 17] Compiling Graphics.X11.Xlib.Context (
Graphics/X11/Xlib/Context.hs, dist/build/Graphics/X11/Xlib/Context.o )
   [ 6 of 17] Compiling Graphics.X11.Xlib.Display (
Graphics/X11/Xlib/Display.hs, dist/build/Graphics/X11/Xlib/Display.o )
   [ 7 of 17] Compiling Graphics.X11.Xlib.Event (
Graphics/X11/Xlib/Event.hs, dist/build/Graphics/X11/Xlib/Event.o )
(Continue reading)

Spencer Janssen | 1 Nov 10:58 2007

Re: KDE_NET_SYSTEM_TRAY_WINDOWS root window property

On Thursday 01 November 2007 01:17:25 Roman Dubtsov wrote:
> Hi,
>
> I'm writing a standalone tray app (stalonetray) and recently I got an
> e-mail from the user asking why stalonetray does not support KDE icons
> under Xmonad WM.
>
> After grepping through the sources I have found that Xmonad does not
> keep list of KDE icons in KDE_NET_SYSTEM_TRAY_WINDOWS root window
> property as expected by stalonetray. As a fallback method (in case
> this property does not exist), stalonetray tries to react on MapNotify
> events from root window to track KDE icons. However, under Xmonad,
> stalonetray never receives such notifies.
>
> So, I have two questions:
> 1. I have no Haskel experience, so could someone clarify: is it
> possible to change Configure.hs so that KDE icons list is kept in
> KDE_NET_SYSTEM_TRAY_WINDOWS root window property?

Yes, this seems possible.  We have a thing called 'manageHook' that is
executed for every new window.  We just need an interested user/hacker to
write the code :).

> 2. Why does not my app receive MapNotifies from root window? Is there
> a error at my end?

I'm not sure what might be going wrong.  Due to its minimalism, xmonad does
things quite differently from most mainstream window managers.  Do you have a
list of window managers that support this fallback method (ion3, wmii, or dwm
especially)?
(Continue reading)

Andrea Rossato | 1 Nov 11:54 2007

Re: KDE_NET_SYSTEM_TRAY_WINDOWS root window property

On Thu, Nov 01, 2007 at 12:17:25PM +0600, Roman Dubtsov wrote:
> 2. Why does not my app receive MapNotifies from root window? Is there
> a error at my end?

This is an interesting question, indeed: XMonad sets both the
StructureNotifyMask and the SubstructureNotifyMask of the root
window's event mask attribute.

By the way, I tried with kmix and korganizer and I was not able to
intercept any MapNotify event. Can you give, as Spencer was asking,
a list of WMs with which this fall back method works?

Regards,

Andrea

David Roundy | 1 Nov 16:20 2007
Picon

darcs patch: -Wall police in Run.

Thu Nov  1 11:20:28 EDT 2007  David Roundy <droundy@...>
  * -Wall police in Run.
Attachment (_wall-police-in-run_.dpatch): text/x-darcs-patch, 111 KiB
Thu Nov  1 11:20:28 EDT 2007  David Roundy <droundy@...>
  * -Wall police in Run.
David Roundy | 1 Nov 16:30 2007
Picon

darcs patch: port Combo (dropping combo).

Thu Nov  1 11:29:15 EDT 2007  David Roundy <droundy@...>
  * port Combo (dropping combo).
Thu Nov  1 11:29:15 EDT 2007  David Roundy <droundy@...>
  * port Combo (dropping combo).
Mats Jansborg | 1 Nov 22:17 2007

Re: darcs patch: code to define a strut-avoiding layout.

David Roundy <droundy@...> writes:

> I haven't pushed it, but it requires actual testing by someone for whom the
> strut code doesn't crash xmonad (presumably 32-bit machines will be fine).
> Review would be less helpful than testing.  I can't test it, for obvious
> reasons (and am also less than motivated to perfect it, for the same
> reasons).

I believe the bugs you are experiencing with ManageDocks may be due to
the type of getWindowProperty32 from the X11 library. The documentation
for XGetWindowProperty says:

  If the returned format is 8, the returned data is represented as a
  char array.  If the returned format is 16, the returned data is
  represented as a short array and should be cast to that type to obtain
  the elements.  If the returned format is 32, the returned data is
  represented as a long array and should be cast to that type to obtain
  the elements.

That is, the data is returned as an array of long even when long is not
32 bits wide. My reading of the above is that the return type of
getWindowProperty32 should be changed to 'IO (Maybe [CLong])' and
analogous for getWindowProperty8 and getWindowProperty16 w.r.t. CChar
and CShort. The situation is the same for XChangeProperty, I think.

I haven't tested this at all (neither on 32 nor 64-bit machines), but if
you want, you can check if the attached patches solve the problem.

Attachment (property-type-change.dpatch): application/octet-stream, 4376 bytes
(Continue reading)

Don Stewart | 1 Nov 22:19 2007

Re: darcs patch: code to define a strut-avoiding layout.

mats:
> David Roundy <droundy@...> writes:
> 
> > I haven't pushed it, but it requires actual testing by someone for whom the
> > strut code doesn't crash xmonad (presumably 32-bit machines will be fine).
> > Review would be less helpful than testing.  I can't test it, for obvious
> > reasons (and am also less than motivated to perfect it, for the same
> > reasons).
> 
> I believe the bugs you are experiencing with ManageDocks may be due to
> the type of getWindowProperty32 from the X11 library. The documentation
> for XGetWindowProperty says:
> 
>   If the returned format is 8, the returned data is represented as a
>   char array.  If the returned format is 16, the returned data is
>   represented as a short array and should be cast to that type to obtain
>   the elements.  If the returned format is 32, the returned data is
>   represented as a long array and should be cast to that type to obtain
>   the elements.
> 
> That is, the data is returned as an array of long even when long is not
> 32 bits wide. My reading of the above is that the return type of
> getWindowProperty32 should be changed to 'IO (Maybe [CLong])' and
> analogous for getWindowProperty8 and getWindowProperty16 w.r.t. CChar
> and CShort. The situation is the same for XChangeProperty, I think.
> 
> I haven't tested this at all (neither on 32 nor 64-bit machines), but if
> you want, you can check if the attached patches solve the problem.
> 

(Continue reading)

Don Stewart | 1 Nov 22:26 2007

Re: X11 issues

valery.vv:
> I think that the following X11 issues relate to xmonad. At least
> indirectly. :)
> 
> 1. There is $USER variable in X11/README commands.
>    Is this a typo? Shouldn't $HOME be used instead?

Yes, well spotted! I've corrected this in the darcs repo.
> 
> 2. cd X11 && Setup.hs configure --help
>    Nothing is said about `--without-xinerama' option.

Ah yes, they're not connected to Setup.hs, I think...
I'm not sure that's worked for a while.

I'll put this on the backburner for now though, unless someone 
has a build error due to this.

> 3. There are even more warnings when building without Xinerama:
> 
>    $ runhaskell Setup.hs build
> !  Setup.hs: Warning: Unknown field 'build-type'
> 
>    Preprocessing library X11-1.3.0...
>    Building X11-1.3.0...
>    [ 1 of 17] Compiling Graphics.X11.Xlib.Types (
> Graphics/X11/Xlib/Types.hs, dist/build/Graphics/X11/Xlib/Types.o )
>    [ 2 of 17] Compiling Graphics.X11.Types ( Graphics/X11/Types.hs,
> dist/build/Graphics/X11/Types.o )
>    [ 3 of 17] Compiling Graphics.X11.Xlib.Atom (
(Continue reading)

Don Stewart | 1 Nov 23:04 2007

Re: darcs patch: zombie_children

dbenbenn:
> Wed Oct 24 18:10:16 PDT 2007  David Benbennick <dbenbenn@...>
>   * zombie_children
>   
>   Second version.  This patch sets SIGCHLD to SIG_IGN, so that any child
>   processes that end will be immediately cleaned up.  It also waits on
>   all existing zombie child processes, in case they already exist.
>   
>   I'm not too happy about waitAllChildren; it doesn't seem very Haskelley.
>   I was surprised that the following didn't work:
>   
>     try $ forever_ $ getAnyProcessStatus False False >>= return . fromJust
>   

I hope to evalute this patch on the weekend. Thanks for being patient.

-- Don

Gmane