- Inkscape Devel - Inkscape Mailman

Roadmap 1.0
by Bryce Harrington 08 Apr '18

08 Apr '18

One of the items scheduled for today was a review of the roadmap, looking both at the next development release, and the path to releasing 1.0. With the change to gtk3, we anticipate there may be some behavioral or functional changes that users may not find desireable, but that we may not discover until the release gets into widespread use, so it has been our plan to message this development release (which we have referred to as 0.93) as more "experimental" than 0.92, and continue releases on the 0.92.x series for them. Even with this messaging, though, we worry that distributors of our software may push 0.93 as the latest release, and fail to adequately provide the 0.92.x series to users that wish to maximize stability. So, one idea discussed today would refer to this development release not as "inkscape 0.93" but as either "inkscape 1.0~alpha" or "inkscape 1.0~pre0", and treat it not as a regular release but as an alpha release for 1.0. From there we could conduct multiple further pre-releases building towards a 1.0 release in, say, a 1-year timeframe. What do you think of this change in versioning nomenclature? Regardless of how we version the releases, there was a concensus among attendees to sharpen our focus towards achieving the 1.0 release expediously, prioritizing stabilization, testing, and documentation efforts. Apart from a limited set of development tasks targeted for 1.0, most development would be strongly encouraged to be done in branches with merge deferred to post-1.0. As requested at the hackfest, I'll take the action to itemize a listing of tests needing written or ported from the old test system, and divvying them out to currently active developers willing to take care of them. For development work that does target landing in 1.0, we would require or at least urge the work be done in a manner that permits disabling or reverting it if testing finds it to be insufficiently stable. I am pretty open as to what we call the pre-1.0 releases, and would like to gather more people's thoughts before deciding a path forward. So, how does this plan sound to you? Bryce

9 18

Hackfest 2018: Actions and Toolbars
by Alex Valavanis 06 Apr '18

06 Apr '18

