May 2005 - Inkscape Devel - Inkscape Mailman

Re: [cairo] SVG scene lib]
by Bryce Harrington 15 May '05

15 May '05

> ---------- Forwarded message ---------- > From: Liam Breck <svg@...808...> > > Proposed: An SVG Scene (aka canvas) Library for Cairo > Feedback requested! > > The Inkscape Wiki discusses an SVG-based canvas lib, but it looks far out > on their roadmap. Could any Inkscape folks comment? Hi Liam, Yes, it's definitely something we want to migrate to but no one is currently working on creating it in canvas form. Inkscape's canvas code can be found in the inkscape/src/display/ directory, and might be worth reviewing for ideas. It's essentially a port of GnomeCanvas that has evolved for our own needs. The API of this code includes functions for things like: * grabbing/ungrabbing focus * Requesting/performing updates/redraws * getting z-order of a given item * Scrolling * calculating if a given point is in the window * getting/setting windows/viewboxes and their coords * Getting the currently selected item(s) * Handling grid overlays * etc. Bryce

1 0

Fwd: [cairo] SVG scene lib
by Ashwin Bharambe 15 May '05

15 May '05

---------- Forwarded message ---------- From: Liam Breck <svg@...808...> Date: May 15, 2005 3:47 PM Subject: Re: [cairo] SVG scene lib (was: MOZ-SVG-cairo) To: cairo@...278... Proposed: An SVG Scene (aka canvas) Library for Cairo Feedback requested! Goals Provide functionality & perfomance suitable for creating full UI/page/etc. Enable multi-client/collaborative applications Enable lightweight applications for mobile platforms Enable presentation of compound documents Features & Requirements Implement SVG object model Render to Cairo; any Cairo backend Layout text with Pango (what about flowText?) Support incremental rendering (differences only) Provide model API for insert/delete/update/z-move Support out-of-process API calling, i.e. for compound documents Provide API to identify SVG object & group at xy, i.e. for hit-testing Allow out-of-band regions (non-SVG, non-Cairo), e.g. video/3D Allow higher-level widgets/applets to "own" model objects Allow use in various frameworks GTK/QT/airWRX/Cocoa/.NET/Python/Java Support multiple clients/viewers of a scene on IP network Support client-specific objects, and properties, e.g. text selection When there's some consensus, I'll crank out a lib for cairo-win32 from our existing code, write a demo app, and release as a prototype under LGPL. The Inkscape Wiki discusses an SVG-based canvas lib, but it looks far out on their roadmap. Could any Inkscape folks comment? Liam Breck Network Improv http://networkimprov.net/airwrx/ _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

1 0

inkscape in the press
by Adib Taraben 15 May '05

15 May '05

the german Lunux-User magazin issue 5/2005 from 21st april had an artikel. "Perfekte Vektorgrafiken in Inkscape" http://www.linux-user.de/ausgabe/2005/05/053-inkscape/index.html http://www.linux-user.de/ I only saw the link and do not have this magazin. Just let you know.

3 2

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

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

LaTeX Export
by Michael Forbes 10 May '05

10 May '05

I am trying to develop a barebones LaTeX export extension. I have wrote the code mostly based of the PovRay export and included the .h and .cpp file in src/extension/internal/Makefile_insert. libinternal.a includes the extension but the main program does not. Can anyone help me with this? Thank you. -Michael Forbes ------------------------------------------------------------ Student System Operator binx.mbhs.edu BEN Manager http://ben.mbhs.edu BNC Internet Division http://bnc.mbhs.edu MBHS Webmaster http://www.mbhs.edu BlazerNet President http://blazernet.mbhs.edu Computer Team Co-President http://computerteam.mbhs.edu MBLUG President http://mblug.mbhs.edu ------------------------------------------------------------

5 10

Defaulting gnome-vfs to yes
by Bryce Harrington 10 May '05

10 May '05

I've committed a change to configure.ac which defaults the GNOME VFS feature to 'on' if automake detects that the Gnome VFS library is present on the system. Keep an eye out for bugs; I've fixed all the ones I've known about. As a reminder, the GNOME VFS feature makes it possible to specify a URL on the commandline when starting inkscape. I.e.: $ inkscape http://mysite.org/foobar.svg It will load the svg file via http into memory and launch Inkscape. There is no support for this in the File Open dialog at this time; it still works only with local files. I don't have any plans to change that, so if you want it, feel free to add it. Bryce

3 4

NEW: <style> rendering support
by Peter Moulder 10 May '05

10 May '05

