- Inkscape Devel - Inkscape Mailman

inkscape-0.92pre0 source tarball
by Bryce Harrington 17 May '16

17 May '16

The alpha for Inkscape 0.92, inkscape-0.92pre0, is released and available for testing from the Download page: https://inkscape.org/en/download/source/ The release is: 0.92pre0 Source Tarball Bzip https://inkscape.org/en/gallery/item/9591/inkscape-0.92pre0.tar.bz2 This is an early preview of our upcoming release and as such can be expected to have some stability issues or incomplete features. See Inkscape's bug tracker for a list of known issues. == Translation == Translators are encouraged to start looking at translation work. String freeze will be in one week (May 22nd), but the i18n POT file has been updated in trunk and we do not anticipate any serious changes between now and string freeze so please feel free to start preparing your language translations. Please aim to get all translation work committed by mid-June. == Packaging == Packagers for Linux, Windows, and OSX should use this source tarball for creating packages for their respective platforms. Note that this was produced using the new cmake system, and the autoconfig build files are not included in this dist; if you require the autoconfig system for your platform you can still generate an autoconfig tarball from our VCS trunk, however you should prioritize shifting to cmake as we will be dropping autoconfig in the future 0.93 release. I plan to post further pre-releases on a roughly weekly cadence until we feel the codebase is stable enough for the final release, which would be late June at the earliest. == About Screen == An About Screen contest should be started at this time - Josh, you've run this contest in the past, will you be available to do it again for 0.92? Can the contest be organized to complete by mid-June or do you think it would require more time than that? ------------------------------------------------------------------------ Thanks, Bryce

4 5

[REFERENDUM] SVG Working Group Meetings for 2016
by Bryce Harrington 16 May '16

16 May '16

A majority vote of the current board members is required for the following matter. Proposal: Authorize SVG WG travel by Tav up to the amount in the SVG WG fund. "Inkscape's Project Leadership committee authorizes Conservancy to pay any invoice from Tav between 2016-03-01 and 2017-02-28 for SVG Working Group meetings, up to the amount presently available in Inkscape's SVG WG Fund, $2384.91. Tav must of course also comply with Conservancy's travel policy." [ ] a. Yes, authorize SVG WG expenses up to amount in fund [ ] b. No, do not authorize these expenses Votes: Resolved: Background: In the past we've had to vote on each of Tav's meeting attendances on a case by case basis. But now that we have set aside a fund specifically for these meetings, I think we should just approve any and all travel he may do, up to the total in that fund. This will eliminate uncertainty for him in making his travel plans, and simplify our voting. I enquired with Bradley Kuhn about how we can do this, and this is what he replied: <quote> Bryce Harrington wrote: > Tav attends these SVG WG meetings pretty routinely now, and I don't > recall us ever not approving his attendance. Now that we have a > dedicated fund set up for this, that isn't going to be used for > anything *but* funding Tav's SVG WG trips, would it be permissible to > give him approval to arrange his attendance at these meetings at his > own discretion, so long as the expenses are within the limit of what's > in the funding pool, without requiring board votes on each individual > meeting? I'd suggest you approve an annual maximum budget that Tav can send invoices for regarding SVG meetings, and instruct Conservancy to pay them provided Tav's within the Conservancy travel policy. That way, you only have to think about it once per year, or when he goes over budget. Something like: "Inkscape's Project Leadership committee authorizes Conservancy to pay any invoice from Tav between now and 2017-01-01 for SVG Working Group meetings, up to a maximum 2016 Travel Budget for Tav's SVG Working Group meetings of $Nk. Tav must of course also comply with Conservancy's travel policy." -- bkuhn <endquote> I aligned the dates to fiscal year 2016 since we decided to shift our budget to those dates. Below is a tally of the SVG WG fund balance as of what's in SFC's ledger system for us: ---- FY 2015 ---- Initial fund $ 0 + $2250.00 Budgeted from Inkscape General Fund 2015 $ 2250 - $ 346.82 SVG WG Sweden $ 1903.18 - $ 12.89 " " $ 1890.29 - $ 12.95 " " $ 1877.34 - $ 37.24 " " $ 1840.10 - $ 15.19 " " $ 1824.91 - $ 49.53 " " $ 1775.38 - $ 394.00 " " $ 1381.38 - $ 31.38 " " $ 1350.00 + $2250.00 Retroactive from FY 2016 Ink. Gen. Fund $ 3600.00 - $ 12.99 SVG WG Sydney Feb 3-5 $ 3587.01 - $ 12.44 " " $ 3574.57 - $1586.80 " " $ 1987.77 - $ 15.55 " " $ 1972.22 - $ 11.67 " " $ 1960.55 - $ 244.29 " " $ 1716.26 - $ 68.89 " " $ 1647.37 ---- FY 2016 ---- + $ 736.54 Donation income Dec 2015 - May 2016 $ 2383.91 This will cover Tav's recent London SVG editor's meeting (which he reports ran to about $500), an editor's meeting in Amsterdam, and other travel he'll undertake through the remainder of FY 2016. If Tav needs to spend in excess of this sum, and there have been additional donation income that covers the overage, at that point we'll need to re-vote to increase the budget limit.

3 2

Inkscape Code of Conduct
by Bryce Harrington 16 May '16

16 May '16

