Inkscape scripting API (Draft)
by Glimmer Labs
Here is the first draft of a Dbus based Inkscape scripting API:
http://www.cs.grinnell.edu/~bergsore/inkscapeDbusRef.html
(Many thanks to the ConsoleKit team for the scripts and build system I
used to generate this documentation.)
I would welcome any comments or criticisms, the interface is very much
still up in the air so any suggestions, from small changes to major
issues, would be welcome.
I would particularly like to hear if people think that this would
potentially support the ways in which they use Inkscape, or whether
there are use cases this doesn't address. If there are lots of uses
that this interface does not support, additional interfaces geared
towards different users could be added. (In fact there was originally
one more interface than there is now, see document_new() for details.)
If you like the current API (in general) feel free to suggest
additional functions or functionality.
Finally, how would you like to see this extended? Dbus has proven to
be quite responsive and robust for this application. How would you
build off the basic platform of the Inkscape application interface?
I will keep the posted link updated as I make changes based on peoples feedback.
-Soren
13 years, 9 months
Cross software User Interface
by Brian Vidal
Hi there, we are starting a huge project in order to take advantage of some
applications UI re-design: we want to make a huge UI redesign in the best
opensource design, authoring and media creation/edition software.
The need to do this is essentially, to provide a cross UI between all major
media-related software.
This way we can make all media-related software in the open source world to
have the same and effective User Interface, so the user can work more
tightly between applications and we can collaborate to each other.
The project is just starting, and we want to put all of our effort to
design, develop and migrate to a efficient, fast and beautiful User
Interface.
Please, think on it.
As a starting point
https://launchpad.net/linux+design+studio<http://www.launchpad.com/linux+design+studio>
Hoping to make the big jump in the community.
Best regards. dael99 (Brian Vidal)
--
Brian Vidal
13 years, 9 months
GSoC 2009 - Time to wrap things up
by Joshua A. Andler
Hey GSoC students and mentors,
I just wanted to give a reminder of the schedule for GSoC.
Students, today is the pencils down date. Please make sure that your
mentor has access to your work today. You do have one week (until the
24th) to do any tweaks or code cleanup, but you should effectively be
done at this point. Please be respectful of your mentors and don't force
them into doing a last second evaluation. Also, if you are planning to
use the additional time for more work, please do communicate that with
your mentor.
Mentors, evaluations can begin starting today and are due on August
24th. No need to rush as I'm sure we'll see some changes trickling in
still.
That's all for now.
Cheers,
Josh
CCing dev list so everyone know where we're at.
13 years, 9 months
SPEventContext stops receiving button1 press/release events
by Arcadie M. Cracan
Hello,
I don't really understand what I am doing wrong. I have a button on the
toolbar of the connector tool (InkAction) that, when gets pressed, basically
creates a new knot that follows the mouse pointer.
At this point (after the button is pressed) SPEventContext (for the connector
tool) stops receiving any button1 press/release events. Other buttons
press/release, pointer motion events are received.
I don't even have a clue for where to start debugging, please help.
Thank you.
Following are some code exerpts:
from toolbox.cpp:
===========
...
g_signal_connect_after( G_OBJECT(inky), "activate",
G_CALLBACK(sp_connector_new_connection_point), holder );
...
static void sp_connector_new_connection_point(GtkWidget *widget, GObject *tbl)
{
SPDesktop *desktop = (SPDesktop *) g_object_get_data( tbl, "desktop" );
SPConnectorContext* cc = SP_CONNECTOR_CONTEXT(desktop->event_context);
if (cc->mode == SP_CONNECTOR_CONTEXT_EDITING_MODE)
cc_create_connection_point(cc);
std::cout<<"Done new connection point."<<std::endl;
}
...
from connector-context.cpp
==================
...
void cc_create_connection_point(SPConnectorContext* cc)
{
if (cc->active_shape && cc->state == SP_CONNECTOR_CONTEXT_IDLE)
{
if (cc->selected_handle)
{
cc_deselect_handle( cc->selected_handle );
}
SPKnot *knot = sp_knot_new(cc->desktop, 0);
cc_select_handle( knot );
cc->selected_handle = knot;
cc->state = SP_CONNECTOR_CONTEXT_NEWCONNPOINT;
}
}
...
Regards,
Arcadie Cracan
13 years, 9 months
Re: [Inkscape-devel] Re : Re : Extracting a saturation map with SVG filters ?
by Jasper van de Gronde
I've attached two files which show how to replace the hue of an image
with a "hard-coded" hue and the hue from a different image (a gradient
in this case), respectively.
Ivan Louette wrote:
> Sorry for no replying earlier !
>
> Thanks for the link and the explanations ! However at the moment I lack
> a lot of technical skills I am afraid... I would have time to learn
> programming but I must concentrate on my main project - writing a novel
> - which progresses too slowly these months. This week end I was very
> busy at cleaning the code of filters.svg ; the result (already
> spectacular this evening) will be commited on SVN probably tomorrow in
> the evening when I will have finished. Then I would concentrate on the
> french filters doc (this is my mother language) I began some weeks ago
> on Floss Manuals.
>
> Have a nice week,
>
> ivan
13 years, 9 months
Preparing for Feature Freeze
by Joshua A. Andler
Hey All,
It appears that the Frost is nearing completion, and the Feature Freeze
will be setting in soon. Given this, it's probably a good time to start
putting together a list of release blocker bugs, as well as discuss if
any features need to be pruned due to them being incomplete.
For reference, here are the bugs that are still milestoned for 0.47:
https://edge.launchpad.net/inkscape/+milestone/0.47
Is anyone aware if there currently any major platform specific bugs like
we had around 0.46? (win32 printing issue is what I speak of)
Also, JonCruz, should we hold back the "Auto" swatch palette from this
release?
At this point I want to again remind people to ensure that the release
notes are as up-to-date as possible! Please take a moment to ensure that
your improvements/enhancements/new features are all mentioned with a
brief explanation where necessary.
Thanks to everyone for your contributions!
Cheers,
Josh
13 years, 9 months
Better hrefs
by Krzysztof Kosiński
Hello all
Currently we have some handling for hrefs (in the form of
Inkscape::URIReference). It provides some signals and callbacks, but doesn't
do everything that I would like it to. To be specific, there are several
places when solving the following problems efficiently would be a great
thing:
1. Given an object, iterate over all references to it.
2. Given an object, iterate over all objects it refers to.
Point 1 is useful for all sorts of things: marking objects for update,
compensating clones, deletion, vacuum defs, etc. Point 2 would allow to
remove 80% of clipboard code, and implement robust ID changing and clash
prevention (which means, one that doesn't have to be updated whenever a new
href-like attribute is added).
Here is my idea. We define a three-way smartpointer that looks like this:
class ObjectRefBase {
...
SPObject *obj;
ObjectRefBase *next;
ObjectRefBase *next_ref;
};
template <typename T>
class ObjectRef : public ObjectRefBase {
...
};
template <typename T> ObjectRef<T> const &getRef(T *obj) {
return static_cast<ObjectRef<T> const &>(*obj);
}
The 'next' and 'next_ref' pointers form a singly-linked cyclic lists. Each
SPObject contains such a smartpointer (by protected inheritance: 'class
SPObject: protected ObjectRefBase, ... {') that can be accessed using the
getRef function, which is a templated friend of SPObject and returns an
ObjectRef of correct type. The header of both lists is the pointer contained
in the referenced object; it has 'obj' set to itself. 'next' allows us to
iterate over references to this object, while 'next_ref' - over references
contained in this object. The constructor might look like this:
ObjectRefBase(SPObject *owner) {
if (owner == this) {
obj = this;
next = this;
next_ref = this;
} else {
next_ref = owner->next_ref;
owner->next_ref = this;
obj = NULL;
next = NULL;
}
}
If this is the embedded instance from protected inheritance, the the first
test will be true and both lists will be initialized as empty (an empty
cyclic list is represented by the header node having a next pointer pointing
to itself). The assignment operator is as follows:
ObjectRefBase &operator=(ObjectRefBase const &other) {
if (obj != NULL) {
ObjectRefBase *cur = this;
while (cur->next != this) cur = cur->next;
cur->next = obj->next;
}
next = other.next;
other.next = this;
}
If the reference pointed to some object, the function walks the list and
removes the reference from the linked list of the previous object; it then
inserts itself into the linked list of the new object. The destructor works
similarly:
~ObjectRefBase() {
ObjectRefBase *cur = this;
while (cur->next != this) cur = cur->next;
cur->next = obj->next;
cur = next_ref;
while (cur->next_ref != this) cur = cur->next_ref;
cur->next_ref = next_ref;
}
Now we can iterate over the references to an object like this:
for (ObjectRefBase *cur = this->next; cur != this; cur = cur->next) {
// do something with each reference to this object
}
And over references contained in an object like this:
for (ObjectRefBase *cur = this->next_ref; cur != this; cur = cur->next_ref)
{
// do something with each reference stored in this object
}
Testing whether the object has any indirect references is dead simple: this
== next. Same for checking whether this object refers to anything: this ==
next_ref. The owner of a reference can be retrieved in linear time (by
walking next_ref until we encounter next_ref == obj). All this of course can
be encapsulated into a nice STL-like iterator interface which provides some
extra type safety not present in ObjectRefBase (for example, we know that
all ObjectRefs which we can reach via 'next' point to the same type).
Handling CSS properties with URI references that are not members of the
object is easy as well: ObjectRef doesn't need to be a member of the owner
for all this to work. There are no boilerplate attach() / release() methods:
the assignment operator of ObjectRef takes care of everything.
If walking the lists during reassignment and destruction turns out to be a
performance problem, we can make both lists doubly-linked rather than
singly-linked, where a node can be removed in constant time, at the price of
2 more pointers stored in each reference. Fast owner retrieval additionally
requires storing the owner pointer. This gives 5 pointers of overhead, so
for 10000 references on a 64-bit machine we get 390KB of overhead - should
be manageable. I thought about a trick that can be used to implement
constant-time erase on a cyclic single list (the iterator actually points
one node before and we use cur->next->value to get the value), but it can't
be applied here.
Why this is better than keeping pointers to the references in std::list or
std::vector?
- no memory allocations when adding a reference = better performance.
- removing a reference is much simpler, because finding it in the list is
not needed.
- signals can be put in the ObjectRef class.
- simple and elegant implementation.
What do you think? Improvements and discussion welcome.
Regards, Krzysztof
--
View this message in context: http://www.nabble.com/Better-hrefs-tp24939304p24939304.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
13 years, 9 months
Live path effects - better XML representation
by Krzysztof Kosiński
While rewriting the node tool I necessarily had to look into path effects.
Live path effects are currently seem to be represented by a single svg:path
that has information on what the original path looked like in the
inkscape:original-d atribute, the applied effects in another attribute, and
additional. I think this is not very flexible, because it does not allow for
example nondestructive boolean operations where both operands are other path
effects. What do you think about this representation:
1. A live path effect is represented by an svg:switch element. An
Inkscape-specific attribute can be added to it to simplify implementation,
but it is not really necessary.
2. The first element in that svg:switch is an inkscape:path-effect element
that contains all the information about objects it was generated from. Shape
parameters are represented as inkscape:path-effect-param elements that can
contain anything including svg:use, svg:rect, svg:path, another
inkscape:path-effect etc. This could allow very nifty things like live
boolean operations. It would also simplify the node editor, because it could
just operate on the invisible children of inkscape:path-effect while being
completely unaware of path effects. As bonus points, path effects created
from rectangles, circles, spirals, etc. could preserve the editing
capabilities of those shapes.
3. The second element would be an svg:path that contains the result of the
path effect, style properties, etc.
4. When opening the file in Inkscape, it would only look at
inkscape:path-effect and recompute the fallback svg:path whenever something
changes. When opening in another SVG viewer, it would only display the
svg:path.
5. To handle live boolean operations, there would be an additional parameter
for shapes that says whether they are 'live'. If a shape is 'live', all
boolean, offset, etc. operations would create path effects instead of paths,
similar to how linked offset works now. In fact, the destructive versions
could be implemented as a combination of creating a path effect and an
object-to-path conversion.
6. Path parameters would accept any SPShape. There would be a separate type
of parameter that accepts a group of shapes. To convince an effect to accept
an object group as a parameter, a special effect called Flatten Group would
be provided - it would convert a group into a path effect suitable for use
as a parameter for another one, and could optionally use a clone rather than
the original for flattening.
Now some use cases:
1. To create an outline of some collection of objects, we create clones of
them, group them, apply Flatten Group and then Offset. Result: whenever any
of those objects is moved or modified, the outline updates.
2. The sun and cloud example in
http://wiki.inkscape.org/wiki/index.php/Lpe-blueprint would be dead simple:
create the circle and the sun ray, use pattern along path; create a clone of
the cloud, make it 'live', create an offset; then apply a live subtraction
between the sun and the clone. Updating any of the original shapes will now
change the appearance. (As a related note, compensation on moving should not
be a global property, but a property of the clone! As demonstrated here, we
want the invisible clone used for the path effect to move with the cloud,
but we want other visible clones to stay where they are when the original is
moved)
UI changes: The LPE stack would need to be changed into an LPE tree like the
layer dialog. The path effect tool would allow the editing of various
parameters using control points and the node editor; selecting an item in
the tree would cause its editing controls and toolbar to appear. Live path
effects would be created from a menu rather than from the tool, like dynamic
offset.
Internal changes: SPLPEItem would be removed, and SPShape would be used as
the type of object that can be used as a path parameter.
What do you think? I think when done this way, path effects (or maybe they
should be called Vector Effects, because they're not really limited to
paths?) provide a generic vector equivalent to filtering. This means they
could become super-powerful, and in fact the main method of editing complex
drawings. There would be some problems with legacy live path effects, but it
can be dealt with at document load.
PS I just noticed this is somewhat similar to the vector effects proposal in
SVG 1.2. It might be wise to plan ahead and make it easy to optionally store
some path effects as an SVG 1.2 vector effect.
Regards, Krzysztof
--
View this message in context: http://www.nabble.com/Live-path-effects---better-XML-representation-tp247...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
13 years, 9 months
Bug Hunt passes 500!
by Tavmjong Bah
The current bug hunt tally is now 507/500. We have reached the mark!
Newly fixed bugs:
6 379977 buliabyak Imagemagick Raster extensions not working
3 308183 JazzyNico Measure Path text shifted when used with a copied object
6 168780 Papouin 0.45 on winxp: Mouse not properly captured..
6 373309 A. Johnson Print has offset on page
12 166678 A. Johnson Paper size or orientation are not used when printing
9 304018 buliabyak Crash when using LPE with node tool selected
3 407893 buliabyak Text Tool attributes messed up.
9 376068 buliabyak Inkscape 0.46_5 Segmentation fault on gradient edit
Top Bug Hunters (With 30 or more points):
120 van Lierop
57 theAdib
45 Bulia Byak
36 JazzyNico
33 T. Holder
30 Jon A. Cruz
Special Mention for most active bug reviewing: ~suv
Tracked at:
http://wiki.inkscape.org/wiki/index.php/Release_Info_for_0.47
Tav
13 years, 9 months
Quick File Import Test
by Tavmjong Bah
Hi,
I just did a quick File Import Test. I did not test all possibilities.
Here are a couple problems:
1. .wmf There are two options. One via Uniconverter and the other from
GDK. Do we need both?
2. Images in PDF appear to be imported upside down.
Tav
13 years, 9 months
