Hi,

https://bugs.launchpad.net/inkscape-devlibs/+bug/1252719 This is a mix of issues, one of which I've personally fixed in the past by rebuilding all the C++ dependencies, but it looks like someone undid this work :(

Note that 1252719 is related to the experimental devlibs-gtk3, not to the official devlibs (and thus the dependencies are from Opensuse).

https://bugs.launchpad.net/inkscape-devlibs/+bug/1153777 Requires updating GDK-Pixbuf, see above. https://bugs.launchpad.net/inkscape-devlibs/+bug/602824 Old report with no activity since 2010. Might be fixed with GDK-Pixbuf update.

I'm currently rebuilding the latest Inkscape revision with a the experimental devlibs to confirm it's fixed.

2. Build GTK 2.24.23, or download it from OBS.

Also note that the experimental devlibs (OBS based) also provide support for GTK2. IMHO it would be far more convenient if we could use it instead of the current devlibs. Unfortunately there are still some bugs, and the most recent GTK2 version available from OBS is GTK 2.24.18.

Regards, -- Nicolas

I built the latest revision 13279 using my environment (Msys/Mingw64/gcc 4.8.1) and the Win 8.1 64bit build completes with some caveat that probably would not be relevant here.

Anyway, the build is not usable on a Windows native 64bit machine because you cannot open any files. The open file dialog does not open.

I have encountered this issue before with 0.48.4 and resolved it by commenting out Windows specific file dialog. The gtk dialog was fine and the build has been used successfully by quite a few people.

However, the whole dialog is now more complicated and the above fix no longer works. I can get the "open file" dialog but it Inkscape crashes immediately when you try to open a selected file. gdb is not very revealing other than: Reading symbols from Z:\opts\opt64\inkscape\inkscape.exe...done. (gdb) r Starting program: Z:\opts\opt64\inkscape\inkscape.exe [New Thread 4188.0x12b4] [New Thread 4188.0x141c] ... warning: Critical error detected c0000374

And then

Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffc452f383c in ?? () (gdb) bt #0 0x00007ffc452f383c in ?? () #1 0x0000000000000003 in ?? () #2 0x000000000023d040 in ?? () #3 0x00007ffc452a4010 in ?? () #4 0x00000000c0000374 in ?? () #5 0x0000000000000000 in ?? () (gdb) q

So, from my perspective, cannot run the current incarnation as a 64-bit build on Windows

Thanks, Partha

On Thu, Apr 10, 2014 at 8:40 AM, su_v <suv-sf@...58...> wrote:

On 2014-04-10 24:01 +0100, Krzysztof Kosiński wrote:

...

I would like to push out Inkscape 0.48.5 in the very near future (1-2 weeks at most), since a fair number of bugfixes have accumulated since the last stable release 15 months ago.

If you know of any simple bugs that can be fixed by backporting a few lines of code, please tag them with "backport-proposed" in the Launchpad bug tracker, so that I can fix them.

I could use some assistance with the following:

1. Writing release notes
2. Making binary packages for Windows and OSX
3. Announcing the release on the website and mailing lists

Anyone wants to help?

Re OSX: the currently available packaging scripts are outdated and fail on Mac OS X 10.6 Snow Leopard and later versions of OS X. See also: http://wiki.inkscape.org/wiki/index.php/Notes_on_Packaging_for_OS_X

Possibly of interest: During the past months I have attempted to rewrite parts of the existing scripts to support creating a GTK+/Quartz based application bundle for trunk (0.91): https://code.launchpad.net/~suv-lp/inkscape/osxmenu

A backport to stable 0.48.x is here: https://code.launchpad.net/~suv-lp/inkscape/osxmenu-0.48.x

Teaser screenshot of latest stable build earlier today: https://dl.dropboxusercontent.com/u/65084033/irc/stable-osxmenu-1.png

Both branches (and the available packages) have to be considered experimental at this stage:

1. the modified scripts (osx-build.sh and osx-app.sh) have not been