The Inkscape Board has approved a Code of Conduct for the Inkscape project, which is now available on our website thanks to the web team. Please take a moment to review: https://inkscape.org/en/community/coc/ We're establishing the CoC as a good practice, not as a result of any incident. The Inkscape community has always striven to be inclusive, polite, and fair, and the CoC is an intent to help cement these good values for future community members. This community has also had a strength of resolving issues internally, and hopefully that tradition will continue to be strong. But if issues do arise, Krzysztof Kosiński has volunteered to be the contact point for things needing escalated, and his email is included in at the end of the CoC. You can also escalate issues to the Board through any standing board member, if needed. Bryce

3 2

Recommending an OS
by Martin Owens 16 May '16

16 May '16

I'm mentioning this in inkscape since it's an interesting idea executed by a company rather than a free software project: http://store.steampowered.com/about/ Take a look at the bottom, where it says: "Ubuntu is our favorite version of Linux. Interested in giving it a whirl? You can install and run Ubuntu from a Live CD or USB stick, or install it to run alongside Windows. Grab an Ubuntu installer from Canonical and see what it’s all about." That's really interesting from our perspective, because our website never recommends using a free software desktop, or linking to ubuntu's website. Are we too cautious about recommending something like Ubuntu along side using Inkscape? Should we say that linux is the platform with the most support and Ubuntu is probably the one you should try first. Or are we happy with the no-opinion presentation we have currently? Is it false balance to present ourselves as if all desktops are equal to us? Anyway, I'm just mulling this over. Best Regards, Martin Owens

9 17

Copy error on Windows XP and 7
by LucaDC 16 May '16

16 May '16

When compiling recent versions under Windows XP and 7 I get this error in the distbase/copy phase: ##### Target : distbase ##### generate the distribution directory with all needed files --- distbase / copy copy : AUTHORS to inkscape copy : 1 file copied --- distbase / copy copy : COPYING to inkscape copy : 1 file copied --- distbase / copy copy : COPYING.LIB to inkscape Make error line 655: copy : file COPYING.LIB does not exist Last try just now with trunk rev 14881. -- View this message in context: http://inkscape.13.x6.nabble.com/Copy-error-on-Windows-XP-and-7-tp4976680.h… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 4

Crashy bug thing (lib2geom exception)
by C R 15 May '16

15 May '16

Don't know if this is related to the crashing issues that Jabier has been encountering, but trunk has been crashing with lib2geom exceptions today. Bug filed here with test file and a video of the issue. https://launchpad.net/bugs/1581955 -C

2 2

Fillet-Chamfer
by Jabiertxo Arraiza Cenoz 15 May '16

15 May '16

Hi to all. I spend all week free time fixing Fillet-Chamfer tool But I get into strange craches all time, 3 or 4 diferent in each change. Need to get some perspective on it and hurry is not welcome in this cases. My apologyes to all people using fillet-chamfer, they need to wait to get it ready again. If anybody can give me light, my bugs become when delete a node of a Fillet-Chamfer path. some times are a double linked list bug -¿maybe by reusing a GDB previous session?-, sometimes are knot indexing ¿Why knotholder not refresh on every node delete? Cheers, Jabier.

2 2

Build failures with current trunk (as of rev 14882)
by Bryce Harrington 12 May '16

12 May '16

Issue #1: CXX color-profile.o ../../src/main.cpp: In function ‘int sp_main_gui(int, const char**)’: ../../src/main.cpp:1071:39: error: expected unqualified-id before ‘&’ token catch (const Gtk::CssProviderError& ex) ^ ../../src/main.cpp:1071:39: error: expected ‘)’ before ‘&’ token ../../src/main.cpp:1071:39: error: expected ‘{’ before ‘&’ token ../../src/main.cpp:1071:41: error: ‘ex’ was not declared in this scope catch (const Gtk::CssProviderError& ex) ^ ../../src/main.cpp:1071:43: error: expected ‘;’ before ‘)’ token catch (const Gtk::CssProviderError& ex) ^ ../../src/main.cpp:1083:39: error: expected unqualified-id before ‘&’ token catch (const Gtk::CssProviderError& ex) ^ ../../src/main.cpp:1083:39: error: expected ‘)’ before ‘&’ token ../../src/main.cpp:1083:39: error: expected ‘{’ before ‘&’ token ../../src/main.cpp:1083:43: error: expected ‘;’ before ‘)’ token catch (const Gtk::CssProviderError& ex) ^ make[5]: *** [main.o] Error 1 I suspect that this was introduced prior to rev 14882, but haven't investigated it. Issue #2: The version specification in the cmake scripts depends on bzr which shouldn't be used in the nightly builds: VER_PREFIX="0.91+devel";\ VER_BZRREV=" r`bzr revno --tree ../..`"; \ if test ! -z "`bzr status -S -V ../../src`"; then \ VER_CUSTOM=" custom"; \ fi; \ VERSION="$VER_PREFIX$VER_BZRREV$VER_CUSTOM"; \ echo "namespace Inkscape { " \ "char const *version_string = \"$VERSION\"; " \ "}" > inkscape-version.new.cpp; \ if cmp -s inkscape-version.new.cpp inkscape-version.cpp; then \ rm inkscape-version.new.cpp; \ else \ mv inkscape-version.new.cpp inkscape-version.cpp; \ fi; \ echo $VERSION /bin/bash: line 1: bzr: command not found /bin/bash: line 2: bzr: command not found CXX main.o I think the solution here is to just shortcircuit all this if we're doing a launchpad build. So this needs an option added to cmake to set the version number. After that, I can adjust the recipe in launchpad to use it. Bryce ----- Forwarded message from Launchpad Buildd System <noreply@...1881...> ----- Date: Tue, 10 May 2016 11:43:28 -0000 From: Launchpad Buildd System <noreply@...1881...> To: Bryce Harrington <bryce@...961...> Subject: [Build #9718826] i386 build of inkscape-trunk 1:0.91.0+devel+14882+65~ubuntu14.04.1 in ubuntu trusty RELEASE [~inkscape.dev/ubuntu/trunk] Reply-To: Launchpad Buildd System <noreply@...1881...> * Source Package: inkscape-trunk * Version: 1:0.91.0+devel+14882+65~ubuntu14.04.1 * Architecture: i386 * Archive: ~inkscape.dev/ubuntu/trunk * Component: main * State: Failed to build * Duration: 17 minutes * Build Log: https://launchpad.net/~inkscape.dev/+archive/ubuntu/trunk/+build/9718826/+f… * Builder: https://launchpad.net/builders/lgw01-38 * Source: not available If you want further information about this situation, feel free to contact a member of the Launchpad Buildd Administrators team. -- i386 build of inkscape-trunk 1:0.91.0+devel+14882+65~ubuntu14.04.1 in ubuntu trusty RELEASE https://launchpad.net/~inkscape.dev/+archive/ubuntu/trunk/+build/9718826 You are receiving this email because your team Inkscape Developers is the owner of this archive. ----- End forwarded message -----

