kcmodule and kcmoduleproxy
kretz at kde.org
Sat Dec 6 10:07:52 GMT 2008
On Saturday 06 December 2008 00:43:43 Parker Coates wrote:
> 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.
Yes, that's also doable, but might be a bit too much effort (there are very
many KCMs out there).
> Using hardcoded sizes would likely cause problems with translations.
Well "cause problems" should more be like "not help much". And it's not only
translations but also different font sizes (think low-DPI vs. high-DPI) that
can influence the size.
> 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.
What if you get a misbehaving (in the size) KCM that gets fixed later. Your
dialog will still be that big. Or KCMs are improved to become smaller. The
dialog still keeps the old size. Or you switch font/font sizes or style.
Those issues are all fixable, but they need lots of thought and code and
testing so that it doesn't become another new annoyance.
Matthias Kretz (Germany) <><
More information about the kde-core-devel