[dev] Binary Space Partitioning Window Manager
Hi, I'm planning on writing a window manager with the following characteristics: - Windows are represented as the leaves of a binary tree. - To each leaf corresponds exactly one window. - The only nodes which can be focused are the leaves. - The leaves are called *window nodes*. - The other nodes are called *container nodes*. - Only two methods of node insertion will be provided: *replace* and *pair*. Example: insertion of a new node (number 4) into the given tree with the *replace* method: b c / \ / \ 3 a --> 4 b ^ / \ ^ / \ 2 1 3 a / \ 2 1 +-+ +-+ ||| ||| || 2 | || 3 | ||| ||| | 3 || --> | 4 || | ^ || | ^ | | | || 1 | || 2 | 1 | ||| || | | +-+ +-+ And with the *pair* method: b b / \ / \ 3 a --> c a ^ / \ / \ / \ 2 1 4 3 2 1 ^ +-+ +-+ ||| ||| || 2 | | 4 | 2 | ||| | ^ || | 3 || --> ||| | ^ || ||| || 1 | | 3 | 1 | ||| ||| +-+ +-+ - Each container node is a split rectangle. - The splitting method of a container node is either *automatic* or *manual*. - In the *automatic* splitting mode, the split type is vertical if the width of the rectangle of the node is greater that its height and horizontal otherwise. - Several tree transformations will be provided: directional leaf swap, node pulling, rotation, contraction, dilatation... Greetings, -- b.d (| |) ^ ^
Re: [dev] Binary Space Partitioning Window Manager
Greetings. On Sat, 28 Jul 2012 11:12:21 +0200 Bastien Dejean wrote: > Hi, > > I'm planning on writing a window manager with the following > characteristics: > > - Windows are represented as the leaves of a binary tree. > - To each leaf corresponds exactly one window. > - The only nodes which can be focused are the leaves. > - The leaves are called *window nodes*. > - The other nodes are called *container nodes*. > - Only two methods of node insertion will be provided: *replace* and *pair*. > [...] > - Each container node is a split rectangle. > - The splitting method of a container node is either *automatic* or *manual*. > - In the *automatic* splitting mode, the split type is vertical if the width > of > the rectangle of the node is greater that its height and horizontal > otherwise. > - Several tree transformations will be provided: directional leaf swap, node > pulling, rotation, contraction, dilatation... > [...] What are the practical and productivity gains you expect from such fea‐ tures? What is your reallife example where such features would be need‐ ed? Sincerely, Christoph Lohmann
Re: [dev] Binary Space Partitioning Window Manager
Bastien Dejean writes: > Hi, > > I'm planning on writing a window manager with the following > characteristics: > > - Windows are represented as the leaves of a binary tree. You should look at herbstluftwm as it already imlements a binary tree method for window management (manual tiling only). -brandon
Re: [dev] Binary Space Partitioning Window Manager
Quoth Bastien Dejean: > I'm planning on writing a window manager with the following > characteristics: > ... Sounds rather interesting, I approve, give it a go. Two potentiial issues I see: - It wouldn't interact too well with tagging. Presumably. Either whole container nodes and their leaves would have to be assigned tags, or each tag would have its own tree structure. The former might actually not be a bad outcome. - I can't imagine how the interface would work in a non-annoying way. How would one choose the container to replace/pair to? Maybe just doing it on whatever window was focused would be fine. Anyway, ignore Christoph, he's just trying to push mediocrity. Nick
Re: [dev] Binary Space Partitioning Window Manager
Greetings. On Sat, 28 Jul 2012 12:23:55 +0200 Nick wrote: > Anyway, ignore Christoph, he's just trying to push mediocrity. Elitism needs scientific analysis too. Just adding features because it sounds cool will end you up in the same situation as Gnome. Sincerely, Christoph Lohmann
Re: [dev] Binary Space Partitioning Window Manager
Christoph Lohmann: > What are the practical and productivity gains you expect from such fea‐ > tures? What is your reallife example where such features would be need‐ > ed? Hyphenated plain text is... a catastrophe.
Re: [dev] Binary Space Partitioning Window Manager
On Sat, Jul 28, 2012 at 11:15:48AM +0100, Nick wrote: > Anyway, ignore Christoph, he's just trying to push mediocrity. At least he runs hg push once in a while. Where is the code?
Re: [dev] Binary Space Partitioning Window Manager
Brandon Invergo: > You should look at herbstluftwm as it already imlements a binary tree > method for window management (manual tiling only). I'm actually an herbstluftwm contributor. The problems I have with herbstluftwm's concepts should be easy to deduce from the first message of this thread. Cheers, -- b.d (| |) ^ ^
Re: [dev] Binary Space Partitioning Window Manager
Greetings. On Sat, 28 Jul 2012 13:54:07 +0200 Bastien Dejean wrote: > Christoph Lohmann: > > > What are the practical and productivity gains you expect from such fea‐ > > tures? What is your reallife example where such features would be need‐ > > ed? > > Hyphenated plain text is... a catastrophe. No. Sincerely, Christoph Lohmann
Re: [dev] Binary Space Partitioning Window Manager
Nick: > Two potentiial > issues I see: > > - It wouldn't interact too well with tagging. Presumably. Either > whole container nodes and their leaves would have to be assigned > tags, or each tag would have its own tree structure. The former > might actually not be a bad outcome. I'm afraid I don't see how it could support tagging. Having one tree per *desktop* seems to be the only option. > - I can't imagine how the interface would work in a non-annoying > way. How would one choose the container to replace/pair to? Maybe > just doing it on whatever window was focused would be fine. It is how I intend to do it (the '^' character in my ASCII drawings indicates the focused window). Thanks for your feedback, -- b.d (| |) ^ ^
Re: [dev] st: improved double-buffering with Xdbe
FYI I've applied this patch to st's default branch (commit #245)
Enjoy,
-brandon
Brandon Invergo writes:
> Hi,
> As some background, I've been using st on an Arm device (Genesi Efika
> MX) which has relatively low specs compared to your average x86/amd64
> computer. st should be ideal because of how small it is compared to
> xterm or rxvt but the reality is that its rendering is quite a bit
> slower. Under heavy processor load, such as building a package, I can
> literally watch the terminal window refreshing (ie I can see a line
> traveling down the window, above which the window is refreshed and below
> which the window is dirty"tearing").
>
> I've changed the code to use the X Double Buffer Extension (Xdbe).
> Instead of rendering to a Pixbuf and then copying that Pixbuf to the
> window, which is a relatively slow operation, it now renders to an
> XdbeBackBuffer and then simply swaps buffers with the window. The result
> is tear-free and apparently faster rendering even on an 800mhz Arm cpu.
>
> A side effect is that the code is a bit shorter as a result too. For
> example, xresize() does almost nothing now, since the XdbeBackBuffer is
> automatically resized with the window (see the DBE manpage), so several
> Xlib calls can be removed from that function.
>
> The provided diff is against the default branch, however I also got it
> working for the xft branch. I can provide a diff for that too if you
> want but the only extra difference is that any Xft draw-related calls
> should work on xw.buf rather than xw.win (including the one in
> xresize()).
>
> LIBS in config.mk should have -lXext appended. I forgot to include that
> in the patch.
>
> A few caveats: 1) my C skills are a bit rusty, 2) I'm unfamiliar with
> Mercurial, 3) I'm completely new to Xlib. So, while it Works For Me
> (tm), you might want to test it a bit and let me know if I messed up
> something.
>
> I'm going to keep hacking on it to try to improve further the speed if I
> can.
>
> Cheers,
> Brandon Invergo
> diff -r e1414acbe547 st.c
> --- a/st.cMon Feb 27 12:48:13 2012 +0100
> +++ b/st.cFri Apr 20 09:10:28 2012 +0200
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #if defined(__linux)
> #include
> @@ -178,7 +179,7 @@
> Display* dpy;
> Colormap cmap;
> Window win;
> - Pixmap buf;
> + XdbeBackBuffer buf;
> Atom xembed;
> XIM xim;
> XIC xic;
> @@ -270,7 +271,7 @@
> static void xdraws(char *, Glyph, int, int, int, int);
> static void xhints(void);
> static void xclear(int, int, int, int);
> -static void xcopy(int, int, int, int);
> +static void xcopy();
> static void xdrawcursor(void);
> static void xinit(void);
> static void xloadcols(void);
> @@ -1620,32 +1621,8 @@
>
> void
> xresize(int col, int row) {
> - Pixmap newbuf;
> - int oldw, oldh;
> -
> - oldw = xw.bufw;
> - oldh = xw.bufh;
> xw.bufw = MAX(1, col * xw.cw);
> xw.bufh = MAX(1, row * xw.ch);
> - newbuf = XCreatePixmap(xw.dpy, xw.win, xw.bufw, xw.bufh,
> XDefaultDepth(xw.dpy, xw.scr));
> - XCopyArea(xw.dpy, xw.buf, newbuf, dc.gc, 0, 0, xw.bufw, xw.bufh, 0, 0);
> - XFreePixmap(xw.dpy, xw.buf);
> - XSetForeground(xw.dpy, dc.gc, dc.col[DefaultBG]);
> - if(xw.bufw > oldw)
> - XFillRectangle(xw.dpy, newbuf, dc.gc, oldw, 0,
> - xw.bufw-oldw, MIN(xw.bufh, oldh));
> - else if(xw.bufw < oldw && (BORDER > 0 || xw.w > xw.bufw))
> - XClearArea(xw.dpy, xw.win, BORDER+xw.bufw, BORDER,
> - xw.w-xw.bufh-BORDER, BORDER+MIN(xw.bufh, oldh),
> - False);
> - if(xw.bufh > oldh)
> - XFillRectangle(xw.dpy, newbuf, dc.gc, 0, oldh,
> - xw.bufw, xw.bufh-oldh);
> - else if(xw.bufh < oldh && (BORDER > 0 || xw.h > xw.bufh))
> - XClearArea(xw.dpy, xw.win, BORDER, BORDER+xw.bufh,
> - xw.w-2*BORDER, xw.h-xw.bufh-BORDER,
> - False);
> - xw.buf = newbuf;
> }
>
> void
> @@ -1801,7 +1778,7 @@
> CWBackPixel | CWBorderPixel | CWBitGravity | CWEventMask
> | CWColormap,
> &attrs);
> - xw.buf = XCreatePixmap(xw.dpy, xw.win, xw.bufw, xw.bufh,
> XDefaultDepth(xw.dpy, xw.scr));
> + xw.buf = XdbeAllocateBackBufferName(xw.dpy, xw.win, XdbeCopied);
>
>
> /* input methods */
> @@ -1871,10 +1848,10 @@
>
> /* copy buffer pixmap to screen pixmap */
> void
> -xcopy(int x, int y, int cols, int rows) {
> - int src_x = x*xw.cw, src_y = y*xw.ch, src_w = cols*xw.cw, src_h =
> rows*xw.ch;
> - int dst_x = BORDER+src_x, dst_y = BORDER+src_y;
> - XCopyArea(xw.dpy, xw.buf, xw.win, dc.gc, src_x, src_y, src_w, src_h,
> dst_x, dst_y);
> +xcopy() {
> +XdbeSwapInfo swpinfo[1] = {{xw.win, XdbeCopied}};
> +XdbeSwapBuffers(xw.dpy, swpinfo, 1);
> +
>
