So good speaking with you, boys.
Greg wrote:
> If the image is assigned to the bargraph's group, then just telling the
> bargraph widget to redraw() will do it.
> But if the image is assigned to the parent window, then you'll have to tell
> the parent window to redraw.
> Be sure to use an Fl_Double_Window to prevent flickering during redraws.
This is exactly what I am doing now.
Ian wrote:
> So long as the background is drawn by your app, then it is feasible to
> composite the bar graphs and etc on top of it.
> But: If the background is drawn by some other app, or is otherwise outside
> the control of your app windows, then compositing the graphs and so forth on
> top becomes Very Tricky.
>> For now the simplest solution I can imagine is to redraw the whole parent of
>> my object.
>
Quite possibly: I think we need to understand more about the nature of
the backgrounds, how they are drawn etc, and from there we can figure
out how to render the graphs on top of them...
Well, there is no window manager ; I have microwindows sitting over the
framebuffer and a single fltk application which does everything, so the
situation is conceptually simple,
because everything is drawn from one single app. Background programs to acquire
remote variables, but only one app writing on lcd.
I manage all the firmware, from bios to Linux kernel to user interface, so I
have full control on the machine.
I am trying to create objects as simple as possible : generally speaking every
object has some functions to "animate" itself, requesting variables from a
remotely connected machine.
For example:
Think of a plant which, in its full realization, is composed of 4 identical
"stations" (tanks, motors, etc.) .
For each station the plant supervision designer will put:
- one background image (the drawing of the station) with a "visible" boolean
coming from remote
- one bargraph (value, min, max, "visible" boolean)
- one box displaying a numeric value (value, format, "visible" boolean)
- one multiple-image box representing the run status (off, on, waiting, etc.)
-> (image index, "visible" boolean)
- one start/stop button
- etc. etc.
Now a plant is smaller and has only two stations: the remote machine will put
some "visible" booleans to zero... and the graphics app
will show only the installed stations.
So one can think: I create a group with image, bargraph, boxes and it's done.
I can't do this, because my app has to be general: it's the plant installer who
knows how the plant is made.
He will create the configuration file for my app (we created a Windows software
for this), specifying where (x, y) and how big the objects are.
It's the classic supervision software : as general as possible. Windows
software to visually design the plant --> configuration file --> my embedded
software
to parse it and show / animate objects.
-----------------
Coming back to the problem: instead of redrawing all the bargraph parent, IMHO
the key point could be the ability to "invalidate" only one small portion of
the parent,
the rectangular portion under the bargraph.
Bargraph::RedrawObject()
{
parent()->invalidateRect(xBar, yBar, wBar, hBar);
redraw();
}
First instruction tells the parent to redraw only the part under the bargraph,
and the second redraws the bargraph.
Obviously this is general: all objects needing some sort of transparency should
behave this way.
Thanks
Lucio
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