1 0

Re: [Inkscape-devel] Recommending an OS
by jelle 11 May '16

11 May '16

> 4. Recommending an OS (Martin Owens) > 5. Re: Recommending an OS (Eduard Braun) Martin, Before we end up in the "My Distro is better than yours" discussion, I would like to state I am no fan of Ubuntu myself. That said, as far as I know it works pretty well on all versions and GUI's available on Linux. It actually also works quite well on Windows is my experience, though I'll never touch another Mac in my life unless my life depends on it, so that's a blank for me. I have to agree with Eduard here, that it feels a bit like the old website remarks,.. designed for X by Y. Optimised for MSIE etc. of Ye Olden Days... Apart from that we might think about making a page about getting print done using FOSS. As far as I am aware there are some articles on the topic, but nothing all that prominent and not easily found. If we can make the case that you can do pretty much what you're doing with commercial software for free and with clear descriptions on how to do things for the average button pusher, it will make a stronger case if there is a clear path using whatever distro of Linux in the description. The same goes for web design btw or any other design form currently getting supported. HPGL plotting and cutters, even embroidery is on the list these days. Something like a "Output Info" button on the website, with a page with links to articles with hands on experience would be great. A time stamp and version related to the link would be useful too btw. Don't know how much effort it would be to create some kind of RSS feed on such articles so the more recent go on top. Or maybe a user input rating the article to relevance. Rather than having a maintainer for such a thing it may be an idea to try and automate it as much as possible. Cheers, Jelle

1 0

Daily logs
by Kamalpreet Grewal 10 May '16

10 May '16

Keeping logs is easy since everyone can check progress of the work. What should I prefer for keeping my daily logs for the GSoC project - my personal website (included below my signature) or via Wiki account? -- Kamalpreet Kaur Grewal Blog: http://kamalpreetgrewal.com/

2 1

[UI] Reviewed blueprints that can be ported
by Xaviju Julián 10 May '16

10 May '16

Hi, As agreed in the LGM, I created a list of all the blueprints of https://blueprints.launchpad.net/inkscape that can be ported to be reviewed by the Inkscape UI team. There is one column with the link to the blueprint, the second column is relevant information about the blueprint, as a link to the full description or resource suggested by the drafter or the comments in the whiteboard. I've added a column named 'Has UI proposal' to mark all of them that already include a UI wireframe by the drafter that can be ported to the gallery. Most of them do not have a wireframe but could be very interesting ideas as well to discuss. It would be nice to set a meeting or hangout to talk as well on how to deal with such a lot of ideas, some or them are really interesting. Best regards, Xavi [Xaviju]

5 8

Bool-LPE /= FilletChamfer
by Jabier Arraiza 09 May '16

09 May '16

I just become too bussy fixong my oun branch. Any one could help me reviewing lpe-bool branch? Thanks in advance. J.

1 0

Fillet-Chamfer
by Jabier Arraiza 09 May '16

09 May '16

Hi to all. I get a review for the new fillet-chamfer code by Krzysztof. There is a lot of changes and I'm not sure I could fix all this week. For this question, I put the old fillet-chamfer code in experimental mode. I hope it not diturb too much. Sorry for all users. I try to finish the thinkgs this weekend to reenable again with the new code. But maybe we can get on 0.92 :(. Cheers, Jabier.

4 4

Wiki account
by Sebastian Zartner 09 May '16

09 May '16

Hi there, I'd like to create a proper specification for my blueprint at https://blueprints.launchpad.net/inkscape/+spec/document-properties-rework and therefore need a wiki account. Could you please create one for me with the name 'Sebastianz'? Thanks in advance! Sebastian

3 3

Inkscape licensing
by Krzysztof Kosiński 08 May '16

08 May '16

Hello everyone, tl;dr: Most Inkscape code is GPLv2+, but the complete program is GPLv3+ due to bits of code from GIMP. The Inkscape Board has resolved some licensing problems within our codebase and Inkscape is now available under GPL version 3 or later. The vast majority of code in Inkscape is covered by GPL version 2 or later; the authors of 4 files that were GPL v2 only were contacted and all agreed to relicense their contributions to GPL v2+, while one file was rewritten from scratch. However, Inkscape also includes a few files from GIMP, which are available under GPL v3+ only. Therefore, redistribution of the complete program is currently possible only under the terms of GPL version 3 or later. We would like to keep existing source and new contributions GPL v2+, so that we may make Inkscape available under GPL v2+ if the GIMP code is removed. Best regards, Krzysztof

