Roadmap for Inkscape 0.93 on Windows - GTK3, devlibs, MSYS2 and support for Windows XP
Hi all,
one of the biggest changes in current trunk is the switch to gtk3.
As some of you already know this step will be a hard one on Windows as we have to rely on pre-built development libraries to be able to compile Inkscape:
* devlibs currently has no support for gtk3 at all. (There's an experimental branch on which jazzynico was working, but as far as I know he was never able to complete it due to build issues) * devlibs64 includes gtk3 3.19.6 but IMHO it's pretty broken and would require *a lot* of work to get anywhere near being usable
As a result we're currently not able to build Inkscape for 32-bit Windows at all (bug 1609954 [1]) and builds with devlibs64 are nowhere close to be usable.
*Therefore I want to propose to switch to MSYS2 for compiling Inkscape trunk on Windows!*
MSYS2 is a rewrite of MSYS including all the necessary build tools to compile native applications for Windows using mingw-w64 (see official homepage [2] for details). Furthermore it includes the package manager "pacman" (users of Arch Linux will know it) which allows to conveniently install and upgrade packages.
The switch would have a *lot* of advantages:
* Easier setup of the build system as gcc and all necessary build tools and libraries are included in MSYS2 (currently we require to download gcc + devlibs + cmake separately and procedure varies widely between 32-bit and 64-bit builds) * A solid set of constantly updated libraries (see [3]). * Packages are usually built with a small set of patches to fix compatibility errors on Windows that would otherwise require hours to figure out when building libraries from scratch. * An active developer community. Questions are answered swiftly, bugs in the provided libraries can usually be figured out jointly. * Creating new packages (if it should ever be required) or recompiling existing packages (i.e. to test a fix) is extremely easy. (I recently added libvisio [4] which was the only dependency of Inkscape not yet provided) * 32-bit and 64-bit builds are equivalent. The exact same library versions are used and MSYS2 includes build environments for both that co-exist by default
I'm already successfully building current trunk with MSYS2 without any issues at all (there are no code changes needed, only environment variables have to be adjusted and the CMake install target has to be adjusted to pick up the correct libraries). If you're interested you can find the latest builds at [5] (the most obvious change is the Adwaita theme that is now used by gtk3 by default but doesn't look very native. However that's something we can customize going forward as desired).
There's one big downside: My builds currently don't work on Windows XP. However I'm afraid this has nothing to do with MSYS2. Many libraries have started to drop support for Windows XP, most importantly gtk3 does not support it after 3.16 [6]. This means we have two possibilites:
* Drop support for Windows XP in Inkscape 0.93 * Try our best to somehow (currently I have no idea how!) continue support for Windows XP. This would most likely require us to keep building, maintaining and distributing our own development libraries (however I guess even here MSYS2 would be a huge help). While achieving this might sound favourable keep in mind that it would require us to limit ourselves to old library versions on purpose with all the inevitable downsides like unfixed bugs and growing number of incompatibilities in newer OSs.
I thought about this for some time now and although it was not an easy decision I'd vote for the first option. I know people still use Windows XP in productive environments (I have an old Windows XP server running myself - shame on me) but to be realistic it's time to move on. Support for XP ended a long time ago, it's insecure and there's only very few cases where people are actually bound to XP for other reasons than convenience. Weighing all the pros and cons I'd say the pros clearly prevail!
*So: Let me know what you think!* Does a switch to MSYS2 as build system sound reasonable to you? Is Windows XP support something we have to keep even if it means a huge amount of additional effort and requires us to limit ourselves on newer platforms on purpose?
Looking forward to you thoughts, Eduard
[1] https://bugs.launchpad.net/bugs/1609954 [2] http://www.msys2.org/ [3] https://github.com/Alexpux/MINGW-packages [4] https://github.com/Alexpux/MINGW-packages/pull/2194 [5] http://download.tuxfamily.org/inkscape/win64/ [6] https://github.com/GNOME/gtk/blob/24483481c1eaa6e3bad9f158e2d4d3ef21505d9b/N...
Le 26/02/2017 à 01:05, Eduard Braun a écrit :
there's only very few cases where people are actually bound to XP for other reasons than convenience.
I’m not sure of what you mean, but I think many professionals still have to use Windows XP because nobody is available/paid/skilled for installing something else, e.g. in hospitals (I’ve also heard the case about Windows 98).
Hopefully, the people who really need Inkscape 0.93 will be able to install a libre OS instead of Windows XP.
Regards, -- Sylvain
And, there are people who are really reluctant to move beyond Windows XP, or are stuck with old computers. In a ideal world, if one is to stick with XP, one would use in a virtual machine in newer computers, but that's not the world we live in. Dropping the support would be the right solution for .93 and beyond. There's no reason to use XP other than legacy gaming or legacy software support.
On 2/26/2017 9:38 AM, Sylvain Chiron wrote:
Le 26/02/2017 à 01:05, Eduard Braun a écrit :
there's only very few cases where people are actually bound to XP for other reasons than convenience.
I’m not sure of what you mean, but I think many professionals still have to use Windows XP because nobody is available/paid/skilled for installing something else, e.g. in hospitals (I’ve also heard the case about Windows 98).
Hopefully, the people who really need Inkscape 0.93 will be able to install a libre OS instead of Windows XP.
Regards,
Sylvain
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
If they are still on XP, they can still use older builds of Inkscape. People stuck on XP must surely be used to new software not working on their old deprecated OS by now.
On 27 Feb 2017 12:07 a.m., "Miguel Lopez" <reptillia39@...3425...> wrote:
And, there are people who are really reluctant to move beyond Windows XP, or are stuck with old computers. In a ideal world, if one is to stick with XP, one would use in a virtual machine in newer computers, but that's not the world we live in. Dropping the support would be the right solution for .93 and beyond. There's no reason to use XP other than legacy gaming or legacy software support.
On 2/26/2017 9:38 AM, Sylvain Chiron wrote:
Le 26/02/2017 à 01:05, Eduard Braun a écrit :
there's only very few cases where people are actually bound to XP for other reasons than convenience.
I’m not sure of what you mean, but I think many professionals still have to use Windows XP because nobody is available/paid/skilled for installing something else, e.g. in hospitals (I’ve also heard the case about Windows 98).
Hopefully, the people who really need Inkscape 0.93 will be able to install a libre OS instead of Windows XP.
Regards,
Sylvain
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R wrote
People stuck on XP must surely be used to new software not working on their old deprecated OS by now.
I agree, this is true. But the problem with Inskcape is that its last 32 bit version is not perfect. So IMO the point is not in new features (new software), but in at least fixing what still needs to in the current 32 bit software.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Roadmap-for-Inkscape-0-93-on-Windows-GTK3-d... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On the other hand, having a development-free branch devoted to bug fixing only could be highly beneficial for trunk where often big efforts are spent on introducing new features and not as many on fixing all the messes that come after them. I assume that for some time (up to the "last active support date" for 32 bit?) the bugs of the two branches are going to be pretty the same; or at least the bugs in the semi-frozen 32 bit branch are going to be present in trunk (not necessarily the opposite because of the new features). So much of the work is going to pay twice.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Roadmap-for-Inkscape-0-93-on-Windows-GTK3-d... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Inkscape is so far from bug free at the moment that it's not even worth worrying about having the upgrade if just counting bugs. :)
Support for XP ended in 2015, which means there have not been security updates from Microsoft in nearly two years...
Unfortunately, XP is not a good OS anymore, as a primary feature of a good OS is updates and support. It's dangerous to use closed source OSs past the support life, because the only company that has access to the code has stopped modifying it.
Imho, we should not be encouraging XP users to stay on XP, or any OS that is no longer supported by the community, or by the software corporation whence it came.
This includes dead distros of Open Source OSs too, such as CrunchBang Linux, etc. We should encourage migration to other platforms, and the project focus on fixing bugs there.
-C
On 27 Feb 2017 9:59 a.m., "LucaDC" <dicappello@...2144...> wrote:
C R wrote
People stuck on XP must surely be used to new software not working on their old deprecated OS by now.
I agree, this is true. But the problem with Inskcape is that its last 32 bit version is not perfect. So IMO the point is not in new features (new software), but in at least fixing what still needs to in the current 32 bit software.
Luca
-- View this message in context: http://inkscape.13.x6.nabble. com/Roadmap-for-Inkscape-0-93-on-Windows-GTK3-devlibs-MSYS2- and-support-for-Windows-XP-tp4979046p4979060.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R wrote
Imho, we should not be encouraging XP users to stay on XP, or any OS that is no longer supported by the community, or by the software corporation whence it came.
Sorry but I can't agree. This is always the same story: just say you don't want to help people who have a problem, don't try to convince them that they don't have it because you don't have any right to say so. If someone says he's stuck with Windows XP, why questioning on this? Just take it for granted and start from there.
C R wrote
Unfortunately, XP is not a good OS anymore, as a primary feature of a good OS is updates and support. It's dangerous to use closed source OSs past the support life, because the only company that has access to the code has stopped modifying it.
I don't agree on this too. Why should a system not connected to internet be unsafe without updates? On the contrary: I wouldn't update any working system where everything works fine and nothing needs being fixed. There's no real danger in keeping using some piece of software that works as is. I really don't feel the urge of always using the very last release of every software I have, unless I need some new feature. On the contrary: I see more danger in updating something that works when I don't need to.
In some environments, primary features of a good OS are its size, its resource requirements and deep knowledge of it gained with years of experience, not update nor support as you don't need them if the system is already well tested and approved.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Roadmap-for-Inkscape-0-93-on-Windows-GTK3-d... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On Mon, 2017-02-27 at 11:13 -0700, LucaDC wrote:
C R wrote
Imho, we should not be encouraging XP users to stay on XP, or any
OS that
is no longer supported by the community, or by the software
corporation
whence it came.
Sorry but I can't agree. This is always the same story: just say you don't want to help people who have a problem, don't try to convince them that they don't have it because you don't have any right to say so. If someone says he's stuck with Windows XP, why questioning on this? Just take it for granted and start from there.
We can actually argue a deeper moral sense about what is encouraging self harm and what is helping to serve user needs.
what CR is trying to say is that it may be morally dubious to increase windows XPs functionality at this stage. To do so suggests that using windows XP with new releases is safe and fair, and it's not safe or fair.
It's hard to say no sometimes. But in this case we're asking the project to spend a lot of time and effort helping people to continue to hurt themselves. I agree with CR here about the harms.
I say no to XP support. The project has enough to fix without supporting a dead operating system. Even if that no means letting users down and forcing them to upgrade their OS or stick with older Inkscape versions.
Best Regards, Martin Owens
- Beaten dead horse removal service
Missed the point of everything I said. It's not about helping or not helping, it's about supporting things that are a danger to users. See for example how many XP machines are currently used in botnet attacks.
I also mentioned running XP in a VM to this user, so I'm clearly not against helping. :)
-C
On 27 Feb 2017 6:15 p.m., "LucaDC" <dicappello@...2144...> wrote:
C R wrote
Imho, we should not be encouraging XP users to stay on XP, or any OS that is no longer supported by the community, or by the software corporation whence it came.
Sorry but I can't agree. This is always the same story: just say you don't want to help people who have a problem, don't try to convince them that they don't have it because you don't have any right to say so. If someone says he's stuck with Windows XP, why questioning on this? Just take it for granted and start from there.
C R wrote
Unfortunately, XP is not a good OS anymore, as a primary feature of a good OS is updates and support. It's dangerous to use closed source OSs past the support life, because the only company that has access to the code has stopped modifying it.
I don't agree on this too. Why should a system not connected to internet be unsafe without updates? On the contrary: I wouldn't update any working system where everything works fine and nothing needs being fixed. There's no real danger in keeping using some piece of software that works as is. I really don't feel the urge of always using the very last release of every software I have, unless I need some new feature. On the contrary: I see more danger in updating something that works when I don't need to.
In some environments, primary features of a good OS are its size, its resource requirements and deep knowledge of it gained with years of experience, not update nor support as you don't need them if the system is already well tested and approved.
Luca
-- View this message in context: http://inkscape.13.x6.nabble. com/Roadmap-for-Inkscape-0-93-on-Windows-GTK3-devlibs-MSYS2- and-support-for-Windows-XP-tp4979046p4979071.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
If they are still on XP, they can still use older builds of Inkscape.
People stuck on XP must surely be used to new software not working on their old deprecated OS by now.
Actually in my experience the situation is the exact opposite. Windows 10 has not offered me access to any new software that is of any interest to me. Instead it has forced me to abandon two old, legacy, pieces of software that I had used daily for about 15 years on XP, and now can no longer use because they are 16 bit software. So the switch to Windows 10 has been a significant step backwards in terms of functionality and in terms of user-friendliness. Windows 10 is incredibly unfriendly when it comes to simple things like copying files, and it is full of bugs and glitches. I upgraded to Windows 10 because I was literally forced to do so, not because I wanted to, and certainly not because it offered me anything that I was actually interested in.
Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Roadmap-for-Inkscape-0-93-on-Windows-GTK3-d... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Hi Alvin. I get your point but to be honest I think that the step from Windows XP to Windows 10 is so wide that it is quite likely to cause troubles. For this reason I don't find it a good example to oppose to what C R was saying.
In my experience, the main problem when moving between OSs has been finding the drivers for (very) old external hardware. I've solved it virtualizing my old XP machine in my new OS: it's effective and gives you the advantages of working with very powerful new hardware using old trusted tools. I'd suggest you try it if you can or are allowed to.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Roadmap-for-Inkscape-0-93-on-Windows-GTK3-d... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
I'm one of those still using Windows XP in my working environment. I'd just share my point of view in case it's useful to take a decision. I both use Inkscape under Windows 7 (64 bit) and Windows XP (32 bit). Knowing that support on Windows XP is ceasing makes me sad because I think it's a good OS. But facing reality, it's not believable that people are going to make huge efforts to keep alive a system that is now inevitably fixed to his last development stage and will not improve anymore.
Nevertheless, I'd like at least to be able to continue using what's still working on it.
So my proposal would be to drop compatibility with Windows XP for current development (sigh!) but keep fixing bugs in the last working 32 bit tree (and maybe some simple backport of what can be done without too much difficulty, but not necessarily). Having all the current features of Inskcape will require a 64 bit system, but people "stuck" to Windows XP systems could still benefit of a form of active support, even if reduced to fixing bugs.
My probably limited knowledge pairs 32 bit with Windows XP. So from my point of view, dropping XP equals dropping active 32 bit development. I don't know if there are other 32 bit systems around actively supported that makes keeping 32 bit compatibility in current trunk desirable and worth it.
Hence, in few words: trunk 64 bit only for active development and last 32 bit working version actively kept bug free but not developed anymore. It could be convenient to set a "last active support date" for this 32 bit semi-frozen branch.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Roadmap-for-Inkscape-0-93-on-Windows-GTK3-d... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
I'm not a developer, and this is not an opinion on the matter. But I was curious how many people might still be using XP. I searched and found this (dated before end of support date)
https://www.cnet.com/news/microsofts-windows-xp-is-still-kickin-do-you-use-i...
And this almost a year after end of support
http://www.techrepublic.com/article/windows-xp-use-declining-but-millions-st...
All best, brynn
-----Original Message----- From: Eduard Braun Sent: Saturday, February 25, 2017 5:05 PM To: inkscape-devel Subject: [Inkscape-devel] Roadmap for Inkscape 0.93 on Windows - GTK3, devlibs, MSYS2 and support for Windows XP
Hi all,
one of the biggest changes in current trunk is the switch to gtk3.
As some of you already know this step will be a hard one on Windows as we have to rely on pre-built development libraries to be able to compile Inkscape:
devlibs currently has no support for gtk3 at all. (There's an experimental branch on which jazzynico was working, but as far as I know he was never able to complete it due to build issues)
devlibs64 includes gtk3 3.19.6 but IMHO it's pretty broken and would require *a lot* of work to get anywhere near being usable
As a result we're currently not able to build Inkscape for 32-bit Windows at all (bug 1609954 [1]) and builds with devlibs64 are nowhere close to be usable.
Therefore I want to propose to switch to MSYS2 for compiling Inkscape trunk on Windows!
MSYS2 is a rewrite of MSYS including all the necessary build tools to compile native applications for Windows using mingw-w64 (see official homepage [2] for details). Furthermore it includes the package manager "pacman" (users of Arch Linux will know it) which allows to conveniently install and upgrade packages.
The switch would have a *lot* of advantages:
Easier setup of the build system as gcc and all necessary build tools and libraries are included in MSYS2 (currently we require to download gcc + devlibs + cmake separately and procedure varies widely between 32-bit and 64-bit builds)
A solid set of constantly updated libraries (see [3]). Packages are usually built with a small set of patches to fix compatibility errors on Windows that would otherwise require hours to figure out when building libraries from scratch.
An active developer community. Questions are answered swiftly, bugs in the provided libraries can usually be figured out jointly. Creating new packages (if it should ever be required) or recompiling existing packages (i.e. to test a fix) is extremely easy. (I recently added libvisio [4] which was the only dependency of Inkscape not yet provided) 32-bit and 64-bit builds are equivalent. The exact same library versions are used and MSYS2 includes build environments for both that co-exist by default
I'm already successfully building current trunk with MSYS2 without any issues at all (there are no code changes needed, only environment variables have to be adjusted and the CMake install target has to be adjusted to pick up the correct libraries). If you're interested you can find the latest builds at [5] (the most obvious change is the Adwaita theme that is now used by gtk3 by default but doesn't look very native. However that's something we can customize going forward as desired).
There's one big downside: My builds currently don't work on Windows XP. However I'm afraid this has nothing to do with MSYS2. Many libraries have started to drop support for Windows XP, most importantly gtk3 does not support it after 3.16 [6]. This means we have two possibilites:
Drop support for Windows XP in Inkscape 0.93 Try our best to somehow (currently I have no idea how!) continue support for Windows XP. This would most likely require us to keep building, maintaining and distributing our own development libraries (however I guess even here MSYS2 would be a huge help). While achieving this might sound favourable keep in mind that it would require us to limit ourselves to old library versions on purpose with all the inevitable downsides like unfixed bugs and growing number of incompatibilities in newer OSs.
I thought about this for some time now and although it was not an easy decision I'd vote for the first option. I know people still use Windows XP in productive environments (I have an old Windows XP server running myself - shame on me) but to be realistic it's time to move on. Support for XP ended a long time ago, it's insecure and there's only very few cases where people are actually bound to XP for other reasons than convenience. Weighing all the pros and cons I'd say the pros clearly prevail!
So: Let me know what you think! Does a switch to MSYS2 as build system sound reasonable to you? Is Windows XP support something we have to keep even if it means a huge amount of additional effort and requires us to limit ourselves on newer platforms on purpose?
Looking forward to you thoughts, Eduard
[1] https://bugs.launchpad.net/bugs/1609954 [2] http://www.msys2.org/ [3] https://github.com/Alexpux/MINGW-packages [4] https://github.com/Alexpux/MINGW-packages/pull/2194 [5] http://download.tuxfamily.org/inkscape/win64/ [6] https://github.com/GNOME/gtk/blob/24483481c1eaa6e3bad9f158e2d4d3ef21505d9b/N...
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
OK, I'm afraid I started something I did not intend to...
To clarify:
* The intent of my message was *not* to discuss whether people still use Windows XP (they do, I know) and it was *not* to discuss if we still want to support Windows XP (we want, if it's possible). * The intent of my message was to discuss possible ways forward regarding the switch to gtk3 in trunk. (Please be aware that this discussion is only about trunk [!] and what will become Inkscape 0.93. Inkscape 0.92 will be unaffected and can be seen as a LTS branch that will always work on Windows XP!)
So regarding Windows XP: Right now I have no idea *how* to support Windows XP in current trunk. Therefore, unless you know of ways how we *can* support Windows XP in trunk there's absolutely no point in discussing whether we want to! This is a purely technical question at this point and has nothing to do with our personal wishes!
Meanwhile my personal focus was actually on the MSYS2 part (on which nobody commented so far) and therefore I hope we can bring this discussion back on track (this is the devel list - not the user list!).
Regards, Eduard
Am 26.02.2017 um 01:05 schrieb Eduard Braun:
Hi all,
one of the biggest changes in current trunk is the switch to gtk3.
As some of you already know this step will be a hard one on Windows as we have to rely on pre-built development libraries to be able to compile Inkscape:
- devlibs currently has no support for gtk3 at all. (There's an experimental branch on which jazzynico was working, but as far as I know he was never able to complete it due to build issues)
- devlibs64 includes gtk3 3.19.6 but IMHO it's pretty broken and would require *a lot* of work to get anywhere near being usable
As a result we're currently not able to build Inkscape for 32-bit Windows at all (bug 1609954 [1]) and builds with devlibs64 are nowhere close to be usable.
*Therefore I want to propose to switch to MSYS2 for compiling Inkscape trunk on Windows!*
MSYS2 is a rewrite of MSYS including all the necessary build tools to compile native applications for Windows using mingw-w64 (see official homepage [2] for details). Furthermore it includes the package manager "pacman" (users of Arch Linux will know it) which allows to conveniently install and upgrade packages.
The switch would have a *lot* of advantages:
- Easier setup of the build system as gcc and all necessary build tools and libraries are included in MSYS2 (currently we require to download gcc + devlibs + cmake separately and procedure varies widely between 32-bit and 64-bit builds)
- A solid set of constantly updated libraries (see [3]).
- Packages are usually built with a small set of patches to fix compatibility errors on Windows that would otherwise require hours to figure out when building libraries from scratch.
- An active developer community. Questions are answered swiftly, bugs in the provided libraries can usually be figured out jointly.
- Creating new packages (if it should ever be required) or recompiling existing packages (i.e. to test a fix) is extremely easy. (I recently added libvisio [4] which was the only dependency of Inkscape not yet provided)
- 32-bit and 64-bit builds are equivalent. The exact same library versions are used and MSYS2 includes build environments for both that co-exist by default
I'm already successfully building current trunk with MSYS2 without any issues at all (there are no code changes needed, only environment variables have to be adjusted and the CMake install target has to be adjusted to pick up the correct libraries). If you're interested you can find the latest builds at [5] (the most obvious change is the Adwaita theme that is now used by gtk3 by default but doesn't look very native. However that's something we can customize going forward as desired).
There's one big downside: My builds currently don't work on Windows XP. However I'm afraid this has nothing to do with MSYS2. Many libraries have started to drop support for Windows XP, most importantly gtk3 does not support it after 3.16 [6]. This means we have two possibilites:
- Drop support for Windows XP in Inkscape 0.93
- Try our best to somehow (currently I have no idea how!) continue support for Windows XP. This would most likely require us to keep building, maintaining and distributing our own development libraries (however I guess even here MSYS2 would be a huge help). While achieving this might sound favourable keep in mind that it would require us to limit ourselves to old library versions on purpose with all the inevitable downsides like unfixed bugs and growing number of incompatibilities in newer OSs.
I thought about this for some time now and although it was not an easy decision I'd vote for the first option. I know people still use Windows XP in productive environments (I have an old Windows XP server running myself - shame on me) but to be realistic it's time to move on. Support for XP ended a long time ago, it's insecure and there's only very few cases where people are actually bound to XP for other reasons than convenience. Weighing all the pros and cons I'd say the pros clearly prevail!
*So: Let me know what you think!* Does a switch to MSYS2 as build system sound reasonable to you? Is Windows XP support something we have to keep even if it means a huge amount of additional effort and requires us to limit ourselves on newer platforms on purpose?
Looking forward to you thoughts, Eduard
[1] https://bugs.launchpad.net/bugs/1609954 [2] http://www.msys2.org/ [3] https://github.com/Alexpux/MINGW-packages [4] https://github.com/Alexpux/MINGW-packages/pull/2194 [5] http://download.tuxfamily.org/inkscape/win64/ [6] https://github.com/GNOME/gtk/blob/24483481c1eaa6e3bad9f158e2d4d3ef21505d9b/N...
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Sorry about that Eduard. I'll be quiet now. :) -C
On 27 Feb 2017 6:51 p.m., "Eduard Braun" <eduard.braun2@...173...> wrote:
OK, I'm afraid I started something I did not intend to...
To clarify:
- The intent of my message was *not* to discuss whether people still use Windows XP (they do, I know) and it was *not* to discuss if we still want to support Windows XP (we want, if it's possible). - The intent of my message was to discuss possible ways forward regarding the switch to gtk3 in trunk. (Please be aware that this discussion is only about trunk [!] and what will become Inkscape 0.93. Inkscape 0.92 will be unaffected and can be seen as a LTS branch that will always work on Windows XP!)
So regarding Windows XP: Right now I have no idea *how* to support Windows XP in current trunk. Therefore, unless you know of ways how we *can* support Windows XP in trunk there's absolutely no point in discussing whether we want to! This is a purely technical question at this point and has nothing to do with our personal wishes!
Meanwhile my personal focus was actually on the MSYS2 part (on which nobody commented so far) and therefore I hope we can bring this discussion back on track (this is the devel list - not the user list!).
Regards, Eduard
Am 26.02.2017 um 01:05 schrieb Eduard Braun:
Hi all,
one of the biggest changes in current trunk is the switch to gtk3.
As some of you already know this step will be a hard one on Windows as we have to rely on pre-built development libraries to be able to compile Inkscape:
- devlibs currently has no support for gtk3 at all. (There's an experimental branch on which jazzynico was working, but as far as I know he was never able to complete it due to build issues) - devlibs64 includes gtk3 3.19.6 but IMHO it's pretty broken and would require *a lot* of work to get anywhere near being usable
As a result we're currently not able to build Inkscape for 32-bit Windows at all (bug 1609954 [1]) and builds with devlibs64 are nowhere close to be usable.
*Therefore I want to propose to switch to MSYS2 for compiling Inkscape trunk on Windows!*
MSYS2 is a rewrite of MSYS including all the necessary build tools to compile native applications for Windows using mingw-w64 (see official homepage [2] for details). Furthermore it includes the package manager "pacman" (users of Arch Linux will know it) which allows to conveniently install and upgrade packages.
The switch would have a *lot* of advantages:
- Easier setup of the build system as gcc and all necessary build tools and libraries are included in MSYS2 (currently we require to download gcc + devlibs + cmake separately and procedure varies widely between 32-bit and 64-bit builds) - A solid set of constantly updated libraries (see [3]). - Packages are usually built with a small set of patches to fix compatibility errors on Windows that would otherwise require hours to figure out when building libraries from scratch. - An active developer community. Questions are answered swiftly, bugs in the provided libraries can usually be figured out jointly. - Creating new packages (if it should ever be required) or recompiling existing packages (i.e. to test a fix) is extremely easy. (I recently added libvisio [4] which was the only dependency of Inkscape not yet provided) - 32-bit and 64-bit builds are equivalent. The exact same library versions are used and MSYS2 includes build environments for both that co-exist by default
I'm already successfully building current trunk with MSYS2 without any issues at all (there are no code changes needed, only environment variables have to be adjusted and the CMake install target has to be adjusted to pick up the correct libraries). If you're interested you can find the latest builds at [5] (the most obvious change is the Adwaita theme that is now used by gtk3 by default but doesn't look very native. However that's something we can customize going forward as desired).
There's one big downside: My builds currently don't work on Windows XP. However I'm afraid this has nothing to do with MSYS2. Many libraries have started to drop support for Windows XP, most importantly gtk3 does not support it after 3.16 [6]. This means we have two possibilites:
- Drop support for Windows XP in Inkscape 0.93 - Try our best to somehow (currently I have no idea how!) continue support for Windows XP. This would most likely require us to keep building, maintaining and distributing our own development libraries (however I guess even here MSYS2 would be a huge help). While achieving this might sound favourable keep in mind that it would require us to limit ourselves to old library versions on purpose with all the inevitable downsides like unfixed bugs and growing number of incompatibilities in newer OSs.
I thought about this for some time now and although it was not an easy decision I'd vote for the first option. I know people still use Windows XP in productive environments (I have an old Windows XP server running myself - shame on me) but to be realistic it's time to move on. Support for XP ended a long time ago, it's insecure and there's only very few cases where people are actually bound to XP for other reasons than convenience. Weighing all the pros and cons I'd say the pros clearly prevail!
*So: Let me know what you think!* Does a switch to MSYS2 as build system sound reasonable to you? Is Windows XP support something we have to keep even if it means a huge amount of additional effort and requires us to limit ourselves on newer platforms on purpose?
Looking forward to you thoughts, Eduard
[1] https://bugs.launchpad.net/bugs/1609954 [2] http://www.msys2.org/ [3] https://github.com/Alexpux/MINGW-packages [4] https://github.com/Alexpux/MINGW-packages/pull/2194 [5] http://download.tuxfamily.org/inkscape/win64/ [6] https://github.com/GNOME/gtk/blob/24483481c1eaa6e3bad9f158e2d4d3 ef21505d9b/NEWS#L2340
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Inkscape-devel mailing listInkscape-devel@...1901...://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------ ------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 26.02.2017 um 01:05 schrieb Eduard Braun:
My builds currently don't work on Windows XP. However I'm afraid this has nothing to do with MSYS2.
Good news: I actually just confirmed that MSYS2 is not the problem! I was able to build Inkscape 0.92.x r15394 with MSYS2 and the build is working nicely on Windows XP. This proves, that there's a compatibility issue in gtk3 or one of its dependecies that prevents Inkscape trunk to work on Windows XP (the 0.92.x build uses gtk2 if you're wondering). If you want to try the build yourself you can download it at [1].
As I said before: I do not currently plan to use MSYS2 for builds of 0.92.x. However if people think the updated library versions are something we would want in Windows builds of the stable branch (especially the 32-bit devlibs are quite dated and have some known issues) this test shows that it would certainly be possible. If there's demand for it let me know, as we should start testing early to rule out any regressions.
Regards, Eduard
[1] http://download.tuxfamily.org/inkscape/win32/inkscape-0.92.x-15394-win32-MSY...
I have a question about MSYS 2. It says it uses a POSIX emulation layer just like Cygwin, but is that just for the build tools like bash and not for the actual compiled programs? I looked at Eduard's experimental binaries and there doesn't seem to be any cygwin runtime. Good, so it seems MSYS 2 is basically a cygwin distribution with gcc-mingw as its compiler. Not depending on a POSIX emulation layer is good (Cygwin builds are usually slower than on native UNIX because fork() is inefficient because there's no copy on write mechanism, and I really didn't like the Cygwin style paths), but then it seems MSYS 2 will have to have 2 sets of libraries - one for the build platform tools with the emulation layer and another set for the target platform without.
I actively build Inkscape for Windows but I've given up building on Windows. I just treat it as an embedded system and use a MinGW cross compiler that runs on GNU/Linux (host=x86_64-linux-gnu, target=x86_64-w64-mingw32). > 5 years ago, I did use MSYS 1, but read about and realized that running build scripts like autotools is quite unreliable in MSYS 1 and Windows in general. I'm guessing MSYS 2 is a lot better.
I do my Windows builds inside a VirtualBox VM, but you don't have to. Windows 10 has a process level VM (not whole system, just like WINE) that lets you run Linux binaries. I tried it a few months ago, but the build speed is poor because of slow I/O. I did need to build and install a lot of packages for the cross compiler environment, so maintenance could be a problem. But if there's a way to install MSYS 2 packages for the cross compiler to use, then I think it can be a viable alternative to building on Windows with MSYS 2.
I know of at least 1 feature in GTK 3 that won't work in Windows XP. I submitted a patch to support touch screens. They're debating whether to bump the version requirement to Vista or keep it at XP and use dynamic loading to call the touch screen functions.
https://bugzilla.gnome.org/show_bug.cgi?id=776568
-Yale
On Mon, Feb 27, 2017 at 2:34 PM, Eduard Braun <eduard.braun2@...173...> wrote:
Am 26.02.2017 um 01:05 schrieb Eduard Braun:
My builds currently don't work on Windows XP. However I'm afraid this has nothing to do with MSYS2.
Good news: I actually just confirmed that MSYS2 is not the problem! I was able to build Inkscape 0.92.x r15394 with MSYS2 and the build is working nicely on Windows XP. This proves, that there's a compatibility issue in gtk3 or one of its dependecies that prevents Inkscape trunk to work on Windows XP (the 0.92.x build uses gtk2 if you're wondering). If you want to try the build yourself you can download it at [1].
As I said before: I do not currently plan to use MSYS2 for builds of 0.92.x. However if people think the updated library versions are something we would want in Windows builds of the stable branch (especially the 32-bit devlibs are quite dated and have some known issues) this test shows that it would certainly be possible. If there's demand for it let me know, as we should start testing early to rule out any regressions.
Regards, Eduard
[1] http://download.tuxfamily.org/inkscape/win32/inkscape-0.92.x-15394-win32-MSY...
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 28.02.2017 um 00:37 schrieb Yale Zhang:
I have a question about MSYS 2. It says it uses a POSIX emulation layer just like Cygwin, but is that just for the build tools like bash and not for the actual compiled programs? I looked at Eduard's experimental binaries and there doesn't seem to be any cygwin runtime. Good, so it seems MSYS 2 is basically a cygwin distribution with gcc-mingw as its compiler. Not depending on a POSIX emulation layer is good (Cygwin builds are usually slower than on native UNIX because fork() is inefficient because there's no copy on write mechanism, and I really didn't like the Cygwin style paths), but then it seems MSYS 2 will have to have 2 sets of libraries - one for the build platform tools with the emulation layer and another set for the target platform without.
MSYS2 basically has two components:
* The MSYS part itself which is a minimal build environment with a POSIX emulation layer based on Cygwin. It includes bash and package managment via Arch Linux's pacman. * Native MinGW toolchains for "mingw-w64-i686" and "mingw-w64-x86_64" which are used to produce native Windows binaries (no POSIX emulation layer involved).
You can look at the list of respective packages at https://github.com/Alexpux/MSYS2-packages https://github.com/Alexpux/MINGW-packages
I actively build Inkscape for Windows but I've given up building on Windows. I just treat it as an embedded system and use a MinGW cross compiler that runs on GNU/Linux (host=x86_64-linux-gnu, target=x86_64-w64-mingw32). > 5 years ago, I did use MSYS 1, but read about and realized that running build scripts like autotools is quite unreliable in MSYS 1 and Windows in general. I'm guessing MSYS 2 is a lot better.
Yes, works almost flawless (e.g. recently build gcc without any issues). The really nice part is that it uses pacman and makepkg which makes building extremely easy.
I do my Windows builds inside a VirtualBox VM, but you don't have to. Windows 10 has a process level VM (not whole system, just like WINE) that lets you run Linux binaries. I tried it a few months ago, but the build speed is poor because of slow I/O. I did need to build and install a lot of packages for the cross compiler environment, so maintenance could be a problem. But if there's a way to install MSYS 2 packages for the cross compiler to use, then I think it can be a viable alternative to building on Windows with MSYS 2.
I have honestly no idea about the stuff you're talking here...
I know of at least 1 feature in GTK 3 that won't work in Windows XP. I submitted a patch to support touch screens. They're debating whether to bump the version requirement to Vista or keep it at XP and use dynamic loading to call the touch screen functions.
From the bug I'm understanding your patch would even require Windows 7?
-Yale
Regards, Eduard
On Mon, Feb 27, 2017 at 2:34 PM, Eduard Braun <eduard.braun2@...173...> wrote:
Am 26.02.2017 um 01:05 schrieb Eduard Braun:
My builds currently don't work on Windows XP. However I'm afraid this has nothing to do with MSYS2.
Good news: I actually just confirmed that MSYS2 is not the problem! I was able to build Inkscape 0.92.x r15394 with MSYS2 and the build is working nicely on Windows XP. This proves, that there's a compatibility issue in gtk3 or one of its dependecies that prevents Inkscape trunk to work on Windows XP (the 0.92.x build uses gtk2 if you're wondering). If you want to try the build yourself you can download it at [1].
As I said before: I do not currently plan to use MSYS2 for builds of 0.92.x. However if people think the updated library versions are something we would want in Windows builds of the stable branch (especially the 32-bit devlibs are quite dated and have some known issues) this test shows that it would certainly be possible. If there's demand for it let me know, as we should start testing early to rule out any regressions.
Regards, Eduard
[1] http://download.tuxfamily.org/inkscape/win32/inkscape-0.92.x-15394-win32-MSY...
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
"your patch would even require Windows 7?" Right, touch screen support will require Windows 7.
"I have honestly no idea about the stuff you're talking here..."
Are you familiar with cross compilers? All I'm saying is that I use a compiler that runs on GNU/Linux that builds binaries for Windows (MingW64). I run it inside a VirtualBox VM on Windows 10, but an alternate VM would Microsoft's UNIX emulation layer. I think a cross compiler environment might be a leaner alternative than using MSYS 2 because *doesn't need to use a separate bash and build tools adapted to Windows *builds will probably be faster (autotool builds are much slower on Windows in my experience)
Downsides would be: *need to build your own Windows packages. If you can install the MSYS 2 packages to your cross compile environment, that would solve the problem. *MSYS 2 packages might have gotten more love in terms of bug fixes *some packages run EXEs to generate code (e.g. tables, (de)serialization functions) but don't handle cross compiles properly.
On Mon, Feb 27, 2017 at 4:28 PM, Eduard Braun <eduard.braun2@...173...> wrote:
Am 28.02.2017 um 00:37 schrieb Yale Zhang:
I have a question about MSYS 2. It says it uses a POSIX emulation layer just like Cygwin, but is that just for the build tools like bash and not for the actual compiled programs? I looked at Eduard's experimental binaries and there doesn't seem to be any cygwin runtime. Good, so it seems MSYS 2 is basically a cygwin distribution with gcc-mingw as its compiler. Not depending on a POSIX emulation layer is good (Cygwin builds are usually slower than on native UNIX because fork() is inefficient because there's no copy on write mechanism, and I really didn't like the Cygwin style paths), but then it seems MSYS 2 will have to have 2 sets of libraries - one for the build platform tools with the emulation layer and another set for the target platform without.
MSYS2 basically has two components:
The MSYS part itself which is a minimal build environment with a POSIX emulation layer based on Cygwin. It includes bash and package managment via Arch Linux's pacman. Native MinGW toolchains for "mingw-w64-i686" and "mingw-w64-x86_64" which are used to produce native Windows binaries (no POSIX emulation layer involved).
You can look at the list of respective packages at https://github.com/Alexpux/MSYS2-packages https://github.com/Alexpux/MINGW-packages
I actively build Inkscape for Windows but I've given up building on Windows. I just treat it as an embedded system and use a MinGW cross compiler that runs on GNU/Linux (host=x86_64-linux-gnu, target=x86_64-w64-mingw32). > 5 years ago, I did use MSYS 1, but read about and realized that running build scripts like autotools is quite unreliable in MSYS 1 and Windows in general. I'm guessing MSYS 2 is a lot better.
Yes, works almost flawless (e.g. recently build gcc without any issues). The really nice part is that it uses pacman and makepkg which makes building extremely easy.
I do my Windows builds inside a VirtualBox VM, but you don't have to. Windows 10 has a process level VM (not whole system, just like WINE) that lets you run Linux binaries. I tried it a few months ago, but the build speed is poor because of slow I/O. I did need to build and install a lot of packages for the cross compiler environment, so maintenance could be a problem. But if there's a way to install MSYS 2 packages for the cross compiler to use, then I think it can be a viable alternative to building on Windows with MSYS 2.
I have honestly no idea about the stuff you're talking here...
I know of at least 1 feature in GTK 3 that won't work in Windows XP. I submitted a patch to support touch screens. They're debating whether to bump the version requirement to Vista or keep it at XP and use dynamic loading to call the touch screen functions.
https://bugzilla.gnome.org/show_bug.cgi?id=776568
From the bug I'm understanding your patch would even require Windows 7?
-Yale
Regards, Eduard
On Mon, Feb 27, 2017 at 2:34 PM, Eduard Braun <eduard.braun2@...173...> wrote:
Am 26.02.2017 um 01:05 schrieb Eduard Braun:
My builds currently don't work on Windows XP. However I'm afraid this has nothing to do with MSYS2.
Good news: I actually just confirmed that MSYS2 is not the problem! I was able to build Inkscape 0.92.x r15394 with MSYS2 and the build is working nicely on Windows XP. This proves, that there's a compatibility issue in gtk3 or one of its dependecies that prevents Inkscape trunk to work on Windows XP (the 0.92.x build uses gtk2 if you're wondering). If you want to try the build yourself you can download it at [1].
As I said before: I do not currently plan to use MSYS2 for builds of 0.92.x. However if people think the updated library versions are something we would want in Windows builds of the stable branch (especially the 32-bit devlibs are quite dated and have some known issues) this test shows that it would certainly be possible. If there's demand for it let me know, as we should start testing early to rule out any regressions.
Regards, Eduard
[1] http://download.tuxfamily.org/inkscape/win32/inkscape-0.92.x-15394-win32-MSY...
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 28.02.2017 um 01:58 schrieb Yale Zhang:
"your patch would even require Windows 7?" Right, touch screen support will require Windows 7.
"I have honestly no idea about the stuff you're talking here..."
Are you familiar with cross compilers? All I'm saying is that I use a compiler that runs on GNU/Linux that builds binaries for Windows (MingW64). I run it inside a VirtualBox VM on Windows 10, but an alternate VM would Microsoft's UNIX emulation layer. I think a cross compiler environment might be a leaner alternative than using MSYS 2 because *doesn't need to use a separate bash and build tools adapted to Windows *builds will probably be faster (autotool builds are much slower on Windows in my experience)
Downsides would be: *need to build your own Windows packages. If you can install the MSYS 2 packages to your cross compile environment, that would solve the problem. *MSYS 2 packages might have gotten more love in terms of bug fixes *some packages run EXEs to generate code (e.g. tables, (de)serialization functions) but don't handle cross compiles properly.
I know what cross compilers are, but never really used them. As you note yourself: Somehow one would still have to obtain the necessary libraries (and I doubt it would be easy - if even possible - to use MSYS2's native packages for that?). Even then: I doubt having to install a VM could be considered "convenient" or "easy"? And if I wanted to use cross compile from Linux I could do that by using Linux from the start and be done with Windows after all instead of running it in a VM. ;-)
Regarding "Microsoft's UNIX emulation layer": You mean what Microsoft calls "Bash on Ubuntu on Windows" [1], right? In fact I did not have that on my radar (I read about it once and wasn't sure if it was an April Fools' joke :-D ). Just installed it and gave it a quick try... But still I guess it wouldn't solve the issue with obtaining the necessary dependencies? And after some initial evaluation it seems to be mostly undocumented... I don't see how this would really help us with building Inkscape? After all everything we need is readily offered by MSYS2, so why bother re-inventing the wheel?
The only advantage you quote are faster builds, but on my machine with MSYS2, CMake and Ninja I really can't complain. Inkscape builds in about 10-15 min on a dual-core notebook CPU (i7-6600U), I guess this is fair? In day-to-day work full rebuilds aren't necessary anyway and then it's only a matter of seconds...
If I'm totally missing something here let me know, but from my point of view there's not much to gain, especially as we're aiming for a solution that virtually everybody should be able to use...
Regards, Eduard
OK, I gave MSYS 2 a try and the binary packages can be easily installed/copied to another build environment (just copy the x86_64-w64-mingw32 directory). So the big problem of needing to build lots of packages from source when setting up a cross compiler is solved. I thought about trying it but realized MSYS 2 packages use pthreads for its threading model while my custom cross GCC uses its internal win32 threading model which is lighter weight but doesn't support C++11 threads out of the box. So, I'll have to rebuild GCC to use that model or find an existing cross tool chain.
"but from my point of view there's not much to gain".
I think that's a fair assessment if you plan to do all your development on Windows. The main group who I imagine might prefer a cross compiler are developers who are already running a Linux distro and are primarily doing development on that platform, since it doesn't require Windows. Or even if they have Windows, they might prefer a Linux build environment without MSYS2's POSIX emulation.
Also, how about some nightly Windows builds for Inkscape? I think that would be easier to do on a Linux server with cross GCC than on Windows.
So, let's stop declaring either as superior. Choose which ever you like.
As for the Windows' built in Linux VM, I tried to test if it can replace my VirtualBox VM. I was able to replace the Ubuntu distro with Debian and build Inkscape, but the build times were too long. If I only recompiled 1 file, it took 1 minute. On VirtualBox, it took around half the time. The files in the Linux VM are stored as regular user files that you can see in Windows. I don't think NTFS is designed to handle all those tiny files.
On Mon, Feb 27, 2017 at 5:56 PM, Eduard Braun <eduard.braun2@...173...> wrote:
Am 28.02.2017 um 01:58 schrieb Yale Zhang:
"your patch would even require Windows 7?" Right, touch screen support will require Windows 7.
"I have honestly no idea about the stuff you're talking here..."
Are you familiar with cross compilers? All I'm saying is that I use a compiler that runs on GNU/Linux that builds binaries for Windows (MingW64). I run it inside a VirtualBox VM on Windows 10, but an alternate VM would Microsoft's UNIX emulation layer. I think a cross compiler environment might be a leaner alternative than using MSYS 2 because *doesn't need to use a separate bash and build tools adapted to Windows *builds will probably be faster (autotool builds are much slower on Windows in my experience)
Downsides would be: *need to build your own Windows packages. If you can install the MSYS 2 packages to your cross compile environment, that would solve the problem. *MSYS 2 packages might have gotten more love in terms of bug fixes *some packages run EXEs to generate code (e.g. tables, (de)serialization functions) but don't handle cross compiles properly.
I know what cross compilers are, but never really used them. As you note yourself: Somehow one would still have to obtain the necessary libraries (and I doubt it would be easy - if even possible - to use MSYS2's native packages for that?). Even then: I doubt having to install a VM could be considered "convenient" or "easy"? And if I wanted to use cross compile from Linux I could do that by using Linux from the start and be done with Windows after all instead of running it in a VM. ;-)
Regarding "Microsoft's UNIX emulation layer": You mean what Microsoft calls "Bash on Ubuntu on Windows" [1], right? In fact I did not have that on my radar (I read about it once and wasn't sure if it was an April Fools' joke :-D ). Just installed it and gave it a quick try... But still I guess it wouldn't solve the issue with obtaining the necessary dependencies? And after some initial evaluation it seems to be mostly undocumented... I don't see how this would really help us with building Inkscape? After all everything we need is readily offered by MSYS2, so why bother re-inventing the wheel?
The only advantage you quote are faster builds, but on my machine with MSYS2, CMake and Ninja I really can't complain. Inkscape builds in about 10-15 min on a dual-core notebook CPU (i7-6600U), I guess this is fair? In day-to-day work full rebuilds aren't necessary anyway and then it's only a matter of seconds...
If I'm totally missing something here let me know, but from my point of view there's not much to gain, especially as we're aiming for a solution that virtually everybody should be able to use...
Regards, Eduard
On 02/28/2017 11:15 AM, Yale Zhang wrote:
I think that's a fair assessment if you plan to do all your development on Windows. The main group who I imagine might prefer a cross compiler are developers who are already running a Linux distro and are primarily doing development on that platform, since it doesn't require Windows. Or even if they have Windows, they might prefer a Linux build environment without MSYS2's POSIX emulation.
Also, how about some nightly Windows builds for Inkscape? I think that would be easier to do on a Linux server with cross GCC than on Windows.
I actually did try to cross-compile inkscape a while ago (when we were still with autotools), with little success (after a few days, I managed to open a binary, but got an "ELF" error that I could not understand, so I gave up), my main goal was precisely to be able to easily provide devel builds to people on windows (I have windows for gaming purposes, but am not familiar at all with how to compile on it).
I'm very interested at how you manage to cross compile, if it's possible to document it.
Thx,
Thanks for your interest and cool avatar. Maybe you should use the force and sai cha on those spammers. I also game on Windows but prefer the GNU tools. I just realized I could use Visual Studio to develop and build Inkscape (thanks to CMake), which will be much more convenient and make iteration faster (no more copying EXEs from VirtualBox). But I don't think Inkscape can compile with the Microsoft compiler.
Here's a summary of how to build a cross compiler:
1. copy the minimum set of target platform (MinGW) header files and C runtime libraries to where you want to install the cross compiler I install to /opt/gcc6.3, so the target files go in /opt/gcc6.3/x86_64-w64-mingw32
Optionally, you can copy all the headers and libraries (for target platform) not needed for building GCC at this time also. You can get those from the MSYS 2 packages.
2. build and install cross binutils that targets MinGW 3. build and install GCC
I have a script that automates #2 and #3.
For #1, you could install MSYS 2 on Windows, then copy the entire x86_64-w64-mingw32 directory to the cross compiler. Or write a script that extracts the MSYS 2 packages.
Currently, I don't use the MSYS 2 packages. I painstakingly built all the necessary packages from source.
Let me give it a test using MSYS 2 packages and reply with detailed instructions.
-Yale
Am 28.02.2017 um 11:15 schrieb Yale Zhang:
"but from my point of view there's not much to gain".
I think that's a fair assessment if you plan to do all your development on Windows. The main group who I imagine might prefer a cross compiler are developers who are already running a Linux distro and are primarily doing development on that platform, since it doesn't require Windows. Or even if they have Windows, they might prefer a Linux build environment without MSYS2's POSIX emulation.
Yeah, then I think we're on the same page here... Either way having an easy possibility to cross-compile would certainly not hurt.
Also, how about some nightly Windows builds for Inkscape? I think that would be easier to do on a Linux server with cross GCC than on Windows.
We could actually use AppVeyor for that. They have MSYS2 installed on theyr workers: https://www.appveyor.com/docs/installed-software/#mingw-msys-cygwin
Hi Eduard (and all),
Thanks for your message. It's time to decide what to do with our old devlibs and Windows XP support indeed.
I have stopped working on the win32 devlibs (on an XP computer) about a year ago due to issues with Gtk3, as you explained, but also with Harfbuzz and Glib. And some others with Imagemagick and Aspell (possibly also linked to missing headers in the TDM-DCC compiler, if I remember correctly). If Windows XP was officially dropped in Gtk+ 3.17.1, the Gnome team was also considering dropping XP for all its projects (https://mail.gnome.org/archives/gtk-devel-list/2014-December/msg00055.html).
Does a switch to MSYS2 as build system sound reasonable to you?
If switching to MSYS2 allows us to get rid of the old devlibs and improves the Windows 32 and 64 bit support it's surely worth a try (just using the same libs versions is a huge improvement, and not only for devlibs maintainers, but for bugs managers too!).
Is Windows XP support something we have to keep even if it means a huge amount of additional effort and requires us to limit ourselves on newer platforms on purpose?
No, it's not. But we should keep XP support for the 0.92.x branch IMHO (with the old win 32 devlibs), even if it means a real LTS support for 0.92.x. And for 0.93, we can drop XP (not that it doesn't mean dropping 32-bit, since most libraries seem to build and work correctly on 32-bit versions of Windows 7).
Regards, -- Nicolas
Am 03.03.2017 um 19:02 schrieb Nicolas Dufour:
Hi Eduard (and all),
Thanks for your message. It's time to decide what to do with our old devlibs and Windows XP support indeed.
I have stopped working on the win32 devlibs (on an XP computer) about a year ago due to issues with Gtk3, as you explained, but also with Harfbuzz and Glib. And some others with Imagemagick and Aspell (possibly also linked to missing headers in the TDM-DCC compiler, if I remember correctly). If Windows XP was officially dropped in Gtk+ 3.17.1, the Gnome team was also considering dropping XP for all its projects (https://mail.gnome.org/archives/gtk-devel-list/2014-December/msg00055.html).
Yes, I noticed that. You did a great job with the devlibs, though, so whatever we decide going forward I'd like to thank you very much for all the effort you put into them over the year!
Does a switch to MSYS2 as build system sound reasonable to you?
If switching to MSYS2 allows us to get rid of the old devlibs and improves the Windows 32 and 64 bit support it's surely worth a try (just using the same libs versions is a huge improvement, and not only for devlibs maintainers, but for bugs managers too!).
Yes, current state is that we could drop devlibs{,64} altogether and depend solely on MSYS2. The only thing I have yet to figure out is how to treat our Python distribution. (Python is part of MSYS2 and even lxml and numpy are available so we'd be mostly covered. The remaining modules could be added via pip on the fly or we could also think about creating packages for them in MSYS2).
Is Windows XP support something we have to keep even if it means a huge amount of additional effort and requires us to limit ourselves on newer platforms on purpose?
No, it's not. But we should keep XP support for the 0.92.x branch IMHO (with the old win 32 devlibs), even if it means a real LTS support for 0.92.x. And for 0.93, we can drop XP (not that it doesn't mean dropping 32-bit, since most libraries seem to build and work correctly on 32-bit versions of Windows 7).
Good to know we're of one opinion here!
Windows XP support in 0.92.x is mandatory, no question there. However I suspect you even missed one of my last messages: Building the 0.92.x branch with MSYS works perfectly, too, and runs on Windows XP just fine! So we can decide freely whether we want to stick with our current devlibs{,64} for the 0.92.x branch or even want to upgrade there, too. Both options have pros and cons:
* devlibs{,64} are well tested so we know what we have (but also what we don't have!). Currently there are various things not working as nicely as they could or not working at all due to outdated or even missing libraries. Also having two sets of development libraries with completely different base (devlibs use TDM-GCC based on MinGW, devlibs64 use mingw-w64) often makes behaviour very inconsistent between both. * MSYS2 would solve all the issues listed above plus if we go forward with the switch it would simplify development on Windows as MSYS2 could be used exclusively for all builds making it much easier to set-up a build system that can handle everything. MSYS2 builds are obviously not tested thoroughly yet, so there's a chance of regressions (which in my opinion is the one and only con).
Regards,
Nicolas
Thanks for your answer and Best Regards, Eduard
Am 03.03.2017 um 20:10 schrieb Eduard Braun:
Yes, I noticed that. You did a great job with the devlibs, though, so whatever we decide going forward I'd like to thank you very much for all the effort you put into them over the year!
* that should have read year*s* (plural). Obviously I wanted to thank you for you continuous work on these things!
Hi Eduard (and all),
Some comments on my first tests with MSYS2 on Windows 7 (64-bit): * MSYS2 is about as easy as MSYS to configure and use, so no bad surprise. From a user's point of view, the only drawback is the automatic mapping between the Windows username and the MSYS2 account (with MSYS, you can choose a different name).
* I installed the 64-bit version, with both the 32 and 64-bit packages (installed via the msys2installdeps.sh script). Note that due to a quite slow Internet connection, I had to launch the script 3 or 4 times (some packages took too long to download and failed in timeout). * The imagemagick-6 packages and the additional Python packages (in the pip install section) were not automatically installed by the script, and I had to add them manually. Probably my fault though, because I launched MSYS2 with the msys2 command, not the mingw32 or ming64 ones (and thus the platform specific folder was not in the path). Could be interesting to document it in the wiki page. * Bzr needs ssh to work correctly (with default settings). It works perfectly with the Openssh package, but I read other users used the Putty package or some Python modules.
* Inkscape trunk 64-bit compilation (with cmake and ninja) works perfectly. The application looks a bit weird with Gtk3 on Windows (If I remember correctly, the UI elements were significantly smaller with my previous Gtk3 tests), but not that bad. And I see no obvious regression with the basic features for now.
* I first tried to compile with gtest installed, but as it failed I removed the folder without investigating. Please tell me if it's expected to work or not.
I'll try to find time this week to test 32-bit building on my 64-bit computer. Probably something to tweak somewhere to make it work (clues are welcome!). Another MSYS2 (32-bit version) is in progress so that I can test it with an old Windows XP computer later (yes, I'm also forced to use one from time to time...).
Thanks for your help, Eduard, MSYS2 looks very promising!
Regards, -- Nicolas
Hi Nicolas,
thanks for testing!
- I installed the 64-bit version, with both the 32 and 64-bit packages (installed via the msys2installdeps.sh script). Note that due to a quite slow Internet connection, I had to launch the script 3 or 4 times (some packages took too long to download and failed in timeout).
Luckily I never had any problems with installing packages on my side, but I found some useful tips at [1] and a suggestion on how to achieve arbitrary download timeouts by using curl at [2].
[1] https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Download_speeds [2] https://bbs.archlinux.org/viewtopic.php?id=180873
- The imagemagick-6 packages and the additional Python packages (in the pip install section) were not automatically installed by the script, and I had to add them manually. Probably my fault though, because I launched MSYS2 with the msys2 command, not the mingw32 or ming64 ones (and thus the platform specific folder was not in the path). Could be interesting to document it in the wiki page.
No, that was my fault (I changed something in the script at the last minute and immediately introduced a regression... what did I expect ;-) ). Fixed with [3]. For installing packages the MSYS shell is actually the officially preferred shell. As a rule of thumb: for all "administrative" tasks (like installing/updating packages) use the MSYS shell. For building native software (like Inkscape) use the MinGW 32/64 shells.
[3] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15577
- Bzr needs ssh to work correctly (with default settings). It works perfectly with the Openssh package, but I read other users used the Putty package or some Python modules.
I'm using openssh, too. In the version of "msys2installdeps.sh" I used for testing I still had included git (which explicitly depends on openssh), so I already had it installed. That being said for a simple checkout one can actually work without ssh and I certainly hope we switch to git soon!
- Inkscape trunk 64-bit compilation (with cmake and ninja) works perfectly. The application looks a bit weird with Gtk3 on Windows (If I remember correctly, the UI elements were significantly smaller with my previous Gtk3 tests), but not that bad. And I see no obvious regression with the basic features for now.
Great! That's obviously by far the most important point. I know there are some issues with GTK3 UI, mostly because Adwaita is used which looks very non-native on Windows and has some incredibly huge controls.However functionality-wise everything is there, so it's fine for testing. Going forward I'm leaning towards using the "win32" native theme. It has it's issues, too, but I think we can fix them with some CSS. Obviously fiddling with UI is something that does not make much sense before we have decided on one of the options, so that's probably one decision we should make early.
- I first tried to compile with gtest installed, but as it failed I removed the folder without investigating. Please tell me if it's expected to work or not.
I never tried gtest to be honest, so can't comment on that.
I'll try to find time this week to test 32-bit building on my 64-bit computer. Probably something to tweak somewhere to make it work (clues are welcome!). Another MSYS2 (32-bit version) is in progress so that I can test it with an old Windows XP computer later (yes, I'm also forced to use one from time to time...).
I'm not sure I understand? I can build both (32/64-bit Inkscape) on Windows 10 x64 (using 64-bit version of MSYS2, but that should not even matter) without any problems. What's there to tweak? Just launch the correct shell ("MSYS2 MinGW 32-bit") and compile exactly as you compiled the 64-bit version.
Regarding Windows XP: You probably have to copy the installation from another machine as the MSYS2 installer currently is said not to work on XP (see note on MSYS2 homepage). Do you want to compile trunk on XP? If so are you planning on gathering old gtk3 packages (+ dependencies) that are still compatible with XP?
Thanks for your help, Eduard, MSYS2 looks very promising!
Regards,
Nicolas
Regards, Eduard
Hi Eduard,
I'll try to find time this week to test 32-bit building on my 64-bit computer.
I'm not sure I understand? I can build both (32/64-bit Inkscape) on Windows 10 x64 (using 64-bit version of MSYS2, but that should not even matter) without any problems. What's there to tweak? Just launch the correct shell ("MSYS2 MinGW 32-bit") and compile exactly as you compiled the 64-bit version.
That's what I expected. It seems that CMake correctly detects the compiler version, but ninja fails to compile anything and returns the following error for the first 5 files: ----- [1/976] Building CXX object src/util/CMakeFiles/util_LIB.dir/ege-tags.cpp.obj FAILED: src/util/CMakeFiles/util_LIB.dir/ege-tags.cpp.obj ... D:\Dev\inkscape\trunk\src\util\ege-tags.cpp:1:0: sorry, unimplemented: 64-bit mode not compiled in /* ***** BEGIN LICENSE BLOCK ***** -----
Here's my CMake report (relevant parts only): ----- CMAKE_SYSTEM_NAME: Windows CMAKE_SYSTEM_VERSION: 6.1.7601 CMAKE_SYSTEM_PROCESSOR: AMD64 CMAKE_C_COMPILER: D:/Dev/msys2-64/mingw32/bin/gcc.exe CMAKE_CXX_COMPILER: D:/Dev/msys2-64/mingw32/bin/g++.exe CMAKE_BUILD_TYPE: Release ... HAVE_MINGW: ON HAVE_MINGW64: ON MINGW_PATH: D:/Dev/msys2-64/mingw32 MINGW_ARCH: i686-w64-mingw32 MINGW_ARCH_PATH: D:/Dev/msys2-64/mingw32/i686-w64-mingw32 MINGW64_INCLUDE: D:/Dev/msys2-64/mingw32/i686-w64-mingw32/include MINGW64_LIB: D:/Dev/msys2-64/mingw32/i686-w64-mingw32/lib -----
Regarding Windows XP: You probably have to copy the installation from another machine as the MSYS2 installer currently is said not to work on XP (see note on MSYS2 homepage).
Yes, that's what I'm going to try. If the issue is with the installer only, it could possibly work.
Do you want to compile trunk on XP? If so are you planning on gathering old gtk3 packages (+ dependencies) that are still compatible with XP?
I wanted to see if we could replace the current win32 devlibs with MSYS2 for the 0.92.x branch. It would be convenient if it could compile on XP...
Regards, -- Nicolas
Am 08.03.2017 um 08:19 schrieb Nicolas Dufour:
Hi Eduard,
I'll try to find time this week to test 32-bit building on my 64-bit computer.
I'm not sure I understand? I can build both (32/64-bit Inkscape) on Windows 10 x64 (using 64-bit version of MSYS2, but that should not even matter) without any problems. What's there to tweak? Just launch the correct shell ("MSYS2 MinGW 32-bit") and compile exactly as you compiled the 64-bit version.
That's what I expected. It seems that CMake correctly detects the compiler version, but ninja fails to compile anything and returns the following error for the first 5 files: [...]
Ah okay... I'll check this evening. I might have an idea what's the problem here. (It seems we have a cmake variable "HAVE_MINGW64" that is not sure if it want's to be say "have 64-bit mingw" or "have mingw-w64". Previously it didn't matter as 32-bit devlibs were based on mingw and devlibs64 were based on mingw-w64, but MSYS2's 32-bit MinGW is based on mingw-w64, too (they really should have called it mingw2 in the first place to avoid the confusion...).
Do you want to compile trunk on XP? If so are you planning on gathering old gtk3 packages (+ dependencies) that are still compatible with XP?
I wanted to see if we could replace the current win32 devlibs with MSYS2 for the 0.92.x branch. It would be convenient if it could compile on XP...
I already built a 32-bit version of (0.92.x with MSYS2 on Windows 10 x64) that runs on Windows XP (it's on the tuxfamily FTP server). If compiling works on XP that would obviously be perfect!
Regards, Eduard
Am 08.03.2017 um 10:12 schrieb Eduard Braun:
That's what I expected. It seems that CMake correctly detects the compiler version, but ninja fails to compile anything and returns the following error for the first 5 files: [...]
Ah okay... I'll check this evening. I might have an idea what's the problem here.
Should work now (fixed in http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15579).
Hello Everybody,
just wanted to quickly hook into the discussion:
1. Switching to MSYS2: Wise choice, totally support it. Btw. GIMP is doing the same for Windows builds.
2. Windows XP: It's a question of resources. Are there enough developers willing to maintain the backports for Windows XP? I seriously doubt that. If Microsoft and GTK drop support for XP, then we should do that as well. It's not fair to technically limit (to some old lib versions) the development of Inkscape because of a few users. People surely have their reasons for sticking with the unsupported OS. I dont judge that. But what is wrong with sticking to an old stable version of Inkscape (like 0.91) in this case? If users are not getting updates for the OS - why then for the software?
Best regards,
Sebastian
*Semiodesk GmbH | *Werner-von-Siemens-Str. 6 Geb. 15k, 86159 Augsburg, Germany | Phone: +49 821 8854401 | Fax: +49 821 8854410 | www.semiodesk.com
This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Semiodesk GmbH is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.
2017-03-09 0:36 GMT+01:00 Eduard Braun <eduard.braun2@...173...>:
Am 08.03.2017 um 10:12 schrieb Eduard Braun:
That's what I expected. It seems that CMake correctly detects the compiler version, but ninja fails to compile anything and returns the following error for the first 5 files: [...]
Ah okay... I'll check this evening. I might have an idea what's the problem here.
Should work now (fixed in http://bazaar.launchpad.net/~ inkscape.dev/inkscape/trunk/revision/15579).
Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
*Status update:* (as some of you might be wondering what Nicolas is talking about; others might have already noticed)
I recently pushed some commits to Inkscape trunk that allow to compile Inkscape using MSYS2 with minimal effort.
I created a step-by-step guide with complete compilation instructions in the Wiki: http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows_with_M...
If you have some time to spare I'd like to encourage you to start experimenting with MSYS2 and Inkscape trunk on Windows! If you should encounter any issues please let me know.
Thanks in advance, Eduard
Am 26.02.2017 um 01:05 schrieb Eduard Braun:
Hi all,
one of the biggest changes in current trunk is the switch to gtk3.
As some of you already know this step will be a hard one on Windows as we have to rely on pre-built development libraries to be able to compile Inkscape:
- devlibs currently has no support for gtk3 at all. (There's an experimental branch on which jazzynico was working, but as far as I know he was never able to complete it due to build issues)
- devlibs64 includes gtk3 3.19.6 but IMHO it's pretty broken and would require *a lot* of work to get anywhere near being usable
As a result we're currently not able to build Inkscape for 32-bit Windows at all (bug 1609954 [1]) and builds with devlibs64 are nowhere close to be usable.
*Therefore I want to propose to switch to MSYS2 for compiling Inkscape trunk on Windows!*
MSYS2 is a rewrite of MSYS including all the necessary build tools to compile native applications for Windows using mingw-w64 (see official homepage [2] for details). Furthermore it includes the package manager "pacman" (users of Arch Linux will know it) which allows to conveniently install and upgrade packages.
The switch would have a *lot* of advantages:
- Easier setup of the build system as gcc and all necessary build tools and libraries are included in MSYS2 (currently we require to download gcc + devlibs + cmake separately and procedure varies widely between 32-bit and 64-bit builds)
- A solid set of constantly updated libraries (see [3]).
- Packages are usually built with a small set of patches to fix compatibility errors on Windows that would otherwise require hours to figure out when building libraries from scratch.
- An active developer community. Questions are answered swiftly, bugs in the provided libraries can usually be figured out jointly.
- Creating new packages (if it should ever be required) or recompiling existing packages (i.e. to test a fix) is extremely easy. (I recently added libvisio [4] which was the only dependency of Inkscape not yet provided)
- 32-bit and 64-bit builds are equivalent. The exact same library versions are used and MSYS2 includes build environments for both that co-exist by default
I'm already successfully building current trunk with MSYS2 without any issues at all (there are no code changes needed, only environment variables have to be adjusted and the CMake install target has to be adjusted to pick up the correct libraries). If you're interested you can find the latest builds at [5] (the most obvious change is the Adwaita theme that is now used by gtk3 by default but doesn't look very native. However that's something we can customize going forward as desired).
There's one big downside: My builds currently don't work on Windows XP. However I'm afraid this has nothing to do with MSYS2. Many libraries have started to drop support for Windows XP, most importantly gtk3 does not support it after 3.16 [6]. This means we have two possibilites:
- Drop support for Windows XP in Inkscape 0.93
- Try our best to somehow (currently I have no idea how!) continue support for Windows XP. This would most likely require us to keep building, maintaining and distributing our own development libraries (however I guess even here MSYS2 would be a huge help). While achieving this might sound favourable keep in mind that it would require us to limit ourselves to old library versions on purpose with all the inevitable downsides like unfixed bugs and growing number of incompatibilities in newer OSs.
I thought about this for some time now and although it was not an easy decision I'd vote for the first option. I know people still use Windows XP in productive environments (I have an old Windows XP server running myself - shame on me) but to be realistic it's time to move on. Support for XP ended a long time ago, it's insecure and there's only very few cases where people are actually bound to XP for other reasons than convenience. Weighing all the pros and cons I'd say the pros clearly prevail!
*So: Let me know what you think!* Does a switch to MSYS2 as build system sound reasonable to you? Is Windows XP support something we have to keep even if it means a huge amount of additional effort and requires us to limit ourselves on newer platforms on purpose?
Looking forward to you thoughts, Eduard
[1] https://bugs.launchpad.net/bugs/1609954 [2] http://www.msys2.org/ [3] https://github.com/Alexpux/MINGW-packages [4] https://github.com/Alexpux/MINGW-packages/pull/2194 [5] http://download.tuxfamily.org/inkscape/win64/ [6] https://github.com/GNOME/gtk/blob/24483481c1eaa6e3bad9f158e2d4d3ef21505d9b/N...
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (12)
-
alvinpenner -
brynn -
C R -
Eduard Braun -
LucaDC -
Marc Jeanmougin -
Martin Owens -
Miguel Lopez -
Nicolas Dufour -
Sebastian Faubel -
Sylvain Chiron -
Yale Zhang