This is a good build that is close to being a release:
For Mountain Lion
http://rapidshare.com/files/4204947016/Inkscape-r0.48.4-r9943-10.8%2B-x86_64...
For Lion:
http://rapidshare.com/files/3505176415/Inkscape-r0.48.4-r9943-10.7%2B-x86_64...
- the menu should be all working but the "Open Recent" submenu. No matter which item is selected, the top open is always opened. This is a bug between gtk/gtk_recent_menu_manager() and gtk-mac-integration. Needs more analysis, not an easy fix.
- Quit, About and Preferences menu items moved under the app menu.
- python should be fully working now on Lion and Mountain Lion
- uniconvertor/sk1libs installed and fixed
The sk1libs/utilsfs.py line
return ['/']
really should be
return ['/System/Library/Fonts', '/Library/Fonts', os.path.expanduser("~/Library/Fonts")]
- no more noise on the terminal stderr
- bunch of improvements and changes in the build system
Hi Valerio,
Quick feedback on the Lion build : the clipboard doesn't seem to communicate with external programs. It works if copy/pasting from inside of Inkscape RC1 itself.
Tested bitmaps or vectors, from inkscape X11 or other apps. A previously "populated" clipboard seems to be emptied when trying to copy from RC1.
Victor
Le 15/01/13 18:17, Valerio Aimale a écrit :
This is a good build that is close to being a release:
For Mountain Lion
http://rapidshare.com/files/4204947016/Inkscape-r0.48.4-r9943-10.8%2B-x86_64...
For Lion:
http://rapidshare.com/files/3505176415/Inkscape-r0.48.4-r9943-10.7%2B-x86_64...
- the menu should be all working but the "Open Recent" submenu. No
matter which item is selected, the top open is always opened. This is a bug between gtk/gtk_recent_menu_manager() and gtk-mac-integration. Needs more analysis, not an easy fix.
Quit, About and Preferences menu items moved under the app menu.
python should be fully working now on Lion and Mountain Lion
uniconvertor/sk1libs installed and fixed
The sk1libs/utilsfs.py line
return ['/']
really should be
return ['/System/Library/Fonts', '/Library/Fonts', os.path.expanduser("~/Library/Fonts")]
no more noise on the terminal stderr
bunch of improvements and changes in the build system
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
[ resending, this time to the list ]
Long-standing issue (never worked reliable with Quartz-based builds): - Bug #546934 “Mac OS X AQUA: clipboard doesnt work” https://bugs.launchpad.net/inkscape/+bug/546934
Oddly, copy&paste between GIMP 2.8.2 (also Quartz-based) and Inkscape.app works ok, and AFAICT GIMP 2.8.2 can also exchange data via clipboard with native OS X applications (I have only used Preview.app for quick tests right now).
On 16/01/2013 08:34, Victor / tokiop wrote:
Hi Valerio,
Quick feedback on the Lion build : the clipboard doesn't seem to communicate with external programs. It works if copy/pasting from inside of Inkscape RC1 itself.
Tested bitmaps or vectors, from inkscape X11 or other apps. A previously "populated" clipboard seems to be emptied when trying to copy from RC1.
Victor
Le 15/01/13 18:17, Valerio Aimale a écrit :
This is a good build that is close to being a release:
For Mountain Lion
http://rapidshare.com/files/4204947016/Inkscape-r0.48.4-r9943-10.8%2B-x86_64...
For Lion:
http://rapidshare.com/files/3505176415/Inkscape-r0.48.4-r9943-10.7%2B-x86_64...
- the menu should be all working but the "Open Recent" submenu. No
matter which item is selected, the top open is always opened. This is a bug between gtk/gtk_recent_menu_manager() and gtk-mac-integration. Needs more analysis, not an easy fix.
Quit, About and Preferences menu items moved under the app menu.
python should be fully working now on Lion and Mountain Lion
uniconvertor/sk1libs installed and fixed
The sk1libs/utilsfs.py line
return ['/']
really should be
return ['/System/Library/Fonts', '/Library/Fonts', os.path.expanduser("~/Library/Fonts")]
no more noise on the terminal stderr
bunch of improvements and changes in the build system
On 15/01/2013 18:17, Valerio Aimale wrote:
This is a good build that is close to being a release:
See comments below
For Mountain Lion
http://rapidshare.com/files/4204947016/Inkscape-r0.48.4-r9943-10.8%2B-x86_64...
For Lion:
http://rapidshare.com/files/3505176415/Inkscape-r0.48.4-r9943-10.7%2B-x86_64...
- the menu should be all working but the "Open Recent" submenu. No
matter which item is selected, the top open is always opened. This is a bug between gtk/gtk_recent_menu_manager() and gtk-mac-integration. Needs more analysis, not an easy fix.
Identical issues occurring with Inkscape and Unity's global menu bar: - 'File > Open Recent' always opens top-most entry - No keyboard shortcuts for menu items - No hints for menu items in the status bar - ... (see my earlier replies for related bug report numbers)
Are these indeed issues which need to be fixed in platform-/distro-/desktop- and/or backend-specific patches, or is it reasonable to assume that they are rooted in the same structure of Inkscape's current code base, and might have a better chance to get addressed in a joint effort if not being tagged with 'osx only'?
- Quit, About and Preferences menu items moved under the app menu.
For the preferences dialog in the application menu, users are likely to expect the typically used shortcut 'Cmd+,' to also work with "native" Inkscape. AFAIU this would need special attention similar to the conflict with the quickzoom feature for 'Cmd+Q' - ',' is hardcoded in the select context to scale the current selection and seems to ignore whether 'Meta' is pressed or not.
- Modifiers, and keyboard shortcuts
Likely not in the focus of 'RC1': AFAICT the latest packages have been compiled with the patch to swap the modifier keys (Ctrl <-> Cmd) for verb-based shortcuts, but at least in the last two the bundled keymap file was not replaced, nor 'mac.xml' included. Out-of-the-box, the RC1 app only supports 'Cmd' as modifier for quit ('Cmd+Q') from the application menu - to figure out the modifier for other keyboard shortcuts, the user has to try what works (the keyboard shortcuts are not displayed in the menu items of the osx menubar, and if 'Meta' is used in the keymap file, the modifer symbol is omitted in tooltips e.g. of toolbar icons, thus no longer a reliable lookup source either).
How could the change of (some) modifiers in shortcuts be communicated to the users of this package? There is no place within the application they could look up the current effective shortcut keys (or dominant modifier), and we don't maintain platform-specific 'mouse and keyboard reference' files at inkscape.org (linked via 'Help' menu entry).
- python should be fully working now on Lion and Mountain Lion
Confirmed.
- uniconvertor/sk1libs installed and fixed
The sk1libs/utilsfs.py line
return ['/']
really should be
return ['/System/Library/Fonts', '/Library/Fonts', os.path.expanduser("~/Library/Fonts")]
Works for all but CorelDraw files (e.g. CDR) - even very simple CDR files I had available for testing (no text, no embedded data or images, only paths/curves) failed to open with the UniConvertor module as currently included in the app bundle:
UniConvertor failed:
Traceback (most recent call last): File "/Users/su_v/Applications/TST/Inkscape-0.48.4-RC1.app/Contents/Resources/python/site-packages/sk1libs/filters/import/cdrloader.py", line 837, in Load self.import_curves() File "/Users/su_v/Applications/TST/Inkscape-0.48.4-RC1.app/Contents/Resources/python/site-packages/sk1libs/filters/import/cdrloader.py", line 880, in import_curves self.begin_page("",layout) AttributeError: CDRLoader instance has no attribute 'begin_page' Traceback (most recent call last): File "<string>", line 1, in <module> File "/Users/su_v/Applications/TST/Inkscape-0.48.4-RC1.app/Contents/Resources/python/site-packages/uniconvertor/__init__.py", line 95, in uniconv_run doc = load.load_drawing(input_file) File "/Users/su_v/Applications/TST/Inkscape-0.48.4-RC1.app/Contents/Resources/python/site-packages/uniconvertor/app/io/load.py", line 377, in load_drawing return load_drawing_from_file(file, filename) File "/Users/su_v/Applications/TST/Inkscape-0.48.4-RC1.app/Contents/Resources/python/site-packages/uniconvertor/app/io/load.py", line 354, in load_drawing_from_file raise SketchLoadError(_("Parsing error: ")+ str(value)) app.events.skexceptions.SketchLoadError: Parsing error: Parsing error: CDRLoader instance has no attribute 'begin_page'
The same CDR file(s) open ok with Inkscape & UniConvertor 1.1.4 on Ubuntu 12.10 (64bit, VM, Python 2.7), and with Inkscape & a rather dated tweaked installation of UniConvertor 1.1.5 for Python 2.6 on my older laptop with Mac OS X 10.5.8 (i386): Sample file from the bug tracker: https://bugs.launchpad.net/inkscape/+bug/442010/+attachment/771958/+files/Frenchcurve.cdr
I had no test files at hand for the other CorelDraw input file formats (CCX, CDT, CGM, CMX).
The remaining input formats based on UniConvertor (AI 8.0 and older, PLT, SK1, WMF) seem to work, as do the output formats (PLT, SK1, WMF) - tested and confirmed by round-trip editing a minimal Inkscape document with Inkscape.app (SVG -> PLT|SK1|WMF -> SVG).
- WRT Crash on exit, or random dialogs from output extensions:
Bug #1046068 is not fixed by including a (semi- or fully-functional) UniConvertor 1.1.5 module in the app bundle, and while with the latest RC1 package Inkscape 0.48.4 doesn't prompt with annoying error dialogs from UniConvertor-based output extensions anymore, it leaves a file with a copy of the clipboard content in $TMPDIR, each time the app is exited with a non-empty clipboard, and has a noticeable delay on exit if the clipboard was not empty (since apparently the clipboard content is attempted to be exported to all supported clipboard targets based on the internal list of output extensions).
The "shortest path to annoyance removal" postpones a fix, and Inkscape is likely to face the same issue again in a few weeks or months, as soon as there are beta releases or release candidates of 0.49 available (trunk currently crashes right after creating a zero-size temp file in $TMPDIR if there is a at least one script-based output extension loaded either from the shared extensions directory or from the user Inkscape profile directory "$XDG_CONFIG_HOME/inkscape/extensions")
a) Assume a user somehow has managed to install 'gimp' (or a wrapper script to GIMP.app) into one of the paths in the app bundle's $PATH variable (add a fake 'gimp' shell script into 'Contents/Resources/bin' to test it): there's yet another dialog now appearing on quit from the GIMP XCF output file type (one or more layers are required, the clipboard content however is saved without layer information). Or the user has some additional extensions installed in '~/.config/inkscape/extensions' - those may also trigger the same issue (depending on the custom output extension).
b) Upstream bugs: including the UniConvertor module doesn't prevent related crashes which may get triggered with Inkscape 0.48.4 on exit, too, after having used the system clipboard to copy and paste e.g. text in Inkscape.app (e.g from GUI widgets containing text or digits) to native osx apps:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 000000000000000000 0 + 0 1 libgtk-quartz-2.0.0.dylib 0x000000010b2642ac gtk_clipboard_store + 268 2 libgtk-quartz-2.0.0.dylib 0x000000010b26432f _gtk_clipboard_store_all + 63 3 libgtk-quartz-2.0.0.dylib 0x000000010b135bc9 gtk_main + 537 4 Inkscape 0x00000001099aac24 sp_main_gui(int, char const**) + 1812 5 Inkscape 0x00000001099aafe1 main + 337 6 Inkscape 0x00000001099a8184 start + 52
(above crash occurred on exit with the RC1 package after copy&pasting the error messages from failed CDR import attempts into native OS X application (MacVim, Thunderbird), working in those other applications for a while before returning to Inkscape and closing it. Similar steps to reproduce the crash in GTK+/Quartz 2.24 are described e.g. in https://bugzilla.gnome.org/show_bug.cgi?id=626499#c18)
- no more noise on the terminal stderr
From the POV of helping with bug triage and user support, I'm not really
happy with the chosen "fix" either (sending _all_ stderr messages to /dev/null), but I do understand that other options are out-of-reach if the goal is to release a Quartz-based package of 0.48.4 ASAP.
- bunch of improvements and changes in the build system
- Gdk-pixbuf: SVG is still missing from gdk-pixbuf loaders - this also prevents rendering preview images in the OpenClipart import dialog. Side-note: while it is a known bug that import from OpenClipart crashes when used a second time within the same Inkscape session on OS X, it is currently (*) still working fine at least for one import - assuming one can browse the search results and make a choice based on the preview image. (*) The refactored 'Import Clipart' in trunk does no longer work on OS X
- Fonts: As mentioned earlier, with recent pango version there doesn't seem to be a compelling reason anymore not to add '/System/Library/Fonts' back to the font directory list in 'Resources/etc/fonts/fonts.conf' - it will provide a functional version of Helvetica, as well as e.g. Lucida Grande to the default fonts available in Inkscape.app.
- Since you seem to be a real wizard with regard to creating osx app packages: How difficult do you think would it be to include a minimal ghostscript installation in the application bundle, with 'gs' itself in 'Resources/bin'? As far as I know this is still a big obstacle for many Mac users who want to open / edit PostScript files in Inkscape.
I'm looking forward to updated patches (or a branch) with the changes for RC1 - it makes testing a binary app easier (at least for me) if one can look up what has actually changed. Probably i forgot some things I wanted to mention, but based on the amount of time I already spent with rewriting and correcting this reply, I better send it now, and follow-up later on...
On 16/01/2013 16:56, ~suv wrote:
On 15/01/2013 18:17, Valerio Aimale wrote:
- bunch of improvements and changes in the build system
- Since you seem to be a real wizard with regard to creating osx app
packages: How difficult do you think would it be to include a minimal ghostscript installation in the application bundle, with 'gs' itself in 'Resources/bin'? As far as I know this is still a big obstacle for many Mac users who want to open / edit PostScript files in Inkscape.
Sorry, correcting an obvious mistake: the dependency for PS/EPS input is of course 'ps2pdf' not 'gs' itself...
On 1/16/13 10:36 AM, ~suv wrote:
On 16/01/2013 16:56, ~suv wrote:
On 15/01/2013 18:17, Valerio Aimale wrote:
- bunch of improvements and changes in the build system
- Since you seem to be a real wizard with regard to creating osx app
packages: How difficult do you think would it be to include a minimal ghostscript installation in the application bundle, with 'gs' itself in 'Resources/bin'? As far as I know this is still a big obstacle for many Mac users who want to open / edit PostScript files in Inkscape.
Sorry, correcting an obvious mistake: the dependency for PS/EPS input is of course 'ps2pdf' not 'gs' itself...
Thanks, I've also become a gtk2 wizard to integrate inkscape into Mac OS X ... dunno if you noticed .......... :-)
There are several scripts with the name psXXpdf
ps2pdf is a script that is part of gs. You were correct, if we want to bundle ps2pdf, we would carry over gs as well.
pstopdf part of a (name your favorite) texmf distribution (I think it's a ruby script)
pstopdf, installed in Mac OSX as '/usr/bin/pstopdf' is proprietary, possible closed source, Apple software.
To make things interesting, I will thrown in the hat pstoedit. In my TeX/LateX/METAFONT/METAPOST heydays (those were good days) I figured that pstoedit was the best in converting ps/eps to editable format. Far superior to gs and ruby script. Maybe we could write an svg exporter/backend for it? the author of pstoedit (all opensource) has a shareware svg exporter
Or would /usr/bin/pstopdf be good enough?
V.
On 16/01/2013 21:37, Valerio Aimale wrote:
On 1/16/13 10:36 AM, ~suv wrote:
On 16/01/2013 16:56, ~suv wrote:
On 15/01/2013 18:17, Valerio Aimale wrote:
- bunch of improvements and changes in the build system
- Since you seem to be a real wizard with regard to creating osx app
packages: How difficult do you think would it be to include a minimal ghostscript installation in the application bundle, with 'gs' itself in 'Resources/bin'? As far as I know this is still a big obstacle for many Mac users who want to open / edit PostScript files in Inkscape.
Sorry, correcting an obvious mistake: the dependency for PS/EPS input is of course 'ps2pdf' not 'gs' itself...
Thanks, I've also become a gtk2 wizard to integrate inkscape into Mac OS X ...
Indeed :)
dunno if you noticed .......... :-)
Yes, I did. Sorry if I missed to adequately express the dept of gratitude the Inkscape project and all Inkscape users on Macs out there owe you! Your efforts to push out a renewed OS X package is highly appreciated and certainly eagerly awaited - even if the number of testers providing feedback here on the list has been relatively small.
There are several scripts with the name psXXpdf
ps2pdf is a script that is part of gs. You were correct, if we want to bundle ps2pdf, we would carry over gs as well.
That's the one that is required by Inkscape: ps2pdf from Ghostscript (See also http://tavmjong.free.fr/INKSCAPE/MANUAL/html/File-Import.html)
pstopdf part of a (name your favorite) texmf distribution (I think it's a ruby script)
pstopdf, installed in Mac OSX as '/usr/bin/pstopdf' is proprietary, possible closed source, Apple software.
To make things interesting, I will thrown in the hat pstoedit. In my TeX/LateX/METAFONT/METAPOST heydays (those were good days) I figured that pstoedit was the best in converting ps/eps to editable format. Far superior to gs and ruby script. Maybe we could write an svg exporter/backend for it? the author of pstoedit (all opensource) has a shareware svg exporter
Or would /usr/bin/pstopdf be good enough?
In my opinion it would be best to use the same helper applications in all ports of Inkscape (i.e. to _not_ modify bundled default input extension scripts specifically for the Mac OS X package), so that the results are -within limits- predictably the same whether one imports other supported file formats on Linux, OS X or Windows. For PostScript support, this means that Inkscape currently relies on ps2pdf from Ghostscript (on all platforms).
In the few rather random tests I had done [1], the results of using ps2pdf or Apple's pstopdf as helper application tended to vary in structure (always) as well as in appearance (sometimes), depending on the content of the original PS/EPS file. Occasionally pstoedit may fail where ps2pdf from Ghostscript still produces a readable PDF file, but I do recall instances where the opposite was true.
The Inkscape Windows installer package currently relies on PostScript being installed externally, which - based on the number of recurring questions about it - poses for many Windows users similar obstacles as for Mac users right now (despite the fact that for Windows there are at least up-to-date Ghostscript installer packages available for download from ghostscript.com, unlike for Mac OS X).
----- [1] If interested in doing more extensive comparisons, here are two (work-in-progress) custom PostScript input extensions I recently started to work on: http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-extensions/files/head:/postscript-input/ They are based on those included with inkscape, use the identical settings of the official extensions on first tab, and have experimental options based on 'gs' on the next two tabs. On the 'Unsupported' tab, one can use 'pstoedit' instead (on OS X).
(Please ignore the terrible layout of the extension dialog if used with Inkscape 0.48.x - it is developed with current trunk which has a more compact layout of the widgets for INX-based dialogs.)
On 1/16/13 8:56 AM, ~suv wrote:
Identical issues occurring with Inkscape and Unity's global menu bar:
- 'File > Open Recent' always opens top-most entry
This one is solved: the problem stems from the fact that both osx-integration and Ubuntu unity build physical menubars with menus that proxy mouse/keyboard events to the real hidden menu. When they emit the menu event by calling
gtk_menu_item_activate ((GtkMenuItem*) menuitem);
which cascades the event the the menuitem widget that is connected to the application, nobody has yet set the "active" menuitem property in that particular menu. When gtk menubars are used directly, the active item is set immediately after the GDK event is processed. In this case, it never happens.
One we know the problem, it is an easy fix that can be put wither in gtkmacintegration or directly in gtk2. I've put it in gtkmacintegration for convenience for now.
Valerio
On 2013-01-17 16:58 +0200, Valerio Aimale wrote:
On 1/16/13 8:56 AM, ~suv wrote:
Identical issues occurring with Inkscape and Unity's global menu bar:
- 'File > Open Recent' always opens top-most entry
This one is solved: the problem stems from the fact that both osx-integration and Ubuntu unity build physical menubars with menus that proxy mouse/keyboard events to the real hidden menu. When they emit the menu event by calling
gtk_menu_item_activate ((GtkMenuItem*) menuitem);
which cascades the event the the menuitem widget that is connected to the application, nobody has yet set the "active" menuitem property in that particular menu. When gtk menubars are used directly, the active item is set immediately after the GDK event is processed. In this case, it never happens.
One we know the problem, it is an easy fix that can be put wither in gtkmacintegration or directly in gtk2. I've put it in gtkmacintegration for convenience for now.
Likely fixed upstream now (gtk-mac-integration git master):
Bug 703675 – GtkRecentChooserMenu: gtk_recent_chooser_get_current_uri always returns first item in list: https://bugzilla.gnome.org/show_bug.cgi?id=703675
Commit: https://git.gnome.org/browse/gtk-mac-integration/commit/?id=24ade60fd771ee2424299320424d04ad009aaeb1
(Note: I have no idea how the upstream fix compares to Valerio's solution used for the Inkscape 0.48.4 RC packages)
On 1/16/13 8:56 AM, ~suv wrote:
- No keyboard shortcuts for menu items - No hints for menu items in
the status bar - ... (see my earlier replies for related bug report numbers) Are these indeed issues which need to be fixed in platform-/distro-/desktop- and/or backend-specific patches, or is it reasonable to assume that they are rooted in the same structure of Inkscape's current code base, and might have a better chance to get addressed in a joint effort if not being tagged with 'osx only'?
This is due to the fact that Inkscpae does not use GtkAccel in menuitems' GtkLabels. Without adding that logic, it won;t happen. Are menu accelerators symbols a show stopper for an OSX 0.48.4?
- Quit, About and Preferences menu items moved under the app menu.
For the preferences dialog in the application menu, users are likely to expect the typically used shortcut 'Cmd+,' to also work with "native" Inkscape. AFAIU this would need special attention similar to the conflict with the quickzoom feature for 'Cmd+Q' - ',' is hardcoded in the select context to scale the current selection and seems to ignore whether 'Meta' is pressed or not.
Same as before GtkAccel has to be implemented.
Works for all but CorelDraw files (e.g. CDR) - even very simple CDR files I had available for testing (no text, no embedded data or images, only paths/curves) failed to open with the UniConvertor module as currently included in the app bundle:
UniConvertor failed:
Traceback (most recent call last): File "/Users/su_v/Applications/TST/Inkscape-0.48.4-RC1.app/Contents/Resources/python/site-packages/sk1libs/filters/import/cdrloader.py", line 837, in Load self.import_curves() File "/Users/su_v/Applications/TST/Inkscape-0.48.4-RC1.app/Contents/Resources/python/site-packages/sk1libs/filters/import/cdrloader.py", line 880, in import_curves self.begin_page("",layout) AttributeError: CDRLoader instance has no attribute 'begin_page' Traceback (most recent call last): File "<string>", line 1, in <module> File "/Users/su_v/Applications/TST/Inkscape-0.48.4-RC1.app/Contents/Resources/python/site-packages/uniconvertor/__init__.py", line 95, in uniconv_run doc = load.load_drawing(input_file) File "/Users/su_v/Applications/TST/Inkscape-0.48.4-RC1.app/Contents/Resources/python/site-packages/uniconvertor/app/io/load.py", line 377, in load_drawing return load_drawing_from_file(file, filename) File "/Users/su_v/Applications/TST/Inkscape-0.48.4-RC1.app/Contents/Resources/python/site-packages/uniconvertor/app/io/load.py", line 354, in load_drawing_from_file raise SketchLoadError(_("Parsing error: ")+ str(value)) app.events.skexceptions.SketchLoadError: Parsing error: Parsing error: CDRLoader instance has no attribute 'begin_page'
The same CDR file(s) open ok with Inkscape & UniConvertor 1.1.4 on Ubuntu 12.10 (64bit, VM, Python 2.7), and with Inkscape & a rather dated tweaked installation of UniConvertor 1.1.5 for Python 2.6 on my older laptop with Mac OS X 10.5.8 (i386): Sample file from the bug tracker: https://bugs.launchpad.net/inkscape/+bug/442010/+attachment/771958/+files/Frenchcurve.cdr
I had no test files at hand for the other CorelDraw input file formats (CCX, CDT, CGM, CMX).
The remaining input formats based on UniConvertor (AI 8.0 and older, PLT, SK1, WMF) seem to work, as do the output formats (PLT, SK1, WMF) - tested and confirmed by round-trip editing a minimal Inkscape document with Inkscape.app (SVG -> PLT|SK1|WMF -> SVG).
Uniconvertor is not an easy package to fix. I'm going to look into it as time permits.
- WRT Crash on exit, or random dialogs from output extensions:
Bug #1046068 is not fixed by including a (semi- or fully-functional) UniConvertor 1.1.5 module in the app bundle, and while with the latest RC1 package Inkscape 0.48.4 doesn't prompt with annoying error dialogs from UniConvertor-based output extensions anymore, it leaves a file with a copy of the clipboard content in $TMPDIR, each time the app is exited with a non-empty clipboard, and has a noticeable delay on exit if the clipboard was not empty (since apparently the clipboard content is attempted to be exported to all supported clipboard targets based on the internal list of output extensions).
The "shortest path to annoyance removal" postpones a fix, and Inkscape is likely to face the same issue again in a few weeks or months, as soon as there are beta releases or release candidates of 0.49 available (trunk currently crashes right after creating a zero-size temp file in $TMPDIR if there is a at least one script-based output extension loaded either from the shared extensions directory or from the user Inkscape profile directory "$XDG_CONFIG_HOME/inkscape/extensions")
The annoyance was to me. If you want to see it revert this line
return ['/System/Library/Fonts', '/Library/Fonts', os.path.expanduser("~/Library/Fonts")]
back to
return ['/',]
When exiting with something in the clipboard, Inkscape will invoke a lower uniconvertor process that will scan all of the main disk. The python process will eat up all your memory, the all of your swap till it will freeze the Mac. I call that a major annoyance. The problem is why does Inkscape invoke that process when items are on the clip. I suspect is trying to leave something on the system clipboard in a particular format. That's where the fix should be
a) Assume a user somehow has managed to install 'gimp' (or a wrapper script to GIMP.app) into one of the paths in the app bundle's $PATH variable (add a fake 'gimp' shell script into 'Contents/Resources/bin' to test it): there's yet another dialog now appearing on quit from the GIMP XCF output file type (one or more layers are required, the clipboard content however is saved without layer information). Or the user has some additional extensions installed in '~/.config/inkscape/extensions' - those may also trigger the same issue (depending on the custom output extension).
b) Upstream bugs: including the UniConvertor module doesn't prevent related crashes which may get triggered with Inkscape 0.48.4 on exit, too, after having used the system clipboard to copy and paste e.g. text in Inkscape.app (e.g from GUI widgets containing text or digits) to native osx apps:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 000000000000000000 0 + 0 1 libgtk-quartz-2.0.0.dylib 0x000000010b2642ac gtk_clipboard_store + 268 2 libgtk-quartz-2.0.0.dylib 0x000000010b26432f _gtk_clipboard_store_all + 63 3 libgtk-quartz-2.0.0.dylib 0x000000010b135bc9 gtk_main + 537 4 Inkscape 0x00000001099aac24 sp_main_gui(int, char const**) + 1812 5 Inkscape 0x00000001099aafe1 main + 337 6 Inkscape 0x00000001099a8184 start + 52
(above crash occurred on exit with the RC1 package after copy&pasting the error messages from failed CDR import attempts into native OS X application (MacVim, Thunderbird), working in those other applications for a while before returning to Inkscape and closing it. Similar steps to reproduce the crash in GTK+/Quartz 2.24 are described e.g. in https://bugzilla.gnome.org/show_bug.cgi?id=626499#c18)
therw is a problem with the clipboard that needs to be analyzed.
V.
On 17/01/2013 17:06, Valerio Aimale wrote:
On 1/16/13 8:56 AM, ~suv wrote:
- WRT Crash on exit, or random dialogs from output extensions:
Bug #1046068 is not fixed by including a (semi- or fully-functional) UniConvertor 1.1.5 module in the app bundle, and while with the latest RC1 package Inkscape 0.48.4 doesn't prompt with annoying error dialogs from UniConvertor-based output extensions anymore, it leaves a file with a copy of the clipboard content in $TMPDIR, each time the app is exited with a non-empty clipboard, and has a noticeable delay on exit if the clipboard was not empty (since apparently the clipboard content is attempted to be exported to all supported clipboard targets based on the internal list of output extensions).
The "shortest path to annoyance removal" postpones a fix, and Inkscape is likely to face the same issue again in a few weeks or months, as soon as there are beta releases or release candidates of 0.49 available (trunk currently crashes right after creating a zero-size temp file in $TMPDIR if there is a at least one script-based output extension loaded either from the shared extensions directory or from the user Inkscape profile directory "$XDG_CONFIG_HOME/inkscape/extensions")
The annoyance was to me. If you want to see it revert this line
return ['/System/Library/Fonts', '/Library/Fonts', os.path.expanduser("~/Library/Fonts")]
back to
return ['/',]
When exiting with something in the clipboard, Inkscape will invoke a lower uniconvertor process that will scan all of the main disk. The python process will eat up all your memory, the all of your swap till it will freeze the Mac. I call that a major annoyance.
Ouch! I'd rather not go there again ;-) - I vaguely recall the troubles I had when trying to get UniConvertor working for Inkscape on Mac OS X 10.5.8. This is also one of the reasons I haven't bothered so far to try again on Lion (besides that I hadn't documented the changes I ended up with in a useful way, nor provided a patch upstream at the time when UniConvertor 1.x was still actively maintained, or at least created a custom Portfile with proper patchfiles to be able to reinstall it easily for python 2.7 or on a different machine).
The problem is why does Inkscape invoke that process when items are on the clip. I suspect is trying to leave something on the system clipboard in a particular format. That's where the fix should be
Agreed - I had added a similar comment yesterday to the bug report tracking this issue, before writing the reply about RC1 here on the list:
<quote> ISTM that Inkscape's system clipboard support needs to be adjusted to better support the (potentially only partially or differently implemented) GtkSelection and GtkClipboard features in the Quartz backend of current GTK+ 2.24.x (to prevent Inkscape from trying to export the clipboard content on exit at all). </quote> https://bugs.launchpad.net/inkscape/+bug/1046068
b) Upstream bugs: including the UniConvertor module doesn't prevent related crashes which may get triggered with Inkscape 0.48.4 on exit, too, after having used the system clipboard to copy and paste e.g. text in Inkscape.app (e.g from GUI widgets containing text or digits) to native osx apps:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 000000000000000000 0 + 0 1 libgtk-quartz-2.0.0.dylib 0x000000010b2642ac gtk_clipboard_store + 268 2 libgtk-quartz-2.0.0.dylib 0x000000010b26432f _gtk_clipboard_store_all + 63 3 libgtk-quartz-2.0.0.dylib 0x000000010b135bc9 gtk_main + 537 4 Inkscape 0x00000001099aac24 sp_main_gui(int, char const**) + 1812 5 Inkscape 0x00000001099aafe1 main + 337 6 Inkscape 0x00000001099a8184 start + 52
(above crash occurred on exit with the RC1 package after copy&pasting the error messages from failed CDR import attempts into native OS X application (MacVim, Thunderbird), working in those other applications for a while before returning to Inkscape and closing it. Similar steps to reproduce the crash in GTK+/Quartz 2.24 are described e.g. in https://bugzilla.gnome.org/show_bug.cgi?id=626499#c18)
therw is a problem with the clipboard that needs to be analyzed.
The crash described in comment #c18 is supposedly fixed with this commit to gtk-2.24 2 days ago: https://bugzilla.gnome.org/show_bug.cgi?id=626499#c21 http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=bc3f1893aa26761c0009ddc993b48623bcfbe4ed
On 1/17/13 9:42 AM, ~suv wrote:
On 17/01/2013 17:06, Valerio Aimale wrote:
On 1/16/13 8:56 AM, ~suv wrote:
- WRT Crash on exit, or random dialogs from output extensions:
Bug #1046068 is not fixed by including a (semi- or fully-functional) UniConvertor 1.1.5 module in the app bundle, and while with the latest RC1 package Inkscape 0.48.4 doesn't prompt with annoying error dialogs from UniConvertor-based output extensions anymore, it leaves a file with a copy of the clipboard content in $TMPDIR, each time the app is exited with a non-empty clipboard, and has a noticeable delay on exit if the clipboard was not empty (since apparently the clipboard content is attempted to be exported to all supported clipboard targets based on the internal list of output extensions).
The "shortest path to annoyance removal" postpones a fix, and Inkscape is likely to face the same issue again in a few weeks or months, as soon as there are beta releases or release candidates of 0.49 available (trunk currently crashes right after creating a zero-size temp file in $TMPDIR if there is a at least one script-based output extension loaded either from the shared extensions directory or from the user Inkscape profile directory "$XDG_CONFIG_HOME/inkscape/extensions")
The annoyance was to me. If you want to see it revert this line
return ['/System/Library/Fonts', '/Library/Fonts', os.path.expanduser("~/Library/Fonts")]
back to
return ['/',]
When exiting with something in the clipboard, Inkscape will invoke a lower uniconvertor process that will scan all of the main disk. The python process will eat up all your memory, the all of your swap till it will freeze the Mac. I call that a major annoyance.
Ouch! I'd rather not go there again ;-) - I vaguely recall the troubles I had when trying to get UniConvertor working for Inkscape on Mac OS X 10.5.8. This is also one of the reasons I haven't bothered so far to try again on Lion (besides that I hadn't documented the changes I ended up with in a useful way, nor provided a patch upstream at the time when UniConvertor 1.x was still actively maintained, or at least created a custom Portfile with proper patchfiles to be able to reinstall it easily for python 2.7 or on a different machine).
The problem is why does Inkscape invoke that process when items are on the clip. I suspect is trying to leave something on the system clipboard in a particular format. That's where the fix should be
Agreed - I had added a similar comment yesterday to the bug report tracking this issue, before writing the reply about RC1 here on the list:
<quote> ISTM that Inkscape's system clipboard support needs to be adjusted to better support the (potentially only partially or differently implemented) GtkSelection and GtkClipboard features in the Quartz backend of current GTK+ 2.24.x (to prevent Inkscape from trying to export the clipboard content on exit at all). </quote> <https://bugs.launchpad.net/inkscape/+bug/1046068>
b) Upstream bugs: including the UniConvertor module doesn't prevent related crashes which may get triggered with Inkscape 0.48.4 on exit, too, after having used the system clipboard to copy and paste e.g. text in Inkscape.app (e.g from GUI widgets containing text or digits) to native osx apps:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 000000000000000000 0 + 0 1 libgtk-quartz-2.0.0.dylib 0x000000010b2642ac gtk_clipboard_store + 268 2 libgtk-quartz-2.0.0.dylib 0x000000010b26432f _gtk_clipboard_store_all + 63 3 libgtk-quartz-2.0.0.dylib 0x000000010b135bc9 gtk_main + 537 4 Inkscape 0x00000001099aac24 sp_main_gui(int, char const**) + 1812 5 Inkscape 0x00000001099aafe1 main + 337 6 Inkscape 0x00000001099a8184 start + 52
(above crash occurred on exit with the RC1 package after copy&pasting the error messages from failed CDR import attempts into native OS X application (MacVim, Thunderbird), working in those other applications for a while before returning to Inkscape and closing it. Similar steps to reproduce the crash in GTK+/Quartz 2.24 are described e.g. in https://bugzilla.gnome.org/show_bug.cgi?id=626499#c18)
therw is a problem with the clipboard that needs to be analyzed.
The crash described in comment #c18 is supposedly fixed with this commit to gtk-2.24 2 days ago: https://bugzilla.gnome.org/show_bug.cgi?id=626499#c21 http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=bc3f1893aa26761c0009ddc993b48623bcfbe4ed
that might fix the crash, but, the weird thing that I observe is that the extension execution machinery is called to save a file for the clipboar ith mime type text/x-javafx/script (???), this is from gdb
$7 = { string_ = { _M_dataplus = { <std::allocator<char>> = { <__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, members of std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Alloc_hider: _M_p = 0x1100ac1e8 "text/x-javafx-script" } } }
and uniconvertor is called in an inferior process with a request to convert an svg to .plt
python -c "import uniconvertor; uniconvertor.uniconv_run();" "/var/folders/34/1gw04r0n67dfh3mrbyw12djw0000gn/T/ink_ext_XXXXXX.svgBKU4QW" UniConvertor .plt
On 17/01/2013 17:54, Valerio Aimale wrote:
On 1/17/13 9:42 AM, ~suv wrote:
On 17/01/2013 17:06, Valerio Aimale wrote:
On 1/16/13 8:56 AM, ~suv wrote:
- WRT Crash on exit, or random dialogs from output extensions:
Bug #1046068 is not fixed by including a (semi- or fully-functional) UniConvertor 1.1.5 module in the app bundle, and while with the latest RC1 package Inkscape 0.48.4 doesn't prompt with annoying error dialogs from UniConvertor-based output extensions anymore, it leaves a file with a copy of the clipboard content in $TMPDIR, each time the app is exited with a non-empty clipboard, and has a noticeable delay on exit if the clipboard was not empty (since apparently the clipboard content is attempted to be exported to all supported clipboard targets based on the internal list of output extensions).
The "shortest path to annoyance removal" postpones a fix, and Inkscape is likely to face the same issue again in a few weeks or months, as soon as there are beta releases or release candidates of 0.49 available (trunk currently crashes right after creating a zero-size temp file in $TMPDIR if there is a at least one script-based output extension loaded either from the shared extensions directory or from the user Inkscape profile directory "$XDG_CONFIG_HOME/inkscape/extensions")
The annoyance was to me. If you want to see it revert this line
return ['/System/Library/Fonts', '/Library/Fonts', os.path.expanduser("~/Library/Fonts")]
back to
return ['/',]
When exiting with something in the clipboard, Inkscape will invoke a lower uniconvertor process that will scan all of the main disk. The python process will eat up all your memory, the all of your swap till it will freeze the Mac. I call that a major annoyance.
Ouch! I'd rather not go there again ;-) - I vaguely recall the troubles I had when trying to get UniConvertor working for Inkscape on Mac OS X 10.5.8. This is also one of the reasons I haven't bothered so far to try again on Lion (besides that I hadn't documented the changes I ended up with in a useful way, nor provided a patch upstream at the time when UniConvertor 1.x was still actively maintained, or at least created a custom Portfile with proper patchfiles to be able to reinstall it easily for python 2.7 or on a different machine).
The problem is why does Inkscape invoke that process when items are on the clip. I suspect is trying to leave something on the system clipboard in a particular format. That's where the fix should be
Agreed - I had added a similar comment yesterday to the bug report tracking this issue, before writing the reply about RC1 here on the list:
<quote> ISTM that Inkscape's system clipboard support needs to be adjusted to better support the (potentially only partially or differently implemented) GtkSelection and GtkClipboard features in the Quartz backend of current GTK+ 2.24.x (to prevent Inkscape from trying to export the clipboard content on exit at all). </quote> <https://bugs.launchpad.net/inkscape/+bug/1046068>
b) Upstream bugs: including the UniConvertor module doesn't prevent related crashes which may get triggered with Inkscape 0.48.4 on exit, too, after having used the system clipboard to copy and paste e.g. text in Inkscape.app (e.g from GUI widgets containing text or digits) to native osx apps:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 000000000000000000 0 + 0 1 libgtk-quartz-2.0.0.dylib 0x000000010b2642ac gtk_clipboard_store + 268 2 libgtk-quartz-2.0.0.dylib 0x000000010b26432f _gtk_clipboard_store_all + 63 3 libgtk-quartz-2.0.0.dylib 0x000000010b135bc9 gtk_main + 537 4 Inkscape 0x00000001099aac24 sp_main_gui(int, char const**) + 1812 5 Inkscape 0x00000001099aafe1 main + 337 6 Inkscape 0x00000001099a8184 start + 52
(above crash occurred on exit with the RC1 package after copy&pasting the error messages from failed CDR import attempts into native OS X application (MacVim, Thunderbird), working in those other applications for a while before returning to Inkscape and closing it. Similar steps to reproduce the crash in GTK+/Quartz 2.24 are described e.g. in https://bugzilla.gnome.org/show_bug.cgi?id=626499#c18)
therw is a problem with the clipboard that needs to be analyzed.
The crash described in comment #c18 is supposedly fixed with this commit to gtk-2.24 2 days ago: https://bugzilla.gnome.org/show_bug.cgi?id=626499#c21 http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=bc3f1893aa26761c0009ddc993b48623bcfbe4ed
that might fix the crash, but, the weird thing that I observe is that the extension execution machinery is called to save a file for the clipboar ith mime type text/x-javafx/script (???), this is from gdb
$7 = { string_ = { _M_dataplus = { <std::allocator<char>> = { <__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, members of std::basic_string<char,std::char_traits<char>,std::allocator<char>
::_Alloc_hider:
_M_p = 0x1100ac1e8 "text/x-javafx-script" }} }
and uniconvertor is called in an inferior process with a request to convert an svg to .plt
python -c "import uniconvertor; uniconvertor.uniconv_run();" "/var/folders/34/1gw04r0n67dfh3mrbyw12djw0000gn/T/ink_ext_XXXXXX.svgBKU4QW" UniConvertor .plt
Confirmed - last night I did a test build with attached patch (0.48.x):
These simple steps: 1) launch inkscape 2) draw a rect 3) copy and paste the rect 4) deselect all and quit (without saving) will show that all available clipboard targets are exported (saved). Here's a list from my local build last night:
(gdb) r Starting program: /Volumes/cyan/src/inkscape/inkscape-0.48.x-quartz/build-debug/src/inkscape Reading symbols for shared libraries ++++++++++++++++++++++++++++++++++++++++++++++++++................................................................................................................................................................. done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries ... done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done
** (inkscape:8895): WARNING **: Clipboard target: image/x-inkscape-svg Reading symbols for shared libraries . done
** (inkscape:8895): WARNING **: Clipboard target: image/x-inkscape-svg
** (inkscape:8895): WARNING **: Clipboard target: image/svg+xml
** (inkscape:8895): WARNING **: Clipboard target: image/x-inkscape-svg-compressed
** (inkscape:8895): WARNING **: Clipboard target: image/svg+xml-compressed
** (inkscape:8895): WARNING **: Clipboard target: image/x-inkscape-svg
** (inkscape:8895): WARNING **: Clipboard target: application/pdf
** (inkscape:8895): WARNING **: Clipboard target: image/png
** (inkscape:8895): WARNING **: Clipboard target: image/x-postscript
** (inkscape:8895): WARNING **: Clipboard target: image/x-e-postscript
** (inkscape:8895): WARNING **: Clipboard target: text/x-povray-script
** (inkscape:8895): WARNING **: Clipboard target: text/x-javafx-script
** (inkscape:8895): WARNING **: Clipboard target: text/x-povray-script
** (inkscape:8895): WARNING **: Clipboard target: text/x-tex
** (inkscape:8895): WARNING **: Clipboard target: image/dxf
** (inkscape:8895): WARNING **: Clipboard target: image/dxf
** (inkscape:8895): WARNING **: Clipboard target: application/x-xcf
** (inkscape:8895): WARNING **: Clipboard target: image/hpgl
** (inkscape:8895): WARNING **: Clipboard target: application/x-zip
** (inkscape:8895): WARNING **: Clipboard target: image/x-plt
** (inkscape:8895): WARNING **: Clipboard target: image/svg+xml
** (inkscape:8895): WARNING **: Clipboard target: application/x-xsk1
** (inkscape:8895): WARNING **: Clipboard target: text/xml+xaml
** (inkscape:8895): WARNING **: Clipboard target: application/x-zip
** (inkscape:8895): WARNING **: Clipboard target: application/x-wmf
** (inkscape:8895): WARNING **: Clipboard target: image/png
Program exited normally. (gdb)
If the clipboard is not empty, every available mime type (clipboard target) is saved on exit, with various dialogs popping up depending on whether an extension reports an error message back or not, after the main document window is closed.
On 17/01/2013 17:06, Valerio Aimale wrote:
On 1/16/13 8:56 AM, ~suv wrote:
- No keyboard shortcuts for menu items
- No hints for menu items in the status bar
- ...
(see my earlier replies for related bug report numbers)
Are these indeed issues which need to be fixed in platform-/distro-/desktop- and/or backend-specific patches, or is it reasonable to assume that they are rooted in the same structure of Inkscape's current code base, and might have a better chance to get addressed in a joint effort if not being tagged with 'osx only'?
This is due to the fact that Inkscpae does not use GtkAccel in menuitems' GtkLabels. Without adding that logic, it won;t happen. Are menu accelerators symbols a show stopper for an OSX 0.48.4?
No, I don't think that the missing symbols are a show stopper: My main concerns are about communicating changes to users: - How do users switching from the X11 version know right away whether they have to relearn the shortcuts with the Quartz-based 0.48.4 package, or whether the old shortcuts are still in effect? - What about new users? - If the modifiers are switched (for verb-based commands only), what about the online 'Inkscape keyboard and mouse reference'? Does it need a separate version for the latest Mac package? - ...
To be honest, based on the RC1 package, it's somewhat unclear to me at the moment whether you plan to replace 'Ctrl' with 'Cmd' for the verb-based shortcuts (using the patch from https://bugs.launchpad.net/inkscape/+bug/1097539 and a modified 'keys/default.xml' file), or rather keep it optional.
On 1/17/13 10:13 AM, ~suv wrote:
On 17/01/2013 17:06, Valerio Aimale wrote:
On 1/16/13 8:56 AM, ~suv wrote:
- No keyboard shortcuts for menu items
- No hints for menu items in the status bar
- ...
(see my earlier replies for related bug report numbers)
Are these indeed issues which need to be fixed in platform-/distro-/desktop- and/or backend-specific patches, or is it reasonable to assume that they are rooted in the same structure of Inkscape's current code base, and might have a better chance to get addressed in a joint effort if not being tagged with 'osx only'?
This is due to the fact that Inkscpae does not use GtkAccel in menuitems' GtkLabels. Without adding that logic, it won;t happen. Are menu accelerators symbols a show stopper for an OSX 0.48.4?
No, I don't think that the missing symbols are a show stopper: My main concerns are about communicating changes to users:
- How do users switching from the X11 version know right away whether
they have to relearn the shortcuts with the Quartz-based 0.48.4 package, or whether the old shortcuts are still in effect?
- What about new users?
- If the modifiers are switched (for verb-based commands only), what
about the online 'Inkscape keyboard and mouse reference'? Does it need a separate version for the latest Mac package?
- ...
To be honest, based on the RC1 package, it's somewhat unclear to me at the moment whether you plan to replace 'Ctrl' with 'Cmd' for the verb-based shortcuts (using the patch from https://bugs.launchpad.net/inkscape/+bug/1097539 and a modified 'keys/default.xml' file), or rather keep it optional.
No, that was just a mistake on my side when I packaged RC1. I forgot to copy mac.xml over to default.xml. If you do that in your Applications/bundle you'll have full Command-Key support.
cd /Applications/Inkscape.app/Contents/Resources/keys cp mac.xml default.xml
On 17/01/2013 18:15, Valerio Aimale wrote:
On 1/17/13 10:13 AM, ~suv wrote:
On 17/01/2013 17:06, Valerio Aimale wrote:
On 1/16/13 8:56 AM, ~suv wrote:
- No keyboard shortcuts for menu items
- No hints for menu items in the status bar
- ...
(see my earlier replies for related bug report numbers)
Are these indeed issues which need to be fixed in platform-/distro-/desktop- and/or backend-specific patches, or is it reasonable to assume that they are rooted in the same structure of Inkscape's current code base, and might have a better chance to get addressed in a joint effort if not being tagged with 'osx only'?
This is due to the fact that Inkscpae does not use GtkAccel in menuitems' GtkLabels. Without adding that logic, it won;t happen. Are menu accelerators symbols a show stopper for an OSX 0.48.4?
No, I don't think that the missing symbols are a show stopper: My main concerns are about communicating changes to users:
- How do users switching from the X11 version know right away whether
they have to relearn the shortcuts with the Quartz-based 0.48.4 package, or whether the old shortcuts are still in effect?
- What about new users?
- If the modifiers are switched (for verb-based commands only), what
about the online 'Inkscape keyboard and mouse reference'? Does it need a separate version for the latest Mac package?
- ...
To be honest, based on the RC1 package, it's somewhat unclear to me at the moment whether you plan to replace 'Ctrl' with 'Cmd' for the verb-based shortcuts (using the patch from https://bugs.launchpad.net/inkscape/+bug/1097539 and a modified 'keys/default.xml' file), or rather keep it optional.
No, that was just a mistake on my side when I packaged RC1. I forgot to copy mac.xml over to default.xml. If you do that in your Applications/bundle you'll have full Command-Key support.
cd /Applications/Inkscape.app/Contents/Resources/keys cp mac.xml default.xml
'mac.xml' isn't included either - I'm attaching a local version created with the patch from https://bugs.launchpad.net/inkscape/+bug/1097539, in case any testers out there want to give it a try...
On 17/01/2013 19:22, Valerio Aimale wrote:
On 1/17/13 11:11 AM, Dave Crossland wrote:
Can you also make a nightly snapshot build? :-)
I think the build system is almost at the point where it can actually do a nightly build.
/me waits patiently for (any) updated code/patches getting shared, and crosses fingers that it won't break the ability to continue building plain command line versions for either backend of GTK+ ;-)
Where do nightly build happen? On somebody's Mac and then uploaded to sourceforge?
There is no place to upload nightly OS X builds anymore since we lost hosting at inkscape.modevia.com - see mailing list archives for earlier discussions about this: http://inkscape.13.n6.nabble.com/Modevia-amp-Nightlies-tt2835810.html#none http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/37526 ... and probably others.
The win32 development snapshot builds done by Uwe Schöller are currently uploaded to his skydrive site, but having a single site with nightly snapshot builds for both Windwos and Mac OS X would be preferred (IMvHO).
IIRC the required amount of space (to keep an archive of the builds) doesn't fit into how Inkscape uses sourceforge.net (at least last time this came up, sf.net was not considered as alternative to inkscape.modevia.com. I could be wrong though - currently I fail to find a related discussion in any of the mailing list archives).
On 1/17/13 11:53 AM, ~suv wrote:
On 17/01/2013 19:22, Valerio Aimale wrote:
On 1/17/13 11:11 AM, Dave Crossland wrote:
Can you also make a nightly snapshot build? :-)
I think the build system is almost at the point where it can actually do a nightly build.
/me waits patiently for (any) updated code/patches getting shared, and crosses fingers that it won't break the ability to continue building plain command line versions for either backend of GTK+ ;-)
patches are time-consuming to maintain. and a pain.
Here's my personal plan:
- give Mac users a usable 0.48.4 - merge all my modifications info trunk or wherever you want them - make sure nightly builds builds
Where do nightly build happen? On somebody's Mac and then uploaded to sourceforge?
There is no place to upload nightly OS X builds anymore since we lost hosting at inkscape.modevia.com - see mailing list archives for earlier discussions about this: http://inkscape.13.n6.nabble.com/Modevia-amp-Nightlies-tt2835810.html#none http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/37526 ... and probably others.
The win32 development snapshot builds done by Uwe Schöller are currently uploaded to his skydrive site, but having a single site with nightly snapshot builds for both Windwos and Mac OS X would be preferred (IMvHO).
IIRC the required amount of space (to keep an archive of the builds) doesn't fit into how Inkscape uses sourceforge.net (at least last time this came up, sf.net was not considered as alternative to inkscape.modevia.com. I could be wrong though - currently I fail to find a related discussion in any of the mailing list archives).
Is there a way to automatically upload to sourceforge and keep just the last 3 builds, to spare space?
Valerio
On 2013-01-16 16:56 +0200, ~suv wrote:
On 15/01/2013 18:17, Valerio Aimale wrote:
On 2013-01-07 15:45 +0200, ~suv wrote:
- Known issues with 'gtk-mac-integration' (from gtk-osx)
(originally tracked in bug #721448 and bug #738973):
- Menubar: thousands of console messages about "object class `GtkLabel' has no property named `accel-closure'" (bug #1043266)
- no more noise on the terminal stderr
From the POV of helping with bug triage and user support, I'm not really happy with the chosen "fix" either (sending _all_ stderr messages to /dev/null), but I do understand that other options are out-of-reach if the goal is to release a Quartz-based package of 0.48.4 ASAP.
Confirmed fixed upstream with latest gtk-mac-integration (git master) - no more warnings flooding the console [*]:
Commit: https://git.gnome.org/browse/gtk-mac-integration/commit/?id=16fefaf1e9191e1d417ff12a70228d4cd96cf816
[*] local test build (r12524) on OS X 10.7.5 with very basic gtk-mac-integration (global menubar) based on code in Gellule's original dev-osx branch: https://code.launchpad.net/~inkscape.dev/inkscape/dev-osx http://bazaar.launchpad.net/~inkscape.dev/inkscape/dev-osx/revision/11628
Can you explain what you did to get sk1libs and friends to compile in 10.8?
I have been frustrated with trying to use Inkscape for my complete workflow. As it is now, I have to move files to another system to generate the plt files I need and that just creates problems if I am not where I can get to it.
I just installed your 0.4.8.4 build but evidently these need to be built still.
You need to install the UniConvertor software. For GNU/Linux: install the package python-uniconvertor. For Windows: download it from http://sk1project.org/modules.php?name=Products&product=uniconvertor and install into your Inkscape's Python location
I get a pile of errors from clang when I try it and don't really know what to do next. I'm not opposed to progress but Apple sometimes moves ahead before we're all ready to move.
-- View this message in context: http://inkscape.13.x6.nabble.com/Mac-OS-X-Build-0-48-4-RC1-tp4965929p4967034... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Five cents from sK1 Project: Content of Inkscape binary bundle can be fixed by Inkscape devs only, but we hope releasing soon UniConvertor 2.0 for MacOS X as a standalone application.
On Jun 5, 2013, at 10:04 AM, Igor Novikov <igor.e.novikov@...400...> wrote:
Content of Inkscape binary bundle can be fixed by Inkscape devs only, but we hope releasing soon UniConvertor 2.0 for MacOS X as a standalone application.
Eh, I have to call shenanigans on this. I think the responsibility for keeping these things up to date lies with the SK1 project. Mountain Lion shipped on July 25, 2012. Surely, that's enough time to fix the build process. Who will care about Uniconvertor 2.0 if they've never gotten 1.x to work?
It's not like these tools are usable as standalone tools but are only broken when incorporated into Inkscape. They don't build easily or at all, at least in OS X. Obviously, some people here know how to build them but why does anything as lightweight as this toolset require anything more than "python setup.py build" or "./configure; make install?"
I'm glad these RCs are available but the effort it took to get them ready was more than it should have been. -- Paul Beard
Are you trying to win an argument or solve a problem?
For Inkscape application UniConvertor is library among other used libs like gtk, freetype, pango etc. Developers of these libraries are not responsible for Inkscape integrity. Concerning UC 2.0, the tool is a part of PrintDesign application (see http://sk1project.org) and will be released any way for MacOS X together with PrintDesign. As an option we could providing .pkg installer for UC to support Inkscape (because Inkscape uses UC as a command line tool). But this will be possible only when we are ready to release PrintDesign.
On Wed, Jun 5, 2013 at 8:23 PM, Paul Beard <paulbeard@...400...> wrote:
On Jun 5, 2013, at 10:04 AM, Igor Novikov <igor.e.novikov@...400...> wrote:
Content of Inkscape binary bundle can be fixed by Inkscape devs only, but we hope releasing soon UniConvertor 2.0 for MacOS X as a standalone application.
Eh, I have to call shenanigans on this. I think the responsibility for keeping these things up to date lies with the SK1 project. Mountain Lion shipped on July 25, 2012. Surely, that's enough time to fix the build process. Who will care about Uniconvertor 2.0 if they've never gotten 1.x to work?
It's not like these tools are usable as standalone tools but are only broken when incorporated into Inkscape. They don't build easily or at all, at least in OS X. Obviously, some people here know how to build them but why does anything as lightweight as this toolset require anything more than "python setup.py build" or "./configure; make install?"
I'm glad these RCs are available but the effort it took to get them ready was more than it should have been. -- Paul Beard
Are you trying to win an argument or solve a problem?
How ServiceNow helps IT people transform IT departments:
- A cloud service to automate IT design, transition and operations
- Dashboards that offer high-level views of enterprise services
- A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Jun 5, 2013, at 10:58 AM, Igor Novikov <igor.e.novikov@...400...> wrote:
For Inkscape application UniConvertor is library among other used libs like gtk, freetype, pango etc. Developers of these libraries are not responsible for Inkscape integrity.
I'm not claiming you or the SK1 team is responsible for Inkscape's integrity: my point is that Inkscape's developers aren't responsible for if/whether the SK1 tools work. Obviously, they have worked out how to build them. Inkscape doesn't rely on sk1libs, except for the export/conversion of files, unlike the other libraries you mention. If I didn't try exporting to hpgl/plt, I would never know there was an sk1libs component. It's not a core Inkscape feature.
UniConvertor 1.x are workable because it works correctly as on Linux and on Windows platforms. The problem is incomplete Inkscape build for MacOS X unlike Windows or Linux versions. We could fix this issue providing .pkg installer for UniConvertor. But this installer will be large, because it should include a lot of libraries which are already shipped with Inkscape bundle. So the best way is improve Inkscape build for Mac.
среда, 5 июня 2013 г. пользователь Paul Beard писал:
On Jun 5, 2013, at 10:58 AM, Igor Novikov <igor.e.novikov@...400...javascript:;> wrote:
For Inkscape application UniConvertor is library among other used libs
like gtk, freetype, pango etc. Developers of these libraries are not responsible for Inkscape integrity.
I'm not claiming you or the SK1 team is responsible for Inkscape's integrity: my point is that Inkscape's developers aren't responsible for if/whether the SK1 tools work. Obviously, they have worked out how to build them. Inkscape doesn't rely on sk1libs, except for the export/conversion of files, unlike the other libraries you mention. If I didn't try exporting to hpgl/plt, I would never know there was an sk1libs component. It's not a core Inkscape feature.
participants (8)
-
Dave Crossland -
Igor Novikov -
Paul Beard -
paulbeard -
su_v -
Valerio Aimale -
Victor / tokiop -
~suv