3 4

Board Meeting @ Friday May 6th, 2016
by Bryce Harrington 08 May '16

08 May '16

May's meeting is coming up. It'll be in #inkscape-devel at noon Pacific time (2000 UTC). http://wiki.inkscape.org/wiki/index.php/Board_Meetings This will be a good opportunity to debrief from the hackfest and identify followup actions that the board should work on in coming months. Bryce

5 11

[UI] Popovers
by Tavmjong Bah 08 May '16

08 May '16

Hi, I just came across a widget in GTK that I didn't know about. It looks interesting: https://blogs.gnome.org/mclasen/2014/01/22/and-now-popovers/ Might be useful to reduce menu size to put some menu items in one of these... such as the Boolean Ops. These can contain icons (where normal GTK 3 menus can not). Tav

2 1

Re: [Inkscape-devel] 0.92 release
by Josh Andler 08 May '16

08 May '16

0.91 was the first time we had an experimental branch, but I'm not against it again. I would also like to hear from Jabier if he thinks something is a review away from inclusion this cycle or if he thinks it's better to defer his branches for 0.92. Cheers, Josh On May 5, 2016 12:15 AM, "Alex Valavanis" <valavanisalex@...400...> wrote: OK, this all sounds very promising. Unfortunately, I won't be available to join in the IRC meeting tomorrow, but by the sounds of things, we're not awaiting any new urgent feature additions. Can I suggest, therefore, that we move into Feature Freeze as soon as possible, and concentrate on bug fixing ready for release? As in previous cycles, we could start an experimental branch for features that can wait until after 0.92. AV On 5 May 2016 at 07:59, Josh Andler <scislac@...400...> wrote: > I've worked with SUV for the past half dozen years or so on figuring out > release blocker stuff. I'm willing to take it on even if there is no > interest on SUV's end to help determine such things. I will draft a release > plan tomorrow morning (as I had previously offered to) and send it to you > Bryce for your review and edits and I will begin reviewing for blocker bugs > in the tracker after that. > > Cheers, > Josh > > On May 4, 2016 9:08 PM, "Bryce Harrington" <bryce@...961...> > wrote: >> >> On Wed, May 04, 2016 at 03:57:51PM +0200, Tavmjong Bah wrote: >> > On Wed, 2016-05-04 at 09:04 -0400, Martin Owens wrote: >> > > On Wed, 2016-05-04 at 14:27 +0200, Tavmjong Bah wrote: >> > > > >> > > > We should discuss this on Friday's IRC meeting. >> > > Friday's meeting is a board meeting isn't it? I thought developer >> > > decisions like releases were more developer consensus on mailing list >> > > type things and less board responsibility. >> > > >> > > (or is this just convenient discussion space?) >> > >> > Yes, it is not the board's duty to make developer decisions. But I >> > think the board does have the responsibility to aid (and prod) the >> > developers to make decisions when needed as well as to support the >> > execution of those decisions (e.g. fund a dedicated hackfest). >> > >> > (it is also a convenient discussion space) >> >> You're both right, and I do agree that having a meeting to get things >> going with the release is a great idea. >> >> Traditionally we've often encouraged non-board-specific technical >> discussions to happen immediately following the board meeting. What if >> we had a short board meeting for say 20-30 min, and then a second >> followup meeting specifically to focus on release coordination >> discussions? >> >> Sounds like we've crested the hill on the cmake work (we still need to >> do a comparison between the automake-generated dist and the cmake dist, >> to see if we're missing anything important). Once we're comfortable >> with what's in the dist, I can cut an alpha release - possibly as early >> as this weekend. I'm prepared to do a series of (bi-weekly?) >> pre-releases as we work towards the final release. Next step would be >> to start gathering a list of release blockers and recruit owners for >> getting those items examined; I would love it if someone could volunteer >> to coordinate/manage the release blocker bugfixing work. >> >> Bryce >> >> >> ------------------------------------------------------------------------------ >> Find and fix application performance issues faster with Applications >> Manager >> Applications Manager provides deep performance insights into multiple >> tiers of >> your business applications. It resolves application problems quickly and >> reduces your MTTR. Get your free trial! >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers > of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

6 8

Re: [Inkscape-devel] [UI] Name for a new function
by jelle 07 May '16

07 May '16

> 2. Re: [UI] Name for a new function (Brynn) > 3. Re: [UI] Name for a new function (Jabiertxo Arraiza Cenoz) > > As far as I can understand from all this what it does is create a polygon from the outline of a stroke. If so wouldn't "outline from stroke", "path from stroke" or "stroke to filled path" not be a better description? Would also be nice if that could happen without destroying the original. The "deconstruct object" sounds more like cutting a path to ribbons from node to node. Something like "segmentate path" might actually be quite handy come to think of it. In combination with a "weld nodes" that is. True, is obtainable with the node editor as well but I like those one click options without keyboard switches. If the circle has no stroke, it is no more than logical it disappears. Cheers, Jelle > > Message: 2 > Date: Sat, 7 May 2016 03:36:19 -0600 > From: "Brynn" <brynn@...3133...> > Subject: Re: [Inkscape-devel] [UI] Name for a new function > To: "Inkscape-Devel" <inkscape-devel(a)lists.sourceforge.net> > Message-ID: <B40A8BBF0C4A40EF9E338A385BCE416B@...3282...> > Content-Type: text/plain; format=flowed; charset="utf-8"; > reply-type=original > > Seeing how it works would help understanding. From a simple user: > > "deconstruct object" sounds like breaking up any object to individual > pieces, maybe like Ungroup, or Break Apart. And I can't imagine how > "stroke > to fill" fits with either of those. ("stroke to fill" sounds like some > kind > of a stripe pattern) > > All best :-) > brynn > > ____________________________ > From: C R > Sent: Saturday, May 07, 2016 3:13 AM > To: Olof Bjarnason > Cc: Inkscape Devel List > Subject: Re: [Inkscape-devel] [UI] Name for a new function > > > Yes please draw some use case diagrams. > (And I like the renaming too. I'm still much more of a user than a > developer > of inkscape and that name (stroke to path) has annoyed me for years!) > > > Will do! And yes, I'm going to recommend renaming it as well. It's always > been a bit of a sticking point in my head as well. > > > -C > > > > On 7 May 2016 11:03, "C R" <cajhne@...400...> wrote: > > I think stroke to path is already a naming convention for a very similar > functionality, so I will keep this name if possible if the feature is not > too different. If a user will receive most of the time the same result I > will try to keep it to avoid confusion. Having too many features with > similar behaviours could be frustrating. > > > Agreed. This is my main reason for proposing a modification to the > behaviour > of Stroke to Path (We can think about renaming it later, however that > may be > confusing to our current user base. As a daily user, I'm all for > changing it > to "Strike to Fill", which is what Stroke to Path actually does. > > I would strongly suggest not to create a new menu option if the > behaviour is > not too different from the expected one if we think the users are going > to > keep using it as they were doing before. > > > To clarify: > 1. Make a red circle with a black stroke > 2. Path > Stroke to Path > > > Watch the red circle vanish > > > Note that I didn't ask Inkscape to throw away the fill, it just does it > because there is no shape to contain it anymore. > Since we have Paint Order in trunk now, this is even more of an issue; > you > don't want Stroke to Path to throw away everything you did to make that > shape look the way it is, which may include a stack of LPEs and markers, > not > to mention the fill may include a complex gradient that you have to copy > and > paste-in-place to recover. The way it has worked has always been a major > workflow bottleneck, and Jabier's new function fixes the problem > entirely. > > > Would folks like to see some use case and work flow diagrams? > If so, I can have them ready tomorrow. > > > -C > > > > > > > > > > Otherwise, reading the feature explanation, "decompose object" or > "deconstruct object"sounds self-explanatory to me. > > > I don't have an answer, but I would raise some questions about how we > think > it is going to be used: what is the purpose, what is the expected outcome > and I would compare to the stroke to path option to ensure that are > enough > different. > > > :) > > > > On Sat, May 7, 2016 at 10:20 AM, Olof Bjarnason > <olof.bjarnason@...400...> > wrote: > > > > > > > > > > Mvh > > > > > /Olof > ----------------- > ?r du systemutvecklare? > Spana in https://cilamp.se > > > > > On 7 May 2016 at 10:14, C R <cajhne@...400...> wrote: > > Basicly, this is how Stroke to Fill should work. > > > How it works now: > Ctrl+Alt+C > Stroke to Path > > > Result: stroke is indeed converted to path, but the fill and all other > parts > of the selection that are not strokes vanish. If any LPEs are applied to > the > path they are thrown out as well (you need to convert object to path > before > this operation to preserve the appearance). > > > > > How it should work (this "deconstruct" alternative): > Ctrl+Alt+C > Stroke to Path > > > Result: All LPE's applied to stroke, then the stroke is converted to > path. > > > My thought is, if we use the convention that a fill is only turned into > an > object if there is a fill set on the object, then we can please anyone > who > prefers the old behaviour. All they have to do is get rid of the fill > colour > on the object before applying Stroke to Path. > > > The current way it's handled is counter-intuitive. Most of the time, all > you > want to do is convert the outline to a fill, not throw away tons of data. > The point is to preserve appearance, and the Jabier's new function does > this > much much better. > > > Thanks, that is a good explanation. However the wording "stroke to path" > isn't that clear to me. > > > Now that I understand what is going on I think "deconstruct" is actually > a > quite good albeit little techy word for the operation. "Decompose"? > "Path to > fills"? > > > The end result is a bunch of filled paths, and the input is what > exactly? I > think "X to Y" is a good but then the X and the Y should be closer to > what > the operation is actually doing ;) > > > > > > My 2p. > -C > > > > > > > > > > > > > On Sat, May 7, 2016 at 9:03 AM, Olof Bjarnason <olof.bjarnason@...400...> > wrote: > > Is there any image giving an example of what the command does...? Like > before/after with arrows and descriptive text? > > > It's kind of hard to understand what is happening from the very brief > description at the top of that thread... > > > > > > > Mvh > > > > > /Olof > ----------------- > ?r du systemutvecklare? > Spana in https://cilamp.se > > > > > On 7 May 2016 at 09:53, Jabiertxo Arraiza Cenoz > <jabier.arraiza@...2893...> > wrote: > > Hi to all UI power! > I Just to know a name for the patch https://bugs.launchpad.net/inkscape > /+bug/1556592 > > See the ScislaC proposal on #5 > Bryce like "Deconstruct object", me too. > > Is ok the name? Another one? > > Cheers, Jabier. > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications > Manager > Applications Manager provides deep performance insights into multiple > tiers > of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications > Manager > Applications Manager provides deep performance insights into multiple > tiers > of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications > Manager > Applications Manager provides deep performance insights into multiple > tiers > of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > > > > > > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications > Manager > Applications Manager provides deep performance insights into multiple > tiers > of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > > > > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > ------------------------------ > > Message: 3 > Date: Sat, 07 May 2016 11:53:57 +0200 > From: Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...> > Subject: Re: [Inkscape-devel] [UI] Name for a new function > To: C R <cajhne@...400...>, Olof Bjarnason <olof.bjarnason@...400...> > Cc: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> > Message-ID: <1462614837.14732.13.camel@...2893...> > Content-Type: text/plain; charset="utf-8" > > I just read the thread. > Olof, the new feature convert the selected items to paths, maybe groups > if have more than one propertye o fill|stroke|marker. > It also retain new paint order. > > So I try to solve one question and now have more :) > In the meet with Josh in IRC he tell is better retain the old stroke to > path (?renaming it?) to old users and add a new item (down stroke to > path) to ?deconstruct object? > > In my point of view, personal only, I think a feature to convert a > "stroke to fill/path" is unnecesary, because "deconstruct object" do > the same with objects with only strokes/markers. > > Cheers, Jabier. > > > El s?b, 07-05-2016 a las 10:13 +0100, C R escribi?: >> > >> > >> > Yes please draw some use case diagrams. >> > >> (And I like the renaming too. I'm still much more of a user than a >> > >> > developer of inkscape and that name (stroke to path) has annoyed me >> > for >> > years!) >> > >> Will do! And yes, I'm going to recommend renaming it as well. It's >> always >> been a bit of a sticking point in my head as well. >> >> -C >> >> >> >> > >> > On 7 May 2016 11:03, "C R" <cajhne@...400...> wrote: >> > >> > I think stroke to path is already a naming convention for a very >> > similar >> > > >> > > functionality, so I will keep this name if possible if the >> > > feature is not >> > > too different. If a user will receive most of the time the same >> > > result I >> > > will try to keep it to avoid confusion. Having too many features >> > > with >> > > similar behaviours could be frustrating. >> > > >> > Agreed. This is my main reason for proposing a modification to the >> > behaviour of Stroke to Path (We can think about renaming it later, >> > however >> > that may be confusing to our current user base. As a daily user, >> > I'm all >> > for changing it to "Strike to Fill", which is what Stroke to Path >> > actually >> > does. >> > >> > >> > > >> > > I would strongly suggest not to create a new menu option if the >> > > behaviour >> > > is not too different from the expected one if we think the users >> > > are going >> > > to keep using it as they were doing before. >> > > >> > To clarify: >> > 1. Make a red circle with a black stroke >> > 2. Path > Stroke to Path >> > >> > Watch the red circle vanish >> > >> > Note that I didn't ask Inkscape to throw away the fill, it just >> > does it >> > because there is no shape to contain it anymore. >> > Since we have Paint Order in trunk now, this is even more of an >> > issue; you >> > don't want Stroke to Path to throw away everything you did to make >> > that >> > shape look the way it is, which may include a stack of LPEs and >> > markers, >> > not to mention the fill may include a complex gradient that you >> > have to >> > copy and paste-in-place to recover. The way it has worked has >> > always been a >> > major workflow bottleneck, and Jabier's new function fixes the >> > problem >> > entirely. >> > >> > Would folks like to see some use case and work flow diagrams? >> > If so, I can have them ready tomorrow. >> > >> > -C >> > >> > >> > >> > >> > >> > > >> > > >> > > >> > > Otherwise, reading the feature explanation, "decompose object" or >> > > "deconstruct object"sounds self-explanatory to me. >> > > >> > > I don't have an answer, but I would raise some questions about >> > > how we >> > > think it is going to be used: what is the purpose, what is the >> > > expected >> > > outcome and I would compare to the stroke to path option to >> > > ensure that are >> > > enough different. >> > > >> > > :) >> > > >> > > On Sat, May 7, 2016 at 10:20 AM, Olof Bjarnason <olof.bjarnason@...1354... >> > > mail.com >> > > > >> > > > wrote: >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > Mvh >> > > > >> > > > >> > > > /Olof >> > > > ----------------- >> > > > ?r du systemutvecklare? >> > > > Spana in https://cilamp.se >> > > > >> > > > >> > > > On 7 May 2016 at 10:14, C R <cajhne@...400...> wrote: >> > > > >> > > > > >> > > > > Basicly, this is how Stroke to Fill should work. >> > > > > >> > > > > How it works now: >> > > > > Ctrl+Alt+C > Stroke to Path >> > > > > >> > > > > Result: stroke is indeed converted to path, but the fill and >> > > > > all other >> > > > > parts of the selection that are not strokes vanish. If any >> > > > > LPEs are applied >> > > > > to the path they are thrown out as well (you need to convert >> > > > > object to path >> > > > > before this operation to preserve the appearance). >> > > > > >> > > > > >> > > > > How it should work (this "deconstruct" alternative): >> > > > > Ctrl+Alt+C > Stroke to Path >> > > > > >> > > > > Result: All LPE's applied to stroke, then the stroke is >> > > > > converted to >> > > > > path. >> > > > > >> > > > > My thought is, if we use the convention that a fill is only >> > > > > turned into >> > > > > an object if there is a fill set on the object, then we can >> > > > > please anyone >> > > > > who prefers the old behaviour. All they have to do is get rid >> > > > > of the fill >> > > > > colour on the object before applying Stroke to Path. >> > > > > >> > > > > The current way it's handled is counter-intuitive. Most of >> > > > > the time, >> > > > > all you want to do is convert the outline to a fill, not >> > > > > throw away tons of >> > > > > data. The point is to preserve appearance, and the Jabier's >> > > > > new function >> > > > > does this much much better. >> > > > > >> > > > Thanks, that is a good explanation. However the wording "stroke >> > > > to path" >> > > > isn't that clear to me. >> > > > >> > > > Now that I understand what is going on I think "deconstruct" is >> > > > actually >> > > > a quite good albeit little techy word for the operation. >> > > > "Decompose"? "Path >> > > > to fills"? >> > > > >> > > > The end result is a bunch of filled paths, and the input is >> > > > what >> > > > exactly? I think "X to Y" is a good but then the X and the Y >> > > > should be >> > > > closer to what the operation is actually doing ;) >> > > > >> > > > >> > > > >> > > > > >> > > > > >> > > > > My 2p. >> > > > > -C >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > On Sat, May 7, 2016 at 9:03 AM, Olof Bjarnason < >> > > > > olof.bjarnason@...400...> wrote: >> > > > > >> > > > > > >> > > > > > Is there any image giving an example of what the command >> > > > > > does...? Like >> > > > > > before/after with arrows and descriptive text? >> > > > > > >> > > > > > It's kind of hard to understand what is happening from the >> > > > > > very brief >> > > > > > description at the top of that thread... >> > > > > > >> > > > > > >> > > > > > >> > > > > > Mvh >> > > > > > >> > > > > > >> > > > > > /Olof >> > > > > > ----------------- >> > > > > > ?r du systemutvecklare? >> > > > > > Spana in https://cilamp.se >> > > > > > >> > > > > > >> > > > > > On 7 May 2016 at 09:53, Jabiertxo Arraiza Cenoz < >> > > > > > jabier.arraiza@...2893...> wrote: >> > > > > > >> > > > > > > >> > > > > > > Hi to all UI power! >> > > > > > > I Just to know a name for the patch >> > > > > > > https://bugs.launchpad.net/inkscape/+bug/1556592 >> <https://bugs.launchpad.net/inkscape/+bug/1556592> >> > > > > > > >> > > > > > > See the ScislaC proposal on #5 >> > > > > > > Bryce like "Deconstruct object", me too. >> > > > > > > >> > > > > > > Is ok the name? Another one? >> > > > > > > >> > > > > > > Cheers, Jabier. >> > > > > > > >> > > > > > > ------------------------------------------------------- >> > > > > > > ----------------------- >> > > > > > > Find and fix application performance issues faster with >> > > > > > > Applications >> > > > > > > Manager >> > > > > > > Applications Manager provides deep performance insights >> > > > > > > into multiple >> > > > > > > tiers of >> > > > > > > your business applications. It resolves application >> > > > > > > problems quickly >> > > > > > > and >> > > > > > > reduces your MTTR. Get your free trial! >> > > > > > > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> > > > > > > _______________________________________________ >> > > > > > > Inkscape-devel mailing list >> > > > > > > Inkscape-devel(a)lists.sourceforge.net >> > > > > > > https://lists.sourceforge.net/lists/listinfo/inkscape-dev >> > > > > > > el >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > --------------------------------------------------------- >> > > > > > --------------------- >> > > > > > Find and fix application performance issues faster with >> > > > > > Applications >> > > > > > Manager >> > > > > > Applications Manager provides deep performance insights >> > > > > > into multiple >> > > > > > tiers of >> > > > > > your business applications. It resolves application >> > > > > > problems quickly >> > > > > > and >> > > > > > reduces your MTTR. Get your free trial! >> > > > > > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> > > > > > _______________________________________________ >> > > > > > Inkscape-devel mailing list >> > > > > > Inkscape-devel(a)lists.sourceforge.net >> > > > > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >> > > > > > >> > > > > > >> > > > >> > > > ------------------------------------------------------------- >> > > > ----------------- >> > > > Find and fix application performance issues faster with >> > > > Applications >> > > > Manager >> > > > Applications Manager provides deep performance insights into >> > > > multiple >> > > > tiers of >> > > > your business applications. It resolves application problems >> > > > quickly and >> > > > reduces your MTTR. Get your free trial! >> > > > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> > > > _______________________________________________ >> > > > Inkscape-devel mailing list >> > > > Inkscape-devel(a)lists.sourceforge.net >> > > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >> > > > >> > > > >> ------------------------------------------------------------------- >> ----------- >> Find and fix application performance issues faster with Applications >> Manager >> Applications Manager provides deep performance insights into multiple >> tiers of >> your business applications. It resolves application problems quickly >> and >> reduces your MTTR. Get your free trial! >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