Hi All, Here's a summary of my work at the Boston Hackfest. Before I continue, I'd like to thank everyone who donated their money or time to support this Hackfest. This has been a really useful event - it's so much easier to deal with tricky design challenges and project management stuff when we can meet face to face. It has also brought together people with very diverse expertise across the project (UI, web, build, extensions, project management etc). This week, we've figured out a path to deliver long desired features (multipage support etc), roadmapped our final route to deliver Inkscape 1.0, done some great website design work, and handled some tricky code structure issues that I'll discuss in this message. If you're able to donate some money to support Inkscape, and future Hackfests, we really appreciate this. You can find the donation link on our website: https://inkscape.org/en/support-us/hackfests/ It would also be great to get some more of the regular contributors from our wider community to join us at future events (i.e., designers, bug-team, experienced users... not just C++ developers!). The developers can learn so much more about the project by discussing it with you. So... what have I been doing this week? == What are Actions? == Basically, an "action" is a thing that Inkscape can do (e.g., flip an object horizontally), which we can identify using an ID code (e.g., "SP_VERB_OBJECT_FLIP_HORIZONTAL"). We can then hook up buttons, menu items etc to activate these actions. In this example, we would set up our Flip Horizontal button in the select-tool toolbar so that when the user clicks it, it activates the required action. My work this week has focused on improving the way we implement actions in our code, which will 1. Allow Inkscape to run on machines with future versions of the Gtk+ library (Gtk 4+) 2. Provide much better separation between the behaviour and user interface (i.e.,, separate pieces of the code will describe what Inkscape "does", and what it "looks like") 3. Make it much easier to create new "flavours" of the Inkscape user interface - for example, an "Inkscape for Kids" or "Inkscape CAD" 4. Make it easier for "non-programmers" to create and reorganise custom toolbars and dialogs 5. Allow us to remove a lot of older "C" code that is very difficult for current "C++" developers to maintain == Where we are now? == In the Inkscape code, we have a mechanism called "verbs" that acts as a kind of action mechanism... it provides a way of using an ID code to look up the required commands to perform an action. On top of this, we have another structure called SPAction that essentially hooks up a couple of signals to the verb. Finally(ish), we use objects called GtkActions from the Gtk+ library, which let us create GUI elements (buttons etc) that we can add to our menus or toolbars that activate the required action. We have also got a few custom sub-classes of GtkAction that let us create special kinds of tool-item that can activate actions... for example, one of these creates a spin-button (a box with a number in it, and "up/down" arrows) that can also handle units, basic arithmetic, and provides a label. == What's the problem? == First, the GtkAction widget (and hence all our custom sub-classes) is deprecated and has been removed from Gtk+ 4, so we need to change. Since Inkscape 1.0 is intended as a "stable" release, we want to make it as future-proof as possible. The main reason for this deprecation is that the GtkAction widget is a slightly weird mix of paradigms: it mixes information about how to display a tool/menu item with information about behaviour. This causes some problems... what if we wanted to run a "headless" Inkscape on a system that has no display? What if we wanted to provide several different GUI options for different kinds of user to trigger the same behaviour? This is one of the reasons why we have the "verbs" system is in place, as it separates behaviour from the GUI. However, there is still quite a lot of code "overhead" needed if we want to hook up Inkscape's Verb behaviour to a GUI element. Essentially, it's "programmers only" territory. What if a designer wanted to add a new toolbar button to their Inkscape to handle a useful feature that is currently buried deep in a menu? What if a teacher wanted to strip out a lot of "advanced" behaviour from the interface to make it easier to introduce Inkscape to their class? At the moment, they have to edit the C++ code, and recompile it... a slow and complicated process! == Where are we going? == We need to move to using GActions (a feature in the Glib/GIO library). This *only* describes the action's behaviour and provides an "activated" signal that we can trigger by simply knowing the action's name. This is completely separated from the GUI. These actions can be activated very easily from a whole range of places, for example: 1. By attaching the action's name to a GUI element in the C++ code (replacing our SPAction/GtkAction code) 2. By activating the action (using its name) from a command-line interface (replacing some of our verbs code) 3. By attaching the action's name to elements in a customised GUI file 4. From external applications, using the DBus system Number 3 in the list provides some very exciting opportunities for future releases, as non-programmers will be able to make a customised user interface by drawing one in the Glade application. You then just attach the name of the required Inkscape action to each GUI element. Want a new button? Just edit Inkscape's user-interface file in Glade and see the changes immediately next time you start... no C++ knowledge needed! == What have I done so far? == I've started working through Inkscape's toolbars, and have replaced the deprecated GtkAction-based widgets with standard widgets (buttons etc). Some of these now hook up to GAction descriptions of behaviour, while others are just based on handling GUI signals (e.g., Button::clicked). So far, I have migrated the toolbars for the Select, Dropper and Connector toolbar, and have killed off a couple of the custom GtkAction-based widgets that were only used in these. In the process, I have also migrated the toolbar code to C++, which should make it a little easier for the current core developers to maintain. Since all the data is now stored as C++ member variables, rather than as GObject data, we now benefit from better compile-time and run-time type-checking that will help to safeguard against errors being introduced in the code in future. I have placed the updated toolbars in the Inkscape::UI::Toolbar namespace and made them into proper sub-classes of the Gtk::Toolbar class. == How can you help? == This important refactoring project must be done before Gtk+ 4 is widely used, and represents a major change to the way that our toolbars are implemented. It represents a couple of thousand lines of code changes and will inevitably cause some regression bugs. I will need your help in thoroughly testing that all the toolbars work correcly! All of these changes are currently in a git branch ("gtk-actions-migration") and will not be merged into the master branch until preliminary testing has been completed. In other words, this will not "mess up" your stable version of Inkscape and will never be part of the current 0.92.x release series! I intend to merge this work well in advance of the Inkscape 1.0 release, so that we have plenty of time for very thorough developer and user testing, and several preliminary bug-fix "alpha" pre-releases before the final stable release. For the very brave: please checkout the "gtk-actions-migration" branch in git, rebuild and test. Please note that this is work-in progress. Do not use this experimental branch for your regular Inkscape drawing work!!! The Node toolbar will not work... the Select, Dropper and Connector toolbars are highly experimental; all the other toolbars are "at risk"! If you don't know how to do this, check out our developer guide. For the quite brave: I'll merge this experimental branch into our master development branch in a few weeks once (a) I've completed the basic work, (b) I've had a good amount of feedback on the branch and know that it "works" to some extent. I'll message you again at this stage and ask everyone to help look for bugs. Again, this will only be visible to developers and users of our experimental "trunk" PPA in Ubuntu. For the intrepid: If you're interested in helping with the code migration - message me and I'll help to divide up the tasks. == The end == I hope this gives an insight into the work I've started doing this week, and will continue over the coming weeks. Thanks once again to everyone who has contributed time, money or even just attention and enthusiasm for the Hackfest. Best wishes, Alex Valavanis (valavanisalex) Inkscape developer

