dia_improved

Fork

More tooltips for toolbar actions

Let substitute also preserve pattern

With Convert to Path as the main user of object_substitute transfer
also the pattern property. Define PROP_STD_PATTERN for the prop
description to be shared with objects and the substitute property
description.

Fix path_build_arc() and implement DiaPathRenderer:draw_rounded_rect()

Together this fixes two main issues open with convert-to-path.

dxf: remove superfluous DiaRenderer prototypes

not necessary if *_renderer_class_init() comes after the renderer
function implementations it is referencing.

cgm: remove superfluous DiaRenderer prototypes

not necessary if *_renderer_class_init() comes after the renderer
function implementations referencing them.

Fix DiaCairoRenderer::draw_rounded_rect() to use fill color

Fix signature of DiaTransformRenderer::draw_polygon()

also the change the internal _polygon() calls color order

DiaRenderer: refine set_linestyle to also contain dashlength

These two parameter are closely related, just fixed a bug where the line style was set
without the dash length being set (i.e. still zero). Instead of putting all the burden
on the renderer's site, just give both parameters at once.

DiaRenderer::draw_arc() and fill_arc() now preserving direction info

The previous definition of Dia's draw/fill-arc was basically following
the definition coming from GDK as follows:

'''
width: the width of the bounding rectangle.
height: the height of the bounding rectangle.
angle1: the start angle of the arc, relative to the 3 o'clock position,
counter-clockwise.
angle2: the end angle of the arc, relative to angle1

Draws an arc or a filled 'pie slice'. The arc is defined by the bounding
rectangle of the entire ellipse, and the start and end angles of the part
of the ellipse to be drawn.
'''

In contrast to GDK where angle2 is always greater than angle1 Dia's now
only uses the counter-clockwise rule requiring the backend code to do
it's own calculations.

The previous approach had shortcomings when backends are actually
interested in the direction of the arc. One such example is cairo,
which could use cairo_arc() and cairo_arc_negative().
If a more complex construct like a path for a rounded rectangle is done
the direction information becomes crucial to have a continuous path for
proper filling. The same issue can be observed with recently added
facilities like DiaPathRenderer and it's convert-to-path use.

Renderer core changes
- gdk: counter-clockwise
- import: direction preserving with big_arc and clockwise flags
- path: XXX: still something wrong with rounded poly-line arcs
- svg: now using directed arcs
- transform: using path_build_arc() which migh be the XXX from above;)
Renderer plug-in changes:
- cairo: now using directed arcs, also resurrecting draw_rounded_rect
- cgm: counter-clockwise
- drs: no change (now using directed arc rendering)
- dxf: counter-clockwise
- hpgl: counter-clockwise
- libart: counter-clockwise (by line approximation as before)
- metapost: already handled preserving arc direction
- pgf: counter-clockwise
- ps: counter-clockwise
- pstricks: counter-clockwise
- python: pass-through to plug-ins
- diadisect.py: warn about angle difference being greater than 360°
- diasvg.py: direction preserving
- diastddia.py: direction preserving (removing FIXME from 2009)
- export-renderer.py: no change, just pass-through
- vdx: preserving direction (by control angle)
- wmf: counter-clockwise
- wpg: counter-clockwise
- xfig: arc direction preserving

BPMN: optimize to combine fill and stroke

also removed some superfluous extra lines which apparently where just
added to get connection points from them.

Misc - Ngon: special handling for Hexagram and more

Drawing a crossing star take a little more points to be properly filled
if the number of rays and windings are not relatively prime. Some more
code needed to do that for {n/3} and higher.
See http://en.wikipedia.org/wiki/Star_polygon for more details.

Assorted - Left-Up Arrow: fix main point again

accidentally reverted with the fix with combine fill and stroke

Misc - Ngon: add density parameter for mote star variants

The n-gon density value depends on num_rays. Only a limited set of values
can be supported, where min/max/step is not enough to reflect it.
So this object is the first user of PropEventHandler to keep density in
valid range (or better it's edit control).

Prefer gtk_adjustment_configure() over new/set pattern

Previously Property::reset_widget() was creating and setting a new
adjustment object to reconfigure value and range. This might have been
the easiest way before gtk_adjustment_configure() was available with
GTK+ 2.14. But with the access pattern for PropEventHandler (next
commit) the recreation caused problems because of signals to already
destroyed objects. The easiest way to overcome that was the switch to
gtk_spin_button_get_adjustment() / gtk_adjustment_configure().

Misc - Ngon: new object for regular polygon or star

A basic object to draw a regular polygon. Based on the given number of 'rays'
three different interpretations are possible: a regular polygon, a star
with the same number of edges but crossing; a concave polygon doubling the
total number of points.

Prepare DiaRenderer::draw_arc() to be refined

- some comments to make the following change more easy
- arc-definition.dia: sketching the current and future behavior
- arcs.dia: dedicated test file for current arc usages

svg: remove superfluous "fill:none" from style attribute

with draw/fill functions being merged it is only consequent to also merge
towards DiaSvgRenderer::get_draw_style()

standard: further optimization of DiaRenderer calls

- "Standard - Arc" uses draw_arc for the simple case to avoid
impreciseness caused by gap calculations
- "Standard - Box", "Standard - Ellipse" need only once call, even
with pattern fill active

cgm: fix image export to CGM

CgmRenderer::draw_image() was creating skewed images during export.
Now it does works on the already existing pixel data (no RGB data copy)
and creates the required alignment.

cgm: replace magic numbers with named constants

No behavior change intended nor observed. There is no effect on the
exported files.

Updated Spanish Translation

diasvg.py: merging fill and stroke broke ellipse

just a single space missing

Finnish translation update

Updated German translation

Updated Czech translation

Updated Serbian translation

Add (not yet full) Hebrew translation

Signed-off-by: fr33domlover <fr33domlover@riseup.net>

DiaRenderer: fix draw_ellipse() in bindings/

DiaRenderer: replace fill_polygon with extended draw_polygon

What started with draw_beziergon() is continued with fill_ellipse(): merge
two calls into one to get rid of superfluous drawing commands and arbitrary
object splits.

To reduce the risk of breaking file formats not yet tested the following
pattern is sometimes used:
- rename draw_ellipse to stroke_ellipse
- keep fill_ellipse as local function
- make new draw_ellipse call one or both for fill and stroke parameter
As a result the output of these exporters wont change at all.

Not yet optimized are: PGF, VDX, XFig

Also not optimized, but more simple are: GDK, Cairo, DXF, HPGL, LibArt, PS,
Pstricks,

Optimized to fill and stroke in one step are: Import, Path, SVG, Transform,
DRS, Metapost, diadissect.py, diastddia.py, diasvg.py, PyDia, Shape, WMF,
WPG

Fully optimized shape rendering for all objects except with active pattern.

PyDia: fix wrong cast to Diagram* were DiagramData* (now really)

PyDiaDiagramData_GetAttr() can deliver attributes from Diagram and
DiagramData. In the stand alone or command line case these are not
necessarily the same. E.g. file conversion is usually only done
with DigramData.