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 :

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:

On Mon, Nov 24, 2014 at 10:46:39PM +0100, Sebastian Zartner wrote: 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 Mon, Nov 24, 2014 at 07:13:55PM -0700, Brynn wrote: 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. 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

On Mon, Nov 24, 2014 at 8:46 PM, Krzysztof Kosiński <tweenk.pl@...972.....> wrote: In trunk, is "Object>Objects..." not quite there? Cheers, Josh

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...>:

2014-11-25 21:38 GMT+01:00 Bryce Harrington <bryce@...961...>: 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

On Tue, Nov 25, 2014 at 7:46 AM, Krzysztof Kosiński wrote: What about align on-canvas stuff that Martin added last year? https://code.launchpad.net/~doctormo/inkscape/align-handles Did anybody evaluate the results of this GSoC project? https://code.launchpad.net/~inkscape.dev/inkscape/symmetry-tool Alex

On 25-11-2014 20:54, Johan Engelen wrote: Not fair and not true. It is some other bug somewhere that causes misbehavior with clones atm. - Johan

On 25-11-2014 23:08, Martin Owens wrote: 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)

2014-11-25 5:55 GMT+01:00 Josh Andler <scislac@...400...>: 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? 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? 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...>: 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

2014-11-29 0:01 GMT+01:00 Martin Owens <doctormo@...400...>: 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

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-forwa... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

El mar, 25-11-2014 a las 05:46 +0100, Krzysztof Kosiński escribió: +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.

Inkscape user community in the brainstorming, would be a great source of 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 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:

On Tue, Nov 25, 2014 at 6:03 PM, Ryan Lerch 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. Alex

On Tue, Nov 25, 2014 at 7:19 AM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote: +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 11/25/2014 02:27 PM, Alexandre Prokoudine wrote: 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

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:

2014-11-26 1:27 GMT+01:00 Bryce Harrington <bryce@...961...>: [...] 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. 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. 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.

2014-11-26 8:03 GMT+01:00 Jon A. Cruz <jon@...18...>: Thanks for the information, never heard of CruiseControl before but seems simple enough to use. -- Christoffer Holmstedt

On Tue, Nov 25, 2014 at 11:38 PM, Johan Engelen <jbc.engelen@...2592...> wrote: +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:/a... 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!". > > 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/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... > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > >

On 26/11/14 10:17, Bryce Harrington wrote: I'm trying to add at least doxygen comments to everything I need to figure out while implementing the "flatten vectors" feature I need. - 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

Hi Bryce, On Wed, Nov 26, 2014 at 10:17 AM, Bryce Harrington < bryce@...961...> 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

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:

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-forwa... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

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