[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    KFontDialog has new option for usage of relative font sizes
From:       Karl-Heinz Zimmer <khz () kde ! org>
Date:       2001-12-15 0:46:37
[Download RAW message or body]

[Hi Daniel, I am cc'ing you because I think you should know about
 this feature, it might be relevant for documentation of KFontDialog...]


Hi,

KDE head branch got a little addition in kdelibs/kdeui/kfontdialog.h .cpp
that might be of some use for KOffice, actually we are using it in kchart.

Specifying an additional *bool parameter when calling KFontDialog::getFont
(or the c'tor, or KFontDialog::getFontAndText) you get a little checkbox
saying "relative" immediately below the "Size" listbox.

Checking this box would result in KFontDialog::getFont returning 'true'
in the new *bool parameter.
The state of the box may also be retrieved by calling
KFontChooser::sizeIsRelative() - this is only for rare cases where you
might prefer using the KFontChooser class rather than the KFontDialog.

Ok, what is this "relative" checkbox good for?

When using fonts you often have the problem that the font size must be
adjusted each time when the size of the paper or the wigdet size was
changed.
One common solution of course is using stylesheets (so the user has to
adjust his base stylesheet only) but this is only one way how to do it,
another solution is: just specify that your font size is _not_ x Points
but x per mille of the widget size (or something similiar).
By doing so your layout will become more independend from changing
widget size - something that might happen easily to a KParts object.

So (to come to an end of my speach :)) this is my proposal: look through
your code and look for possibilities to enhance the usability by giving
the user the option to choose relative sizes rather than fixed ones. Of
course this not only belongs to font sizes but to many other things as
well: line widths, diameter of little marker symbols, relative distance
of floating frames from the paper border . . .

I am sure it is easier to think about this now, since KOffice today is a
great and large project but not a 'huge' project - and I am sure the same
task will take far more time when being performed in one or two years.
I see KOffice on a completely different level then and it probably will
be far more complicated to make such changes then, so that's why I am
making the proposal to think about this option today. :))

Cheers,

Karl-Heinz

-- 
Karl-Heinz Zimmer, Senior Software Engineer, Klarälvdalens Datakonsult AB
<mailto:khz@klaralvdalens-datakonsult.se>            <mailto:khz@kde.org>

   BugCops  ***  Making Free Software Better  ***  http://bugcops.org

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]