Re: [dev] [OT] Music?
On 9/21/10, Ammar James wrote: > I feel compelled to reply to this since none of you fools seem to > listen to hip-hop. ;p > [bunch of good artists] > http://www.youtube.com/watch?v=JQRRnAhmB58 > > http://www.youtube.com/watch?v=IcY0a8gKCzc > Ugh, YouTube links on d...@suckless.org? -- kv, - Bjartur
Re: [dev] mcwm
On Wed, 15 Sep 2010 22:15 +0200, "Jakub Lach" wrote: > 15/09/2010 21:51 Uriel : > > > What issues? and why aren't they fixed? > > > > uriel > > Oh, I was expecting something more along > the lines of "SDL is abomination and pile > of putrid garbage anyway".. Haha! It's certainly a git to window managers, SDL has given me trouble with every window manager I've taken seriously in the last 5 years. What I think SDL is doing is discarding the last resize event received. I got that idea first on my PDA with ion3 and OpenTTD where ion3 was set to full-screen-maximize OpenTTD: I'd see a black border above the window corresponding in height to ion3's title bar. In WindowMaker on the desktop yesterday I found OpenTTD would not unmaximize; after unmaximizing it would remain at the maximized size. I'm not sure if ion3 and WindowMaker are reparenting window managers.
Re: [dev] [OT] Music?
Ammar James wrote: > I feel compelled to reply to this since none of you fools seem to > listen to hip-hop. ;p True hardcore rap died with Lord Invader, man.
Re: [dev] [OT] Music?
On Tue, Sep 21, 2010 at 10:01:10AM +, Bjartur Thorlacius wrote: On 9/21/10, Ammar James wrote: I feel compelled to reply to this since none of you fools seem to listen to hip-hop. ;p [bunch of good artists] http://www.youtube.com/watch?v=JQRRnAhmB58 http://www.youtube.com/watch?v=IcY0a8gKCzc Ugh, YouTube links on d...@suckless.org? See http://hg.suckless.org/vp -- Kris Maglione He who joyfully marches to music in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would suffice. --Albert Einstein
Re: [dev] [dwm] tagging interface
> You want the KeyRelease event. Note that, by default, X11 > will generate > spurious repeat KeyPress events. Years ago I read the > relevant SDL code > (which maintains a vector of which keys are currently down) to > see if it > had a nice way of handling these events. It turns out it > just had > a heuristic for detecting them and ignoring them; iirc, the > synthetic repeat > events look like a KeyRelease followed by a KeyPress, where the only > difference between the two events is the type (i.e. Release then > Press), > and the time, which is off by one. These are pushed onto > the X event > queue simultaneously, so a reliable test is, when encountering > KeyRelease, also call XPeekEvent to see if the follow-up KeyPress > exists. In this case, the KeyRelease/KeyPress pair can be > interpretedas a repeat event, and ignored. That would suck. Good to know it can be done tho. I have heard of a way to turn off repeats, and I'll look into that before I do any nasty race-condition hacks. I guess the SDL is a good source. (haha pun) Is there anything in dwm that depends on repeats that would be broken if I changed it somehow? I'll get hacking and post a patch if I ever finish. Thanks for your help.
Re: [dev] [dwm] tagging interface
2010/9/21 Wolf Tivy :
> I would like to change the way tag selection works in my dwm.
> The way I think it should work is if you press two (or more) tag
> select keysbefore you release one of them, dwm would select both
> tags. Likewise for tagging windows. I think this would make the
> tagging stuff much more usable and intuitive.
I'm not sure I'm understanding what you mean but I think you can
achieve that only changing your config:
#define TAGKEYS(KEY,TAG) \
{ MODKEY, KEY, toggleview, {.ui
= 1 << TAG} }, \
(n.b. toggleview instead of view)
You don't need to release modkey to toggle more tags, so there is no
much difference with what you are suggesting. The only "problem" I see
is that your previous tags won't be remembered, I don't know if that
is important for you. Maybe what you want is to always set tags and
not toggle them (how do you deactivate tags then?), for that you will
need to write your own function, but it is a simple matter of using
another boolean operator.
--
- yiyus || JGL . 4l77.com
Re: [dev] [dwm] tagging interface
On Tue, Sep 21, 2010 at 07:07:30PM +, Wolf Tivy wrote: > That would suck. Good to know it can be done tho. I have heard of > a way to turn off repeats, and I'll look into that before I do any > nasty race-condition hacks. The only mechanism I know of is what "xset r off" does, i.e. it is not a per-application thing. I think you'd find disabling it to be annoying in many applications. You may want to check this yourself, but years ago I dissected the issue and I remember it not being a race condition. That is, when the X server decides to repeat a key, it simultaneously (i.e. atomically wrt anything looking at the X event queue) places both Release and Press events on the queue. I just checked in xev, here you can see how these pairs of events appear: KeyRelease event, serial 28, synthetic NO, window 0x2e1, root 0x119, subw 0x0, time 1926272019, (75,141), root:(76,142), state 0x0, keycode 39 (keysym 0x73, s), same_screen YES, XLookupString gives 1 bytes: (73) "s" XFilterEvent returns: False KeyPress event, serial 28, synthetic NO, window 0x2e1, root 0x119, subw 0x0, time 1926272019, (75,141), root:(76,142), state 0x0, keycode 39 (keysym 0x73, s), same_screen YES, XLookupString gives 1 bytes: (73) "s" XmbLookupString gives 1 bytes: (73) "s" XFilterEvent returns: False As you can see, I misspoke earlier: the events have *exactly* the same time field. Combining this with what I said about the queuing (the "atomic" insertion), I think you'll agree that doing XPeekEvent inside the KeyRelease handler, and discarding the pair of events if the time, keycode, etc fields match, is a sufficiently robust test. Also, though this may seem nasty, it is nice in the sense that all programs reacting to KeyPress events get key the same key repeat behavior 'for free'.
Re: [dev] [OT] Music?
On Wed, Sep 22, 2010 at 12:41:01AM +, hiro wrote: did you consider using webfs? No, and I'll give you my reasons, 1) It's been several years since I last ported webfs to plan9port, and I wasn't in the mood to do it again. 2) webfs needs a client, and I'd have had to write one. I'd rather have used hget, but webcookies isn't ported, and even if it were, plan9port's hget isn't modified to access it the p9p way. 3) Even if webcookies were ported, YouTube requires a player that can read the cookies from a previous web access, and none of them support mplayer. It would require an external process to prefetch for every play (or a real OS mount of the filesystem, and opening the data stream file with the player), which means no live seeking. -- Kris Maglione The computing scientist's main challenge is not to get confused by the complexities of his own making. --Edsger W. Dijkstra
Re: [dev] [OT] Music?
Thanks, Wow, mplayer knows how to handle cookies? Now everything makes sense again! :D
Re: [dev] [dwm] tagging interface
> I'm not sure I'm understanding what you mean but I think you can
> achieve that only changing your config:
>
> #define TAGKEYS(KEY,TAG) \
> {
> MODKEY, KEY, toggleview, {.ui
> = 1 << TAG} }, \
>
> (n.b. toggleview instead of view)
>
> You don't need to release modkey to toggle more tags, so there
> is no
> much difference with what you are suggesting. The only "problem"
> I see
> is that your previous tags won't be remembered, I don't know if that
> is important for you. Maybe what you want is to always set tags and
> not toggle them (how do you deactivate tags then?), for that you will
> need to write your own function, but it is a simple matter of using
> another boolean operator.
Sorry for being unclear. Not quite like toggle. I mean when you press a
tag key it does the normal thing (tags = newtag or whatever), but then
if you press more tag keys before you release any of them it adds them
to the selection (like tags |= newtag). So if you mash a key combo like
MOD-1-2 and then release, it selects 1 and 2. Likewise with tagging
clients.
Whats this about previous tags? I found something fitting that description
in the source but I can't figure out why it's done like that or where it gets
used.
Is there some 'previous selection' function somewhere? If not, why is that
ugliness in there?
Thanks.
Re: [dev] [dwm] tagging interface (X event stuff)
> As you can see, I misspoke earlier: the events have *exactly* > the same time > field. Combining this with what I said about the queuing > (the "atomic" > insertion), I think you'll agree that doing XPeekEvent inside the > KeyRelease handler, and discarding the pair of events if the time, > keycode, etc fields match, is a sufficiently robust test. > > Also, though this may seem nasty, it is nice in the sense that all > programs reacting to KeyPress events get key the same key repeat > behavior 'for free'. Well that's good news. Everything should be doable then. To bad about no per-app turnoff tho. Thanks a lot! I should have this thing (alternative tagging interface) done soon, then I will post.
Re: [dev] [dwm] tagging interface
Ok so I'm done my little mods, works great. I have attached a 'patch' so that the rest of you can play with it. Some possible breakage is that the new view function doesn't toggle between the two tag sets. Still works for me though. I find this new interface to be much nicer than the seperate toggle functions. Thanks for all the help! - Original Message - From: Wolf Tivy Date: Monday, September 20, 2010 9:44 pm Subject: [dev] [dwm] tagging interface To: dev@suckless.org > I would like to change the way tag selection works in my dwm. > The way I think it should work is if you press two (or more) tag > select keysbefore you release one of them, dwm would select both > tags. Likewise for tagging windows. I think this would make the > tagging stuff much more usable and intuitive. > > I thought it would be a simple matter of adding another flag and > testing/setting it appropriately on keyup and keydown events. > But then I looked at dwm.c and it looks like it's set up to handle > 'keypress' events where what I want is 'keydown' and 'keyup'. > > So does anyone know how to change the mode or something so > that we can get the paired events instead of just 'keypress'? > I know this is possible somewhere because that's how SDL does it. > > Thanks. > -Wolf > combo.c Description: Binary data
