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

List:       kde-core-devel
Subject:    Re: New KGraphicsSignalPlotter class
From:       John Tapsell <johnflux () gmail ! com>
Date:       2010-01-29 2:06:45
Message-ID: 43d8ce651001281806v6d212f78ib0a5600ed8670989 () mail ! gmail ! com
[Download RAW message or body]

2010/1/28 Aaron J. Seigo <aseigo@kde.org>:
> On January 27, 2010, John Tapsell wrote:
>> avoid this.  I have put a lot of work into KSIgnalPlotter to make it
>> faster and better, and it would be nice for the plasma widget to
>> benefit from this.
>
> sounds good
>
>> I want to reduce this plasma widget to a bare
>> shell that just inherits KGraphicsSignalPlotter and adds on the few
>> plasma specifics bits (using theme colors mostly.  Maybe also the SVG
>> code)
>
> we can't change what it inherits. it is a QGraphicsWidget, and that has to
> stay that way for API compatibility reasons.
>
> the way to go about this depends on whether KGraphicSignalPlotter has a very
> different API from Plasma::SignalPlotter or not. if the API is the same (or
> close enough) then the job should be easy:
>
> Plasma::SignalPlotter can internally have a KGraphicsSignalPlotter as a child
> in a QLinearLayout and pass on all the API calls to it.

if I want kdelibs/widgets/plasma/signalplotter to use
KGraphicsSignalPlotter then presumably I will need to move this widget
into kdelibs, right?  Where should it go?

John

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

Configure | About | News | Add a list | Sponsored by KoreLogic