Fwd: [Bug 238796] Re: Display mode toggle needs update to all 3 modes
Again, pls. review and commit the patch. Thx, Adib.
Is there any new TODO list for the 0.47 release?
---------- Forwarded message ---------- From: theAdib <theAdib@...1439...> Date: Sun, Sep 13, 2009 at 2:25 AM Subject: [Bug 238796] Re: Display mode toggle needs update to all 3 modes To: theAdib@...1439...
attached patch cycles through all 3 display modes normal->without filters->outline pls test.
HTH, Adib.
** Changed in: inkscape Status: Confirmed => In Progress
** Changed in: inkscape Assignee: MenTaLguY (mental) => theAdib (theadib)
** Attachment added: "BUG238796_display_toggle.patch" http://launchpadlibrarian.net/31734073/BUG238796_display_toggle.patch
-- Display mode toggle needs update to all 3 modes https://bugs.launchpad.net/bugs/238796 You received this bug notification because you are a bug assignee.
Thanks to Adib's question... Let's start the discussion.
It appears that there are still a few packaging issues to be worked out. For one, the win32 libs still haven't been officially updated (outside of Chris Morgan's personal copy) that I am aware of. Status update on this please? Also, I keep seeing more OSX packaging stuff trickling in (thankfully).
I had also seen some issues relating to the copied vectors being pasted as bitmap which had a proposed patch (don't recall offhand if it was committed yet, will look at more in depth in the next couple days).
JonCruz, PLEASE (pretty please with a cherry on top) ifdef out the "auto" swatch stuff already since a proper fix is really not looking likely for this release...
The couple of patches Adib submitted just need to be reviewed and committed (which I'm confident there will be no problem).
What else folks? These items are a *minimum* before pre3 can be branched... and pre3 needs to be it, then the release.
Cheers, Josh
On Sun, Sep 13, 2009 at 2:48 PM, Joshua A. Andler <scislac@...400...> wrote:
It appears that there are still a few packaging issues to be worked out. For one, the win32 libs still haven't been officially updated (outside of Chris Morgan's personal copy) that I am aware of. Status update on this please?
My latest build was just using the latest devlibs. I haven't updated anything which isn't in the publicly available devlibs.
I think that I've now sorted out all the packaging issues for the Win32 installer, but we'll need pre3 to really test them.
-- Chris Morgan <chris.morganiser@...400...>
I'm good at making two things: mistakes and enemies.
On 09/13/2009 06:48 AM, Joshua A. Andler wrote:
I had also seen some issues relating to the copied vectors being pasted as bitmap which had a proposed patch (don't recall offhand if it was committed yet, will look at more in depth in the next couple days).
See https://bugs.launchpad.net/inkscape/+bug/296778. Patch is ready but needs testing.
And the patch I sent to this list on september 6th is also still to be reviewed by the release wardens.
Diederik
On 9/13/09, Diederik en Rezi <mail@...1689...> wrote:
On 09/13/2009 06:48 AM, Joshua A. Andler wrote:
I had also seen some issues relating to the copied vectors being pasted as bitmap which had a proposed patch (don't recall offhand if it was committed yet, will look at more in depth in the next couple days).
See https://bugs.launchpad.net/inkscape/+bug/296778. Patch is ready but needs testing.
I tested it as much as I could on Windows - right now my Linux computer is broken so I cannot test there; if someone can test copy/paste on Linux with this patch, it will be good to commit.
On Sun, 2009-09-13 at 23:32 -0400, bulia byak wrote:
On 9/13/09, Diederik en Rezi <mail@...1689...> wrote:
On 09/13/2009 06:48 AM, Joshua A. Andler wrote:
I had also seen some issues relating to the copied vectors being pasted as bitmap which had a proposed patch (don't recall offhand if it was committed yet, will look at more in depth in the next couple days).
See https://bugs.launchpad.net/inkscape/+bug/296778. Patch is ready but needs testing.
I tested it as much as I could on Windows - right now my Linux computer is broken so I cannot test there; if someone can test copy/paste on Linux with this patch, it will be good to commit.
I could not reproduce the issue on linux to begin with (my gtkmm is 2.17.11)... however, I applied the patch and saw no difference in my work or testing, so it appears to be safe. I will go ahead and commit it.
Cheers, Josh
On Sat, 2009-09-12 at 21:48 -0700, Joshua A. Andler wrote:
Thanks to Adib's question... Let's start the discussion.
What else folks? These items are a *minimum* before pre3 can be branched... and pre3 needs to be it, then the release.
1. Fix to bug 382313 Image Filter broken for extrernal images
The problem has been localized to matrix inversion in lib2geom. Waiting for a patch from lib2geom experts. I have a quick and dirty patch if none is forthcoming.
2. Fix to bug 167472 save as dialogue, duplicate 'Compressed Inkscape SVG' entry
~suv notes that that both svgz_output.inx and svgz_input.inx in share/extensions are redundant. They have been replaced by internal extensions (src/extensions/internal/svgz.h and svgz.cpp). He's tested their removal on OS X Leopard.
3. Fix or disable export to POVray.
Output is broken in 0.47. Bob Jamison was going to look into fixing it. I just sent a query to him about this. If it isn't fixed it should be disabled.
4. Optimized SVG output export failing.
It seems that the file yocto_css.py is not being installed (missing entry in share/extensions/Makefile?).
Tav
On Sun, 2009-09-13 at 10:59 +0200, Tavmjong Bah wrote:
- Fix to bug 167472 save as dialogue, duplicate 'Compressed Inkscape
SVG' entry
~suv notes that that both svgz_output.inx and svgz_input.inx in share/extensions are redundant. They have been replaced by internal extensions (src/extensions/internal/svgz.h and svgz.cpp). He's tested their removal on OS X Leopard.
I thought there were some people having issues with the internal ones. If that's not the case I believe they should be removed. Can someone test these two across the various platforms so that we know which is best?
Optimized SVG output export failing.
It seems that the file yocto_css.py is not being installed (missing
entry in share/extensions/Makefile?).
Added to the Makefile.am.
--Ted
On 14/9/09 08:05, Ted Gould wrote:
On Sun, 2009-09-13 at 10:59 +0200, Tavmjong Bah wrote:
- Fix to bug 167472 save as dialogue, duplicate 'Compressed Inkscape
SVG' entry
~suv notes that that both svgz_output.inx and svgz_input.inx in share/extensions are redundant. They have been replaced by internal extensions (src/extensions/internal/svgz.h and svgz.cpp). He's tested their removal on OS X Leopard.
I thought there were some people having issues with the internal ones. If that's not the case I believe they should be removed. Can someone test these two across the various platforms so that we know which is best?
Both svgz_input.inx and svgz_output.inx in its current form fail (confirmed for svgz_output.inx on Ubuntu, XP and OS X in bug #167472) with the error
Can't Spawn!!! spawn returns: 8
i.e. support for <command reldir="path">somecommand -with -arguments</command> seems broken or removed in current SVN builds
~suv (aka V aka Véronique ;-)
On Mon, 2009-09-14 at 10:43 +0200, ~suv wrote:
On 14/9/09 08:05, Ted Gould wrote:
I thought there were some people having issues with the internal ones. If that's not the case I believe they should be removed. Can someone test these two across the various platforms so that we know which is best?
Both svgz_input.inx and svgz_output.inx in its current form fail (confirmed for svgz_output.inx on Ubuntu, XP and OS X in bug #167472) with the error
Can't Spawn!!! spawn returns: 8
Sounds good. Removed.
i.e. support for <command reldir="path">somecommand -with -arguments</command> seems broken or removed in current SVN builds
Ah, that would have been broken in 0.47 as well. Probably not fixable at this point for 0.48, but is there a bug filed with that description?
--Ted
On 15/9/09 03:35, Ted Gould wrote:
On Mon, 2009-09-14 at 10:43 +0200, ~suv wrote:
Both svgz_input.inx and svgz_output.inx in its current form fail (confirmed for svgz_output.inx on Ubuntu, XP and OS X in bug #167472) with the error
Can't Spawn!!! spawn returns: 8
Sounds good. Removed.
thanks
i.e. support for <command reldir="path">somecommand -with -arguments</command> seems broken or removed in current SVN builds
Ah, that would have been broken in 0.47 as well. Probably not fixable at this point for 0.48, but is there a bug filed with that description?
(you mean not fixable for 0.47?)
so far it's only in the comments of bug #167472 “save as dialogue, duplicate 'Compressed Inkscape SVG' entry” https://bugs.launchpad.net/inkscape/+bug/167472
Since 'ai_output.inx' has been removed these were the only extensions left that directly called a command with parameters:
On 7/7/09 17:02, ~suv wrote:
LeWitt:extensions suv$ grep reldir *.inx|grep -v extensions ai_output.inx: <command reldir="path">gs -q -dNODISPLAY -dSAFER ps2ai.ps</command> svgz_input.inx: <command reldir="path">gzip -cd</command> svgz_input.inx: <check reldir="path">gzip</check> svgz_output.inx: <command reldir="path">gzip -c</command> LeWitt:extensions suv$
~suv
On 15/9/09 03:35, Ted Gould wrote:
On Mon, 2009-09-14 at 10:43 +0200, ~suv wrote:
i.e. support for <command reldir="path">somecommand -with -arguments</command> seems broken or removed in current SVN builds
Ah, that would have been broken in 0.47 as well. Probably not fixable at this point for 0.48, but is there a bug filed with that description?
new: Bug #431290 https://bugs.launchpad.net/inkscape/+bug/431290 “[inx] <command reldir="path">somecommand -with -arguments</command> fails”
Joshua A. Andler wrote:
What else folks? These items are a *minimum* before pre3 can be branched... and pre3 needs to be it, then the release.
from previous list:
PDF export: text to path still broken Bug #388257 “Inkscape 0.47Pre: PDF/PS Export 'Text to Paths' gives inconsistent results” https://bugs.launchpad.net/inkscape/+bug/388257
Although there exists a workaround (convert text to path _before_ exporting, not with the option in the export dialog) it is important IMHO as PDF seems to be one of the most used output/exchange formats.
Bug #399604 “'malloc: *** error' after changing numeric precision to 1 or 2” https://bugs.launchpad.net/inkscape/+bug/399604
Could you at least disable the GUI part in the preferences for this setting? On OS X the Inkscape interface is completely unresponsive after a restart, on XP it crashes immediately when restarted after changing the setting, no confirmation on linux so far. Inkscape can only be run again after either dumping 'preferences.xml' or manually editing it and resetting the precision value to 8. (tested again with Inkscape r22200 on OS X 10.5.8, bug still present)
~suv
On 9/13/09, ~suv <suv-sf@...58...> wrote:
Bug #399604 “'malloc: *** error' after changing numeric precision to 1 or 2” https://bugs.launchpad.net/inkscape/+bug/399604
Could you at least disable the GUI part in the preferences for this setting?
Done in 22232. I contacted Jasper about this bug, since the error seems to be in his code, but got no reply so far...
On 14/9/09 16:31, bulia byak wrote:
On 9/13/09, ~suv <suv-sf@...58...> wrote:
Bug #399604 “'malloc: *** error' after changing numeric precision to 1 or 2” https://bugs.launchpad.net/inkscape/+bug/399604
Could you at least disable the GUI part in the preferences for this setting?
Done in 22232. I contacted Jasper about this bug, since the error seems to be in his code, but got no reply so far...
Thank you for looking into this bug - and my apologies for the unfortunate choice of words in my above comment!
I didn't even think of just raising the lower limit for the spinbutton... but it is an elegant workaround - better than disabling the numeric precision setting in the GUI as a whole, until the bug is fixed! Numeric precision >= 3 works with Inkscape r22221 on OS X, no crash or hang.
~suv
On Sun, Sep 13, 2009 at 8:48 AM, Joshua A. Andler wrote:
What else folks?
1. Broken SVG tutorials: for some reasion spacing between paragraphs is wrong
2. Eraser tool doesn't work on objects with SVG Filters reliably. For me it doesn't erase parts of filtered objects at all. Joshua reports that for him it works if he changes brush radius.
3. SVG Filters i18n is broken. I'm about to submit a bug report, but here goes: open Filter Editor, then start adding and removing filters to an object and keep an eye on the list of filters in the editor: it will jump from filter's ID to filter's name (already a bug), but never ever will display localized name of a filter. This has been so since the very beginning, I'm afraid.
Alexandre
On Mon, 2009-09-14 at 10:10 +0400, Alexandre Prokoudine wrote:
- SVG Filters i18n is broken. I'm about to submit a bug report, but
here goes: open Filter Editor, then start adding and removing filters to an object and keep an eye on the list of filters in the editor: it will jump from filter's ID to filter's name (already a bug), but never ever will display localized name of a filter. This has been so since the very beginning, I'm afraid.
I'm not sure where the bug is here. See, the filters are putting the name into the XML file, and the editor is just using that name. But, theoretically a user could change that name, and we wouldn't want to localize it if a user changed it to something that happened to be translated.
It seems like when we use a filter, we should be putting the translated name into the XML file. Does that make sense to everyone?
--Ted
On Tue, Sep 15, 2009 at 5:23 AM, Ted Gould wrote:
On Mon, 2009-09-14 at 10:10 +0400, Alexandre Prokoudine wrote:
- SVG Filters i18n is broken. I'm about to submit a bug report, but
here goes: open Filter Editor, then start adding and removing filters to an object and keep an eye on the list of filters in the editor: it will jump from filter's ID to filter's name (already a bug), but never ever will display localized name of a filter. This has been so since the very beginning, I'm afraid.
I'm not sure where the bug is here.
Well, I'm, sure that the bug is in two places :)
1. Filter Editor should never ever expose filter ID and then hide after switching object to a different filter, which it does right now.
2. If we can't make a filter's name show up as localized everywhere, we shouldn't make it localizable anywhere.
Alexandre
On Wed, 2009-09-16 at 11:04 +0400, Alexandre Prokoudine wrote:
On Tue, Sep 15, 2009 at 5:23 AM, Ted Gould wrote:
On Mon, 2009-09-14 at 10:10 +0400, Alexandre Prokoudine wrote:
- SVG Filters i18n is broken. I'm about to submit a bug report, but
here goes: open Filter Editor, then start adding and removing filters to an object and keep an eye on the list of filters in the editor: it will jump from filter's ID to filter's name (already a bug), but never ever will display localized name of a filter. This has been so since the very beginning, I'm afraid.
I'm not sure where the bug is here.
Well, I'm, sure that the bug is in two places :)
- Filter Editor should never ever expose filter ID and then hide
after switching object to a different filter, which it does right now.
Yes.
- If we can't make a filter's name show up as localized everywhere,
we shouldn't make it localizable anywhere.
I guess my question comes down to, is it localized in that case or is it a user setting. For instance, we show localized template names but if I named a file "Letter" it shouldn't be translated in the file dialog. At the point of looking at the filter label in the file, it could very well be something the user has put in. If they called a filter "Snow" then we shouldn't translate it even if we have a translation for "Snow."
--Ted
Hi,
De : Ted Gould <ted@...11...> À : Alexandre Prokoudine <alexandre.prokoudine@...400...>
- If we can't make a filter's name show up as localized everywhere,
we shouldn't make it localizable anywhere.
I guess my question comes down to, is it localized in that case or is it a user setting. For instance, we show localized template names but if I named a file "Letter" it shouldn't be translated in the file dialog. At the point of looking at the filter label in the file, it could very well be something the user has put in. If they called a filter "Snow" then we shouldn't translate it even if we have a translation for "Snow."
The string is already translated in the Filters menus (ok, we probably won't add one manually...) and in the status bar (thanks to your patch). I've attached a patch which localize the filter's name in the editor if you think it should be done. If not, we need to find another way to localize it elsewhere (we could localize the filter's label BEFORE writing it in the SVG code, and thus use a translated label instead of the translation of the English one...).
Regards, -- Nicolas
participants (10)
-
Alexandre Prokoudine -
bulia byak -
Chris Morgan -
Diederik en Rezi -
Joshua A. Andler -
Nicolas Dufour -
Tavmjong Bah -
Ted Gould -
the Adib -
~suv