1 0

[UI] Name for a new function
by Jabiertxo Arraiza Cenoz 07 May '16

07 May '16

Hi to all UI power! I Just to know a name for the patch https://bugs.launchpad.net/inkscape /+bug/1556592 See the ScislaC proposal on #5 Bryce like "Deconstruct object", me too. Is ok the name? Another one? Cheers, Jabier.

5 7

Re: [Inkscape-devel] TempGString to simplify common pattern in code..?
by Jon A. Cruz 07 May '16

07 May '16

Glib and gtk are c, but there are c++ wrapper layers we are using: Glibmm and Gtkmm. Check for those names Sent from my mobile device. -------- Original message -------- From: Olof Bjarnason <olof.bjarnason@...400...> Date: 5/6/2016 07:54 (GMT-08:00) To: "Jon A. Cruz" <jon@...18...> Cc: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> Subject: Re: [Inkscape-devel] TempGString to simplify common pattern in code..? OK, I read up a little on GLib and GTK+. Both are (pure) C libraries, so I fail to see how they could provide a RAII idiom? Last time I checked, C didn't have constructors/destructors...? Or maybe there is some pre-processor magic to make it happen...? std::string is nice (I would prefer it in fact) but it wouldn't call g_free automatically when the gchar* variable goes out of scope. Mvh /Olof-----------------Är du systemutvecklare?Spana in https://cilamp.se On 6 May 2016 at 15:51, Olof Bjarnason <olof.bjarnason@...400...> wrote: Yeah, of course if there already exists a solution / pattern then that would be preferrable... (I have only looked at cases for deallocating gchar* using g_free, I do not know what encoding is used inside the strings, and a TempGString object would be agnostic to the encoding anyway.) Anyone know if there is a RAII type for string handling in GLib? My google fu fails me on this atm. Mvh /Olof-----------------Är du systemutvecklare?Spana in https://cilamp.se On 6 May 2016 at 15:40, Jon A. Cruz <jon@...18...> wrote: This sounds like something that should already be covered by gtkmm or even std::string. Usually it's better to look first to existing solutions before inventing our own wheel. IIRC Glib::ustring should cover the cases where we have content that is guaranteed to be UTF-8. (Keep in mind that gtk+ apps have to keep track of three different encodings and not get them mixed up. For strings that are potentially different encodings we can use std::string. For content that looked like a string but is actually a byte sequence, we can use std::vector<char> or std::vector<uint8_t> On Fri, May 6, 2016, at 05:38 AM, Olof Bjarnason wrote: Does anyone want to voice an opinion on this one or should I just go ahead and do it? What about using implicit casting, you OK with that? I think reviewing it should be fairly straight-forward as it's almost a regex search-replace operation (just almost heh). BTW I noticed there is a paste option on the web site too, so here it is: https://inkscape.org/en/paste/9559/ -- Jon A. Cruz jon@...18... ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 2

