On 08.12.2011 16:23, Jens Grunert wrote: > What I want to do is something very simple, in the past I wrote a program to > display millions of rectangles, each is an widget, being selectable and > completely filled with an fl_rect, with a tooltip with its name and > selectable rectangle colors (a viewer for semiconductor placements). > > I'm quite happy now with this simple and straightforward implementation since > on powerful machines it's fast enough. On this topic I did exchange > information with people from the forum. > > Now the interesting news: there are also many components with rectilinear > shapes (like L-shape, T-shape and many more). > > The easiest way - for me - would be the possibility of widgets not only > x,y,w,h but with a polygonal boundary. This would be a cool feature :-).
In the past I had some thoughts (and a partially working) implementation of widgets that can have other "child" widgets (called "sub-widgets" to distinguish them from Fl_Group's child widgets) outside their own widget boundaries. This way you could combine two rectangles to an L or T shape and maybe this could work for you. I still like the idea, but this won't happen before FLTK 3.0, so maybe in 4.0 or ... maybe never. > The second easiest way is to draw a polygon within the standard widget - > therefore were my questions below, but there is the drawback that the widget > itself is actually bigger than the physical object which creates all sorts of > problems many with select and tool tips which could show wrong object > name(s). I'm a bit stuck at the moment and thinking of the best way to > implement the polygonal objects. Some thoughts: I had a similar problem (a small puzzle program, AKA pentomino): http://en.wikipedia.org/wiki/Pentomino http://de.wikipedia.org/wiki/Pentomino It was only a test/demo version, just for fun, so it is usable, but far from complete. I decided to make the whole playing field one widget, drawing the area where to put the parts in and all the parts in the main widget's drawing method. The 12 individual pentomino's are now included in the widget as an array of structures that describe their properties (color, shape, position, rotation, etc.), and the widget's handle() method is used to pick and move the tiles. Done this way, you get an FL_PUSH event, and then your widget's handle() method has to decide, which one of the individual parts has been clicked, if any. Same for moving and drawing. That's how I would (try to) do it in your case too, but this is maybe somewhat like a complete rewrite of the internal implementation logic. Con: lot of work, maybe, depending on what you need to implement. Pro: probably much faster, since you can optimize the widget's handle() method depending on your knowledge of the internal structures, whereas a FLTK group widget with lots (really millions?) of children tends to become slow WRT event handling and maybe also drawing. Back to your "drawing rectangles" question: in such a simple case it should be straightforward, if you don't need complex rotation or similar. In my case I could combine always 5 simple squares to draw one pentomino, and the coordinates are directly available (so I used them literally, without a matrix, i.e. no translation, rotation, or anything else). Drawing a nice border might be more difficult to do. Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
