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 : -- . ..: + o |‹ i o p

On 15/01/2013 18:17, Valerio Aimale wrote: See comments below 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'? 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). Confirmed. 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: 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... 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: (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>) 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. - 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 1/16/13 10:36 AM, ~suv wrote: 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 1/16/13 8:56 AM, ~suv wrote: 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 1/16/13 8:56 AM, ~suv wrote: 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? Same as before GtkAccel has to be implemented. Uniconvertor is not an easy package to fix. I'm going to look into it as time permits. 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 therw is a problem with the clipboard that needs to be analyzed. V.

On 1/17/13 9:42 AM, ~suv wrote: 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:06, Valerio Aimale wrote: 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 17/01/2013 18:15, Valerio Aimale wrote: '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 1/17/13 11:11 AM, Dave Crossland wrote: I think the build system is almost at the point where it can actually do a nightly build. Where do nightly build happen? On somebody's Mac and then uploaded to sourceforge? V.

On 1/17/13 11:53 AM, ~suv wrote: 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 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: 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=16fefaf1e9191... [*] 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...

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. -- Regards, Igor Novikov sK1 Project http://sk1project.org On Tue, Jun 4, 2013 at 7:04 PM, paulbeard <paulbeard@...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. 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: -- Regards, Igor Novikov sK1 Project http://sk1project.org

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 писал: -- Regards, Igor Novikov sK1 Project http://sk1project.org