TempGString to simplify common pattern in code..?
by Olof Bjarnason 06 May '16

06 May '16

Hi guys! One thing I noticed while browsing around Inkscape source, was the pattern "allocate temp gtk string, call some api, deallocate temp string". I think it makes sense to make a small "TempGString" class that captures this (RAII) pattern, and deallocates the string on going out of scope. This would have some advantages compared to current approach: 1) string would be freed regardless of how the code exits the block (exceptions e.g.) 2) 2 lines instead of 3 3) easier on the eyes Sample before-after code snippet: Before: if (!qname_prefix(code).id()) { gchar *svg_name = g_strconcat(prefix, ":", g_quark_to_string(code), NULL); repr->setCodeUnsafe(g_quark_from_string(svg_name)); g_free(svg_name); } After: if (!qname_prefix(code).id()) { TempGString svg_name(g_strconcat(prefix, ":", g_quark_to_string(code), NULL)); repr->setCodeUnsafe(g_quark_from_string(svg_name)); } Syntax highlighted version available here: http://pastebin.com/t7p0TVfj The constructor takes the freshly allocated string, and the destructor calls g_free on it. There is an operator overload so that contexts that expect ordinary pointers to gchar* gets what it want. This automagic casting is a point I'm a bit ambivalent about myself; I wouldn't mind having an accessor function "get_gchar_ptr()" or similar just to be super explicit, thoughts on that? I don't think this would break anything, however it might be that I'm ignorant to some weird behaviour of ghar* or glib/gtk? On a convention/code style notion, I looked through the code for RAII (worst abbreviation for something so clear/simple semantically) and noticed it's used in a couple other places, however I've still been wary of introducing this refactoring to the code base as I don't know if you guys would like it. The pattern occurs on at least 140 places in the code base. Cheers, /Olof

