Re: [dwm] Virtual keyboards

From: Anselm R Garbe <>
Date: Sun, 8 Feb 2009 09:44:54 +0000

Hi Peter,

2009/1/31 Peter Hartlich <>:
>> I like this patch and will apply it to 5.4 which is going to be
>> released until the weekend.
> One problem with it is that you don't really know where keyboard input
> will be going (dwm being focus-follows-mouse by default). I use another
> patch on top of that (attached) to draw a selfgcolor border around the
> last focusable window when an unfocusable window is selected, but I'm
> not sure recycling selfgcolor is kosher...
> Plus you may want to rename focus() to selectwin() or something.

I see. I think the whole unfocussable stuff needs further thinking
before going mainstream. I'm going to release 5.4 now.

It appears to me that both the onscreen keyboard and the client with
the input focus should have a selfg border -- at least that makes most
sense in my opinion. Introducing another couple just for that sounds
quite over-engineered to me.

>> I should get broadband today that I'll be ack online and can support
>> questions regarding my upcoming st and libtg release.
> So, when's the st release and does libtg (if that's the name of the
> not-completely-secret project) use XCB? :)

Well, I changed my mind several times during the last weeks. When I
get time I end up thinking that several decisions I made are wrong by
nature... but I will come up with one way or another soon. I'm not too
convinced libtg as it is (X abstraction primitives + text format
processing + parts of text window abstractions and input handling) is
the right way to go. I feel remembered at the wmii times, when wmii
was screwed up due to depending on its 9P scripting interface. I
believe I did the same journey with st making it dependent on libtg,
and I tend to revert this mistake at the moment.

Kind regards,
Received on Sun Feb 08 2009 - 09:44:54 UTC

This archive was generated by hypermail 2.2.0 : Sun Feb 08 2009 - 09:48:05 UTC