dockapps/wmswallow/todo
2017-02-21 11:15:02 +00:00

131 lines
4.8 KiB
Plaintext

-*- text -*-
TODO:
Bugs:
-------------
Feature-wishes:
-----------------------
detect automatically if a window wants to be managed or not (should be
easy, but the -unmanaged switch works well, too)
Kill apps nicely when killed. (Some signal handling)
Make wmswallow not only accept mouseclicks on ButtonPress, but also get
some contents of the cutbuffer on (say) a middleclick, and then do
something user-defineable about it. (generic solution for wmnetselect
stuff)
Write manpage
Maybe write freebsd port
Do things reliably/the clean way
-> I mean, don't wait for some microsecs, when you can ask the app
what's up -> find out how! -> XSync seems to work...
-> Wait a second at the right moment helps some things greatly!
Still i don't know if it's the "right thing"[TM]
Problems (maybe unresolvable):
--------------------------------------
WindowMaker segfaults if an instance of wmswallow hangs when
the wm is restarted -> Probably windowmaker bug, but can be fixed by
better signal-handling on behalf of wmswallow
If you swallow apps on the clip *and* in the dock at the same time,
the apps for the clip wander to the dock and vice versa...
Huh? This is most strange. I fear that looks like one of
WindowMaker's many bugs.. :) (Yeah, blame it on others, good
strategy!)
Shaped apps that change their shape will look "out of sync". This is
especially visible with
wmswallow xdaliclock xdaliclock -24 -transparent -cycle \
-geometry 61x61 -fn fixed -oink-oink
There are other problems with xdaliclock -transparent (flicker, the
seconds are lagged behind respectively out of beat) which do not
depend on wmswallow and can be noticed as well, when
xdaliclock -transparent is not being swallowed.
perfmeter objects to have its mouseclicks selected
-> As a workaround, i make the XInputSelect Mask dependant on
whether the user wants to click on the window, or not. But
i'd like to do it better (i.e. force perfmeter to accept
the change)
-> In fact, for every application that selects ButtonPress
events, the same events cannot be selected twice (manpage
of XSelectInput(3))
-> It seems, this "Problem" cannot be fixed!
click works only on the surface of the swallowed window:
(Obviously, because the rest of the area belongs to the
dock... Or can that be redeemed?)
===============================================================================
DONE:
Make basic dockable App
Then steal code off fvwm2 to learn how to swallow stuff
-> done.. Wow! That's easy!
Resize swallowed window appropriately
Judge what to get by following rule:
1. name
2. class
Get command to run from commandline and spawn program.
Somehow handle shaped windows (Like xeyes)
-> Ok, even resizing works
Option: -updateshape (or similar) for apps that change their shape
(like oclock -transparent)
-> is done by default behaviour! :-)
Clean up allocated space (fix memory holes)!
-> Looks ok now. Sending multiple Events under X11 has evil
effects!
Better command-line switch handling. Following commandline-switches:
-noshape/-shape : Switch shape functionality on or off
-getclick: Define commandline to exec when window is clicked
-geometry: Define geometry of swallowed application!
(Size is useful, position as well, to adjust asclock)
-id: Give Window-id to swallow
Freshmeat announcement
Let apps take keyboard focus
-> might or might not be a problem with windowmaker/dock
-> It wasn't... :-) wmMand used Enter and Leave events and then set
the focus for himself. And i blatantly stole the code... (just
2 lines...) :-)
The currently focused window flickers, when the shape gets updated.
This is especially strong with
wmswallow xdaliclock xdaliclock -24 -transparent -cycle \
-geometry 61x61 -fn fixed -oink-oink
This also interferes with focus, and it can be seen that the shape
gets updated in an unclean way, i.e. the shape and the graphics seem
"out of sync"
-> Action on Focus event shortened, XMapSubwindows and XMapWindow
weren't necessary, stealshape only grabs the shape to the
iconwin
Swallowing sometimes is unreliable (especially on WindowMaker start
with many instances) ... Why?
-> Theory: Maybe when several instances of wmswallow start,
the tree of windows gets changed in a way that sometimes a
window cannot be found anymore.
-> Jason helped a little, i figured the rest out... every
windowmanager reparents windows, and waiting for that is
very reliable...
-> done!
some apps cannot be found (xmountains). Why? xmountains in particular
seems to lack a window-id. I didn't know that was possible...
-> resolved by Jason, i did not really check the WM_NAME
just made an rpm specfile