On 10/21/10, Hannes Hochreiner wrote:

So it is still possible to get commit changes until October 25?

Yes, very much so :)

Alexandre Prokoudine http://libregraphicsworld.org

On 23/10/10 23:13, J.B.C.Engelen@...1578... wrote:

...

-----Original Message----- From: Alexandre Prokoudine [mailto:alexandre.prokoudine@...400...]

We were planning to release 0.48.1 around October 25.

Nice. I just committed a bunch of crash bug fixes to trunk and also to 0.48.x.

I notice a lot of "VoidSymbol" in the menu of 0.48.x... am I the only one who has those 'errors' ?

Seeing them too, with r9686 from 0.48.x on OS X 10.5.8:

Menu entries without defined keyboard shortcut have 'VoidSymbol' added instead.

~suv

Drawing paraxial line segments doesn't work with Inkscape 0.48 devel. Only the last segment of a closed shape is replaced by two perpandicular segments. (rev. 9840 and already before while it works very well in 0.48.0

ivan

________________________________ De : "J.B.C.Engelen@...1578..." <J.B.C.Engelen@...1578...> À : alexandre.prokoudine@...400...; inkscape-devel@lists.sourceforge.net Envoyé le : Sam 23 octobre 2010, 23h 13min 40s Objet : Re: [Inkscape-devel] 0.48.1 next week

-----Original Message----- From: Alexandre Prokoudine [mailto:alexandre.prokoudine@...400...] Sent: woensdag 20 oktober 2010 23:13 To: Inkscape Devel List Subject: [Inkscape-devel] 0.48.1 next week

Hi,

We were planning to release 0.48.1 around October 25.

Nice. I just committed a bunch of crash bug fixes to trunk and also to 0.48.x.

I notice a lot of "VoidSymbol" in the menu of 0.48.x... am I the only one who has those 'errors' ?

Cheers, Johan

------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On 23/10/10 23:23, Ivan Louette wrote:

Drawing paraxial line segments doesn't work with Inkscape 0.48 devel. Only the last segment of a closed shape is replaced by two perpandicular segments. (rev. 9840 and already before while it works very well in 0.48.0

Note: does _not_ affect the 0.48.x branch (last tested with revision 9686).

~suv

Thanks a lot !!!

ivan

________________________________ De : Diederik van Lierop <mail@...1689...> À : ~suv <suv-sf@...58...>; Ivan Louette <ivan_louette@...48...> Cc : inkscape-devel@lists.sourceforge.net; J.B.C.Engelen@...1578...; alexandre.prokoudine@...400... Envoyé le : Dim 24 octobre 2010, 10h 50min 05s Objet : Re: [Inkscape-devel] Paraxial line segments stopped to work in Inkscape devel

This was due to my commit. I will fix this today.

Diederik

Works perfectly for me now. Thanks a lot for your fix !

ivan

________________________________ De : Diederik van Lierop <mail@...1689...> À : inkscape-devel@lists.sourceforge.net Envoyé le : Dim 24 octobre 2010, 13h 16min 29s Objet : Re: [Inkscape-devel] Paraxial line segments stopped to work in Inkscape devel

On 10/24/2010 10:50 AM, Diederik van Lierop wrote:

This was due to my commit. I will fix this today.

Diederik

This should have been fixed as of rev. #9847

Please test.

Diederik

------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On 24/10/10 20:39, Ivan Louette wrote:

Perhaps is it already fixed but I didn't upgrade to Ubuntu 10.10. No problems on Ubuntu 10.04.

http://forum.ubuntu-fr.org/viewtopic.php?pid=3808032#p3808032

not fixed - not even known if really an Inkscape issue...

Bug #627134 “Cursor position markers are not cleared from rulers”: https://bugs.launchpad.net/inkscape/+bug/627134

(some stats: 10 duplicate reports, affects 60 people, and has many 'me too' comments as well as 24 additional subscribers)

Also mentioned in the comments: zooming in/out and panning the canvas clears the rulers from the artifacts (leftover triangles marking cursor position).

~suv

On 2010-10-24 20:23, ~suv wrote:

On 23/10/10 23:13, J.B.C.Engelen@...1578... wrote:

...

...

