[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