May 2005 - Inkscape Devel - Inkscape Mailman

Fwd: Re: [cairo] MOZ-SVG-cairo (was: usable libsvg-cairo?)
by unknown＠example.com 13 May '05

13 May '05

----- Forwarded message from Liam Breck <svg@...808...> ----- Date: Thu, 12 May 2005 01:25:39 -0400 From: Liam Breck <svg@...808...> Reply-To: Liam Breck <svg@...808...> Subject: Re: [cairo] MOZ-SVG-cairo (was: usable libsvg-cairo?) To: cairo@...278... Considering the progress on Mozilla SVG, we're looking at pulling the Mozilla SVG cairo backend into a standalone library, wrapped for use outside Mozilla. It wouldn't parse the XML, but it would let you use any parser or content model to drive rendering. We need this (or something similar) for SVGTerm, a mechanism that continually updates an SVG scene on one or more remote screens. (Embedding Gecko would be overkill for this app.) Is this something that others would like to have? Would anyone foresee problems with this approach? Liam Breck Network Improv http://networkimprov.net/airwrx/ ------------------- Date: Wed, 11 May 2005 20:06:41 +0800 From: Charles Wang <charles.wang@...809...> Subject: [cairo] Is there a usable libsvg-cairo? To: cairo@...278... Message-ID: <1115813201.5852.2.camel@...16...> Content-Type: text/plain Hi: I just want to use libsvg-cairo to render SVG into cairo_surface, but the libsvg-cairo can not pass compilation. I think the code of libsvg- cairo is out-dated because the rapid change of cairo API. Can I get some older version of cairo to let the current libsvg-cairo work correctly? Thanks greatly. Charles May 11, 2005. _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo ----- End forwarded message -----

3 3

keeping one single inkscape process
by Pim Snel 13 May '05

13 May '05

Hi, Is it possible to hook into an existing inkscape process. I thought sodipodi had an command line option --unique once which made sodipodi use an exiting process when opening a new file. Gimp has a utility called gimp-remote which has the same functionality. Thanks for this amazing project. Pim Snel

2 1

Re: problem with parasite cross over in translations
by Arpad Biro 12 May '05

12 May '05

Hi, > This patch was focusing on /src/select-toolbar.cpp so that X, Y, > W (idth), H (eight) strings become translatable. > The problem is that now, in all .pot file, H can conflict with > H (ue) of the color tab of clonetiler.cpp dialog. There's a solution for this kind of problem: context sensitive strings. An example from a KDE translation file (kdelibs.po): ------------------- #: kdecore/kcalendarsystemgregorian.cpp:99 kdecore/klocale.cpp:550 msgid "" "_: May short\n" "May" msgstr "mag" #: kdecore/kcalendarsystemgregorian.cpp:127 kdecore/klocale.cpp:566 msgid "" "_: May long\n" "May" msgstr "maggio" ------------------- These two strings above are from the same (Italian) PO file. If the UI language is English, then the appropriate KDE applications will display "May" in both cases, but if the UI language is Italian, then one of the strings will be "mag", while the other will be "maggio". As you can see, there can be multiple translations for the _same_ English string, you just have to differentiate them with context (the "_: blah blah blah\n" lines before the English strings). The Italian ("it") PO file I used as example is here: http://webcvs.kde.org/kde-i18n/it/messages/kdelibs/kdelibs.po Arpad Biro Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

2 1

Re: [Inkscape-user] Effects on Windows
by unknown＠example.com 12 May '05

12 May '05

aaron@...749... wrote: > Kevin Wixson wrote: > > aaron@...749... wrote: > >> On a related note can anyone tell me how to install XML::XQL::DOM with > >> ActiveState Perl on Windows? It is required for the DropShadow effect, > >> so it might be a useful bit of info to have hanging around in the > >> mailing list archives. > >> >> To install packages with ActiveState Perl you should use the PPM (Perl >> Package Manager) app. From the command line type "ppm" to start the >> app, then "search XQL" or "search DOM" to get a listing of related >> packages. Then use the install method of PPM to get the package and >> install it once you've found what you're looking for. > > But what do I do when the module doesn't turn up as a result of either > of those searches? Can I configure an alternative repository? Or > download the package and install by hand? I thought perhaps someone had > installed it successfully and could relate the steps they took. Well I made it work but my method just doesn't seem to be the right way. 1: install prereqs with ppm: install xml-dom install parse-yapp install datemanip 2: download xml-xql from: http://www.cpan.org/authors/id/T/TJ/TJMATHER/XML-XQL-0.68.tar.gz 3: open command prompt and locate perl's lib directory with: perl -e "print qq(@INC)" (mine was C:/Perl/site/lib) 4: unpack xml-xql archive 5: copy contents of XML-XQL-*\lib\XML into C:\Perl\site\lib\XML 6: copy XML-XQL-*\XQLParser\Parser.pm to C:\Perl\site\lib\XML\XQL Aaron Spike

1 0

Effects on Windows
by unknown＠example.com 11 May '05

11 May '05

It looks like the Win32 snapshot builds linked on the downloads page have been absent for the last few days. But Bob Jamison had one from May 11, 2005. I just tested it and Effects now work unmodified on Windows. Thanks Ted. On a related note can anyone tell me how to install XML::XQL::DOM with ActiveState Perl on Windows? It is required for the DropShadow effect, so it might be a useful bit of info to have hanging around in the mailing list archives. Aaron Spike

3 7

Inkscape 0.42 and gtkmm
by Bryce Harrington 11 May '05