From: Alexandre Prokoudine [mailto:alexandre.prokoudine@...400...]

We were planning to release 0.48.1 around October 25.

...

I notice a lot of "VoidSymbol" in the menu of 0.48.x... am I the only one who has those 'errors' ?

AFAICT either r9679 [1] has to be backed out of the 0.48.x branch, or the other revisions in trunk for the shortcuts in tooltips [2] have to be backported to 0.48.x as well: r9745 and r9747 [3].

I have an obvious preference (get the tooltips in there), as this was an oft heard problem during LGM and could really help the discoverability of shortcuts. However, I'm very busy trying to finish my master thesis and don't really have the time to figure out how to properly backport those changes and check that they didn't break anything else. So if someone else could have a go at it that would be great! Otherwise it might just be better to back out r9679 (assuming that that indeed helps and doesn't introduce any more serious problems).

On Thu, Oct 28, 2010 at 6:04 PM, Tavmjong Bah wrote:

On Thu, 2010-10-21 at 01:12 +0400, Alexandre Prokoudine wrote:

...

Hi,

We were planning to release 0.48.1 around October 25.

Are there any issues of satble version somebody is working on or planning to work on in the coming days?

Do we have Windows and Mac packagers at the ready for that?

Do you know of any reason we should postpone this point release?

It's probably too late for 0.48.1

I don't think it is. Nobody cut a release to the best of my knowledge.

but here are two regressions I've just found:

1. It is no longer possible to scale/rotate patterns used to fill text

(related to changing the snap point for text?).

2. Export to PDF of an object masked with a gradient is broken.

Good gods, that's really not good at all.

Alexandre Prokoudine http://libregraphicsworld.org

On 28/10/10 16:04, Tavmjong Bah wrote:

On Thu, 2010-10-21 at 01:12 +0400, Alexandre Prokoudine wrote:

...

We were planning to release 0.48.1 around October 25.

Are there any issues of satble version somebody is working on or planning to work on in the coming days?

Do we have Windows and Mac packagers at the ready for that?

Do you know of any reason we should postpone this point release?

It's probably too late for 0.48.1 but here are two regressions I've just found:

1. It is no longer possible to scale/rotate patterns used to fill text

(related to changing the snap point for text?).

Reproduced with Inkscape 0.48.0 and 0.48+devel r9860 on OS X 10.5.8 Possibly not implemented in the new node tool?

~suv

Looks like I have fixed it. As a bonus we get multiple shape editing (e.g. editing 4 rects and 2 ellipses at the same time) for free in the node tool. The shape tools still can't handle many shapes at once though, and there are no multi-shape features.

See rev. 9867 in trunk, 9708 in stable.

There's still the ruler redraw issue.

Regards, Krzysztof

On 1/11/10 04:50, ~suv wrote:

@Krzysztof - another question about the current state of the node tool:

In revision 9827 (trunk) as well as in the 0.48.x branch (r9685) you removed the feature to retract the handles of cusp nodes by applying the shortcut 'Shift+C' twice (or clicking on the 'Make selected nodes corner' button on the controls bar twice).

° The feature to retract the handles of all selected nodes was useful imho e.g. to quickly reset a curved path or to turn a selection of non-adjacent nodes into sharp corners. There is no real alternative for it: changing the segment type requires and thus affects at least two adjacent nodes, 'Ctrl-clicking' the handles for each node manually to retract it can be impracticable if the change is needed for a bigger selection of nodes in a complex path. But even to make two non-adjacent cusp nodes sharp, it now requires at least 4 (Ctrl+)clicks, possibly more if one needs to zoom in on each node or make the handles visible first.

Personally I think this is a regression or loss of usability for the node tool. Was the reason to disable the feature to retract the handles of cusp nodes purely technical or do you think there is no need for this feature when node-editing complex paths? Can it be restored? What do others think about this change?

Attaching simple use case: starting with a star with smoothed (rounded) corners, I want to make the inner nodes sharp corners (i.e. handles rectracted) but keep the outer ones smooth and with unchanged handle lengths to get the outline of a simple flower.