Inkscape now understands <style> elements: it correctly renders the following simple document: <svg> <defs> <style type="text/css"> .strokeblue {stroke:blue;stroke-width:5} .fillred {fill:red} </style> </defs> <rect x="10" y="10" width="50" height="50" /> <rect x="70" y="10" width="50" height="50" class="strokeblue" /> <rect x="130" y="10" width="50" height="50" class="fillred" /> <rect x="190" y="10" width="50" height="50" class="fillred strokeblue" /> </svg> There are a number of limitations: - Allows a single <style> element in the document. Doesn't allow external stylesheets, doesn't allow more than one <style> element. (Or rather it ignores all but one of the <style> elements, possibly changing which one it respects based on which was most recently re-read.) See notes below. - No editing interface other than the XML editor. (There are two parts to this: (i) editing the stylesheet; (ii) specifying what classes each object belongs to.) - Doesn't respect media restrictions (e.g. ignores "this rule applies only to non-visual media" directives, and doesn't allow having one style for print and another style for on-screen). - Someone more familiar with how to subclass an SPObject (i.e. what methods need to be instantiated and how) should have a look at sp-style-elem.cpp. - Not tested much. > > As members of the s4-p18, me Mamdouh El Tabech and Nicolas Jacquey, we are > > interested now in trying to solve the bug of global style. > > > The problem is divided into two, whether the style was included in the > > beginning of the document or it was in an extra file. > > > Do you have any idea to help us in where and what to change? The limitation of just one author stylesheet per document is an oversight in libcroco datastructures. Dodji (libcroco maintainer) agrees it's a libcroco bug, and the CRCascade or CRStyleSheet data structure can be changed accordingly. (The way most of libcroco implements `list of T' is for the T struct to get next/prev members, i.e. add next & prev members to CRStyleSheet, add cr_stylesheet_* functions for accessing this list, and leave CRCascade unchanged. Not saying I like the current scheme, but I think we should use the same scheme throughout libcroco, and consider changing the scheme throughout libcroco at once.) Meanwhile, Inkscape will also need changing: SPStyleElem's read_content method will need to update just its own CRStyleSheet, and we'll need to make sure that the list of stylesheets in the CRCascade matches the order of their occurrence in the document, so that we get the right precedence when stylesheets conflict with each other. I don't know the right way of handling external stylesheets. Does any other part of inkscape allow external xlink:href's ? libcroco's CRInput either already allows URLs or at least has it planned. (I don't have the source code handy here.) Handling @media rules and <style>'s media attribute is a Simple Matter of Programming. Existing code: SPStyleElem has a media field defined in media.{cpp,h}, initialized to all media. pjrm. -- bbyak: swatches, rich text, gradient on canvas... JonCruz: The answer to the ultimate question of life, the universe, and everything... JonCruz: Inkscape 0.42!!!!!!!

2 1

Adobe Photoshop 8.0 - 75% OFF
by Kendra L.Brown 10 May '05

10 May '05

Get all the popular software possible for extremely low prices! Our software is 2-10 times cheaper than sold by our competitors. Just a few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Enter here: http://www.ineedsoft.biz Regards, Kendra Brown _____________________________________________________ To be taken off future campaigns, go: http://www.ineedsoft.biz/uns.htm _____________________________________________________

1 0

translation of HACKING and README
by Arpad Biro 09 May '05

09 May '05

Hi, We have a French translation for inkscape/HACKING and inkscape/README in the tracker: http://sf.net/tracker/index.php?func=detail&aid=1190412&group_id=93438&atid… I committed them as inkscape/HACKING.fr and inkscape/README.fr respectively. Please let me know if we should use some other filename or location instead. Arpad Biro __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

5 5

SPView moved to src/ui/view/
by Bryce Harrington 09 May '05

09 May '05

I've moved the view.* code into src/ui/view/. Eventually svg-view* and all of the *desktop* stuff will move into this subdir as well. I checked compilation and that inkscape runs, but it's possible this change will cause breakage somewhere, so please keep an eye out. Bryce

1 0

gtkmm - DialogManager in SPDesktop
by Bryce Harrington 09 May '05

09 May '05

I've added the DialogManager into the old SPDesktop. This means that the current codebase can now use the new dialogs via DialogManager. It also means that the way is now open for anyone that wishes to create new gtkmm dialogs using the new dialog code. I have hooked in one dialog - Messages (aka ishmal's Debug Dialog). I chose this because it's a finished dialog, and because I figure it's not as critical as some of the drawing dialogs, in case it misbehaves. If you wish to create a new dialog, please feel free to use the Messages dialog as an example. To add a new dialog, the process is straightforward: 1. Create a .cpp and .h for your dialog in src/ui/dialog/. The dialog must derive from Dialog (see dialog.*). 2. Add your class to DialogManager. You do this by adding an #include to dialog-manager.cpp, add a member pointer to the DialogManager class in dialog-manager.h, and a get*Dialog() routine (you can just cut and paste from one of the other dialogs). 3. Add a menu item and shortcut key for your dialog. See verbs.cpp and interface.cpp. I think you'll find that creating dialogs with the new system can be done in about half the code as before, and maintenance is greatly increased since the common boilerplate code is factored out into base classes. Also, the classes are simpler in that they have fewer pointers, and don't need to handle their own instantiation; DialogManager takes care of this. Fewer pointers and less need for memory management implies fewer opportunities for bugs to creep in. Also, since DialogManager is used for accessing dialogs, there is no need to include the dialog headers in other parts of the code; theoretically this should cut down on include header nesting and make compilation work a bit faster. Some caveats: The preferences loading/saving code isn't implemented. This means that dialogs won't "remember" their settings between program runs. However, there is code to track this info in there, so should be straightforward to hook up if anyone wishes. As well, some of the code for transient behavior is there, but not all, so transient behavior is probably not right. Feel free to fix; it's all implemented in the Dialog base class so only has to be fixed in one place, and then all dialogs will behave correctly. Bryce