11 May '05

Hi all, Recently I've been appraising how much work it's going to take to achieve the goal we set for 0.42 to get converted to gtkmm. The choice to switch to gtkmm was made at the very start of the project, so it's always been one of our biggest goals. Several actions we took in our earlier releases were geared towards this end. In fact, we've been planning to convert to gtkmm for several releases now. Of course, this is not a trivial undertaking. Initially we approached doing it piecemeal, one dialog at a time. Several dialogs got converted, but we noticed that each dialog turned out surprisingly different than the others. This is where I got involved - to try to help establish some common practices for implementing dialogs. I also figured that even though I had other stuff I wanted to work on (i.e. markers and extensions), for project priorities it was probably more valuable to pitch in with getting progress on the gtkmm stuff. Today I think the new dialog code is pretty good. There is a base class we can use for dialogs, that provides the common behaviors, and a DialogManager to better track their memory and instantiation. The individual dialogs still need to all be converted over, but we've already got a handful converted, and there's another handful that are already in gtkmm but just need to be restyled to work with the new code. So now, the rest of the dialog conversion work *can* be done piece by piece, without risking problematic inconsistencies. However, converting to gtkmm means much more than just converting each dialog; the main interface (toolbars, buttons, canvas, etc.) also needs to be turned into gtkmm code. This requires conversion of SPView, SPSvgView, SPDesktop, and SPDesktopView. SPDesktop alone is a pretty big project; I've been hammering at it bit by bit for the past few months but feel like I've barely made a dent. It's pretty frustrating; I feel like I'm pulling the proverbial thread from the sweater. Anyway, given what it looks like needs to be done, I don't really have the time/patience/energy to see the View/Desktop work through to completion by myself. There are other things I want to do for Inkscape and Open Clip Art that are higher priority to me. If someone else wants to work on it, I can share what I've learned and explain what it looks like needs to be done. Finally, given this, I see no point in continuing with the goal of completing gtkmm for 0.42. It's just too much effort, compared with the number of people committed to working on it. I hate the idea of having to yet again bump it to the next release, though. If it couldn't be achieved for 0.39, 0.40, 0.41, and 0.42, why would we think it could be done for 0.43? I think that given the lack of activity, the most logical thing is to just postpone it indefinitely. The work just seems to get in the way of making releases, and given that people are more interested in working on misc. individual things rather than gtkmm, anyway, there's little value in setting it as a goal; it just sets up expectations that are proving unachievable. The desire for a release is clearly much higher than the desire to finish implementing gtkmm at this time. Thus, I would like to propose we scrap the remaining plans for 0.42 in the roadmap, and go ahead and start the 0.42 release process. Opinions? Bryce

5 9

[bryce@...260...: Re: inkscape/po/POTFILES.in]
by Bryce Harrington 11 May '05

11 May '05

Peter, FYI -- ----- Forwarded message from Bryce Harrington <bryce@...260...> ----- Date: Mon, 9 May 2005 15:41:11 -0700 From: Bryce Harrington <bryce@...260...> To: Arpad Biro <biro_arpad@...36...> Subject: Re: inkscape/po/POTFILES.in Hmm... Sorry, I didn't realize it had been put in intentionally. That line was causing several of us compile errors yesterday; is there any other way we could address the underlying issue? Bryce On Mon, May 09, 2005 at 03:28:29PM -0700, Arpad Biro wrote: > Hi, > > I needed to revert your change in $SUBJECT, which means I added > "[encoding: UTF-8]" again to that file. I need that line because > otherwise the following happens: > > # ../intltool-update --pot > ERROR: xgettext failed to generate PO template file because there is > non-ASCII > string marked for translation. Please make sure that all strings > marked > for translation are in uniform encoding (say UTF-8), then > *prepend* the > following line to POTFILES.in and rerun intltool-update: > > [encoding: UTF-8] > > > > > Because of this, I cannot update PO files without that line. > > > Arpad Biro > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ----- End forwarded message -----

2 1

Inkscape 0.42 release plans
by Bryce Harrington 11 May '05

11 May '05

Hi all, After talking several developers, I think the idea of a release is good, but folks still have development work to finish up. I think we should leave the rest of this month to development, and move into a bug fixing phase starting around June 1st, with a goal of producing 0.42 some time in June or early July. Bryce

1 0

simple bug fix for configure.ac
by Jeremy C. Reed 11 May '05

11 May '05

Please fix the test = conditional in configure.ac. -if test "x$gc_ok" == "xyes"; then +if test "x$gc_ok" = "xyes"; then This == is not portable. If replying, please carbon-copy me. Jeremy C. Reed BSD News, BSD tutorials, BSD links http://www.bsdnewsletter.com/

2 1

problem with parasite cross over in translations
by unknown＠example.com 10 May '05

10 May '05

Hi A few days ago, I've submitted small patch and Bulia has kindly commited it. This patch was focusing on /src/select-toolbar.cpp so that X, Y, W (idth), H (eight) strings become translatable. The problem is that now, in all .pot file, H can conflict with H (ue) of the color tab of clonetiler.cpp dialog. See the following extract of fr.po # Hue (in HSV) # Dialog item #: src/dialogs/clonetiler.cpp:2170 src/select-toolbar.cpp:424 msgid "H" msgstr "T" and the attached screenshots So I'm afraid my idea of having those strings translatable was not so good, and my patch, a dummy one... Maybe Arpad or another experienced translator has already faced the same kind of problem and knows a workaround (I hope). I apologize for the annoyance. Regards, Matiphas

1 0