When I go to File -> Open menu option in a KDE program, the open file dialog displayed is tiny. Therefore, file list is almost impossible to see. Reproducible: Always Steps to Reproduce: 1. Go to File -> Open menu option Actual Results: The displayed dialog is tiny Expected Results: The dialog should appear in a "normal", visible size.
Created attachment 113087 [details] Screenshot of the described problem
I've seen this happen sporadically but never consistently or at a level where I was bothered by it. When it does happen, I can resize the file dialog, close it and open it again, and it's back to normal. What version of kde are we talking about? useflags? other interesting tidbits of information?
(In reply to comment #2) > I've seen this happen sporadically but never consistently or at a level where I > was bothered by it. When it does happen, I can resize the file dialog, close it > and open it again, and it's back to normal. This happens always and it's impossible for me to resize the dialog window. > What version of kde are we talking about? useflags? other interesting tidbits > of information? Using fluxbox as WM. K3b and KBabel are the only KDE apps on my system. Installed packages related to KDE: [I--] [ ] kde-base/kde-i18n-3.5.5 (3.5) [I--] [ ] kde-base/kdelibs-3.5.5-r9 (3.5) [I--] [ ] x11-libs/qt-3.3.6-r4 (3) [I--] [ ] kde-base/kbabel-3.5.5 (3.5) [I--] [ ] app-cdr/k3b-0.12.17 (0)
I think the output from emerge --info could provide useful information as well (useflags and much other stuff) The times I've seen it, has been with the fluxbox windowmanager as well. Does the problem disappear for you when you switch to another window manager? (either log into something else, or try kde-base/kwin, the kde windowmanager). It could be caused by fluxbox or a combination of fluxbox/kde troubles :-)
emerge --info output: Portage 2.1.2.2 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.17-gentoo-r8 i686) ================================================================= System uname: 2.6.17-gentoo-r8 i686 AMD Athlon(tm) processor Gentoo Base System release 1.12.9 Timestamp of tree: Sun, 11 Mar 2007 10:50:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="eu_ES.UTF-8" LC_ALL="eu_ES.UTF-8" LINGUAS="eu" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X aac alsa apache2 bash-completion berkdb bitmap-fonts bzip2 cli cracklib crypt ctype cups dbus dri encode esd fbcon ffmpeg flac gdbm geoip gif gpm gtk hal iconv imlib ipv6 isdnlog java jpeg libg++ mad midi mmx mmxext mp3 mysql mysqli ncurses nls nptl nptlonly nsplugin nvidia opengl pam pcre pdf perl png ppds pppd python readline reflection session spl ssl svg tabs tcpd tiff truetype truetype-fonts type1-fonts unicode userlocales vorbis win32codecs wma x86 xorg xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="eu" USERLAND="GNU" VIDEO_CARDS="nv" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS At the moment I can't test any other WM since I only have fluxbox installed. I'll try with xfwm4 for instance (can't compile kde-base/kwin!). Let's wait until it compiles... O:)
(In reply to comment #4) > The times I've seen it, has been with the fluxbox windowmanager as well. Does > the problem disappear for you when you switch to another window manager? > (either log into something else, or try kde-base/kwin, the kde windowmanager). > It could be caused by fluxbox or a combination of fluxbox/kde troubles :-) I've tested xfwm4 and during its session I've been able to resize the dialog window. Now in fluxbox, I see the window in the size I left in xfwm4. After researching a little bit, I've found that session.screen0.decorateTransient option needs to be set to true in ~/.fluxbox/menu file in order to have the dialog windows resizeable. So, this simply can be resolved changing the commented option. But now I ask myself: why is the dialog window so tiny the first time? Is just a fluxbox 'bad' behavior or does it affect to other WMs?
(In reply to comment #6) > I've tested xfwm4 and during its session I've been able to resize the dialog > window. Now in fluxbox, I see the window in the size I left in xfwm4. This would suggest to me that the dialog size is somewhere stored by KDE or QT, and may not actually be the WM's fault after all. Then again, it is certainly possible that fluxbox (and apparently xfwm4 also) is missing some special hint or event that the dialog is sending when it is opened the first time. > After researching a little bit, I've found that > session.screen0.decorateTransient option needs to be set to true in > ~/.fluxbox/menu file in order to have the dialog windows resizeable. I was able to resize the dialog window using ALT+right drag, even though there were no window handles. If you have changed your 'session.modKey' in ~/.fluxbox/init, it may be WIN+right drag. I have talked to fluxbox upstream about this, very briefly. They have some reports of this happening in GTK as well. However, since the workaround is very easy (alt+drag to resize), it's not likely that they will spend very much time looking into it. I may look into it myself in the future, time permitting, but I do not believe this is a major or critical bug. Reducing severity. If you would like to help investigate this issue, any information you can get from the QT or GTK folks on exactly how this dialog is *supposed* to work the first time would be very useful.
(In reply to comment #7) > (In reply to comment #6) > > I've tested xfwm4 and during its session I've been able to resize the dialog > > window. Now in fluxbox, I see the window in the size I left in xfwm4. > > This would suggest to me that the dialog size is somewhere stored by KDE or QT, > and may not actually be the WM's fault after all. Then again, it is certainly > possible that fluxbox (and apparently xfwm4 also) is missing some special hint > or event that the dialog is sending when it is opened the first time. I've been looking after the configuration setting for the dialog size: it's stored in ~/.kde/share/config/kdeglobals file under [KFileOpenDialog Settings] section. The parameters are Height and Width, measured in pixels. > > After researching a little bit, I've found that > > session.screen0.decorateTransient option needs to be set to true in > > ~/.fluxbox/menu file in order to have the dialog windows resizeable. > > I was able to resize the dialog window using ALT+right drag, even though there > were no window handles. > > If you have changed your 'session.modKey' in ~/.fluxbox/init, it may be > WIN+right drag. I didn't know ALT+right click was able to resize the window... it works, right. > I have talked to fluxbox upstream about this, very briefly. They have some > reports of this happening in GTK as well. However, since the workaround is > very easy (alt+drag to resize), it's not likely that they will spend very much > time looking into it. I may look into it myself in the future, time > permitting, but I do not believe this is a major or critical bug. Reducing > severity. If you don't know ALT+right drag is possible you're lost! like me some time ago... xD > If you would like to help investigate this issue, any information you can get > from the QT or GTK folks on exactly how this dialog is *supposed* to work the > first time would be very useful. http://bugs.kde.org/show_bug.cgi?id=124902 refers to this initial behaviour. So as you said before, this seems a KDE issue rather than fluxbox or other WM problem.
Thanks for the information. I for one am convinced this is a KDE problem, and not a fluxbox one. I wonder if there's some way the KDE team could set a default 'kdeglobals' with a sane dialog size on install? Bringing in the KDE herd.
Sorry for taking so long to respond. Unfortunately , this problem is rather trivial but I couldn't come up with a similarly trivial solution: Width and height of of the file dialog are indeed stored in the user's kdeglobals configuration file (they can be set system-wide in $KDEDIR/share/config/kdeglobals, too, but that doesn't really help here either): [KFileDialog Settings] Height 1024=148 Width 1280=599 As you can see, both are set relative to the user's current screen resolution. This is something we can't easily determine from an ebuild. If you resize the file dialog, its new size is saved to kdeglobals and it should be fine ever after. We could specify height/width settings for "common" screen resolutions in $KDEDIR/share/config/kdeglobals. This has at least two other drawbacks: If the user chooses an "uncommon" screen resolution, the problem would return and be even harder to diagnose. Furthermore, if the user resizes the file dialog only the difference compared to $KDEDIR/share/config/kdeglobals is written to ~/.kde/share/config/kdeglobals. I don't really like this approach because using the global file location is rather uncommon (I've never had it in years of using KDE) and it would effectively split (user) configurations into two separate locations. Another approach: I think we should principally be able to set sane default settings using kconf_update (which is run when KDE starts and when kded sees a new update file) from kdelibs but we would have to write a script or mini-app that a) determines the current user's resolution, b) calculates sane defaults for the file dialog and c) returns those to kconf_update. Doing this, though, would introduce new potential sources of problems and would probably be more of an effort than configuring the WM to allow you to resize the file dialog. (I'm using fvwm myself and only consciously noticed during my tests for this bug that I suffer from the same problem. :) ) In short: I think it would be better to configure the WM in question to allow you to resize the file dialog (which I took for granted as being the default because I've never seen any WM *not* allowing it by default) instead of trying to correct it in Gentoo's KDE. Of course, the upstream bug is still open and, IMHO, valid so you might want to vote on that. I'm sorry for not having better news for you but if you can think of another possibility which I might have missed, by all means feel free to suggest it. I'm leaving kde herd cc'ed so that we'll get to see anything you might come up with.
Sounds like UPSTREAM to me...
