- Inkscape Devel - Inkscape Mailman

Inkscape Project Stats - Oct '05
by Bryce Harrington 17 Oct '05

17 Oct '05

Statistics Jun 1 Aug 1 Oct 1 Oct 15 ========== ====== ====== ====== ====== Max Week's Rank on SourceForge: 38 3 26 26 Total SF Page Views 1,935,964 4,452,437 4,948,483 5,329,542 Total SF Downloads 254,647 378,712 501,162 534,047 Total Freshmeat URL Hits 19,149 21,261 23,148 23,454 Total Freshmeat Subscriptions 183 208 229 233 Lines of Code in src/: 374,180 389,945 544,117 544,031 Code lines 260,236 270,423 373,797 373,738 Comment line 67,136 70,478 108,884 108,883 Blank 53,443 55,698 73,412 73,386 Lines of Docs in doc/: 27,790 28,090 27,176 27,176 Lines of content in website: 42,490 44,483 48,689 48,928 Size of the Inkscape wiki: 26,729 34,890 34,847 34,847 Bugs open/total: 215/1223 215/1445 260/1643 267/1684 Features open/total: 453/ 728 440/816 453/ 934 468/ 955 Patches open/total: 11/ 230 8/325 10/ 346 14/ 357 CVS Commits (as per inkscape-cvs) 12,040 12,915 14,201 14,372 Inkscape-devel membership: 179 200 213 217 Inkscape-announce membership: 202 236 284 299 Inkscape-user membership: 248 276 310 314 Inkscape-tester membership: 31 30 Num Translations: 33 33 34 35 Ave Translation Ratio: 47.8 54.6 51.5 51.5

1 0

Open Clip Art Library Release 0.18 Announcement :: www.openclipart.org
by Jon Phillips 17 Oct '05

17 Oct '05

