the euclid-wm thread

falconindy · 2010-06-24 21:26:15

wmdiem wrote:

"The line system("x-terminal-emulator &"); should be system("xterm &");"
Why's that? At least on Debian, xterm is an actual executable (that many people don't like to use), x-terminal-emulator is a link that the user can point to whatever emulator he likes. The real solution to this will come when I write a config, then the user can point to anything he wants.

Yeah Debian loves to generalize apps and have a symlink point to the user's "soup du-jour". It's purely a Debian thing, though. If you wanted some sort of stop gap solution, you could create a #define for the terminal and let the user just set that define before compiling. Archers are used to that kind of thing .

Also, I would recommend using a fork/exec rather than calling system (which will end up creating 2 extra processes instead of 1). dwm has a clean example of this:

void
spawn(const Arg *arg) {
    if(fork() == 0) {
        if(dpy)
            close(ConnectionNumber(dpy));
        setsid();
        execvp(((char **)arg->v)[0], (char **)arg->v);
        fprintf(stderr, "dwm: execvp %s", ((char **)arg->v)[0]);
        perror(" failed");
        exit(0);
    }
}

BKLive · 2010-06-25 00:08:43

If you're removing start-euclid you should update your Makefile to remove it, as well as remove it from the svn trunk so it's not part of your code-base. (or a required part of your installation).

And the svn-grabbing-unnecessary-files thing for the PKGBUILD.. unless there's a really sleek way that you could imagine doing this without potentially negating code changes and additions in the future, then tell me what you've got. As it's written it's good enough for the pre-release testing phases and constant updates.

BKL

sicpsnake · 2010-06-25 00:48:06

I haven't tried it yet (no time), but I do think it's nice to see another tiling window manager. If you can keep the memory foot print equal to or lower than DWM, I might use it. Also, I am not sure if this is already part of the WM, but if you do have some sort of status bar (or plan on implementing one), I would really like to see it optional--I don't use one and I don't plan on it.

Keep up the good work.

Aedit · 2010-06-25 00:59:24

@BKLive: I just meant the svn template config files ("config", "servers", "README.txt" and "auth/"). I know other Arch svn PKGBUILDS also have "--config-dir ./". No big deal, but presumably they won't be used.

wmdiem · 2010-06-25 04:27:01

@falconindy:
I've changed the system() to a fork-exec. Rather than clunk around with adding in #defines, I wrote a really basic config file parser (I'll build on it as I have time). It currently can handle two options: dmenu and term. Like so:

dmenu = dmenu_run
term = xterm

This file needs to be named $XDG_CONFIG_HOME/euclid-wm.conf or (only if $XDG_CONFIG_HOME is not defined) in $HOME/.config/euclid-wm.conf

saline · 2010-06-25 05:57:55

I still see a lot of flicker when a new window is opened, a window is destroyed or on move/resize. Also, M+<shift>+Q might be a better option for exiting than a one key difference from the three finger salute. M+<shift>+Q is (closer to) familiar to a lot of us, as well.

The config is a plus.

Last edited by saline (2010-06-25 05:58:15)

wmdiem · 2010-06-25 14:47:22

