I have the latest debian package, but dunno what that is... can't you
put something in the about dialog, so that I know... I never remember
this terminal stuff.
Anyways, I get a crash when I try to copy a text with a gradient fill.
That is strange on the one hand and annoying on the other. I hope it's
an easy to fix or fixed already.
just wondering if I should file a bug, or if it's so simple that I don't
Especially in the guides and the positioning dialog it would be helpful
to be able to put mathimatical stuff in there. Imagine you have a guide
at 45.6 and want one 7 mm further to the right, you'd just type 45.6+7
and there you go... even more important is something like dividing by 2
or 3, I need that quite often.
Btw: Since my laptop was for repair, I used CorelDraw, and I think for
basic vector editing and layouting inkscape is by now better than Corel.
That is something!
Which also brings me to one other thing I'm missing: Baseline Grid. Even
for simple flyers and brochures it's nice (or rather necessary) to have.
CorelDraw just pissed me of for not having it!
I got my laptop back, with working ethernet card, Yeah!! Take care!
- the sp_fullscreen function should be perhaps in desktop.cpp, not in
- the planned shortcut for fullscreen is F11 - I don't think f is a good
idea, it's easy to press it accidentally
- use the last argument of true when registering a shortcut in
shortcuts.cpp, so it shows up in the menu
- on my KDE 3.14, fullscreen only works properly when there are no other
maximized windows. If there's a maximized window and an Inkscape window over
it, then calling fullscreen results in unending flashing of these two
windows - this can only be stopped by killing Inkscape. Anyone else having
- when I open new document windows from a fullscreen window, they are
sometimes on top of it but sometimes they sink under the fullscreen window
(can't guess what is the algorithm here).
The new MSN 8: advanced junk mail protection and 2 months FREE*
I made a small code example of loading dynamic extensions to
something like Inkscape. I put a Zip file of the code here:
Basically this does plugin loading Netscape-style.
It scans a directory for files beginning with a given
prefix ("ix" in this case) and the proper suffix for a shared
object (".so" on Unices, ".dll" on Win32).
It loads each object, finds a C function called CreateExtension.
This is ---MUCH--- easier than linking to C++... Directly linking to
a C++ resource on a shared object is fraught with DANGER!
It casts the resulting void * to an Extension object, which has
virtual overloaded methods for any class extending it. It then
calls a few methods on each one, just to show that it is honest.
The Makefile works on Linux. I'll make it work on
Win32 later. It just needs to use the dlltool to make dll's
instead of .so's. But it is Happy Hour right now, and I must keep
my priorities straight!! ;-)
Hope this is helpful if considering methods of Inkscape
I just got back to my normal location at UC-San Diego. It is nice to be
back in my 24 work zone.
I'm thinking of a few things and decided that I would itemize rather
1.) PAYPAL: Do we have some form of paypal donations setup for our
project. I would like to look into this. I've even been toying with the
idea of getting some form of funding from UCSD to plugin to our project
to "encourage" certain features to be implemented. I don't know if the
"bounties" concept fits, but is interesting.
2.) NODE USABILITY: I don't know what to call it, but I will call it the
extra-functionality "handle" for spirals, stars, circles and squares
(rounding) is hard to see against a white background. I think we need to
do something about the visibility of this. Maybe either by putting a
white border around it, or making it reverse on colors. The normal nodes
are hard to see sometimes as well. I think we should change the color of
the nodes to be darker, or have a white outline or something to pop-them
out against black and other dark colors. Just a thought...if you are all
interested in this, then I will add another RFE.
3.) TIMETABLE for the next release? I know we have many many many more
tasks to complete for this milestone, but now that we are after the new
year, maybe we could have a target date for getting the current
milestone complete. How about Sunday, February 1st?
Jonathan Phillips <jon@...15...>
The Help > Tutorial is mostly written, please read and criticize. It's
pretty big, but not complete of course. Maybe later I'll break it into a
basic tutorial and an advanced tutorial.
I'm also interested to see how it comes up with regards to fonts, window
size, etc. Posting a screenshot of the tutorial to the site would probably
BUG: When I zoom out from the tutorial page, it ultimately crashes. This
looks like an instance of this bug:
which could not be reproduced outside of my machine. So please test the
tutorial by zooming out as far as you can, and report if you get a crash.
Now I will write an XSLT transformation to automatically generate an SVG
page with the keyboard shortcuts for reference, also to be linked from Help.
I think it's nicer and more instructive to present Inkscape help in
Inkscape, instead of running an external browser :)
MSN 8 with e-mail virus protection service: 2 months FREE*
Can anyone please compile the latest CVS for Windows so the latest additions could be tested there? I have Windows but no Windows development tools.
Sign-up for your own personalized E-mail at Mail.comhttp://www.mail.com/?sr=signup
Search Smarter - get the new eXact Search Bar for free!
>Hmm, that gives me an idea... how do you feel about the idea of having a
>more general 'viewport history' or something like that (which would
>include zoom), orthagonal to the document undo history?
It IS already a vewport history, that is, each list member in
desktop->zooms_past stores four numbers that define the visible area _and_
zoom. However new members to this list are added only when you are zooming
in or out, not when you are panning canvas at the same zoom. This is
logical: you can pan very slowly, and adding a new "undo step" for each
one-pixel panning will make this history unusable.
However you gave me an idea: I can store past viewport not only before I do
zoom, but also after that; later, when a next zoom is started, I will
compare the current viewport with the last stored and, if it's the same, not
store it. This way I will be adding one viewport record if there was no
panning between zooms and two records if there was panning, these records
storing the first and last viewports at this zoom. I think it will be a bit
more convenient this way.
The new MSN 8: smart spam protection and 2 months FREE*