2 4

Style Dialog Design [UI]
by Kamalpreet Grewal 05 May '16

05 May '16

Talking about CSS support in Inkscape, a style dialog box will be added during GSoC this year. A design has already been proposed by Tavmjong at [1]. Some discussions have been done in thread 'Style Dialog'. We need a review of the design for the style dialog from the interface team. Which options should be available in it? How it should behave when a user interacts with it? Any modifications in the design are most welcome. [1]: http://wiki.inkscape.org/wiki/index.php/Style_Editor -- Kamalpreet Kaur Grewal Blog: http://kamalpreetgrewal.com/

5 8

Gtk3 Documentation in the wiki
by Martin Owens 04 May '16

04 May '16

This is a reminder about the Gtk3 issues page: http://wiki.inkscape.org/wiki/index.php/Gtk_issues We need all developers who do anything with gtk to help fill in the page to document what we've learned and communicate to gnome developers how it could be better. Thank you for listening to this reminder. Best Regards, Martin Owens

5 7

Credits Page
by Martin Owens 03 May '16

03 May '16

Docs and Developers, There's a new credits page on the website, it documents the full list of people who help do documentation, translations and website work: https://inkscape.org/en/credits/ It could be expanded to include regular lp:inkscape codebase too, since the lists are dynamic and most are generated from bzr logs. Best Regards, Martin Owens

1 0