icewm
icewm copied to clipboard
bbidulock
Emacs too low on screen at startup
Perhaps one day a long standing problem could be solved: emacs always starts too low on the screen:
And needs to be manually dragged up:
$ xrdb /dev/null $ xrdb -query|wc 0 0 0 $ emacs -q # or -Q Hmm there are 200 message long threads...
It looks like this problem is due to Emacs+GTK. On startup Emacs asks icewm to become visible. Icewm honors this request, but then immediately Emacs asks to become larger vertically to accommodate an extra status bar.
It should have first created this extra status bar, before asking to become mapped. Then icewm could place it on screen completely visible. I think your problem is easily solved by adding this to your winoptions file:
emacs.geometry: +0+-30
If need be, you can also set this pref: LimitPosition=0.
Those workarounds are great to know, but I want to get this problem finally solved for future generations. So are there any more details you would like to add? Or perhaps you could send your analysis directly to [email protected] !
There is already more than sufficient analysis in the links you gave above.
So did the workaround work for you? I could make a more automatic solution, but that would require testing and evaluation by users, before I could release it.
It looks like this problem is due to Emacs+GTK.
I also have a strange problem in ruby-gtk3 applications.
https://i.imgur.com/SR1aIlR.png
In the event it can not be easily seen, at the bottom bar, on the right hand side, I can close entries via the mouse, but the bottom bar does not instantly re-calculate the size afterwards. This is different to the behaviour of regular applications, so this may be because I wrote the ruby-gtk3 applications incorrectly (for example, they crash on exit rather than exit gracefully ... even then I found icewm's behaviour a bit confusing, because that spacer where the old application was open, is recalculated at a later time or when I focus on e. g. the first tabs ... anyway, sorry for distracting the issue here, I have not yet investigated this in a way so as to make it easily reproducible for others. But I wanted to comment that gtk does indeed seem to be a bit peculiar in general.)
[mistake removed]
Putting
LimitPosition=0
into .icewm/preferences and restarting icewm and then running emacs -Q also didn't help, no matter what xrdb had.
So how did I survive this bug for a decade without going nuts each day?
$ grep fulls .emacs
(fullscreen . maximized)
No, please read carefully. It said: "add this to your winoptions file." The winoptions file is in the same directory as your preferences file. It is explained in the man page icewm-winoptions. Make sure it has at least this line:
emacs.geometry: +0+-30
and do icesh winoptions to make icewm reload the winoptions from that file. It should make a difference, for sure, if you do it correctly.
Ah! OK, it turns out one needs
emacs.geometry: +0+0
If one uses that "30" solution, the header bar is chopped.
Commit 8b624a0 introduces an automatic solution for icewm: whenever an application resizes itself outside of the work area then icewm will reposition it slightly towards the center, such that its border is aligned with the border of the work area. The "work area" is the area of the desktop which excludes the taskbar. People are welcome to test and evaluate this. Does this fit with how you want to use your applications and how they behave?
OK, I'll test it once it hits Debian sid, and if it works, I'll hunt down all related open bugs and close them. Thanks!
Ohh, no! It got too hard! I am the guy who WANTS the windows outside the work area partially.
I'm using chromium a bit offset to up and left, to get a bit larger visible area with command: wmctrl -i -r 0x04600007 -e 3,-5,-16,1485,867 (0x04600007 is the window id of chromium)
Before this patch it worked for years:
But after this patch I can't set negative values:
Manually dragging the window outside works (alt+f7 or alt+mouse), but I can't set it within scripts.