October 16, 2005 - Release 0.18 of Open Clip Art Library (http://www.openclipart.org), containing over 6900 SVG files created by over 500 artists, is now available for download and use. For the month of September, the Open Clip Art Library sought imagery related to pets including images of different breeds appropriate for use by animal shelters. For the upcoming 0.19 release, due November 1, 2005, the theme is Halloween. This is any artist's chance to submit to the Open Clip Art Library images of ghosts and goblins, bats, witches, and pumpkins. The community would also welcome printable templates for creating holiday decorations usable in Inkscape, OpenOffice?, Scribus, and, or other graphics applications. Some of the highlights from this release: * New top level categories 'science', 'electronics' * New subsections 'religion', 'astronomy', 'network', and more * Flags collection has been fleshed out / improved a bit more * Bunch of new signs/symbols * Lots of new vehicles, office, sports, music, and toys clipart A lot of the previously 'unsorted' art is now sorted and moved into other categories, and several duplicates removed. While much more work is required before the collection is perfect, this release refines the collection for easier access. Please download it directly from: http://openclipart.org/downloads/0.18/openclipart-0.18-full.tar.bz2 http://openclipart.org/downloads/0.18/openclipart-0.18-full.tar.gz http://openclipart.org/downloads/0.18/openclipart-0.18-full.zip http://openclipart.org/downloads/0.18/openclipart-0.18-win32.exe Or, find one of the other packages at: http://openclipart.org/downloads/0.18/ The Open Clip Art Library (http://www.openclipart.org/) aims to create an archive of user contributed clip art that may be freely used. All graphics submitted to the project are placed into the Public Domain according to the Creative Commons Public Domain Declaration.

1 0

RE: [Inkscape-devel] Bitmap manipulation
by Charles Moir 16 Oct '05

16 Oct '05

> From: bulia byak [mailto:buliabyak@...400...] > Sent: 15 October 2005 18:04 > On top of that, in my humble opinion, this is also the most awkward > thing in Xara from UI viewpoint. The Xara strength has always been to > edit everything on the canvas. So opening a separate window for bitmap > feels extremely clumsy. Totally agree and that's the way we're going. You can already use some picture editor tools on the vector object directly such as our Enhance dialog (brightness, sharpen, blur etc). Indeed many picture plug-ins now work on canvas in Xara (on vector or bitmap objects alike). Work to do still but I completely agree, editing and painting operations should be able to be done directly on canvas just like all other tools. We're sort of about 2/3rds the way there now. Our architecture is such that they can be used stand-alone in the picture editor, OR directly on canvas in Xara, so you get the best of both worlds. i.e. the plugs-in designed to work in a pure bitmap editor, just work on canvas for free in Xara. Charles

3 2

Re: What should 'zoom to content do? (was Re: [Inkscape-devel] zooming bug)
by jiho 16 Oct '05

16 Oct '05

On 15 oct. 05, at 21:01, Ben Fowler wrote: > I am assuming that you meant to post to the list. yes sorry about that. inkscape's list should really have a "reply to" address set up if this is possible. > On 10/15/05, jiho <jo.irisson@...400...> wrote: > >> If this is a good solution for a newly opened/finished file (which >> should not have things outside the page in order to print correctly), >> I think this might be annoying when editing the file. For example, I >> very often put some objects outside the page while I edit the rest. I >> might zoom into the page on a small selection and then zooming out to >> content, including what is outside the page is a very efficient way >> of finding back all my objects. otherwise it is often a pain to look >> for it outside, or to zoom out manually, find them, move them, zoom >> back in... >> > > Terminology: Outside the page | Off the page | On the pasteboard > > If you have a small selection already made, 'Zoom to content' (I would > call it 'Fit All') is not the same as 'Fit selection'. I would suggest > that 'Zoom to content' always sets the zoom to fit all objects. I am > sorry if I implied otherwise. Ok I think I misunderstood you. Just to be clear what you propose is in fact: - zoom to page: zooms to the page ;-) - zoom to content: zooms to fit ALL visible objects - zoom to selection: zooms to the selection unless selection is larger than the page, in this case zoom to the page. is that it? in this case: "why not", but my opinion is that if there are real issues in the file, they should provoke some strange behavior in order to be corrected. > Also, I suspect that what you are looking for is a zoom between the > 'User state' (showing a small part of your drawing, possibly > defined by > a selection of one or a small number of objects) and the 'Standard > state' (showing all). I think that the key to this is to have an easy > way of switching between these states. In this case I think you might have misunderstood me. I'm sorry if I was not clear by english is not my main language. There are two things: - what I though you suggested before. I though you suggested that zoom to content should not zoom out of the page. to which I replied that IMHO current behavior (zooming to all, even off the page) was useful to quickly visualize all objects during the editing process. - the problem with the file with the insane bbox. this problem was revealed by the complete zoom out. in this case the zoom issue was in fact just _revealing_ some other problem: the fact that apparently Make bitmap copy produced an object with a wrong bbox. so in this case the problem does not come from the zoom but from "Make a bitmap copy". So in fact I am quite happy with current behavior of the zoom tool ;-) > I don't think that we can guarantee perfect or even satisfactory > results > when working with insane files, but I do think that the Interface > should > not be surprising. > > What is the least surprising behaviour here? > > I am proposing that when you make a selection, including 'Select > All' and > then 'Fit Selection' you should see the boundary selection handles > just > inside your workarea. > > I am suggesting that the meat of your report was that when you > expected > the zoom to be 66% and many objects visible, you observed the zoom to > be 1% and the objects to be the canvas equivalent as screwed up into > a tiny ball. > > It is your bug, not mine and you are free to correct me. concerning the reaction facing this bug, please see my answer to the other thread. thank you for taking care of this issue as you did from the beginning. JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/

2 1

RE: [Inkscape-devel] RE:Xara Announcement
by Charles Moir 16 Oct '05

16 Oct '05

