inkscape git mirror?
by MenTaLguY
I'm interested in setting up a git mirror of Inkscape SVN; who's the person in charge of our server currently? We'll need to have a fairly current version of git, libsvn, and the libsvn perl bindings installed to do this.
-mental
14 years, 9 months
Odd size of imported bitmaps
by Dan H.
Hello,
I've imported a 400x400 pixel TIFF image into an inkscape drawing, and
it comes out as 112.89 x 112.89 mm, which translates to a resolution of
roughly 90 dpi.
Where does this number come from? Shouldn't inkscape honour the dpi
information that is embedded in the TIFF image?
Alternatively, for images that don't have a "built-in" resolution,
inkscape should ask for a "native" size of the image or use a changeable
default resolution.
Also I noticed that some imported images have width and height xml
attributes while others don't. All this came to my attention when I
worked with a SVG file with 20 imported images of about 10MB each (TIFF
uncompressed) which bogged down my computer. I tried substitutung the
TIFFs with scaled-down (by .25) working copies, which worked fine for
those images that had width and height attributes (the others came out a
fourth of the size),
I'm just wondering how Inkscape arrives at the "native" size of an
image, and I wanted to know if others agreed with my notion that in a
vector drawing program the resolution of imported bitmaps was of high
importance.
It would also be nice if Inkscape could somehow reload image properties
if the original bitmap had changed (by scaling or cropping, for instance).
Thanks,
--Dan
15 years, 6 months
[PATCH] Dockable dialogs, and some concerns...
by Gustav Broberg
Hi all,
I've been busy with work since the release of 0.45, but now I have
finally found some time to spend on Inkscape again... :)
I have uploaded a patch to the tracker which is a first attempt to
implement dockable dialogs/panels using gdl (Gnome development
library).
http://sourceforge.net/tracker/index.php?func=detail&aid=1688508&group_id...
The patch adds a dockable pane to the desktop on which any GTKmm:ified
dialog can be docked. Here are some screenshots showing what it's all
about:
http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png
To compile you'll need gdl >= 0.6.1, the latest version is available
here: http://ftp.gnome.org/pub/GNOME/sources/gdl/0.7/gdl-0.7.2.tar.bz2
Gdl is a fairly small UI library developed for IDE:s such as
Anjuta. The main thing it provides is a set of components to build
dockable interfaces.
I realize that it would be better to do this without an additional
library, but right now I think gdl is the best option assuming that we
want a dockable interface.
The pros of using gdl, as I see it, are:
* It provides a lot for free. Dockable items (dialogs in this case)
can be attached and detached to docks, iconified to dock bars and
docked to each other as separate floating groups. Furthermore they
can be stacked as notebook tabs, and complete layouts can be
saved/restored from disk (I haven't got that one working, though).
It would require a major amount of work to reproduce the docking
functionality found in gdl.
* It's still actively developed. Inkscape could benefit from the new
functionality added to gdl.
...and the cons:
* It's yet another library, with all the problems that brings. The
availability could be an issue. Distributions that provide Anjuta
or Screem should have gdl in their repos as well. Merging gdl into
Inkscape's tree is probably a bad idea...
* I haven't tried it on win32 or Mac OS X, so I'm not sure about the
compatibility. It used to require some gnome only libraries, but it
doesn't anymore from what I know.
* It's a C library. There is a C++ wrapper called gdlmm, but it
hasn't been worked on since 2005, and I'm not sure how
complete/stable it is.
The only alternative to gdl that I know of is CurlyAnkles. It has the
same issues with availability and compatibility as gdl, but is less
mature (I'm not aware of any project that uses it yet). On the
positive side it provides other widgets that could improve Inkscape's
interface.
As for the design I've chosen to keep the current UI::Dialog::Dialog
hierarchy as opposed to extending UI::Widget::Panel, which I guess was
planned to be the root class of everything dockable (?). The main
reasons for this were that I wanted to keep the old dialog behavior as
an option and also that I wanted to avoid rewriting the code of the
current dialogs.
The way I did this was to break out much of the functionality of
Dialog::Dialog into the implementations of an interface
Dialog::Behavior. The implementations that extends it are
FloatingBehavior (the current dialog behavior) and DockBehavior. Each
dialog is instantiated with a behavior and the DialogManager handles
them the same way as before, regardless of behavior.
The Dialog::Behavior interface covers most of the functionality of
Gtk::Dialog. FloatingBehavior is just a proxy for a real Gtk::Dialog
(just as before), while DockBehavior tries to emulate the dialog
functionality on a GdlDockItem. This allows all the current dialogs
(under UI::Dialog) to be dockable without rewriting them.
A global preference "options.dialogtype" controls what the kind of
dialogs to create (0 = old/floating, 1 = new/dock).
It's still a work in progress, and I'd be glad to get feedback on the
design, etc. (The class naming could probably be more
accurate/consistent, for instance.)
There's a bunch of known bugs, but I'm not experiencing any major ones
right now. I've probably broken something that used to work with the
floating dialogs, though.
Please note that this patch only works for the GKmm:ified dialogs
under UI::Dialog, so dialogs such as Fill&Stroke and the XML editor
won't be dockable.
If there's an interest in working on this, I could create a branch,
otherwise I'll just drop patches as I proceed. (I intend to continue
to keep it up to date even if there's no plan to merge it -- Inkscape
is pretty much unusable without it for me when using my primary window
manager :)
I'll be on the IRC channel in a near future if anybody would like to
discuss this further...
--
Gustav
15 years, 11 months
Save icon
by Romain Thouvenin
Hello,
I like the way many programs update the save icon with a "grey" one
when the document is saved, just like inkscape does it with undo and
redo buttons.
I wanted to propose a patch to do that, but I got lost in the code
base... Could anyone give me some hint ? Where are the undo and redo
buttons updated ?
Thanks,
Romain
15 years, 11 months
Re: [Inkscape-devel] SoC 3D box tool - website updated
by bulia byak
On 3/30/07, Thorsten Wilms <t_w_@...123...> wrote:
> As long as boxes are the only supported primitive,
They don't need to remain the only primitive for long. Very little
will change in the properties and operation of the 3D tool if we teach
it to create, for example, a cylinder or a cone inscribed into the 3D
box instead of the box itself. It should be quite easy to add.
> there's no point
> in having VPs without box is what I meant.
A VP without a box is no more useful than a gradient handle on canvas
without an obejct wit this gradient :)
> But there should be planes/grids at least, too.
The beauty of the proposed approach is that the 3D boxes themselves
can serve as both planes and grids. Any dragging of a box's corner
will snap it to the edges of other boxes, making boxes with collinear
edges very easy to do. Also there will be commands for subdividing a
box into smaller boxes in any dimension, thus creating snappable 3D
grids.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
15 years, 11 months
Escaping $ in commandline parameters
by unknown＠example.com
I just fixed a bug: string parameters were not escaped causing problems when using " . Also $ bugs on linux, because it tries to replace $... with a defined variable; if there are other operating systems that need escaping of $ aswell, please add them to the #ifdef in /src/extension/parameter.cpp line 19.
I only know Linux and Windows and cannot check for other operating systems.
Maybe a make check something should be added for this! (i don't know how, sorry)
Cheers,
Johan
15 years, 11 months
Inkscape go-slow Saturday Experiment (with data)
by Donn
Hello Eric, MenTaLguY and Bulia. :)
I spent quite some time this morning getting this data.
I did 2 things - kept a log and ran Eric's perl script. The log from the
script is 151Kb in size, so let me know to whom I can email it. (I won't
attach it to the list.)
I really tried to graph column 1 against column 2 but OpenOffice was weird,
Koffice kept crashing and I have now spent over an hour trying to gnuplot it
to no avail. I am not mathematically inclined and have given-up -- I hope you
guys make more sense of the data than I can.
I hope this helps you debug something, I'll keep watching the lists. If you
need me to try anything else, please shout.
Regards,
Donn
15 years, 11 months
Playing around
by Maximilian Albert
Hi all,
I am currently playing around with the code to get familiar with it and
find out how things work. Sometimes I stumble across a piece of
functionality that is apparently missing (or I am not able to find it).
The most recent example is that I wanted to flip an entire path
horizontally about one of its selected nodes - AFAICT from the code,
flipping is only supported about the center of a selection. So I went
ahead and tried to implement that, which worked surprisingly well.
Now I wonder if other people might be interested in this, too. I read
about the "patch first, ask later" policy. I'm not entirely sure,
however, how something like this would best be integrated in terms of
both menu structure and the precise functionality - for example, what to
do when several nodes are selected; I have come across situations where
it is convenient to choose between the left-/right- or top-/bottommost
node, but that clutters up the menus quite a bit.
Anyway, I still reckon it's better to come up with a patch first and ask
for feedback afterwards, right? In this case I'd just arrange things so
that they seem convenient to me. Would I send this kind of patch to this
mailing list or should I already submit it to the patch tracker?
Thanks for your advice,
Max
>From MAILER-DAEMON Thu Mar 29 10:48:02 2007
Date: Thu, 29 Mar 2007 19:47:26 +0200
From: Thorsten Wilms <t_w_@...123...>
To: inkscape-devel(a)lists.sourceforge.net
Message-ID: <20070329174725.GC4679@...1413...>
References: <460AABE4.1030309@...173...> <20070328182237.GC4676@...1413...>
<460BF118.20107@...173...>
MIME-Version: 1.0
In-Reply-To: <460BF118.20107@...173...>
Priority: normal
X-Mailer: Mutt
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by sourceforge.net.
See http://spamassassin.org/tag/ for more details.
Report problems to
http://sf.net/tracker/?func=add&group_id=1&atid=200001
Subject: Re: [Inkscape-devel] SoC 3D box tool - website updated
X-BeenThere: inkscape-devel(a)lists.sourceforge.net
X-Mailman-Version: 2.1.8
Precedence: list
Reply-To: t_w_@...123...
List-Id: <inkscape-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>,
<mailto:inkscape-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=inkscape-devel>
List-Post: <mailto:inkscape-devel@lists.sourceforge.net>
List-Help: <mailto:inkscape-devel-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>,
<mailto:inkscape-devel-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 17:48:03 -0000
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
On Thu, Mar 29, 2007 at 07:02:16PM +0200, Maximilian Albert wrote:
> > Just some idea of a slightly different organisation:
> > - Don't have the user add VPs or a box, but a perspective
> > object
>
> I'm not sure if I get you right here. Why would it be more convenient to
> add an "abstract" perspective object rather than just adjusting some VPs
> with a few drags, where you can _see_ what happens? Or do you mean that
> you want to be able to treat perspectives as objects of their own?
You can't have a box without VPs and VPs are useless if there is no
box. Additionaly the VPs of a perspective share a horizon.
Regarding adding a box by dragging, I'm a bit concerned about the
need for 3 drags in a row. Simply adding a box with default size
would work around this (where the 'default' size should actually
take the zoom level into account).
> Internally, perspectives will be separated from boxes anyway. This makes
> it possible to compare perspectives for different boxes, to copy them
> from one box to another (here some care must of course be taken as to
> which corners should remain fixed), to define a default perspective,
> etc. But boxes are a very convenient way to define perspectives, so why
> not use them for this purpose?
If any number of boxes can be tied to a 3-VP/horizon system,
I think this clearly establishes that there are separate entities.
The user can't form the right expectations if you try to cover this
up.
> > - The perspective object could come with 2 VPs on a horizon and
> > one box per default.
>
> That kind of perspective will be the default when dragging a box anyway
> (at least, in the beginning). You may be right, however, that one could
> try and separate the concepts a bit more from the user's point of view,
> too. But only if this doesn't make things less intuitive or more
> complicated to grasp. I'll give it some further thoughts.
>
>
> > - The number of VPs would be a parameter of the perspective
> > object like corners are for stars/polygons.
>
> Hmm, I think the number of VPs should be three unconditionally. However,
> each of them should be toggleable between 'finite' and 'infinite', i.e.
> the PLs either meet in a point or they are parallel. This provides a way
> to keep track of the _direction_ of parallel PLs, too. It's just an
> internal thing, though.
Well, where I said 2 VPs, I actually meant 2 'finite' and one 'infinite',
as I have a hard time thinking of a point if I see parallel lines ;)
> > Hmm, for setups with several boxes in different perspectives,
> > VPs have to be organised in groups.
> For what purpose exactly?
'have to be' is maybe a bit hard, but say you have 3 boxes, all on the
same plane. 2 have parallel edges, the 3rd is rotated. The 2 share all
3 VPs, but the 3rd only has the nadir in common with them.
For additional boxes, you could choose between 2 groups of VPs (or
create additional VPs).
The alternative would be to select 3 VPs for a new box, one by one.
--
Thorsten Wilms
Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil
15 years, 11 months
removing effects
by bulia byak
I plan to remove these two extension effects, please speak up if you disagree:
svg_dropshadow: writtern in Perl for which we have no support
infrastructure on Windows; is really primitive, more a proof of
concept than a useful effect. I suggest that if anyone wants to have
such an effect, it's easier to rewrite it in Python using inkex, with
gaussian blur and clones (but better wait until we have more SVG
filters supported, which will allow us to have black shadows
regardless of the color of the object).
Export groups as PNGs: seems to be redundant with the recent
improvements in Export ("Batch export all selected objects") that do
the same but in a more integrated and controllable fashion.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
15 years, 11 months
