manage
by Martin Owens
What is the difference between manage and Gtk::manage ?
ui/dialog/document-properties.cpp:290 Gtk::HBox *space = manage (new
Gtk::HBox);
ui/dialog/document-properties.cpp:95 _page_page(Gtk::manage(new
UI::Widget::NotebookPage(1, 1, true, true))),
Use of manage in my own code produces ‘manage’ was not declared in this
scope even when every head has been included from the dp code. very odd.
I'm also having trouble with ButtonBox:
error: no matching function for call to ‘Gtk::ButtonBox::ButtonBox()’
even with include gtkmm/buttonbox.h
What is going on?
Martin
10 years
sp-color-icc-selector.cpp
by Arshdeep Singh
Hello devs,
I want to divert your attention to the function
void getThings( cmsUInt32Number space, gchar const**& namers, gchar
const**& tippies, guint const*& scalies )
{
{_("Cyan"), _("Magenta"), _("Yellow"), _("Black"), "", ""},
--
Arshdeep Singh
Third Year, Computer Engineering
Delhi Technological University
Ph: +91-9654115614
https://sites.google.com/site/adsingh1729/home
10 years
Re: [Inkscape-devel] Inkscape-devel Digest, Vol 84, Issue 10
by Carlos Lopez Gonzalez
Hi!
Maybe you find interesting how Synfig implements the variable width along a path.
Initially Synfig tied the width controls to the stroke points so you can vary the width from control point to control point of the stroke. This is useful in many cases but produces problems for those cases where the stroke has many points and the wanted width variation is smooth from the start of the stroke to the end.
Also, when the number of control points is small and you want to have many control widths you become forced to add more unwanted control points to add variable width there.
So we came in with the Advanced Outline:
http://wiki.synfig.org/wiki/Advanced_Outline_Layer
The advanced outline responds to those questions this way:
1. How should the position of the points where the widths are defined be
described along the path?
It has two options.
a) Homogeneous: position of the width control is total length stroke based.
b) Non Homogeneous: position of the width control is based on the number of beziers and inside each bezier it is length based. So for three beziers (4 points if the stroke is open) a position of 0.5 means the middle length of the second bezier. But for four beziers (5 points if the stroke is open) a position of 0.5 means coincidence with the third control point of the stroke (regardless the length of each bezier)
2. How should the widths be defined?
We use a multiplier of the global width of the stroke. A value of 1.0 (neutral multiplier) will use the global width of the stroke. Negative values are allowed.
3. Should the widths be symmetric or asymmetric about the path?
We use symmetric. It is easy to extend to asymmetric.
4. Should negative numbers be allowed?
Yes
5. How should smoothing be done?
We use a 5th degree spline smooth function in linear combination with a linear interpolation. An extra parameter (smoothness) allows to change between full smooth to linear. Details here:
https://github.com/synfig/synfig/blob/master/synfig-core/src/synfig/value...
6. Questions about end-cap and line-join
We have discontinuities in the tangent depending on the interpolation smoothness value. When interpolation is full smooth its tangent is continuous. When interpolation is linear, tangent is not continuous.
One latest addition non mentioned in the wiki yet, is the inclusion of a internal parameter of the width control: lower and upper boundaries.
Those values (default lower=0.0 and default upper=1.0) defines how is the width control placed along the stroke.
This solution was applied when we found that the width control points moved when you extend a stroke in drawing mode. Extending the stroke implies in the worst case to increase the number of bezier points and/or the overall length of the stroke. In those cases it is impossible to keep the width control points in place, so we added the lower and upper boundaries to adjust those values when the stroke is extended to keep the width control points in place form the point of view of the old stroke (before extend). So when you extend a stroke, the width control points boundaries are modified from the defaults to the calculated values to keep them in place. For example, one width control point that is placed at a position of 0.5 from the point of view of the original stroke (at its middle of a 0.0 to 1.0 boundaires), when the stroke length is doubled, the width control point position doesn't change (it remains to be 0.5) but the boundaries goes from (0.0, 1.0)
to (0.0, 2.0).
This is very important when you deal with device inputs where the user doesn't create the stroke in one time, but in several and consecutive hand drawn strokes that are joined together in a single object.
Maybe you wonder why do we want to have a single object after the extension of the stroke: keeping one single object allows to animate the width control position along all the extended stroke without troubles, and at the same time it keeps the width control position in place after extend.
Finally, Advanced Outlines supports dashes with custom tips for each side of the dash segment and variable width within the dash segment length.
I hope those comments helps you to decide about Powerstroke and to give suggestions to SVG Working Group.
Cheers!
>________________________________
>Date: Fri, 10 May 2013 07:55:03 +0200
>From: Tavmjong Bah <tavmjong@...8...>
>Subject: [Inkscape-devel] [SVG WG] Variable width strokes
>To: inkscape-devel(a)lists.sourceforge.net
>Message-ID: <1368165303.2239.145.camel@...16...>
>Content-Type: text/plain; charset="UTF-8"
>
>
>Hi Johan and others,
>
>The SVG Working Group discussed variable width strokes last night. A
>number of questions came about how it should be implemented in SVG. As
>we have this implemented via the Power Stroke (PS) LPE it would be
>interesting to get some feedback from Johan and others about these
>topics:
>
>
>1. How should the position of the points where the widths are defined be
>described along the path?
>
> PS uses a real number where the integer part gives the node (numbered
>from the start of the path) and the fractional part the fractional
>distance between that node and the next node.
>
> The WG seems to favor defining the position using a property via the
>distance along the path defined either as a percentage of the total
>length or in absolute units. The argument is that then the same property
>could be assigned using CSS to multiple paths (e.g. a large number of
>lines that represent hair). On the other hand, having node based
>positioning would allow a use as shown in:
>
>https://people.mozilla.com/~bbirtles/variable-width-stroke/variable-width...
>
>2. How should the widths be defined?
>
> PS uses absolute user units. The WG seems to favor using a percentage
>of the stroke width. This would allow quick adjustment of the whole path
>thickness.
>
>3. Should the widths be symmetric or asymmetric about the path?
>
> PS uses symmetric widths. The WG wants to eventually allow asymmetric
>strokes but maybe not at the time.
>
>4. Should negative numbers be allowed?
>
> PS allows negative numbers. The WG seems to favor allowing negative
>strokes if asymmetric strokes are allowed.
>
>5. How should smoothing be done?
>
> PS provides four different algorithms. The WG seems to favor for the
>moment one smoothing algorithm (Catmull-Rom?) with maybe a linear
>smoothing. There was some discussion of allowing the algorithm to change
>along the path.
>
>6. Questions about end-cap and line-join:
>
> PS has discontinuities with the various end-caps. Illustrator has
>continuous edges (at least with round end-caps).
>
>Tav
>
>
>Discussion on www-svg:
>
>http://lists.w3.org/Archives/Public/www-svg/2013May/0002.html
>
>Minutes of last nights meeting:
>http://www.w3.org/2013/05/09-svg-minutes.html
>
>Illustrator end-caps:
>http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0101.html
>
>
10 years
Expand a Widget Gtk2 and Gtk3
by Martin Owens
Hey guys,
I've been struggling with getting my designed UI into code and I need
some help.
I have a Gtk::Toolbar with a few buttons a space widget and then a few
more buttons. The goal is to set h_expand on the space widget in Gtk2
and push the two sets of buttons to either side. The code for Gtk3 is
fairly strait forward but C++ isn't letting me call child_set_property
and set_expand doesn't do anything; so I'm stuck.
Code: http://paste.ubuntu.com/5655252/
P.S. I'm used to using glade, do we not use it because it's a bad dep or
because inkscape was made before glade existed?
Thanks for your help.
Best Regards, Martin Owens
10 years
Canonprinter Debian 7 and Inkscape
by Axel Richter
Hey devs,
how can i print my art with my canon out? Nothing go when i press the
printerbutton.
please help me
thanks
Axel Richter
10 years
Re: [Inkscape-devel] Something special about Cairo glyph draws?
by Krzysztof Kosiński
2013/5/8 mathog <mathog@...1176...>:
> Hi,
>
> One more question regarding cairo drawing within inkscape. I have most of
> the
> text_decoration for CSS 2 and CSS 3 implemented (for drawing, assuming it is
> already
> in the SVG; dotted, dashed, and wavy are only represented with more lines
> for the moment,
> see attachment) but cannot get the text_decoration_color field to "take".
> The color data
> gets all the way to drawing_text.cpp, where the decoration render code does
> this:
>
> ct.save();
>
> // The next call is SUPPOSED to change the pen color - it does not
> ct.setSource(
> _nrstyle.text_decoration_color.color.v.c[0],
> _nrstyle.text_decoration_color.color.v.c[1],
> _nrstyle.text_decoration_color.color.v.c[2],
> 1.0
> );
> std::cout << "DEBUG RGB {"
> << _nrstyle.text_decoration_color.color.v.c[0] << ","
> << _nrstyle.text_decoration_color.color.v.c[1] << ","
> << _nrstyle.text_decoration_color.color.v.c[2] << "}"
> <<std::endl;
>
> // code that draws underline, strike-through etc. here
>
> ct.restore();
>
>
> The output of the program shows:
>
> ...
> DEBUG RGB {0,0,0}
> DEBUG RGB {0,0,0}
> DEBUG RGB {0.25098,0.878431,0.815686}
> DEBUG RGB {0.25098,0.878431,0.815686}
> DEBUG RGB {1,0.647059,0}
> DEBUG RGB {1,0.647059,0}
> DEBUG RGB {0,0.501961,0}
> DEBUG RGB {1,0,0}
> DEBUG RGB {0,0,1}
> ...
>
> which looks to me like the colors are OK, but on the screen all of the lines
> are the same color as the text. The
> line draws are between the save and restore too, so that part is working
> properly, just not the change in color.
>
> Any idea what is wrong with this approach?
Cairo will only actually draw the pixels once you call cairo_stroke or
cairo_fill. Before then, the target surface is not modified - only the
context's path information is. If the decoration is a different color,
you need to call this operator twice - once for text and the second
time for the decoration.
One more remark; I don't think implementing this functionality
"manually" is the right approach. Pango, the text layout library we're
using, has built-in support for decorations, but for historical
reasons we are not using the layouts generated by Pango. The proper
way to add these features would be to pass along the Pango layout down
to the display tree level and then use Pango-Cairo to display it. This
would have some additional benefits, e.g. we could configure hinting
and antialiasing properties for the displayed text.
https://developer.gnome.org/pango/stable/PangoMarkupFormat.html
https://developer.gnome.org/pango/unstable/pango-Cairo-Rendering.html
Regards, Krzysztof
10 years
Seeking ideas on layer handling with symbols
by Sebastian Götte
Hi,
I'm currently working on a GSoC proposal to add PCB layout and
schematics editing capabilities to Inkscape (it's not as hard as it
sounds). In a PCB layout, you have a number of (physically stacked)
layers (one copper layer on each side of the board, possibly multiple
copper layers *inside* the board, green solder mask on both sides on top
of the copper layers and white print on top of the solder mask for
markings etc.). I'm currently unsure on how to map these layers to SVG.
It appears obvious to map these to Inkscape layers/SVG groups. This does
not work too well however, since all components on the board span
multiple layers (pads for the pins on the copper layer, cut-outs for the
pads on the solder mask and a package outline and part id/number on the
silkscreen). If a component is moved, all parts of it (on any layers)
need to be moved simultaneously, and in fact, normally it does not make
sense to even select the parts of a component individually.
My problem is that this would essentially require cross-group groups,
i.e. groups whose elements can be elements of other groups not part of
the group, which clashes with XML's tree structure.
Currently, I have two and a half ideas on how to address this issue:
1) I implement PCB layers as something different to Inkscape's layers
that is just denoted by an object property (I don't like this). This
attribute would be pretty similar to the z-order attribute that will
be include in SVG 2.
2) I find some way of "linking" multiple groups on multiple layers (I
don't like this either, it's easier but more "hackish").
I'm currently leaning towards the second option since I can imagine the
first will require a *lot* of work (though I will still look into that
further).
Perhaps you have some ideas on how this could be implemented in pre-2.0
SVG.
Thanks,
Sebastian
10 years
