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!
I'm in the process of developing the new GNOME Office portal.
There's has been talk of GNOME Office applications requiring a quality
SVG canvas. Your roadmap suggests that, at some point, you intend to
separate out an SVG canvas from the Inkscape codebase.
I also notice your plans for a clip art extension. This would also be
an excellent tool for other GNOME Office applications.
GO already contains arguably the best available spreadsheet application
in Gnumeric, one of the leading word processors in AbiWord, and an
excellent data(base)-agnostic backend in the Gnome-DB project that is a
unique facet to GO. We are looking to include Conglomerate (advanced
XML editor), Mergeant (database management), and Planner (project
management) as well as Inkscape. The increased collaboration and code
re-use could produce an office suite to be reckoned with.
Inkscape is becoming the leading SVG editor. I am in a position of
ignorance (not a coder or a projcet lead) but I firmly believe there is
a desire from the GO team to include Inkscape among GO or, at the very
least, make use of some of the excellent functionality provided by
Perhaps Inkscape could make use of the advanced editing capabilities of
Conglomerate or other facets of GO? There is libgsf, libgda, libgnomedb
and the planned libgoffice (emerging from Gnumeric).
I know not the details nor how any of this would be accomplished and
indeed parts of it is mere speculation by myself. I can only humbly
invite some (or all!) of you to join the GO mailing list in order to
begin discussions with the more technical members of GO with regards to
what GO and Inkscape can do for each other:
In the potential GO application list, we have a distinct selection of
potentially (if not arguably) best-of-breed applications. If they were
to collaborate then who knows what exciting prospects the future might
hold! But first the respective project leads must be prepared to look
months or even years ahead in terms of planning and setting goals.
Thank you for your time and I hope to hear from you soon!
Charles Goodwin <charlie@...208...>
Online @ http://www.charlietech.com
With 0.37 happily out the door, we're ready to kick off the event you've
all been looking forward to - yup, the BUG HUNT.
Over the past few releases we've closed an insane number of bugs. Out
of a total of 187 bugs that have been submitted, only 61 remain open.
Particularly, we've been very attentive to close any bug that leads to a
crash. No matter how obscure the bug, we don't want Inkscape to crash -
But there's a lot of smaller bugs that don't cause crashes, that are no
less important to get fixed.
Our goal for this release is to close a lot of bugs. Since we usually
have focused mainly on the critical bugs, this time let's instead focus
on the older bugs, that normally don't get much attention. Let's make
our objective for 0.38 to either reduce the number of bugs submitted
before the 0.37 release announce on 2/15/04 to fewer than 10, or to
reduce our ratio of open-to-total bugs from 30% to 10%.
1. Bugs 841633-896992 52 9
2. Open/Total Bug Ratio 33% 10%
Now, it may take some time for us to achieve this. If it looks like
it's going to take significantly more than a month, then we should
do a few 0.37.x point releases along the way. When we've achieved
either objective 1 or objective 2, we will release 0.38.
I think having a numerical goal will make this a fun release, even
though it's just bug fixing, in that our progress towards the goal will
be very easy to see. And having two objectives will hopefully help us
avoid getting frustrated if we get stuck trying to meet one.
A few notes on how to handle bugs. First, when reviewing a bug ask if
it really is a feature request in disguise. If so, don't be shy about
kicking it over to be an RFE. Second, you may find that the bug is a
symptom of a larger underlying problem; in this case, perhaps consider
finding some way to address the symptom directly and close the bug, and
write up in detail what needs to be done to address the larger problem
and submit that as an RFE.
On Sat, 21 Feb 2004, Nestor Diaz Valencia wrote:
> Date: Sat, 21 Feb 2004 10:38:57 +0000
> From: Nestor Diaz Valencia <nestordiaz@...207...>
> To: Alan Horkan <horkana@...44...>
> Subject: Re: [Inkscape-devel] Re: 'dialogs' menu (screenshot inside)
> You are right, gimp stock icons, plus openoffice stock icons.
> The theme is not perfect but it looks integrated.
I had a look.
Rather than simply embed the new icons I would ideally like to see the
icon theme specifications followed so that users can switch themes rather
than being stuck with just one. I've been meaning for a long time to get
the original vector graphics for the High Contrast theme and make a low
(~16) theme out of it.
The (gfig) star and spiral icons are pretty bad, but they were drawn too
small originally because of the cramped gfig user interface and I think
jimmac didn't change them much when he redrew them.
If you are going to use the stock icons from OpenOffice I think it would
be far better if you used the ellipse icon that doesn't have a segment
sliced out of it (because the ellipse tool in inkscape cannot draw shapes
like that yet). (I really hope I remember this right because I've deleted
the mail with the attachment and although I tried to find it in the
mailing list archives there is a signficant delay before Sourceforge
updates the mailing list archives
All the icons are on Jimmacs website
Stock Draw circle
Stock Draw square
I should admit that I'm not a huge fan of Jimmacs Gnome 2 icons and I
actually prefer clearer sharper icons however it is a great bit of work
you have done and it great that someone tried this, just the other day on
GnomeDesktop.org a user was asking for Inkscape to use the stock icons.
I also considered taking the icons Inkscape was already using and
colouring in the Square Circle and Star to the colours they are now using
by default to make them more easily distinguishable at a glance.
Hope that makes sense
>Starting today, I'll be working on a new Inkscape::AST module, which
>will eventually replace the current SPRepr subsystem.
Hurray!!! I can't wait when it's ready! :)
But what does AST stand for?
>The goal is to reduce the complexity of the XML code, while allowing for
>e.g. CSS and SVG path data to be manipulated in the same tree, in
>broken-down form (rather than as monolithic strings).
And also to automate any and all inheritance and precedence issues, so that
we can use ONE function to access the effective value of any property, be it
in CSS string or in attribute, no matter how many levels of parents or defs
(defs can be recursive, too) may affect it.
Click, drag and drop. My MSN is the simple way to design your homepage.
SO I proceeded with the dir. reorg. last night and I have the head
compiling and all that. I still have some other little tweaks, but the
largest chunk (excluding packaging) has been committed.
Please make sure that I did not break anything. The icons and extensions
folders now are inside share. Also, I put the svg files that were in
icons (about.svg, keys.svg, and tutorial.svg) and put them into
share/screens and updated and created a variable INKSCAPE_SCREENDIR
instead of INKSCAPE_PIXMAPDIR for these files where accessed in help.cpp
(this is defined in src/Makefile.am).
ISHMAL, could you please look and see how a fresh cvs windows build
works. I have a strong feeling that a I broke it, as I have no test box
and tried to conceptually follow what I did on the linux side. The part
that might not work I'm pretty sure is contained in config.h.mingw and
Makefile.mingw I believe. I became slightly confused after staring at
weird makefile syntax for a couple of hours.
I will delve further into cleaning up the makefiles now that I
understand automake and makefiles much better. There is sooo much legacy
architecture and cheap hacks where the same paths are called in
different places in the makefiles. Also, would you all agree that I
should migrate the current recursive makefiles to just one top-level
makefile? You all might also email me/the list a wishlist of how to
clean up the source tree and the makefile nasties as they currently
If you want to refer to the dir. reorg plan:
Jonathan Phillips <jon@...15...>
Starting today, I'll be working on a new Inkscape::AST module, which
will eventually replace the current SPRepr subsystem.
The goal is to reduce the complexity of the XML code, while allowing for
e.g. CSS and SVG path data to be manipulated in the same tree, in
broken-down form (rather than as monolithic strings).
libxml will still be used for parsing XML data, and hopefully we will be
able to start using libcroco for CSS data as well.
The new XML editor will also use the AST code, and it in turn will serve
as a basis for the Layers dialog UI.
Questions are welcome.
>From the roadmap overview:
6. Create Plugin Architecture 0.40
* This architectural change will establish a new mechanism for how
features are added and maintained in the codebase.
7. New Features 0.41
* Implement snap-to object, enhanced layer support, and boolean
8. STL Architectural Change 0.42
* Shift codebase to using STL for data structures.
* Replace use of #defines and enums with hashmap lookups
9. Extract SVG Canvas into a library 0.43
Obviously I'm massively ignorant of the issues involved, but from what I
can see milestones 6 and 7 are relatively independent of 6 and 9.
>From a GO perspective, it would absolutely brilliant if you could bring
milestone 9 into milestone 6, the point at which you might start using
libgoffice for the plugin handling. (And I personally hope you do
because it will help make goffice more functional, featureful, and
robust as well as give Jody a bit of help.)
The reason I bring this up is that the sooner the Inkscape SVG canvas is
available, the sooner other applications (esp. GO apps) can organise
themselves around incorporating it.
Charles Goodwin <charlie@...208...>
Online @ http://www.charlietech.com
Bulia or anyone else,
When I scroll use the vertical scrollbar everything is very smooth and
the canvas is not smeared, but when I use my scrollbar mouse, the canvas
is smeared in the update. This is especially true when looking at the
tutorial. Can someone else verify this. Although this is not a bug, it
is kinda weird updating of the canvas. Anyway...it becomes cumbersome to
use the scroll mouse to move around with these weird updates, as you
can't see exactly where you are heading. It would be nice if a similar
update method was used as is with the vertical scrollbar wheel. NOTE: I
have not looked at the code for thi.
Jonathan Phillips <jon@...15...>