[Bug 286617] Re: KeepassX quits when autotype with @ in user or password
Not directly related to this one, I would say. This has to do with dead keys. On some -- e.g. German -- keyboard layouts, ^ is a dead key as is ', ` and ~. All of them make autotype stop, when occuring in a password, on my system. -- KeepassX quits when autotype with @ in user or password https://bugs.launchpad.net/bugs/286617 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 286617] Re: KeepassX quits when autotype with @ in user or password
I can confirm this bug from a clean 8.10 install (without any additional repositories). I also had a look into the source code. The assertion occurs in the function HelperX11::getModifiers. In this function, there is a for loop with a range of 0 to 3 (i=0; i < 4), which iterates over the entries of the KeySym list returned by XGetKeyboardMapping. However, this list may be longer than 4 elements, which is the case for "@", obviously. Changing the loops range to 0-SymsPerKey (which is a value returned also by XGetKeyboardMapping, indicating how many elements the list has), removes the assertion -- the autotype completes without crashing the application. However: Now a "q" is typed instead of a "@" which is caused by the function HelperX11::pressModifiers. For me, getModifiers returns a 4 (with the above change) for "@" but there is no case for 4 in the switch statement of pressModifiers, so no modifier key press is simulated. I am not an X11 guru but maybe there is one here and he can do something with this information. -- KeepassX quits when autotype with @ in user or password https://bugs.launchpad.net/bugs/286617 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 286617] Re: KeepassX quits when autotype with @ in user or password
Sorry for double posting but I should add two other things, that I found out:
First the bug seems to occur with other characters that involve pressing AltGr.
I tested this with "|", which -- on a German keyboard -- is typed as AltGr+<.
As this worked in hardy and the corresponding code did not change in keepassx
(the original reporter of this bug and me, too, used 0.3.3 already in hardy),
some other change has to cause this and I think I found it:
Running this little program:
"#include
#include
#include
int main (int argc, char *argv[])
{
Display *d = XOpenDisplay (NULL);
int n, i;
KeySym *syms = XGetKeyboardMapping (d, 24, 1, &n); // KeyCode 24 is "@".
for (i = 0; i < n; ++i)
{
printf("%x\n", syms[i]);
}
XFree (syms);
XCloseDisplay (d);
}"
on a hardy machine yields:
"71
51
40
7d9
40
7d9
0"
With 0x40 being the KeySym of "@" HelperX11::getModifiers returns 2, which is
interpreted as AltGr by HelperX11::pressModifiers.
On my new intrepid install, this gives me:
"71
51
71
51
40
7d9
40"
Which makes getModifiers return 4 (or crash with an assertion, if you didn't
apply the change I mentioned in the last post), which can not be interpreted by
pressModifiers.
As said, I am not an X11 guru and thus cannot judge, whether this is a
bug in intrepids X11 or a design flaw in keepassx (or maybe in a
completely different place like a keyboard map...).
--
KeepassX quits when autotype with @ in user or password
https://bugs.launchpad.net/bugs/286617
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 131013] Re: starting compiz in KDE displaces adept from tray
I just confirmed that the patch is not in hardies kdebase source package (kdebase_3.5.9-0ubuntu7.3), yet. This is also the case for the 3.5.9 tag of KDEs SVN. This one is till at revision 774532 and thus does not include the fix (783764). I also experienced the bug again in 8.04, but not as often as in previous releases; the "Deksotp Effects"-Settings stuff somehow seems to have found a way of starting Compiz and KDE in an order that "hides" this bug in most cases. I also noticed it in KDE4 once or twice but _without_ Compiz (but with KDE(4)s compositing manager). This may or may not be another bug, I haven't looked at the code here, yet, what I did check however is, whether my patch was also applied to KDE4s KWin: It isn't. If I can help to bring this patch into Ubuntu, please notify me, I just don't know how. Zaar Hai: Thank you very much. Šarūnas Rimša: If you still need it: dcop is a command line utility to "speak DCOP", the protocol KDE applications use (until version 4) to communicate with one another. "kded kded" selects the application I want to talk to. I'm not that much into DCOP and don't quite know what exactly these two parameters mean ^^". loadModule is the function of the so selected "module" and kdetrayproxy is the argument to this function. This command thus basically means something like "Hey kded, load the module 'kdetrayproxy' for me, please!" I hope this answers your question. Ah yes and sorry for the (very oO) late reply. -- starting compiz in KDE displaces adept from tray https://bugs.launchpad.net/bugs/131013 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 262961] [NEW] python-fuse's xmp.py bad at handling larger files
Public bug reported: Binary package hint: python-fuse The xmp.py example filesystem included in the python-fuse - and thus probably many, if not all, filesystems derived from that one and directly accessing an underlying filesystem tree - has some issues with reading somewhat large files. By large I mean e.g. 4GB, where the error (described below) is nearly guaranteed to occure. Large can but also mean 3MB, where the bug only shows up from time to time. Copying such a file into a mountpoint mounted by xmp.py and then comparing the original with that copy gives differences. I.e. "diff original mount/copy" would give a differing line and similarly "cmp original mount/copy" a differing byte. Actually not only one line/byte, but from that first line/byte onwards, the whole copy seems to be "shifted". The size of the two files although is equal. As said, depending on the size of the file, this bug appears more or less often. The difference also starts on seemingly random positions. These two circumstances lead me to think of a race condition and here is, what I found out: python-fuse (or FUSE in general?) has a debug mode, so I mounted an xmp FS with the "-d" option, that activates it. python /usr/share/doc/python-fuse/examples/xmp.py -d -o root=/home/user/test /home/user/mount Now we have a fuse daemon running in the foreground, kindly telling us, what he is doing on the FS mounted at ~/mount, which is just a "mirror" of ~/test. No assume that ~/lipsum.txt is a file of any kind but with a size that is appropriate to meet the above description, so that it triggers the bug: cp ~/lipsum.txt ~/mount Now just compare until cmp reports a differing byte: cmp ~/lipsum.txt ~/mount/lipsum.txt (NOTE for ~3MB files, this sometimes took me 20 tries, so be patient or choose an even bigger file) Let's assume we got this: lipsum.txt mount/lipsum.txt differieren: Byte 376833, Zeile 64658. Now the good thing about cmp is, that - per default - stops reading after finding the first difference. We should now be able to see some odd behavior in the last lines of debug output of the xmp FS. So here they are: --- READ[136293708] 131072 bytes from 114688 READ[136293708] 131072 bytes unique: 1594, error: 0 (Success), outsize: 131088 unique: 1595, opcode: READ (15), nodeid: 2, insize: 80 READ[136293708] 131072 bytes from 245760 READ[136293708] 131072 bytes unique: 1595, error: 0 (Success), outsize: 131088 unique: 1596, opcode: READ (15), nodeid: 2, insize: 80 unique: 1597, opcode: READ (15), nodeid: 2, insize: 80 !! READ[136293708] 131072 bytes from 376832 READ[136293708] 131072 bytes from 507904 !! READ[136293708] 131072 bytes unique: 1597, error: 0 (Success), outsize: 131088 READ[136293708] 131072 bytes unique: 1596, error: 0 (Success), outsize: 131088 unique: 1598, opcode: FLUSH (25), nodeid: 2, insize: 64 FLUSH[136293708] unique: 1598, error: 0 (Success), outsize: 16 unique: 1599, opcode: RELEASE (18), nodeid: 2, insize: 64 RELEASE[136293708] flags: 0x8000 unique: 1599, error: 0 (Success), outsize: 16 --- I marked the important part with exclamation marks: Two read commands directly after another and note the similarity between the offset of the first of them and the offset for the first difference, that cmp reported: the first byte read from that offset - in that first read command - differs; now to the second read command: using cmp -b can also give you the values of the differing bytes. The following is just an example: Say cmp finds that byte 376833 differs and says "the original is 'x'" and the copy has a 'z' there, then you can open your file in a hex editor (or any other tool, that has a function like "Go to byte offset"), go to the offset mentioned by the _second_ read between my exclamation marks, and you will find exactly that 'z' there. So here is the race condition: The two marked read commands happen simultaniously; the first one seeks to the offset mentioned first. the second one seeks to the second offset. The first "thread" (I don't know whether this is about threads, let me just call it thread for now) takes up its work again; it reads - BUT from the second offset (explaining the 'z' on the position of the 'x'). Outputting the offset and the actual file position (self.file.tell()) inside the read method gives differing results for the two marked reads, they can for example be reversed (e.g. first read has offset 20, tell() says 10, second read has offset 20, tell() says 10; the first read puts the cursor to 20 using seek, the second one does the same with offset 10. the first then reads from 10 on -- 10 bytes -- and comes to stop at offset 20, from which position then the second one starts actually reading), for this particular example I got: 1. offset: 376832, position: 507904 2. offset: 507904, position: 638976, so the second read again starts at the position, where the first one stopped reading AFTER being placed to a wrong offset
[Bug 131013] Re: starting compiz in KDE displaces adept from tray
Just out of curiosity -- how is this supposed to be fixed? I just double-checked again, whether the patch is in the Ubuntu source package of kdebase (of my up-to-date 8.04.1) and it is not (I didn't check the debian/patches folder the last time I stated this - only the "pure" source files - but there, too, no luck). While I am at it: Confirming the last "still there" comment. As said in my last post, since the "Visual Effects" stuff (the config dialog and so on) got integrated into Kubuntu, the bug "happens" not so often but I noticed recently, that it almost always shows up after logging out and back in. Only after rebooting (or maybe after restarting the kdm service, didn't test this, yet), it doesn't apper again (that much). -- starting compiz in KDE displaces adept from tray https://bugs.launchpad.net/bugs/131013 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 131013] Re: starting compiz in KDE displaces adept from tray
OK, thanks for the clarification. Then let me try to bring it to the "Fix Released" state ;). As said already and as you may have noticed, I am not that much into Ubuntus packaging infrastructure, so contact me if the following is crap: I prepared two debdiffs - two because I didn't know whether to use the source packages (or the *.dsc's to be precise) or the binary packages, so I made both ;). They are attatched to this (the one for the source packages) and the following (the binary one) comment (and not marked as patches, I hope this is right...). I also uploaded the source package, which I made for this, to my PPA, where the binary packages are just being built, so keep an eye on it. ** Attachment added: "kwin_fix_tray_without_kwin.debdiff" http://launchpadlibrarian.net/17316973/kwin_fix_tray_without_kwin.debdiff -- starting compiz in KDE displaces adept from tray https://bugs.launchpad.net/bugs/131013 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 131013] Re: starting compiz in KDE displaces adept from tray
As said, the other debdiff... ** Attachment added: "kwin_fix_tray_without_kwin-bin.debdiff" http://launchpadlibrarian.net/17316981/kwin_fix_tray_without_kwin-bin.debdiff -- starting compiz in KDE displaces adept from tray https://bugs.launchpad.net/bugs/131013 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 131013] Re: starting compiz in KDE displaces adept from tray
OK, thats good news, thanks Scott. The patch should already be in KDE 3.5.10 according to the revision number of the kwin files in KDEs SVN (849627). The patch was committed in revision 783764. So it should work. However, if it doesn't I'll have a look ;). -- starting compiz in KDE displaces adept from tray https://bugs.launchpad.net/bugs/131013 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 131013] Re: starting compiz in KDE displaces adept from tray
Just upgraded to the backported 3.5.10 packages: I cannot say something about bug #261694, Kicker does not crash here. It seems to work here: I logged in and out several times and all tray icons are in place _except_ when my dcop server (silently) crashes. This however is a seperate problem, as it also happened to me with 3.5.9 (and I think also .8?). This behavior (of the icons, not dcop ;)) is expected though, because the patch -- which is applied in the 3.5.10 source packages, checked -- uses dcop to bring the icons in place. So if dcop crashes for some unrelated reason, this is not in the scope of this bug (and thus this patch). Seen from this bugs perspective only, the backport thus works for me, too, so go for hardy-updates! ;) -- starting compiz in KDE displaces adept from tray https://bugs.launchpad.net/bugs/131013 You received this bug notification because you are a member of Kubuntu Team, which is subscribed to kdebase in ubuntu. -- kubuntu-bugs mailing list [EMAIL PROTECTED] https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
[Bug 193333] Re: Kopete crashes X specially if compiz is running
I can confirm this bug with the current nvidia(-glx-new) driver (169.12), kernel 2.6.24.16 and a 7950 card (or something like this x) ). Compiz is enabled. Oh and i run Kubuntu Hardy (the KDE3 "version") 32bit here by the way. I also found this bug which seems kind of related to this one: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/183715 Additionaly I had this bug in two other situations: After finishing an update with Adept and after closing ZSNES from fullscreen. Unfortunately I don't know whether these crashes have the same reason as the Kopete problem. Another wild guess from a kernel+driver-hacking noob: While looking up the kernel and driver version to post them here, I noticed some differences; according to apt-cache I have the following versions: linux-image-2.6.24-generic: 2.6.24-16.30 linux-restricted-modules-2.6.24-generic: 2.6.24.12-16.34 nvidia-glx-new: 169.12+2.6.24.12-16.34 (matches the restricted modules, but not the kernel image, does it?) I always thought that kernels and drivers are very sensitive to version differences... or is this normal? As said, just my two cents ^_^". -- Kopete crashes X specially if compiz is running https://bugs.launchpad.net/bugs/19 You received this bug notification because you are a member of Kubuntu Team, which is subscribed to kopete in ubuntu. -- kubuntu-bugs mailing list [EMAIL PROTECTED] https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
[Bug 160264] Re: compiz displays white screen when locked
Just want to add my "confirmed" here: Three users on a nVIDIA-graphics based PC here with one (me) using compiz and getting a white screen when switching from a "normal" (Metacity) user to mine (not the other way around, though). All this is under Gutsy. -- compiz displays white screen when locked https://bugs.launchpad.net/bugs/160264 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 55273] Re: inkscape generates no latex formula
Similar problems here in Ubuntu Gutsy (=> Inkscape 0.45): When trying to render
ANY valid latex string, inkscape hangs after pressing the OK button still
showing the input dialog.
No error message in the console but in a file under /tmp
(ink_ext_stderr_), I get this:
pstoedit: version 3.44 / DLL interface 108 (build Apr 29 2007 - release build -
g++ 4.1.3 20070423 (prerelease) (Ubuntu 4.1.2-3ubuntu3)) : Copyright (C) 1993 -
2006 Wolfgang Glunz
PostScript/PDF Interpreter finished. Return status 2 executed command :
/usr/bin/gs -q -dDELAYBIND -dWRITESYSTEMDICT -dNODISPLAY -dNOEPS
/home/jules-k/psin3JohNg
The interpreter seems to have failed, cannot proceed !
Traceback (most recent call last):
File "/usr/share/inkscape/extensions/eqtexsvg.py", line 121, in
e.affect()
File "/usr/share/inkscape/extensions/inkex.py", line 157, in affect
self.effect()
File "/usr/share/inkscape/extensions/eqtexsvg.py", line 116, in effect
svg_open(self, svg_file)
File "/usr/share/inkscape/extensions/eqtexsvg.py", line 69, in svg_open
doc = xml.dom.minidom.parse(filename)
File "/usr/lib/python2.5/site-packages/_xmlplus/dom/minidom.py", line 1915,
in parse
return expatbuilder.parse(file)
File "/usr/lib/python2.5/site-packages/_xmlplus/dom/expatbuilder.py", line
926, in parse
result = builder.parseFile(fp)
File "/usr/lib/python2.5/site-packages/_xmlplus/dom/expatbuilder.py", line
211, in parseFile
parser.Parse("", True)
xml.parsers.expat.ExpatError: no element found: line 1, column 0
Sorry, if I miss something obvious, it's in the middle of the night here
;)
--
inkscape generates no latex formula
https://bugs.launchpad.net/bugs/55273
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 55273] Re: inkscape generates no latex formula
I also don't like messing with my package system in a way like this so I built my own custom (lib)pstoedit(-dev) package set based on the ubuntu source package and the upstream tarball. Is there any chance, that this bug will get fixed in the repositories before Hardy? -- inkscape generates no latex formula https://bugs.launchpad.net/bugs/55273 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 131013] Re: starting compiz in KDE displaces adept from tray
OK sorry for double posting (and again a probably long message) but I think I've got it. I think I've discovered the basic problem and also have a possible workaround (more or less); I cannot give you a patch as my idea didn't work, but what I wanted to do programatically directly in KDE can also be done in a start script; and then it actually works. So what happens: In the previous post I said, that we are looking at two problems actually here and I want to revise my self in this point: It is the same problem but time plays an important role here; What happens when a tray icon is hidden (KSystemTray::hide) in KDE is actually a removal of that icon from the tray. It becomes a top level window but an unmapped one so it cannot be seen; but it still holds the _NET_KDE_SYSTEM_TRAY_WINDOW_FOR (or however it is called) property, so that KWin remembers to redock it, if it is shown again. If now another window manager starts up and begins manage all the top level windows, this manager (which includes as far as I tested compiz, metacity, xfwm4 and wmaker), that manager doesn't care about that property anymore. If NOW the icon is shown again, it becomes a standart, mapped top level window. Another flaw, that is as far as I understand the situation now not directly related to this problem is, that compiz maps unmapped tray windows (i.e. their unmapped top level windows). metacity also does this. This problem is tray icon specific; I tried to unmap a normal window, then start commpiz and the window didn't get mapped... but this is the reason, why you see the adept notifier tray window in the top left of your screen; after its start up, it is hidden, then compiz starts, maps it and makes it a toplevel window (as stated above, it actually already is one...) So now the workaround: As can be read in some forum entries about this problem, adding another tray application (!KDE tray application!) to the tray, adjusts all the others (so mostly adept) as well; why is this? If there is a window manager running, that doesn't support KDEs tray protocol (e.g. compiz), and a KDE protocol tray window is created (CREATED, not SHOWN, so a new one, not an old one redocked), KDE loads the kdetrayproxy module, which - on its creation - goes through all the top level windows, looks for the above mentioned property and docks these windows accordingly. So the solution to redock displaced icons directly after window manager replacement is to load this module directly after KWin's exit. I wanted to do this in the code of the tray applet; it should watch the manager selection of WM_Sn (n=screen number) and load kdetrayproxy, if kwin looses it. This didn't work unfortunately, but as said, one can load the module for example in the compiz startup scirpt: dcop kded kded loadModule kdetrayproxy I hope this helps; FOR INFORMATION ONLY and for those further interested: I said, that the displacement of adept and other apps are two different problems and then took that back; so what happens, if another app gets displaced? - app _creates_ icon X (doesn't show it up until now) - compiz starts and doesn't care about X's KDE tray property, maps it due to some unknown reason -> "top level window tray icon" - NOW app maps X; this is actually the moment, in which the systray docking magic takes place - the stuff that I tried to log as mentioned in the previous post, but due to KWin's absence, this doesn't happen; my log code wasn't executed, which made me think, that two different problems exist here; the important thing and also a bit of the design flaw that is the basis of this bug is, that kwins management of the tray icons starts at the first point, but the management of the tray applet in step three; in between KWin disappears so this is basically a communication problem. Thank you for reading -- starting compiz in KDE displaces adept from tray https://bugs.launchpad.net/bugs/131013 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 131013] Re: starting compiz in KDE displaces adept from tray
Just another FIY and this time a rather short one :P: Filed a bug about KWin in KDE's bug tracker as I am now completely convinced that every aspect of the here described behavior is a problem of KWin's handling of "tray icon windows" (or maybe more generally QXEmbed widgets, but see the report linked below) and its communication with the system tray applet; and because I want this one to be fixed ;) It seems to be not related to adept, ubuntu or any specific window manager like compiz. Bug report here: http://bugs.kde.org/show_bug.cgi?id=157438 -- starting compiz in KDE displaces adept from tray https://bugs.launchpad.net/bugs/131013 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 131013] Re: starting compiz in KDE displaces adept from tray
Hello, wanted to confirm this bug (on Kubuntu 7.10 with all updates until now, graphics card is - if this information is useful - an nVidia 7950 GTX or however it is called...^^") and post some things I found out about this; maybe this is useful to someone... (and hopefully someone can understand this crappy English I'm writing here :P); I didn't know where else to write this (my launchpad profile gives me a "Homepage" inside the Ubuntu wiki - can/may I publish such information there??): At first: None of the mentioned workarounds really worked for me but I found out, that Adept Notifier getting displaced from the tray when you start compiz AFTER session "restoration" (all tray icons already there) and before or within, are two distinct problems; in the second case, this behavior can also hit other applications as mentioned in this bug report: https://bugs.launchpad.net/adept/+bug/47988. For me, it was mainly kBluetooth, but also Amarok from time to time. I compiled a test KDE environment so that I could insert logging at the interesting portions (the systray "suff") of kdelibs and kdebase. What I found out now is, that if you start compiz as part of the session, then the windows, that get "displaced" from the tray, actually never get added to it. I placed a log command inside SystemTrayApplet::embedWindow and it doesn't show up in the log file. If I start compiz after session initialization, the log says, that Adept Notifier got added - but twice; also logging the removal of tray icons showed, that it was also removed several times (my logs are a bit weired so don't hit me, if these numbers are wrong). I don't know, whether this behavior is correct (I mean, the adept tray icon is hidden and so on ...) but it made me look into adept_notifiers code and I think I narrow the source of the bug a bit: I have written a very simple kde app (kdevelops "Hello World in KDE") and added a tray icon to it: tray = new KSystemTray (NULL, NULL); // tray is a KSystemTray * tray->hide (); This is in the constructor of my KApplication derivate, which is approximately what adept does without checking for updates and so on. If I now start this application and start compiz after it, I get - as with adept - a small window in the upper left screen edge, which also shows up in the taskbar (ADDITIONALY to the applications main window). My conclusion: KSystemTray::hide (which is actually a method derived from Qt's QLabel, which in turn gets it from QFrame if I remember correctly) does something to tray windows, which makes compiz make them top level windows. Actually this also happens with metacity; now I don't know, how much code compiz and metacity share, so I cannot say whether this is a Qt bug or one in compiz's / metacity's common codebase... If I talk absolute nonsense here and this behavior is normal then just ignore me or write me some insults via e-Mail, but I think this is what makes adept behave like that and if you call that a bug, than it cannot be wanted behavior. I hope somebody can do something with this and am sorry for flooding this thread with such a long text oO -- starting compiz in KDE displaces adept from tray https://bugs.launchpad.net/bugs/131013 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
