July 2007 - Inkscape Devel - Inkscape Mailman

back-compatibility: font name quoting
by MenTaLguY 05 Jul '07

05 Jul '07

It looks like recent trunk has begun putting single quotes around font names with spaces in them; I believe this is fine in terms of the CSS spec, except that recent released versions of Inkscape can't parse that and end up using the default font (generally bitstream vera) instead. Ideas? -mental

3 10

n00b questions
by joel＠...1709... 04 Jul '07

04 Jul '07

Hi, Given that I'm pretty new to the Inkscape developement world, I had a couple questions. The first is this: what hurdles stand between Inkscape today, and v1.0? I love using it, and I've now completely migrated over from CorelDRAW. I'm really keen to see Inkscape develop and become more and more popular, for a couple of reasons: 1. it's good for the world, and 2. more users mean more developers which means more features/innovation more quickly - which is good for me! v0.45.1 is great, and v0.46 will be even greater. I'm now happy to use Inkscape for most of my design work. It's not perfect - it's a bit rough around the edges, but in general it does the job pretty well. From my point of view, the app needs a bit of polishing here and there to improve slickness, but generally it's in pretty good shape. However, reading the roadmap it says that we're at least 11 releases away from v1.0. If you're roughly on a 6 month release cycle, that puts v1.0 at least 5 years away! Surely that's not right? I worry that until Inkscape gets to >v1.0 it will be seen as "experimental" and "unstable" by many. I worry that until 1.0, the app will languish, not attracting the user base or developer base it deserves.. Companies won't trust it, and Ubuntu probably won't bundle it for example. So to rephrase my question: how many of the tasks in the roadmap are *truly* necessary? Maybe I'm being niéve, but surely inkscape doesn't have to be all things to all men - even at 1.0. Many of the ideas seem tantalysing; I can't wait. But surely we need to sort between "must have" and "nice to have". We can add the "nice to haves" into v1.1, or v2.0 just fine, no? I'll ask my second question in a second e-mail.

4 3

Re: [Inkscape-devel] Script Updates
by joel＠...1709... 04 Jul '07

04 Jul '07

For myself I would like to see as much live updating in inkscape as possible. The more visual feedback the user gets, the more fluid the app will feel. If using an effect were like compiling a program, then: no, you wouldn't want to update every time you change a line of code. Compiling is slow, and the intermediate results are completely useless. However, we're trying to help te user be artistic. Effects generally run quite quickly, and the intermediate results are often useful in helping the user find the magic combination of parameters that create just the right effect. Live updating needn't make inkscape feel slow if: 1. script threads run at low/medium a priority so the rest of the app/system don't lock up. 2. script execution is quickly aborted if the user changes a parameter, or presses cancel. On a connected topic: would it be worth adding some kind of optional progress API to the python set? This way potentially long running scripts can give some feedback as to the percentage progress that has been made. I think this could be useful when doing live preview, or when doing the final render. Otherwise a script is rather like the Turing Machine; you never whether to give up waiting. ---------------------------------------- From: "bulia byak" <buliabyak@...400...> Sent: 03 July 2007 10:35 To: "Ted Gould" <ted@...11...> Subject: Re: [Inkscape-devel] Script Updates On 7/3/07, Ted Gould wrote: > Well, I challenged whether this is required in a previous e-mail, and > you didn't respond. So I assumed that you thought my logic was > flawless :) It's not about logic. It's about "feel" if you like, about perception and doing what is expected. If I have a dialog with several parameters, and you set them in turn, you are not interested in seeing the result after only one parameter is set. But once you set the first parameter, you see something changing on your canvas and you waste your time trying to figure out what happened. This is annoying and wasteful (although, of course, in another situation where I want to fine-tune the parameters, it's a huge time saver). -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 1

Re: [Inkscape-devel] n00b questions
by joel＠...1709... 03 Jul '07

03 Jul '07

