Version: 0.10.5 (using KDE KDE 3.5.3)
Installed from: Gentoo Packages
I discovered Kig some days ago and really like it. Till now I always used XFig for drawing geometrics, but Kig is much more convenient, so thumbs up. But one thing is bothering me:
If you draw some polygons which overlap, you cannot distinguish them visually. Let's say you have this figure:
| r1 |
| +---------+ |
| | r2 | |
| | | |
| | | |
+--+----+-+ | |
| | +-+-------+ |
| r3 |
Even if you fill all rectangles with different colors, r1 will completely cover r2 and the intersection of r3 and r1 is not visible, too. Same with (r1 intersection r2 intersection r3).
It would be great if the intersected areas were colored with the color you get by mixing the colors of the participating polygons.
Another approach would be to let the user add textures (stripes (///, \\\, ||| or ---), dots, etc.) to the polygons, so that you can distinguish intersections by looking at which textures they have.
Even another approach: Add layers to the objects. But that's not a very good solution, because then you would have no way to make intersections visible. You only could select the visible participant...
I'll attach a sample file, which has the 3 overlapping polygons mentioned above. In this example file the inner polygon r2 is not covered, but I'm sure I draw a similar figure before and the inner polygon was covered. I guess it depends on the order of drawing...
Created attachment 16954 [details]
the figure with the 3 overlapping polygons
> Even if you fill all rectangles with different colors, r1 will completely
> cover r2 and the intersection of r3 and r1 is not visible, too. Same with
> (r1 intersection r2 intersection r3).
This happens only with polygons, though. If you draw a line over the polygons,
it will be visible through them.
> It would be great if the intersected areas were colored with the color you
> get by mixing the colors of the participating polygons.
Calculating the intersected areas of two polygons is not a trivial task.
The "mixing" colour could be archived by playing a bit with the alpha channel
of the polygon brush. I should experiment a bit and see what happens...
> Another approach would be to let the user add textures (stripes (///, \\\,
> ||| or ---), dots, etc.) to the polygons, so that you can distinguish
> intersections by looking at which textures they have.
This can be a nice idea. It wouldn't fix the problem when using a plain color
to draw the polygon, though ;)
> I'll attach a sample file, which has the 3 overlapping polygons mentioned
> above. In this example file the inner polygon r2 is not covered, but I'm
> sure I draw a similar figure before and the inner polygon was covered. I
> guess it depends on the order of drawing...
True. Actually it depends on the order when drawing.
>> Even if you fill all rectangles with different colors, r1 will
>> completely cover r2 and the intersection of r3 and r1 is not visible,
>> too. Same with (r1 intersection r2 intersection r3).
> This happens only with polygons, though. If you draw a line over the
> polygons, it will be visible through them.
Ah, now I've found "Sides of a Polygon". At least that's a good workarround.
But then there's another thing: Now I try drawing all sides of all polygons
and fill them with the color "#FFFFFF" (white). As an effect the labels
inside the polygons get grayed out the more they are covered. So to get this
work properly it would be good to have polygons without any fill color, thus
making them transparent.
SVN commit 611416 by pino:
Improve the polygon drawing: instead of painting them with a semi-dense pattern, use an alpha value for the brush color so it's really possible to see through them.
(In http://img82.imageshack.us/my.php?image=tmp44tt3.png compare Kig/Qt3 (above) with Kig/Qt4 (below).)
Can not be in Kig/Qt3 due to Qt3 limitations.
M +17 -2 misc/kigpainter.cpp
M +5 -0 misc/kigpainter.h
M +1 -0 objects/object_drawer.cc
--- trunk/KDE/kdeedu/kig/misc/kigpainter.cpp #611415:611416
@@ -52,7 +52,8 @@
mdoc( doc ),
msi( si ),
mNeedOverlay( no ),
- overlayenlarge( 0 )
+ overlayenlarge( 0 ),
+ mSelected( false )
mP.setBackground( QBrush( Qt::white ) );
@@ -277,6 +278,11 @@
+void KigPainter::setSelected( bool selected )
+ mSelected = selected;
static void setContains( QRect& r, const QPoint& p )
@@ -293,7 +299,10 @@
QPen oldpen = mP.pen();
QBrush oldbrush = mP.brush();
- setBrush( QBrush( color, Qt::Dense4Pattern ) );
+ QColor alphacolor = color;
+ if ( !mSelected )
+ alphacolor.setAlpha( 100 );
+ setBrush( QBrush( alphacolor, Qt::SolidPattern ) );
setPen( Qt::NoPen );
// i know this isn't really fast, but i blame it all on Qt with its
// stupid container classes... what's wrong with the STL ?
@@ -306,6 +315,7 @@
mP.drawPolygon( t, fillRule );
setPen( oldpen );
setBrush( oldbrush );
if( mNeedOverlay ) mOverlay.push_back( t.boundingRect() );
@@ -459,6 +469,11 @@
return 20 * pixelWidth();
+ mSelected = false;
void KigPainter::pointOverlay( const Coordinate& p1 )
Rect r( p1, 3*pixelWidth(), 3*pixelWidth());
--- trunk/KDE/kdeedu/kig/misc/kigpainter.h #611415:611416
@@ -71,6 +71,7 @@
+ bool mSelected;
* construct a new KigPainter:
@@ -110,6 +111,8 @@
void setFont( const QFont& f );
+ void setSelected( bool selected );
QColor getColor() const;
bool getNightVision( ) const;
@@ -284,6 +287,8 @@
+ void unsetSelected();
--- trunk/KDE/kdeedu/kig/objects/object_drawer.cc #611415:611416
@@ -38,6 +38,7 @@
p.setStyle( mstyle );
p.setPointStyle( mpointstyle );
p.setFont( mfont );
+ p.setSelected( sel );
imp.draw( p );