> From: Ted Gould [mailto:ted@...11...] > Sent: 15 October 2005 00:36 ... > A couple of things here: > > - Do you expect to release the Live Effect plugins as open source also? > I thought so, but you listed it here as the additional features in a > boxed version. We can and will make the Xara owned ones Open Source. But we bundle many (17 at the last count) provided by third party companies that specialise in providing Photoshop plugins, such as Alien Skin. Very cool effects but we have no ownership or control over them. > - It sounds like your initial plan is not to sell a Linux boxed version, > is that correct? There is no short term plan to sell a boxed Linux version. Down the road (one we get to a 1.0 stage) if we can add enough added value, this might be possible. e.g. if we can persuade the likes of Alien Skin to create Linux compatible plug-ins that we could bundle in a premium boxed version, and if enough people want things like commercial support, CD, manuals, whatever, then it's a possibility. > - Have you looked at the embedded Linux market? One device that I'm > anticipating is the Nokia 770, which will run Linux. My understanding > is that the graphics application there is... well... Xara could probably > help :) An uber-fast rendering engine would definitely be of interest > to embedded developers. I think this could be an exciting potential > market for Xara, and companies like Nokia would probably pay for the > porting to their device. I love the device, and would love to put something like Xara on it. But this is exactly what I'd hope would be one of the benefits of going open-source. We couldn't justify spending time on this (unless Nokia pay us) but if there are enough enthusiasts willing to put the work in then they can take our code and create it for themselves, and everyone else. It would be very cool to do. > I totally agree on the Pantone point, but that leads me to say, why not > just leave the whole thing as LGPL Not an option because it could then be used by our commercial competitors, especially on Windows, against us. Would be hugely damaging. So I'm with Stallman on the copyleft aspect of GPL. We make our stuff free and can be used by anyone else as long as they make their stuff free as well. > and not worry about the BSD stuff. > Then you can link to other libraries as need be, and sell that as your > boxed version. Then users can contribute under their copyright, and > licensed under a single license. This would protect you from the case > where a significant contribution could be integrated by Adobe without > any contribution to the community. Ah do you mean why can't we take contributions in LGPL? If I understand LGPL correctly that only allows for linking via a defined library API. So it doesn't work for contributions to the code itself. That would still prevent us (or anyone) creating versions containing other non-open licensed code. Charles

1 0

RE: [Inkscape-devel] Bitmap manipulation
by Charles Moir 16 Oct '05

16 Oct '05

> From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel- > admin(a)lists.sourceforge.net] On Behalf Of Ted Gould > Sent: 16 October 2005 05:46 .. > ... but I think the single biggest > thing Inkscape could do to help integration is notice changes in bitmap > files. So, I link in a JPEG, and if I change that file in any other > application Inkscape notices and updates instantaneously. I think this > should be possible with further GNOME-VFS integration. Then, the > command is to just to open GIMP on the file. Yes, great. Something really simple like that. I'd support that (in Xara or Inkscape). But we'd like to go further (and part of the reason we do it the way we do with a private API) so that we pass raw (or PNG) bitmaps to and fro, to avoid the JPEG lossy cycle. We also keep the photo edit list associated with the bitmap, so you can edit it in future and alter (or undo) the previous edits you did to the bitmap. That requires a bitmap editor to remember the lists of edits, and keep a master around. But for a basic simple, still very useful feature, just watching for file changes would seem to do the trick.

1 0

RE: [Inkscape-devel] Bitmap manipulation
by Charles Moir 16 Oct '05

16 Oct '05

> Perhaps it would be a good idea to come to the Libre Graphics Meeting > 2006 in Lyon, to define your position in the OpenSource Community. > http://wiki.gimp.org/gimp/LibreGraphicsMeeting > > Tobias All ready to put in my diary, only to discover I've already booked a vacation at that time, which is a real pain. I'll see if we can send some other representative. We should be there I agree. Charles

1 0

Proposed changes to Keyboard shortcuts
by Alan Horkan 16 Oct '05

16 Oct '05

=== Patch first === The Patch https://sourceforge.net/tracker/download.php?group_id=93438&atid=604308&fil… The Patch assigns F1 to Help, Keys and moves some other keys around mapping them to ones used by Xara. The tracker request https://sourceforge.net/tracker/index.php?func=detail&aid=1326159&group_id=… === Ask questions later === (And these are just for starters) Inkscape has keybindings for almost everything which makes it very hard to change anything without having consequences, it is worse than a Rubiks cube. I tried to make changes as non invasive as possible but it was difficult. I may not use Inkscape every day but it is precisely for that reason I find it so important to try and get inkscape to use Keybindings which resemble those used by other applications. F1 for Help was one of the first and most important keybindings I learnt (and hitting Esc like a madman anytime something went wrong was probably the second). It is not just about F1 but it seems like a place to start. Beginners and new users face a much steeper learning curve if Inkscape uses different conventions from other applications. I realise an changes will be uncomfortable for existing users but no one ever claimed Inkscape was ready for stable 1.0 and not going to change things around. Experienced users should know inkscape will be subject to changes and they are exactly the people best able to adapt to changes and if we are lucky they might even like the changes because they make inkscape a little more like Xara. The long term solution is of course to have fully switchable keyboard profiles. That doesn't change the need for good defaults and I hope by trying out these ideas (even if they need to be reverted before the next release) it will encourage people who do not like it to come up with better suggestions rather than blocking changes. Using F1 for help is a convention used by Windows, Mac OS X, Gnome, KDE. The changes make Inkscape more like Xara [1] in particular. Precedent is significant but if we at least try out the change we can get a better idea of the impact. If people really hate the change and it has to be reverted it will at least help show the need for different keyboard shortcut profiles sooner rather than later. There are many more things which could be said about this but please lets try it and come up with ways to do it better rather than not doing it at all. (bulia mentioned his displeasure at the choice of Zoom key which I expect could be addressed parallel to this by providing other Zoom functionality but I think that may need seperate discussion.) Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ [1] Keyboard Shortcuts for Xara http://www.xaraxone.com/html/tip_of_the_week_4.html http://www.xaraxone.com/assets/images/tip_30.gif (I have a text reference of the Xara shortcuts too somwhere, if anyone has a reference for Corel I'd appreciate it too.)