A thought just occured to me: would it be useful for someone to create a wiki page that contains a list of *all* the SVG features (maybe the contents page of some SVG specification), so that we can check off the things we have, and people like me can see what remains to be completed? ---------------------------------------- From: "Joshua A. Andler" <joshua@...533...> Sent: 03 July 2007 12:21 To: joel@...1709... Subject: Re: [Inkscape-devel] n00b questions joel@...1709... wrote: > > Hi, > Given that I'm pretty new to the Inkscape developement world, I had a couple questions. > > The first is this: what hurdles stand between Inkscape today, and v1.0? Better SVG Compliance. I believe the last discussion put it at SVG Tiny 1.1 being fully supported. As great as Inkscape is in the general vector realm, we are first and foremost (specifically) an SVG editor. I also recall there being goals for falling below a certain amount of bugs or something along those lines. > If you're roughly on a 6 month release cycle, that puts v1.0 at least 5 years away! > > Surely that's not right? The above addresses this. If we had full support tomorrow (which won't happen), the next release could be targeted 1.0. > I worry that until Inkscape gets to >v1.0 it will be seen as "experimental" and "unstable" by many. I worry that until 1.0, the app will languish, not attracting the user base or developer base it deserves.. Companies won't trust it, and Ubuntu probably won't bundle it for example. Being with the project for a few years, I can tell you it's seen nothing but steady growth and adoption. It seems that once people understand why it's not "1.0", they get past the superficial numbering. Honestly, if people choose software based on version number, they're not properly evaluating all candidates. That said, if people view Inkscape as a general purpose vector editor and not an SVG editor, if we hit 1.0 without full color management support and rockstar pdf output, things would look really bad to them. Oh and as for Ubuntu bundling it... two of our core devs are Ubuntu developers, so if we will ever stand a chance, it probably lies more with their powers of persuasion (and user demand) than a superficial number. ;) For the record, the first thing that Ubuntu utilizes on your computer at startup (GRUB) is only 0.97, or rythmbox which is a default install is at 0.11, etc... so I don't think numbers matter that much. So... if you want to get things moving toward 1.0 you can either polish up the rough edges you see, or work toward SVG Tiny compliance. Either way, it moves Inkscape forward. :) -Josh P.S. I'm sure others will elaborate more and make me look like a fool. ;)

2 1

Re: [Inkscape-devel] Second n00b question: Cairoification
by joel＠...1709... 03 Jul '07

03 Jul '07

Thanks for both your answers, they're both very informative. Sorry abut th ^Ms, the "SmarterMail" web client I'm using is maybe not so smart. The problem'll go away by next week when I get back on my real mail client. ---------------------------------------- From: "Joshua A. Andler" <joshua@...533...> Sent: 03 July 2007 12:27 To: joel@...1709... Subject: Re: [Inkscape-devel] Second n00b question: Cairoification joel@...1709... wrote: > > Here's my second question: how's the cairofication coming along? Cairofication is awaiting a few fixes in Cairo. My understanding is that after that, we're golden. > For me this would be a truly killer feature: fast hardware rendering in OpenGL. What problems stand in the way of us switching over before the next release? I heard about the problem with off-centre elipse gradient fills. Is this the only sticking point? Couldn't we just cludge it by composing the gradient out of loads of bilinear filled triangles, or by a pile of ellipses? Or couldn't we put pressure on the Cairo guys to add support - wouldn't having Inkscape use their engine be a big incentive for them to grease the weels? Bulia and Carl Worth (a core Cairo dev) know what fixes we need. There are 3 or 4 of them I believe. A couple which are pretty serious. One relates to spurious lines showing up when zooming in. Another relates to Masks not rendering correctly (which you could possibly look into on our end to make it compatible with how Cairo currently wants masks, as it would be faster than waiting for the fix on Cairo's end - per Carl). And there is one or two more that I don't recall offhand. Honestly, before any faster hardware rendering, the biggest benefit we get is half the memory consumption... not to mention free renderer upgrades as Cairo improves. > Or are there other things to think about? or is it simply a work in progress for the assigned developer? If you would really like to look into making this stuff happen, please let us know. You could also drop by our jabber room or IRC to talk as well. -Josh

1 0

Second n00b question: Cairoification
by joel＠...1709... 03 Jul '07

03 Jul '07

