Strange resizing issue with kde4-kile

[diochnos]

Dear All,

I noticed that there was a very recent update on many kde libraries (last 2-5 days) and today that I attempted to open kile and start writing text I have to face a very strange issue. The "normal" window of kile exceeds the size of my visible desktop; its dimensions are probably 2-3 times the visible horizontal space that I have for my desktop. Unfortunately, I can not resize the window and make it fit in my desktop as a whole, unless I maximize the window, in which case it is automatically adjusted to take over the entire screen.

So, the problem is that even though I can resize kile vertically and see part of my desktop above or below the window, there seems to be some threshold on the horizontal resizing that I am allowed to do that is somewhere between 2-3 times the space that I have for my actual desktop. Perhaps there is a constant like 0.25 (* screen width) that takes care of this minimum allowed horizontal resizing of the window and this has changed by one decimal to 2.5 by accident? I really can not think of anything else, since up until last week I had no such "visibility" issues and I could resize the window normally.

I also tested if the same problem is apparent on okular, kwrite, and kate, but I have no resizing issues there, which makes it even weirder.

I am running 10.9.5 with all the relevant updates provided by Apple on an 11-inch Air. I am referring to MacPorts version 2.3.1. For what it's worth, I have also installed poppler with the variants +qt4+quartz.

Thanks in advance for your time.

[sv@…]

Hello,

I can confirm this behavior on OSX 10.9.3 with MacPorts 2.3.1 and last update on 14. Oct 2014. This bug is probably an issue between the minimum window option in Qt and some settings in kile.

What I have tried/observed so far:

Removing kilerc (~/Library/Preferences/KDE/share/config) does not solve this problem.

kate's minimum window size is much smaller then kile's. So i guess its not an issue with kate (the internal text editor of kile?).

Removing the full KDE (~/Library/Preferences) configurations folder does neither help.

[NicosPavlov]

I tested a little the issue, and found that it is generated by a patch newly added to the Portfile: patch-nativeDialogs.diff. The easy solution is be just to deactivate it, but as kile seems to be the only application having this issue, it may be possible to keep the advantage of the patch while solving the kile resizing issue.

[RJVB (René Bertin)]

Is it possible to build and run kile without having TeX installed?

[NicosPavlov]

The applications would still run as a text editor, yes.

[RJVB (René Bertin)]

I'll see if I can come up with something.

In the meantime, there's a simpler workaround than rebuilding kdelibs4. Find kile's settings file (kilerc?) in /Library/Preferences/KDE/share/config , and make sure it has the following:

[KFileDialog Settings]
Native=false

i.e. either add a line "Native=false" to an existing KFileDialog section, or add the section with the line, as shown. This will make kile use non-native (i.e. KDE) style dialogs.

This is something I use for kdenlive for instance, but in that app's case it is only the file dialogs that are garbled in native mode, nothing else.

[RJVB (René Bertin)]

I can't reproduce the issue, not even with the "Macintosh (Aqua)" theme ...

[NicosPavlov]

Alright, there seem to be some misunderstanding. It is not the open dialog which is wrongly resized, but the main window, as shown in the screenshots I just attached. Moreover, this happens not only at the start, but also when running some of the tools, which makes the issue more irritating.

For what I understand, your configuration is not the one currently present in Macports, as themes are not available at this time. Your layout is also not the usual one, it seems to me. As such, the workaround you gave (deactivating native kfiledialog) actually does not solve the issue, as it changes the open dialog and not the main window.

As the patch seems to induce some issues in certain applications, I would tend to deactivate it for now.

[RJVB (René Bertin)]

I know it's never been about the open file dialog, my screenshot just showed one to prove I'm using native dialogs.

Indeed, I'm not running a config currently in MacPorts, I'm running kdelibs 4.14.2 (which might explain something). I did upload a port package for the QtCurve theme shown (and know Marko uses it too).

Anyway, I never intended the native file dialogs patch to be anything but an optional variant, because it's not a patch I conceived myself. In other words, I don't really know what it does, and from the RR I seem to recall that there was a part to it that raised questions. I'll see what I can figure out knowing that the runtime deactivation of the patch does not prevent this resizing issue.

However, I'd raise an issue with the kile devs too. It seems not impossible that this is due to something in their own code (silly example: use some information from KFileDialog to resize the main window).

[NicosPavlov]

Alright. Patch deactivated in r127016. I left it in the repo, in case a variant is made one day.

[RJVB (René Bertin)]

OK, I understand what happened here, thanks to a mail from Ian on the mailinglist.

The native filedialogs patch included with the 4.13.3 kdelibs4 release in fact included the unified toolbars patch (the 1st hunk in the patchfile, to kmainwindow.cpp). That one was shown to cause enough issues that I don't even use it myself.

Please remind me to post an up-to-date native filedialogs patch (not that it has changed...)!

[zhu527812567@…]

Replying to nicos@…:

Alright. Patch deactivated in r127016. I left it in the repo, in case a variant is made one day.

Thanks!

This helps me.
I built krita 2.8.5 from upstream source and suffered a crash when closing(minimizing?) the window. This change fixed the problem.

Replying to rjvbertin@…:
The unified toolbars patch also breaks krita's own toolbar. (krita uses her own theme anyway)