6 17

Bitmap manipulation
by Charles Moir 16 Oct '05

16 Oct '05

On Tue, Oct 11, 2005 at 08:22:39PM -0300, bulia byak wrote: > > Another focus of Xara is on bitmap manipulation. They have a built-in > > Picture Editor, something like a primitive Photoshop. I think it's > > safe to bet Inkscape will never have such a thing - why do it if we > > can just call Gimp instead. > Well, depends what you mean by "have such a thing": calling gimp code > would count as having such a thing; though currently we don't do that > at all to my knowledge, and we certainly don't currently make it easy > to edit embedded bitmaps, or have gimp layers implemented as separate > <image/>s, or allow other vector objects to be visible when editing a > bitmap. > > pjrm. This point reminds of another area we could cooperate. We do have an integrated bitmap / photo editor, because in principle I don't believe you can or should separate the two worlds. Real users want to mix photos and vector artwork, and so it's simply more convenient to be able to do this directly from within your vector editor. (And Microsoft Expression will be majoring on this point - integrated bitmap and vector editing, indeed the only significant change MS have made to Expression they bought, is adding a fully integrated bitmap editor) So in Xara X we added an API to call an external photo editor, so that you could double click a photo, (or a bitmap fill) edit your picture, close the window and the edited result is passed back. The theory was that we could use any external editor and were not going to make it specifically the Xara Picture Editor. So in principle this is exactly like you guys calling out to GIMP. But our Xara <-> Picture Editor API sucks, partly because it's very COM based and partly because it's become very specific to our implementation of the photo editor. Worse, our Picture Editor component is going to be an absolute dog to port to Linux because unlike Xara X, it was never designed to be the slightest bit platform portable. GDI+ code everywhere, transparent fading, rounded dialogs, the lot. This remains a major potential stumbling block for the port down the road (it will be the last component we do). So we should also be changing our API to be more general purpose. So the user can configure their favourite photo editor to be called when they want to edit a photo. So, if this is a feature that you guys are thinking of adding to Inkscape, lets have a common API to call external photo editors. Then we can be compatible - we can both use and call Photo editors in a compatible way. What's more this provides an added incentive for the various photo editors out there to support this API and so greatly increase the interop and choice for all users. I might be talking b**ls here, because for all I know Linux already has an open, common API to pass photos to and from the various picture editors. But it seems another area where we could both possibly develop a feature in parallel, but both benefit equally from it. Or is this rubbish?

4 3

RE: [Inkscape-devel] Bitmap manipulation
by Charles Moir 15 Oct '05

15 Oct '05

> > I might be talking b**ls here, because for all I know Linux already has > > an open, common API to pass photos to and from the various picture > > editors.... > > I don't know of anything *specifically* for that. > > However, there is an API that might be relevant here, with added benefits. > It's a network protocol, primarily for 3D graphics collaboration, called > "Verse": > > http://www.blender.org/modules/verse/ > > Performance could be an issue for large bitmaps, since it's a network > protocol, but perhaps an optimised version could be used locally. This is interesting and possibly suitable. Might be more suitable as an API to interface to 3D apps (which is another area altogether - Illustrator and Corel have had good 3D capabilities for a while). Charles

2 1