4. Feature Freeze √ Stable Branch is forked from Mainline √ Regular development resumes on Mainline. √ Avoid major refactorings on Mainline. √ Only bug fixes committed to Stable Branch. √ Bug fixes are cherrypicked from Mainline. √ Inkscape must pass 'make distcheck' String Freeze √ No further string changes allowed on Stable Branch. √ Finalize tutorials to be shipped with release √ Finalize other docs included in the release √ Finalize about screen √ Finalize Release Notes except Known Issues √ Translators work on translations. √ Recruit Release Wardens for Hard Freeze
5. Hard freeze. √ Only Release Wardens can commit to Stable Branch Cherrypick bug fixes from Mainline to Stable Complete any late work under advisement of Wardens Focus on release-critical bug fixing. Finalize all extensions Finalize codebase translations Finalize Known Issues section of Release Notes Finalize packaging scripts Post additional inkscape-0.91-pre*.tar.gz releases
Inkscape has completed Feature Freeze and String Freeze, and is now moving to Hard Freeze.
Translators, thanks for your efforts. If there are any late translations please coordinate with Jazzynico, and submit them to him for committing. We're down to the wire though so don't delay!
Developers, at this point only Josh and I should be committing to the tree. We'll accept patches if they're either a) obviously safe and a useful fix, or b) more complex but fix a particularly severe bug. In either case, please make sure the fix is already applied to the 0.92 branch, and then send Josh and I a backported patch ready to be landed on 0.91.
Josh will follow up with our evaluation of blocker bugs. Things actually look to be in fairly good shape. If anyone has a bug they want to raise as a blocker, now's the time to do it!
Since we're in a new stage of the release, I'll cut one last pre-release tarball.
Bryce
P.S. We're also going to need to do some marketing work to publicise the release, and I'm thinking we should establish a formal marketing team. I'll try to organize something soon; if you're interested in joining early, or have ideas to consider in the meantime, please shoot me an email.
This is good news. However, PowerStroke's "CubicBezierJohan" issue still stands. We either have to remove it for now, or we should rename this to "CubicBezierBeta"? (In the UI, and also in the XML representation)
thanks, Johan
On 20-11-2014 9:18, Bryce Harrington wrote:
Feature Freeze √ Stable Branch is forked from Mainline √ Regular development resumes on Mainline. √ Avoid major refactorings on Mainline. √ Only bug fixes committed to Stable Branch. √ Bug fixes are cherrypicked from Mainline. √ Inkscape must pass 'make distcheck' String Freeze √ No further string changes allowed on Stable Branch. √ Finalize tutorials to be shipped with release √ Finalize other docs included in the release √ Finalize about screen √ Finalize Release Notes except Known Issues √ Translators work on translations. √ Recruit Release Wardens for Hard Freeze
Hard freeze. √ Only Release Wardens can commit to Stable Branch Cherrypick bug fixes from Mainline to Stable Complete any late work under advisement of Wardens Focus on release-critical bug fixing. Finalize all extensions Finalize codebase translations Finalize Known Issues section of Release Notes Finalize packaging scripts Post additional inkscape-0.91-pre*.tar.gz releases
Inkscape has completed Feature Freeze and String Freeze, and is now moving to Hard Freeze.
Translators, thanks for your efforts. If there are any late translations please coordinate with Jazzynico, and submit them to him for committing. We're down to the wire though so don't delay!
Developers, at this point only Josh and I should be committing to the tree. We'll accept patches if they're either a) obviously safe and a useful fix, or b) more complex but fix a particularly severe bug. In either case, please make sure the fix is already applied to the 0.92 branch, and then send Josh and I a backported patch ready to be landed on 0.91.
Josh will follow up with our evaluation of blocker bugs. Things actually look to be in fairly good shape. If anyone has a bug they want to raise as a blocker, now's the time to do it!
Since we're in a new stage of the release, I'll cut one last pre-release tarball.
Bryce
P.S. We're also going to need to do some marketing work to publicise the release, and I'm thinking we should establish a formal marketing team. I'll try to organize something soon; if you're interested in joining early, or have ideas to consider in the meantime, please shoot me an email.
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Johan,
What are your reservations about removing it? What are your reservations about naming it something aside from Beta? Are you planning to change it but want users to have it available in the interim?
Cheers, Josh
On Thu, Nov 20, 2014 at 11:42 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
This is good news. However, PowerStroke's "CubicBezierJohan" issue still stands. We either have to remove it for now, or we should rename this to "CubicBezierBeta"? (In the UI, and also in the XML representation)
thanks, Johan
On 20-11-2014 9:18, Bryce Harrington wrote:
Feature Freeze √ Stable Branch is forked from Mainline √ Regular development resumes on Mainline. √ Avoid major refactorings on Mainline. √ Only bug fixes committed to Stable Branch. √ Bug fixes are cherrypicked from Mainline. √ Inkscape must pass 'make distcheck' String Freeze √ No further string changes allowed on Stable Branch. √ Finalize tutorials to be shipped with release √ Finalize other docs included in the release √ Finalize about screen √ Finalize Release Notes except Known Issues √ Translators work on translations. √ Recruit Release Wardens for Hard Freeze
Hard freeze. √ Only Release Wardens can commit to Stable Branch Cherrypick bug fixes from Mainline to Stable Complete any late work under advisement of Wardens Focus on release-critical bug fixing. Finalize all extensions Finalize codebase translations Finalize Known Issues section of Release Notes Finalize packaging scripts Post additional inkscape-0.91-pre*.tar.gz releases
Inkscape has completed Feature Freeze and String Freeze, and is now moving to Hard Freeze.
Translators, thanks for your efforts. If there are any late translations please coordinate with Jazzynico, and submit them to him for committing. We're down to the wire though so don't delay!
Developers, at this point only Josh and I should be committing to the tree. We'll accept patches if they're either a) obviously safe and a useful fix, or b) more complex but fix a particularly severe bug. In either case, please make sure the fix is already applied to the 0.92 branch, and then send Josh and I a backported patch ready to be landed on 0.91.
Josh will follow up with our evaluation of blocker bugs. Things actually look to be in fairly good shape. If anyone has a bug they want to raise as a blocker, now's the time to do it!
Since we're in a new stage of the release, I'll cut one last pre-release tarball.
Bryce
P.S. We're also going to need to do some marketing work to publicise the release, and I'm thinking we should establish a formal marketing team. I'll try to organize something soon; if you're interested in joining early, or have ideas to consider in the meantime, please shoot me an email.
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I mentioned removing it (like the mirror-extrapolate), but I think Martin told us that some people depend on it, i.e. if we remove it it will break people's files. Of course, such is the risk of using a development version; but it is not very nice.
If we keep it in: I'm all for another name. It is just a suggestion from the technical creator. If people have other ideas, that'd be great. Technically, (iirc), the parameter sets the 'beta' for the whole curve. The UI name is not so important, we can always change that after. But the SVG name, we can't. Having it called "CubicBezierBeta" in SVG I think would be fine. A potential problem is that it is the only interpolator that needs a parameter. If we create another interpolator that needs a parameter, I'm not sure if the current thing is set up well for that.
-Johan
On 20-11-2014 22:01, Josh Andler wrote:
Johan,
What are your reservations about removing it? What are your reservations about naming it something aside from Beta? Are you planning to change it but want users to have it available in the interim?
Cheers, Josh
On Thu, Nov 20, 2014 at 11:42 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
This is good news. However, PowerStroke's "CubicBezierJohan" issue still stands. We either have to remove it for now, or we should rename this to "CubicBezierBeta"? (In the UI, and also in the XML representation)
thanks, Johan
On 20-11-2014 9:18, Bryce Harrington wrote:
Feature Freeze √ Stable Branch is forked from Mainline √ Regular development resumes on Mainline. √ Avoid major refactorings on Mainline. √ Only bug fixes committed to Stable Branch. √ Bug fixes are cherrypicked from Mainline. √ Inkscape must pass 'make distcheck' String Freeze √ No further string changes allowed on Stable Branch. √ Finalize tutorials to be shipped with release √ Finalize other docs included in the release √ Finalize about screen √ Finalize Release Notes except Known Issues √ Translators work on translations. √ Recruit Release Wardens for Hard Freeze
Hard freeze. √ Only Release Wardens can commit to Stable Branch Cherrypick bug fixes from Mainline to Stable Complete any late work under advisement of Wardens Focus on release-critical bug fixing. Finalize all extensions Finalize codebase translations Finalize Known Issues section of Release Notes Finalize packaging scripts Post additional inkscape-0.91-pre*.tar.gz releases
Inkscape has completed Feature Freeze and String Freeze, and is now moving to Hard Freeze.
Translators, thanks for your efforts. If there are any late translations please coordinate with Jazzynico, and submit them to him for committing. We're down to the wire though so don't delay!
Developers, at this point only Josh and I should be committing to the tree. We'll accept patches if they're either a) obviously safe and a useful fix, or b) more complex but fix a particularly severe bug. In either case, please make sure the fix is already applied to the 0.92 branch, and then send Josh and I a backported patch ready to be landed on 0.91.
Josh will follow up with our evaluation of blocker bugs. Things actually look to be in fairly good shape. If anyone has a bug they want to raise as a blocker, now's the time to do it!
Since we're in a new stage of the release, I'll cut one last pre-release tarball.
Bryce
P.S. We're also going to need to do some marketing work to publicise the release, and I'm thinking we should establish a formal marketing team. I'll try to organize something soon; if you're interested in joining early, or have ideas to consider in the meantime, please shoot me an email.
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, Nov 20, 2014 at 1:11 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
If we keep it in: I'm all for another name. It is just a suggestion from the technical creator. If people have other ideas, that'd be great. Technically, (iirc), the parameter sets the 'beta' for the whole curve.
If kept in and the SVG name changes, doesn't that break it for the previous users?
A potential problem is that it is the only interpolator that needs a parameter. If we create another interpolator that needs a parameter, I'm not sure if the current thing is set up well for that.
So additional parameters aren't really future-proof? Would that be for the beta type or any other existing/future interpolators?
Cheers, Josh
On 20-11-2014 22:53, Josh Andler wrote:
On Thu, Nov 20, 2014 at 1:11 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
If we keep it in: I'm all for another name. It is just a suggestion from the technical creator. If people have other ideas, that'd be great. Technically, (iirc), the parameter sets the 'beta' for the whole curve.
If kept in and the SVG name changes, doesn't that break it for the previous users?
Yes, good point. :( I guess the only thing it would change is that there would be a workaround for those people (manually change the name in svg). The whole "temporary johan" tryout thing was very dumb. I'm sorry for that.
A potential problem is that it is the only interpolator that needs a parameter. If we create another interpolator that needs a parameter, I'm not sure if the current thing is set up well for that.
So additional parameters aren't really future-proof? Would that be for the beta type or any other existing/future interpolators?
It just that I have not thought about it. The SVG-name now is "interpolator_beta". That may or may not work for the other interpolator parameters. Worse, the current system forces all interpolator parameters like that to share the same UI name: "Smoothness" currently.
-Johan
Hi,
We need to decide what to do about a whole set of bugs brought on by the current behavior when changing inkscape:document-unit.[1] In 0.48 this attribute only effected what values were shown in the GUI. All values inside the SVG file were still stored as 'user-units' ('px' in CSS styles). In 0.91 changing inkscape:document-unit form the 'Page' tab of the Document Properties dialog changes the 'viewBox' and attempts to change all the length units inside the SVG file (rectangle width/height, etc.) to match. I can see how this could be useful but it is incredibly difficult to do right as illustrated by the number of bugs reported (and the many more I am sure have not been reported, think, for example of all the length values inside filters).
Question: How easy would it be to revert back to the 0.48 behavior for 0.91?
Tav
[1] http://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape:_Document_Unit_Cha...
FYI: I just had a friend upgrade to trunk to get the 0.91 unit behavior. He actually needs this for work to do a very accurate technical design. In other words: the viewBox change is /awesome/. It is very unfortunate that there are bugs related to it. But backing-off completely is a huge step back. I thought most annoying bugs are related to changing the units for an existing document. Is that correct? If so, all we have to do is warn people about that, e.g. with an extra dialog telling people that changing document unit only works for fresh documents or 0.91 documents. Documents from earlier versions of Inkscape may have troubles.
I'm afraid we will run into the exact same problems when we postpone this change to the next release. My intuition tells me that there is no general way to properly upgrade a "broken" Inkscape pre-0.91 document that works in all cases. But I may be wrong of course.
-Johan
On 20-11-2014 21:09, Tavmjong Bah wrote:
Hi,
We need to decide what to do about a whole set of bugs brought on by the current behavior when changing inkscape:document-unit.[1] In 0.48 this attribute only effected what values were shown in the GUI. All values inside the SVG file were still stored as 'user-units' ('px' in CSS styles). In 0.91 changing inkscape:document-unit form the 'Page' tab of the Document Properties dialog changes the 'viewBox' and attempts to change all the length units inside the SVG file (rectangle width/height, etc.) to match. I can see how this could be useful but it is incredibly difficult to do right as illustrated by the number of bugs reported (and the many more I am sure have not been reported, think, for example of all the length values inside filters).
Question: How easy would it be to revert back to the 0.48 behavior for 0.91?
Tav
[1] http://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape:_Document_Unit_Cha...
On Thu, 2014-11-20 at 22:05 +0100, Johan Engelen wrote:
FYI: I just had a friend upgrade to trunk to get the 0.91 unit behavior. He actually needs this for work to do a very accurate technical design. In other words: the viewBox change is /awesome/. It is very unfortunate that there are bugs related to it. But backing-off completely is a huge step back.
Including the viewBox IS awesome. I don't want to get rid of this part. What I want to suppress is changing the ratio between the SVG height/width and viewBox once the document is created which is what happens when the unit identifier is changes. It is this change that causes problems.
I thought most annoying bugs are related to changing the units for an existing document. Is that correct? If so, all we have to do is warn people about that, e.g. with an extra dialog telling people that changing document unit only works for fresh documents or 0.91 documents. Documents from earlier versions of Inkscape may have troubles.
0.91 documents don't work either once you've put in things like clips, filters, symbols etc. This is seriously broken. Changing units on a fresh document does work but then one can use the Generic Template to get whatever SVG unit you want.
I'm afraid we will run into the exact same problems when we postpone this change to the next release. My intuition tells me that there is no general way to properly upgrade a "broken" Inkscape pre-0.91 document that works in all cases. But I may be wrong of course.
-Johan
On 20-11-2014 21:09, Tavmjong Bah wrote:
Hi,
We need to decide what to do about a whole set of bugs brought on by the current behavior when changing inkscape:document-unit.[1] In 0.48 this attribute only effected what values were shown in the GUI. All values inside the SVG file were still stored as 'user-units' ('px' in CSS styles). In 0.91 changing inkscape:document-unit form the 'Page' tab of the Document Properties dialog changes the 'viewBox' and attempts to change all the length units inside the SVG file (rectangle width/height, etc.) to match. I can see how this could be useful but it is incredibly difficult to do right as illustrated by the number of bugs reported (and the many more I am sure have not been reported, think, for example of all the length values inside filters).
Question: How easy would it be to revert back to the 0.48 behavior for 0.91?
Tav
[1] http://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape:_Document_Unit_Cha...
On 20-11-2014 22:27, Tavmjong Bah wrote:
On Thu, 2014-11-20 at 22:05 +0100, Johan Engelen wrote:
FYI: I just had a friend upgrade to trunk to get the 0.91 unit behavior. He actually needs this for work to do a very accurate technical design. In other words: the viewBox change is /awesome/. It is very unfortunate that there are bugs related to it. But backing-off completely is a huge step back.
Including the viewBox IS awesome. I don't want to get rid of this part. What I want to suppress is changing the ratio between the SVG height/width and viewBox once the document is created which is what happens when the unit identifier is changes. It is this change that causes problems.
I thought most annoying bugs are related to changing the units for an existing document. Is that correct? If so, all we have to do is warn people about that, e.g. with an extra dialog telling people that changing document unit only works for fresh documents or 0.91 documents. Documents from earlier versions of Inkscape may have troubles.
0.91 documents don't work either once you've put in things like clips, filters, symbols etc. This is seriously broken. Changing units on a fresh document does work but then one can use the Generic Template to get whatever SVG unit you want.
Ok, so what you are proposing is removing the ability to change units on-the-fly (remove it from UI) until we properly implement it? Then, the use case I mentioned is satisfied by using a document template. And if someone really wants to change units, and take problems for granted, he can go into XML and change the unit.
That sounds OK to me.
How about we "gray out" the widget, with a mouse-over tooltip pointing towards an FAQ item with a more detailed explanation+workaround?
-Johan
On Thu, 2014-11-20 at 23:56 +0100, Johan Engelen wrote:
On 20-11-2014 22:27, Tavmjong Bah wrote:
On Thu, 2014-11-20 at 22:05 +0100, Johan Engelen wrote:
FYI: I just had a friend upgrade to trunk to get the 0.91 unit behavior. He actually needs this for work to do a very accurate technical design. In other words: the viewBox change is /awesome/. It is very unfortunate that there are bugs related to it. But backing-off completely is a huge step back.
Including the viewBox IS awesome. I don't want to get rid of this part. What I want to suppress is changing the ratio between the SVG height/width and viewBox once the document is created which is what happens when the unit identifier is changes. It is this change that causes problems.
I thought most annoying bugs are related to changing the units for an existing document. Is that correct? If so, all we have to do is warn people about that, e.g. with an extra dialog telling people that changing document unit only works for fresh documents or 0.91 documents. Documents from earlier versions of Inkscape may have troubles.
0.91 documents don't work either once you've put in things like clips, filters, symbols etc. This is seriously broken. Changing units on a fresh document does work but then one can use the Generic Template to get whatever SVG unit you want.
Ok, so what you are proposing is removing the ability to change units on-the-fly (remove it from UI) until we properly implement it? Then, the use case I mentioned is satisfied by using a document template. And if someone really wants to change units, and take problems for granted, he can go into XML and change the unit.
That sounds OK to me.
How about we "gray out" the widget, with a mouse-over tooltip pointing towards an FAQ item with a more detailed explanation+workaround?
This sounds like a good solution.
Tav
-Johan
On 2014-11-20 22:27 (+0100), Tavmjong Bah wrote:
On Thu, 2014-11-20 at 22:05 +0100, Johan Engelen wrote:
I thought most annoying bugs are related to changing the units for an existing document. Is that correct? If so, all we have to do is warn people about that, e.g. with an extra dialog telling people that changing document unit only works for fresh documents or 0.91 documents. Documents from earlier versions of Inkscape may have troubles.
0.91 documents don't work either once you've put in things like clips, filters, symbols etc. This is seriously broken. Changing units on a fresh document does work but then one can use the Generic Template to get whatever SVG unit you want.
Just a reminder: the procedural 'Generic canvas ...' template which allows to define an arbitrary document size and choose a unit ("SVG unit:") is not part of 0.91.
The refactoring of the templates (replacing many static templates with procedural ones) originally was committed in experimental (along with the dpi change), and was merged into trunk after the release branch for 0.91.x was created.
On Fri, 2014-11-21 at 09:50 +0100, su_v wrote:
On 2014-11-20 22:27 (+0100), Tavmjong Bah wrote:
On Thu, 2014-11-20 at 22:05 +0100, Johan Engelen wrote:
I thought most annoying bugs are related to changing the units for an existing document. Is that correct? If so, all we have to do is warn people about that, e.g. with an extra dialog telling people that changing document unit only works for fresh documents or 0.91 documents. Documents from earlier versions of Inkscape may have troubles.
0.91 documents don't work either once you've put in things like clips, filters, symbols etc. This is seriously broken. Changing units on a fresh document does work but then one can use the Generic Template to get whatever SVG unit you want.
Just a reminder: the procedural 'Generic canvas ...' template which allows to define an arbitrary document size and choose a unit ("SVG unit:") is not part of 0.91.
The refactoring of the templates (replacing many static templates with procedural ones) originally was committed in experimental (along with the dpi change), and was merged into trunk after the release branch for 0.91.x was created.
Ahh, you are write. The procedural template in 0.91 does not include the unit identifier. We should update 0.91 with the newer procedural template (and get rid of the templates it makes redundant).
Tav
On Thu, Nov 20, 2014 at 10:05:46PM +0100, Johan Engelen wrote:
FYI: I just had a friend upgrade to trunk to get the 0.91 unit behavior. He actually needs this for work to do a very accurate technical design. In other words: the viewBox change is /awesome/. It is very unfortunate that there are bugs related to it. But backing-off completely is a huge step back. I thought most annoying bugs are related to changing the units for an existing document. Is that correct? If so, all we have to do is warn people about that, e.g. with an extra dialog telling people that changing document unit only works for fresh documents or 0.91 documents. Documents from earlier versions of Inkscape may have troubles.
-1 for warning dialogs. Clutter, plus no one bothers reading them.
I'm afraid we will run into the exact same problems when we postpone this change to the next release. My intuition tells me that there is no general way to properly upgrade a "broken" Inkscape pre-0.91 document that works in all cases. But I may be wrong of course.
Delaying it to next release adds time we can use to fix the problems.
For example, hiding the "set document units" functionality would paper over the problem but breaks several use cases. To fix that we could add a "Display units" feature that lets the user work in the GUI with a different set of units than are stored in the document. That's not the sort of feature we want to be putting in the week before release but is certainly something we could do in a 0.92 timeframe.
That's just one example, I'm sure other bugs in the list could similarly benefit from having extra development time to work on.
In general, I'd much rather land the unit changes when we can demonstrate significant new improvements to users, especially if it brings risk of bugs or breaking use cases. Right now it sounds like the benefits it brings are being swamped by the bugs.
-Johan
On 20-11-2014 21:09, Tavmjong Bah wrote:
Hi,
We need to decide what to do about a whole set of bugs brought on by the current behavior when changing inkscape:document-unit.[1] In 0.48 this attribute only effected what values were shown in the GUI. All values inside the SVG file were still stored as 'user-units' ('px' in CSS styles). In 0.91 changing inkscape:document-unit form the 'Page' tab of the Document Properties dialog changes the 'viewBox' and attempts to change all the length units inside the SVG file (rectangle width/height, etc.) to match. I can see how this could be useful but it is incredibly difficult to do right as illustrated by the number of bugs reported (and the many more I am sure have not been reported, think, for example of all the length values inside filters).
Question: How easy would it be to revert back to the 0.48 behavior for 0.91?
Tav
[1] http://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape:_Document_Unit_Cha...
On 21-11-2014 10:41, Bryce Harrington wrote:
On Thu, Nov 20, 2014 at 10:05:46PM +0100, Johan Engelen wrote:
FYI: I just had a friend upgrade to trunk to get the 0.91 unit behavior. He actually needs this for work to do a very accurate technical design. In other words: the viewBox change is /awesome/. It is very unfortunate that there are bugs related to it. But backing-off completely is a huge step back. I thought most annoying bugs are related to changing the units for an existing document. Is that correct? If so, all we have to do is warn people about that, e.g. with an extra dialog telling people that changing document unit only works for fresh documents or 0.91 documents. Documents from earlier versions of Inkscape may have troubles.
-1 for warning dialogs. Clutter, plus no one bothers reading them.
Do you have any good arguments against a warning dialogs? The two given are not convincing. "clutter" : one would only see a warning dialog when there is something to warn about, no clutter there. "no one bothers reading them": This is a warning that would pop up very rarely; not something someone would get used to after seeing it 100s of times. And I think it is simply not true that people don't read text in a dialog.
I'm afraid we will run into the exact same problems when we postpone this change to the next release. My intuition tells me that there is no general way to properly upgrade a "broken" Inkscape pre-0.91 document that works in all cases. But I may be wrong of course.
Delaying it to next release adds time we can use to fix the problems.
For example, hiding the "set document units" functionality would paper over the problem but breaks several use cases. To fix that we could add a "Display units" feature that lets the user work in the GUI with a different set of units than are stored in the document. That's not the sort of feature we want to be putting in the week before release but is certainly something we could do in a 0.92 timeframe.
That's just one example, I'm sure other bugs in the list could similarly benefit from having extra development time to work on.
In general, I'd much rather land the unit changes when we can demonstrate significant new improvements to users, especially if it brings risk of bugs or breaking use cases. Right now it sounds like the benefits it brings are being swamped by the bugs.
I meant to say that we should keep the overall units/viewbox change (not the "change unit" feature). There are significant improvements with having proper units/viewbox. For starters: having the SVG document shows well in other viewers.
As Tav wrote, the only bugs left are when someone /changes/ the units on an existing document with things other than simple paths. Having units on a document as-is now works fine, please someone speak up if not.
-Johan
I just noticed the option is still called "Default units". I thought I mentioned this before, but it should really be renamed to "Document units". "Default units" is a huge misnomer.
- Johan
On 20-11-2014 21:09, Tavmjong Bah wrote:
Hi,
We need to decide what to do about a whole set of bugs brought on by the current behavior when changing inkscape:document-unit.[1] In 0.48 this attribute only effected what values were shown in the GUI. All values inside the SVG file were still stored as 'user-units' ('px' in CSS styles). In 0.91 changing inkscape:document-unit form the 'Page' tab of the Document Properties dialog changes the 'viewBox' and attempts to change all the length units inside the SVG file (rectangle width/height, etc.) to match. I can see how this could be useful but it is incredibly difficult to do right as illustrated by the number of bugs reported (and the many more I am sure have not been reported, think, for example of all the length values inside filters).
Question: How easy would it be to revert back to the 0.48 behavior for 0.91?
Tav
[1] http://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape:_Document_Unit_Cha...
Is "Default units" a misnomer if people can change unit widgets for the document in other places?
Cheers, Josh
On Fri, Nov 21, 2014 at 11:14 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
I just noticed the option is still called "Default units". I thought I mentioned this before, but it should really be renamed to "Document units". "Default units" is a huge misnomer.
- Johan
On 20-11-2014 21:09, Tavmjong Bah wrote:
Hi,
We need to decide what to do about a whole set of bugs brought on by the current behavior when changing inkscape:document-unit.[1] In 0.48 this attribute only effected what values were shown in the GUI. All values inside the SVG file were still stored as 'user-units' ('px' in CSS styles). In 0.91 changing inkscape:document-unit form the 'Page' tab of the Document Properties dialog changes the 'viewBox' and attempts to change all the length units inside the SVG file (rectangle width/height, etc.) to match. I can see how this could be useful but it is incredibly difficult to do right as illustrated by the number of bugs reported (and the many more I am sure have not been reported, think, for example of all the length values inside filters).
Question: How easy would it be to revert back to the 0.48 behavior for 0.91?
Tav
[1] http://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape:_Document_Unit_Cha...
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
To me, it is a misnomer because widgets using it as "default units" is incidental. The setting is stored under "inkscape:document-units" in SVG.
So this is what confuses me then perhaps? People want it to work as setting the default unit for the UI?
As Bryce wrote:
"To fix that we could add a "Display units" feature that lets the user work in the GUI with a different set of units than are stored in the document. That's not the sort of feature we want to be putting in the week before release but is certainly something we could do in a 0.92 timeframe."
I think we could easily get such an extra setting in 0.91.1. (stored e.g. as "inkscape:display-units")
-Johan
On 21-11-2014 20:58, Josh Andler wrote:
Is "Default units" a misnomer if people can change unit widgets for the document in other places?
Cheers, Josh
On Fri, Nov 21, 2014 at 11:14 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
I just noticed the option is still called "Default units". I thought I mentioned this before, but it should really be renamed to "Document units". "Default units" is a huge misnomer.
- Johan
On 20-11-2014 21:09, Tavmjong Bah wrote:
Hi,
We need to decide what to do about a whole set of bugs brought on by the current behavior when changing inkscape:document-unit.[1] In 0.48 this attribute only effected what values were shown in the GUI. All values inside the SVG file were still stored as 'user-units' ('px' in CSS styles). In 0.91 changing inkscape:document-unit form the 'Page' tab of the Document Properties dialog changes the 'viewBox' and attempts to change all the length units inside the SVG file (rectangle width/height, etc.) to match. I can see how this could be useful but it is incredibly difficult to do right as illustrated by the number of bugs reported (and the many more I am sure have not been reported, think, for example of all the length values inside filters).
Question: How easy would it be to revert back to the 0.48 behavior for 0.91?
Tav
[1] http://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape:_Document_Unit_Cha...
On Fri, Nov 21, 2014 at 12:09 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
So this is what confuses me then perhaps? People want it to work as setting the default unit for the UI?
If I'm not mistaken, that is all it did in 0.41-0.48.5.
Cheers, Josh
On 21-11-2014 21:17, Josh Andler wrote:
On Fri, Nov 21, 2014 at 12:09 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
So this is what confuses me then perhaps? People want it to work as setting the default unit for the UI?
If I'm not mistaken, that is all it did in 0.41-0.48.5.
Ok, so shall I then disable the change to viewbox upon Default unit change? It is pretty straightforward to do.
-Johan
On 22-11-2014 19:24, Johan Engelen wrote:
On 21-11-2014 21:17, Josh Andler wrote:
On Fri, Nov 21, 2014 at 12:09 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
So this is what confuses me then perhaps? People want it to work as setting the default unit for the UI?
If I'm not mistaken, that is all it did in 0.41-0.48.5.
Ok, so shall I then disable the change to viewbox upon Default unit change? It is pretty straightforward to do.
See rev. 13748 in trunk.
-J
Thanks for looking into this. I will do some tests, apply it against my copy of 0.91.x, do the same tests again, and report back.
Cheers, Josh
On Sat, Nov 22, 2014 at 10:40 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 22-11-2014 19:24, Johan Engelen wrote:
On 21-11-2014 21:17, Josh Andler wrote:
On Fri, Nov 21, 2014 at 12:09 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
So this is what confuses me then perhaps? People want it to work as setting the default unit for the UI?
If I'm not mistaken, that is all it did in 0.41-0.48.5.
Ok, so shall I then disable the change to viewbox upon Default unit change? It is pretty straightforward to do.
See rev. 13748 in trunk.
-J
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Thanks Johan,
I hope this works as it would really move us closer to a release. This exactly the solution I was hoping for.
I've found a rather nasty bug if units are changed to 'meters' and back but maybe it won't matter in 0.91 with the change you've made.
I think it might be worth back porting the procedural templates that are in trunk. This certainly would be a huge cleanup of the templates under 'File->New->Templates' and would allow one to choose in many cases the default document unit when the new file is created (something that is suppose to be a highlight of this release). Please compare the list of templates between trunk and 0.91. The only possible disadvantage of back porting is the need to translate the new templates.
Tav
On Sat, 2014-11-22 at 10:44 -0800, Josh Andler wrote:
Thanks for looking into this. I will do some tests, apply it against my copy of 0.91.x, do the same tests again, and report back.
Cheers, Josh
On Sat, Nov 22, 2014 at 10:40 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 22-11-2014 19:24, Johan Engelen wrote:
On 21-11-2014 21:17, Josh Andler wrote:
On Fri, Nov 21, 2014 at 12:09 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
So this is what confuses me then perhaps? People want it to work as setting the default unit for the UI?
If I'm not mistaken, that is all it did in 0.41-0.48.5.
Ok, so shall I then disable the change to viewbox upon Default unit change? It is pretty straightforward to do.
See rev. 13748 in trunk.
-J
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, Nov 22, 2014 at 11:21 AM, Tavmjong Bah <tavmjong@...8...> wrote:
I think it might be worth back porting the procedural templates that are in trunk. This certainly would be a huge cleanup of the templates under 'File->New->Templates' and would allow one to choose in many cases the default document unit when the new file is created (something that is suppose to be a highlight of this release). Please compare the list of templates between trunk and 0.91. The only possible disadvantage of back porting is the need to translate the new templates.
The procedural templates would add new string changes which we cannot do at this point unless we're okay with having untranslated strings (I'm not a fan of such a big code change as well as the untranslated strings myself). However, instead of porting, we should probably discuss when to start the release process for 0.92. If we get 0.91 out and 0.92 doesn't have any major new regressions, I see no reason not to push into chilling right after the holidays. We could target a late winter or early spring 0.92 release if all goes well and if we're not in bad shape currently.
Cheers, Josh
On Sat, Nov 22, 2014 at 08:21:10PM +0100, Tavmjong Bah wrote:
Thanks Johan,
I hope this works as it would really move us closer to a release. This exactly the solution I was hoping for.
I've found a rather nasty bug if units are changed to 'meters' and back but maybe it won't matter in 0.91 with the change you've made.
What was the issue?
I recall seeing a problem when changing between meters and back due to loss of significance, which resulted in slightly offset nodes here and there. A similar issue could occur with aligned lines becoming disaligned (i.e. two nearly exact points prior to unit change become signficantly non-exact post change, to where the lines visibly diverge).
If the issue you saw was something along those lines, I think there's no easy work around - the fix will be when we switch to a single document unit type.
I think it might be worth back porting the procedural templates that are in trunk. This certainly would be a huge cleanup of the templates under 'File->New->Templates' and would allow one to choose in many cases the default document unit when the new file is created (something that is suppose to be a highlight of this release). Please compare the list of templates between trunk and 0.91. The only possible disadvantage of back porting is the need to translate the new templates.
Sorry, Josh is right - The time is already come and gone for string changes for 0.91.0.
Bryce
Tav
On Sat, 2014-11-22 at 10:44 -0800, Josh Andler wrote:
Thanks for looking into this. I will do some tests, apply it against my copy of 0.91.x, do the same tests again, and report back.
Cheers, Josh
On Sat, Nov 22, 2014 at 10:40 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 22-11-2014 19:24, Johan Engelen wrote:
On 21-11-2014 21:17, Josh Andler wrote:
On Fri, Nov 21, 2014 at 12:09 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
So this is what confuses me then perhaps? People want it to work as setting the default unit for the UI?
If I'm not mistaken, that is all it did in 0.41-0.48.5.
Ok, so shall I then disable the change to viewbox upon Default unit change? It is pretty straightforward to do.
See rev. 13748 in trunk.
-J
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, 2014-11-22 at 16:26 -0800, Bryce Harrington wrote:
On Sat, Nov 22, 2014 at 08:21:10PM +0100, Tavmjong Bah wrote:
Thanks Johan,
I hope this works as it would really move us closer to a release. This exactly the solution I was hoping for.
I've found a rather nasty bug if units are changed to 'meters' and back but maybe it won't matter in 0.91 with the change you've made.
What was the issue?
I hadn't turned up issues with my own testing yesterday, but it's not surprising that suv was able to do so. :) Note the following does not happen in unpatched 0.91.
With patched 0.91, behavior is incorrect in the following scenario: 1) Launch patched 0.91.x with default new prefs (default new doc) 2) Open Document Properties, change Default units to mm 3) Draw a rect, then change the size numerically in the Rectangle Tool Controls bar to something round like 100x100 (ruler will show it's not as expected) 4) Switch to Selector Tool and look at the width and height in the Controls Bar
Symptoms: The rect is nowhere near the correct size on canvas. The rectangle tool reports a different size than selector tool & rulers.
It does appear that the root issue happens in trunk as well (it manifests differently though as the scaling looks to be off in the other direction). In Trunk for step 2 switch to px instead. It seems like this issue is probably worth looking into since it exists in both branches (0.91 possibly just papered over) and could be rectangle tool specific.
Cheers, Josh
On Sat, Nov 22, 2014 at 10:44 AM, Josh Andler <scislac@...400...> wrote:
Thanks for looking into this. I will do some tests, apply it against my copy of 0.91.x, do the same tests again, and report back.
Cheers, Josh
On Sat, Nov 22, 2014 at 10:40 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 22-11-2014 19:24, Johan Engelen wrote:
On 21-11-2014 21:17, Josh Andler wrote:
On Fri, Nov 21, 2014 at 12:09 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
So this is what confuses me then perhaps? People want it to work as setting the default unit for the UI?
If I'm not mistaken, that is all it did in 0.41-0.48.5.
Ok, so shall I then disable the change to viewbox upon Default unit change? It is pretty straightforward to do.
See rev. 13748 in trunk.
-J
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Nevermind the optimism about it possibly being just in the rect tool... it manifests with Extensions too (thanks to suv again for finding).
Same steps of changing document to px for trunk or mm for patched 0.91. Then run Extensions>Render>Gear>Gear... (or another extension which uses units) and it will be scaled incorrectly as well.
Cheers, Josh
On Sun, Nov 23, 2014 at 10:09 AM, Josh Andler <scislac@...400...> wrote:
I hadn't turned up issues with my own testing yesterday, but it's not surprising that suv was able to do so. :) Note the following does not happen in unpatched 0.91.
With patched 0.91, behavior is incorrect in the following scenario:
- Launch patched 0.91.x with default new prefs (default new doc)
- Open Document Properties, change Default units to mm
- Draw a rect, then change the size numerically in the Rectangle Tool
Controls bar to something round like 100x100 (ruler will show it's not as expected) 4) Switch to Selector Tool and look at the width and height in the Controls Bar
Symptoms: The rect is nowhere near the correct size on canvas. The rectangle tool reports a different size than selector tool & rulers.
It does appear that the root issue happens in trunk as well (it manifests differently though as the scaling looks to be off in the other direction). In Trunk for step 2 switch to px instead. It seems like this issue is probably worth looking into since it exists in both branches (0.91 possibly just papered over) and could be rectangle tool specific.
Cheers, Josh
On Sat, Nov 22, 2014 at 10:44 AM, Josh Andler <scislac@...400...> wrote:
Thanks for looking into this. I will do some tests, apply it against my copy of 0.91.x, do the same tests again, and report back.
Cheers, Josh
On Sat, Nov 22, 2014 at 10:40 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 22-11-2014 19:24, Johan Engelen wrote:
On 21-11-2014 21:17, Josh Andler wrote:
On Fri, Nov 21, 2014 at 12:09 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
So this is what confuses me then perhaps? People want it to work as setting the default unit for the UI?
If I'm not mistaken, that is all it did in 0.41-0.48.5.
Ok, so shall I then disable the change to viewbox upon Default unit change? It is pretty straightforward to do.
See rev. 13748 in trunk.
-J
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Yeah :(
The extension framework (inkex.py) was rewritten to properly handle the unit used for SVG coordinates. That code looked at "inkscape:document-unit" for that... But, by now it is clear that "inkscape:document-unit" means "Display units" and is unrelated to the SVG unit used. OK. So I've changed the extension Python code to now calculate the SVG unit from the document width and viewbox [1]. It falls back to 'px' units for any errors, for example when there is no viewbox defined. This should make it work for legacy documents.
Thanks for testing, Johan
( Note that legacy documents use 90dpi, whereas others use 96dpi. I see no possible way to fix this, other than looking at the Inkscape version number in the SVG upon loading the file into newer 96dpi-versions of Inkscape... )
[1] https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13750/ https://bazaar.launchpad.net/%7Einkscape.dev/inkscape/trunk/revision/13750/
On 23-11-2014 20:38, Josh Andler wrote:
Nevermind the optimism about it possibly being just in the rect tool... it manifests with Extensions too (thanks to suv again for finding).
Same steps of changing document to px for trunk or mm for patched 0.91. Then run Extensions>Render>Gear>Gear... (or another extension which uses units) and it will be scaled incorrectly as well.
Cheers, Josh
On Sun, Nov 23, 2014 at 10:09 AM, Josh Andler <scislac@...400...> wrote:
I hadn't turned up issues with my own testing yesterday, but it's not surprising that suv was able to do so. :) Note the following does not happen in unpatched 0.91.
With patched 0.91, behavior is incorrect in the following scenario:
- Launch patched 0.91.x with default new prefs (default new doc)
- Open Document Properties, change Default units to mm
- Draw a rect, then change the size numerically in the Rectangle Tool
Controls bar to something round like 100x100 (ruler will show it's not as expected) 4) Switch to Selector Tool and look at the width and height in the Controls Bar
Symptoms: The rect is nowhere near the correct size on canvas. The rectangle tool reports a different size than selector tool & rulers.
It does appear that the root issue happens in trunk as well (it manifests differently though as the scaling looks to be off in the other direction). In Trunk for step 2 switch to px instead. It seems like this issue is probably worth looking into since it exists in both branches (0.91 possibly just papered over) and could be rectangle tool specific.
Cheers, Josh
On Sat, Nov 22, 2014 at 10:44 AM, Josh Andler <scislac@...400...> wrote:
Thanks for looking into this. I will do some tests, apply it against my copy of 0.91.x, do the same tests again, and report back.
Cheers, Josh
On Sat, Nov 22, 2014 at 10:40 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 22-11-2014 19:24, Johan Engelen wrote:
On 21-11-2014 21:17, Josh Andler wrote:
On Fri, Nov 21, 2014 at 12:09 PM, Johan Engelen <jbc.engelen@...2592...> wrote: > So this is what confuses me then perhaps? > People want it to work as setting the default unit for the UI? If I'm not mistaken, that is all it did in 0.41-0.48.5.
Ok, so shall I then disable the change to viewbox upon Default unit change? It is pretty straightforward to do.
See rev. 13748 in trunk.
-J
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 20 Nov 2014 00:18:42 -0800 Bryce Harrington <bryce@...961...> wrote:
<snip>
String Freeze √ No further string changes allowed on Stable Branch. √ Finalize tutorials to be shipped with release
Tutorial of Tracing-pixcelart is incomplete yet. Descriptions of the GUI are already obsolete. Although it's not listed in 0.91-tutorial-review[1], it appears in Help > Tutorials.
√ Finalize other docs included in the release √ Finalize about screen √ Finalize Release Notes except Known Issues √ Translators work on translations. √ Recruit Release Wardens for Hard Freeze
<snip>
[1]http://wiki.inkscape.org/wiki/index.php/0.91-tutorial-review
Masato Hashimoto <cabezon.hashimoto@...400...> a écrit :
Bryce Harrington <bryce@...961...> wrote:
String Freeze √ No further string changes allowed on Stable Branch.
I agree that we should not change existing string so that we don't break existing translations, but is it still ok to add missing strings? I'm referring to Bug #1388916 "There seem to be untranslatable strings in MapSymbolsNPS.svg" (https://bugs.launchpad.net/inkscape/+bug/1388916).
√ Finalize tutorials to be shipped with releaseTutorial of Tracing-pixcelart is incomplete yet. Descriptions of the GUI are already obsolete. Although it's not listed in 0.91-tutorial-review[1], it appears in Help > Tutorials.
Thanks for the reminder, Masato. I'm going to work on the documentation files (tutorials, man pages and Keys and mouse reference) next week and generate updated SVG versions. While I'm at it, I'll try to fix the Pixelart tutorial. Of course it would be great if someone with very good English skills could help (the minimum would be to review my changes...).
Regards, -- Nicolas
On Sat, Nov 22, 2014 at 07:59:26PM +0000, Nicolas Dufour wrote:
Masato Hashimoto <cabezon.hashimoto@...400...> a écrit :
Bryce Harrington <bryce@...961...> wrote:
String Freeze √ No further string changes allowed on Stable Branch.I agree that we should not change existing string so that we don't break existing translations, but is it still ok to add missing strings? I'm referring to Bug #1388916 "There seem to be untranslatable strings in MapSymbolsNPS.svg" (https://bugs.launchpad.net/inkscape/+bug/1388916).
You can use your judgment as translation coordinator. Addition of strings for translation is lower risk since it doesn't break existing translations. However, we're maybe a week or two from release so there may not a lot of time to translate them. So, again, use your judgment.
√ Finalize tutorials to be shipped with releaseTutorial of Tracing-pixcelart is incomplete yet. Descriptions of the GUI are already obsolete. Although it's not listed in 0.91-tutorial-review[1], it appears in Help > Tutorials.
Thanks for the reminder, Masato. I'm going to work on the documentation files (tutorials, man pages and Keys and mouse reference) next week and generate updated SVG versions. While I'm at it, I'll try to fix the Pixelart tutorial. Of course it would be great if someone with very good English skills could help (the minimum would be to review my changes...).
I would suggest if there are changes to the english versions of the documentations, to hold those for 0.91.1, and focus on just getting the existing versions translated. We probably only have a week or two left for this work.
Bryce
On Sat, 22 Nov 2014 16:57:40 -0800 Bryce Harrington <bryce@...961...> wrote:
On Sat, Nov 22, 2014 at 07:59:26PM +0000, Nicolas Dufour wrote:
Masato Hashimoto <cabezon.hashimoto@...400...> a écrit :
Bryce Harrington <bryce@...961...> wrote:
String Freeze √ No further string changes allowed on Stable Branch.I agree that we should not change existing string so that we don't break existing translations, but is it still ok to add missing strings? I'm referring to Bug #1388916 "There seem to be untranslatable strings in MapSymbolsNPS.svg" (https://bugs.launchpad.net/inkscape/+bug/1388916).
You can use your judgment as translation coordinator. Addition of strings for translation is lower risk since it doesn't break existing translations. However, we're maybe a week or two from release so there may not a lot of time to translate them. So, again, use your judgment.
As a translator, I'd like to be decided it asap:)
√ Finalize tutorials to be shipped with releaseTutorial of Tracing-pixcelart is incomplete yet. Descriptions of the GUI are already obsolete. Although it's not listed in 0.91-tutorial-review[1], it appears in Help > Tutorials.
Thanks for the reminder, Masato. I'm going to work on the documentation files (tutorials, man pages and Keys and mouse reference) next week and generate updated SVG versions. While I'm at it, I'll try to fix the Pixelart tutorial. Of course it would be great if someone with very good English skills could help (the minimum would be to review my changes...).
I would suggest if there are changes to the english versions of the documentations, to hold those for 0.91.1, and focus on just getting the existing versions translated. We probably only have a week or two left for this work.
Bryce
Traceing-pixelart tutorial is a brand-new tutorial for 0.91. And current it describes about non-existent GUI. IMHO, we have two options for it which include it in 0.91 or not (in 0.91.1).
Masato Hashimoto <cabezon.hashimoto@...400...> a écrit :
As a translator, I'd like to be decided it asap:)
Decided. The NPS symbols file is now fixed in the branch and the trunk. Thanks for the patch!
Traceing-pixelart tutorial is a brand-new tutorial for 0.91. And current it describes about non-existent GUI.
The tutorial is currently fully translated to Greek and Dutch. Changing the content would break those translations, and I'm not sure the affected translators still have time to work on it. That said, it would be really bad to release a new feature with an incorrect tutorial... I'd rather have an English only tutorial.
IMHO, we have two options for it which include it in 0.91 or not (in 0.91.1).
Point releases are bugfix only, and should not include string changes. But if can contain new or updated translations. If we don't fix the tutorials now, it will wait until 0.92... Thus I suggest we do our best to have a clean tutorial as soon as possible, and, if translators don't find time to work on it, let them know that the translations can be included in 0.91.1.
Regards, -- Nicolas
On Sun, 23 Nov 2014 17:38:45 +0000 (UTC) Nicolas Dufour <nicoduf@...48...> wrote:
<snip>
Traceing-pixelart tutorial is a brand-new tutorial for 0.91. And current it describes about non-existent GUI.
The tutorial is currently fully translated to Greek and Dutch. Changing the content would break those translations, and I'm not sure the affected translators still have time to work on it. That said, it would be really bad to release a new feature with an incorrect tutorial... I'd rather have an English only tutorial.
On Sun, 23 Nov 2014 16:57:16 -0800 Bryce Harrington <bryce@...961...> wrote:
On Mon, Nov 24, 2014 at 02:01:32AM +0900, Masato Hashimoto wrote:
I would suggest if there are changes to the english versions of the documentations, to hold those for 0.91.1, and focus on just getting the existing versions translated. We probably only have a week or two left for this work.
Bryce
Traceing-pixelart tutorial is a brand-new tutorial for 0.91. And current it describes about non-existent GUI.
The tutorial covers functionality that is not implemented in Inkscape currently? If that's the case then I'd definitely suggest waiting on adding it until later.
Sorry for lucking info, current tracing-pixcelart tutorial describes non-existent GUI "widget" for example:
"What connection should I keep?" is what libdepixelize asks. It tries to apply all heuristics to the conflicting diagonals and keeps the connection of the winner. If a tie happens, both connections are erased.
"What connection should I keep?" isn't existent current GUI (and was existent past revision, afair).
As for me, I already translated the tutorial but I have been found like it so waited it to be updated.
2014-11-24 14:16 GMT-03:00 Masato Hashimoto <cabezon.hashimoto@...400...>:
"What connection should I keep?" isn't existent current GUI (and was existent past revision, afair).
This part explains why there are so many tweaks in the GUI. There was never a "what connection should I keep?" button or will ever be.
Hi,
I'm halfway in my translation of the Tracing Pixel Art tutorial, and I didn't notice anything wrong (except a "don't->doesn't" mistake) so far.
@Masato, did you manage to generate the SVG tutorials recently? I'm currently stuck with wrong attribute values (mainly y="0INVALID" attributes in rectangle elements) that prevent the SVG from showing correctly. I've tried to use Inkscape 0.48.5 instead of 0.91, and switch between OpenJDK and Oracle Java, with no success unfortunately... I guess there's something wrong with my computer, but it would be great if you could confirm it works for you. Thanks!
-- Nicolas
On Mon, Nov 24, 2014 at 02:01:32AM +0900, Masato Hashimoto wrote:
I would suggest if there are changes to the english versions of the documentations, to hold those for 0.91.1, and focus on just getting the existing versions translated. We probably only have a week or two left for this work.
Bryce
Traceing-pixelart tutorial is a brand-new tutorial for 0.91. And current it describes about non-existent GUI.
The tutorial covers functionality that is not implemented in Inkscape currently? If that's the case then I'd definitely suggest waiting on adding it until later.
IMHO, we have two options for it which include it in 0.91 or not (in 0.91.1).
Our intent is to get 0.91.1 out fairly soon after 0.91.0 so please don't feel rushed at getting it in now if it's not yet 100% ready.
Bryce
2014-11-21 4:27 GMT-03:00 Masato Hashimoto <cabezon.hashimoto@...400...>:
Tutorial of Tracing-pixcelart is incomplete yet. Descriptions of the GUI are already obsolete.
2014-11-23 14:01 GMT-03:00 Masato Hashimoto <cabezon.hashimoto@...400...>:
Traceing-pixelart tutorial is a brand-new tutorial for 0.91. And current it describes about non-existent GUI.
I just compiled Inkscape (`bzr info` gives me branch bzr+ssh:// bazaar.launchpad.net/+branch/inkscape/ ) and I fail to see the out-of-sync references.
Care to elaborate?
On Thu, Nov 20, 2014 at 12:18 AM, Bryce Harrington <bryce@...961...> wrote:
Since we're in a new stage of the release, I'll cut one last pre-release tarball.
I would just ask that if a new pre is going to be cut that we get the patch [1] for Default units/viewbox landed in the branch first. I'd like to test things further over the weekend though before I'd be comfortable endorsing it though.
P.S. We're also going to need to do some marketing work to publicise the release, and I'm thinking we should establish a formal marketing team. I'll try to organize something soon; if you're interested in joining early, or have ideas to consider in the meantime, please shoot me an email.
I think so too. Obviously I'll be interested in trying to help get this going as well.
Cheers, Josh
[1] https://bugs.launchpad.net/inkscape/+bug/1387864/comments/2
On Sat, Nov 22, 2014 at 02:44:11PM -0800, Josh Andler wrote:
On Thu, Nov 20, 2014 at 12:18 AM, Bryce Harrington <bryce@...961...> wrote:
Since we're in a new stage of the release, I'll cut one last pre-release tarball.
I would just ask that if a new pre is going to be cut that we get the patch [1] for Default units/viewbox landed in the branch first. I'd like to test things further over the weekend though before I'd be comfortable endorsing it though.
Alright, I'll hold off a bit. Give me the signal when it's a good time to cut a pre.
P.S. We're also going to need to do some marketing work to publicise the release, and I'm thinking we should establish a formal marketing team. I'll try to organize something soon; if you're interested in joining early, or have ideas to consider in the meantime, please shoot me an email.
I think so too. Obviously I'll be interested in trying to help get this going as well.
Thanks!
Bryce
On Thu, Nov 20, 2014 at 12:18:42AM -0800, Bryce Harrington wrote:
- Feature Freeze √ Stable Branch is forked from Mainline √ Regular development resumes on Mainline. √ Avoid major refactorings on Mainline. √ Only bug fixes committed to Stable Branch. √ Bug fixes are cherrypicked from Mainline. √ Inkscape must pass 'make distcheck' String Freeze √ No further string changes allowed on Stable Branch. √ Finalize tutorials to be shipped with release √ Finalize other docs included in the release √ Finalize about screen √ Finalize Release Notes except Known Issues √ Translators work on translations. √ Recruit Release Wardens for Hard Freeze
Here's where we're at:
5. Hard freeze. √ Only Release Wardens can commit to Stable Branch Cherrypick bug fixes from Mainline to Stable Complete any late work under advisement of Wardens √ Focus on release-critical bug fixing. √ Finalize all extensions √ Finalize codebase translations Finalize Known Issues section of Release Notes √ Finalize packaging scripts √ Post additional inkscape-0.91-pre*.tar.gz releases
Josh can you report on where we are with the last three items, or are we ready to move on to the final release? I'd love to get the final release tarball packaged this weekend.
Bryce
Inkscape has completed Feature Freeze and String Freeze, and is now moving to Hard Freeze.
Translators, thanks for your efforts. If there are any late translations please coordinate with Jazzynico, and submit them to him for committing. We're down to the wire though so don't delay!
Developers, at this point only Josh and I should be committing to the tree. We'll accept patches if they're either a) obviously safe and a useful fix, or b) more complex but fix a particularly severe bug. In either case, please make sure the fix is already applied to the 0.92 branch, and then send Josh and I a backported patch ready to be landed on 0.91.
Josh will follow up with our evaluation of blocker bugs. Things actually look to be in fairly good shape. If anyone has a bug they want to raise as a blocker, now's the time to do it!
Since we're in a new stage of the release, I'll cut one last pre-release tarball.
Bryce
P.S. We're also going to need to do some marketing work to publicise the release, and I'm thinking we should establish a formal marketing team. I'll try to organize something soon; if you're interested in joining early, or have ideas to consider in the meantime, please shoot me an email.
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, Jan 24, 2015 at 11:40:41AM -0800, Bryce Harrington wrote:
On Thu, Nov 20, 2014 at 12:18:42AM -0800, Bryce Harrington wrote:
- Feature Freeze √ Stable Branch is forked from Mainline √ Regular development resumes on Mainline. √ Avoid major refactorings on Mainline. √ Only bug fixes committed to Stable Branch. √ Bug fixes are cherrypicked from Mainline. √ Inkscape must pass 'make distcheck' String Freeze √ No further string changes allowed on Stable Branch. √ Finalize tutorials to be shipped with release √ Finalize other docs included in the release √ Finalize about screen √ Finalize Release Notes except Known Issues √ Translators work on translations. √ Recruit Release Wardens for Hard Freeze
Here's where we're at:
- Hard freeze. √ Only Release Wardens can commit to Stable Branch Cherrypick bug fixes from Mainline to Stable Complete any late work under advisement of Wardens √ Focus on release-critical bug fixing. √ Finalize all extensions √ Finalize codebase translations Finalize Known Issues section of Release Notes √ Finalize packaging scripts √ Post additional inkscape-0.91-pre*.tar.gz releases
Josh can you report on where we are with the last three items, or are we ready to move on to the final release? I'd love to get the final release tarball packaged this weekend.
(Offlist Josh mentioned we're waiting on a couple items but may be ready to go Sunday night.)
Bryce
Inkscape has completed Feature Freeze and String Freeze, and is now moving to Hard Freeze.
Translators, thanks for your efforts. If there are any late translations please coordinate with Jazzynico, and submit them to him for committing. We're down to the wire though so don't delay!
Developers, at this point only Josh and I should be committing to the tree. We'll accept patches if they're either a) obviously safe and a useful fix, or b) more complex but fix a particularly severe bug. In either case, please make sure the fix is already applied to the 0.92 branch, and then send Josh and I a backported patch ready to be landed on 0.91.
Josh will follow up with our evaluation of blocker bugs. Things actually look to be in fairly good shape. If anyone has a bug they want to raise as a blocker, now's the time to do it!
Since we're in a new stage of the release, I'll cut one last pre-release tarball.
Bryce
P.S. We're also going to need to do some marketing work to publicise the release, and I'm thinking we should establish a formal marketing team. I'll try to organize something soon; if you're interested in joining early, or have ideas to consider in the meantime, please shoot me an email.
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (8)
-
Bryce Harrington -
Johan Engelen -
Josh Andler -
Masato Hashimoto -
Nicolas Dufour -
su_v -
Tavmjong Bah -
Vinícius dos Santos Oliveira