March 2007 - Inkscape Devel - Inkscape Mailman

win32 build working again
by Bob Jamison 08 Apr '24

08 Apr '24

The win32 build, which was broken for the weekend, is working again. I just made a "manual autobuild" again, so that we can see how it looks on Windows: http://troi.titan-aeu.com/~rjamison/inkscape/builds/ Bob

2 1

inkscape git mirror?
by MenTaLguY 18 Jun '08

18 Jun '08

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

6 11

Odd size of imported bitmaps
by Dan H. 31 Aug '07

31 Aug '07

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

4 5

[PATCH] Dockable dialogs, and some concerns...
by Gustav Broberg 23 Apr '07

23 Apr '07

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=9… 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

17 46

Save icon
by Romain Thouvenin 10 Apr '07

10 Apr '07

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

5 6

Re: [Inkscape-devel] SoC 3D box tool - website updated
by bulia byak 08 Apr '07

08 Apr '07

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

5 10

Escaping $ in commandline parameters
by unknown＠example.com 05 Apr '07

05 Apr '07

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

3 4

Inkscape go-slow Saturday Experiment (with data)
by Donn 03 Apr '07

03 Apr '07

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

2 5

Two bug fixes
by - - 01 Apr '07

01 Apr '07

[ 1516323 ] Context Menu of Object with "Link" is bogus [ 1689087 ] Typo in perspective.py Hi, I tried to create a diff file for those two. It's a very small change, but it's my first time working on open source and with svn, so I just wanted to do something simple first that wouldn't mess up any of the original code. Also just to check whether I'm following the right procedure. Weblinks: http://sourceforge.net/tracker/index.php?func=detail&aid=1516323&group_id=9… http://sourceforge.net/tracker/index.php?func=detail&aid=1689087&group_id=9… For the first bug, it was suggested that "Ungroup" be removed from the menu. However, I left it there, as it had much code attached to it, and wasn't sure it was desirable to remove it. -Omar. _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter

3 2

Playing around
by Maximilian Albert 01 Apr '07

01 Apr '07

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

3 6