7 11

Board meeting Fri Apr 6
by Bryce Harrington 06 Apr '18

06 Apr '18

Sorry for the late notice on this one. Our monthly board meeting is scheduled for this Friday, Apr 6th, at 10am Pacific in #inkscape-devel. All members are welcome. http://wiki.inkscape.org/wiki/index.php/Board_Meetings Agenda: + Merchandise sales [crogers] + LGM 2018 [Tav] + GSoC [ScislaC] + Other Business

1 0

Hackfest / lost and found
by Máirín Duffy 06 Apr '18

06 Apr '18

Hi everyone :) We found an Asus digitizer pen in the area where the Inkscape Hackfest was found. I was wondering if any hackfest participant may have lost it? I am happy to ship it home to you. Cheers, ~m

5 6

Feeling stressed?
by Bryce Harrington 04 Apr '18

04 Apr '18

Hi all, I've been picking up a lot of indicators of stress in our project participants. Each seems to be a unique case, with a different cause, and so there can be no universal solution. But if you're feeling stressed it might help to take a look at a broader perspective, and see some of the great progress being made. We just completed a very effective Hackfest. We burned through our list of discussion topics and unblocked progress on multiple fronts, and helped get each other on the same page on several topics. I think everyone came away energized, a bit overwhelmed, and enthusiastic to get moving on some big efforts. It was an intense week. I wish everyone could have come! We want to organize future hackfests to be more convenient for you, so everyone gets a chance to benefit from face-to-face time with each other. The Inkscape 1.0 release is now visible on the horizon, which is very exciting and will be a massive achievement for our project. There is still planning to be done, and it'll be probably about a year before we reach it, but a lot of path clearing has been done the past couple weeks to ensure we can head there at full speed. Print/color management, multi-page, GActions, and more are starting to get charted out; 1.0 is not going to be the end of the road, but rather the start on some major innovations for Inkscape. It is almost overwhelming to think of all the work needed, but know that while they'll be progressing in parallel, our focus right now is the 1.0 release. People have been very understanding that we have to pace ourselves and prioritize stability right now. Several changes are afoot for our infrastructure - mailing lists, merchandise, forums, a website redesign, and bug tracking all have improvements under way. Quite a bit to do, but will strengthen both our user and contributor communities, and we have plenty of time to do them. Another bit of very good news is that Inkscape is doing well monetarily. At the start of FY2017 we had $18,414; after one year this has grown to $45,732. This is thanks both to prolific individual donors and several very generous sponsoring companies -- people believe in us and what we're doing, and are providing us with financial resources to do even more. Looking at this past month's financial data, donations appear to have picked up even more, and we've several potential sponsors that will likely pitch in once they see some plans for specific features they're interested in. All of this funding gives Inkscape a lot of flexibility to do more to improve both the software and the community. And, to boot, efforts on new fundraising sources are in process, which could kick us off in a 'virtuous circle'. At least some people are finding stress from the sheer amount of different things, and how quickly they're progressing. I sure feel it. I just want to say - pace yourself. Don't be afraid of letting others take over some of your tasks, and don't be shy about asking for load sharing if you feel overwhelmed. Please email me privately if you need help. I expect things will even out better in the next few months -- the release and the hackfest caused acceleration on a bunch of stuff, but the next few weeks should get quieter as people take time to digest. In some cases, the stress has shown itself in various discussions. Please know we're taking these seriously and working behind the scenes to improve relationships. This community wrote a remarkably good Code of Conduct for itself, well worth reading (or re-reading): https://inkscape.org/en/community/coc/ In the next week or so I'll post a plan for getting us to 1.0, with specific tasks that we'll need people to pitch in on. Meanwhile, take some time to get recentered and get the stresses eliminated. :-) Hugs and cheers, Bryce

