[Panel-devel] problem with time dataengine

[Michael Olbrich]

On Tue, Jul 24, 2007 at 04:00:39AM -0600, Aaron J. Seigo wrote:
> On Tuesday 24 July 2007, Michael Olbrich wrote:
> > On Tue, Jul 24, 2007 at 12:24:39AM -0600, Aaron J. Seigo wrote:
> > I'm not sure I like it. The problem is, that an applet doesn't get what
> > it asks for. That makes the applets a lot more complicated.
> 
> this assumes the applet cares. i don't think it many cases it does.

I'm not so sure either way. I am a bit concerned about the hidden
problems this may cause. After all such problems only occur in
combination with other applets.

> > Take a graph for example that plots cpu usage, network traffic, etc.
> > (That's what I was actually looking into when I looked at the time
> > dataengine to see how to handle different update intervals).
> 
> heh. so the TimeEngine was a red herring ;)

Not really. I'm a lazy man. So when I faced the problem I looked if
someone else had already solved it. That's how I found the problem in
the TimeEngine. And I prefer to talk about real code instead of
theoretical problems.

> > The applet requests updates every 20 seconds. What it may get are updates
> > every 5 seconds.
> > Now the applet needs to
> > a) know the real update rate (including notifications when it changes).
> > b) do some kind of accumulation to provide a correct graph.
> 
> i assume the issue you want to calculate at the applet end things like kb per 
> second for network? that should be done in the engine, to be perfectly 
> honest. accumulating raw counts for additional analysis in applets is just 
> asking for problems.

What I want to do is, shift the graph by one pixel and add the new value
whenever the signal is emitted. But that is not possible if the signal
comes too often.

> drawing (and therefore performance) is probably more likely an issue.

very true.

> > And if the updates come every 3 seconds it's not even possible to do
> > things right.
> 
> it's quite possible. it just means doing math and possibly fudging numbers 
> slightly, both of which, i understand, sucks. i'm actually more concerned 
> about the former (makes it harder) than the latter (we're not building 
> controls for a nuclear power plant).

Well, I could get the correct graph but not an update exactly every 20
seconds (which is not really a problem in this case). But you are
correct, this is not something that should be necessary in an applet.

> > How about making sources unique by name + configuration?
> > When an applet changes a property the following happens:
> > If a source with the matching configuration exists, switch to that one.
> > Otherwise create a new source for the requested configuration.
> 
> what would the DataEngine's API to this be? the DE should only need to update 
> the data in one place. it also means a bunch of copies of data all over the 
> place.. ugh. we could share the Data between DataContainers and have 
> one "master" DataContainer .... all to achieve having separate timeouts?

I see your point.

> looking at the realities of things there's a really limited set of 
> configuration needs and the ones that seem most contentious are time related. 
> it may make more sense to do multiple signals based on timings... 

Basically handle the timing differently than all other properties?

> what i really need to do is go over each engine an enumerate what the actual 
> settings that are needed are and see if some patterns emerge there. perhaps 
> it's all about timing.
> 
> right now the engine drives the timings, perhaps some of that needs to move to 
> DataContainer; but having multiple DataContainers kicking around sounds 
> really bad.

How about adding some kind of polling capability to DataContainer:

engine->connectSource(sourceName, interval, this);

The corresponding DataContainer and a timer for interval are created.
Whenever the timer expires call:

DataContainer::poll(uint interval) {
    emit updateData();
    checkForUpdates(interval); // calls the signal that corresponds
                               // to "interval".
}

This way the engine doesn't have to worry about the timer either.

michael