catwm, Cute and Tiny Window Manager

pyknite · 2010-07-07 07:33:57

sicpsnake wrote:

I think I found a bug.
Sometimes, if open a window on a desktop that has no windows open currently, it will act as if there is a slave window beside it. Here's a screenshot.
http://omploader.org/tNHV3cQ

I noticed this bug too... I'll try to correct it when I got the time (I'am making my Bachelor "thesis" and I got a lot of work to do)

knopwob · 2010-07-07 17:58:23

hey,

i just tried this one for a few hours and i'm really liking it. So it's likely this one will become my main window manager. Just wanted to say: good work and thank you for this piece of software :-)

knopwob · 2010-07-07 21:31:19

hey,

i just found a bug in catwm. Whenever i close the download window, which firefox spawns on downloading something, firefox closes aswell. Steps to repoduce:
-> open firefox
-> download something
-> close the download window with alt+x

Just say something if you need more info.

milomouse · 2010-07-07 21:44:17

@knopwob: alt+x (in the default config) is the kill command. try using the Esc (escape) key for the downloads window

pyknite · 2010-07-07 21:46:06

knopwob wrote:

hey,
i just found a bug in catwm. Whenever i close the download window, which firefox spawns on downloading something, firefox closes aswell. Steps to repoduce:
-> open firefox
-> download something
-> close the download window with alt+x
Just say something if you need more info.

Yep, I know this bug... I need to find a way to manage these "unmanaged" window (like messagebox,...)
You can also reproduce this bug when you open the source of a page

And thanks for the report and your compliment

cesura · 2010-07-07 21:47:34

knopwob wrote:

hey,
i just found a bug in catwm. Whenever i close the download window, which firefox spawns on downloading something, firefox closes aswell. Steps to repoduce:
-> open firefox
-> download something
-> close the download window with alt+x
Just say something if you need more info.

+1 I can confirm this. I believe it is because X sees that both windows have the same ID (or something ) and closes all instances of that ID.

EDIT: Or it destroys the parent when you destroy a child

milomouse wrote:

@knopwob: alt+x (in the default config) is the kill command. try using the Esc (escape) key for the downloads window

This seems to solve it The "clunkyness" of firefox made me switch to uzbl.

Last edited by cesura (2010-07-07 21:53:57)

knopwob · 2010-07-07 22:10:00

i don't know if it helps, but i tested it with some other programs, like pidgin and gvim. Everything works fine there. Openfiledialogs, new windows created by those programs etc.

But just at this very moment some other problem occured. Someone wrote me at pidgin (i didn't have a dialog window open). Pidgin was not at the desktop i am currently on. So pidgin should have opened the dialog-window, but i can't find it. And when i clicked on another contact on my contact list, so that the dialog-window should get the focus, pidgin closed. (ps -aux | grep pidgin returns nothing). Well this got a bit messy so i'll try it to explain in another way:

desktop 1: pidgin

i was at desktop 2 and someone wrote me -> pidgins dialog window opened but i can't find it.
I think it wasn't added correctly to the linked list of the windows.
And when i chanded the focus to the dialog window via clicking on another contact in my contact list, pidgin terminated.

i don't know if this is another form of the same bug meantioned above or something else.

again, if i can help, just say something ;-)

knopwob · 2010-07-07 22:45:40

hey,

it's me again. Well after testing some more i get the feeling, the way you close the windows (via alt+x) isn't the way to go.

everyone of the following outputs are collected by opening the programs in a terminal, closing their window via alt+x and look into the terminal.