2 1

Re: [Inkscape-devel] Hackfest 2018: Actions and Toolbars
by jelle 03 Apr '18

03 Apr '18

Hi all, A lot of exiting things going on here. Separating the GUI from the functionality of Inkscape and allowing to use it as a command line tool sounds really cool. Now the question that arises to me is whether that means Inkscape could be used as a service and output could get rendered to a client browser? That would allow for a wide variety of GUI's to be developed that could cater to specific uses. I could envision a touch version and probably a VR interface would be more of an option as well. Obviously the fast rendering with Cairo would be lost that way, but for limited use cases (for instance without filters) that should be fast enough I think. Cheers, Jelle

5 6

New Das Stroke LPE
by Jabier Arraiza 01 Apr '18

01 Apr '18

Hey folks, Whit the help of Lazur and the thread: http://www.inkscapeforum.com/viewtopic.php?f=22&t=24175&p=83448&hilit=s troke+dash#p83448 just do a tiny LPE to fix it. Here are the new video showing it (no audio): https://archive.org/details/dash-stroke-lpe Hope is useful since is not included in the SVG spec. With love, Jabiertxo.

1 1

Hackfest 2018: Variable fonts, refactoring, etc.
by Bryce Harrington 01 Apr '18

01 Apr '18

----- Forwarded message from Tavmjong Bah <tavmjong@...8...> ----- Date: Sun, 01 Apr 2018 03:31:32 +0200 From: Tavmjong Bah <tavmjong@...8...> To: Bryce Harrington <bryce@...961...> Subject: Hackfest 2018: Variable fonts, refactoring, etc. Bryce, can you forward this to the inkscape-devel list? SourceForge is blocking my Internet provider's mail server. Thanks. Hi, Before I start my report on the Boston Hackfest, I would like to thank Martin Owens, our Inkscape host, and Máirín Duffy, our Red Hat host. Martin did a great job of showing us around Boston and making sure we were properly fed (even cooking us a lunch!). Máirín, a designer at Red Hat, gave us great feedback on Inkscape in its current form and on our plans for future Inkscape versions. I would also like to thank the other Red Hatters, especially Matthias Clasen, who helped make this hackfest a success! And I would like to thank the many donors to the Inkscape hackfest fund that make these hackfests possible. I'll start with the item that will most excite Inkscape users: Variable Font Support in Inkscape. Variable fonts are fonts that contain "axes" that can be tweaked by the user. The simplest example would be a font that contains an axis for weight. Instead of being limited to a few discrete font weights, each requiring its own font file, a user of variable fonts can with just one file select weights with any values continuously between a minimum and maximum value. Prior to the hackfest I got rendering of variable fonts working in Inkscape. This required handling the CSS property used to set the axes and modifying the rendering code to use the axes. (I should mention that this only works with very new versions of the libraries we use to handle fonts and text.) At the hackfest I worked with Felipe on adding support to the user interface. Felipe got a prototype version working during the hackfest. Felipe and I also had discussion with Matthias, a Red Hat employee who works on GTK about Matthias' improved GTK Font Selection widget to which he has added variable font support. I spent some time experimenting with replacing the font selection in the Text and Font dialog with the native GTK widget (after getting positive feedback from the designers in the room). Speaking of Matthias. We spent time with him discussing some of the problems we have with GTK. This was very productive, both in validating our move to GActions (discussed already by Alex) as well as getting feed back on a number of other issues. Maybe the biggest blocker in getting to 1.0 is how broken floating dialogs are under the Wayland compositor, a replacement for the X11 window server. The library we use to handle floating dialogs, GDL, is not used by many projects (maybe only two). The code is complex and fixing it to work with Wayland may be too difficult. After feedback from Máirín it appears our best way forward is to replace GDL with use of the GtkNoteBook widget which handles dragging and dropping tabs. (Máirín also finds Gimp's use of tabs to dock dialogs much easier to use than our current system.) One of my biggest beefs about working on Inkscape code is how poorly documented it is. Part of the problem is that code is strewn throughout the repository so it is often hard to find the code that handles a particular thing. This also leads to code duplication as its hard to see that we already have solution to a particular problem. I've proposed a directory reorganization that better sort the code by its purpose. This, and having README files in each directory should help new developers find their way through our code base. After several round of discussion and feedback we've come up with a solid plan which I'll be implementing in the next few weeks. Part of the directory reorganization is to get all the graphical interface code into one place so we can work on isolating the GUI components from other parts. This should allow us to more easily create an efficient command-line version of Inkscape. (Alex's work on GActions should also help us give more power to the command line.) There were quite a few other very useful discussions we had: the road map, documentation, increasing diversity, our website, etc. I personally find that I am not very efficient at actual hacking during hackfests (I work best when I am in the peace and quiet of my own home) but the discussions we have during hackfests leads to great productivity afterwards. Tav ----- End forwarded message -----

