Re: [dev] Wayland st!!??
On Sat, Jul 27, 2013 at 10:43:00PM -0700, Michael Forney wrote: On Sat, 27 Jul 2013 14:17:42 -0400, Carlos Torres vlaadbr...@gmail.com wrote: I didn't know about this http://www.phoronix.com/scan.php?page=news_itempx=MTQyMTQ I'm both excited or looking to troll I'm the author of the port. I'm not sure how the suckless community feels about Wayland, but it seems like the core protocol is fairly lightweight, depends only on libffi, and is refreshing to work with compared to X. Weston's goals are perhaps more orthogonal to suckless, but I think there is potential for a suckless compositor. I'd rather use dwm + wayland than dwm + xorg.
[dev] [tabbed] [PATCH] Fixed obscure miscalculation when a client is closed.
This crops up whenever you just switched from tab # N+1 to tab # N
and close current tab. unmanage() first decreases lastsel
(so it becomes N) then erroneously tests it against sel and focuses first tab
instead. One can see that focus() would never set lastsel == sel,
so I took liberty to fix this annoying behaviour which happens to frequently
with newposition = 0 and npisrelative = True settings.
---
tabbed.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tabbed.c b/tabbed.c
index ba1df21..9ece904 100644
--- a/tabbed.c
+++ b/tabbed.c
@@ -1008,7 +1008,11 @@ unmanage(int c) {
}
if(c == sel) {
- if(lastsel 0 lastsel != sel) {
+ /* Note that focus() will never set lastsel == sel,
+* so if here lastsel == sel, it was decreased by above
if() clause
+* and was actually (sel + 1) before.
+*/
+ if(lastsel 0) {
focus(lastsel);
} else {
focus(0);
--
1.8.3.2
[dev] [tabbed] [PATCH] Limit mouse handling to top bar area.
It's rather annoying when you e.g. scroll in Surf, move your mouse a little bit
too low, and Tabbed starts to switching tabs because you got caught in lower
border area. I don't think this behaviour is intentional or desirable.
---
tabbed.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tabbed.c b/tabbed.c
index 9ece904..6c8a986 100644
--- a/tabbed.c
+++ b/tabbed.c
@@ -175,6 +175,9 @@ buttonpress(const XEvent *e) {
if((getfirsttab() != 0 ev-x TEXTW(before)) || ev-x 0)
return;
+ if(ev-y 0 || ev- y bh)
+ return;
+
for(i = 0; i nclients; i++) {
if(clients[i]-tabx ev-x) {
switch(ev-button) {
--
1.8.3.2
[dev] [st] [PATCH] Fixed memory leak in xsettitle().
---
st.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/st.c b/st.c
index 289ecb8..0b1e97a 100644
--- a/st.c
+++ b/st.c
@@ -3211,6 +3211,7 @@ xsettitle(char *p) {
Xutf8TextListToTextProperty(xw.dpy, p, 1, XUTF8StringStyle,
prop);
XSetWMName(xw.dpy, xw.win, prop);
+ XFree(prop.value);
}
void
--
1.8.3.2
Re: [dev] [dwm] multiple monitors, default window placement
On Wed, Jul 03, 2013 at 06:59:34PM +0200, Anselm R Garbe wrote:
On 28 June 2013 14:25, Martin Kopta mar...@kopta.eu wrote:
If I create new window, it gets placed on the primary monitor no matter what
monitor is currently focused and no matter where mouse cursor is. It is
annoying, but (for most apps) I can just move the window to the prefered
(nonprimary) monitor. But some apps cannot be moved -- rdesktop and such. Is
there any solution to this? It is considered as faulty behavior? Did I miss
something in config.h? Thank you.
Do you experience this with vanilla dwm from git? If not, then it
might help to see your rules declaration of config.h.
Best regards,
Anselm
Yes, I use newest vanilla dwm from git without any patches. My rules are empty:
static const Rule rules[] = { { 0 } };
Full config.h at pastebin [1]. Thank you for your time!
Best regards,
Martin
[1] http://pastebin.com/01FZfWjN
pgpj6QH3RMWG9.pgp
Description: PGP signature
Re: [dev] Wayland st!!??
On Mon, Jul 29, 2013 at 04:15:59PM +1000, oneofthem wrote: On Sat, Jul 27, 2013 at 10:43:00PM -0700, Michael Forney wrote: On Sat, 27 Jul 2013 14:17:42 -0400, Carlos Torres vlaadbr...@gmail.com wrote: I didn't know about this http://www.phoronix.com/scan.php?page=news_itempx=MTQyMTQ I'm both excited or looking to troll I'm the author of the port. I'm not sure how the suckless community feels about Wayland, but it seems like the core protocol is fairly lightweight, depends only on libffi, and is refreshing to work with compared to X. Weston's goals are perhaps more orthogonal to suckless, but I think there is potential for a suckless compositor. I'd rather use dwm + wayland than dwm + xorg. I am very interested in st (as well as other suckless projects) on weston/wayland as well. The wayland protocol seems to be very concise and it certainly does not come with all of the legacy baggage of X. That said, I noticed that the wayland port of the st code is around 70 lines longer than the X version[1]. I have not investigated way that is though. As far as I know dwm would have to be ported as a wayland-compositor (which does not do any composing). Does anyone know of a dwm-port/suckless-compositor for the wayland protocol that is still being actively developed? [1] https://github.com/michaelforney/st/blob/wayland/st.c (wayland vs. master branch) pgp0TmiJTH5ts.pgp Description: PGP signature
[dev] The new version of wondrous swaprootname (1)!
The version 2.0 of swaprootname (1) has seen the world, now with less race conditions! swaprootname [1] is your tool of choice for permanently or temporarily changing root window name, in scripts or regularly in shell. Unfortunately, previous version suffered from an issue: if you launched two instances of it, sometimes it will not restore original name properly, which is indeed annoying. The new version fixes this, and now you can have as many scripts concurrently showing useful information in root name as you want! [2] Download one today and rejoice! [1] https://github.com/ElectronicRU/swaprootname [2] Technically, X11 text properties may or may not have some maximum length, so amount of scripts is tecnically limited, but I expect this bound to be large enough. Also, race conditions may still occur, due to name changing not being instant, but chances are, they will not.
Re: [dev] daemon for DWM
Hello there, On 29 July 2013 01:02, Silvan Jegen s.je...@gmail.com wrote: Comments and criticism is welcome. The net monitor is something I'm looking for, though I'm not sure how I would integrate it with my current shell script: https://github.com/kaihendry/Kai-s--HOME/blob/master/.xinitrc#L43 https://github.com/kaihendry/Kai-s--HOME/blob/master/bin/dwm_status Prefer the versatility of shell. :} Though that earlier shell example is incomplete and I guess it would have to be daemonised to keep the old values. Maybe I'll adjust the C program to write the netstats to a file for a shell script like mine to read it? Is that sane? And run your C program from systemd? (*duck*)
Re: [dev] daemon for DWM
On Mon, Jul 29, 2013 at 05:26:23PM +0800, Kai Hendry wrote: Hello there, On 29 July 2013 01:02, Silvan Jegen s.je...@gmail.com wrote: Comments and criticism is welcome. The net monitor is something I'm looking for, though I'm not sure how I would integrate it with my current shell script: https://github.com/kaihendry/Kai-s--HOME/blob/master/.xinitrc#L43 https://github.com/kaihendry/Kai-s--HOME/blob/master/bin/dwm_status Prefer the versatility of shell. :} Though that earlier shell example is incomplete and I guess it would have to be daemonised to keep the old values. Both are functionally equivalent of course. IMHO a dedicated but simple C program is a more efficient and cleaner solution, however. Maybe I'll adjust the C program to write the netstats to a file for a shell script like mine to read it? Is that sane? That seems rather insane to me, I have to admit :-) And run your C program from systemd? (*duck*) Well, I am running systemd as well so that does not strike me as being especially duck-worthy. Other people on this list have a different opinion on this, I bet...
Re: [dev] Wayland st!!??
On Mon, 29 Jul 2013 09:59:06 +0200, Silvan Jegen s.je...@gmail.com wrote: I am very interested in st (as well as other suckless projects) on weston/wayland as well. The wayland protocol seems to be very concise and it certainly does not come with all of the legacy baggage of X. That said, I noticed that the wayland port of the st code is around 70 lines longer than the X version[1]. I have not investigated way that is though. It's mostly because of the many event handlers. In Wayland, you don't have to register listeners for objects, but if you do, you have to implement all of it's events. Mostly this is okay, but in a few places, there were some events that I didn't use, like the drag and drop facilities in wl_data_device. Also, Wayland uses separate events for button/key press/release as well as axis (which required a new axis binding shortcut list in config.h and handling in st.c). These little changes add up (function prototypes as well as definitions), which account for the difference in code size. However, nearly all of this is cosmetic and doesn't really affect the code's complexity. As far as I know dwm would have to be ported as a wayland-compositor (which does not do any composing). Does anyone know of a dwm-port/suckless-compositor for the wayland protocol that is still being actively developed? Making dwm act as a Wayland shell (what Wayland calls a window manager), wouldn't be too difficult. Many of the X11 related bits correspond fairly closely to wl_shell bits, and the ones that don't probably aren't even necessary under Wayland. However, the compositor part is tricky. The easiest method would be to make dwm a shell plugin for Weston. I don't like this approach because Weston seems to be focusing on a more modern desktop features like animation, transparency, window decorations, etc. I also dislike the idea of dwm being loaded as a plugin. I don't think that implementing a compositor from scratch (which would do nothing more than blit the windows onto your screen, and maybe draw some borders) is out of the question. I'm estimating that it could be done in ~4000 lines (maybe more, maybe less). The question in this scenario is where does the window manager fit in? I don't like the idea of the window manager being in the same project as the compositor, as they do two different jobs and other window managers should be able to make use of it as well. However, there has to be some implementation of wl_shell on the compositor side. One solution would be to make a protocol extension (which are really easy to do) and use it to communicate with a separate window manager process. This would be similar to how an X window manager works, but it would require implementing a wl_shell that kind of acts as a proxy. Another option would be to make the compositor into a library that a window manager can link with. The wl_shell implementation would be more direct but then we would have to deal with giving the window manager/compositor special privileges (Weston does this by using a suid launcher which does stuff like open input devices and manage drm master through a socket pair). Another problem is that we would have a single program which does quite a lot of stuff. I'd love to hear other people's opinions on this topic. -- Michael Forney mfor...@mforney.org
Re: [dev] Wayland st!!??
On Mon, Jul 29, 2013 at 03:08:44AM -0700, Michael Forney wrote: On Mon, 29 Jul 2013 09:59:06 +0200, Silvan Jegen s.je...@gmail.com wrote: I am very interested in st (as well as other suckless projects) on weston/wayland as well. The wayland protocol seems to be very concise and it certainly does not come with all of the legacy baggage of X. That said, I noticed that the wayland port of the st code is around 70 lines longer than the X version[1]. I have not investigated way that is though. It's mostly because of the many event handlers. In Wayland, you don't have to register listeners for objects, but if you do, you have to implement all of it's events. Mostly this is okay, but in a few places, there were some events that I didn't use, like the drag and drop facilities in wl_data_device. Also, Wayland uses separate events for button/key press/release as well as axis (which required a new axis binding shortcut list in config.h and handling in st.c). These little changes add up (function prototypes as well as definitions), which account for the difference in code size. However, nearly all of this is cosmetic and doesn't really affect the code's complexity. First of all, thanks a lot for these explanations! As far as I know dwm would have to be ported as a wayland-compositor (which does not do any composing). Does anyone know of a dwm-port/suckless-compositor for the wayland protocol that is still being actively developed? Making dwm act as a Wayland shell (what Wayland calls a window manager), wouldn't be too difficult. Many of the X11 related bits correspond fairly closely to wl_shell bits, and the ones that don't probably aren't even necessary under Wayland. However, the compositor part is tricky. The easiest method would be to make dwm a shell plugin for Weston. I don't like this approach because Weston seems to be focusing on a more modern desktop features like animation, transparency, window decorations, etc. I also dislike the idea of dwm being loaded as a plugin. So the reason you would not want dwm to be a shell plugin for Weston is that Weston is too focused on fancy modern features, correct? I don't think that implementing a compositor from scratch (which would do nothing more than blit the windows onto your screen, and maybe draw some borders) is out of the question. I'm estimating that it could be done in ~4000 lines (maybe more, maybe less). The question in this scenario is where does the window manager fit in? I don't like the idea of the window manager being in the same project as the compositor, as they do two different jobs and other window managers should be able to make use of it as well. It sounds to me like implementing a simple blitting compositor from scratch would be useful not only for the suckless projects, but other people not caring about those modern compositing features you mentioned as well. If there was such a simple blitting compositor, one could then write dwm as a shell plugin for it. That way one could retain some modularity while not having to use any of these modern features of Weston. However, there has to be some implementation of wl_shell on the compositor side. One solution would be to make a protocol extension (which are really easy to do) and use it to communicate with a separate window manager process. This would be similar to how an X window manager works, but it would require implementing a wl_shell that kind of acts as a proxy. Another option would be to make the compositor into a library that a window manager can link with. The wl_shell implementation would be more direct but then we would have to deal with giving the window manager/compositor special privileges (Weston does this by using a suid launcher which does stuff like open input devices and manage drm master through a socket pair). Another problem is that we would have a single program which does quite a lot of stuff. Implementing a proxy wl_shell for this hypothetical blitting compositor and having dwm as a separate process communicating with it would be another possible approach. Please note that I have no idea how difficult it would be to implement a blitting wayland compositor in ~4000 lines of code. pgp0LSHdzqKeE.pgp Description: PGP signature
[dev] Re: daemon for DWM
Kai Hendry dixit: And run your C program from systemd? (*duck*) /me shudders (at the mere thought of “anathema” Poettering software) Someone actually took my analog clock (written in mksh) and packaged it for Arsch Linux, with a systemd… whatever they call initscripts these days… that runs it on tty12. I’m still unsure what to think about that. bye, //mirabilos -- 22:59⎜Vutral glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜Vutral die meisten raffen auch nicht mehr von windows | 23:01⎜Vutral bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus?
Re: [dev] Re: coreutils / moreutils - DC a directory counter
On mán 29.júl 2013 04:39, Paul Hoffman wrote: Their 100+ Perl and bash scripts are slow because they're opening files in a humongous directory. They can't subdivide the directory because they're afraid that they will break the scripts when modifying them. I posted a comprehensive comment on the blog post that has yet to be approved by the censor. In short, ext2/3 directories are linked lists. You can traverse said list in constant space and process each entry when you encounter it. O(n) time is unavoidable. Bash globs and ls listings are automatically sorted. Dash and ls -f or find . -type f don't. Switching to dash might result in all sorts of compatibility issues, but s/ls/ls -f/g is easy to test, and just might work. And then s/ \* / \$(ls -f) /g (assuming old regex, \n in $IFS). Dividing the directory into folders requires structural changes and just contains the scalability issue instead of just not sorting. Sorting does not only take up to O(n^2) time, but requires searching for every single entry in the linked list. That's equal to traversing half the list n times, instead of all of the list just once. http://ext2.sourceforge.net/2005-ols/paper-html/node3.html P.S. This just might be my favorite regex: s/ \* / \$\(ls -f\) /g.
Re: [dev] Wayland st!!??
On Mon, 29 Jul 2013 12:47:49 +0200, Silvan Jegen s.je...@gmail.com wrote: So the reason you would not want dwm to be a shell plugin for Weston is that Weston is too focused on fancy modern features, correct? Eh, maybe I am being a bit too hard on Weston. It just seems to be growing quite steadily which scares me and I wasn't thrilled with it overall. Implementing a proxy wl_shell for this hypothetical blitting compositor and having dwm as a separate process communicating with it would be another possible approach. Yeah, that's what I tried to describe. -- Michael Forney mfor...@mforney.org
Re: [dev] Re: coreutils / moreutils - DC a directory counter
Bjartur Thorlacius dixit: by the censor. In short, ext2/3 directories are linked lists. You can traverse Are they, still? I thought they had the equivalent of UFS_DIRHASH nowadays… bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs
Re: [dev] Re: coreutils / moreutils - DC a directory counter
On mán 29.júl 2013 11:38, Thorsten Glaser wrote: Are they, still? I thought they had the equivalent of UFS_DIRHASH nowadays… Ext4 does, optionally.
