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
- 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
- uniconvertor/sk1libs installed and fixed
The sk1libs/utilsfs.py line
really should be
return ['/System/Library/Fonts', '/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:
Traceback (most recent call last):
line 837, in Load
line 880, in import_curves
AttributeError: CDRLoader instance has no attribute 'begin_page'
Traceback (most recent call last):
File "<string>", line 1, in <module>
line 95, in uniconv_run
doc = load.load_drawing(input_file)
line 377, in load_drawing
return load_drawing_from_file(file, filename)
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:
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**) +
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
- no more noise on the terminal stderr
From the POV of helping with bug triage and user support, I'm not
happy with the chosen "fix" either (sending _all_ stderr messages
/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