Roadmap brainstorming for 0.92 and forward
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/Roadmap
I'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
Hi !
I'm not a programer/developer, just a basic user, but I have few ideas for the roadmap, I'd just want to contribute on the wiki, but I'm not allowed to. Is it possible to have a password for my pseudo "Teto" in order to contribute ?
Cheers, Teto.
Le 23/11/2014 08:45, Bryce Harrington a écrit :
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/RoadmapI'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
Done. You should be receiving an email shortly.
Cheers, Josh
On Sun, Nov 23, 2014 at 8:01 AM, Teto <teto45@...2519...> wrote:
Hi !
I'm not a programer/developer, just a basic user, but I have few ideas for the roadmap, I'd just want to contribute on the wiki, but I'm not allowed to. Is it possible to have a password for my pseudo "Teto" in order to contribute ?
Cheers, Teto.
Le 23/11/2014 08:45, Bryce Harrington a écrit :
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/RoadmapI'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Bryce,
Thanks for getting the discussion started on this! The list is already looking like a great place to start. I'm hoping that this can give us some good direction moving forward with the next handful of releases.
Cheers, Josh
On Sat, Nov 22, 2014 at 11:45 PM, Bryce Harrington <bryce@...961...> wrote:
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/RoadmapI'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I'm not a (good) C++ programmer nor am I part of the Inkscape team, though I imagine several items on the current roadmap to be huge. SVG 2 support, Hardware acceleration or animation support for example sound like things that could take a long time to be fully implemented.
So as Bryce said, in order to shorten Inkscape's release cycle you should focus on just a few (smaller) features for the next release(s). All (bigger) features should be developed in parallel on their own branch and merged when they are ready. They should not block a release. Surely keeping these branches synchronized with the main branch may sometimes be quite difficult, but worth doing to keep a clear roadmap and don't let users wait too long for new versions. To do so maybe a few people could focus on these bigger things while the others work on the parts for the next release. Though that depends on the number of contributors you have, of course.
Sebastian
On 23 November 2014 at 20:49, Josh Andler <scislac@...400...> wrote:
Bryce,
Thanks for getting the discussion started on this! The list is already looking like a great place to start. I'm hoping that this can give us some good direction moving forward with the next handful of releases.
Cheers, Josh
On Sat, Nov 22, 2014 at 11:45 PM, Bryce Harrington <bryce@...961...> wrote:
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/RoadmapI'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl...
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, Nov 24, 2014 at 10:46:39PM +0100, Sebastian Zartner wrote:
I'm not a (good) C++ programmer nor am I part of the Inkscape team, though I imagine several items on the current roadmap to be huge. SVG 2 support, Hardware acceleration or animation support for example sound like things that could take a long time to be fully implemented.
So as Bryce said, in order to shorten Inkscape's release cycle you should focus on just a few (smaller) features for the next release(s). All (bigger) features should be developed in parallel on their own branch and merged when they are ready. They should not block a release. Surely keeping these branches synchronized with the main branch may sometimes be quite difficult, but worth doing to keep a clear roadmap and don't let users wait too long for new versions. To do so maybe a few people could focus on these bigger things while the others work on the parts for the next release. Though that depends on the number of contributors you have, of course.
Sebastian
Hi Sebastian, yes you're exactly right re: big projects. You have a good suggestion to allow feature work to go on in parallel in separate branches. You're right that it can be a pain to keep in sync (and to attract testers), but that's a good way to allow progress to be made without risking release delays.
In the past what we've sometimes done is break a big task up into logical chunks and spread the chunks over sequential releases. Roadmaps are perfect for organizing this type of work.
So for instance, one release might implement just backend infrastructure for the feature, then the next would add basic GUI support in an experimental fashion, and the third expands to advanced functionality and general spit and polish.
SVG 2 support is actually a collection of specific features; I could easily see us chip off some of the simpler features in one release, and leave more complex features for later releases. We'll have to scope it out and see what best matches interests and implementation feasibility.
Hardware acceleration I actually think may not be terribly hard to do in terms of coding. The trouble will be more in ensuring it is performant and robust - which is going to lean more on testing, testing, testing.
Animation support really is a big thing indeed, and we've only taken baby steps at scoping the work out. Indeed "Animation" is like "Drawing" - there's many different methods and styles, each needing a somewhat different type of UI. It's not even clear if Inkscape *should* be a vector animation editor, because of the hugely different UI needs (like trying to do word processing with a spreadsheet program). Liam has been working on ideas of splitting Inkscape's core code from the user interface code; if this is done, then I could conceive of us utilizing the same backend code but have two frontends, one specialized in doing 2D drawing, the other specialized in animation work.
Sebastian, thanks again for the ideas, and I hope you hang around and help with hashing out plans.
Bryce
On 23 November 2014 at 20:49, Josh Andler <scislac@...400...> wrote:
Bryce,
Thanks for getting the discussion started on this! The list is already looking like a great place to start. I'm hoping that this can give us some good direction moving forward with the next handful of releases.
Cheers, Josh
On Sat, Nov 22, 2014 at 11:45 PM, Bryce Harrington <bryce@...961...> wrote:
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/RoadmapI'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl...
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Friends, Frequently there are posts in forums, where people give often detailed, and often passionate requests and explanations for what is needed to make Inkscape what they think it should be. Unless I misunderstand Bryce's comments, it seems to me, including the Inkscape user community in the brainstorming, would be a great source of ideas! Although I notice this was not cross-posted in the user mailing list. So there's a good chance I don't understand. Anyway, if I did understand, I wanted to ask if I could post a message in the forums, quoting Bryce's op on this topic, and requesting input. Or if not, in lieu, could I post links to a few forum messages, on the referenced wiki page, which seem to me to represent an overview of the most frequent user requests? Thank you very much :-) brynn
-------------------------------------------------- From: "Bryce Harrington" <bryce@...961...> Sent: Sunday, November 23, 2014 12:45 AM To: <inkscape-devel@...6...> Subject: [Inkscape-devel] Roadmap brainstorming for 0.92 and forward
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/Roadmap
I'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, Nov 24, 2014 at 07:13:55PM -0700, Brynn wrote:
Hi Friends, Frequently there are posts in forums, where people give often detailed, and often passionate requests and explanations for what is needed to make Inkscape what they think it should be. Unless I misunderstand Bryce's comments, it seems to me, including the Inkscape user community in the brainstorming, would be a great source of ideas! Although I notice this was not cross-posted in the user mailing list. So there's a good chance I don't understand.
Right, there's a bit of a distinction here. The roadmap reflects where the developers in particular intend to go. Certainly user requests and suggestions are important input to enable developers to form concepts of what's needed. But users aren't familiar with the codebase or how Inkscape is architected internally, so they don't have the context to know if a given idea is easy or hard, if it's a logical extension of existing code or would require massive internal restructuring.
As well, a lot of the things that need nailed down in the roadmap are lower level infrastructural bits, which often will not be user-visible. For instance, modularizing internal libraries, switching from bzr to git, and adopting C++11 are all going to require broad developer agreement for planning, but will have no user visible effect. But (we think) they'll be necessary to help keep Inkscape development moving forward briskly.
Think of user-visible features like the leaves on the tree, whereas for the roadmap we're discussing more about what limbs need lopped off and which need grafted on to give us the healthiest canopy.
Anyway, if I did understand, I wanted to ask if I could posta message in the forums, quoting Bryce's op on this topic, and requesting input. Or if not, in lieu, could I post links to a few forum messages, on the referenced wiki page, which seem to me to represent an overview of the most frequent user requests? Thank you very much :-)
Yes, that would be great input for the process.
Also, the roadmap can cover more than just the core codebase - anything that will require broad team agreement and/or planning is topical. That could include restructuring how we do tutorials, migrating the wiki from mediawiki to something else, etc.
Bryce
1.0 milestones:
1. Fixed flowtext support (i.e. the text should show in browsers) 2. Default coordinate system must match the default SVG coordinate system
I think these were accepted by consensus as conditions for the 1.0 release some time ago, but I don't remember the discussion perfectly.
Some other ideas:
1. Better XML representation for path effects. Currently code-wise LPE support is a mess and this is in large part caused by piggybacking LPE data on normal objects instead of putting it into dedicated objects with svg:switch fallback. The whole design of storing all LPE parameters as attributes on a special node instead of as separate objects in defs is a nightmare to work with.
2. Object browser. Basically, something like the XML editor but for the SP tree.
3. True two-way reference tracking, so that it's possible to change the ID of an arbitrary object and have all references to it update automatically, as well as enumerate all objects that refer to a specific object. I have some ideas on how to do this if someone is interested.
4. Better integration of LPEs, which would to some extent depend on 1 and 3 (I don't want to deal with maintaining the resulting pile of spaghetti if we do this before 1). I imagine this would work like this: - user makes a clone - LPE is applied to the clone - this tells the LPE engine that it should actually make a reference to the clone's original - editing the original updates in realtime Similar things could happen for clipping paths and other objects. In general, I think the paradigm of using clones to represent references to objects is a good idea. Alternatively, things like boolean operations could always work as LPEs, and the Convert to Path operation would be for destructively applying edits.
5. Improvements to the selector tool: - a mode object positions are transformed, but the objects themselves are unaffected (only translated) - a mode that works as if each object was selected in turn and the same transform was applied to it
6. Support for point symmetry at the node editor level. Basically, you should be able to easily create a symmetric shape that does not have a node at the symmetry axis.
7. Change page size by dragging page borders or corners. (Needs some input on how this would be enabled / disabled, since I guess it would be annoying to have this always on in the selector or node editor. Might be a separate tool.)
8. Nicer support for space symmetry (tilings). They should be editable on the canvas instead of trial-and-error fiddling with numbers in the clone tiler dialog. Implementing 6 would fix some of the problem, but
9. Shape tool improvements: draggable rectangle sides, draggable circle radius / ellipse axes, etc.
10. More sophisticated gradient editor, allowing for things like non-linear gradients (emulated by gradients with many stops).
11. More useful right-click context menus that display only things relevant to the selected object instead of some generic operations.
12. Waf as build system on all platforms.
13. Python scripting. My impression is that this would have a better chance of producing something actually useful than D-Bus scripting due to the "worse is better" principle. Must go in tandem with some rather deep refactoring to avoid transferring the existing limitations of the internal API to the scripting language. https://en.wikipedia.org/wiki/Worse_is_better
14. Support for automatic pixel art tracing of images where each of the pixels is scaled up to a larger square. The tracer should not assume that the pixels of the image are exactly 1x1, and if possible should be tolerant of JPEG compression artifacts. I guess this can be done with a simple Fourier transform-based algorithm. Example: http://research.microsoft.com/en-us/um/people/kopf/pixelart/supplementary/re...
Regards, Krzysztof
Solving the svg filters resolution problem (and giving the user the possibility to define it right in the Filters Editor or in the ui of customizable ones) and thus solving the inconsistences in zooming on fitered objects which contains for example convolution matrix.
Solving other display bugs in filters (often seen when applying most effects to background).
And of course SVG 2.0 !
Thanks, ivan
Le 25/11/14 05:55, Josh Andler a écrit :
On Mon, Nov 24, 2014 at 8:46 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
- Object browser. Basically, something like the XML editor but for the SP tree.
In trunk, is "Object>Objects..." not quite there?
Cheers, Josh
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
There are different categories of suggestions now in the roadmap suggestion list, maintenance (split libraries out, change version control system, back-end improvements, c++11), new features (SVG, UI improvements), bugfixes. Is it worth the time to split all suggestions into different groups to get a better overview of them or is that just time spent on the wrong thing? -- Christoffer Holmstedt
2014-11-25 12:48 GMT+01:00 ivan louette <ivan_louette@...48...>:
Solving the svg filters resolution problem (and giving the user the possibility to define it right in the Filters Editor or in the ui of customizable ones) and thus solving the inconsistences in zooming on fitered objects which contains for example convolution matrix.
Solving other display bugs in filters (often seen when applying most effects to background).
And of course SVG 2.0 !
Thanks, ivan
Le 25/11/14 05:55, Josh Andler a écrit :
On Mon, Nov 24, 2014 at 8:46 PM, Krzysztof Kosiński <tweenk.pl@...1857...00...> wrote:
- Object browser. Basically, something like the XML editor but for the SP tree.
In trunk, is "Object>Objects..." not quite there?
Cheers, Josh
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Nov 25, 2014 at 01:18:52PM +0100, Christoffer Holmstedt wrote:
There are different categories of suggestions now in the roadmap suggestion list, maintenance (split libraries out, change version control system, back-end improvements, c++11), new features (SVG, UI improvements), bugfixes. Is it worth the time to split all suggestions into different groups to get a better overview of them or is that just time spent on the wrong thing?
If it helps with giving folks a bigger picture view of things, by all means please go ahead. May help us identify where we need to do further brainstorming. Good suggestion.
There should also be categories for 'Documentation', 'Infrastructure', 'Community', and probably a few others for stuff outside plain coding work.
Bryce
-- Christoffer Holmstedt
2014-11-25 12:48 GMT+01:00 ivan louette <ivan_louette@...48...>:
Solving the svg filters resolution problem (and giving the user the possibility to define it right in the Filters Editor or in the ui of customizable ones) and thus solving the inconsistences in zooming on fitered objects which contains for example convolution matrix.
Solving other display bugs in filters (often seen when applying most effects to background).
And of course SVG 2.0 !
Thanks, ivan
Le 25/11/14 05:55, Josh Andler a écrit :
On Mon, Nov 24, 2014 at 8:46 PM, Krzysztof Kosiński <tweenk.pl@...1761....400...> wrote:
- Object browser. Basically, something like the XML editor but for the SP tree.
In trunk, is "Object>Objects..." not quite there?
Cheers, Josh
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2014-11-25 21:38 GMT+01:00 Bryce Harrington <bryce@...961...>:
On Tue, Nov 25, 2014 at 01:18:52PM +0100, Christoffer Holmstedt wrote:
There are different categories of suggestions now in the roadmap suggestion list, maintenance (split libraries out, change version control system, back-end improvements, c++11), new features (SVG, UI improvements), bugfixes. Is it worth the time to split all suggestions into different groups to get a better overview of them or is that just time spent on the wrong thing?
If it helps with giving folks a bigger picture view of things, by all means please go ahead. May help us identify where we need to do further brainstorming. Good suggestion.
There should also be categories for 'Documentation', 'Infrastructure', 'Community', and probably a few others for stuff outside plain coding work.
Bryce
Ok, I did a quick categorization of the list and added some notes mentioned in this email thread. I think it is easier now to get an overview. Some items on the list are out of my knowledge space so if anything is in the wrong category, just move it.
-- Christoffer Holmstedt
Solving the svg filters resolution problem (and giving the user the possibility to define it right in the Filters Editor or in the ui of customizable ones) and thus solving the inconsistences in zooming on fitered objects which contains for example convolution matrix.
Solving other display bugs in filters (often seen when applying most effects to background).
And of course SVG 2.0 !
Thanks, ivan
Le 25/11/14 05:55, Josh Andler a écrit :
On Mon, Nov 24, 2014 at 8:46 PM, Krzysztof Kosiński <tweenk.pl@...233.....400...> wrote:
- Object browser. Basically, something like the XML editor but for the SP tree.
In trunk, is "Object>Objects..." not quite there?
Cheers, Josh
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, Nov 26, 2014 at 07:54:28PM +0100, Christoffer Holmstedt wrote:
2014-11-25 21:38 GMT+01:00 Bryce Harrington <bryce@...961...>:
On Tue, Nov 25, 2014 at 01:18:52PM +0100, Christoffer Holmstedt wrote:
There are different categories of suggestions now in the roadmap suggestion list, maintenance (split libraries out, change version control system, back-end improvements, c++11), new features (SVG, UI improvements), bugfixes. Is it worth the time to split all suggestions into different groups to get a better overview of them or is that just time spent on the wrong thing?
If it helps with giving folks a bigger picture view of things, by all means please go ahead. May help us identify where we need to do further brainstorming. Good suggestion.
There should also be categories for 'Documentation', 'Infrastructure', 'Community', and probably a few others for stuff outside plain coding work.
Bryce
Ok, I did a quick categorization of the list and added some notes mentioned in this email thread. I think it is easier now to get an overview. Some items on the list are out of my knowledge space so if anything is in the wrong category, just move it.
Thanks!
-- Christoffer Holmstedt
Solving the svg filters resolution problem (and giving the user the possibility to define it right in the Filters Editor or in the ui of customizable ones) and thus solving the inconsistences in zooming on fitered objects which contains for example convolution matrix.
Solving other display bugs in filters (often seen when applying most effects to background).
And of course SVG 2.0 !
Thanks, ivan
Le 25/11/14 05:55, Josh Andler a écrit :
On Mon, Nov 24, 2014 at 8:46 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
- Object browser. Basically, something like the XML editor but for the SP tree.
In trunk, is "Object>Objects..." not quite there?
Cheers, Josh
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Nov 25, 2014 at 7:46 AM, Krzysztof Kosiński wrote:
- Improvements to the selector tool:
- a mode object positions are transformed, but the objects themselves
are unaffected (only translated)
- a mode that works as if each object was selected in turn and the
same transform was applied to it
What about align on-canvas stuff that Martin added last year?
https://code.launchpad.net/~doctormo/inkscape/align-handles
- Nicer support for space symmetry (tilings). They should be editable
on the canvas instead of trial-and-error fiddling with numbers in the clone tiler dialog. Implementing 6 would fix some of the problem, but
Did anybody evaluate the results of this GSoC project?
https://code.launchpad.net/~inkscape.dev/inkscape/symmetry-tool
Alex
On 25-11-2014 5:46, Krzysztof Kosiński wrote:
- Better XML representation for path effects. Currently code-wise LPE
support is a mess and this is in large part caused by piggybacking LPE data on normal objects instead of putting it into dedicated objects with svg:switch fallback. The whole design of storing all LPE parameters as attributes on a special node instead of as separate objects in defs is a nightmare to work with.
Some counter text here: The design of having all parameters of one LPE in a defs node has been very nice to work with (I think I am one of the /very/ few that actually worked with this?). Previous to the node tool changes, we could edit a path's original path and LPE bend path at the same time perfectly fine. What happened to this? ;-) :P
Yes, the LPE design is simple. I agree parts of it have turned into spaghetti, mostly because people wanted LPE's to work on groups, text, their shoelaces, etc ;) Also, cruft has collected because of unfinished work that never got removed. For advanced work, something new is needed. LPE was never meant to do bool ops on two paths. Nor was it meant to be generative (create path out of nowhere). The thing you describe with clones actually did work pretty nicely, but got distroyed in experimental by the "Fill Between Many" change. I don't know why that change was made and it will have to be reverted I think.
One thing to keep in mind while designing a broader math operations framework: gradients are (in my opinion) over designed, with too many objects and different tree nodes for just one gradient. This actually made and makes our gradient code buggy and hard to work with.
Fair warning, Johan
On 25-11-2014 20:54, Johan Engelen wrote:
The thing you describe with clones actually did work pretty nicely, but got distroyed in experimental by the "Fill Between Many" change. I don't know why that change was made and it will have to be reverted I think.
Not fair and not true. It is some other bug somewhere that causes misbehavior with clones atm.
- Johan
On Tue, 2014-11-25 at 21:05 +0100, Johan Engelen wrote:
On 25-11-2014 20:54, Johan Engelen wrote:
The thing you describe with clones actually did work pretty nicely, but got distroyed in experimental by the "Fill Between Many" change. I don't know why that change was made and it will have to be reverted I think.
Not fair and not true. It is some other bug somewhere that causes misbehavior with clones atm.
- Johan
It looks like you're arguing with yourself. Did I miss a reply?
Martin,
On 25-11-2014 23:08, Martin Owens wrote:
On Tue, 2014-11-25 at 21:05 +0100, Johan Engelen wrote:
On 25-11-2014 20:54, Johan Engelen wrote:
The thing you describe with clones actually did work pretty nicely, but got distroyed in experimental by the "Fill Between Many" change. I don't know why that change was made and it will have to be reverted I think.
Not fair and not true. It is some other bug somewhere that causes misbehavior with clones atm.
- Johan
It looks like you're arguing with yourself. Did I miss a reply?
No reply was missed in between. Second-me was wrong, the bug was indeed caused by the "Fill Between Many" change, but not related to Fill Between Many itself. Fixed in trunk.
(sorry off topic)
On Tue, Nov 25, 2014 at 08:54:41PM +0100, Johan Engelen wrote:
On 25-11-2014 5:46, Krzysztof Kosiński wrote:
- Better XML representation for path effects. Currently code-wise LPE
support is a mess and this is in large part caused by piggybacking LPE data on normal objects instead of putting it into dedicated objects with svg:switch fallback. The whole design of storing all LPE parameters as attributes on a special node instead of as separate objects in defs is a nightmare to work with.
Some counter text here: The design of having all parameters of one LPE in a defs node has been very nice to work with (I think I am one of the /very/ few that actually worked with this?). Previous to the node tool changes, we could edit a path's original path and LPE bend path at the same time perfectly fine. What happened to this? ;-) :P
Yes, the LPE design is simple. I agree parts of it have turned into spaghetti, mostly because people wanted LPE's to work on groups, text, their shoelaces, etc ;) Also, cruft has collected because of unfinished work that never got removed. For advanced work, something new is needed. LPE was never meant to do bool ops on two paths. Nor was it meant to be generative (create path out of nowhere). The thing you describe with clones actually did work pretty nicely, but got distroyed in experimental by the "Fill Between Many" change. I don't know why that change was made and it will have to be reverted I think.
Ah, good retrospective.
It's impressive that LPEs have been a source of so much community contribution. It's hard to predict when an extensible feature is going to receive a lot of outside contribs, but perhaps for future lesson learned is that we need a project infrastructure that allows us to share these contributions outside the core inkscape package. Then, if we have this as a more general purpose solution, then when others come up with clever extensible mechanisms they can use this to collect and distribute their bits. I don't know whether this would be in the form of a 'contribs' tarball, or a plugin repository, or good/bad/ugly packages, or an interactive downloader ala ClipArt; but some method for sharing out these unofficial bits, would allow us to enforce some quality control on them, without violating our culture of open contributions.
Bryce
2014-11-25 5:55 GMT+01:00 Josh Andler <scislac@...400...>:
On Mon, Nov 24, 2014 at 8:46 PM, Krzysztof Kosiński <tweenk.pl@...847...0...> wrote:
- Object browser. Basically, something like the XML editor but for the SP tree.
In trunk, is "Object>Objects..." not quite there?
Yes, I meant something like this. I didn't run make install for a pretty long time and had the old menu structure. In my mind this dialog should also have some means to edit the parameters of the shapes, or perhaps this could be put in Object Properties.
There's a bigger UI problem here. Right now we can modify shape parameters (e.g. number of corners on a star) only through the toolbar in the appropriate tool. This means one must select a shape and then select the correct tool. This is clearly suboptimal, since the correct tool might not be immediately obvious. However, if we put the same controls in the Object Properties dialog, it will lead to UI duplication. Does anyone know how other tools solve this?
- Improvements to the selector tool:
- a mode object positions are transformed, but the objects themselves
are unaffected (only translated)
- a mode that works as if each object was selected in turn and the
same transform was applied to it
What about align on-canvas stuff that Martin added last year?
There was a movie that demonstrated how this worked, but it was removed from Blip - is it available anywhere else? Could we convince Martin to reupload it?
- Nicer support for space symmetry (tilings). They should be editable
on the canvas instead of trial-and-error fiddling with numbers in the clone tiler dialog. Implementing 6 would fix some of the problem, but
Did anybody evaluate the results of this GSoC project?
https://code.launchpad.net/~inkscape.dev/inkscape/symmetry-tool
I mentored this, but the results are not very usable. The project turned out to be more complicated than expected. For example, I recall that it turned out somewhere along the way that for each clone it is necessary to store how it was transformed to its position.
2014-11-25 20:54 GMT+01:00 Johan Engelen <jbc.engelen@...2592...>:
Some counter text here: The design of having all parameters of one LPE in a defs node has been very nice to work with (I think I am one of the /very/ few that actually worked with this?). Previous to the node tool changes, we could edit a path's original path and LPE bend path at the same time perfectly fine. What happened to this? ;-) :P
Yes, the LPE design is simple. I agree parts of it have turned into spaghetti, mostly because people wanted LPE's to work on groups, text, their shoelaces, etc ;) Also, cruft has collected because of unfinished work that never got removed.
Well, that's kind of the point. The current LPE design is reasonable for the model of one input path being transformed to one output path. If I started from these assumptions I would've had probably come up with a similar design. However, once multiple path parameters are put on a separate LPE node, handling this design in the node editor is very tedious, because the set of objects contained in Inkscape::Selection and the set of objects which are supposed to display their editing controls are no longer the same.
Regards, Krzysztof
On Fri, 2014-11-28 at 23:40 +0100, Krzysztof Kosiński wrote:
What about align on-canvas stuff that Martin added last year?
There was a movie that demonstrated how this worked, but it was removed from Blip - is it available anywhere else? Could we convince Martin to reupload it?
Here you go, fresh upload to youtube (from 2013, older branch shown):
https://inkscape.org/en/gallery/item/2504/
The feature should be dead easy to do since all the code got into trunk, only the specifics about when the align handles need to be added. Actually adding handles of any kind should be much easier now :-D
Martin,
2014-11-29 0:01 GMT+01:00 Martin Owens <doctormo@...400...>:
Here you go, fresh upload to youtube (from 2013, older branch shown):
This feature provides easier access to alignment functions, so it's something completely unrelated to my point 5.
This thing I have in mind would make it easier to e.g. "spread out" objects without changing their relative distances from each other. For example if you have some circles arranged in a pattern, this feature would allow you to: 1. resize the pattern of circles without resizing the circles themselves. 2. resize every circle by the same amount without resizing the pattern.
Regards, Krzysztof
I made some additions to the roadmap
1. Improved the "evaluate PDF export" item with link to earlier mailing list discussion about PDF export for printing industry, I think that is what it boils down to in the end.
2. Added item about mailing list archive should be available under inkscape.org. -- Christoffer Holmstedt
2014-11-29 0:54 GMT+01:00 Krzysztof Kosiński <tweenk.pl@...400...>:
2014-11-29 0:01 GMT+01:00 Martin Owens <doctormo@...400...>:
Here you go, fresh upload to youtube (from 2013, older branch shown):
This feature provides easier access to alignment functions, so it's something completely unrelated to my point 5.
This thing I have in mind would make it easier to e.g. "spread out" objects without changing their relative distances from each other. For example if you have some circles arranged in a pattern, this feature would allow you to:
- resize the pattern of circles without resizing the circles themselves.
- resize every circle by the same amount without resizing the pattern.
Regards, Krzysztof
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
SVG units are defined by document height/width (defaults to "px" units)
and the viewbox numbers. From that information, Inkscape (and python script inkex.py) calculates the SVG unit.
This is extremely confusing. I cannot even begin to determine how we are ever going to be able to explain this mess to a user, given the fact that we cannot even agree amongst ourselves as to what is being discussed here. First of all, the concept of "SVG unit" has never been defined anywhere, or at least I have never seen a meaningful definition of it. Secondly, there is no practical motivation for moving in this direction given that there was absolutely nothing wrong with the previous system of units. It is true that the name was unfortunate. It should not have been called default units, it should have been called document units, which is more meaningful. It is also true that there were some bugs, but those bugs are still there now and are not going to go away just by defining a new concept. Furthermore, not only are the bugs still there, but on top of that we are not in a position to be able to fix them because we are in a state of suspended animation while we try to figure out what to do. On top of that we will be defining yet another concept of unit, namely a SVG Unit on top of the existing display unit, to add to the interminable plethora of units that we already have. So, just for the record, here is my concept of how the previous system used to work, and also why I like it. The previous system worked with three types of variable. Two of these variables were independent variables and could be modified by the user using the gui. Both of these variables were geometrical in nature and had physical units associated with them, so they could be defined very clearly. The physical units were also defined very clearly and precisely as physical lengths. The first of these variables was the page size, which had units associated with it, and was specified in the page width and height in the XML root. The second variable was the viewbox which had lengths which were given in the root while the units of the viewbox were given in the namedview section using inkscape:document-units. It is unfortunate that the viewbox units are specified in a different section of the XML than the actual coordinate values, this is very confusing. However that deficiency would be very easy to fix, just a matter of relocating a variable to a better location. The point that I am trying to make is that this is a very physical picture of the representation and it is very easy to explain to anyone, no matter who they may be. It is also very flexible, because the units of the page size can be specified independently of the units of the viewBox. As for the reason why there are two independent quantities here, you can use the concept of a source document and a target document and you can visualize the process of projecting the original page size as a source onto the viewbox as a target. This is very visual and very unambiguous and very precise. Then the third variable of course is the relationship between page size and viewbox, or between source and target. This is a dimensionless ratio which is a dependent variable, not an independent variable, and would normally not be immediately accessible to the user, nor would the user normally need to have access to this particular variable. It might be useful to the programmer, not the user. To the best of my knowledge this model is sufficiently flexible to do everything that we need to do. It does not contain any redundant information, and it does not rely on any non-physical concepts. This, I believe, is the model that was in operation until about a month ago or so, and it was working perfectly well, apart from the fact that there were a few outstanding issues that needed to be resolved concerning coordinate transformations. Now it appears that this model has been abandoned in favor of a new system which has yet to be defined, for reasons that are still not clear to me. On top of that, all development work has apparently ground to a halt while we discuss this issue interminably, to no avail. I am utterly at a loss for words, I am speechless, notwithstanding the above outburst.
Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Roadmap-brainstorming-for-0-92-and-forward-... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 29 November 2014 at 20:51, the Adib <theadib@...400...> wrote:
I really would like to see the current release than discussing the next one.
However we should define if we focus on a time-based or feature-based release mechanism.
This is a very important point, IMO. As I stated earlier http://sourceforge.net/p/inkscape/mailman/message/32145816/ Inkscape has an extremely long release cycle, which needs to be shortened. In order to reduce the time between two major releases I'd vote for a mainly time-based release cycle, because I believe that a feature-based cycle may cause long delays in case specific features may be harder to implement than initially thought. This being said, it's good to predefine, which features should be tackled for an upcoming release before you start working on it. Though they should be deferred to the next release in case they take longer to implement than expected.
Again, I'm just an Inkscape user, but I'm talking from my experience as a Firebug Working Group member, where I learned that it's important to make regular releases.
On 1 December 2014 at 23:42, alvinpenner <penner@...1856...> wrote:
SVG units are defined by document height/width (defaults to "px" units)
and the viewbox numbers. From that information, Inkscape (and python script inkex.py) calculates the SVG unit.
This is extremely confusing.
Detailed discussions about specific parts like this one should happen in separate threads, IMO. The topic of this thread is to define the tasks to work on for 0.92+.
On 1 December 2014 at 18:36, Ryan Lerch <rlerch@...43...> wrote:
I'm definintely keen on digging into UX in inkscape further too, though this might be suited for a new thread -- or a discussion in #inkscape-devel :)
FWIW I can also help creating UI mockups (e.g. like the one in bug 1362061 https://bugs.launchpad.net/inkscape/+bug/1362061) and make suggestions to improve the UX.
Sebastian
El mar, 25-11-2014 a las 05:46 +0100, Krzysztof Kosiński escribió:
1.0 milestones:
- Fixed flowtext support (i.e. the text should show in browsers)
+1 to flowtext improvements. There are a few features that would take flowtext from the barely usable state it is now to a new level:
- The ability to set spacing before and after paragraphs. - Word-break (localised hyphenation)
Other features as tabulations, bullet lists, and better opentype support for type in general would be welcome, although not as critical as the ones I mentioned above.
For anybody intending to use Inkscape for professional graphic design work, those features would add enough for a new version.
Gez.
So "No" I didn't understand. But "Yes" posting in the forum would be helpful.
Ok, here's my post. If I said anything wrong, please let me know, and I'll correct it.
http://www.inkscapeforum.com/viewtopic.php?f=21&t=18053
Thanks, brynn
-------------------------------------------------- From: "Bryce Harrington" <bryce@...961...> Sent: Monday, November 24, 2014 7:37 PM To: "Brynn" <brynn@...3133...> Cc: <inkscape-devel@...6...> Subject: Re: [Inkscape-devel] Roadmap brainstorming for 0.92 and forward
On Mon, Nov 24, 2014 at 07:13:55PM -0700, Brynn wrote:
Hi Friends, Frequently there are posts in forums, where people give often detailed, and often passionate requests and explanations for what is needed to make Inkscape what they think it should be. Unless I misunderstand Bryce's comments, it seems to me, including the Inkscape user community in the brainstorming, would be a great source of ideas! Although I notice this was not cross-posted in the user mailing list. So there's a good chance I don't understand.
Right, there's a bit of a distinction here. The roadmap reflects where the developers in particular intend to go. Certainly user requests and suggestions are important input to enable developers to form concepts of what's needed. But users aren't familiar with the codebase or how Inkscape is architected internally, so they don't have the context to know if a given idea is easy or hard, if it's a logical extension of existing code or would require massive internal restructuring.
As well, a lot of the things that need nailed down in the roadmap are lower level infrastructural bits, which often will not be user-visible. For instance, modularizing internal libraries, switching from bzr to git, and adopting C++11 are all going to require broad developer agreement for planning, but will have no user visible effect. But (we think) they'll be necessary to help keep Inkscape development moving forward briskly.
Think of user-visible features like the leaves on the tree, whereas for the roadmap we're discussing more about what limbs need lopped off and which need grafted on to give us the healthiest canopy.
Anyway, if I did understand, I wanted to ask if I could posta message in the forums, quoting Bryce's op on this topic, and requesting input. Or if not, in lieu, could I post links to a few forum messages, on the referenced wiki page, which seem to me to represent an overview of the most frequent user requests? Thank you very much :-)
Yes, that would be great input for the process.
Also, the roadmap can cover more than just the core codebase - anything that will require broad team agreement and/or planning is topical. That could include restructuring how we do tutorials, migrating the wiki from mediawiki to something else, etc.
Bryce
Unless I misunderstand Bryce's comments, it seems to me, including the
Inkscape user community in the brainstorming, would be a great source of
ideas!
You surely will get a lot of suggestions out of that. To collect ideas from users you may want to use uservoice.com. E.g. the Firefox DevTools team uses this https://ffdevtools.uservoice.com successfully to get some info about what users actually want.
Though from what I read here maintanance and automated testing currently seem to be higher prioritized than new functionality (which is definitely an important point). So maybe asking users should be deferred for one or two versions. Then the important point is of course to motivate your contributors to do these maintainance tasks, which can be achieved by updating and extending the wiki info for developers, splitting bigger changes into small tasks, do mentoring and code review. To get people to write automated tests you need to provide some API and example tests, which can be copied and adjusted by the people to cover other functionality.
Although I notice this was not cross-posted in the user mailing list.
Yes, while I'm 'just' a user I requested access to this list a while ago as there are some discussions like this one were I believe I can give some valuable feedback.
Sebastian, thanks again for the ideas, and I hope you hang around and help
with hashing out plans.
Sure, I'm happy to help. I may not always answer immediately (like this time), though.
Sebastian
On 25 November 2014 at 03:13, Brynn <brynn@...3133...> wrote:
Hi Friends, Frequently there are posts in forums, where people give often detailed, and often passionate requests and explanations for what is needed to make Inkscape what they think it should be. Unless I misunderstand Bryce's comments, it seems to me, including the Inkscape user community in the brainstorming, would be a great source of ideas! Although I notice this was not cross-posted in the user mailing list. So there's a good chance I don't understand. Anyway, if I did understand, I wanted to ask if I could post a message in the forums, quoting Bryce's op on this topic, and requesting input. Or if not, in lieu, could I post links to a few forum messages, on the referenced wiki page, which seem to me to represent an overview of the most frequent user requests? Thank you very much :-) brynn
From: "Bryce Harrington" <bryce@...961...> Sent: Sunday, November 23, 2014 12:45 AM To: <inkscape-devel@...6...> Subject: [Inkscape-devel] Roadmap brainstorming for 0.92 and forward
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/Roadmap
I'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl...
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 11/23/2014 02:45 AM, Bryce Harrington wrote:
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/RoadmapI'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
I'm happy to help flesh out some of the ideas in the way of mockups from a UX guy / artist's perspective for any of these feature ideas too.
Do we use the launchpad blueprints at all? or is it all still just done in the wiki?
cheers, ryanlerch
On Tue, Nov 25, 2014 at 6:03 PM, Ryan Lerch wrote:
I'm happy to help flesh out some of the ideas in the way of mockups from a UX guy / artist's perspective for any of these feature ideas too.
If I may just chime in, Inkscape could do with an updated design to use way, way less screen space. We really could learn a lot from e.g. Gravit.
Alex
+10 for that !
Le 25/11/14 16:19, Alexandre Prokoudine a écrit :
If I may just chime in, Inkscape could do with an updated design to use way, way less screen space. We really could learn a lot from e.g. Gravit.
Alex
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Nov 25, 2014 at 7:19 AM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Tue, Nov 25, 2014 at 6:03 PM, Ryan Lerch wrote:
I'm happy to help flesh out some of the ideas in the way of mockups from a UX guy / artist's perspective for any of these feature ideas too.
If I may just chime in, Inkscape could do with an updated design to use way, way less screen space. We really could learn a lot from e.g. Gravit.
+1 It's especially painful at the standard 1366x768 that most laptops ship with. I'm just wondering, do you have any suggestions for decent GTK3 apps to look at? It just seems like a natural place to look since we hope to make that transition at some point.
Cheers, Josh
On Tue, Nov 25, 2014 at 9:10 PM, Josh Andler wrote:
If I may just chime in, Inkscape could do with an updated design to use way, way less screen space. We really could learn a lot from e.g. Gravit.
+1 It's especially painful at the standard 1366x768 that most laptops ship with. I'm just wondering, do you have any suggestions for decent GTK3 apps to look at?
Not really, no. To the best of my knowledge, GTK+ apps (and GTK+3 apps in particular) tend to be in the productivity and entertainment depts these days, and those aren't areas we you typically get a lot of dockable dialogs and suchlike.
Perhaps this should go to a separate thread, but here are some initial thoughts.
1. Dialogs in Inkscape were designed by different people who didn't put a lot of thought into how well these dialogs align to each other. For instance, if you have a relatively narrow dialog such as Align/Distribute, and then you open SVG Filters editor or SVG Glyphs, you get a complete mess.
2. Inkscape leans towards text-based UI elements (just look at the LPE dock), while comparable proprietary software products are more icon-based.
3. This needs an actual research, but my gut feeling tells me that various non-free applications of this kind tend to use less padding around elements, which naturally decreases the amount of screen estate being used.
4. Inkscape doesn't use ellipsis for too long captions. The Symbols dialog in 0.91 is that wide only because v0.91 ships a symbols set called "United States National Park Service Map Symbols" and automatically expands the width of the dock to show the name in its entirety. What some other (non-GTK+) apps do instead is showing a dock/dialog as small as possible while keeping it usable and showing an ellipsis at the end of the visible part of the name. When you resize that dock/dialog, the rest if the text starts appears character by character, until there's nothing left to ellipsize. Granted, Inkscape is not alone here: GIMP shows a horizontal scrollbar when a layer's name is too long and doesn't fit (it looks just as bad).
The course of action that seems sensible to me (I don't insist on that) is to take a holistic approach to UI design:
1. Analyze the existing UI, make a list of UI decisions that are inconsistent between each other. 2. Look around, see how other project solves these things, figure out what's good/applicable for Inkscape (like designing particular custom widgets that are less pixel-hungry etc.). 3. Design some sort of HIG for Inkscape. 4. Use it to redesign existing dialogs/docks.
I've no doubts that there will be problems like the one you guys had with the SVG Filters dialog that causes both love and hate in more or less equal proportions. But if others solve this somehow, so can you.
Alex
On 11/25/2014 02:27 PM, Alexandre Prokoudine wrote:
On Tue, Nov 25, 2014 at 9:10 PM, Josh Andler wrote:
If I may just chime in, Inkscape could do with an updated design to use way, way less screen space. We really could learn a lot from e.g. Gravit.
+1 It's especially painful at the standard 1366x768 that most laptops ship with. I'm just wondering, do you have any suggestions for decent GTK3 apps to look at?
Not really, no. To the best of my knowledge, GTK+ apps (and GTK+3 apps in particular) tend to be in the productivity and entertainment depts these days, and those aren't areas we you typically get a lot of dockable dialogs and suchlike.
Perhaps this should go to a separate thread, but here are some initial thoughts.
- Dialogs in Inkscape were designed by different people who didn't
put a lot of thought into how well these dialogs align to each other. For instance, if you have a relatively narrow dialog such as Align/Distribute, and then you open SVG Filters editor or SVG Glyphs, you get a complete mess.
- Inkscape leans towards text-based UI elements (just look at the LPE
dock), while comparable proprietary software products are more icon-based.
- This needs an actual research, but my gut feeling tells me that
various non-free applications of this kind tend to use less padding around elements, which naturally decreases the amount of screen estate being used.
- Inkscape doesn't use ellipsis for too long captions. The Symbols
dialog in 0.91 is that wide only because v0.91 ships a symbols set called "United States National Park Service Map Symbols" and automatically expands the width of the dock to show the name in its entirety. What some other (non-GTK+) apps do instead is showing a dock/dialog as small as possible while keeping it usable and showing an ellipsis at the end of the visible part of the name. When you resize that dock/dialog, the rest if the text starts appears character by character, until there's nothing left to ellipsize. Granted, Inkscape is not alone here: GIMP shows a horizontal scrollbar when a layer's name is too long and doesn't fit (it looks just as bad).
The course of action that seems sensible to me (I don't insist on that) is to take a holistic approach to UI design:
- Analyze the existing UI, make a list of UI decisions that are
inconsistent between each other. 2. Look around, see how other project solves these things, figure out what's good/applicable for Inkscape (like designing particular custom widgets that are less pixel-hungry etc.). 3. Design some sort of HIG for Inkscape. 4. Use it to redesign existing dialogs/docks.
I've no doubts that there will be problems like the one you guys had with the SVG Filters dialog that causes both love and hate in more or less equal proportions. But if others solve this somehow, so can you.
Alex
For me, there are two more thoughts that i have been thinking about lately too:
1. The behaviour of the docking dialogs themselves. I find it really hard to still wrap my head around it. Each dialog opens in a seperate dialog group in the sidebar, resulting in a huge scrolled list of dialogs. You can move the dialogs into the group, which makes a tab-button selector at the bottom to switch between. Also the ability to iconify docks seems a bit strange as well. The way gimp does dialogs in the single window mode might be something to glean ideas from too. It uses the tabs at the top.
2. Tool Bar, Dialog, Menu Group?
Many features of inkscape seem inconsistent on where they are presented to the user. For example, the snapping toolbar was added as a toolbar -- would this be better presented as a dialog that can be docked? Also, Extensions and filters are presented as huge menu groups -- would these also be better suited to a dialog presentation, where a richer interface for filtering lists of items, searching, grouping and providing visual examples of them could be created?
I'm definintely keen on digging into UX in inkscape further too, though this might be suited for a new thread -- or a discussion in #inkscape-devel :)
cheers, ryanlerch
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, Dec 1, 2014 at 9:36 AM, Ryan Lerch <rlerch@...43...> wrote:
- The behaviour of the docking dialogs themselves. I find it really
hard to still wrap my head around it. Each dialog opens in a seperate dialog group in the sidebar, resulting in a huge scrolled list of dialogs. You can move the dialogs into the group, which makes a tab-button selector at the bottom to switch between. Also the ability to iconify docks seems a bit strange as well. The way gimp does dialogs in the single window mode might be something to glean ideas from too. It uses the tabs at the top.
This x100. I did up a quick screenshot of 3 different dock layouts to show the flexibility (and how compact it can be). [1]
I'm definintely keen on digging into UX in inkscape further too, though this might be suited for a new thread -- or a discussion in #inkscape-devel :)
I think between the points Alexandre and you have raised, if you would be willing to do some mockups it would probably be useful to have available. I'm not saying we shouldn't discuss it further. I just think that a "visual goal" might inspire people to get into some UI code.
Cheers, Josh
For me, the biggest area of "win" for us is becoming more stable and polishing things. At the GSoC Summit, a friendly guy told us that we don't have to think about what new features to add: "Inkscape is already awesome". A friendly warning for too much "feature gogoGOgO!".
We've collected a lot of deferred maintenance debt. I think it is time to repay that; we should work on disentangling the spaghetti, improve code readability, polish existing features to high satisfaction, etc. I think once we have done that, we are ready for more adventurous things on the roadmap. What I mean is: put maintenance in the near-future roadmap, and new features further out.
To help with refactoring: reinvigorate unittests + rendertests. This is already started at jenkins.inkscape.org:8080, but we should have a larger effort in improving our testsuite (possibly move to other test framework, but at the very least move all unittests into a dedicated tree structure, separate from the src tree); and also in extending and improving our rendertestsuite; and possibly also create a UI testsuite or something of the kind (or a cmdline testsuite). In general: TESTING. Having more comprehensive tests, /and checking them every day/ for early discovery, I think will greatly reduce release-cycle times. Less bugs need to be squashed and hopefully less nasty block bugs too. It is pretty rewarding too to fix a bug measurably by creating a test, and be sure it will not ever fail again without us knowing.
Perhaps this does not sound as much fun as creating a completely new feature. But I think it can be, and I think it is necessary. Although the results of work on these topics are not directly visible, I think the user /will/ notice it: all existing features will become more predictable, more stable, and more pleasant to work with.
If you agree that large maintenance overall is needed, read the attachment. Warning: put on your friendly smile hat!
- Johan
On 23-11-2014 8:45, Bryce Harrington wrote:
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/RoadmapI'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
On Tue, Nov 25, 2014 at 11:38:45PM +0100, Johan Engelen wrote:
For me, the biggest area of "win" for us is becoming more stable and polishing things. At the GSoC Summit, a friendly guy told us that we don't have to think about what new features to add: "Inkscape is already awesome". A friendly warning for too much "feature gogoGOgO!".
We've collected a lot of deferred maintenance debt.
Right. Over the last several years we've accumulated a number of nice features (particularly some of the great annual GSoC work), at the cost of incurred maintenance and stability work. For 0.91 we deliberately focused on the stability work over general maintenance, and I think we have come a long way towards addressing that. So, yes, agreed your points below it's time to prioritize maintenance type stuff, and spit and polish existing features a bit.
I think it is time to repay that; we should work on disentangling the spaghetti, improve code readability, polish existing features to high satisfaction, etc. I think once we have done that, we are ready for more adventurous things on the roadmap. What I mean is: put maintenance in the near-future roadmap, and new features further out.
Yes, agreed, this is a good overall strategy to guide our prioritization when we get to that step.
To help with refactoring: reinvigorate unittests + rendertests. This is already started at jenkins.inkscape.org:8080, but we should have a larger effort in improving our testsuite (possibly move to other test framework, but at the very least move all unittests into a dedicated tree structure, separate from the src tree);
I've been involved in projects that keep unit tests in trunk, as well as a few where they lived in separate repositories. Universally the latter projects' test suites got ignored and quickly fell out of date. Indeed there got to be kind of a discrimination against test writing as a chore. Consequently the testsuites for those projects atrophied; and the more they atrophied the less seriously they got taken; and the less importance people placed on improving them.
Then there have been projects that not only kept the tests in trunk, but made them *the* priority when developing features. Launchpad was very gung ho on this. Cairo is too, to a lesser extent. The test suite actually ends up taking up an appreciable proportion of the codebase, and you may find yourself putting as much effort into writing the tests as on the feature itself (and maybe even more!) But the result is that when you make any arbitrary change to the codebase, and the testsuite still passes, you feel a very strong sense of confidence that your change is right and hasn't broken anything.
Anyway, this is all to say I feel strongly based on my experience that we should keep all tests that we want to actually work and be useful, IN-tree. And in fact in code reviews one of the first things we should check for is whether new or updated tests are being included.
and also in extending and improving our rendertestsuite; and possibly also create a UI testsuite or something of the kind (or a cmdline testsuite). In general: TESTING.
+1
Having more comprehensive tests, /and checking them every day/ for early discovery, I think will greatly reduce release-cycle times. Less bugs need to be squashed and hopefully less nasty block bugs too. It is pretty rewarding too to fix a bug measurably by creating a test, and be sure it will not ever fail again without us knowing.
Perhaps this does not sound as much fun as creating a completely new feature. But I think it can be, and I think it is necessary.
I wonder what we can do as a project to stimulate more test writing activity. More visible posting of test writing activity might help. Maybe posting howto's and tips & tricks on writing good tests.
Bryce
2014-11-26 1:27 GMT+01:00 Bryce Harrington <bryce@...961...>:
On Tue, Nov 25, 2014 at 11:38:45PM +0100, Johan Engelen wrote:
[...]
To help with refactoring: reinvigorate unittests + rendertests. This is already started at jenkins.inkscape.org:8080, but we should have a larger effort in improving our testsuite (possibly move to other test framework, but at the very least move all unittests into a dedicated tree structure, separate from the src tree);
I've been involved in projects that keep unit tests in trunk, as well as a few where they lived in separate repositories. Universally the latter projects' test suites got ignored and quickly fell out of date. Indeed there got to be kind of a discrimination against test writing as a chore. Consequently the testsuites for those projects atrophied; and the more they atrophied the less seriously they got taken; and the less importance people placed on improving them.
Then there have been projects that not only kept the tests in trunk, but made them *the* priority when developing features. Launchpad was very gung ho on this. Cairo is too, to a lesser extent. The test suite actually ends up taking up an appreciable proportion of the codebase, and you may find yourself putting as much effort into writing the tests as on the feature itself (and maybe even more!) But the result is that when you make any arbitrary change to the codebase, and the testsuite still passes, you feel a very strong sense of confidence that your change is right and hasn't broken anything.
Anyway, this is all to say I feel strongly based on my experience that we should keep all tests that we want to actually work and be useful, IN-tree. And in fact in code reviews one of the first things we should check for is whether new or updated tests are being included.
I assumed that Johan meant "in the same repository but in another directory with proper structure". Moving tests into another repository sounds really weird, never heard of it before.
and also in extending and improving our rendertestsuite; and possibly also create a UI testsuite or something of the kind (or a cmdline testsuite). In general: TESTING.
+1
UI testing would be really interesting to dig into. I know there are tools for it for web interfaces but haven't seen any for desktop UI. Though I see this as a last step in the testing area.
Having more comprehensive tests, /and checking them every day/ for early discovery, I think will greatly reduce release-cycle times. Less bugs need to be squashed and hopefully less nasty block bugs too. It is pretty rewarding too to fix a bug measurably by creating a test, and be sure it will not ever fail again without us knowing.
Perhaps this does not sound as much fun as creating a completely new feature. But I think it can be, and I think it is necessary.
I wonder what we can do as a project to stimulate more test writing activity. More visible posting of test writing activity might help. Maybe posting howto's and tips & tricks on writing good tests.
Bryce
The "only" thing missing for me is the workflow and automatic running of tests. My experience is mostly with Git, Github, Bitbucket, Gitlab, Bamboo CI, Travis CI and my own instances of Jenkins. This is purely my own preference and I think with more experience with Bazaar/Launchpad it would work good-enough as well but overall, launchpad seems outdated as a useful "tool".
When pushing a feature branch to my own fork in Github and within seconds/minutes (depending on size of project) I know from Travis CI that my code didn't mess things up, and I can now send a pull request to mainline. This is enough for me to dig into refactoring code/writing unit tests. Gerrit is also a pretty good tool when it comes to code review.
On Tue, Nov 25, 2014, at 10:54 PM, Christoffer Holmstedt wrote:
The "only" thing missing for me is the workflow and automatic running of tests. My experience is mostly with Git, Github, Bitbucket, Gitlab, Bamboo CI, Travis CI and my own instances of Jenkins. This is purely my own preference and I think with more experience with Bazaar/Launchpad it would work good-enough as well but overall, launchpad seems outdated as a useful "tool".
FYI, I've done this in the past with Inkscape by using CruiseControl. Sometimes I even had two instances running - one watching the server and one watching my local working filesystem.
Not sure if I have any of the config laying around... but one of the factors for using CruiseControl was being able to get it installed and running in under 20 minutes. So it should be not to hard to get those others going. Mainly a matter of setting the right trigger and then configuring to invoke "make check"
2014-11-26 8:03 GMT+01:00 Jon A. Cruz <jon@...18...>:
On Tue, Nov 25, 2014, at 10:54 PM, Christoffer Holmstedt wrote:
The "only" thing missing for me is the workflow and automatic running of tests. My experience is mostly with Git, Github, Bitbucket, Gitlab, Bamboo CI, Travis CI and my own instances of Jenkins. This is purely my own preference and I think with more experience with Bazaar/Launchpad it would work good-enough as well but overall, launchpad seems outdated as a useful "tool".
FYI, I've done this in the past with Inkscape by using CruiseControl. Sometimes I even had two instances running - one watching the server and one watching my local working filesystem.
Not sure if I have any of the config laying around... but one of the factors for using CruiseControl was being able to get it installed and running in under 20 minutes. So it should be not to hard to get those others going. Mainly a matter of setting the right trigger and then configuring to invoke "make check"
-- Jon A. Cruz jon@...18...
Thanks for the information, never heard of CruiseControl before but seems simple enough to use. -- Christoffer Holmstedt
On Wed, Nov 26, 2014 at 07:54:04AM +0100, Christoffer Holmstedt wrote:
2014-11-26 1:27 GMT+01:00 Bryce Harrington <bryce@...961...>:
On Tue, Nov 25, 2014 at 11:38:45PM +0100, Johan Engelen wrote:
[...]
To help with refactoring: reinvigorate unittests + rendertests. This is already started at jenkins.inkscape.org:8080, but we should have a larger effort in improving our testsuite (possibly move to other test framework, but at the very least move all unittests into a dedicated tree structure, separate from the src tree);
I've been involved in projects that keep unit tests in trunk, as well as a few where they lived in separate repositories. Universally the latter projects' test suites got ignored and quickly fell out of date. Indeed there got to be kind of a discrimination against test writing as a chore. Consequently the testsuites for those projects atrophied; and the more they atrophied the less seriously they got taken; and the less importance people placed on improving them.
Then there have been projects that not only kept the tests in trunk, but made them *the* priority when developing features. Launchpad was very gung ho on this. Cairo is too, to a lesser extent. The test suite actually ends up taking up an appreciable proportion of the codebase, and you may find yourself putting as much effort into writing the tests as on the feature itself (and maybe even more!) But the result is that when you make any arbitrary change to the codebase, and the testsuite still passes, you feel a very strong sense of confidence that your change is right and hasn't broken anything.
Anyway, this is all to say I feel strongly based on my experience that we should keep all tests that we want to actually work and be useful, IN-tree. And in fact in code reviews one of the first things we should check for is whether new or updated tests are being included.
I assumed that Johan meant "in the same repository but in another directory with proper structure". Moving tests into another repository sounds really weird, never heard of it before.
Ah, whoops my bad, sorry!
and also in extending and improving our rendertestsuite; and possibly also create a UI testsuite or something of the kind (or a cmdline testsuite). In general: TESTING.
+1
UI testing would be really interesting to dig into. I know there are tools for it for web interfaces but haven't seen any for desktop UI. Though I see this as a last step in the testing area.
There are indeed a variety of UI testing frameworks including at least a couple specific to gtk applications for testing the widgetry. I'm not sure how valuable tests will be - "Widget UI" usually either works or it doesn't most of the time, and it gets reworked often which risks tests bitrotting - but if done judiciously could well prove to be a boon.
For "On Canvas UI" you can test a) behavior, and b) rendering. Behavioral testing might be a bit beyond our capabilities right now, but rendering testing is doable by comparing the rendered screen against reference images. Cairo has this style of test suite, which I've mucked around with and am in process of implementing something similar for Wayland. Since this UI is in-house developed we may get more bang for our buck writing tests for this, but I'm not certain.
Having more comprehensive tests, /and checking them every day/ for early discovery, I think will greatly reduce release-cycle times. Less bugs need to be squashed and hopefully less nasty block bugs too. It is pretty rewarding too to fix a bug measurably by creating a test, and be sure it will not ever fail again without us knowing.
Perhaps this does not sound as much fun as creating a completely new feature. But I think it can be, and I think it is necessary.
I wonder what we can do as a project to stimulate more test writing activity. More visible posting of test writing activity might help. Maybe posting howto's and tips & tricks on writing good tests.
Bryce
The "only" thing missing for me is the workflow and automatic running of tests. My experience is mostly with Git, Github, Bitbucket, Gitlab, Bamboo CI, Travis CI and my own instances of Jenkins. This is purely my own preference and I think with more experience with Bazaar/Launchpad it would work good-enough as well but overall, launchpad seems outdated as a useful "tool".
Johan has been experimenting with Jenkins and automatic running of tests so if this is an area you're interested in, definitely touch base with him. I hope we can expand in this area significantly in the coming releases.
Launchpad is indeed a bit outdated, and unfortunately no longer actively maintained. I don't think we're at a part where we're ready to mass migrate off of it, but I do think we'll probably avoid increasing dependence on it in favor of looking at other services and tools.
Our culture here favors open source including for infrastructural services, as much as is feasible. One thing Launchpad does have going for it is that it *is* (technically) Open Source. But I don't see us on Launchpad in 10 years.
Bryce
On Tue, Nov 25, 2014 at 11:38 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
We've collected a lot of deferred maintenance debt. I think it is time to repay that; we should work on disentangling the spaghetti, improve code readability, polish existing features to high satisfaction, etc. I think once we have done that, we are ready for more adventurous things on the roadmap. What I mean is: put maintenance in the near-future roadmap, and new features further out.
+1
As an occasional contributor I'm still quite often overwhelmed by the complexity of the code base, even after all those years. I might be guilty of adding spaghetti too, can't tell for sure. But IMHO it's not just code readability, it's more that the bigger picture of inkscape that's important. It would help if we had better documentation of Inkscape 's architecture. Is this all we have today?
http://wiki.inkscape.org/wiki/index.php/Architectural_overview http://wiki.inkscape.org/wiki/index.php/SubsystemRearchitecture http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/download/head:/arch...
Regards,
Diederik
On Tue, Nov 25, 2014 at 11:38 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
For me, the biggest area of "win" for us is becoming more stable and polishing things. At the GSoC Summit, a friendly guy told us that we don't have to think about what new features to add: "Inkscape is already awesome". A friendly warning for too much "feature gogoGOgO!".
We've collected a lot of deferred maintenance debt. I think it is time to repay that; we should work on disentangling the spaghetti, improve code readability, polish existing features to high satisfaction, etc. I think once we have done that, we are ready for more adventurous things on the roadmap. What I mean is: put maintenance in the near-future roadmap, and new features further out.
To help with refactoring: reinvigorate unittests + rendertests. This is already started at jenkins.inkscape.org:8080, but we should have a larger effort in improving our testsuite (possibly move to other test framework, but at the very least move all unittests into a dedicated tree structure, separate from the src tree); and also in extending and improving our rendertestsuite; and possibly also create a UI testsuite or something of the kind (or a cmdline testsuite). In general: TESTING. Having more comprehensive tests, /and checking them every day/ for early discovery, I think will greatly reduce release-cycle times. Less bugs need to be squashed and hopefully less nasty block bugs too. It is pretty rewarding too to fix a bug measurably by creating a test, and be sure it will not ever fail again without us knowing.
Perhaps this does not sound as much fun as creating a completely new feature. But I think it can be, and I think it is necessary. Although the results of work on these topics are not directly visible, I think the user /will/ notice it: all existing features will become more predictable, more stable, and more pleasant to work with.
If you agree that large maintenance overall is needed, read the attachment. Warning: put on your friendly smile hat!
- Johan
On 23-11-2014 8:45, Bryce Harrington wrote:
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/RoadmapI'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, Nov 26, 2014 at 10:04:52AM +0100, Diederik van Lierop wrote:
On Tue, Nov 25, 2014 at 11:38 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
We've collected a lot of deferred maintenance debt. I think it is time to repay that; we should work on disentangling the spaghetti, improve code readability, polish existing features to high satisfaction, etc. I think once we have done that, we are ready for more adventurous things on the roadmap. What I mean is: put maintenance in the near-future roadmap, and new features further out.
+1
As an occasional contributor I'm still quite often overwhelmed by the complexity of the code base, even after all those years. I might be guilty of adding spaghetti too, can't tell for sure. But IMHO it's not just code readability, it's more that the bigger picture of inkscape that's important. It would help if we had better documentation of Inkscape 's architecture. Is this all we have today?
http://wiki.inkscape.org/wiki/index.php/Architectural_overview http://wiki.inkscape.org/wiki/index.php/SubsystemRearchitecture http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/download/head:/arch...
Thanks for the input, and you're right. This ought to be a lot better. What we do have came years ago after a complaint quite similar to what you're making today, and likely is a bit obsolescent now. It seems that once someone understands the codebase architecture well enough to document it, they lose the need for (and thus interest in writing) said documentation! :-)
Can you pose some architectural questions that we could use to help guide documentation writing?
Bryce
Diederik
On Tue, Nov 25, 2014 at 11:38 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
For me, the biggest area of "win" for us is becoming more stable and polishing things. At the GSoC Summit, a friendly guy told us that we don't have to think about what new features to add: "Inkscape is already awesome". A friendly warning for too much "feature gogoGOgO!".
We've collected a lot of deferred maintenance debt. I think it is time to repay that; we should work on disentangling the spaghetti, improve code readability, polish existing features to high satisfaction, etc. I think once we have done that, we are ready for more adventurous things on the roadmap. What I mean is: put maintenance in the near-future roadmap, and new features further out.
To help with refactoring: reinvigorate unittests + rendertests. This is already started at jenkins.inkscape.org:8080, but we should have a larger effort in improving our testsuite (possibly move to other test framework, but at the very least move all unittests into a dedicated tree structure, separate from the src tree); and also in extending and improving our rendertestsuite; and possibly also create a UI testsuite or something of the kind (or a cmdline testsuite). In general: TESTING. Having more comprehensive tests, /and checking them every day/ for early discovery, I think will greatly reduce release-cycle times. Less bugs need to be squashed and hopefully less nasty block bugs too. It is pretty rewarding too to fix a bug measurably by creating a test, and be sure it will not ever fail again without us knowing.
Perhaps this does not sound as much fun as creating a completely new feature. But I think it can be, and I think it is necessary. Although the results of work on these topics are not directly visible, I think the user /will/ notice it: all existing features will become more predictable, more stable, and more pleasant to work with.
If you agree that large maintenance overall is needed, read the attachment. Warning: put on your friendly smile hat!
- Johan
On 23-11-2014 8:45, Bryce Harrington wrote:
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/RoadmapI'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl...
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 26/11/14 10:17, Bryce Harrington wrote:
On Wed, Nov 26, 2014 at 10:04:52AM +0100, Diederik van Lierop wrote:
http://wiki.inkscape.org/wiki/index.php/Architectural_overview http://wiki.inkscape.org/wiki/index.php/SubsystemRearchitecture http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/download/head:/arch...
Thanks for the input, and you're right. This ought to be a lot better. What we do have came years ago after a complaint quite similar to what you're making today, and likely is a bit obsolescent now. It seems that once someone understands the codebase architecture well enough to document it, they lose the need for (and thus interest in writing) said documentation! :-)
I'm trying to add at least doxygen comments to everything I need to figure out while implementing the "flatten vectors" feature I need.
Can you pose some architectural questions that we could use to help guide documentation writing?
- How are objects stored? How can they be accessed / modified / how can I find out if they are clipped etc. - How is object storage related to SVG? e.g. SPDocument->SPRoot <--> <svg>, to me that was non-obvious - Is every Object (except SPDocument->SPRoot) guaranteed to have a parent object?
Alexander
On 26/11/14 10:17, Bryce Harrington wrote:
Can you pose some architectural questions that we could use to help guide documentation writing?
What's the difference between an SPObject and an SPItem? Which svg elements translate into an SPItem, which into an SPObject?
Alexander
Hi Bryce,
On Wed, Nov 26, 2014 at 10:17 AM, Bryce Harrington < bryce@...961...> wrote:
Can you pose some architectural questions that we could use to help guide documentation writing?
These are the things I've been digging into in the past few years: - What does SP stand for (took me a while to find that out) - What's the purpose of each of these classes: SPDocument, SPView, SPNamedView, SPCanvas - How does Inkscape handle multiple open documents and multiple views - Actions, Verbs, shortcuts, ... - How does inkscape go from parsing the XML file to storing the objects, - How are these objects displayed, modified, and saved again to XML - How are changes from the XML (editor) propagating to the objects, and vice versa - Where does the GUI hook into this? - What about filters, LPEs, .... - Rendering on screen, vs. rendering for printing, vs. rendering for exporting - Extensions, python/javascript API, DBus, command line interface
I don't think we need very detailed information on all this stuff (although that would help too), but at least it should be authoritative, with useful pointers and references. Figuring out the details is not a problem.
Diederik
These are the things I've been digging into in the past few years:
- What does SP stand for (took me a while to find that out)
- What's the purpose of each of these classes: SPDocument, SPView,
SPNamedView, SPCanvas
- How does Inkscape handle multiple open documents and multiple views
- Actions, Verbs, shortcuts, ...
- How does inkscape go from parsing the XML file to storing the objects,
- How are these objects displayed, modified, and saved again to XML
- How are changes from the XML (editor) propagating to the objects, and
vice versa
- Where does the GUI hook into this?
- What about filters, LPEs, ....
- Rendering on screen, vs. rendering for printing, vs. rendering for
exporting
- Extensions, python/javascript API, DBus, command line interface
I don't think we need very detailed information on all this stuff
(although that would help too), but at least it should be authoritative, with useful pointers and references. Figuring out the details is not a problem.
Diederik
Isn't some of that covered in doc/ ?
Sure, there's some information in doc/. But it's amazingly shallow and outdated. The most relevant files there haven't been touched for about 10 years!
Diederik
On Sat, Nov 29, 2014 at 9:06 PM, Liam White <inkscapebrony@...400...> wrote:
These are the things I've been digging into in the past few years:
- What does SP stand for (took me a while to find that out)
- What's the purpose of each of these classes: SPDocument, SPView,
SPNamedView, SPCanvas
- How does Inkscape handle multiple open documents and multiple views
- Actions, Verbs, shortcuts, ...
- How does inkscape go from parsing the XML file to storing the objects,
- How are these objects displayed, modified, and saved again to XML
- How are changes from the XML (editor) propagating to the objects, and
vice versa
- Where does the GUI hook into this?
- What about filters, LPEs, ....
- Rendering on screen, vs. rendering for printing, vs. rendering for
exporting
- Extensions, python/javascript API, DBus, command line interface
I don't think we need very detailed information on all this stuff
(although that would help too), but at least it should be authoritative, with useful pointers and references. Figuring out the details is not a problem.
Diederik
Isn't some of that covered in doc/ ?
From the top of my head... some possible topics for infrastructure improvement:
* Google test support + add extensive set of unit tests * Get rid of all forks of common embedded libs (gdl, libcroco etc) * Fix -Werror builds for all deprecated symbols * Decide on a preferred build system (autotools/Cmake/waf) and kill the others * Fix Gtk+ 3 support (lots of UX testing needed)... eventually drop Gtk+ 2 support * ...on that note, maybe we need to define some kind of formal UX testing programme? * Start using C++11 features to clean-up code: auto declarations, range-based for loops etc * Complete Doxygen docs (-Wdocumentation in Clang)
Cheers,
AV
On 29 November 2014 at 21:05, Diederik van Lierop <mail@...1689...> wrote:
Sure, there's some information in doc/. But it's amazingly shallow and outdated. The most relevant files there haven't been touched for about 10 years!
Diederik
On Sat, Nov 29, 2014 at 9:06 PM, Liam White <inkscapebrony@...400...> wrote:
These are the things I've been digging into in the past few years:
- What does SP stand for (took me a while to find that out)
- What's the purpose of each of these classes: SPDocument, SPView,
SPNamedView, SPCanvas
- How does Inkscape handle multiple open documents and multiple views
- Actions, Verbs, shortcuts, ...
- How does inkscape go from parsing the XML file to storing the objects,
- How are these objects displayed, modified, and saved again to XML
- How are changes from the XML (editor) propagating to the objects, and
vice versa
- Where does the GUI hook into this?
- What about filters, LPEs, ....
- Rendering on screen, vs. rendering for printing, vs. rendering for
exporting
- Extensions, python/javascript API, DBus, command line interface
I don't think we need very detailed information on all this stuff (although that would help too), but at least it should be authoritative, with useful pointers and references. Figuring out the details is not a problem.
Diederik
Isn't some of that covered in doc/ ?
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Here is my personal wishlist of things that need to be fixed for 0.92.
1. We need to re-enable the Document Properties setting that allows us to specify the variable inkscape:document-units. I understand that this was disabled for the purpose of being able to release 0.91. But now that we are discussing 0.92 this setting should be re-enabled in trunk. The point is that we cannot evaluate, or test, or fix, the bugs associated with changing document units in current trunk, see Bug 1397564.
2. I believe a suggestion has been made that we might want to distinguish between Display Units and Document Units (or what was previously called Default Units) in the future, after changing Document Units has been re-enabled in trunk. (Unfortunately I cannot locate the precise reference). I would like to vote against that, even before the vote is held. We already have far too many different definitions of units as it is. I have counted, in the gui, no less than 12 different locations where a drop down box exists that allows you to change units, including things like Prefs and Fill&Stroke and so on. This is too many. We need to reduce the number of different definitions of units, not add more. No user can be expected to make sense out of this, I certainly can't.
3. On the same subject, the interaction between these different drop down boxes is sometimes unpredictable, meaning that it is sometimes one way. For example, changing Display Units in Document Properties will change the units associated with the F1 toolbar if it is active. However any change in the F1 toolbar units will not affect the Display Units. The same type of one-way linkage occurs also for F2, M, and F4. I would suggest that one-way linkages of this type should be forbidden because they are confusing.
4. On a somewhat similar note, the namedview section of XML contains a variable called 'units', which appears to be redundant, since the page size units are now stored directly in the width and height variables in the root. I would suggest it be removed. I would be more than happy to fix any breakage that might occur in the Python Extension system as a result.
5. For aesthetic reasons I would like to see someone tackle Bug 1369197 which relates to transformation of displacements during a unit change. I think this is probably beyond me, but it gives the Inkscape representation a very unexpected/unpredictable behavior after applying a unit change.
hth, Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Roadmap-brainstorming-for-0-92-and-forward-... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Hi Alvin, I think your confusion stems from using "document units". This name is very ambiguous and should not be used. Instead, distinguish between "Display units" and "SVG units" (SVG "user-units"). Display units is for UI purposes, and is completely (*completely*) unrelated to the units for the values in SVG.
"inkscape:document-units" specifies Display units (as it always has), and is unrelated to SVG units. The big problem we had in trunk was that "inkscape:document-units" was mixed with SVG units. We killed that, and now most is fine again, afaik.
SVG units are defined by document height/width (defaults to "px" units) and the viewbox numbers. From that information, Inkscape (and python script inkex.py) calculates the SVG unit. Only issue I know of, is that when a user manually changes the viewbox, without an according change in document height/width, Inkscape does not recalculate what SVG unit is used. You would have to reload the file. Also, Inkscape at the moment does not support SVG units other than the units it knows of upon load. This is easy to fix, however not done yet.
On 30-11-2014 18:18, alvinpenner wrote:
Here is my personal wishlist of things that need to be fixed for 0.92.
- We need to re-enable the Document Properties setting that allows us to
specify the variable inkscape:document-units. I understand that this was disabled for the purpose of being able to release 0.91. But now that we are discussing 0.92 this setting should be re-enabled in trunk. The point is that we cannot evaluate, or test, or fix, the bugs associated with changing document units in current trunk, see Bug 1397564.
Specifying inkscape:document-units from the Document Properties dialog has never been disabled. 0.91 and trunk actually behave the same for units. You can change display units (like all previous versions of Inkscape), and there is no UI for changing SVG units.
- I believe a suggestion has been made that we might want to distinguish
between Display Units and Document Units (or what was previously called Default Units) in the future, after changing Document Units has been re-enabled in trunk. (Unfortunately I cannot locate the precise reference). I would like to vote against that, even before the vote is held.
We have proven that we cannot do it (combining Display units and SVG units). We now have separated the difference between Display units and SVG units clearly in code, and poofff!, gone are the bugs and problems. :)
We already have far too many different definitions of units as it is. I have counted, in the gui, no less than 12 different locations where a drop down box exists that allows you to change units, including things like Prefs and Fill&Stroke and so on. This is too many. We need to reduce the number of different definitions of units, not add more. No user can be expected to make sense out of this, I certainly can't.
This is a separate issue. And really, all those dropboxes relate to Display units.
- On the same subject, the interaction between these different drop down
boxes is sometimes unpredictable, meaning that it is sometimes one way. For example, changing Display Units in Document Properties will change the units associated with the F1 toolbar if it is active. However any change in the F1 toolbar units will not affect the Display Units. The same type of one-way linkage occurs also for F2, M, and F4. I would suggest that one-way linkages of this type should be forbidden because they are confusing.
- On a somewhat similar note, the namedview section of XML contains a
variable called 'units', which appears to be redundant, since the page size units are now stored directly in the width and height variables in the root. I would suggest it be removed. I would be more than happy to fix any breakage that might occur in the Python Extension system as a result.
Sounds good, go ahead and kill it.
- For aesthetic reasons I would like to see someone tackle Bug 1369197
which relates to transformation of displacements during a unit change. I think this is probably beyond me, but it gives the Inkscape representation a very unexpected/unpredictable behavior after applying a unit change.
This is one of the many difficulties in actually changing the SVG units for an existing document.
- Johan
On Sat, Nov 29, 2014 at 9:06 PM, Liam White <inkscapebrony@...400...> wrote:
These are the things I've been digging into in the past few years:
- What does SP stand for (took me a while to find that out)
- What's the purpose of each of these classes: SPDocument, SPView,
SPNamedView, SPCanvas
- How does Inkscape handle multiple open documents and multiple views
- Actions, Verbs, shortcuts, ...
- How does inkscape go from parsing the XML file to storing the
objects,
- How are these objects displayed, modified, and saved again to XML
- How are changes from the XML (editor) propagating to the objects, and
vice versa
- Where does the GUI hook into this?
- What about filters, LPEs, ....
- Rendering on screen, vs. rendering for printing, vs. rendering for
exporting
- Extensions, python/javascript API, DBus, command line interface
I don't think we need very detailed information on all this stuff
(although that would help too), but at least it should be authoritative, with useful pointers and references. Figuring out the details is not a problem.
Diederik
To add to the discussion we had a month ago about the documentation of
Inkscape's architecture, I've thought of some additional topics that would be very useful for both new and not-so-new devs: - Tav's wrap-up of the units discussion - Tav's recent blog post on planet.inkscape.org, although some of this is already documented in /docs I guess. I especially like this part: "what the heck is an ‘arenaitem’?" - Some pointers to the use of affine transformations and homogeneous coordinates (not just in Inkscape, but for SVG in general). Just linking to the relevant Wikipedia pages is already a big step, e.g. http://en.wikipedia.org/wiki/Affine_transformation.
Regards,
Diederik
On Fri, 2015-01-02 at 23:12 +0100, Diederik van Lierop wrote:
On Sat, Nov 29, 2014 at 9:06 PM, Liam White <inkscapebrony@...400...> wrote: > These are the things I've been digging into in the past few years: > - What does SP stand for (took me a while to find that out) > - What's the purpose of each of these classes: SPDocument, SPView, SPNamedView, SPCanvas > - How does Inkscape handle multiple open documents and multiple views > - Actions, Verbs, shortcuts, ... > - How does inkscape go from parsing the XML file to storing the objects, > - How are these objects displayed, modified, and saved again to XML > - How are changes from the XML (editor) propagating to the objects, and vice versa > - Where does the GUI hook into this? > - What about filters, LPEs, .... > - Rendering on screen, vs. rendering for printing, vs. rendering for exporting > - Extensions, python/javascript API, DBus, command line interface > > I don't think we need very detailed information on all this stuff (although that would help too), but at least it should be authoritative, with useful pointers and references. Figuring out the details is not a problem. > > DiederikTo add to the discussion we had a month ago about the documentation of Inkscape's architecture, I've thought of some additional topics that would be very useful for both new and not-so-new devs:
Tav's wrap-up of the units discussion
Tav's recent blog post on planet.inkscape.org, although some of this
is already documented in /docs I guess. I especially like this part: "what the heck is an ‘arenaitem’?"
- Some pointers to the use of affine transformations and homogeneous
coordinates (not just in Inkscape, but for SVG in general). Just linking to the relevant Wikipedia pages is already a big step, e.g. http://en.wikipedia.org/wiki/Affine_transformation.
I would really like better documentation of the SP tree. It is not clear what many of the various SPObject methods are suppose to do despite hints from their names. For example, what exactly are these functions suppose to do?
SPObject::build() SPObject::invoke_build() SPObject::set() SPObject::update() SPObject::modified()
This becomes more relevant in the derived classes. For example, why is Inkscape::DrawingShape::setStyle() called in
SPShape::update() SPShape::modified() SPShape::show()
Some operations result in calls to all three functions, thus style is being set three times when it need be called once.
It is interesting to put in random print statements and see just how often some functions are called on what should be simple operations. Type a single character in the text tool and Layout::_clearInputObjects() is called seven times!
Tav
participants (20)
-
Alex Valavanis -
Alexander Brock -
Alexandre Prokoudine -
alvinpenner -
Bryce Harrington -
Brynn -
Christoffer Holmstedt -
Diederik van Lierop -
Gez -
ivan louette -
Johan Engelen -
Jon A. Cruz -
Josh Andler -
Krzysztof Kosiński -
Liam White -
Martin Owens -
Ryan Lerch -
Sebastian Zartner -
Tavmjong Bah -
Teto