![](https://secure.gravatar.com/avatar/51236019eeb4ed0d1a99db490eeb88ed.jpg?s=120&d=mm&r=g)
Thank you Ryan for uploading those videos. Its so nice to see the faces of the folks that I read almost on a daily basis. Good stuff.
On Tue, Mar 27, 2018, 7:48 PM Ryan Gorley via Inkscape-devel, < inkscape-devel@lists.sourceforge.net> wrote:
If my last message didn't send properly here is that link again to the video: https://youtu.be/4stNumKreTc
Ryan
On March 27, 2018 4:49:16 PM Bryce Harrington <bryce@...961...> wrote:
A recap of some discussions that have been under way...
- On the first day I gave a presentation on modularity, and identified
areas in both Inkscape the codebase and Inkscape the project, to encapsulate complexity into more easily understood chunks, with well defined and simple interfaces between them.
- Gtk3 (and Gtk4) issues were brainstormed. We use several Gtk2
functionalities which are deprecated in Gtk3, and may be removed in Gtk4. We scoped out ideas for transitioning, such as migrating from GtkAction to GAction, and GtkMain to GtkApplication. The discussions helped clear some blockers, and Alex is now digging into the code and working out how we can do the change with minimum impact on UI appearance or behavior.
Longer term, once these transitions are made, there are a number of more impactful changes that could be attempted. One scheme we scoped out was to separate the frontend and backend of Inkscape, using GActions as the interface. The backend would present a lengthy list of all of its internal operations (Actions). There would be separate sets of Document Actions (like moving a node on a Bézier curve) and Window Actions (like resizing the window). The frontend UI would translate its widget clicks and menu picks into the corresponding actions and pass them down. Apart from giving us better organized code, this could also make it easier to have multiple kinds of UI's (e.g. a simplified "kidscape" interface) or even no-UI (e.g. a headless version that processes commands through command line args or a batch language).
- Website strategy is under heavy discussion. It's been a while since
the website has had a design refresh, and whiteboard markers are flowing. Improving mobile friendliness seems important, also better use of graphics and videos is being explored, and better emphasis on using some of the great user stories out there. There's also a recognition that we have needs for something more user-facing (e.g. something "brochure-like") and something more back-office-y (the contributor community, aka "contributy"). A lot of this will need a lot more hashing out and collecting wider ideas, but I'm looking forward to seeing how this work proceeds in coming weeks and months.
- Variable fonts. This new type of font permits e.g. sliding scale of
style aspects like bold between letter forms. Some implementation work has already been done, but the hackfest has been used to hash out some remaining questions and implementation details. There's still some UX/UI questions on how it should be implemented in the interface.
- Improved gradients using random dithering in pixman. Lots of
discussions in both IRL and IRC around Mc's code to add better gradient rendering to pixman, that avoids banding by randomly dithering the colors. The patch has been proposed to pixman and some feedback's been received, but still mulling over how to actually get this feature into use.
- Color management / CMYK. We had an in-depth discussion between
coders and designers to hash out what we ought to be shooting for in terms of requirements. We discussed a "print pre-flight dialog" concept that had come up in some of the Vectors team discussions. What's needed as a next step is to flesh out the concept - workflow use cases, a mockup UI, and analysis of how data in/out flows need to work. There are a lot of ideas and user stories, that need gelled into something coherent that people can start throwing darts at.
- SVG 2 working group, and future directions. A number of features we
wanted to see included in the SVG 2 spec sound like they will get dropped. Further, this change of direction by the WG suggests it may get tougher to include artistic-oriented features in future revisions of the spec. We discussed some of the problems, but the path forward for us is unclear.
I'm certain I've missed a number of the discussions here, and am not capturing all the work under way. Hopefully other attendees can fill in what I've missed or gotten wrong, and provide more details from my above summary. Please ask questions, too.
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel