Switching between enlightenment 0.16.6_pre4 and 0.16.5-r4, I found that kuickshow only produces a tiny window with what looks like a one pixel content with the newer version of enlightenment (both used as a viewer in konqueror or called from the command line). kuickshow started without argument works as expected, it's only displaying actual pictures that doesn't work. Other KDE image programs (kpaint, kview) do work on both versions of e16. Also, kuickshow keeps working through all other window managers I tested (e.g. blackbox). Having a remote instance of kuickshow with a display in a local e16 shows the same defects (for 0.16.6_pre4) as if it was running locally. Seems like some math error either in kuickshow or e16. Reproducible: Always Steps to Reproduce: Portage 2.0.48-r1 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1) COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -O2 -g -pipe" CXXFLAGS="-march=athlon-tbird -O2 -g -pipe" ACCEPT_KEYWORDS="x86 ~x86" kde-base/kdegraphics-3.1.2
odd, works fine over here ... maybe its a preference thing ?
Odd, indeed. I am seeing this on several machines. It doesn't seem to be user prefs: $ cd $ rm -rf .* * $ echo exec enlightenment > .xinitrc $ startx -- :1 (open Eterm) $ kuickshow /tmp/tst_any_pic.jpg -> one pixel window that remains black if magnified in e 0.16.6_pre4, works perfectly with 0.16.5, though I'm positive I didn't change global prefs in /etc, and I wonder how that would affect only the latest e16 and no other window manager anyway.
ok, after you load up kuickshow and its 1x1 pixels, launch another term and manipulate the window with eesh. set it to a 'normal' size and close it ... then re-launch it and see if it is still 1x1 ... if it is, resize it again, but this time have enlightenment remember the settings on it ... alt+right click -> Remember
> manipulate the window with eesh. set it to a 'normal' size and close it ... I set it to 100 x 100. Result: a 100 x 100 black window (plus the usual window decorations, of course). Sometimes one bright pixel in the center, depending on the picture. > re-launch it and see if it is still 1x1 ... It is. > if it is, resize it again, but this time have enlightenment remember the > settings on it ... alt+right click -> Remember Still one pixel size. Checking the window settings confirms that enlightenment has the "Remember Size" flag set, though. In this setup kuickshow displays all images as 1x1 pixel. Asking it for the properties yields correct answers, though, and saving the picture works, too. It seems that some change in enlightenment causes kuickshow to make bogus calls to the window manager. One more thing: Every zoom action in kuickshow makes the window size go back to 1x1. Hitting '+' to zoom in, no matter how many times, won't change anything -- there's one bright pixel in the middle. Hitting 'o' (restore original size) will also shrink the window back to 1x1, but when resizing the window the picture is there as it should be, and further zoom requests work as expected (except that they keep resizing the _window_ to 1x1). In addition to reproducing this on several machines, I have also rebuilt gentoo from scratch without ~x86 in a chroot partition. The only unstable package in there is enlightenment. Same effect. Could it be some exotic USE flag? Here are mine: 3dnow aalib alsa apache2 arts avi cdr crypt cups debug dvd encode esd ethereal fbcon gdbm gif gnome gpm gtk2 gtkhtml imlib java jpeg kde ldap libwww matrox mbox mozilla mozsvg mpeg ncurses oggvorbis opengl pam pda pdflib perl pic png qt quicktime readline -slang snmp spell ssl -svga tcpd tetex tiff truetype vim-with-x X xinerama xml2 xmms xv zlib
i just added pre5 ... if it doesnt fix your problem ill talk to the upstream authors
I tried pre5. Still no go.
well the answer has been found, but i dont know if you'll like it :) i'd post the sf link but they're down atm :x Re: [E-devel] e16.6 Windows are sometimes moved when resizing (was BUGS) From: Kim Woelders <kim@woelders.dk> (he maintains 0.16.x now) To: enlightenment-devel@lists.sourceforge.net Date: 06.08.2003 16:20 <snip> It turns out that some apps issue ConfigureRequests with more or less bogus values, and E gives them exactly what they request. I have now seen this with - mozilla(1.4): Sets its origin to (0,0) when using the resize button. - kuickshow 0.8.5 (rh9): Sets its origin/size to (0,0)/(1,1). - gdb 5.2 (rh9): Sets its console/source window origins to (0,0) at startup. Unless I'm missing something here, it seems to me that that these apps are broken. In theory, E could be configured (e.g. in windowmatches.cfg) to ignore certain of the ConfigureRequest parameters for particular apps. I don't think it's worth wile, though. So, until somebody convinces me otherwise, this is not a bug in E :-) /Kim
what does `kuickshow -version` return for you ? root@vapier 0 root # kuickshow -version Qt: 3.1.2 KDE: 3.1.3 KuickShow: 0.8.5 maybe upgrading those will 'fix' the problem ...
The reason I filed this bug against e16 (and not kdegraphics) is that the version of e in Gentoo testing made it appear. IOW: The older (current stable) version of e either magically fixed the bogus request, or it somehow managed to convince kuickshow not to send bogus requests to begin with. There _is_ something about the new e16 version that triggers the bug in kuickshow, since the bug won't show up in other window managers. Since this is a serious bug and one I care quite a bit about, I'd like to take this up with the kdegraphics maintainers. Can I reopen the bug and assign it to component "KDE" or will that break standard Gentoo operating procedures (I could also open a new bug pointing to this one) ? FWIW: $ kuickshow -version Qt: 3.1.2 KDE: 3.1.2 KuickShow: 0.8.5 I don't expect upgrading KDE to help much with this.
fixed in cvs, hopefully next pre takes care of it Roger Luethi wrote: > There are quite a few applications that break with 0.16.6pre. Turns out the > reason for this is the new _partial_ support for the Window Manager > Specification. > > The new e16 tricks programs into believing the standard is implemented, but > it fails to set _NET_WORKAREA, which is a _required_ property (it's been > this way since 1.0) [1]. Depending on the application, hilarity ensues > (some try to fit into a 0x0 work area). > > The attached patch is against e16 CVS and has seen little testing. It works > for me (fixes broken apps), but you may well have better values for that > property, or better locations to invoke EWMH_SetWorkArea() from. > This makes kuickshow behave quite a bit more reasonable :-)
bugzilla