vetted to work on other systems with dependencies installed in different prefixes: the main goal for now was to be able to produce working, self-containted relocatable application bundles which support (almost) as many features as installs on other platforms. A lot of necessary checks, e.g. for OS X and Xcode version (for compiler flags) need to be updated or added. 2) no updated documentation available about the process itself (from getting the required dependencies installed to compiling inkscape itself to creating the application bundle) 3) both branches have changes not only to scripts in 'packaging', but also in 'src' (for OS integration like global menubar and keyboard shortcut modifiers, and for relocation support). Since I don't really code in C/C++ myself, my primary goal was to make the required changes work as expected (which they do, mostly), but all these changes really need code review and a lot of help to improve/fix them (avoid mem leaks etc.). Some features are still pending (due to lack of skills and time).

A summary of open known issues is listed on the branch page: https://code.launchpad.net/~suv-lp/inkscape/osxmenu

Some of the issues I would consider critical for the release of new GTK+/Quartz based OS X packages (stable or trunk): https://code.launchpad.net/bugs/1046068 https://code.launchpad.net/bugs/1116468 https://code.launchpad.net/bugs/1302627 https://code.launchpad.net/bugs/1024344

Regards, V

P.S: Please note: available packages for testing are currently shared via my personal Dropbox account (a free one, which has download limits for shared files). They are (from my point of view) at this stage not yet ready for wider testing (please don't post the dropbox links elsewhere, thx). Clayton Walker, Andy Fitzsimon and Michael New have been testing trunk builds on OS X Mavericks and provide(d) very helpful feedback.

---

Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Hi Krzysztof,

Previously with 0.48.4, I was able to disable Windows file dialog simply in the filedialog.cpp and I was good to go.

Now, if I use the same process, I can disable the Windows file dialog and get the gtk file dialog, but I get a segfault when I try to open a file (or save a file for that matter).

Thanks, Partha

On Sat, Apr 12, 2014 at 11:54 AM, Krzysztof Kosiński <tweenk.pl@...400...>wrote:

2014-04-12 4:36 GMT+02:00 Partha Bagchi <partha1b@...400...>:

...

I built the latest revision 13279 using my environment (Msys/Mingw64/gcc 4.8.1) and the Win 8.1 64bit build completes with some caveat that

probably

...

would not be relevant here.

Anyway, the build is not usable on a Windows native 64bit machine because you cannot open any files. The open file dialog does not open.

I have encountered this issue before with 0.48.4 and resolved it by commenting out Windows specific file dialog. The gtk dialog was fine and

the

...

build has been used successfully by quite a few people.

However, the whole dialog is now more complicated and the above fix no longer works. I can get the "open file" dialog but it Inkscape crashes immediately when you try to open a selected file. gdb is not very

revealing

...

other than: Reading symbols from Z:\opts\opt64\inkscape\inkscape.exe...done. (gdb) r Starting program: Z:\opts\opt64\inkscape\inkscape.exe [New Thread 4188.0x12b4] [New Thread 4188.0x141c] ... warning: Critical error detected c0000374

Does this error happen with the Windows file dialogs disabled, or are they too difficult to disable?

Regards, Krzysztof

I am not familiar with Ip:inkscape-devlibs64 project. Can you tell me how to share my environment there?

Thanks in advance, Partha

On Sat, Apr 12, 2014 at 5:36 PM, the Adib <theadib@...400...> wrote:

Hello Partha,

what about sharing your environment on a lp:inkscape-devlibs64 project? so potentially more people could investigate.

regards,

Adib

On Sat, Apr 12, 2014 at 5:02 PM, Partha Bagchi <partha1b@...400...> wrote:

...

Hi Krzysztof,

Previously with 0.48.4, I was able to disable Windows file dialog simply in the filedialog.cpp and I was good to go.

Now, if I use the same process, I can disable the Windows file dialog and get the gtk file dialog, but I get a segfault when I try to open a file (or save a file for that matter).

Thanks, Partha

On Sat, Apr 12, 2014 at 11:54 AM, Krzysztof Kosiński <tweenk.pl@...360...400...

...

wrote:

...

2014-04-12 4:36 GMT+02:00 Partha Bagchi <partha1b@...400...>:

...

I built the latest revision 13279 using my environment

(Msys/Mingw64/gcc

...

4.8.1) and the Win 8.1 64bit build completes with some caveat that

probably

...

would not be relevant here.

Anyway, the build is not usable on a Windows native 64bit machine

because

...

you cannot open any files. The open file dialog does not open.

I have encountered this issue before with 0.48.4 and resolved it by commenting out Windows specific file dialog. The gtk dialog was fine

and the

...

build has been used successfully by quite a few people.

However, the whole dialog is now more complicated and the above fix no longer works. I can get the "open file" dialog but it Inkscape crashes immediately when you try to open a selected file. gdb is not very

revealing

...

other than: Reading symbols from Z:\opts\opt64\inkscape\inkscape.exe...done. (gdb) r Starting program: Z:\opts\opt64\inkscape\inkscape.exe [New Thread 4188.0x12b4] [New Thread 4188.0x141c] ... warning: Critical error detected c0000374

Does this error happen with the Windows file dialogs disabled, or are they too difficult to disable?

Regards, Krzysztof

---

Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

That sounds great. I just hope that I can figure out how to use Ip. Anyway, I will be happy to upload my environment.

Thanks, Partha

On Sat, Apr 12, 2014 at 6:10 PM, Krzysztof Kosiński <tweenk.pl@...400...>wrote:

2014-04-12 23:45 GMT+02:00 Partha Bagchi <partha1b@...400...>:

...

I am not familiar with Ip:inkscape-devlibs64 project. Can you tell me

how to

...

share my environment there?

I think Adib was talking about sharing your environment in a new LP project.

However, I have a better idea: I can add you to the Inkscape Developers team. Then you will be able to push a Bazaar branch containing your build environment to:

lp:~inkscape.dev/inkscape-devlibs/devlibs-64bit

I will then register this as a series.

Regards, Krzysztof

My launchpad id is partha1b.

Thanks, Partha

On Sat, Apr 12, 2014 at 6:53 PM, Krzysztof Kosiński <tweenk.pl@...972.....>wrote:

2014-04-13 0:40 GMT+02:00 Partha Bagchi <partha1b@...400...>:

...

That sounds great. I just hope that I can figure out how to use Ip.

Anyway,

...

I will be happy to upload my environment.

OK, in that case tell me your Launchpad account name.

There are some instruction on the wiki on how to use Bazaar, but if you have problems feel free to ask. http://wiki.inkscape.org/wiki/index.php/Working_with_Bazaar

Regards, Krzysztof

On 2014-04-15 16:04 +0100, Adam Strzelecki wrote:

I was doing some fixing to OSX builds back in 2008. Now I came back to see whazzup (since Inkscape is best SVG editor around) and had a chat with Valerio (su_v) yesterday.

Sorry to disappoint you - I'm not Valerio ;-) (my first name starts with V too, though).

Cheers, V

2014-04-15 16:04 GMT+02:00 Adam Strzelecki <ono@...1858...>:

Hello,

I was doing some fixing to OSX builds back in 2008. Now I came back to see whazzup (since Inkscape is best SVG editor around) and had a chat with Valerio (su_v) yesterday.

Basically his builds are great improvement to what is there both in trunk (OSX builds scripts) and X11 based builds experience.

Therefore I strongly encourage Inkscape maintainers to incorporate his patches into Inkscape trunk and finally provide native OSX builds.

OK, I can merge these branches, though I can't test them as I have no access to OSX.

I note that suv's branch contains some extra extensions in the packaging directory. Is this intended? Why are they not in the global extension directory?

For sake of best Mac experience I have made very close to „native” GTK2 theme here: https://github.com/nanoant/Mac-gtk2-theme

Here is how it looks like: https://raw.githubusercontent.com/nanoant/Mac-gtk2-theme/master/screenshots/...

This may be better for a default theme as it more less resembles native OSX interface and it is close to how previous X11 builds look like. But of course user may be given an option to choose dark theme instead.

If you could make a branch that provides this theme or modify the packaging script so that it downloads and puts this theme into the OSX package, I could also merge this.

Regards, Krzysztof

2014-04-15 19:34 GMT+02:00 su_v <suv-sf@...58...>:

On 2014-04-15 18:53 +0100, Krzysztof Kosiński wrote:

...

2014-04-15 16:04 GMT+02:00 Adam Strzelecki <ono@...1858...>:

...

Hello,

I was doing some fixing to OSX builds back in 2008. Now I came back to see whazzup (since Inkscape is best SVG editor around) and had a chat with Valerio (su_v) yesterday.

Basically his builds are great improvement to what is there both in trunk (OSX builds scripts) and X11 based builds experience.

Therefore I strongly encourage Inkscape maintainers to incorporate his patches into Inkscape trunk and finally provide native OSX builds.

OK, I can merge these branches, though I can't test them as I have no access to OSX.

I note that suv's branch contains some extra extensions in the packaging directory. Is this intended? Why are they not in the global extension directory?

Please note: current state of the branch is 'experimental', and I didn't request a merge at this stage yet.

I would really like to get 0.48.5 out of the door this week (e.g. get a tarball uploaded).

Should I just release it as is, or wait for further OSX improvements?

Regards, Krzysztof

In my experience, it's a bad idea to pile on a bunch of complex changes at the last minute. It sounds like 0.48.5 is ready to go, and Mac OSX stuff is still in development. Better to take your time and make sure it's a quality release. As Adam mentioned, you can still announce that Mac integration is important and under development and start recruiting beta testers.

On Tue, Apr 15, 2014 at 12:05 PM, su_v <suv-sf@...58...> wrote:

On 2014-04-15 19:37 +0100, Krzysztof Kosiński wrote:

...

2014-04-15 19:34 GMT+02:00 su_v <suv-sf@...58...>:

...

On 2014-04-15 18:53 +0100, Krzysztof Kosiński wrote:

...

2014-04-15 16:04 GMT+02:00 Adam Strzelecki <ono@...1858...>:

...

Hello,

I was doing some fixing to OSX builds back in 2008. Now I came back

to see whazzup (since Inkscape is best SVG editor around) and had a chat with Valerio (su_v) yesterday.

...

...

...

...

Basically his builds are great improvement to what is there both in

trunk (OSX builds scripts) and X11 based builds experience.

...

...

...

...

Therefore I strongly encourage Inkscape maintainers to incorporate

his patches into Inkscape trunk and finally provide native OSX builds.

...

...

...

OK, I can merge these branches, though I can't test them as I have no access to OSX.

I note that suv's branch contains some extra extensions in the packaging directory. Is this intended? Why are they not in the global extension directory?

Please note: current state of the branch is 'experimental', and I didn't request a merge at this stage yet.

I would really like to get 0.48.5 out of the door this week (e.g. get a tarball uploaded).

Should I just release it as is, or wait for further OSX improvements?

Don't know, either (neither option seems really ok). [0]

1. Current packaging scripts in trunk and in the stable release branch

don't work to quickly produce a new X11-based package of 0.48.5. [1]

2. Creating new packages with GTK+/Quartz and better OS integration

requires changes in 'src' which need to be reviewed, fixed, or written (some are missing at the moment). [2]

3. A possible compromise for 0.48.5 (native backend, but no OS

integration) might be doable, but would also take time. [3]

IIRC - for the stable release branch, after the long delays which had occurred in the past, it was decided to not delay a new release itself, even if packages for some of the supported platforms are still missing.

How to handle this if creating the missing packages would require changes to the released sources, I don't know.

Regards, V

[0] I would not want to be the one who calls for or causes a further delay, OTOH if there's another release without OS X packages, this will further hurt Inkscape's image among Mac users.

[1] The application launcher which in this case needs to be a binary no longer compiles (on 10.6 and later), the precompiled python modules which used to be hosted on modevia are gone, the script to fill the app bundle is outdated wrt upstream changes and awfully slow, available documentation of the build and packaging process it out-of-date (also wrt upstream changes in MacPorts, and in newer releases of OS X / Xcode).

[2] These changes in 'src' also need to be verified to not cause issues on other platforms (for example the additional modifier added for usage in the keymap files).

[3] Does not exist yet (as branch, or patch). In the osxmenu branch, one would have to revert the OS integration parts, and its effects on the bundle structure & launcher. The resulting package would have less OS integration (no support for 'Open with...' or for opening files by drag&drop on the Dock icon), and still use 'Ctrl' instead of 'Cmd'.

---

Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

I personally believe that packaging is a secondary issue. The first is to make sure that it works as a native OSX application. Once we can determine that, we can always create the package.

Thanks, Partha

On Tue, Apr 15, 2014 at 9:03 PM, Krzysztof Kosiński <tweenk.pl@...972.....>wrote:

2014-04-15 21:05 GMT+02:00 su_v <suv-sf@...58...>:

...

1. Current packaging scripts in trunk and in the stable release branch

don't work to quickly produce a new X11-based package of 0.48.5. [1]

So it sounds like have to provide a Quartz build for OSX, right?

...

2. Creating new packages with GTK+/Quartz and better OS integration

requires changes in 'src' which need to be reviewed, fixed, or written (some are missing at the moment). [2]

What items are still missing and how long would it take to implement them?

I can review the code changes, but I have tons of stuff to do at the university, so I'm not sure how long it will take :/

...

3. A possible compromise for 0.48.5 (native backend, but no OS

integration) might be doable, but would also take time. [3]

If most of the work towards making a correct package with OS integration is done, then I'd rather wait a little for #2.

...

IIRC - for the stable release branch, after the long delays which had occurred in the past, it was decided to not delay a new release itself, even if packages for some of the supported platforms are still missing.

How to handle this if creating the missing packages would require changes to the released sources, I don't know.

I can always make a new release with Mac-specific changes only (0.48.5.1 or 0.48.6) - this is not a big problem.

I think it might be best to release 0.48.5 now, and once the improved OSX port is ready to go, release 0.48.6 as a specifically OSX-oriented release. What are your thoughts on this?

Regards, Krzysztof

---

Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On 2014-04-16 03:03 +0100, Krzysztof Kosiński wrote:

2014-04-15 21:05 GMT+02:00 su_v <suv-sf@...58...>:

...

1. Current packaging scripts in trunk and in the stable release branch

don't work to quickly produce a new X11-based package of 0.48.5. [1]

So it sounds like have to provide a Quartz build for OSX, right?

It's about time to switch to GTK+/Quartz builds: many Mac users really dislike having to install XQuartz, and to use X11-based applications. In my own experience GTK+/Quartz-based builds are usable - despite some backend-specific issues with the GUI and with canvas updates.

Canvas updates ================ Overall slowness and lagging as was described here: http://inkscape.13.x6.nabble.com/Inkscape-native-Mac-OS-X-build-look-improvements-tp2826961p2826975.html in my experience seems to have improved a lot during the past years (probably upstream in the Quartz backend of Gdk/Gtk), but isn't fully solved yet.

The application bundles based on the branch 'osxmenu' use this setting (in the bundle's Info.plist file): <key>CGDisableCoalescedUpdates</key> <true/> which helps for example to improve real-time updates which happen both on-canvas and in the status bar messages, e.g. when rotating a selection by dragging a rotation handle with the mouse.

Canvas updates are still delayed under these circumstances:

GTK2 and GTK3 Quartz backend: - hiding/showing GUI elements (menu 'View > Show/Hide') - toggling grid on/off (only if the rulers are hidden) - updating the selection cue and transformation handles (only if all GUI elements are hidden (Shift+F11)) GTK3 Quartz backend only: - scrolling, panning (space bar + pointer move, scrolling, Ctrl+Arrow keys) (not updated canvas areas show the solid background color from the gtk theme, instead of the (outdated) drawing content)

Symptom: a horizontal stripe of the visible canvas area (relative to the cursor position) is immediately updated, for the rest a manual "trigger" is required.

Actions which may trigger full canvas update: - moving the selection (edit) - hovering a visible GUI element (toolbar, dock) with the mouse pointer - switch focus to the controls bar (Alt+X) - scrolling / zooming (if rulers are visible) - updates in the status bar (if visible): Any key press which updates the message displayed in the status bar, any changes of the current mouse pointer position or of the zoom level (both are live-updated in the status bar).

Actions to trigger an update of sel cue / transformation handles: - hovering a transformation handle to highlight it - anything which updates the status bar (if visible) - hovering any visible part of the GUI outside canvas (works even with the minimized dock in 'Shift+F11' mode)

...

2. Creating new packages with GTK+/Quartz and better OS integration

requires changes in 'src' which need to be reviewed, fixed, or written (some are missing at the moment). [2]

What items are still missing and how long would it take to implement them?

-- Missing:

File name & location ==================== When using the global menubar, there is no way to find out the location of the currently opened document in the file system: - Inkscape trunk no longer displays the full path in the window title bar (not even after saving - the full path is now displayed as status bar message, and disappears quickly as soon as the notification area is updated). - The items in the 'File > Open recent' only display the file name, and the tooltips with the full path info are not shown if using the global osx menu bar (works ok if the menubar is docked in the document window, with either of the two available GTK+ backends on OS X).

Proposed partial solution: most native OS X application display a proxy icon in the window title bar of document windows, just in front of the file name, which - when clicked with the modifier 'alt/opt' pressed - displays a dropdown menu with the full path as list of folders: it allows to quickly open a file manager (Finder) window at the location of the document or one of the parent folders.

Sample code (C) in Gedit to implement such a proxy icon: https://git.gnome.org/browse/gedit/tree/gedit/gedit-app-osx.c#n99 Related documentation: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/WinPa...

I don't know a solution for displaying the full information for items in the 'File > Open recent' menu. For now, the information can be accessed via file chooser dialog (there the tooltips work ok for the items in the 'Recently Used' list).

Menu: layout ============ When using the global menu bar on OS X, the menu items for preferences and input devices need to be moved to the application menu (currently they are still in the 'Edit' menu, following the GNOME HIG).

Sample code in GIMP: https://git.gnome.org/browse/gimp/tree/app/gui/gui.c#n498

Should be easy to implement for someone with moderate C++ skills and familiar with Inkscape's methods to reference the menu itself and the individual menu items.

Menu: radio buttons in sub-menus ================================ Radio menu items in sub-menus are not updated on change, affects: View -> Display mode View -> Color Display mode

For the 'toolbar layout' choices ('View' menu, at the bottom), it works now by forcing an update of the global menu: http://bazaar.launchpad.net/~suv-lp/inkscape/osxmenu/view/head:/src/interface.cpp#L620 but I didn't figure out how to achieve the same for radio menu items in the sub-menus. Valerio Aimale's latest RC packages of 0.48.4 last year did solve this for the sub-menus too, but unfortunately the related code was never shared.

Menu: check buttons (trunk) =================== Check menu items don't sync with keyboard shortcuts (same verb): View > Page Grid View > Guides View > Color-managed View

Also happens when using Unity's global menubar: https://bugs.launchpad.net/inkscape/+bug/1136344

Wishlist ======== (nice to have, but not critical)

* context menu for the Dock icon * GUI option to change theme (gtk) and icons (inkscape)

-- Other known issues:

Clipboard (release critical) ========= For upstream GTK+/Quartz it was decided to preserve any clipboard content present at the time when the application quits, and the clipboard content is requested in all registered output formats from the application.

Many of Inkscape's output formats are script-based extensions. Not all of them are able to process the SVG file of the clipboard content without failure (either prompting an error message about missing layers, or failing to handle certain object types, or crashing because the document lacks expected attributes, e.g. document width and height). These error messages pop up after the user quit the application - depending on what was on the clipboard, there can be 5-10 of them, and each error message dialog has to be closed individually, otherwise the application does not quit.

https://bugs.launchpad.net/inkscape/+bug/1046068

Current osxmenu packages use workarounds in python modules and scripts for known issues with individual extensions (rather messy solution, doesn't work for externally maintained extensions).

Ideally I think this should be addressed internally, similar to how those error messages are suppressed if Inkscape is not used in GUI mode: https://bugs.launchpad.net/inkscape/+bug/1046068/comments/18

Window size ===========

The window position doesn't handle the vertical offset for the global menu bar correctly, which also results in not recording the 'Maximized' window state correctly. Annoying, but not critical: https://bugs.launchpad.net/inkscape/+bug/1302627

SVG Font editor =============== Not usable with GTK+/Quartz (crashes in stable and trunk): https://bugs.launchpad.net/inkscape/+bug/1116468

Based on what is mentioned in many inkscape-related tweets, blog posts and comments elsewhere, Inkscape's SVG font editor has gained a lot of popularity recently for creating custom (icon) fonts to be used in web design. It would be a pity to have the feature disabled for Mac users ...

Import Clipart ============== crash in stable: https://bugs.launchpad.net/inkscape/+bug/365567 fails in trunk: https://bugs.launchpad.net/inkscape/+bug/943148

Probably best to disable (hide from menu) for now.

It is unclear to me why the new GIO-based version of the import dialog in trunk fails on OS X - the same error can be reproduced with a sample application like "Gio Async Read Example" described here: http://www.micahcarrick.com/asynchronous-read-in-python-with-gio.html

Possibly related to missing packages (gvfs maybe), or some schemas (?) required by glib2, or indeed due to missing support for such async operations on OS X in Glib/GIO - I never was able to figure this out on my own.

I can review the code changes, but I have tons of stuff to do at the university, so I'm not sure how long it will take :/

Would it help if I post smaller diffs for changes in 'src' which are not restricted to GTK+/Quartz with #ifdef's (and thus might affect other platforms too); each with a brief summary?

(I know that the commit log the 'osxmenu' branch is rather messy, some changes occurred over several commits, or had later changes / reverts)

Regards, V

On 2014-04-16 22:37 +0100, Adam Strzelecki wrote:

There also one minor annoyance, but noticeable for Mac user. Inkscape should not quit when closing last window, but only when users explicitly close it via menu or Dock. Also when Inkscape has no documents open, clicking on Dock should open new empty document, otherwise it should bring up first open document. This is behavior found in most apps on Mac.

There is also interesting bug connected to issue above, using ⌘W (Close Window) when there is only one window immediately creates new document, rather than quitting or leaving Inkscape without documents open.

AFAIU Apple is changing the behavior of native applications wrt 'Termination of Apps', as mentioned in the related bug report: https://bugs.launchpad.net/inkscape/+bug/171935/comments/7

Personally, I would not consider this a release critical (certainly not for a bug-fix release of the current stable series, nor for upcoming major release 0.91) - Inkscape is not and won't ever be a "real" native OS X application (even with the Quartz backend of GTK+).

On Tue, Apr 15, 2014 at 12:53 PM, Krzysztof Kosiński <tweenk.pl@...2179......>wrote:

2014-04-15 16:04 GMT+02:00 Adam Strzelecki <ono@...1858...>:

...

Hello,

I was doing some fixing to OSX builds back in 2008. Now I came back to

see whazzup (since Inkscape is best SVG editor around) and had a chat with Valerio (su_v) yesterday.

...

Basically his builds are great improvement to what is there both in

trunk (OSX builds scripts) and X11 based builds experience.

...

Therefore I strongly encourage Inkscape maintainers to incorporate his

patches into Inkscape trunk and finally provide native OSX builds.

OK, I can merge these branches, though I can't test them as I have no access to OSX.

Great! I have now successfully compiled revision 13280 on my Mac ( I build with minimum OSX version 10.6.8) running Mavericks (no, I don't use Macport). I can test it for you.

Thanks, Partha