moving kosdwidget to kdereview

[Ben Cooksley]

the setPosition() now takes two enums, XPosition and YPosition that
are effectively wrappers for the numbers used previously, as of
revision 857268

Ben Cooksley

On 9/5/08, Ben Cooksley <sourtooth at gmail.com> wrote:
> yes! i use a shaped window.
>
> -the idea behind the defaultBlah() functions are for applications to
> discover whether or not the osd will automatically update the font or
> palette, but i can see the reason for not having it.
>
> -the use case for setting the position, is that applications may want
> a certain position ( ie. center or top left ) i think i can provide a
> direction system, i will work on it. ( complete with reasonable
> default )
>
> the weekend gives me lots of free time :) so i should be able to work
> out the issues raised.
>
> thanks,
>
> ben cooksley
>
> On 9/5/08, Aaron J. Seigo <aseigo at kde.org> wrote:
>> On Thursday 04 September 2008, Ben Cooksley wrote:
>>> 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.
>>
>> ah .. you're using a shaped window then?
>>
>>> 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.
>>
>> as the application would change this itself, the application can also
>> track
>> it, no? no point in bloating the api for 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 )
>>
>> cool
>>
>>> 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.
>>
>> i'd rather see a directional system, e.g. NorthWest or Center. it gives
>> the
>> same effect without the odd 20x20 grid thing. when would i want an OSD at
>> (5,5)?
>>
>> for that matter, what is the use case for when an application needs to set
>> the
>> location of the OSD at all? can that be handled completely internal to the
>> OSD
>> widget?
>>
>> --
>> 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
>>
>>
>