@saline: "I still see a lot of flicker when a new window is opened, a window is destroyed or on move/resize"
I've looked into this, and I'm not sure what can be done about it. Basically, anytime you resize a window, it is the window's job to redraw its contents. Some applications/widget-sets are more graceful about successive resizes than others. (You can see a little discussion of it here: http://fixunix.com/xwindows/556305-resi … b-app.html). Anyway, after you drew my attention to it I did some tests with various applications and the flicker does seem highly dependent on the app. E.g., xterm is quite smooth overall (although there is a tiny bit of flicker in the text, but I don't find it annoying), xfce4 terminal, however, has a terrible flicker and things bounce all over during resize. Interestingly, chrome is silky smooth, and FF isn't bad either (the status bar tends to bounce quite a bit, but there is no flicker).
Anyway, so it looks to me like this is an it's-their-fault sort of bug. There might be some hack that would compensate for this behavior, but I'm not aware of it (other than say, replacing the windows with empty boxes during resize, which I'm not really interested in doing).
If my observations don't line up with what you are seeing, or if anyone knows of a trick to lessen the effect, let me know.

"Also, M+<shift>+Q might be a better option for exiting"
Yes, I like that. I'll change it. Better yet, I might make that the first keybinding that the config file supports.

@sicpsnake:
When/if the bar get's implemented it will be optional.

@BKLive: I'll remove it.

BKLive · 2010-06-26 07:46:25

@Falconindy: I took a look at your comment and when I added the changes to use the Makefile it generates butt loads of Warnings and Errors out saying that /path/to/euclid-wm-svn/pkg/usr/share/man/man1/euclid-wm.1 : No such file or directory. And with just "make install" it errors saying that you don't have permission to remove /usr/bin/euclid-wm.o or some such error. The warnings are for extra ";" outside of a function and mixed declarations galore.

@wmdiem: warnings above.. issues.

So I'm going to fiddle (technical term) with the installation. It looks like in the Makefile ${DESTDIR} is used enough that DESTDIR should be more like /usr but I realize that it's trying to use the Fakeroot /usr, and so the fiddling commences.

also.. @Falconindy: since the Makefile generates the error, the original PKGBUILD still works, so leaving it for now.

also also.. doing the svn checkout, and from the command line.. doing make && sudo make install .. no issues.. installs clean without errors

also also also.. @ALL: I'm pretty sure that in the Makefile it says

@install -m644 euclid.1 ${DESTDIR}/${MANDIR}/man1/euclid-wm.1

but in the PKGBUILD prior to starting to use the Makefile it says

@install -m644 euclid.1 -D ${DESTDIR}/${MANDIR}/man1/euclid-wm.1

and the other @install lines before that one have the -D modifier on there, which means create all leading components of $DEST except the last (/man1...) then copying the SOURCE to DEST (read that from the man page).. so throw the -D on the man page line and it should be 100%

Last edited by BKLive (2010-06-26 08:28:33)

DIDI2002 · 2010-06-26 08:50:36

euclid

sicpsnake · 2010-06-26 08:56:17

wmdiem wrote:

...
@sicpsnake:
When/if the bar get's implemented it will be optional.
....

Nice. How's the memory foot print on Euclid currently?

portix · 2010-06-26 11:14:38

@BKLive
You won't get mixed declarations warnings if you add -std=c99 to CFLAGS
@wmdiem
I get a segfault, pressing Mod1 + Shift. You also forget to include <unistd.h> (which declares fork and execvp) and maybe you should use memset instead of bzero (bzero is deprecated for years).

Anonymo · 2010-06-26 13:58:38

Shouldn't this be in community contributions?

wmdiem · 2010-06-26 14:48:36

@BKLive:
Yeah. Going through the list of warnings is on the top of my queue.
BTW, I've fixed a number of fairly significant things since r49 (a number of potential segfaults, tons of config options, manpage updates, added the -D flag you mentioned above, etc). If it's possible could you bump pkgver?

@sicpsnake:

~$ ps v -C euclid-wm
PID     TTY     STAT    TIME    MAJFL   TRS     DRS     RSS     %MEM    COMMAND
10541   ?       Ss      0:00    0       26      3157    1176    0.1     euclid-wm

@portix:
Can you give a bit more information? I don't see how that combination (alone) could do something that might segfault it. Which is to say, euclide _shouldn't_ even be getting an event notify for a bare mod1 + shift.
Also, several potential segfaults have been caught in the more recent revisions. I discovered a couple by being fatfingered, and accidentally running functions that it didn't make any sense to run.
I've added the unistd.h explicitly. thanks.
I'll look at changing bzero.

In general: I don't know what the conventions are, but to those more familiar with the Arch forums, should this thread be moved to another venue (either within the forum, or off the forum altogether)?
I'm just concerned about constantly bumping a thread that is of limited interest to the community at large.
(On a more or less related note, I've added a mailing list.)

BKLive · 2010-06-26 18:57:06

@wmdiem: updated the AUR now that the makefile is updated. The build still generates a bunch of warnings about ";" being outside the function and one about a 7 being passed to XChangeProperty which is apparently a 'const unsigned char *' and is getting passed a number instead! OH! And I was busy earlier today so I hadn't updated yet. I anticipate updates every day as long as you have them, but 7 or 8 times isn't an every-day type of deal

@All: We should continue this topic in the euclid-wm mailing list, or create an IRC, or start a new thread like "the euclid-wm thread", or just use the google code issues tab to generate new issues for the project. Great for awareness, poor for issue generator for a project.

Last edited by BKLive (2010-06-26 18:58:15)

portix · 2010-06-27 10:23:49

@wmdiem: I cannot give you more information. euclid-wm simply segfaults if i press alt-shift. I tried to debug it, but strangely i didn't get a segfault in a Xephyr-session starting euclid-wm from gdb but if i open a window, it doesn't get keyboardfocus (if i don't start it from gdb it also segfaults).
You can simply replace bzero(char, length) with memset(char, '\0', length).

wmdiem · 2010-06-27 17:58:05

@ portix: First I'd be much more comfortable continuing this elsewhere; An issue report would be best, but the mailing list would work too. This also would have the benefit of keeping any information that came out of this easier to find.

2nd, can you tell me what rev(s) you are seeing this in? A combination of now-corrected bugs relating to how keybindings are handled *might* have been able to lead to what you were describing. So if you don't mind, give r72 a try and see if you still see it.

Thanks.

wmdiem · 2010-07-23 16:44:43

I just wanted to announce, for anyone interested, that a stable version is now available:

http://code.google.com/p/euclid-wm/

(As to my previous discomfort with continuing this thread, I have since noticed that there are a number of general discussions that run on for pages, and a moderator has explicitly said to continue discussion of euclid-wm here.)

BKLive · 2011-12-14 08:26:41

The 0.4.0 rc1 is available now from the Google code site. Will update pkgbuilds when I have more than my phone available. Just reviving because of development revival.

Edit: and can we get this topic moved to community contributions? Possibly the name changed to actually mention euclid-wm? Suggestions for everyone!

Last edited by BKLive (2011-12-14 08:30:53)

fsckd · 2011-12-14 16:49:52

BKLive wrote:

Edit: and can we get this topic moved to community contributions? Possibly the name changed to actually mention euclid-wm? Suggestions for everyone!

I see no reason not to.

mod action: Moving from Applications & Desktop Environments to Community Contributions.

Diem should be the one to change the title. Also it would not be bad to link to the new home.

wmdiem · 2011-12-14 23:31:02

Fsckd: "Diem should be the one to change the title."

I'm a bonehead, can't figure out how to do this: Can anyone give me any hints?

Edit: scratch that.

Last edited by wmdiem (2011-12-15 00:42:51)

Arch Linux

#26 2010-06-24 21:26:15

Re: the euclid-wm thread

#27 2010-06-25 00:08:43

Re: the euclid-wm thread

#28 2010-06-25 00:48:06

Re: the euclid-wm thread

#29 2010-06-25 00:59:24

Re: the euclid-wm thread

#30 2010-06-25 04:27:01

Re: the euclid-wm thread

#31 2010-06-25 05:57:55

Re: the euclid-wm thread

#32 2010-06-25 14:47:22

Re: the euclid-wm thread

#33 2010-06-26 07:46:25

Re: the euclid-wm thread

#34 2010-06-26 08:50:36

Re: the euclid-wm thread

#35 2010-06-26 08:56:17

Re: the euclid-wm thread

#36 2010-06-26 11:14:38

Re: the euclid-wm thread

#37 2010-06-26 13:58:38

Re: the euclid-wm thread

#38 2010-06-26 14:48:36

Re: the euclid-wm thread

#39 2010-06-26 18:57:06

Re: the euclid-wm thread

#40 2010-06-27 10:23:49

Re: the euclid-wm thread

#41 2010-06-27 17:58:05

Re: the euclid-wm thread

#42 2010-07-23 16:44:43

Re: the euclid-wm thread

#43 2011-12-14 08:26:41

Re: the euclid-wm thread

#44 2011-12-14 16:49:52

Re: the euclid-wm thread

#45 2011-12-14 23:31:02

Re: the euclid-wm thread

Board footer