svg filters crash
by Alexandre Prokoudine
Hi,
For last couple of days Inkscape crashes whenever an SVG Filter from
Filters menu is chosen.
https://bugs.launchpad.net/inkscape/+bug/334050
BTW, we have 37 more bugs tagged with "crash". If we are planning to
do a release this year, maybe we should encourage ourselves to clean
up the mess or at least leave several wet floor signs around :)
Alexandre
12 years, 2 months
Export, Publish and Save As
by Martin Owens
Hi inkscapers,
I was looking at a few bugs (#168504 and #168958) and thinking about
some of my own personal grievances with the whole business of exporting
and saving as.
Currently in inkscape 0.46 (Ubuntu 8.10) there are a whole boat full of
exporting, saving, loading menus in the File menu. Most of which seem to
follow this logic:
1) File New/Load/Save
* New >
* Open ...
* Open Recent >
* Revert
* Save
* Save As ...
* Save a copy ...
2) Import/Export
* Import ...
* Export Bitmap ...
* Import from Open Clipart ...
3) Print ...
4) Vacuum Defs
5) Preferences
* Document Properties ...
* Document Meta Data ...
* Inkscape Preferences ...
* Input Devices ...
6) Application
* Close
* Quit
This seems a bit of a mess, although I don't know if you've changed much
for 0.47 so apologies if this has already been put through for
refinement.
My suggestions would be as follows:
* Move Revert to Edit and have it as a function of the undo system.
And/Or rename it to 'Reload from File'
* Remove Save a Copy and replace with 'Publish ...' which would have a
dialog specifically designed to export to pdf, plain svg or png and with
options that make sense such as v1.1 svg, clean defs and no personal
data (such as paths).
* The document properties and meta data seem out of place, since
they're more to do with the document object than the file object. Maybe
a top level document menu? One that includes some of the edit menu items
specific for the document?
* Vacuum Defs seems like a plugin or something that could be a part of
publish, or the doc menu.
* Import and Export make sense, but perhaps having plugins that allow
imports and exports to various places and removing the specific link for
open clipart.
Thoughts? Flames?
Regards, Martin Owens
12 years, 2 months
Re: [Inkscape-devel] website
by Jarosław Foksa
Hey,
I've been working on inkscape.org mockup, but just like Joshua I
somehow couldn't finish it for several months...
>Do we have a new design? Do we have anybody to work on new
>website?
It's still work in progress: http://wstaw.org/p/4e95/
Please give me 1 week to finish header and main menu icons, maybe this
will make it look a bit cleaner. If you have any ideas how this layout
could be improved further then feel free to share them here.
12 years, 2 months
website
by Alexandre Prokoudine
Hi,
I'd love to know about our plans for inkscape.org. Some time ago it
was proposed to move to Drupal, and there was even a theme contest at
DeviantArt.
Right now I have here an experienced webmaster interested in Inkscape
who could turn a ready-to-go design into PHP templates or whatever you
want. Do we have a new design? Do we have anybody to work on new
website?
Alexandre
12 years, 2 months
Re: [Inkscape-devel] [Inkscape-docs] Helo
by Alexandre Prokoudine
On Tue, Feb 24, 2009 at 8:38 AM, adam hyde wrote:
> how many of the inkscape doc team are going to the LGM?
I'm probably not present this year.
Alexandre
12 years, 2 months
libgdl
by Joel Holdsworth
Hi All,
Just to say that working on the Lumiera project, we've adopted the GDL
library for panel management, same as Inkscape. We've found some
shortcomings with GDL: it's got a few bugs, the documentation is sparse,
and it lacks some features that we need. Right now the Anjuta guys are
maintaining it, and I'm submitting patches, and other people seem to be
contributing to it from time to time.
I notice that Inkscape uses it's own forked version of GDL. I don't know
who's maintaining that code, but can I suggest that someone take some
time to try and move over to using the shared library? The Anjuta guys
are very helpful, and seem happy to accept all kinds of patches,
including feature additions, so there shouldn't be too many political
problems in merging.
If you can merge over, then Inkscape, Anjuta, and Lumiera will all
benefit from shared maintenance of the code. The flip side is that I'm
squashing bugs, and I'd like Inkscape to benefit from my work!
Is this going to be possible, do you think?
Best Regards
Joel
12 years, 2 months
Issue with work on new font dropdown
by Milosz Derezynski
Hello Everyone,
I want to discuss one issue with the new font dropdown. I've already begun
work on it and it can be seen in action in these 2 videos:
http://futurepast.free.fr/out.ogv
http://futurepast.free.fr/preview-text-update.ogv
It uses threading for generating the preview as not to stall the UI/main
application while scrolling, or take too long to startup when generating all
the previews
at startup of the application.
My architecture for this is very pluggable, I defined interfaces for all the
classes used and wrote a few sample implementations which you can see at
work in those
2 videos. Now I've run into a problem: For the class that generates the
actual thumbnails I've initially chosen Pango to render them. Now it seems
that Pango is not
thread-safe and I wrote another implementation using just cairo which seems
to work fine so far.
The issues is that with cairo, we don't get proper thumbnails for some
fonts, or some scripts. Pango handles this on a higher level and much
better. Bulia mentioned to
me that tradeoffs might be possible, but I am not sure at which point to
make these. I'm not an export on cairo or freetype2 to make this particular
backend work properly
with all fonts and all scripts/glyphs.
Then, there is always the third option of not using threading, but I'd
prefer to keep it since it works really well and is an ideal solution for
the problem of time-consuming rendering
of previews of complex fonts. Please don't worry about "threading" itself,
I'm using libsigx in accordance with Bulia, which can be found here:
http://www.assembla.com/wiki/show/sigx
and is a threading library based on libsigc++ and makes thread programming
*very* safe.
The question now is:
- Keep the cairo-only backend with the tradeoff that we can not render
everything properly
- Try awkward things with Pango like dlopening() a 2nd ("private") instance
of libpango and use this solely for generation of the previews
- Drop threading(?)
- Does anyone have a 4th solution?
To those interested: The details in the problems with Pango lie in that some
structures inside libpango are not properly locked or protected, and race
conditions occur when simply
running the thumbnail generation in a thread with the same libpango
instance, and merely simply rendering the application's UI with Gtk+ which
uses Pango for text widgets and/or
rendering canvas text since layout-TNG uses Pango as well from what I've
seen in the code so far.
Any suggestions regarding this problem are appreciated.
Regards,
M.
--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
12 years, 2 months