1 0

Re: [Inkscape-devel] [Inkscape-user] New Das Stroke LPE
by Jabier Arraiza 01 Apr '18

01 Apr '18

I just see the spec. I hope I can improve the LPE with it. Regards, Jabier On Sun, 2018-04-01 at 14:16 +0200, Tavmjong Bah wrote: > On Sun, 2018-04-01 at 12:51 +0200, Jabier Arraiza wrote: > > Hey folks, > > > > Whit the help of Lazur and the thread: > > http://www.inkscapeforum.com/viewtopic.php?f=22&t=24175&p=83448&hil > > it > > =s > > troke+dash#p83448 just do a tiny LPE to fix it. > > > > Here are the new video showing it (no audio): > > > > https://archive.org/details/dash-stroke-lpe > > Nice! > > > Hope is useful since is not included in the SVG spec. > > If it's an LPE it doesn't need to be in the SVG spec. Have a look at > this to see what the SVG group was thinking about before it was > removed > from the SVG 2 spec: > > https://svgwg.org/specs/strokes/#StrokeDashing > > > With love, Jabiertxo. > > ------------------------------------------------------------------- > > ----------- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Inkscape-user mailing list > > Inkscape-user(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-user

1 0

Re: [Inkscape-devel] [Inkscape-user] New Das Stroke LPE
by Jabier Arraiza 01 Apr '18

01 Apr '18

Thanks Tav for the feedback. Im working in a feature to allow use min lenght of a segment to define the aproximate lenght of the hole/dash, this allow corner perfect dashes in a rectangle with diferent ammount of dashes. I go to the link you send to catch more ideas... I realy like more a SVG spec than a LPE, mainly because Im not recreating the stroke but subdividing the segment, so we cannot handle fills without fill between many LPE. Regards. On Sun, 2018-04-01 at 14:16 +0200, Tavmjong Bah wrote: > On Sun, 2018-04-01 at 12:51 +0200, Jabier Arraiza wrote: > > Hey folks, > > > > Whit the help of Lazur and the thread: > > http://www.inkscapeforum.com/viewtopic.php?f=22&t=24175&p=83448&hil > > it > > =s > > troke+dash#p83448 just do a tiny LPE to fix it. > > > > Here are the new video showing it (no audio): > > > > https://archive.org/details/dash-stroke-lpe > > Nice! > > > Hope is useful since is not included in the SVG spec. > > If it's an LPE it doesn't need to be in the SVG spec. Have a look at > this to see what the SVG group was thinking about before it was > removed > from the SVG 2 spec: > > https://svgwg.org/specs/strokes/#StrokeDashing > > > With love, Jabiertxo. > > ------------------------------------------------------------------- > > ----------- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Inkscape-user mailing list > > Inkscape-user(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-user

1 0