kcmodule and kcmoduleproxy

Sebastian Sauer mail at dipe.org
Thu Dec 4 19:55:17 GMT 2008

Albert Astals Cid wrote:
> A Dijous 04 Desembre 2008, Matthias Kretz va escriure:
>> AFAIR that's the original behavior of the proxy. This line was probably
>> introduced to "fix" the incorrect initial size of the dialog (yes, as svn
>> blame + svn log tells us). I.e. with your patch the dialog now might
>> resize when you show one of the contained KCMs for the first time.
>> IMO (not humble in this case) it is better to have a resizing dialog than
>> a long delay before having the dialog ready. Which is why I made the
>> proxy delay loading, and breaking it like this one might have just
>> deleted all the delayed loading logic...
>> If dialogs are initially "ridicolous"ly small then the application needs
>> to be "fixed" to set a sensible initial size for the dialog...
> I disagree, i don't need to set any sensible small size, Qt does it for
> me, and quite good actually. You are bypassing it, and it's failing, and
> you say it's the developers fault?

As far as I understood the prob is here that e.g. Konqi's settings-dialog does 
resize what is, without question, evil as well and needs to be fixed.

I would suggest, and that's how I did understood Matthias, that we should look 
at e.g. Konqi's settings-dialog how to fix it while preserving the KDE3 logic 
of delaying loading the kcmodule's as long as possible (what the patch is 

My suggestion here was to follow what we did with systemsettings. In the case 
of Konqi's settings-dialog we could try to identify those kcmodules which do 
result in such a resize and either (short term solution) put them into a 
QScrollArea or (long term solution) make them more friendly to also work fine 
on e.g. a eeePC.

Would that be better?

More information about the kde-core-devel mailing list