1 0

gcc 4 help needed
by MenTaLguY 09 May '05

09 May '05

I've been told that line 111 of debug/logger.cpp doesn't compile with gcc 4. Could someone please give me the specific error (with all context lines, please)? -mental

2 3

English tutorials converted
by bulia byak 08 May '05

08 May '05

May 1st, 2005 — Thanks to the active help from the community, all English tutorials that we had in SVG are now converted to DocBook! From within Inkscape, they are still available as fully editable SVG which you can play with, but having the DocBook source makes it easy to produce any other formats or renditions automatically. In particular, all converted tutorials are now availble in HTML, linked from our Documentation page. What's next? We have several of the tutorials translated into several languages. Now we need to convert these to DocBook as well. Here is a page http://inkscape.org/cgi-bin/wiki.pl?TranslationInformation with details on how to translate tutorials or convert existing translations. We already have the Basic in Spanish and several French ones are being worked on; the rest are up for grabs. Pick a tutorial and make it available in your native language! -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 4

Re: Fwd: [s4-p18] [Inkscape-devel] svg2ps - Test Files
by MenTaLguY 08 May '05

08 May '05

On Sun, 2005-05-08 at 13:35, bulia byak wrote: > What I have at the moment is a couple of scripts that read the CSS2.1, > SVG1.1 and CSS3Text specs as downloaded off the w3c site, find all the > property definitions within them and automagically produce output such > as: > > /** \brief Representation of the CSS 'counter-reset' property > > Generated from "[ <identifier> <integer>? ]+ | none | inherit" > Inherit: False > Initial: none > */ > struct inkscape::style::css::counter_reset { > bool read(Glib::ustring const &str); > Glib::ustring write() const; > void set_to_initial(); > unsigned set:1; > unsigned inherit:1; > unsigned type:1; > struct inkscape::style::css::identifier { > unsigned integer_set:1; > struct css_identifier value_identifier; > struct css_integer value_integer; > }; What exactly does this sort of nested declaration mean? > std::vector<struct identifier> value_identifier; > enum {type_identifier, type_none}; > }; > 1) Where do I go from here? The simplest answer is to bundle the whole > lot into SPStyle, like we have at the moment. The problem with that is > of course that the current struct is at least 320 bytes and putting > all 160+ css properties into it would consume a significant amount of > memory in a large drawing. At the opposite end of the memory:cpu ratio > spectrum is to have no SPStyle at all and require everyone to call > read() themselves if they want a pre-parsed property. Half-way points > are of course possible too, where particularly common properties like > fill and stroke are held in SPStyle but everything else is evaluated > on each request. There are also lazy evaluation schemes which save the > results of the evaluation, and so on and so forth. My personal > favorite at the moment is to have most things lazy but a selected few > always calculated. That's probably the best long-term goal. For the short-term lumping everything into SPStyle is best because it is simple and is known to work. Longer-term I will have to get a better sense of the design before making any recommendations. Probably some sort of lazy thing backed by an associative data structure, queried by symbols (i.e. GQuark or the like) would be best. Whatever it ultimately is, the interface for lazy and non-lazy properties should remain uniform. > 2) The more fundamental question: am I even going in the right > direction? I'm replacing a simple yet difficult-to-maintain piece of > code with a complex yet zero maintainance (or close to it, anyway) > piece of code. What's the point anyway when I should only need to run > it once, then throw it away? Since the majority of properties are > simple enums, wouldn't it be easier to do it all by hand? Is this just > refactoring for its own sake, without any useful new features in > sight? (Actually that's not true; a proper implementation of shorthand > properties is notably lacking at the moment). In principle it's much better. Don't ever believe the "just once" part though. It's best to have the source specifications and the script that generates them in the source tree, and have them be authoritative. And generate the code as part of the build process. Because Things Will Change, and the last thing you want is to tempt people into manual hacking of generated code. Do see if you can hoist some of the stuff that's currently generated into non-generated superclasses though. Anything that gets repeated multiple places is screaming for refactoring. The platonic ideal is that there should only be one place in the entire codebase which is authoritative for a particular pattern of code. -mental

1 0