General state of OSX native?
Hi everybody,
I am currently trying to get inkscape running with gtk3/OSX-native. After quite a bit of struggling, I got everything compiled and executable. When I run inkscape, however, I get tons of assertions, the window looks terrible, is just barely responsive and completely unusable. The info on the web is not very conclusive, so I wonder:
* is inkscape OSX/native generally still in such a bad state or did I maybe not build it correctly? * is anyone working on this actively? * what is the state of inkscape/gtk3 in general? * What are the areas that require work to improve the situation? Perhaps, I could help out?
Generally, I used to use inkscape quite heavily several years ago on Linux and absolutely loved it. Today, I am forced to use OSX for work and would sometimes love to have inkscape available for some quick drawing task. The usability of the inkscape/gtk2/XQuark on OSX, however, has always put me off using inkscape altogether (booting Linux for every occasional quick drawing is just not an option). I would really love to see this situation improve.
Greetings, Norbert
You can get native OSX experimental builds from ~suv's branch though it's based on gtk2. I have also built it myself from her branch if you need.
On Sun, Dec 28, 2014 at 9:04 AM, Norbert Nemec <Norbert.Nemec.list@...173...> wrote:
Hi everybody,
I am currently trying to get inkscape running with gtk3/OSX-native. After quite a bit of struggling, I got everything compiled and executable. When I run inkscape, however, I get tons of assertions, the window looks terrible, is just barely responsive and completely unusable. The info on the web is not very conclusive, so I wonder:
- is inkscape OSX/native generally still in such a bad state or did I
maybe not build it correctly?
- is anyone working on this actively?
- what is the state of inkscape/gtk3 in general?
- What are the areas that require work to improve the situation?
Perhaps, I could help out?
Generally, I used to use inkscape quite heavily several years ago on Linux and absolutely loved it. Today, I am forced to use OSX for work and would sometimes love to have inkscape available for some quick drawing task. The usability of the inkscape/gtk2/XQuark on OSX, however, has always put me off using inkscape altogether (booting Linux for every occasional quick drawing is just not an option). I would really love to see this situation improve.
Greetings, Norbert
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 28/12/14 17:33 , schrieb Partha Bagchi:
You can get native OSX experimental builds from ~suv's branch though it's based on gtk2. I have also built it myself from her branch if you need.
Thanks, I will look into this.
Anyhow: It was my understanding that the native OSX support of gtk2 was fundamentally limited and that gtk3 promised significant improvements (not quite sure where I read this...)
Is it true that gtk3 support of inkscape is improving? Has anyone tried this on native OSX?
Greetings, Norbert
On 2014-12-28 15:04 (+0100), Norbert Nemec wrote:
I am currently trying to get inkscape running with gtk3/OSX-native. After quite a bit of struggling, I got everything compiled and executable. When I run inkscape, however, I get tons of assertions, the window looks terrible, is just barely responsive and completely unusable. The info on the web is not very conclusive, so I wonder:
Can't confirm with local inkscape trunk builds (I have bin compiling Inkscape trunk with experimental GTK3 on OS X 10.7.5 about since the time this is actually possible via configure option. Of the current local trunk builds (updated about once a week) with GTK+/X11 3.4.3, GTK+/Quartz 3.6.4, GTK+/X11 3.14.6 and GTK+/Quartz 3.14.6 (besides the regular GTK2 builds), not one exposes the issues you briefly described (to the point of being "completely unusable"). OTOH I would not have recommended experimental GTK3 builds for regular usage at this stage either (but they are more than "completely unusable" here, at least).
Minor detail: I never installed an unstable GTK3 release (or GTK+ from git master), and don't know the state of Inkscape trunk compiled and running with GTK+/Quartz 3.15.3 or master.
Independent of the used backend and platform, experimental GTK3 builds have still plenty of issues - a few have already been reported in the bug tracker: https://bugs.launchpad.net/inkscape/+bugs?field.tag=gtk3
- is inkscape OSX/native generally still in such a bad state or did I
maybe not build it correctly?
Can't really tell (no information about how you compiled trunk with experimental GTK3 on your Mac).
Based on my own limited experience, Inkscape packages compiled with GTK2/Quartz are not in _such_ a bad state in general (at least based on the user feedback for builds based on the 'osxmenu' branch [1]) - they aren't at release quality either though (Inkscape stable and trunk branches lack any OS X-specific integration code for the Quartz backend, and the updated macosx packaging scripts are still focused on creating an application bundle with GTK2/X11-based builds).
- is anyone working on this actively?
Inkscape trunk with GTK3 and Quartz backend specifically? Not that I am aware of.
- what is the state of inkscape/gtk3 in general?
- What are the areas that require work to improve the situation?
Perhaps, I could help out?
Inkscape with GTK3 in general is experimental and not "done" yet (yes, it compiles, but it seems to need a lot more work). This is no different for Inkscape with GTK3/Quartz on OS X. The official GTK+ version for Inkscape (stable, upcoming 0.91 and trunk) is still GTK2 at the moment, and AFAIK won't change in the near future.
Generally, I used to use inkscape quite heavily several years ago on Linux and absolutely loved it. Today, I am forced to use OSX for work and would sometimes love to have inkscape available for some quick drawing task. The usability of the inkscape/gtk2/XQuark on OSX, however, has always put me off using inkscape altogether (booting Linux for every occasional quick drawing is just not an option). I would really love to see this situation improve.
Too bad - you seem to dismiss any other option than GTK+/Quartz 3 for OS X. If this isn't quite true, you might want to give newer GTK2/X11-based app bundles a test, or even one with GTK2/Quartz. Links to downloads (OS X 10.7 or later) can be found on the download page at inkscape.org (0.91pre3, 0.91+devel)[2], and on my launchpad profile page [1] (including the experimental 'osxmenu' branch).
We also started an attempt to track osx packaging status in the wiki [3].
Regards, V
[1] https://code.launchpad.net/~suv-lp [2] http://inkscape.org/en/download/ [3] http://wiki.inkscape.org/wiki/index.php/Notes_on_Packaging_for_OS_X
On 2014-12-29 01:16 (+0100), su_v wrote:
Too bad - you seem to dismiss any other option than GTK+/Quartz 3 for OS X. If this isn't quite true, you might want to give newer GTK2/X11-based app bundles a test, or even one with GTK2/Quartz. Links to downloads (OS X 10.7 or later) can be found on the download page at inkscape.org (0.91pre3, 0.91+devel)[2], and on my launchpad profile page [1] (including the experimental 'osxmenu' branch).
We also started an attempt to track osx packaging status in the wiki [3].
(…)
Sorry, wrong link, use this one instead: [1] https://launchpad.net/~suv-lp
[2] http://inkscape.org/en/download/ [3] http://wiki.inkscape.org/wiki/index.php/Notes_on_Packaging_for_OS_X
Thanks! I just tried the gtk2/Quartz build from your profile and it really feels and looks much better than anything I have seen before on OSX.
The most recent gtk2/x11 build seems somewhat improved as well, but it still does not provide the smooth experience that I remember from Linux.
I really hope that the native-OSX (including osxmenu) will soon be stabilized sufficiently to have it considered for the official builds.
Greetings, Norbert
Am 29/12/14 1:20 , schrieb su_v:
On 2014-12-29 01:16 (+0100), su_v wrote:
Too bad - you seem to dismiss any other option than GTK+/Quartz 3 for OS X. If this isn't quite true, you might want to give newer GTK2/X11-based app bundles a test, or even one with GTK2/Quartz. Links to downloads (OS X 10.7 or later) can be found on the download page at inkscape.org (0.91pre3, 0.91+devel)[2], and on my launchpad profile page [1] (including the experimental 'osxmenu' branch).
We also started an attempt to track osx packaging status in the wiki [3].
(…)
Sorry, wrong link, use this one instead: [1] https://launchpad.net/~suv-lp
[2] http://inkscape.org/en/download/ [3] http://wiki.inkscape.org/wiki/index.php/Notes_on_Packaging_for_OS_X
I compiled osxmenu (~suv's branch) using gtk3 and it looks good to me.
It was a little tricky since configure is not set to automatically do this and gtk-mac-integration had to recompiled for gtk3.
If you wish to try it, let me know.
Thanks, Partha
On Tue, Dec 30, 2014 at 7:50 AM, Norbert Nemec <Norbert.Nemec.list@...173...> wrote:
Thanks! I just tried the gtk2/Quartz build from your profile and it really feels and looks much better than anything I have seen before on OSX.
The most recent gtk2/x11 build seems somewhat improved as well, but it still does not provide the smooth experience that I remember from Linux.
I really hope that the native-OSX (including osxmenu) will soon be stabilized sufficiently to have it considered for the official builds.
Greetings, Norbert
Am 29/12/14 1:20 , schrieb su_v:
On 2014-12-29 01:16 (+0100), su_v wrote:
Too bad - you seem to dismiss any other option than GTK+/Quartz 3 for OS X. If this isn't quite true, you might want to give newer GTK2/X11-based app bundles a test, or even one with GTK2/Quartz. Links to downloads (OS X 10.7 or later) can be found on the download page at inkscape.org (0.91pre3, 0.91+devel)[2], and on my launchpad profile page [1] (including the experimental 'osxmenu' branch).
We also started an attempt to track osx packaging status in the wiki [3].
(…)
Sorry, wrong link, use this one instead: [1] https://launchpad.net/~suv-lp
[2] http://inkscape.org/en/download/ [3] http://wiki.inkscape.org/wiki/index.php/Notes_on_Packaging_for_OS_X
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2015-01-05 01:27 (+0100), Partha Bagchi wrote:
I compiled osxmenu (~suv's branch) using gtk3 and it looks good to me.
It was a little tricky since configure is not set to automatically do this
Inkscape with GTK3 is still at an experimental stage, hence it needs to be enabled intentionally (not automatically) by running configure with the corresponding option to enable it; for details see
$ ./configure --help | grep -A 1 gtk3
and gtk-mac-integration had to recompiled for gtk3.
1) gtk-mac-integration IMvHO is not the best plan to pursue for porting Inkscape GTK3 to OS X (as explained on the osxmenu branch page).
2) GTK3 offers built-in features to support the global menu bar on OS X - a future Inkscape GTK3 on OS X ought to make use of those gtk3-native features instead of relying on a third-part library which will not be maintained for GTK3 (even if it might work with current GTK3 releases). This will require some major refactoring in Inkscape though AFAIU (way beyond what I personally ever could look into).
3) The osxmenu branch was never compiled locally with GTK3 + gtk-mac-integration (configured with '--with-gtk=gtk+-3.0') for exactly this reason (I rather spent time on the GTK2 port, where OS X integration requires this external library), so I don't know how the modifications in 'src/' might affect the build if linked with gtk-mac-integration for gtk3. Adding support to the packaging scripts for a self-contained fully relocatable osxmenu app bundle based on GTK3 has not been worked on [1].
If you wish to try it, let me know.
Would you mind sharing details on your build environment, and your custom packaging scripts [2]? Do you use the same "symbolic links in /tmp"-hack for your Inkscape packages to achieve some kind of relocation support as in your McGIMP packages?
Regards, V
[1] AFAICT GTK3 adds requirements (e.g. a full icon theme (-> download size), more session daemons, etc.). One example: I never got the predefined 'Recent' bookmark in the GTK3 file chooser working without running a session dbus and gvfsd (configured with gtk support enabled). We already need these two daemons (gvfs configured with http support enabled) for the openclipart import, but that's more of an optional feature compared to being able to access the most recently used files in the file chooser.
[2] ideally by sharing a link to a repository/branch which includes the custom scripts
Thanks, Partha
On Tue, Dec 30, 2014 at 7:50 AM, Norbert Nemec <Norbert.Nemec.list@...173...> wrote:
Thanks! I just tried the gtk2/Quartz build from your profile and it really feels and looks much better than anything I have seen before on OSX.
The most recent gtk2/x11 build seems somewhat improved as well, but it still does not provide the smooth experience that I remember from Linux.
I really hope that the native-OSX (including osxmenu) will soon be stabilized sufficiently to have it considered for the official builds.
Greetings, Norbert
Am 29/12/14 1:20 , schrieb su_v:
On 2014-12-29 01:16 (+0100), su_v wrote:
Too bad - you seem to dismiss any other option than GTK+/Quartz 3 for OS X. If this isn't quite true, you might want to give newer GTK2/X11-based app bundles a test, or even one with GTK2/Quartz. Links to downloads (OS X 10.7 or later) can be found on the download page at inkscape.org (0.91pre3, 0.91+devel)[2], and on my launchpad profile page [1] (including the experimental 'osxmenu' branch).
We also started an attempt to track osx packaging status in the wiki [3].
(…)
Sorry, wrong link, use this one instead: [1] https://launchpad.net/~suv-lp
[2] http://inkscape.org/en/download/ [3] http://wiki.inkscape.org/wiki/index.php/Notes_on_Packaging_for_OS_X
First of all, thank you for providing the source so that one can build a native OSX Inkscape. I wish your work was already merged into trunk!!
On Mon, Jan 5, 2015 at 9:05 AM, su_v <suv-sf@...58...> wrote:
On 2015-01-05 01:27 (+0100), Partha Bagchi wrote:
I compiled osxmenu (~suv's branch) using gtk3 and it looks good to me.
It was a little tricky since configure is not set to automatically do this
Inkscape with GTK3 is still at an experimental stage, hence it needs to be enabled intentionally (not automatically) by running configure with the corresponding option to enable it; for details see
$ ./configure --help | grep -A 1 gtk3
Yes I am aware of using --enable-gtk3-experimental during configure. Is that what you mean? You cannot build with gtk3 without this. Anyway, building with simply gtk3 does not enable any OSX menu features. You are left with a build that is similar to an XQuartz build.
and gtk-mac-integration had to recompiled for gtk3.
- gtk-mac-integration IMvHO is not the best plan to pursue for porting
Inkscape GTK3 to OS X (as explained on the osxmenu branch page).
I agree with you but see above. Without gtk-mac-integration, I could not get any of the menus to show up in the menubar.
- GTK3 offers built-in features to support the global menu bar on OS X
- a future Inkscape GTK3 on OS X ought to make use of those gtk3-native
features instead of relying on a third-part library which will not be maintained for GTK3 (even if it might work with current GTK3 releases). This will require some major refactoring in Inkscape though AFAIU (way beyond what I personally ever could look into).
Agree.
- The osxmenu branch was never compiled locally with GTK3 +
gtk-mac-integration (configured with '--with-gtk=gtk+-3.0') for exactly this reason (I rather spent time on the GTK2 port, where OS X integration requires this external library), so I don't know how the modifications in 'src/' might affect the build if linked with gtk-mac-integration for gtk3. Adding support to the packaging scripts for a self-contained fully relocatable osxmenu app bundle based on GTK3 has not been worked on [1].
If you wish to try it, let me know.
Would you mind sharing details on your build environment, and your custom packaging scripts [2]? Do you use the same "symbolic links in /tmp"-hack for your Inkscape packages to achieve some kind of relocation support as in your McGIMP packages?
Yes, I use the same "hack" whereby I mount the library system on tmp. This way you can launch the App from anywhere you like. From my various readings, using @executable_path is also considered a no-no which is what some other Apps seem to use.
You can download my build from http://www.partha.com/temp/Inkscape-gtk3-osx.app.zip. The script is of course embedded in the build.
Would you prefer that I provide the script separately? I can also provide my build environment if you wish.
Thanks, Partha
Regards, V
[1] AFAICT GTK3 adds requirements (e.g. a full icon theme (-> download size), more session daemons, etc.). One example: I never got the predefined 'Recent' bookmark in the GTK3 file chooser working without running a session dbus and gvfsd (configured with gtk support enabled). We already need these two daemons (gvfs configured with http support enabled) for the openclipart import, but that's more of an optional feature compared to being able to access the most recently used files in the file chooser.
[2] ideally by sharing a link to a repository/branch which includes the custom scripts
Thanks, Partha
On Tue, Dec 30, 2014 at 7:50 AM, Norbert Nemec <Norbert.Nemec.list@...173...> wrote:
Thanks! I just tried the gtk2/Quartz build from your profile and it really feels and looks much better than anything I have seen before on OSX.
The most recent gtk2/x11 build seems somewhat improved as well, but it still does not provide the smooth experience that I remember from Linux.
I really hope that the native-OSX (including osxmenu) will soon be stabilized sufficiently to have it considered for the official builds.
Greetings, Norbert
Am 29/12/14 1:20 , schrieb su_v:
On 2014-12-29 01:16 (+0100), su_v wrote:
Too bad - you seem to dismiss any other option than GTK+/Quartz 3 for OS X. If this isn't quite true, you might want to give newer GTK2/X11-based app bundles a test, or even one with GTK2/Quartz. Links to downloads (OS X 10.7 or later) can be found on the download page at inkscape.org (0.91pre3, 0.91+devel)[2], and on my launchpad profile page [1] (including the experimental 'osxmenu' branch).
We also started an attempt to track osx packaging status in the wiki [3].
(…)
Sorry, wrong link, use this one instead: [1] https://launchpad.net/~suv-lp
[2] http://inkscape.org/en/download/ [3] http://wiki.inkscape.org/wiki/index.php/Notes_on_Packaging_for_OS_X
On 2015-01-05 19:40 (+0100), Partha Bagchi wrote:
Would you mind sharing details on your build environment, and your custom packaging scripts [2]? Do you use the same "symbolic links in /tmp"-hack for your Inkscape packages to achieve some kind of relocation support as in your McGIMP packages?
Yes, I use the same "hack" whereby I mount the library system on tmp. This way you can launch the App from anywhere you like. From my various readings, using @executable_path is also considered a no-no which is what some other Apps seem to use.
Just curious: Any official sources for this statement ("@executable_path is also considered a no-no")?
The "no-no" I'm aware of is using '$DYLD_LIBRARY_PATH' in deployed software (i.e. outside of development and testing environments) instead of making the effort to rewrite the library paths with install_name_tool [1].
Regards, V
[1] install_name_tool is part of the cctools (installed with Xcode), see http://www.opensource.apple.com/source/cctools/cctools-862/misc/install_name...
@executable_path and @loader_path are described on the man page of dyld: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPa...
Well, I was doing some reading when I started to learn about building on a Mac. So, my knowledge is limited and/or out dated.
If you look at the above references, then I think the preference is to use the macro @loader_path rather than @executable_path due to mechanism of resolution of these macros. As or 10.5, I think you would want to use @rpath.
However, as I said, I utilize the /tmp folder which is always available and mounting and u-mounting the framerwork at /tmp does not include any name clashes and allows me to locate the App anywhere. Moreover, I don't have to content with build processes where the prefix is "a-very-very-long-path-that-I-can-modify-with_install_name_tool" and contend with headerpad_max_install_names though I still use header padding as a matter of routine.
Finally, I make no claims about being an expert in any of these and purely do this as a hobby in an effort to learn about the Mac system.
Thanks, Partha
On Mon, Jan 5, 2015 at 2:50 PM, su_v <suv-sf@...58...> wrote:
On 2015-01-05 19:40 (+0100), Partha Bagchi wrote:
Would you mind sharing details on your build environment, and your custom packaging scripts [2]? Do you use the same "symbolic links in /tmp"-hack for your Inkscape packages to achieve some kind of relocation support as in your McGIMP packages?
Yes, I use the same "hack" whereby I mount the library system on tmp. This way you can launch the App from anywhere you like. From my various readings, using @executable_path is also considered a no-no which is what some other Apps seem to use.
Just curious: Any official sources for this statement ("@executable_path is also considered a no-no")?
The "no-no" I'm aware of is using '$DYLD_LIBRARY_PATH' in deployed software (i.e. outside of development and testing environments) instead of making the effort to rewrite the library paths with install_name_tool [1].
Regards, V
[1] install_name_tool is part of the cctools (installed with Xcode), see http://www.opensource.apple.com/source/cctools/cctools-862/misc/install_name...
@executable_path and @loader_path are described on the man page of dyld: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPa...
On 2015-01-05 19:40 (+0100), Partha Bagchi wrote:
On Mon, Jan 5, 2015 at 9:05 AM, su_v <suv-sf@...58...> wrote:
On 2015-01-05 01:27 (+0100), Partha Bagchi wrote:
I compiled osxmenu (~suv's branch) using gtk3 and it looks good to me.
It was a little tricky since configure is not set to automatically do this
Inkscape with GTK3 is still at an experimental stage, hence it needs to be enabled intentionally (not automatically) by running configure with the corresponding option to enable it; for details see
$ ./configure --help | grep -A 1 gtk3
Yes I am aware of using --enable-gtk3-experimental during configure. Is that what you mean? You cannot build with gtk3 without this. Anyway, building with simply gtk3 does not enable any OSX menu features. You are left with a build that is similar to an XQuartz build.
I have just pushed a change to the osxmenu branch (r12890) to support compiling the branch with experimental GTK3 and gtk-mac-integration (if installed for gtk3) with these two configure flags (there should be no further changes required):
$ ./configure --enable-gtk3-experimental --enable-macintegration
I'm still convinced that Inkscape GTK3 OS X ports should _not_ use the external library 'gtk-mac-integration' for the global menubar and other features (and that instead Inkscape should be refactored so that the application can make use of the new built-in features of GTK3 for such integration tasks (on all supported gtk+ targets)).
Regards, V
On Mon, Jan 5, 2015 at 5:57 PM, su_v <suv-sf@...58...> wrote:
On 2015-01-05 19:40 (+0100), Partha Bagchi wrote:
On Mon, Jan 5, 2015 at 9:05 AM, su_v <suv-sf@...58...> wrote:
On 2015-01-05 01:27 (+0100), Partha Bagchi wrote:
I compiled osxmenu (~suv's branch) using gtk3 and it looks good to me.
It was a little tricky since configure is not set to automatically do this
Inkscape with GTK3 is still at an experimental stage, hence it needs to be enabled intentionally (not automatically) by running configure with the corresponding option to enable it; for details see
$ ./configure --help | grep -A 1 gtk3
Yes I am aware of using --enable-gtk3-experimental during configure. Is that what you mean? You cannot build with gtk3 without this. Anyway, building with simply gtk3 does not enable any OSX menu features. You are left with a build that is similar to an XQuartz build.
I have just pushed a change to the osxmenu branch (r12890) to support compiling the branch with experimental GTK3 and gtk-mac-integration (if installed for gtk3) with these two configure flags (there should be no further changes required):
$ ./configure --enable-gtk3-experimental --enable-macintegration
I'm still convinced that Inkscape GTK3 OS X ports should _not_ use the external library 'gtk-mac-integration' for the global menubar and other features (and that instead Inkscape should be refactored so that the application can make use of the new built-in features of GTK3 for such integration tasks (on all supported gtk+ targets)).
Regards, V
We're totally aligned on this. However, John Rall's comment about gtk3 (https://wiki.gnome.org/Projects/GTK+/OSX/Integration) says, "Gtk+-3.4 added built-in quartz menu integration without documentation."
I don't know if the documentation has improved or not, though on the Mac I am using 3.14.6 and not the 3.15.x branch because of the new dependence on xlib!
Thanks, Partha
participants (3)
-
Norbert Nemec -
Partha Bagchi -
su_v