I can't do this in current trunk and 0.48.x unless -- in this simple example -- I Ctrl-click on 48 handles individually, a task that could be done with a rubber-band selection and 'Shift+C Shift+C' in earlier revisions. Using segment commands doesn't help to achieve the desired path because it needs and affects adjacent nodes.

~suv

On 1/11/10 17:47, Krzysztof Kosiński wrote:

W dniu 1 listopada 2010 04:50 użytkownik ~suv <suv-sf@...58...> napisał:

...

On 31/10/10 19:40, Krzysztof Kosiński wrote: ° The feature to retract the handles of all selected nodes was useful imho e.g. to quickly reset a curved path or to turn a selection of non-adjacent nodes into sharp corners. There is no real alternative for it: changing the segment type requires and thus affects at least two adjacent nodes, 'Ctrl-clicking' the handles for each node manually to retract it can be impracticable if the change is needed for a bigger selection of nodes in a complex path. But even to make two non-adjacent cusp nodes sharp, it now requires at least 4 (Ctrl+)clicks, possibly more if one needs to zoom in on each node or make the handles visible first.

As a compromise, I can reintroduce that, but the handles will only be retracted when all selected nodes are cusp. The reason for removing it was that if you selected a cusp node and a smooth node and clicked the cusp node button, the smooth node would be turned to cusp, while the cusp node would have its handles retracted. This is rather annoying and you can destroy your path accidentally.

I don't understand yet how this would work in practice:

If handles will only be retracted when all selected nodes are cusp, does it still allow to convert a selection of mostly smooth nodes to cusp nodes?

If yes, then after using the command once, all nodes are cusp now (though some still have colinear handles), and another 'Shift+C' would retract all handles -> same as previous behavior.

If no, it means that you actually disallow converting smooth nodes into cusp nodes as soon as there is at least one cusp node among the selected. This however doesn't make converting node types easier because in this case the user has to find and deselct each and every cusp node within the selection first (possibly not an easy task if e.g. a cusp and a smooth node coincide or are very close).

Why do you want to change the behavior of the previous two releases? I could find no bug report asking for such a change or complaining about the previous behavior of 'Shift+C':

'Shift+C' converted a smooth node into a cusp node (keeping the handles and appearance unchanged), and retracted handles of cusp nodes (if present). If applied twice to the same selection (be it smooth, cusp or a mix of nodes), in effect all handles were retracted. If a smooth or half-smooth node needed to stay (half-)smooth, it could still be changed back to smooth after the first command without loss because its handles stayed unchanged.

~suv

On 2/11/10 00:29, Krzysztof Kosiński wrote:

W dniu 1 listopada 2010 20:27 użytkownik ~suv <suv-sf@...58...> napisał:

...

If handles will only be retracted when all selected nodes are cusp, does it still allow to convert a selection of mostly smooth nodes to cusp nodes?

If yes, then after using the command once, all nodes are cusp now (though some still have colinear handles), and another 'Shift+C' would retract all handles -> same as previous behavior.

Yes, this will be the new behavior. Previously, when you selected a cusp and a smooth node, clicking on the cusp node button would convert the smooth node to cusp and simultaneously retract the handles of the cusp node. (Probably the old node tool behaved this way, but the new one didn't)

My logic module must have had low battery yesterday ;)

So, the difference I failed to grasp between the behavior as seen in 0.47 / 0.48 and your proposed compromise is about the 'intermediary' state of cusp nodes with extracted handles (joining two curves or a curve and a line):

A -- previous behavior with a selection of mixed nodes types:

Shift+C Shift+C initial node type | | | | | smooth (h visible) --> cusp (h unchanged) --> cusp (h retracted) cusp (h extracted) --> cusp (h retracted) --> cusp (h no-op) cusp (h retracted) --> cusp (h no-op) --> cusp (h no-op)

B -- proposed behavior with a selection of mixed nodes types:

Shift+C Shift+C initial node type | | | | | smooth (h visible) --> cusp (h unchanged) --> cusp (h retracted) cusp (h extracted) --> cusp (h no-op) --> cusp (h retracted) cusp (h retracted) --> cusp (h no-op) --> cusp (h no-op)

I think this would be fine (tests with the actual tool outstanding), but certainly it would be appreciated to have the feature to retract the handles of multiple selected nodes restored.

Thanks for looking into this, ~suv

