focus issues with XVile
I typically run Vile (http://www.invisible-island.net/vile/vile.html) in an rxvt window but occasionally I run it using it's native Xwindow interface (xvile). I use these settings to visually track window focus: BorderColor "red" BorderTileForeground "#d7d7d7" BorderTileBackground "#d7d7d7" ctwm seems to have focus issues with xvile. The best way I can describe this behavior is that only the move recently executed copy of xvile will receive the focus. I can raise older copies of xvile but they won't accept the keyboard focus. There 2 "work arounds" for this but either are convenient: - forcing the focus using a f.focus call in the WindowOps menu - start multiple copies of xvile and restart ctwm (f.restart), after this focus is simply controlled with the mouse in the usual fashion I also tried the ForceFocus setting in .ctwmrc but that didn't seem to have a noticeable effect. I tested ctwm/xvile back to ctwm 3.8.2 but they behaved the same so I assume this is something quarky to xvile but it doesn't seem to have any X specific settings or resources that would effect this behavior. Wayne
Re: UseThreeDMenus text alignment
On Thu, Oct 11, 2018 at 07:08:07PM -0500, Matthew D. Fuller wrote: > On Thu, Oct 11, 2018 at 03:20:49PM -0400 I heard the voice of > Wayne, and lo! it spake thus: > > > > When UseThreeDMenus is defined in .ctwmrc it appears that the text > > of menu is shifted down by some number of pixels causing the menu > > text not to line with the menu selection and is aesthetically > > unpleasing. > > Interesting. So, I _can_ reproduce it in Xnest and Xephyr, but it's > dependant on the MenuFont. The builtin default is > "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*", which looks fine. > But with "-misc-fixed-bold-r-normal--*-140-*-*-*", it gets shifted. > > A few-pixel shift in things is characteristic of the font height > estimation changes we landed just after 3.8.2 (r298). And if I fire > up that nest'd ctwm with LANG=C or an ISO8859-1 charset, the shift > does go away. So that at least points a good finger at where the > problem is. > > > -- > Matthew Fuller (MF4839) | fulle...@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ >On the Internet, nobody can hear you scream. > One important detail that I neglected to report is the log that is produced when ctwm > 4.x is started: Failed to get fontset -*-helvetica-bold-r-normal-*-*-120-*,* Failed to get fontset -*-helvetica-bold-r-normal-*-*-120-*,* Failed to get fontset -*-helvetica-bold-r-normal-*-*-120-*,* Failed to get fontset -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-*,* Failed to get fontset -*-helvetica-bold-r-normal-*-*-120-*,* Failed to get fontset -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-*,* Failed to get fontset -adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1,* This happens when run under Xephyr on my system which results in the 'misc-fixed' font being selected so, that explains it. Xnest and Xorg must be using the adobe-helvetica, as you mentioned. I'm not married to helvetica so I can work around that for now. Thank you for looking into that Matthew. BTW, what is the significance of MF4839? Regards, Wayne
Re: UseThreeDMenus text alignment
On Thu, Oct 11, 2018 at 03:20:49PM -0400 I heard the voice of Wayne, and lo! it spake thus: > > When UseThreeDMenus is defined in .ctwmrc it appears that the text > of menu is shifted down by some number of pixels causing the menu > text not to line with the menu selection and is aesthetically > unpleasing. Interesting. So, I _can_ reproduce it in Xnest and Xephyr, but it's dependant on the MenuFont. The builtin default is "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*", which looks fine. But with "-misc-fixed-bold-r-normal--*-140-*-*-*", it gets shifted. A few-pixel shift in things is characteristic of the font height estimation changes we landed just after 3.8.2 (r298). And if I fire up that nest'd ctwm with LANG=C or an ISO8859-1 charset, the shift does go away. So that at least points a good finger at where the problem is. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: The one improvement I'd like on ctwm
On Mon 08 Oct 2018 at 20:40:55 -0400, Steve Litt wrote: > Contrastingly, ctwm keeps the windows on a given workspace in a ring > buffer. This requires two different keystrokes: One to navigate > clockwise, and one to navigate counterclockwise. For whatever reason, > even after 2 months using specially created hotkeys for these > circular navigations, I couldn't get my muscle memory to work with the > 2 key solution. The window manages that keep a stack instead of a ring also have 2 different key bindings for forward and backward, but the second one isn't used much, typically. Usuallt ALT-TAB and SHIFT-ALT-TAB. I just looked at the code, and in principle it isn't hard to change the ring into a stack. Adding an option to do it is just a bit more work. BUT: it would be useless. Other window managers keep some kind of box open as long as you keep the ALT (or for me WINDOWS) key down. You can press TAB several times. When you finally let go of ALT, the then-selected window is really made active, and pulled to the top of the stack. But ctwm doesn't work like that. Every time you hit the key combination, it immediately switches to the next window in the ring. If you pull that one out to the "top", you'd simply keep switching between two windows. MAYBE if we can link an event to "letting go of ALT", that could be bound to a new action that modifies the ring to behave like a stack. But I haven't looked yet how easy or hard that would be. But if it is possible it would be a nice configuration flexibility. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: UseThreeDMenus text alignment
On Thu, Oct 11, 2018 at 03:27:30PM -0400, Wayne wrote: > On Thu, Oct 11, 2018 at 03:20:49PM -0400, Wayne wrote: > > > > When UseThreeDMenus is defined in .ctwmrc it appears that the text of > > menu is shifted down by some number of pixels causing the menu text > > not to line with the menu selection and is aesthetically unpleasing. > > > > If I remove the UseThreeDMenus option 2D menus look fine. Any > > suggestions as to what I'm doing wrong? > > > > Some other information that might help is that this does NOT occur if I > > run ctwm in Xephyr, which baffles me. It DOES happen when running on > > Xorg and when running in Xvfb viewed via x11vnc. > > > > I've attached images of both the 2D and 3D menu as they are rendered > > on my X server. > > > > Thanks in advance for any insight you guys can provide, > > Wayne > > > > > > > > Version Info: > > OS: Slackware Linux 14.2 (64-bit) > > Xorg/Xvfb/Xephyr: 1.18.3 > > ctwm 4.0.2 (slackbuilds.org) > > (bzr:fulle...@over-yonder.net-20180825230426-jqmrn4j7ghjafx4h) > > ... and now for the attachments that I neglected to attach. > Sorry for all the SPAM... I went a grabbed 3.8.2 and that does not exhibit the corrupted 3D menus. I then test 4.0.0 and it does exhibit corrupted 3D menus. Note I did not change my .ctwmrc file between these tests so there is apparently some issue introduce after 3.8.2 which is causing this behavior. Wayne
Re: UseThreeDMenus text alignment
On Thu, Oct 11, 2018 at 03:20:49PM -0400, Wayne wrote: > > When UseThreeDMenus is defined in .ctwmrc it appears that the text of > menu is shifted down by some number of pixels causing the menu text > not to line with the menu selection and is aesthetically unpleasing. > > If I remove the UseThreeDMenus option 2D menus look fine. Any > suggestions as to what I'm doing wrong? > > Some other information that might help is that this does NOT occur if I > run ctwm in Xephyr, which baffles me. It DOES happen when running on > Xorg and when running in Xvfb viewed via x11vnc. > > I've attached images of both the 2D and 3D menu as they are rendered > on my X server. > > Thanks in advance for any insight you guys can provide, > Wayne > > > > Version Info: > OS: Slackware Linux 14.2 (64-bit) > Xorg/Xvfb/Xephyr: 1.18.3 > ctwm 4.0.2 (slackbuilds.org) > (bzr:fulle...@over-yonder.net-20180825230426-jqmrn4j7ghjafx4h) ... and now for the attachments that I neglected to attach.
Re: The one improvement I'd like on ctwm
> I wanted to be able to type into the partly covered window > [...] > It would have been intolerable to always have to bring the > text window to the top in order to provide text input. So > in that context, the mouse was used to interact with the > program being tested and demonstrated and also used to > change input focus between the test/demo window and the > partly covered text window. That's mostly my style of working. And if you have a trackpoint on your keyboard, you don't even have to move your hand to move the pointer. > In most other contexts, e.g. editing latex source in a text > window and every now and again viewing the formatted PDF file > generated from the text, I don't need to use the mouse and > can use keyboard to write the file and generate pdf, and if > needed, to raise and lower the editor window. Indeed. But zooming in to a particular region to check some detail in the PDF is *much* simpler using the mouse and the "marquee zoom" feature of acroread or gv. > I also don't know any way to use keyboard to select and paste > text between applications, e.g. from a text file in the editor > to a web browser window, or vice versa. I've configured both xterm and vim to use shift-insert to paste text from the X11 selection. In vim you can use registers "*" and "+" to copy text to/from the X11 selection and clipboard. For firefox, pentadactyl/vimperator provide lots of useful keyboard commands (e.g., select an URL in a text window, got to firefox and press "P", which makes firefox open that URL in a new tab; you can select text from a web page using "caret mode").
