Fwd: Re : Inskape 0.48pre1 - Error message when saving as wmf
On Thu, Jul 8, 2010 at 6:14 PM, bulia byak <buliabyak@...400...> wrote:
2010/7/8 Nicolas Dufour <nicoduf@...48...>:
- Removing the Uniconvertor scripts from the devlibs. UniConvertor
import or export scripts warn users to install UniConvertor manually (and give the site address) when the libs are missing. (Note to self: fix the gettext import bug in uniconv_output.py...).
I think that will be perceived as a regression. Lots of formats that used to work will suddenly stop working. We had a lot of pain with displaying messages like this - most people simply perceive any such message as an error and complain or give up without reading. Those who read it and act on it will be a minority.
From other side a lot of win32 users ask us "Why you announce XXX feature
but i have not this in Inkscape?". We cannot synchronize our project development cycles, it's normally. But we could provide for user a way updating UniConvertor. External UniConvertor installation is a best solution because current bundle updating is a task rather for programmer than for conventional user/designer.
What's such a big problem with including a new UC into devlibs?
Actually there are not impossible tasks. It's just a subject of additional development time and resulted bundle size. Latest version has several new native extensions and more complex structure. And in next versions we will add new native resources because users ask for more and more complex features.
As a simple solution we can provide for users an Inkscape-0.48-with-UniConvertor.zip archive with Inkscape installer, UniConvertor MSI and small REAME file inside. To simplify UniConvertor download the best way is not a message "You need downloading from bla-bla-bla site..." but just a button "Download" which opened browser on required page. Last option is for those users who download Inkscape exe installer only.
Another valuable reason is planned preferences for translation. We are going provide a lot of translation options (we already have the code but we still not expose it as a command line options) and naturally such preferences could be managed better from GUI than command line. So we will add preferences dialogs for each format into UniConvertor. It's not an easy task so for Inkscape team will be better utilizing ready dialogs from UniConvertor than creating the same but on Inkscape side. And as I have wrote UniConvertor translation progress dialog would be also a good additional feature for Inkscape.
Regards,
Igor Novikov sK1 Project http://sk1project.org
On Jul 8, 2010, at 9:39 AM, Igor Novikov wrote:
Another valuable reason is planned preferences for translation. We are going provide a lot of translation options (we already have the code but we still not expose it as a command line options) and naturally such preferences could be managed better from GUI than command line. So we will add preferences dialogs for each format into UniConvertor. It's not an easy task so for Inkscape team will be better utilizing ready dialogs from UniConvertor than creating the same but on Inkscape side. And as I have wrote UniConvertor translation progress dialog would be also a good additional feature for Inkscape.
Unfortunately this approach is going in the opposite direction from Inkscape. Mixing different UI elements, especially toolkits, is one of the major issues with Inkscape and one that reviewers who might recommend it to others find to be a major problem. There are many other issues with such mixing, and the Scribus team has confirmed and pointed out many more. These issues have also plagued libraries and interfaces such as TWAIN.
For a library, it is far better to separate user interface from the functionality, and to abstract needed data into the API. We also have been planning on a refactoring pass for both our plugins and our preferences, so unifying those instead of diversifying is where we'd like to go.
As you know at the moment we have two packages: uniconvertor and uniconvw. First is a command line interface to translation engine, second is a GUI interface. We plan adding preferences dialogs to uniconvw and command line options to uniconvertor. If you prefer command line translation this interface will be accessible anyway. If you need we can adding verbose mode for command line and you could parsing this info.
uniconvw is pyGtk based so it's the same toolkit as Inkscape used. Actually there is no problem in using GUI way because it has the same L&F and this dialog can be screen centered. Even transitional and modal features is possible if you will pass Inkscape window xid/winID. Under Windows to look more natively Inkscape calls WinAPI dialogs. So it's already toolkit mixing. But under win platform it's considered like rather advanced feature than a bad coding. At opposite cmd window for translation process is a worst case. Common win pattern is: avoid using command line, prefer library function calls.
On Fri, Jul 9, 2010 at 8:08 AM, Jon Cruz <jon@...18...> wrote:
On Jul 8, 2010, at 9:39 AM, Igor Novikov wrote:
Another valuable reason is planned preferences for translation. We are
going provide a lot of translation options (we already have the code
but we still not expose it as a command line options) and naturally such
preferences could be managed better from GUI than command line.
So we will add preferences dialogs for each format into UniConvertor.
It's not an easy task so for Inkscape team will be better utilizing ready
dialogs from UniConvertor than creating the same but on Inkscape side.
And as I have wrote UniConvertor translation progress dialog
would be also a good additional feature for Inkscape.
Unfortunately this approach is going in the opposite direction from Inkscape. Mixing different UI elements, especially toolkits, is one of the major issues with Inkscape and one that reviewers who might recommend it to others find to be a major problem. There are many other issues with such mixing, and the Scribus team has confirmed and pointed out many more. These issues have also plagued libraries and interfaces such as TWAIN.
For a library, it is far better to separate user interface from the functionality, and to abstract needed data into the API. We also have been planning on a refactoring pass for both our plugins and our preferences, so unifying those instead of diversifying is where we'd like to go.
On Jul 9, 2010, at 1:40 AM, Igor Novikov wrote:
uniconvw is pyGtk based so it's the same toolkit as Inkscape used. Actually there is no problem in using GUI way because it has the same L&F and this dialog can be screen centered. Even transitional and modal features is possible if you will pass Inkscape window xid/winID. Under Windows to look more natively Inkscape calls WinAPI dialogs. So it's already toolkit mixing. But under win platform it's considered like rather advanced feature than a bad coding. At opposite cmd window for translation process is a worst case. Common win pattern is: avoid using command line, prefer library function calls.
Well... there are many differences, *especially* if we go with separate installs. I've worked in this area a lot, so I've seen many of the surprises.
Passing win id's is also very problematic. This was, among other things, a big problem with the XEmbed / GTKPlug / System tray implementations (server and client).
Additionally, we've been having more and more problems as the Win32 dialogs diverge, so we're either backing those out to GTK's, or making it a runtime switch.
So guys please select a way for UniConvertor integration. As for our project we have resolved support issues from our users concerning UniConvertor update providing current UniConvertor MSI package. But I can not insist on a certain variant of Inkscape development because you better know the objectives, methods and requirements of your project. Nevertheless we are ready improving any integration variant.
Regards,
Igor Novikov sK1 Project http://sk1project.org
On Fri, Jul 9, 2010 at 11:46 AM, Jon Cruz <jon@...18...> wrote:
On Jul 9, 2010, at 1:40 AM, Igor Novikov wrote:
uniconvw is pyGtk based so it's the same toolkit as Inkscape used.
Actually there is no problem in using GUI way because it has the same L&F and this dialog can be screen centered. Even transitional and modal features is possible if you will pass Inkscape window xid/winID. Under Windows to look more natively Inkscape calls WinAPI dialogs. So it's already toolkit mixing. But under win platform it's considered like rather advanced feature than a bad coding. At opposite cmd window for translation process is a worst case. Common win pattern is: avoid using command line, prefer library function calls.
Well... there are many differences, *especially* if we go with separate installs. I've worked in this area a lot, so I've seen many of the surprises.
Passing win id's is also very problematic. This was, among other things, a big problem with the XEmbed / GTKPlug / System tray implementations (server and client).
Additionally, we've been having more and more problems as the Win32 dialogs diverge, so we're either backing those out to GTK's, or making it a runtime switch.
Igor Novikov wrote:
So guys please select a way for UniConvertor integration. As for our project we have resolved support issues from our users concerning UniConvertor update providing current UniConvertor MSI package. But I can not insist on a certain variant of Inkscape development because you better know the objectives, methods and requirements of your project. Nevertheless we are ready improving any integration variant.
So, just to be clear, what ways are there for calling UniConverter? A command-line executable and a GUI? Both stand-alone applications?
If so, I think I would prefer calling a commandline executable, it's not that difficult to prevent a "dos prompt" popping up on Windows and catching stdout if necessary (in principle it could even be used to communicate with Inkscape). This would probably give us much less trouble then trying to interoperate with a GUI program on different platforms (not impossible, but much less flexible and more prone to "weird" issues).
Jasper van de Gronde wrote:
Igor Novikov wrote:
So guys please select a way for UniConvertor integration.
I would also prefer a commandline executable (Win32). I have Uniconvertor 1.1.4 installed separately under Python 2.6. For me the ideal solution would be to be able to use Uniconvertor 1.1.4 in Inkscape rather than the 1.1.3 that is shipped. I don't know how to do this (admittedly have not tried very hard).
I will not be installing 1.1.5 on my machine because of the size; the .msi file is 13.9 MB compared to an .exe file which was 769 K for version 1.1.4.
Alvin Penner
On Sat, Jul 10, 2010 at 5:54 PM, Alvin Penner <penner@...1856...> wrote:
Jasper van de Gronde wrote:
Igor Novikov wrote:
So guys please select a way for UniConvertor integration.
I would also prefer a commandline executable (Win32). I have Uniconvertor 1.1.4 installed separately under Python 2.6. For me the ideal solution would be to be able to use Uniconvertor 1.1.4 in Inkscape rather than the 1.1.3 that is shipped. I don't know how to do this (admittedly have not tried very hard).
I think it's not a good idea. Why use an outdated version? If you need built-in UniConvertor so ver.1.1.5 is better than 1.5 year old 1.1.4 release. MSI package size is so large because it includes own Python copy.
We have created stand alone version because a lot of win users cannot understand all required installation steps. They prefer downloading 13Mb file than experimenting with separate Python MSI, PIL, ReportLab and UniConvertor .exe installers.
Also, IMHO installation size does not matter now. Average modern HDD capacity is 1Tb and Win7 requirements for HDD is much more than 1Gb.
Regards,
Igor Novikov sK1 Project http://sk1project.org
2010/7/10 Igor Novikov <igor.e.novikov@...400...>:
We have created stand alone version because a lot of win users cannot understand all required installation steps. They prefer downloading 13Mb file than experimenting with separate Python MSI, PIL, ReportLab and UniConvertor .exe installers.
What exactly is the reason UC 1.1.5 doesn't work when dropped into Inkscape's Python directory? I can update Inkscape devlibs to the versions required by UniConvertor 1.1.5, and add any needed stuff.
I think the main problem is that UniConvertor is not perceived by users as a separate application, but as an integral part of Inkscape. The majority of users is probably not even aware of its existence. For me, shipping 1.1.5 but interoperating with a standalone install if present is the way to go; this way a person that hits an import bug can install a newer version but the rest is never bothered.
Additionally, let's not forget about point releases like 0.47.1. I think they can be used for UniConvertor upgrades, and UC upgrades would be an important motivating factor to actually have them.
Also, IMHO installation size does not matter now. Average modern HDD capacity is 1Tb and Win7 requirements for HDD is much more than 1Gb.
Installation size doesn't matter but download size still does.
Regards, Krzysztof
2010/7/10 Krzysztof Kosiński <tweenk.pl@...400...>
2010/7/10 Igor Novikov <igor.e.novikov@...400...>:
We have created stand alone version because a lot of win users cannot understand all required installation steps. They prefer downloading 13Mb file than experimenting with separate Python MSI, PIL, ReportLab and UniConvertor .exe
installers.
What exactly is the reason UC 1.1.5 doesn't work when dropped into Inkscape's Python directory? I can update Inkscape devlibs to the versions required by UniConvertor 1.1.5, and add any needed stuff.
It's just require more efforts than for previous version. But there is no serious reason to use old 1.1.4 version vs 1.1.5
I think the main problem is that UniConvertor is not perceived by users as a separate application, but as an integral part of Inkscape. The majority of users is probably not even aware of its existence. For me, shipping 1.1.5 but interoperating with a standalone install if present is the way to go; this way a person that hits an import bug can install a newer version but the rest is never bothered.
Additionally, let's not forget about point releases like 0.47.1. I think they can be used for UniConvertor upgrades, and UC upgrades would be an important motivating factor to actually have them.
This issue we have resolved in 1.1.5 version providing integration patch for Inkscape. If you will decide using internal UniConvertor we will continue supporting this patch for next Inkscape versions.
Also, IMHO installation size does not matter now. Average modern HDD capacity is 1Tb and Win7 requirements for HDD is much more than 1Gb.
Installation size doesn't matter but download size still does.
If user has downloaded Inkscape (~40Mb) so downloading of 13Mb is not a problem.
Regards,
Igor Novikov sK1 Project http://sk1project.org
Igor Novikov wrote:
If you will decide using internal UniConvertor we will continue supporting this patch for next Inkscape versions.
- is this patch currently available? - what is the difference between this patch and the full .msi download which is present on your website?
On Sun, Jul 11, 2010 at 12:33 AM, Alvin Penner <penner@...1856...> wrote:
Igor Novikov wrote:
If you will decide using internal UniConvertor we will continue supporting this patch for next Inkscape versions.
- is this patch currently available?
- what is the difference between this patch and the full .msi download
which is present on your website?
The patch is a small GUI vbs script accessible from Windows Start menu after UniConvertor MSI installation. Also in UniConvertor menu group you can find HTML description of the patch. So it just a part of MSI and can be found in project SVN.
http://uniconvertor.svn.sourceforge.net/viewvc/uniconvertor/UniConvertor/tru...
Regards,
Igor Novikov sK1 Project http://sk1project.org
W dniu 10 lipca 2010 22:42 użytkownik Igor Novikov <igor.e.novikov@...400...> napisał:
2010/7/10 Krzysztof Kosiński <tweenk.pl@...400...> It's just require more efforts than for previous version. But there is no serious reason to use old 1.1.4 version vs 1.1.5
What exactly needs adding / updating in order for 1.1.5 to work as an internal installation, e.g. one that uses Inkscape's Python and GTK stack? By the way, if you have commit access to Inkscape trunk, you also have commit access to Inkscape devlibs.
2010/7/10 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
Speaking of which, what are we going to do about new file formats supported by UC 1.1.5 and not recognizable by 0.48?
They require writing .inx files like share/extensions/sk1_input.inx and share/extensions/sk1_output.inx. AFAIK no other changes are necessary.
Regards, Krzysztof
2010/7/11 Krzysztof Kosiński <tweenk.pl@...400...>
W dniu 10 lipca 2010 22:42 użytkownik Igor Novikov <igor.e.novikov@...400...> napisał:
2010/7/10 Krzysztof Kosiński <tweenk.pl@...400...> It's just require more efforts than for previous version. But there is no serious reason to use old 1.1.4 version vs 1.1.5
What exactly needs adding / updating in order for 1.1.5 to work as an internal installation, e.g. one that uses Inkscape's Python and GTK stack?
At first you need adding sk1libs package, after that uniconvertor package. Building requirements you can find in setup.cfg Also you can take a look at sk1libs/setup_win32.py
I think all libs are already in Inkscape bundle because it uses the same native libs as UniConvertor (libjpeg, libfreetype, liblcms etc.)
By the way, if you have commit access to Inkscape trunk, you also have commit access to Inkscape devlibs.
No I haven't.
Regards,
Igor Novikov sK1 Project http://sk1project.org
On 7/11/10, Igor Novikov wrote:
What exactly needs adding / updating in order for 1.1.5 to work as an internal installation, e.g. one that uses Inkscape's Python and GTK stack?
At first you need adding sk1libs package, after that uniconvertor package. Building requirements you can find in setup.cfg Also you can take a look at sk1libs/setup_win32.py
I think all libs are already in Inkscape bundle because it uses the same native libs as UniConvertor (libjpeg, libfreetype, liblcms etc.)
So, do we have this solved for Windows and/or Mac?
Alexandre Prokoudine http://libregraphicsworld.org
2010/8/13 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
So, do we have this solved for Windows and/or Mac?
I managed to build sk1libs and uniconvertor 1.1.5 on Windows today. I'll update the devlibs once I verify that it works.
Regards, Krzysztof
On 13/8/10 03:02, Alexandre Prokoudine wrote:
On 7/11/10, Igor Novikov wrote:
What exactly needs adding / updating in order for 1.1.5 to work as an internal installation, e.g. one that uses Inkscape's Python and GTK stack?
At first you need adding sk1libs package, after that uniconvertor package. Building requirements you can find in setup.cfg Also you can take a look at sk1libs/setup_win32.py
I think all libs are already in Inkscape bundle because it uses the same native libs as UniConvertor (libjpeg, libfreetype, liblcms etc.)
So, do we have this solved for Windows and/or Mac?
Mac: UniConvertor was never bundled with Inkscape on OS X.
Unfortunately there are no UniConvertor 1.1.5 packages for OS X available for download, and according to http://sk1project.org/forum/viewthread.php?thread_id=114 UniConvertor 1.1.5 fails to work on OS X if built from the sources (I haven't yet tried myself to build 1.1.5, only 1.1.4 and SVN r187).
AFAIU bundling UniConvertor with Inkscape.app for all the supported platforms/archs would likely increase download size too much. OTOH many Mac users don't have the skills to install it on the command line, and a recent request for a UniConvertor port in MacPorts hasn't seen further activity yet http://trac.macports.org/ticket/26016.
~suv
On Fri, Aug 13, 2010 at 5:40 AM, ~suv <suv-sf@...58...> wrote:
On 13/8/10 03:02, Alexandre Prokoudine wrote:
On 7/11/10, Igor Novikov wrote:
What exactly needs adding / updating in order for 1.1.5 to work as an internal installation, e.g. one that uses Inkscape's Python and GTK stack?
At first you need adding sk1libs package, after that uniconvertor
package.
Building requirements you can find in setup.cfg Also you can take a look
at
sk1libs/setup_win32.py
I think all libs are already in Inkscape bundle because it uses the same native libs as UniConvertor (libjpeg, libfreetype, liblcms etc.)
So, do we have this solved for Windows and/or Mac?
Mac: UniConvertor was never bundled with Inkscape on OS X.
Unfortunately there are no UniConvertor 1.1.5 packages for OS X available for download, and according to http://sk1project.org/forum/viewthread.php?thread_id=114 UniConvertor 1.1.5 fails to work on OS X if built from the sources (I haven't yet tried myself to build 1.1.5, only 1.1.4 and SVN r187).
AFAIU bundling UniConvertor with Inkscape.app for all the supported platforms/archs would likely increase download size too much. OTOH many Mac users don't have the skills to install it on the command line, and a recent request for a UniConvertor port in MacPorts hasn't seen further activity yet http://trac.macports.org/ticket/26016.
~suv
This SF.net email is sponsored by
Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I think the problem is rather incorrect build issue than real bug in the ft2 module. If MacOS X build is important for Inkscape release I could testing UniConvertor build under MacOS X Leopard.
2010/8/13 Igor Novikov <igor.e.novikov@...400...>:
I think the problem is rather incorrect build issue than real bug in the ft2 module. If MacOS X build is important for Inkscape release I could testing UniConvertor build under MacOS X Leopard.
There are a few changes I had to make before UC compiled on Windows 1. MinGW requires you to include windows.h before wingdi.h 2. There is a file that includes (possibly indirectly) both basetsd.h and windows.h - these two files have conflicting typedefs 3. DL_IMPORT declarations on global extern variables cause link failures - they are only needed if the variable is in a different DLL
Regards, Krzysztof
On 7/10/10, Krzysztof Kosiński wrote:
Additionally, let's not forget about point releases like 0.47.1. I think they can be used for UniConvertor upgrades, and UC upgrades would be an important motivating factor to actually have them.
Speaking of which, what are we going to do about new file formats supported by UC 1.1.5 and not recognizable by 0.48?
Alexandre Prokoudine http://libregraphicsworld.org
participants (7)
-
Alexandre Prokoudine -
Alvin Penner -
Igor Novikov -
Jasper van de Gronde -
Jon Cruz -
Krzysztof Kosiński -
~suv