Re: [Inkscape-devel] New contributor (we have new code!) that we need to help
Hi,
Thank you so much for the very warm welcome! I look forward to working with you and contributing more code upstream!
Josh, I subscribed to the mailing list, but for some reason I haven't been getting emails from it... I tried to resubscribe, hopefully that works!
Tav, that sounds like a fantastic birthday party! I've done quite a bit of looking into the internal workings of SPObjects when I created the objects dialog, and I think I have a decent understanding of how everything is updated, but it does get very confusing due to gobject obscurities... If it would help out, I can take a closer look into this and start documenting the process so that it will be easier to work with in the future.
When I created the objects dialog patch to submit upstream, I went through my code, added comments, reorganized, and fixed as many bugs as I could find. The blurring crash that you're referring to is most likely due to a linked-list error, which I also encountered in my testing and hopefully fixed in the patch. I also reworked styling the buttons, so the up/down arrows should hopefully now have tooltips (although it may still be unclear as to what they do, so a more descriptive tooltip may be needed).
The random hiding of objects with drag-and-drop appears to be a weird side effect of the workaround for supporting multiple items. To fix this, I added a flag in the patch which gets set if the mouse-down event occurs over the visible column. When the mouse is released, if this flag is not set the visibility toggle will not be triggered. In my tests, it seemed that only the visibility column was being triggered, so I didn't add flags for the other columns, but they could easily be added if issues pop up in the future.
In the latest Ponyscape release, there is an issue with re-selecting items when they've been moved via drag-and-drop that causes a lot of assertion errors (which may be the errors that you were seeing). I store the source SPItems in a vector, which I iterate over and move on a drop operation. I was also using this vector to select the items post-move, but they no longer referred to the correct SPItem (due to how SPObjects are built and moved). In the patch, I now store the ID's of the items before they're moved in a different vector and use that for fetching and selecting the items after the move.
Moving items between layers and into and out of groups is currently only able to be done through drag-and-drop... It would be possible to add buttons similar to the XML editor, but that may overcrowd the UI. This functionality could also be added to the right-click menu, which might be a better solution. You can already group and ungroup items using the right-click menu (along with clipping and masking items).
If you notice anything else or have any suggestions on improving things, let me know and I'll take a look into it!
I am planning on doing the same process of reviewing, commenting, and bugfixing my code before creating a patch for the tags dialog, and will definitely be sure to keep in mind all of the points you brought up about it. In the top revision of Ponyscape I have already added the ability to rename objects in the tags dialog, and I will look into the rest of the items that you have brought up!
I may eventually move Ponyscape development into a branch on launchpad... For the time being I am using a repository on a local server, which has been working out so far, but I can definitely see where it would be beneficial to have a public branch as well. Looking forward to working more with the development team!
Ted Janeczko On Tue, Mar 19, 2013 at 12:13 PM, Josh Andler <scislac@...400...> wrote:
I'm sending this to you only because I don't know that you've subscribed to our developer list yet. :)
---------- Forwarded message ---------- From: Tavmjong Bah <tavmjong@...8...> Date: Tue, Mar 19, 2013 at 6:27 AM Subject: Re: [Inkscape-devel] New contributor (we have new code!) that we need to help To: Josh Andler <scislac@...400...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net
Hi,
First, let me say this really sounds great! Welcome Ted! I could have used Ponyscape a couple of months ago when I was preparing a Pony party for my older daughter's sixth birthday. The guests played pin the horn on Fluttershy and the birthday cake was a Pony Carousel.
Here are some random thoughts:
Let's be honest, 0.49 isn't going to happen soon. There is no sign that anybody is tackling the bitmap scaling problem from either the Inkscape or the Cairo side. And even if Cairo were to have the API's needed today it will be awhile before there is a Cairo release with them.
Given that, I don't think we need to be overly worried about changes to the Inkscape code base. (But I do think new features should be reasonably complete.)
I am intrigued by Ted's comment about using an XmlNodeObserver for handling updates. It would be good to have someone really understand how updates are handled by Inkscape. When I put in random print statements I often see the same code being executed multiple times when it should only be executed once. We seem to have quasi-circular loops going on.
Playing with the Object dialog in Ponyscape:
- Blurring an object crashes Ponyscape.
- It's not clear what all the icons are for... no tooltips. What are
the up/down icons for?
- Clicking on the "domino" shaped icon brings up a color picker which I
can't seem to get rid of. I have to restart the program.
- Layers and objects seem to be randomly hidden when dragging them up
and down.
- Can't move objects between layers using arrows.
- Not easy to move objects into and out of groups (like in the XML
editor).
- I see lots of error messages.
In summary, it's a good start but needs polishing before merging (note: I haven't tested the patch, just Ponyscape).
Playing with the Tagging dialog:
- Needs tooltips or other hints on how to use.
- The items list is auto opened... maybe should also be auto closed?
- Would be useful to be able to rename objects in dialog.
- Might be good to integrate with symbols dialog (create custom symbols
from tagged objects).
If Ted plans on submitting patches routinely, it might make sense for him to keep his code repository as a branch of Inkscape. It would make it easier to follow his work.
Tav
On Tue, 2013-03-19 at 00:18 -0700, Josh Andler wrote:
Hey all,
I submitted a new "report" based around a patch submitted from the primary developer of Ponyscape (an Inkscape derivative project focused on making life easier for artists interested in creating My Little Pony fan art).
Check out the first new patch he has submitted upstream at: https://bugs.launchpad.net/inkscape/+bug/1157024
I've talked with him a bit and he's really doing some good work at a rapid pace, but as we know, we don't have the same leeway upstream to add features that may change on a regular basis. So, he sees Ponyscape as a good testing ground to let things have some time to mature and ripen and then he will submit patches upstream. He also doesn't want to step on any toes or anything.
That first patch is for a long awaited feature. If others would be willing to test and do some code review, it will help us to establish a tighter relationship with Ted. He's already met the 2 patch requirement and has commit access, but he really wants feedback and to get things right before stuff is committed.
My guess is with the amount of divergence and level of changes he makes, this patch vs direct commit paradigm might be around for a while (he has a lot of irons in the fire for new/improved features). My view is that I don't mind doing this side of things provided other devs will be willing to help test and give feedback.
Cheers, Josh
Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mar 19, 2013, at 12:01 PM, Ted Janeczko wrote:
Hi,
Thank you so much for the very warm welcome! I look forward to working with you and contributing more code upstream!
Josh, I subscribed to the mailing list, but for some reason I haven't been getting emails from it... I tried to resubscribe, hopefully that works!
Tav, that sounds like a fantastic birthday party! I've done quite a bit of looking into the internal workings of SPObjects when I created the objects dialog, and I think I have a decent understanding of how everything is updated, but it does get very confusing due to gobject obscurities... If it would help out, I can take a closer look into this and start documenting the process so that it will be easier to work with in the future.
Hi, great to see you around and the stuff coming in.
I know that there is a lot of work needed to clean up things better in our somewhat ancient codebase (some of the update cycles caused problems for the layer dialog too).
I wanted to toss out two main hints:
First, we probably need to get the update flow explicit and then cleaned up. Things were originally better separated, but since there is a quite a lot of complexity to how things were implemented, latter developer was more easily confused. I've touched up a little of it in a few places, but an overall fix is in order.
The second item is that we're at the point where we can really benefit from a "resource manager". This needs to be a central thing to track potential external items such as CSS, color palettes, symbols, placed or embedded images, fonts, etc. Right now each has its own way of doing things, and we are losing a lot of processing to inefficient update mechanisms.
Once the weekend rolls around I'll have more time to look at things in general, and at any cleanup that might still be needed to get the patches in.
Thanks again!
On 19-03-13 20:01, Ted Janeczko wrote: ...
Tav, that sounds like a fantastic birthday party! I've done quite a bit of looking into the internal workings of SPObjects when I created the objects dialog, and I think I have a decent understanding of how everything is updated, but it does get very confusing due to gobject obscurities... If it would help out, I can take a closer look into this and start documenting the process so that it will be easier to work with in the future.
I looked at this some time ago, and one of the main issues is that we constantly keep around the XML (text) representation of attributes. So you update some internal path representation, which triggers an update of the XML, which triggers an update of the internal path representation. (I don't remember how we actually avoid an infinite loop.) This not only causes immense slow-downs, but also causes a loss of precision when doing several transformations in sequence for example. So any clarification on how this mechanism works exactly would indeed be hugely appreciated.
On Mar 20, 2013, at 1:28 AM, Jasper van de Gronde wrote:
On 19-03-13 20:01, Ted Janeczko wrote: ...
Tav, that sounds like a fantastic birthday party! I've done quite a bit of looking into the internal workings of SPObjects when I created the objects dialog, and I think I have a decent understanding of how everything is updated, but it does get very confusing due to gobject obscurities... If it would help out, I can take a closer look into this and start documenting the process so that it will be easier to work with in the future.
I looked at this some time ago, and one of the main issues is that we constantly keep around the XML (text) representation of attributes. So you update some internal path representation, which triggers an update of the XML, which triggers an update of the internal path representation. (I don't remember how we actually avoid an infinite loop.) This not only causes immense slow-downs, but also causes a loss of precision when doing several transformations in sequence for example. So any clarification on how this mechanism works exactly would indeed be hugely appreciated.
I think the short answer how it works is:
"It doesn't"
There are some 'interesting' work-arounds in place with various toggles being set to try to stop loops, but we really need to improve the overall situation.
Much of this has been in place since quite early days, but you do seem to have summarized the main issues. There are also some issues with timing in regards to subsets of one of the two trees getting disconnected as they are being worked on.
On Wed, 2013-03-20 at 20:13 -0700, Jon Cruz wrote:
On Mar 20, 2013, at 1:28 AM, Jasper van de Gronde wrote:
On 19-03-13 20:01, Ted Janeczko wrote: ...
Tav, that sounds like a fantastic birthday party! I've done quite a bit of looking into the internal workings of SPObjects when I created the objects dialog, and I think I have a decent understanding of how everything is updated, but it does get very confusing due to gobject obscurities... If it would help out, I can take a closer look into this and start documenting the process so that it will be easier to work with in the future.
I looked at this some time ago, and one of the main issues is that we constantly keep around the XML (text) representation of attributes. So you update some internal path representation, which triggers an update of the XML, which triggers an update of the internal path representation. (I don't remember how we actually avoid an infinite loop.) This not only causes immense slow-downs, but also causes a loss of precision when doing several transformations in sequence for example. So any clarification on how this mechanism works exactly would indeed be hugely appreciated.
I think the short answer how it works is:
"It doesn't"
There are some 'interesting' work-arounds in place with various toggles being set to try to stop loops, but we really need to improve the overall situation.
Much of this has been in place since quite early days, but you do seem to have summarized the main issues. There are also some issues with timing in regards to subsets of one of the two trees getting disconnected as they are being worked on.
Would this be a good GSOC project?
On 21-3-2013 16:40, Tavmjong Bah wrote:
On Wed, 2013-03-20 at 20:13 -0700, Jon Cruz wrote:
On Mar 20, 2013, at 1:28 AM, Jasper van de Gronde wrote:
On 19-03-13 20:01, Ted Janeczko wrote: ...
Tav, that sounds like a fantastic birthday party! I've done quite a bit of looking into the internal workings of SPObjects when I created the objects dialog, and I think I have a decent understanding of how everything is updated, but it does get very confusing due to gobject obscurities... If it would help out, I can take a closer look into this and start documenting the process so that it will be easier to work with in the future.
I looked at this some time ago, and one of the main issues is that we constantly keep around the XML (text) representation of attributes. So you update some internal path representation, which triggers an update of the XML, which triggers an update of the internal path representation. (I don't remember how we actually avoid an infinite loop.) This not only causes immense slow-downs, but also causes a loss of precision when doing several transformations in sequence for example. So any clarification on how this mechanism works exactly would indeed be hugely appreciated.
I think the short answer how it works is:
"It doesn't"
There are some 'interesting' work-arounds in place with various toggles being set to try to stop loops, but we really need to improve the overall situation.
Much of this has been in place since quite early days, but you do seem to have summarized the main issues. There are also some issues with timing in regards to subsets of one of the two trees getting disconnected as they are being worked on.
Would this be a good GSOC project?
Oof, to me this sounds like the worst GSoC project imaginable! ;-)
Cheers, Johan
2013/3/21 Johan Engelen <jbc.engelen@...2592...>:
On 21-3-2013 16:40, Tavmjong Bah wrote:
Would this be a good GSOC project?
Oof, to me this sounds like the worst GSoC project imaginable! ;-)
+1
I increasingly think the whole model of separate SP and XML trees might need a rework. The main result of the current approach is that higher-level code still manipulates XML directly and listens to XML change notifications (bad thing).
Maybe the correct solution is to - make the SP tree objects implement the XML tree interfaces, preferably via protected inheritance to prevent higher-level code from mucking with them. - provide enough information about SVG structure to the XML tree that it can be type-aware (e.g. CSS information would be stored as parsed CSS, not as strings; images embedded in data URIs would be stored as decoded PNG / JPEG data, not as a base64 encoded string)
The loss of precision mentioned by Jasper is actually something we need to keep, because otherwise the document would change slightly when reloaded. (Either that or always write out numbers with full precision.)
Regards, Krzysztof
On 2013-03-22 03:48, Krzysztof Kosiński wrote:
The loss of precision mentioned by Jasper is actually something we need to keep, because otherwise the document would change slightly when reloaded. (Either that or always write out numbers with full precision.)
Not necessarily. There are all sorts of solutions imaginable that avoid changing the document slightly when reloading it while also avoiding loss of precision when repeatedly changing a value. For example, one could store the original string and clear it whenever the value changes, regenerating it only when requested. True, if one then saves the file and transforms a shape there is still some loss of precision compared to directly applying the second transform and then saving, but that should typically be hardly noticeable. (And in my mind it's better to be precise when one is able to.)
A different option would be to somehow ensure that everything is constrained in such a way that it is always "precise" up to a given tolerance, but that is probably going a bit too far.
A more pragmatic option to avoid the discrepancy between floats and serialized values is to use a binary format. For example an EXI encoding of the SVG document. To me this would make the most sense, as it solves a host of "silly" problems and is typically more efficient.
On Thu, 2013-03-21 at 16:40 +0100, Jon Cruz wrote:
Much of this has been in place since quite early days, but you do seem to have summarized the main issues. There are also some issues with timing in regards to subsets of one of the two trees getting disconnected as they are being worked on.
Jon, how much do you think this would cost to hire someone to do for us? It sounds like the kind of work that we really need to do and maybe a kickstarter could fund some full time work.
Maybe some tests to point the problems out too.
Martin,
participants (7)
-
Jasper van de Gronde -
Johan Engelen -
Jon Cruz -
Krzysztof Kosiński -
Martin Owens -
Tavmjong Bah -
Ted Janeczko