- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Interpolate
by Jose Hevia 15 May '05

15 May '05

> bulia byak wrote: > > On 5/14/05, aaron@...749... <aaron@...749...> wrote: > >>Please download the latest version. It should no longer have this > >>limitation. Thanks for your help. > > > > Excellent, subdivision works now. Generally the results are very good, > > but there's one glitch illustrated by the attached file: the left path > > has 2 nodes and the right one 3, so the left one is subdivided, but > > interpolation gives wrong length and direction of the bezier handle at > > the bottom node near the left path (i.e. the points A and B have too > > different bezier handles, so there's a visible gap there). This may be > > caused by some error in the subdivision function (the top and middle > > nodes in the subdivied path seem to be OK, it's only the bottom one > > that is off). > > Ah yes, I see. I will look at that. Side note. I can't run the > interpolate script on the file you sent me. It fails with an xml > namespace error. strange. > > Also opening an svg created on such a large screen makes me wonder. > Could Inkscape be taught to open maximized if the window size stored in > the document is larger than the screen? I find windows that are larger > than my screen difficult to work with. I wonder if other people feel > that way too. > > Aaron Spike Not really, in Linux you could press Alt ,then drag the entire window with the mouse. Jose Hevia

1 0

dangerous duplication - please fix
by bulia byak 14 May '05

14 May '05

(I'm not sure if this will get through to the list, so I'm cc'ing those who did commits to the relevant dir) Today I reviewed our po files and noticed a lot of new UI strings coming from the ui/ directory. This needs to be fixed immediately, or at least before we declare the string freeze and call the translators to update translations. These new strings are really a very bad idea for several reasons: - They are duplicate of strings found elsewhere, but often non-exact duplicates (or their originals have changed since they were copied). This means a lot of useless extra work for translators, dangers of further desynchronization, etc. - These strings are sometimes "fixed" wrongly. For example in stock-items.cpp, someone wrote "Select _Original Clone" instead of the "Select _Original". This "correction" simply does not make sense; what is meant is "select the original _of the_ clone" but even in that form it's wrong because it is applicable not only to clones. - Most strings in ui/view/edit.cpp have hard-coded shortcuts in them, e.g "Next zoom (from history of zooms) (Shift+`)". This is absolutely intolerable, for obvious reasons. The old code has special provisions for generating shortcut strings for the UI, and losing that is a serious regression. I can see several approaches to fixing this, please choose one or more as appropriate: 1. If this ui/ code is unused and is not going to be used, simply delete it and regenerate the po's. 2. If it is currently unused but may be used later, at least remove it from the list of po sources, so it does not contaminate the po files, until it is fixed properly. 3. Rewrite the code so that, where possible, it takes the strings from the standard central location. For example all verbs have their commands and tooltips in verbs.cpp, so copying them over into ui/stock-items.cpp is very very wrong. 4. Where 3. is not appropriate and you want to move some of the strings into some new code or structure, do this ONLY when that new code or structure is fully workable, and then immediately delete them from the source location, so that there's no duplication ever. Until then, use some placeholder strings in your code and make sure they don't get into the po files. As you may have noticed, I'm _constantly_ revising and copyediting the UI strings, because it's such an important aspect of the UI. Please don't undermine my efforts. I hope this mess is cleaned as soon as possible. Thanks! -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 4

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