- Inkscape Devel - Inkscape Mailman

Ruler units revisited
by Aaron Spike 23 Jan '05

23 Jan '05

In reference to: http://sourceforge.net/mailarchive/forum.php?thread_id=6260553&forum_id=360… With the latest autopackage working on my machine again, I finally had a chance to play with the new units code. Thank you all it is super. And now I think I have nailed down what my trouble was all along. Would someone please try the following and confirm that I am not crazy. create a new document change document preferences default units to inches (notice ruler units change) save document and close inkscape. open inkscape open recent the document look at rulers (not inches) open recent the document look at rulers (now inches again) Thanks, Aaron Spike

3 2

XForms for extensions and UI
by Jon A. Cruz 23 Jan '05

23 Jan '05

I've been kickout out the possiblity of implementing some basic XForms or XForms-ish implementation for our UI, including for the extension & scripting support. Among other things, I think it would shift things around and get them more useable than just putting in .glade file and libglade parsing. It's a bit similar to XUL, but with a focus that I think is more appropriate for our needs. Anyway, I came across this article that gives a quick overview of some things, and how it might benefit us. I think it would be good if everyone could at least skim it. ---------------------------------------- The Secret Life of XForms http://www.devx.com/xml/Article/17714/0/page/1 "XForms recently reached the W3C's Candidate Recommendation status—and you need to know about it—because XForms isn't a form description language, it's a language for describing applications in a platform-independent way. Best of all, it integrates easily with technologies you already know, such as XHTML, XPath, SVG, and CSS. " ---------------------------------------- Read it through, and then think of how this could be taking our 'verbs' approach a step further, and also give extensions and scripts a nice way to get and use UI without having to resort to the evils of Gtk::Socket and such.

1 0

Roadmap updated
by Bryce Harrington 23 Jan '05

23 Jan '05

With Scislac's help, the Roadmap's been updated: http://inkscape.org/cgi-bin/wiki.pl?Roadmap Basically, we've just moved all the milestones forward one release, so that 0.41 can be released fairly soon (it'll be mostly just bug fixing). I've also outlined more of the work in the Gtkmm section for 0.42. Please everyone take a moment to look through the roadmap and check that the things you plan to work on in 2005 are listed in there, and add them (with your name), if not. Also, PLEASE consider volunteering for some of the Gtkmm tasks by listing your name next to some tasks. Remember that the current gtkmm code is going to be integrated into the main codebase as soon as 0.41 hits the shelves, and there's a lot to do so the more help, the sooner we'll get through it. Gtkmm is not hard to learn if you know C++. I estimate at least two more weeks before we're ready to freeze for 0.41, so expect the Gtkmm work to become the project's focus by the end of Feb. I suspect it may take 2-4 months of work to complete, although given a lot of participation we could probably cut that in half. Bryce

1 0

new screenshot
by bulia byak 22 Jan '05

22 Jan '05

See a new and beautiful screenshot at the top of http://inkscape.org/screenshots/index.php Send us your new and beautiful screenshots, too! :)

1 0

Transparency support for postscript output
by Ashwin Bharambe 22 Jan '05

22 Jan '05

Hi all, I am assuming that postscript not having transparency natively would be the reason for inkscape not supporting transparency in EPS or postscript outputs. What would be required to implement support for this? Ashwin

9 14

Re: [Inkscape-devel] button sizes?
by Andreas Nilsson 22 Jan '05

22 Jan '05

David Christian Berg wrote: >Alors: >When I designed my icon theme, I noticed exactly the same problem as >Andreas did. Designing icons to use the space of 16*16 in the menu will >be clipped in the tool-option-bar. >I don't agree that this means, that the buttons have to become larger. A >svg will look rather crisp at any size and gnome is going svg, for sure. >It just means, that the rendering of the icons is kinda screwed. >The size on canvas should not matter at all! That's what svg is for. >Find the object you want to draw, take it's width or height, whatever is >bigger, and scale it proportionally to fit either the 16px of the Menu >or the I think 20 px of the tool-option bar. That's how it should work. >Right now I have to design a 24pt*24pt icon to fit the menubar. Since it >actually is 16px*16px one might think that maybe scaling up a 16pt*16pt >object would give very crisp results, but it doesn't. At the same time, >the node-editing icons created in 20pt*20pt allow you to draw single >pixels, which are 1pt*1pt. >So as I said, all this is kinda screwed, but it doesn't count as a >reason for increasing the button size. > >David > > So youre saying that there might be another reason for the clipping? The clipping is my main concern, and I thought that the size was the problem. If that is not, I apoligy for my request to make the buttons larger, especally if people find it a problem with normal-sized icons. - Andreas

7 8

Blog: Jakub Steiner: Inkscape Evaluation
by Tobias Jakobs 22 Jan '05

22 Jan '05

Hi all, Jakub Steiner alias jimmac (The Gnome/Gimp icon man: http://jimmac.musichall.cz/ ) wrote a review of Inkscape: http://primates.ximian.com/~jimmac/blog/Artwork/Inkscape -- Tobias <tobias.jakobs@...128...>

3 2

button sizes?
by bulia byak 21 Jan '05

21 Jan '05

Sorry it's me ranting again. Do we HAVE to have those large buttons? I find them clumsy at this size. Up to now, there was: - a meaningful hierarchy of sizes: main tool buttons large, tool control buttons small. - a coordination of the sizes of the buttons and the rest of controls (spinbuttons, etc). Both these are now broken. Why? What for? Can we return the small size at least as an option? I'm aware of the "other apps do it this way" argument, and I'm generally sympathetic, but I don't think it has the priority over the "yuck, it's ugly" argument. That is, when what other apps do looks nice or at least decent, borrow. When our own solution is demonstrably better, stick with it. P.S. The join/cap buttons with thick white midline replaced by thick black midline became even worse. So I went ahead and fixed them using a thin dotted midline.

4 5

Connectors
by Ashwin Bharambe 21 Jan '05

21 Jan '05

Hi all, Is there support for object connectors in inkscape? I have not been able to find one. And if not, I am willing to contribute. Ashwin

3 2

configure error with -ldl and Boehm
by Jeremy C. Reed 20 Jan '05

20 Jan '05

See revision 1.11 of inkscape/inkscape/configure.ac: "When adding -lgc to LIBS, also add its dependencies -lpthread -ldl." Replaces LIBS="$LIBS -lgc" with LIBS="$LIBS -lgc -lpthread -ldl" This appears to be wrong. Some systems do not have -lpthread (such as gc built with --disable-threads) and -ldl (such as NetBSD). For example (when building using pkgsrc under NetBSD): configure:21460: checking for GC_malloc in -lgc configure:21490: c++ -o conftest -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetyp e2 -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -L/usr/X11R6/lib -Wl,-R/usr/X11R6/lib conftest.cc -lgc -lpthread -ldl -lintl >&5 ld: cannot find -ldl configure:21496: $? = 1 Anyways, -ldl is added to LIBS if needed in the configure script. Maybe re-order as necessary. I am not sure about checking for -lpthread though. Jeremy C. Reed open source, Unix, *BSD, Linux training http://www.pugetsoundtechnology.com/

5 15