Here's my second question: how's the cairofication coming along? For me this would be a truly killer feature: fast hardware rendering in OpenGL. What problems stand in the way of us switching over before the next release? I heard about the problem with off-centre elipse gradient fills. Is this the only sticking point? Couldn't we just cludge it by composing the gradient out of loads of bilinear filled triangles, or by a pile of ellipses? Or couldn't we put pressure on the Cairo guys to add support - wouldn't having Inkscape use their engine be a big incentive for them to grease the weels? Or are there other things to think about? or is it simply a work in progress for the assigned developer?

2 1

Re: [Inkscape-devel] Toolbar Icons in Windows
by joel＠...1709... 02 Jul '07

02 Jul '07

Those icons also look really good. I'm so glad all these open applications are getting a face lift; it makes them so much more appealing. ---------------------------------------- From: Andreas Nilsson <nisses.mail@...563...> Sent: 01 July 2007 15:38 To: joel@...1709... Subject: Re: [Inkscape-devel] Toolbar Icons in Windows joel@...1709... wrote: > I have a question about standard toolbar icons. I notice that when I > run inkscape in Gnome in Ubuntu, the system provides some of the > standard icons in toolbar for things like Open, Save, Print, Cut, Copy > and Paste. These Ubuntu provided icons look really good (are > they Tango?). However, in the Windows version of Inkscape (or is it > GTK+ ?), the standard icons just look a little dreary, and washed out. > Is there any chance that the Windows users could have brighter icons > which follow the Windows style guidelines? - like the Silk Icons > (http://www.famfamfam.com/lab/icons/silk/), or for that matter any > icons which follow the Tango style guidlines? > Hi Joel! I assume you refer to the gtk+ stock icons that are being used in the stable windows builds, and yes, they fit in somewhat bad on windows. However, new gtk+ stock icons are coming in the next stable release (gkt+ 2.12?). These should blend in a bit better with other windows applications. Check out http://www.andreasn.se/blog/?p=45 for more details. - Andreas

1 0

Re: [Inkscape-devel] Toolbar Icons in Windows
by joel＠...1709... 02 Jul '07

02 Jul '07

Those icons look great! I can't wait till they're in. ---------------------------------------- From: "Alexandre Prokoudine" <alexandre.prokoudine@...400...> Sent: 01 July 2007 14:24 To: inkscape-devel <inkscape-devel(a)lists.sourceforge.net> Subject: Re: [Inkscape-devel] Toolbar Icons in Windows On 7/2/07, joel wrote: > These Ubuntu provided icons look really good (are they Tango?). They are in Tango style, but not Tango. The theme is called Human. > or for that matter any icons which follow the Tango style guidlines? Yes, we have a tango styled icon set in works. Have a look at http://gnomelook.org/content/show.php/Tangofied+inkscape+icons+set?content=… if you want to know more :) Alexandre ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

Toolbar Icons in Windows
by joel＠...1709... 01 Jul '07

01 Jul '07

I have a question about standard toolbar icons. I notice that when I run inkscape in Gnome in Ubuntu, the system provides some of the standard icons in toolbar for things like Open, Save, Print, Cut, Copy and Paste. These Ubuntu provided icons look really good (are they Tango?). However, in the Windows version of Inkscape (or is it GTK+ ?), the standard icons just look a little dreary, and washed out. Is there any chance that the Windows users could have brighter icons which follow the Windows style guidelines? - like the Silk Icons (http://www.famfamfam.com/lab/icons/silk/), or for that matter any icons which follow the Tango style guidlines? Sorry to keep posting comments about such seemingly trival details - I'm just stickler for details sometimes.

3 2

new API: XML::Subtree
by MenTaLguY 01 Jul '07

01 Jul '07

I've introduced a new API for monitoring changes to subtrees of a given XML tree. It extends the existing change notification API for XML::Node by providing an attachment point for NodeObservers to observe changes to an entire subtree in the document, instead of just a single node. The main difference is that rather than registering a NodeObserver with a Node via Node::addObserver, you create a Subtree object for that node and add the observer to it instead. XML::Node *some_node; XML::NodeObserver &observer; ... XML::Subtree *subtree = new XML::Subtree(*some_node); subtree->addObserver(observer); ... subtree->removeObserver(observer); delete subtree; // XML::Subtree is manually manged I'm going to do a more efficient implementation of XML::Subtree eventually, but that shouldn't alter the API given here. -mental

1 0