|
|
|
Home » U++ Library support » Look and Chameleon Technology » Compiz fix
| Compiz fix [message #20820] |
Fri, 10 April 2009 17:32  |
kodos
Messages: 111
Registered: March 2008
|
Experienced Member |
|
|
Hi,
I don't know how the standard settings are in other Linux distributions but at least in Ubuntu the standard settings for compiz is to use the Animation plugin, an they have different animations for top level windows and "other" windows (like popupmenus and other things). So for example if you open the file menu in TheIDE it looks weird. Compiz decides what animation it should use according to its type.
I have hacked a quick fix which works for me, but it isn't really nice, because I just set every window which is created with redirect==true to be a popup menu. I'm afraid I don't know how I could detect in the Create method which sort of window actually is created and set type correctly.
EDIT: The patch is for the CtrlCore/X11Wnd.cpp file 
EDIT2: And a link which shows every type a WM should understand: http://standards.freedesktop.org/wm-spec/1.4/ar01s05.html
A correct fix would probably use those types.
-
Attachment: patch
(Size: 0.54KB, Downloaded 451 times)
[Updated on: Fri, 10 April 2009 17:35] Report message to a moderator |
|
|
|
| Re: Compiz fix [message #20855 is a reply to message #20820] |
Tue, 14 April 2009 19:57  |
 |
mirek
Messages: 14162
Registered: November 2005
|
Ultimate Member |
|
|
| kodos wrote on Fri, 10 April 2009 11:32 |
Hi,
I don't know how the standard settings are in other Linux distributions but at least in Ubuntu the standard settings for compiz is to use the Animation plugin, an they have different animations for top level windows and "other" windows (like popupmenus and other things). So for example if you open the file menu in TheIDE it looks weird. Compiz decides what animation it should use according to its type.
I have hacked a quick fix which works for me, but it isn't really nice, because I just set every window which is created with redirect==true to be a popup menu. I'm afraid I don't know how I could detect in the Create method which sort of window actually is created and set type correctly.
EDIT: The patch is for the CtrlCore/X11Wnd.cpp file
EDIT2: And a link which shows every type a WM should understand: http://standards.freedesktop.org/wm-spec/1.4/ar01s05.html
A correct fix would probably use those types.
|
Thanks, applied.
I guess that for really good fix, we will have to add "type hint" to Ctrl (MENU, TOOLTIP, DROPLIST etc...) and call it appropriately... (with some reasonable default).
Mirek
|
|
|
|
|
|
|
|
|
|
| Re: Compiz fix [message #21004 is a reply to message #20999] |
Sat, 25 April 2009 10:47 |
|
mirek
Messages: 14162
Registered: November 2005
|
Ultimate Member |
|
|
| phirox wrote on Fri, 24 April 2009 14:07 |
| luzr wrote on Fri, 24 April 2009 10:42 |
R807 there was accepted related submitted patch...
The file is CtrlCore/X11Proc.cpp.
(Use svn history in theide).
Mirek
|
Thanks for pointing me in the right direction. My problem was fixed by removing the newly added code. Basically the following code has been put around the ev1 part:
if(ev1->type == KeyPress)
*ev2 = *ev1;
else {
...
}
My guess is that it is an attempt at speeding up things but somehow the IsWaitingEvent() call is too important to skip.
|
Well, in fact, now I remember, it was not accepted patch, but my fix.
I believe the problem to fix is that some X11 systems, in case of autorepeat, put series of "KeyPress/KeyRelease" pairs, while others (and especially those with compiz enabled) only series of KeyPress.
I would like to find a reason for doubling characters before reversing the change. Maybe you could activate LLOGs (at the beginning of file) to see what is going on?
Mirek
|
|
|
|
| Re: Compiz fix [message #21005 is a reply to message #20820] |
Sat, 25 April 2009 11:13 |
|
mirek
Messages: 14162
Registered: November 2005
|
Ultimate Member |
|
|
OK, thinking about the issue, maybe this patch might help:
case KeyPress:
pressed = true;
LLOG("event type:" << event->type << " state:" << event->xkey.state <<
"keycode:" << event->xkey.keycode);
for(;;) {
XEvent ev1[1], ev2[1];
bool hasev2 = false;
if(!IsWaitingEvent()) break;
do
XNextEvent(Xdisplay, ev1);
while(ev1->type == NoExpose && IsWaitingEvent());
LLOG("ev1 type:" << ev1->type << " state:" << ev1->xkey.state <<
"keycode:" << ev1->xkey.keycode);
if(ev1->type == KeyPress)
*ev2 = *ev1;
else {
if(ev1->type != KeyRelease ||
ev1->xkey.state != event->xkey.state ||
ev1->xkey.keycode != event->xkey.keycode ||
!IsWaitingEvent()) {
XPutBackEvent(Xdisplay, ev1);
break;
}
do
XNextEvent(Xdisplay, ev2);
while(ev2->type == NoExpose && IsWaitingEvent());
LLOG("ev2 type:" << ev2->type << " state:" << ev2->xkey.state <<
"keycode:" << ev2->xkey.keycode);
hasev2 = true;
}
if(ev2->type != KeyPress ||
ev2->xkey.state != event->xkey.state ||
ev2->xkey.keycode != event->xkey.keycode) {
if(hasev2)
XPutBackEvent(Xdisplay, ev2);
XPutBackEvent(Xdisplay, ev1);
break;
}
else {
XFilterEvent(ev1, None);
if(hasev2)
XFilterEvent(ev2, None);
}
count++;
}
case KeyRelease: {
Please try. (It is on svn too).
Mirek
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Dec 13 22:07:49 CET 2024
Total time taken to generate the page: 0.03079 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