p.s.

Possibly a slightly related issue: Bug #655222 “Tangent node doesn't remain smooth after removing control handles”: https://bugs.launchpad.net/inkscape/+bug/610817 also reported in https://bugs.launchpad.net/inkscape/+bug/610817

... and in case you have some spare time ;) list of reports tagged with 'node-editing' sorted by 'newest first': https://bugs.launchpad.net/inkscape/+bugs?field.tag=node-editing&orderby=-datecreated&field.omit_dupes.used and a shorter one, tagged with 'node-editing' and 'regression': https://bugs.launchpad.net/inkscape/+bugs?field.tag=node-editing+regression&field.tags_combinator=ALL&orderby=-datecreated&field.omit_dupes.used

W dniu 7 listopada 2010 08:55 użytkownik ~suv <suv-sf@...58...> napisał:

1. r9875 fails to build for me with this error:

LeWitt:mp-x11 suv$ time make make  all-recursive Making all in src make  all-am  CXX    ui/dialog/aboutbox.o  CXX    ui/tool/multi-path-manipulator.o ui/tool/multi-path-manipulator.cpp: In member function ‘virtual bool Inkscape::UI::MultiPathManipulator::event(GdkEvent*)’: ui/tool/multi-path-manipulator.cpp:628: error: ‘SEGMENT_LINEAR’ was not declared in this scope make[3]: *** [ui/tool/multi-path-manipulator.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

9876 and later should be OK (Thanks Jon). It should have been SEGMENT_STRAIGHT - I had it correct but then accidentally undid it.

2. reintroduce missing shortcut(s) in revision 9875:

...

Reintroduce Shift+L shortcut and handle retraction when setting the type of already cusp nodes to cusp in the node tool

On this occasion could you please also reintroduce the corresponding shortcut to turn a straight line segment into a curve - 'Shift+U'?

http://inkscape.org/doc/keys048.html#id2407623 https://bugs.launchpad.net/inkscape/+bug/532905

OK

3. trunk fails to build on Windows most likely due to recent changes in

revisions 9867 and/or 9868 (fix pattern editing, edit multiple non-path shapes at once)

https://bugs.launchpad.net/inkscape/+bug/670296

I will upgrade the Boost headers in devlibs to something more recent.

Regards, Krzysztof

W dniu 7 listopada 2010 22:46 użytkownik Jon Cruz <jon@...18...> napisał:

If it is a problem with older versions of the BOOST libraries, then updating the libs on windows is really just suppressing a symptom rather than fixing the root cause. A little autoconf tweak, or just using existing #ifdefs should fix it for all platforms.

The build failure is caused by a bug in Boost.MPL. The version in devlibs is 4 years old (1.34.1). No errors were reported for Unix environments so far. So in this specific case upgrading Boost in devlibs to fix it should be OK. If any Linux distro had such an ancient copy of Boost, it would fail our GTK platform requirements.

Regards, Krzysztof

On Nov 7, 2010, at 2:19 PM, Krzysztof Kosiński wrote:

The build failure is caused by a bug in Boost.MPL. The version in devlibs is 4 years old (1.34.1). No errors were reported for Unix environments so far. So in this specific case upgrading Boost in devlibs to fix it should be OK. If any Linux distro had such an ancient copy of Boost, it would fail our GTK platform requirements.

Thanks, the version number was what I was literally writing a note to ask for.

The most helpful thing would be to determine which version of BOOST fixes the issue. We now know that it is somewhere later than 1.34.1 but before 1.44.

Again, though, I'd like to stress that "build for me" or "builds for us" is not always a safe test. I just did a quick scan, and found that one of the main corporate distros (RHEL 5, CentOS 5) has BOOST 1.33.1. So if we require more than that, we cut ourselves out of a huge portion of the professional market.

A quick RPM Find search shows that OpenSUSE 11 had BOOST 1.34.1. That is a current version of OpenSUSE. BOOST 1.36.1 and 1.39.0 are also in 11.x versions

The bottom line is that if we do bump up requirements, we need to be precise about it. If nothing else we will be able to let people know up front that their distro is no longer supported. And avoiding a requirement on the latest-and-greatest of a lib will keep our potential users from being significantly reduced.