Re: [dev] [dwm] can't toggle tags with mouse
On Wed, May 26, 2010 at 01:08:27AM +0200, orsch...@googlemail.com wrote: > Sorry forgot to add a small request when we're already talking about this > issue. > > Is there any way to display the currently used layout via xsetroot in > statusbar? > I simply use something like setxkbmap -option "grp:alt_shift_toggle,grp_led:caps" "ie,de" which uses the otherwise unused caps lock led for this. Btw, I noticed that if you specify more than two keyboards, bits 13 and 14 in XEvent->xbutton->state seem to indicate which layout is currently selected. This seems to be consistent with the following macro defined in /usr/include/X11/extensions/XKB.h : #define XkbGroupForCoreState(s) (((s)>>13)&0x3) Rather than including XKB.h and dealing with its macros, the better solution might be to simply list the allowed modifiers in the CLEANMASK macro as in the attached patch. This works for any number of keyboard layout and masks out any other modifiers by default. Arguably the definition of CLEANMASK could even move to config.def.h for easy tweakability by users. Andreas diff --git a/dwm.c b/dwm.c --- a/dwm.c +++ b/dwm.c @@ -43,7 +43,7 @@ /* macros */ #define D if(1) #define BUTTONMASK (ButtonPressMask|ButtonReleaseMask) -#define CLEANMASK(mask) (mask & ~(numlockmask|LockMask)) +#define CLEANMASK(mask) (mask & (ShiftMask|ControlMask|Mod1Mask|Mod2Mask|Mod3Mask|Mod4Mask|Mod5Mask)) #define INRECT(X,Y,RX,RY,RW,RH) ((X) >= (RX) && (X) < (RX) + (RW) && (Y) >= (RY) && (Y) < (RY) + (RH)) #define ISVISIBLE(C)((C->tags & C->mon->tagset[C->mon->seltags])) #define LENGTH(X) (sizeof X / sizeof X[0])
[dev] [wmii] ubuntu packages on launchpad are broken
Hi everyone, especially Kris, I installed the lucid (and afterwards looked at the one from karmic, which shows the same behaviour) package from launchpad [1] on the lucid I'm unfortunately forced to use, and both packages are tiny (4.8 KiB) and lack essential files. I guess that's related to the recent problems with building wmii on ubuntu. r...@noam:~# dpkg -L wmii /. /usr /usr/share /usr/share/doc /usr/share/doc/wmii /usr/share/doc/wmii/README /usr/share/doc/wmii/copyright /usr/share/doc/wmii/changelog.Debian.gz /usr/share/menu /usr/share/menu/wmii /usr/share/icons /usr/share/icons/wmii.png /etc/X11/wmii-3.5/rc.wmii /etc/X11/wmii-3.5/wmiirc /etc/X11/wmii-3.5/welcome That's all, no binaries, nothing. Also, would you please add a wmii.desktop file for gdm to /usr/share/xsessions/, where this piece of crap keeps it's configs since the authors never heard something about /etc for config files? Kind regards, Moritz [1] https://launchpad.net/~maglione-k/+archive/ppa
Re: [dev][surf]
Sorry, I know this topic is old, but I was wondering: Why is YAML considered harmful? It's on http://harmful.cat-v.org/software/, but I can't find references about why I should not use it. Do you guys have documents or readings to provide about this?
Re: [dev][surf]
On 5/26/10, Christophe-Marie Duquesne wrote: > Sorry, I know this topic is old, but I was wondering: Why is YAML > considered harmful? It's on http://harmful.cat-v.org/software/, but I it is built on similar ideas as xml (tries to be a generic something) it has many inconsistent syntax elements (like a "feature rich" wiki) compare http://yaml.org/spec/1.2/spec.html and http://www.json.org/ yaml has complicated grammar rules which makes it hard to parse for both human and machine readers and does not seem to solve any particular problem
Re: [dev] [surf] please recheck tip
The patch looks quite good. Applied. Thanks! :) 2010/5/25 Nibble : > For the moment I've done a little patch (against tip) that fixes the > recently removed "wget download" feature, and also allows to download > files using the "Download linked file" entry in the popup menu. It > would be easy change the DOWNLOAD(p) macro to use another download > manager. > > Kind regards, > -- nibble > > On Tue, 25 May 2010 15:41:24 +0200 > pancake wrote: > >> On 05/25/10 15:24, Josh Rickmar wrote: >> > On Tue, May 25, 2010 at 11:36:28AM +0200, Claudio M. Alessi wrote: >> > >> >> On Mon, May 24, 2010 at 04:06:00PM -0400, Josh Rickmar wrote: >> >> >> >>> Also, is there a better way of doing cookies then wget? As an >> >>> (Open)BSD user, I'd like to use something in base (I did install >> >>> wget though to test to make sure that wasn't the download problem >> >>> above). >> >> IIRC you can use ftp(1) for HTTP requests. >> >> >> > Thanks, I knew about (and use) ftp(1), but didn't think it would >> > work with cookies. However, after checking the manpage, I see that >> > it does support them with the -c flag. >> > >> > >> Why dont distribute a shellscript that gets URL+cookie as arguments, >> and let the users implement their own methods like using wget, ftp, >> curl, firefox* or whatever >> >> * = yeah, using surf for browsing and firefox for download is the most >> retarded idea i can think of xD.. but surely..opening xterm or having >> a way to display all wgets in a single xterm would be good (dvtm?) >> >> Having a suckless download manager can be good. just few locs in sh. >> >> --pancake >> > >
Re: [dev][surf]
On Wed, May 26, 2010 at 02:57:12PM +0200, Christophe-Marie Duquesne wrote: > Sorry, I know this topic is old, but I was wondering: Why is YAML > considered harmful? It's on http://harmful.cat-v.org/software/, but I > can't find references about why I should not use it. Do you guys have > documents or readings to provide about this? > Hello, When it was designed, some of JSON's goals was to be minimal and future-proof. As it is described in [1], you can expect it not to change. On the other hand, YAML is not a standard (and its description is quite huge [2]). Same data can be represented in many different ways, and as syntax is considerably more complex, YAML parsers are more buggy. TL;DR : JSON sucks less. Do you really need more expressivity in the serialization language ? [1] RFC 4627, The application/json Media Type for JSON [2] http://www.yaml.org/spec/1.2/spec.html -- Etienne Millon
Re: [dev] [wmii] ubuntu packages on launchpad are broken
On Wed, 26 May 2010 14:26:42 +0200 Moritz Wilhelmy wrote: > Hi everyone, especially Kris, > > I installed the lucid (and afterwards looked at the one from karmic, > which shows the same behaviour) package from launchpad [1] on the > lucid I'm unfortunately forced to use, and both packages are tiny > (4.8 KiB) and lack essential files. I guess that's related to the > recent problems with building wmii on ubuntu. > > ... > > That's all, no binaries, nothing. Thanks for the report. I've had this problem before with launchpad, and it's strange because it doesn't always happen. Anyway, I've updated my build release script and it shouldn't happen again. New packages are up for lucid and karmic. > Also, would you please add a wmii.desktop file for gdm to > /usr/share/xsessions/, where this piece of crap keeps it's configs > since the authors never heard something about /etc for config files? That's interesting. It seems that the install line got lost in some update. It's there in the new packages. Although, I have to admit, I tend to discourage people using dot-desktop files (or really display managers at all). I only ever installed it because the official package does. -- Kris Maglione Fast, fat computers breed slow, lazy programmers. --Robert Hummel
Re: [dev] [wmii] ubuntu packages on launchpad are broken
Hi, Thanks for the quick fix! > That's interesting. It seems that the install line got lost in some > update. It's there in the new packages. Although, I have to admit, I > tend to discourage people using dot-desktop files (or really display > managers at all). I only ever installed it because the official package > does. I repeat, this is not my computer :-) Kind regards, Moritz
[dev] [dwm] System unusable after closing foobillard
Hi, I don't know if it's more a foobillard or a dwm problem but here on my FreeBSD laptop, if I start foobillard (tiled) it runs fine but if I try to close it the bar still has "foobillard" as the current window but the window disappear and then the system is completely unusable. In fact, I can move the mouse but it's so slow, I don't know if it's an infinite loop I can't do anything ! Can't spawn term, can't go to the ttys (that's weird a freeze like this). I tried a sleep 20; pkill -9 foobillard in a other term after closing it but it does not work neither. The problem is that foobillard do not have WM_CLASS atom, so can't make it start directly in floating mode. Should I mail to the foobillard upstream too? King regards. -- Demelier David
Re: [dev] Announcing rc-http 1.0
Hi, Just to say that I want to be on the list. Thanks for rc-httpd (I wait a little bit before complete the installation, maybe until werc will come with it). Sébastien On 2010-05-25, à 17:53:29 +0100, Ethan Grammatikidis wrote : > rc-httpd is a web server designed to run anywhere werc will, > requiring only rc, awk, sed, and ls from the Plan 9 toolset. At 388 > lines of code it's not tiny, but it is rather feature-complete. It > will serve CGI scripts (including werc), its own modules (rather > more efficient than CGI), static files, and automatically index > directories across multiple separately-configured virtual hosts. > Configuration requires writing rc script, but I think many people > will still find it easier than configuring Apache or many other > servers. > > Find it at http://eekee.is-a-geek.org/rc-httpd/ > > I hope this message isn't too much like spam. I wanted to get the > news of rc-httpd's existence 'out there', but won't be announcing > future releases on these lists unless encouraged otherwise. Mail me > off-list if you would like news of future updates. > > -- > Simplicity does not precede complexity, but follows it. -- Alan Perlis > >
Re: [dev] Announcing rc-http 1.0
Ok, you're on the list. I don't blame you for waiting, a couple of bugs popped up immediately after release (of course). On 26 May 2010, at 18:56, Sébastien Lacombe wrote: Hi, Just to say that I want to be on the list. Thanks for rc-httpd (I wait a little bit before complete the installation, maybe until werc will come with it). Sébastien On 2010-05-25, à 17:53:29 +0100, Ethan Grammatikidis wrote : rc-httpd is a web server designed to run anywhere werc will, requiring only rc, awk, sed, and ls from the Plan 9 toolset. At 388 lines of code it's not tiny, but it is rather feature-complete. It will serve CGI scripts (including werc), its own modules (rather more efficient than CGI), static files, and automatically index directories across multiple separately-configured virtual hosts. Configuration requires writing rc script, but I think many people will still find it easier than configuring Apache or many other servers. Find it at http://eekee.is-a-geek.org/rc-httpd/ I hope this message isn't too much like spam. I wanted to get the news of rc-httpd's existence 'out there', but won't be announcing future releases on these lists unless encouraged otherwise. Mail me off-list if you would like news of future updates. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [dev] [dwm] can't toggle tags with mouse
Hello Andreas, you may missunderstand my question. I'm looking for a possibility to display the used layout (in my case either de or pl) via xsetroot in the statusbar of dwm. Do you have any idea how to achieve that? By the way thanks for the improved version of your patch. I applied it and it's still working fine. :) Regards Robert 2010/5/26 Andreas Amann : > On Wed, May 26, 2010 at 01:08:27AM +0200, orsch...@googlemail.com wrote: >> Sorry forgot to add a small request when we're already talking about this >> issue. >> >> Is there any way to display the currently used layout via xsetroot in >> statusbar? >> > > I simply use something like > setxkbmap -option "grp:alt_shift_toggle,grp_led:caps" "ie,de" > which uses the otherwise unused caps lock led for this. > > Btw, I noticed that if you specify more than two keyboards, bits 13 and 14 > in XEvent->xbutton->state seem to indicate which layout is currently > selected. This seems to be consistent with the following macro defined in > /usr/include/X11/extensions/XKB.h : > #define XkbGroupForCoreState(s) (((s)>>13)&0x3) > > Rather than including XKB.h and dealing with its macros, the better solution > might be to simply list the allowed modifiers in the CLEANMASK macro as in the > attached patch. This works for any number of keyboard layout and masks out > any other modifiers by default. Arguably the definition of CLEANMASK could > even move to config.def.h for easy tweakability by users. > > > Andreas > > >
[dev] [wmii] Build problems with the tips of wmii and libixp
I'm trying to build the latest tip of wmii (97d57038e60a) and libixp (b2b7cb840090). I'm facing the following issues which end up in a similar manner: * wmii: CC lib/libstuff/util/_die.o In file included from /usr/include/bits/sigcontext.h:28, from /usr/include/sys/ucontext.h:27, from /usr/include/signal.h:359, from lib/libstuff/util/_die.c:4: /usr/include/asm/sigcontext.h:96: error: declaration does not declare anything make[2]: *** [util/_die.o] Error 1 make[1]: *** [dall] Error 2 make: *** [dall] Error 2 * libixp: CC lib/libixp/socket.o In file included from /usr/include/bits/sigcontext.h:28, from /usr/include/sys/ucontext.h:27, from /usr/include/signal.h:359, from lib/libixp/socket.c:8: /usr/include/asm/sigcontext.h:96: error: declaration does not declare anything make[2]: *** [socket.o] Error 1 make[1]: *** [dall] Error 2 make: *** [dall] Error 2 I can build wmii's 3.9-1 tag without problems, as well as rev d8b0d0508291 of libixp. I'm on Linux with gcc 4.3.4. What could be happening? On the other hand I see that the wmii repository now has 2 heads. If the goal is to have a 3.9 maintenance branch and another one for the main development, maybe it would be worth it to use named branches? Unless it's a short life head. Thanks, Juan Pablo
Re: [dev] [wmii] Build problems with the tips of wmii and libixp
On Wed, 26 May 2010 22:25:21 +0200 Juan Pablo Aroztegi wrote: > I'm trying to build the latest tip of wmii (97d57038e60a) and libixp > (b2b7cb840090). I'm facing the following issues which end up in a > similar manner: > > * wmii: > > CC lib/libstuff/util/_die.o > In file included from /usr/include/bits/sigcontext.h:28, > from /usr/include/sys/ucontext.h:27, > from /usr/include/signal.h:359, > from lib/libstuff/util/_die.c:4: > /usr/include/asm/sigcontext.h:96: error: declaration does not declare > anything make[2]: *** [util/_die.o] Error 1 > make[1]: *** [dall] Error 2 > make: *** [dall] Error 2 > > * libixp: > > CC lib/libixp/socket.o > In file included from /usr/include/bits/sigcontext.h:28, > from /usr/include/sys/ucontext.h:27, > from /usr/include/signal.h:359, > from lib/libixp/socket.c:8: > /usr/include/asm/sigcontext.h:96: error: declaration does not declare > anything make[2]: *** [socket.o] Error 1 > make[1]: *** [dall] Error 2 > make: *** [dall] Error 2 > > I can build wmii's 3.9-1 tag without problems, as well as rev > d8b0d0508291 of libixp. I'm on Linux with gcc 4.3.4. What could be > happening? Looking at the file, I'm guessing that you're on i386. It looks like that particular header uses anonymous unions on i386 (only) for some reason, and in hg, I've added the -pedantic-errors CFLAG. Usually the system headers are better at dealing with such things. For that matter, I'd expect gcc to ignore the setting in system headers anyway. At any rate, can you try changing -pedantic-errors to -pedantic in mk/gcc.mk? > On the other hand I see that the wmii repository now has 2 heads. If > the goal is to have a 3.9 maintenance branch and another one for the > main development, maybe it would be worth it to use named branches? > Unless it's a short life head. It's actually had two heads for ages, but one of them wasn't intentional. As for named branches, I'm generally not a fan. They're a relatively new feature, so they don't really seem like the ‘hg way’ to me. At any rate, I don't intend much maintenance in that branch in the future. The only reason it's there is because there were build problems with the release. -- Kris Maglione It is what you read when you don't have to that determines what you will be when you can't help it. --Oscar Wilde
Re: [dev] [wmii] Build problems with the tips of wmii and libixp
> Looking at the file, I'm guessing that you're on i386. It looks like > that particular header uses anonymous unions on i386 (only) for some > reason, and in hg, I've added the -pedantic-errors CFLAG. Usually the > system headers are better at dealing with such things. For that matter, > I'd expect gcc to ignore the setting in system headers anyway. > > At any rate, can you try changing -pedantic-errors to -pedantic in > mk/gcc.mk? Yes, you are right, I'm on 386. And switching to -pedantic make both wmii and libixp build successfully. > It's actually had two heads for ages, but one of them wasn't > intentional. As for named branches, I'm generally not a fan. They're a > relatively new feature, so they don't really seem like the ‘hg way’ to > me. At any rate, I don't intend much maintenance in that branch in the > future. The only reason it's there is because there were build problems > with the release. Oh ok, I didn't notice that before. I generally also prefer the "one repository per branch" approach, but I'd also choose named branches over unnamed heads. As you say this doesn't apply in this case, though. Thank you, Juan Pablo
[dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
Hello, In the latest tip, recently I have run into a problem where when I run wmiir xwrite /tag/sel/ctl kill in a terminal for example, wmii stops responding to any keypresses, but I can switch between already open windows with the mouse, though not much else. Any idea what is going on or how I might be able to troubleshoot the issue? Thanks, Alex
Re: [dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
On Wed, 26 May 2010 17:06:52 -0400 Alex Kilgore wrote: > Hello, > In the latest tip, recently I have run into a problem where > when I run wmiir xwrite /tag/sel/ctl kill in a terminal for example, > wmii stops responding to any keypresses, but I can switch between > already open windows with the mouse, though not much else. > Any idea what is going on or how I might be able to troubleshoot the > issue? Thanks, Well, in general, you wouldn't write ‘kill’ to /tag/sel/ctl, because it wouldn't do anything but report an error. Er, just read the subject, though, in which case: 1) What rc are you using? 2) Try wmiir read /event from the commandline and see if your key presses are reported. It's possible that your rc is catching some signal from whatever client was killed, but I really couldn't say without more specifics. -- Kris Maglione A man's library is a sort of harem. --Ralph Waldo Emerson
Re: [dev] [wmii] Build problems with the tips of wmii and libixp
On Wed, 26 May 2010 22:52:12 +0200 Juan Pablo Aroztegi wrote: > > Looking at the file, I'm guessing that you're on i386. It looks like > > that particular header uses anonymous unions on i386 (only) for some > > reason, and in hg, I've added the -pedantic-errors CFLAG. Usually > > the system headers are better at dealing with such things. For that > > matter, I'd expect gcc to ignore the setting in system headers > > anyway. > > > > At any rate, can you try changing -pedantic-errors to -pedantic in > > mk/gcc.mk? > Yes, you are right, I'm on 386. And switching to -pedantic make both > wmii and libixp build successfully. Okay, I'll have to switch it to -pedantic in the repo and add -pedandic-errors to my config.local.mk. Thanks for the info. -- Kris Maglione It is a farce to call any being virtuous whose virtues do not result from the exercise of its own reason. --Mary Wollstonecraft
Re: [dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
On Wed, May 26, 2010 at 05:37:57PM -0400, Kris Maglione wrote: > On Wed, 26 May 2010 17:06:52 -0400 > Alex Kilgore wrote: > > > Hello, > > In the latest tip, recently I have run into a problem where > > when I run wmiir xwrite /tag/sel/ctl kill in a terminal for example, > > wmii stops responding to any keypresses, but I can switch between > > already open windows with the mouse, though not much else. > > Any idea what is going on or how I might be able to troubleshoot the > > issue? Thanks, > > Well, in general, you wouldn't write ‘kill’ to /tag/sel/ctl, because it > wouldn't do anything but report an error. Er, just read the subject, > though, in which case: Ah, yes, I meant /client/sel/ctl, sorry > > 1) What rc are you using? I am using wmiirc, just in case there was an issue with that, I copied a fresh one from the rc directory and still can reproduce the behavior > 2) Try wmiir read /event from the commandline and see if your key >presses are reported. The keypresses are still reported, but it seems that they are just not acted upon > > It's possible that your rc is catching some signal from whatever client > was killed, but I really couldn't say without more specifics. > > -- > Kris Maglione > > A man's library is a sort of harem. > --Ralph Waldo Emerson >
Re: [dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
On Wed, 26 May 2010 17:55:09 -0400 Alex Kilgore wrote: > > 2) Try wmiir read /event from the commandline and see if your key > >presses are reported. > > The keypresses are still reported, but it seems that they are just > not acted upon In that case, the problem is either with wmiir, the 9P connection itself, or wmiirc. The best thing to do is launch wmiirc from a terminal as ‘sh -x wmiirc’. You'll probably want to ‘wmiir rm /rbar/status’, as well. Then run ‘wmiir xwrite /client/sel/ctl kill’ and see what output you get from wmiirc when you try key pressing your accelerator keys. Probably best to just post the output here, actually. It might be a good idea to find wmiirc's subprocesses with ‘psid -p’, too. -- Kris Maglione The easy confidence with which I know another man's religion is folly teaches me to suspect that my own is also. --Mark Twain
[dev] final fix for debian
Hi Kris, I built the .deb package from 3.9-2 with make deb. The build was ok, but there was a problem with installation. I had to change a line in file: debian/patches/01-config-local-mk.patch where: +DESTDIR=$(ROOT)/debian/wmii-hg/ should instead be: +DESTDIR=$(ROOT)/debian/wmii/ Just fix that and the package is debian ready. Thanks for this great wm! Davide
Re: [dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
On Wed, May 26, 2010 at 06:28:25PM -0400, Kris Maglione wrote:
> On Wed, 26 May 2010 17:55:09 -0400
> > The keypresses are still reported, but it seems that they are just
> > not acted upon
>
> In that case, the problem is either with wmiir, the 9P connection
> itself, or wmiirc. The best thing to do is launch wmiirc from a
> terminal as ‘sh -x wmiirc’. You'll probably want to ‘wmiir
> rm /rbar/status’, as well. Then run ‘wmiir xwrite /client/sel/ctl kill’
> and see what output you get from wmiirc when you try key pressing your
> accelerator keys. Probably best to just post the output here, actually.
> It might be a good idea to find wmiirc's subprocesses with ‘psid -p’,
> too.
Actually, this helped quite a bit, first of all, I tried running sh -x
~/.wmii-hg/wmiirc and realized that the issue only happens when I am using
dash, so sh behaved as expected, so if i change the #!/bin/dash -f in wmiirc to
#!/bin/sh, the problem goes away!
When I did run ‘wmiir xwrite /client/sel/ctl kill’ from a dash instance of
wmiirc, it quits execution
Just in case you might know what was causing it based on this information,
this is the end of the output of
dash -x ~/.wmii-hg/wmiirc
+ echo ClientMouseDown 0xed 3
+ sed s/^[^ ]* //
+ wi_arg=0xed 3
+ unset IFS
+ set -- ClientMouseDown 0xed 3
+ event=ClientMouseDown
+ shift
+ Event ClientMouseDown 0xed 3
+ event=ClientMouseDown
+ shift
+ read wi_event
+ wi_fnmenu Client 3 0xed
+ group=Client-3
+ shift 2
+ echo Client-3
+ tr - _
+ _last=Client_3_last
+ eval last="$Client_3_last"
+ last=
+ echo LBar-3-Delete
Client-3-Delete
Client-3-Fullscreen
+ awk -v s=Client-3 BEGIN{n=length(s)}
substr($1,1,n) == s{print substr($1,n+2)}
+ set -- Delete Fullscreen
+ [ 2 != 0 ]
+ wmii9menu -i Delete Fullscreen
+ res=Delete
+ [ -n Delete ]
+ eval Client_3_last="$res"
+ Client_3_last=Delete
+ Menu Client-3-Delete 0xed
+ menu=Client-3-Delete
+ shift
+ wmiir xwrite /client/0xed/ctl kill
+ true
Thanks a lot for the help
Re: [dev] final fix for debian
On Thu, 27 May 2010 00:33:05 +0200 Davide Anchisi wrote: > Hi Kris, > > I built the .deb package from 3.9-2 with make deb. The build was ok, > but there was a problem with installation. > I had to change a line in file: >debian/patches/01-config-local-mk.patch > where: >+DESTDIR=$(ROOT)/debian/wmii-hg/ > should instead be: >+DESTDIR=$(ROOT)/debian/wmii/ > > Just fix that and the package is debian ready. It's already done in the launchpad release. I hadn't considered updating the release tarball, too... -- Kris Maglione Only the educated are free. --Epictetus
[dev] Fullscreen issue & EWMH
Hi,
I recently switched from Firefox to Chrome and surprisingly Chrome
weren't able to switch to full screen because of the way GTK handles
full screen.
So, here is a patch that can be integrated or provided as an auxiliary
patch that makes dwm support the _NET_WM_STATE_FULLSCREEN atom.
Regards,
--
Sylvain `Magicking` Laurent
diff -r 1456ca0c94b7 dwm.c
--- a/dwm.c Sun Apr 11 18:42:32 2010 +0100
+++ b/dwm.c Mon May 24 21:12:07 2010 +0200
@@ -58,7 +58,8 @@
/* enums */
enum { CurNormal, CurResize, CurMove, CurLast };/* cursor */
enum { ColBorder, ColFG, ColBG, ColLast }; /* color */
-enum { NetSupported, NetWMName, NetLast }; /* EWMH atoms */
+enum { NetSupported, NetWMName, NetWMState,
+ NetWMFullscreen, NetLast }; /* EWMH atoms */
enum { WMProtocols, WMDelete, WMState, WMLast };/* default atoms */
enum { ClkTagBar, ClkLtSymbol, ClkStatusText, ClkWinTitle,
ClkClientWin, ClkRootWin, ClkLast }; /* clicks */
@@ -162,6 +163,7 @@
static void cleanup(void);
static void cleanupmon(Monitor *mon);
static void clearurgent(Client *c);
+static void clientmessage(XEvent *e);
static void configure(Client *c);
static void configurenotify(XEvent *e);
static void configurerequest(XEvent *e);
@@ -250,6 +252,7 @@
static unsigned int numlockmask = 0;
static void (*handler[LASTEvent]) (XEvent *) = {
[ButtonPress] = buttonpress,
+ [ClientMessage] = clientmessage,
[ConfigureRequest] = configurerequest,
[ConfigureNotify] = configurenotify,
[DestroyNotify] = destroynotify,
@@ -1293,6 +1296,20 @@
}
void
+clientmessage(XEvent *e) {
+ XClientMessageEvent *cme = &e->xclient;
+
+ if (cme->message_type == netatom[NetWMState]) {
+ if (cme->data.l[1] == netatom[NetWMFullscreen]) {
+ if (cme->data.l[0])
+XChangeProperty(dpy, cme->window, netatom[NetWMState], XA_ATOM, 32, PropModeReplace, (unsigned char*)&netatom[NetWMFullscreen], 1);
+ else
+XChangeProperty(dpy, cme->window, netatom[NetWMState], XA_ATOM, 32, PropModeReplace, (unsigned char*)0, 0);
+ }
+ }
+}
+
+void
quit(const Arg *arg) {
running = False;
}
@@ -1392,6 +1409,7 @@
XEvent ev;
static const char *evname[LASTEvent] = {
[ButtonPress] = "buttonpress",
+ [ClientMessage] = "clientmessage",
[ConfigureRequest] = "configurerequest",
[ConfigureNotify] = "configurenotify",
[DestroyNotify] = "destroynotify",
@@ -1510,6 +1528,8 @@
wmatom[WMState] = XInternAtom(dpy, "WM_STATE", False);
netatom[NetSupported] = XInternAtom(dpy, "_NET_SUPPORTED", False);
netatom[NetWMName] = XInternAtom(dpy, "_NET_WM_NAME", False);
+ netatom[NetWMState] = XInternAtom(dpy, "_NET_WM_STATE", False);
+ netatom[NetWMFullscreen] = XInternAtom(dpy, "_NET_WM_STATE_FULLSCREEN", False);
/* init cursors */
cursor[CurNormal] = XCreateFontCursor(dpy, XC_left_ptr);
cursor[CurResize] = XCreateFontCursor(dpy, XC_sizing);
Re: [dev] Fullscreen issue & EWMH
What do you mean by talking about fullscreen? Fullscreen when using Chrome itself or also when watching Flash content? Because this is still an unsolved problem. Regards Robert 2010/5/27 Sylvain Laurent : > Hi, > > I recently switched from Firefox to Chrome and surprisingly Chrome > weren't able to switch to full screen because of the way GTK handles > full screen. > > So, here is a patch that can be integrated or provided as an auxiliary > patch that makes dwm support the _NET_WM_STATE_FULLSCREEN atom. > > Regards, > > -- > Sylvain `Magicking` Laurent >
Re: [dev] Fullscreen issue & EWMH
On Thu, May 27, 2010 at 07:59:29AM +0200, orsch...@googlemail.com wrote: > Because this is still an unsolved problem. Both problem are solved: o Chrome: see the previous post; o Flash: see http://lists.suckless.org/dev/0912/2687.html Regards, Claudio M. Alessi
