kcmodule and kcmoduleproxy
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