kcmodule and kcmoduleproxy

[Parker Coates]

On Fri, Dec 5, 2008 at 18:02, Albert Astals Cid wrote:
> A Divendres 05 Desembre 2008, Matthias Kretz va escriure:
>> On Friday 05 December 2008 14:06:46 Celeste Lyn Paul wrote:
>> > > 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.
>>
>> Keep in mind that with lazy loading, if you want to never resize
>> automatically, you have to use scrollbars.
>>
>> > > 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 about).
>>
>> Yes, my suggestion is to make a best guess at the needed size and use that
>> as initial (or enforced minimum) size for the dialog from the
>> Konqueror/Kontact code. Then the chances that a KCM doesn't fit and needs a
>> resize/scrollbars is much reduced.
>>
>> > > 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?
>> >
>> > Wouldn't using a scrollbar be a good idea as a fallback regardless if it
>> > fits in 800x600?  When you have 800x600 on a 4.25 inch/10.8 cm screen,
>> > 9pt font is pretty damn small. I've heard a lot of netbook users complain
>> > about some dialogs (not sure if they were kcm or other) not fitting
>> > because they increase their default font size, and some accessibility
>> > themes increase font size, which results in more use of vertical UI.
>>
>> BTW, back in January 2005 KCModuleProxy used a QScrollView to embed KCMs. I
>> don't remember the details why Frans removed them again: you can try your
>> luck with reading the svn logs and mailinglists from that time...
>>
>> FWIW, my opinion about resizing vs. scrollbars is that as long as the
>> resized dialog fits onto the screen it should resize. If the dialog would
>> get bigger than the screen than it should instead use scrollbars.
>> Rationale: if I'd get a dialog with scrollbars I'd resize it manually to
>> make the scrollbars go away (as long as it fits on my screen). As the
>> computer can do the resizing better and faster than I can ...
>
> Other solution is having the possibility of .desktop files of the kcm having a
> suggested minimum size field that we use to calculate their minimum size if
> they have not been loaded. It could get out of sync but would fix fast
> loading and sizing jumpyness.

Using hardcoded sizes would likely cause problems with translations.

What if some arbitrary initial size is used on first run, but when the
dialog is closed the size is saved in the rc file and used again the
next time the dialog is shown.

This seems like a pretty simple solution, so I'm sure I'm missing some
of the complexity of the problem.

Parker