moving kosdwidget to kdereview

[Ben Cooksley]

hi,

I run it in a non-composited environment ( ie. with kde compositing
off ), it still has its rounded edges, etc. from a quick run a while
ago, there is no difference between composited and non-composited mode
unless something else does something.

defaultFont() and defaultPalette() are for applications to check
whether or not the application will automatically update the palette +
font when the kde color scheme changes ( yes, that does exist: please
see lines 74, 114-126. line 74 allows the updating to be triggered.
lines 114-126 actually do it.

the positionx() and positiony() functions are actually deprecated,
they are back from the messy days when it and kdisplay were one piece.
i have already removed them both. ( i will commit it though when i fix
the api docs )

i am already working on cleaning up the apidocs as you have suggested.
do you have any other suggestions for a positioning system? it is
there so that applications do not have to worry about the screen size,
or any changes. if i remove it then every application needs to handle
it seperately ( leading to code dup. ). if you merely want to change
the grid size that is easy to do.

ben cooksley

On 9/5/08, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Thursday 04 September 2008, Ben Cooksley wrote:
>> hi,
>>
>> i have moved my kosdwidget library from playground/base to kdereview.
>> kosdwidget is a widget that can be used by an application,library,
>> daemon, etc. to display an on-screen display in a easy way.
>>
>> it aims to be able to display some text, some supplied progress ( in a
>> progress bar ) and a image, as well as being able to be hidden either
>> when it is clicked or on a timer. it automatically integrates by
>> setting the appropriate kde font and palette whenever it changes, and
>> is based on qwidget. the image is automatically scaled to fit the
>> space provided for image display. all i have described above is
>> currently functional. i hope to move it to kdelibs trunk.
>
> for me this is the real showstopper:
>
> * which applications are using it?[1]
>
>
> other issues include:
>
> * how does it look in a non-composited environment?
>
> * the apidox still look a mess; they should be formatted like every other
> class does: short lines so its readable by looking at the header in a text
> editor
>
> * i still don't agree with the 20x20 grid system
>
> * positionx and positiony (besides that they should probably be positionX
> and
> positionY) are redundant with position().x() and position().y()
>
> * why defaultFont() and defaultPalette()?
>
> * theming is still not considered in the code.
>
>
> i don't think this is a valid candidate for kdelibs. the code needs more
> maturing, it needs to be used in some real world applications (i'd suggest
> seeing if you can work with the Amarok guys, in fact).
>
> [1]  the kdisplay app doesn't count, really. it's in playground, it's whole
> purpose is this one item ....
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Trolltech
>
>