firefox:

 (firefox:23391): GLib-GObject-WARNING **: invalid unclassed pointer in cast to `GtkWidget'
[1]    23391 segmentation fault (core dumped)  firefox

geany:

geany
The program 'geany' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 1838 error_code 9 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

kdevelop:

X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 40 (X_TranslateCoords)
  Resource id:  0x1600058
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 40 (X_TranslateCoords)
  Resource id:  0x1600058
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 40 (X_TranslateCoords)
  Resource id:  0x1600058
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 40 (X_TranslateCoords)
  Resource id:  0x1600058
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 40 (X_TranslateCoords)
  Resource id:  0x1600058
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 40 (X_TranslateCoords)
  Resource id:  0x1600058
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 40 (X_TranslateCoords)
  Resource id:  0x1600058
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 40 (X_TranslateCoords)
  Resource id:  0x1600058
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 40 (X_TranslateCoords)
  Resource id:  0x1600058

noteworthy at this one: the kdevelop window closed but the
process /usr/bin/kdevelop.bin
keeps running.

and just to verify that the problem isn't something else on my computer, i did these steps the same way in musca and all the programs terminated just fine. I'll try to have a look into muscas sources to see how they are closing the windows and edit this post, if i figure something out.

pyknite · 2010-07-07 23:08:23

@knopwob: thx... I already see that there where some errors sometimes with closing function. I really need to rewrite a big part of the code to get away from these bugs... I you found something, just tell me

I don't have many time during the week because I'm working on my bachelor "thesis", but I'll take a look at all your comments during the weekend (after partiying )

Last edited by pyknite (2010-07-07 23:08:58)

knopwob · 2010-07-07 23:44:53

here's a patch. This sends a proper signal to the window. Please consider that these are my first baby steps with c so don't just apply this patch blindly but check if everything looks correct ;-) But it seems to work here.
This could also need some kind of "force kill", if the window ignores the signal. Maybe I try to write something for that tomorrow (it's late at night here).

--- src/catwm/catwm.c    2010-07-08 01:38:02.544774356 +0200
+++ ../src/catwm/catwm.c    2010-07-08 01:36:49.330623325 +0200
@@ -289,8 +289,17 @@ void keypress(XEvent *e) {
 }
 
 void kill_client() {
-    if(current != NULL)
-        XDestroyWindow(dis, current->win);
+    if(current != NULL) {
+        //send delete signal to window
+        XEvent ke;
+        ke.type = ClientMessage;
+        ke.xclient.window = current->win;
+        ke.xclient.message_type = XInternAtom(dis, "WM_PROTOCOLS", True);
+        ke.xclient.format = 32;
+        ke.xclient.data.l[0] = XInternAtom(dis, "WM_DELETE_WINDOW", True);
+        ke.xclient.data.l[1] = CurrentTime;
+        XSendEvent(dis, current->win, False, NoEventMask, &ke);
+    }
 }

EDIT:
good look with your thesis btw. Hopefully it's my time to write one in a year ;-)

Last edited by knopwob (2010-07-07 23:46:09)

cesura · 2010-07-07 23:45:21

Not really a bug, just a question: If there are 11 desktops, shouldn't catwm default to desktop 0 instead of 1?

If there are supposed to be only 10, then:

const Arg arg = {.i = 1};

should be:

const Arg arg = {.i = 0};

and

static desktop desktops[10];

should be:

static desktop desktops[9];

Just curious Sorry if that sounds confusing.

Last edited by cesura (2010-07-07 23:46:20)

cesura · 2010-07-07 23:51:11

knopwob wrote:

here's a patch. This sends a proper signal to the window. Please consider that these are my first baby steps with c so don't just apply this patch blindly but check if everything looks correct ;-) But it seems to work here.
This could also need some kind of "force kill", if the window ignores the signal. Maybe I try to write something for that tomorrow (it's late at night here).
--- src/catwm/catwm.c    2010-07-08 01:38:02.544774356 +0200
+++ ../src/catwm/catwm.c    2010-07-08 01:36:49.330623325 +0200
@@ -289,8 +289,17 @@ void keypress(XEvent *e) {
 }
 
 void kill_client() {
-    if(current != NULL)
-        XDestroyWindow(dis, current->win);
+    if(current != NULL) {
+        //send delete signal to window
+        XEvent ke;
+        ke.type = ClientMessage;
+        ke.xclient.window = current->win;
+        ke.xclient.message_type = XInternAtom(dis, "WM_PROTOCOLS", True);
+        ke.xclient.format = 32;
+        ke.xclient.data.l[0] = XInternAtom(dis, "WM_DELETE_WINDOW", True);
+        ke.xclient.data.l[1] = CurrentTime;
+        XSendEvent(dis, current->win, False, NoEventMask, &ke);
+    }
 }
EDIT:
good look with your thesis btw. Hopefully it's my time to write one in a year ;-)

It works!
I'll see what I can do about the force kill

EDIT:
Theoretically, couldn't you do:

void kill_client() {
    while(current != NULL) {
        //send delete signal to window
        XEvent ke;
        ke.type = ClientMessage;
        ke.xclient.window = current->win;
        ke.xclient.message_type = XInternAtom(dis, "WM_PROTOCOLS", True);
        ke.xclient.format = 32;
        ke.xclient.data.l[0] = XInternAtom(dis, "WM_DELETE_WINDOW", True);
        ke.xclient.data.l[1] = CurrentTime;
        XSendEvent(dis, current->win, False, NoEventMask, &ke);
    }
}

This way, a signal would be repeatedly sent until the window accepts. The problem with this is that it could hang the window manager. [THIS METHOD DOESN'T WORK]

Or:

void kill_client() {
    if(current != NULL) {
        //send delete signal to window
        XEvent ke;
        ke.type = ClientMessage;
        ke.xclient.window = current->win;
        ke.xclient.message_type = XInternAtom(dis, "WM_PROTOCOLS", True);
        ke.xclient.format = 32;
        ke.xclient.data.l[0] = XInternAtom(dis, "WM_DELETE_WINDOW", True);
        ke.xclient.data.l[1] = CurrentTime;
        if(XSendEvent(dis, current->win, False, NoEventMask, &ke) && current != NULL) {
            XKillClient(dis,current->win);        
        }
    }
}

Two problems with that one. First, the window could still refuse the signal, and then, well, you're screwed. Secondly, XKIllClient() would kill the parent window, which in turn kills all child windows. [THIS METHOD DOESN'T WORK]

EDIT EDIT: The problem with the second one is that there isn't enough time for current to be set to NULL, so it kills the client. I'll keep looking *sigh*

Last edited by cesura (2010-07-08 00:56:51)

knopwob · 2010-07-08 01:01:22

if i understand this correctly, your second method would kill the the window directly after the signal is send. But this would cause race conditions ff the window can't close itself fast enough, because it needs to save some data or something like that. And i guess it would also kill directly these windows that ask "Are you sure you want to quit?" or "Save before quit?" before closing.

i would just map this to a new key combination like shift+alt+x.

EDIT:

you were faster than me :-P
the alt+x and shift+alt+x would be the same idea as kill $PID and kill -9 $PID

Last edited by knopwob (2010-07-08 01:04:28)

cesura · 2010-07-08 01:08:09

knopwob wrote:

if i understand this correctly, your second method would kill the the window directly after the signal is send. But this would cause race conditions ff the window can't close itself fast enough, because it needs to save some data or something like that. And i guess it would also kill directly these windows that ask "Are you sure you want to quit?" or "Save before quit?" before closing.
i would just map this to a new key combination like shift+alt+x.
EDIT:
you were faster than me :-P
the alt+x and shift+alt+x would be the same idea as kill $PID and kill -9 $PID

Precisely Another problem (with firefox at least) is that using number 2 freezes the WM, making me have to Ctrl-Alt-F1 out of it. I'll see if it has this effect on other programs.

cesura · 2010-07-08 01:21:03

Ok, I created a separate function called force_kill_client() and mapped it to MOD|ShiftMask,XK_x. There appear to be problems with only firefox.

Last edited by cesura (2010-07-08 07:26:27)

knopwob · 2010-07-08 01:31:51

can you post a patch for that?

cesura · 2010-07-08 01:37:00

knopwob wrote:

can you post a patch for that?

Creating patch...will post soon

catwm.c.patch:

*** catwm.c    2010-07-07 20:44:44.114741638 -0500
--- catwm2.c    2010-07-07 20:46:21.661203398 -0500
***************
*** 79,84 ****
--- 79,85 ----
  static void increase();
  static void keypress(XEvent *e);
  static void kill_client();
+ static void force_kill_client();
  static void maprequest(XEvent *e);
  static void next_desktop();
  static void next_win();
***************
*** 289,296 ****
  }
  
  void kill_client() {
!     if(current != NULL)
!         XDestroyWindow(dis, current->win);
  }
  
  void maprequest(XEvent *e) {
--- 290,326 ----
  }
  
  void kill_client() {
!     if(current != NULL) {
!         //send delete signal to window
!         
!     XEvent ke;
!         ke.type = ClientMessage;
!         ke.xclient.window = current->win;
!         ke.xclient.message_type = XInternAtom(dis, "WM_PROTOCOLS", True);
!         ke.xclient.format = 32;
!         ke.xclient.data.l[0] = XInternAtom(dis, "WM_DELETE_WINDOW", True);
!         ke.xclient.data.l[1] = CurrentTime;
!         XSendEvent(dis, current->win, False, NoEventMask, &ke);
! 
!      }
! }
! 
! void force_kill_client() {
!     if(current != NULL) {
!         //send delete signal to window
!         
!     XEvent ke;
!         ke.type = ClientMessage;
!         ke.xclient.window = current->win;
!         ke.xclient.message_type = XInternAtom(dis, "WM_PROTOCOLS", True);
!         ke.xclient.format = 32;
!         ke.xclient.data.l[0] = XInternAtom(dis, "WM_DELETE_WINDOW", True);
!         ke.xclient.data.l[1] = CurrentTime;
!         if(XSendEvent(dis, current->win, False, NoEventMask, &ke) && current != NULL) {
!         XKillClient(dis,current->win);
!     }
! 
!      }
  }
  
  void maprequest(XEvent *e) {
***************
*** 445,451 ****
      // List of client
      head = NULL;
      current = NULL;
! 
      // Master size
      master_size = sw*MASTER_SIZE;
  
--- 475,481 ----
      // List of client
      head = NULL;
      current = NULL;
! ki
      // Master size
      master_size = sw*MASTER_SIZE;

config.h.patch:

*** config.h    2010-07-07 20:41:24.161349217 -0500
--- config2.h    2010-07-07 20:42:21.097894779 -0500
***************
*** 54,59 ****
--- 54,60 ----
      {  MOD,             XK_h,                       decrease,       {NULL}},
      {  MOD,             XK_l,                       increase,       {NULL}},
      {  MOD,             XK_x,                       kill_client,    {NULL}},
+     {  MOD|ShiftMask, XK_x,                       force_kill_client,    {NULL}},
      {  MOD,             XK_j,                       next_win,       {NULL}},
      {  MOD,             XK_Tab,                     next_win,       {NULL}},
      {  MOD,             XK_k,                       prev_win,       {NULL}},

Those should work Tell me if they don't.

Last edited by cesura (2010-07-08 01:50:21)

cesura · 2010-07-08 01:59:43

Ok, I have come to this conclusion:
The WM freezes when force_kill_client() is executed only when a client has a child window. Otherwise it's fine.

knopwob · 2010-07-08 02:10:06

1. when firefox has a child window i can't kill firefox with kill_client. I have to kill_client the childwindow first.
2. firefox with childwindow and force_kill_client kills my whole xserver

And i don't think it is necessary to send the signal again in the force_kill_client function, since that one should
only be used, if the normal kill_client doesn't work. So we can assume, the program wont handle the signal anyway.

knopwob · 2010-07-08 02:14:41

i REALLY have to go to bed now. The sun starts to rise and my alarm clock will go off in about 3 hours
i will look further into it after work.

cesura · 2010-07-08 02:16:12

knopwob wrote:

And i don't think it is necessary to send the signal again in the force_kill_client function, since that one should
only be used, if the normal kill_client doesn't work. So we can assume, the program wont handle the signal anyway.

The problem that arises is that I haven't actually had a need to use force_kill_client(), because all of the clients I have ever closed have accepted the first signal. Therefore, it is of zero use to me. Plus the fact, as you and I both confirmed, you have to restart X after using it (this could possible be fixed).

knopwob wrote:

i REALLY have to go to bed now. The sun starts to rise and my alarm clock will go off in about 3 hours hmm
i will look further into it after work.

Haha okay. Good luck

Last edited by cesura (2010-07-08 02:17:23)

knopwob · 2010-07-08 02:28:36

well, on another point of view, you could say, we don't need the force_kill_client() anyway. Since, when a programm doesn't handle the signal, we could assume it has crashed. And the user could handle a crashed programm by

killall -9 program

in a shell.

cesura · 2010-07-08 02:34:59

knopwob wrote:

well, on another point of view, you could say, we don't need the force_kill_client() anyway. Since, when a programm doesn't handle the signal, we could assume it has crashed. And the user could handle a crashed programm by
killall -9 program
in a shell.

From that stand point, we could just get rid of kill_client() and have the user manually close each program with killall

In all seriousness, I understand what you are saying. Very rarely will a window not accept the kill signal, so force_kill_signal() is fairly useless.

cesura · 2010-07-08 05:49:05

Ok, spent some time writing this, but the wiki entry is done! Tell me if anything should be added.

http://wiki.archlinux.org/index.php/Catwm

pyknite · 2010-07-08 07:46:05

Eh guys... You're awesome \o/

Arch Linux

#51 2010-07-07 07:33:57

Re: catwm, Cute and Tiny Window Manager

#52 2010-07-07 17:58:23

Re: catwm, Cute and Tiny Window Manager

#53 2010-07-07 21:31:19

Re: catwm, Cute and Tiny Window Manager

#54 2010-07-07 21:44:17

Re: catwm, Cute and Tiny Window Manager

#55 2010-07-07 21:46:06

Re: catwm, Cute and Tiny Window Manager

#56 2010-07-07 21:47:34

Re: catwm, Cute and Tiny Window Manager

#57 2010-07-07 22:10:00

Re: catwm, Cute and Tiny Window Manager

#58 2010-07-07 22:45:40

Re: catwm, Cute and Tiny Window Manager

#59 2010-07-07 23:08:23

Re: catwm, Cute and Tiny Window Manager

#60 2010-07-07 23:44:53

Re: catwm, Cute and Tiny Window Manager

#61 2010-07-07 23:45:21

Re: catwm, Cute and Tiny Window Manager

#62 2010-07-07 23:51:11

Re: catwm, Cute and Tiny Window Manager

#63 2010-07-08 01:01:22

Re: catwm, Cute and Tiny Window Manager

#64 2010-07-08 01:08:09

Re: catwm, Cute and Tiny Window Manager

#65 2010-07-08 01:21:03

Re: catwm, Cute and Tiny Window Manager

#66 2010-07-08 01:31:51

Re: catwm, Cute and Tiny Window Manager

#67 2010-07-08 01:37:00

Re: catwm, Cute and Tiny Window Manager

#68 2010-07-08 01:59:43

Re: catwm, Cute and Tiny Window Manager

#69 2010-07-08 02:10:06

Re: catwm, Cute and Tiny Window Manager

#70 2010-07-08 02:14:41

Re: catwm, Cute and Tiny Window Manager

#71 2010-07-08 02:16:12

Re: catwm, Cute and Tiny Window Manager

#72 2010-07-08 02:28:36

Re: catwm, Cute and Tiny Window Manager

#73 2010-07-08 02:34:59

Re: catwm, Cute and Tiny Window Manager

#74 2010-07-08 05:49:05

Re: catwm, Cute and Tiny Window Manager

#75 2010-07-08 07:46:05

Re: catwm, Cute and Tiny Window Manager

Board footer