In-depth review of Inkscape

GTK+ won't have a Cairo widget. GTK+ will be entirely based on Cairo. Watch out GTK+ 2.8 !!

Surely you'll still be able to draw bitmaps?

You kind of *need* to as a lot of graphics don't scale down to 16x16 or 24x24 too well.

Should work--SVG can embed bitmaps.

--John Stracke

I really can't speak to why Lauris has been, ah, intermittent. This time, though, he agreed to hand over the keys to the codebase; I'm hoping I can rescue it.

I think my major thrust is going to be creating a scripting interface (with Python bindings, I think). The immediate benefit would be plugins, as in GNOME; but the long-term goal would be to beef it up so that it can be used for building different UIs on top of the SVG core. That would open it up for more people to experiment with improvements to the UI.

-- John Stracke

Inkscape has beginnings of Perl and Python scripting already in the codebase. In CVS there's even a "Script" dialog with some example script. It's not really usable yet because little of the functionality is exposed, but the foundation is laid. Why not work on Inkscape scripting instead?

show some respect to people who have actually DONE something!

you obviously have not heard about things called "politeness", "respect to other's opinion" and the like.

your philosophy seems to be "i don't like your ideas so i can spit to your face"

Nobody is/was stealing code from sodipodi, as far as I can see is/was sodipodi licenced under the GPL so forking the code is legal, in other words not stealing. The nice thing about this is that some great projects weren't hijacked by dictorial developers, look at gcc and how it was forked and the fork became the mainline again after it was a better gcc. Look at xfree and how it stalled for years and now xorg is taken the lead.

Forking doesn't automaticly mean that everbody is jumping ship, there are many forks which died while mainline continued and/or remained the popular one.

I don't see why a sodipodi/inkscape, xfree/xorg, gcc/egcc/gcc fork should be bad and a mozilla seamonkey/firefox fork should be good, because of the will and proud of one man? Then he should have used another license!

Many developers don't actually reflect about the fact that the GPL in fact in some way takes away their code. Once published, others can use and modify the code for whatsoever purpose. I'm heavily supporting GPL, just saying that devs should be in knowledge of these facts.

On your comments: I think insulting people doesn't help anybody. Lauris as an individual has spent years on Sodipodi and thus Inkscape, he is a respectable person and the right of being heard, even if you ignore his arguments. Insulting him disqualifies you and your point of view. Forks always hurt.

I don't think I was insulting. Laurus has developed a great application and released it under the GPL and I admire that. But it is totally unfair to ignore the great advances Inkscape made with the same code base after the fork. Too me this is a indication that there was a conflict of interessed that couldn't be resolved in the form of the Sodipodi project, and a GPL project is more then the lead developer alone! The contributors, should when time advance, get more and more influence. The fork and the state inkscape is in now indicates clearly that the contributors where being ignored. Again, if you don't want this to happen you should use another license.

The great advantage Laurus could have is that he can take things from inkscape if he wish, afterall it is GPL.

Yeah but if the code is GPL'ed, you can take back whatever others took from you. That's the whole point.

You're expounding only commonly held urban legends about C++. Anybody who's actually used the language to any extent knows otherwise.

Sorry, but I followed the link to the CVS repository and had a look at the new C++ based Inkscape code. I doubt that the code could possibly be much worse. Perhaps if it was written in Perl...

Perhaps you noticed that what takes about 7,000 lines of code in inkscape_gtkmm/C++ takes about 15,000 to 20,000 lines of code in mainline Inkscape/C...

That is however not an inherent feature of the programming language. Refactoring the old code and porting things to GObject / GTK+-2.x would most probably have had a similar effect on codesize.

It's a feature of the programming language because C++ can abstract more things behind the class interface, and you need fewer calls on objects than with the GObject model.

The legacy code already uses GObject and GKT+-2.x... Moving to Gtkmm is what's significantly impacting line count.

All you save is the (admittedly annoying) boilerplate code that's needed to define a class. You can however also cut that code down to a few lines using the GType boilerplate macros defined in gtype.h.

As an InkScape user, let me suggest why I think it doesn't have a palette:

Because it already has "paste style."

If you want the equivalent of a palette, just make a bunch of rectangles, color them how you like, and then paste-style from them.

That is, click a rectangle, type CTRL-C (copy), and then click where you want it's styled use- type CTRL-ALT-V (paste style), if I recall correctly. Or maybe it's CTRL-SHIFT-V; one of those two.

There's no palette because no one yet coded it. As simple as that. If you send us a palette patch, we'll gladly accept it.

That said, what you say is true as well, to some extent. Many conveniences, including the Paste style and the Dropper tool, were added that alleviated the need for a palette, making it a less urgent need. Still, it would be nice to have it.

You expect me to make a bunch of rectangles any time I draw a picture in Inkscape? I can't believe I just read that.

I don't want to copy styles with a ctrl-shift-whatever magic key combo. I don't want a palette EQUIVALENT. I want to have a palette, which is visible on the workspace at all times, which is easy to access and which is easy to use. Vide: Corel Draw - the palette is very compact, yet the colors are well visible, left click changes the color, right click changes the border color. Easy as pie. Is that too much to ask for? For me, it's functionality which is absolutely fundamental. Even MS Paint has a palette.

I'm confident that Inkscape developers are aware of this issue and will take care of it sooner or later :)

(Not the previous poster, but...)

Ah, right. Instead of the program working the way I want, I have to work the way the program wants. No thanks. I'll stick with my Mac to do graphics.

Unlike Mac, with Inkscape, even if you don't have program working the way you want, you can go on and fix it. True, Inkscape is still very clumsy in some areas. In other areas, however, it is very convenient - even more convenient than Illustator, as Jimmac notes in his review (re: pixel movement and scaling with Alt). This is because those who worked on it influenced its development in those areas. Join us and you'll be able to influence it too!

Unlike Mac, with Inkscape, even if you don't have program working the way you want, you can go on and fix it. True, Inkscape is still very clumsy in some areas. In other areas, however, it is very convenient - even more convenient than Illustator, as Jimmac notes in his review (re: pixel movement and scaling with Alt). This is because those who worked on it influenced its development in those areas. Join us and you'll be able to influence it too!

If you step back and consider carefully, you'll realize that you have to work "the way the program wants" to use *any* software. You're just so used to the Mac/Illustrator way of working that you *think* it's your way when it is in fact Apple and Adobe's way.

What happens if you press Tab several times in a row and what would you expect to happen instead?

OK, this is WAY off topic.

Let's say I have an image open and the workspace window is maximized, the toolbox and dockers are above it, but the workspace is focused (gimp-2.2).

Press tab once, all dockers disappear, like they should. Press tab again, only the toolbox appears, and it gets focus, so you have to click the workspace (the window with the image) and press tab again to bring the dockers back. But then the toolbox hides itself under the workspace (which is maximized), so you need to find it on the taskbar and bring it back if you want to change something in the dockers as well as your tool (switching mouse mode to XMouse doesn't really help). Setting the sticky-on-top attribute for the toolbox and the dockers won't help because that attribute is lost when they're hidden (gnome 2.6/metacity). Setting different window manager hints in the gimp doesn't always work.

In effect, every time I use a tool on the image, every window hides behind it, and I have to bring the toolbox/dockers back either by TAB or by digging in the taskbar.

When I'm editing a large image in Photoshop, I hide my dockers up to 15-20 times per minute. By the annoying behavior I described, Gimp slows me down by a factor of 5-8, rendering itself useless. In my opinion, some kind of functionality should be introduced to emulate more photoshop-like behavior in this case (1: the toolbox and the dockers remember their always on top state, 2: they disappear and appear simultaneously when pressing tab). Either my WM/Gimp configuration is broken, or Photoshop has this far better organized.

There's an option in the GIMP to force the toolbox and any free-floating docks to register themselves as "Utility Windows". If you do this (and restart the GIMP) then they won't be focused when you "tab" them. They also will not show up in the task list.

Look for this option under "Window Management" in Preferences.

I don't know why this isn't a default setting, but I'm guessing it has something to do with some Windowmanagers not properly supporting the specific Utility-window-hint.

errr, gimp has nothing to do with the focus of the window. that is entirely the window manager's work. If your WM has an option to not set focus to new windows (E16 has an option like that), then the canvas will keep the focus after the TAB.

There are lots of different ways of using the GIMP. Personally, I'm using Xinerama (one desktop spanning two screens) and I keep all the palettes and toolboxes on one screen and edit the image on my big screen; this setup works very well for me.

You should really bring this up on the gimp-developers list, which is very active right now. Bring this to the developers attention, and I'm sure that they'll help you out.

I think you should bring this topic up on the GIMP developer mailing list. At the moment plans are made for 2.4, it's a good time to suggest changes.

Thanks for the advice, I'll visit the list when I have some spare time. I'm glad I didn't get usual replies like "go to he** you photoshop freak"

go to he** you photoshop freak

hehe just kidding. seriously though if you are that heavily doing graphics work I find that better then anything is the xinerama mode using 2 monitors. i understand that not everyone has this option but once you've gotten into the 2 monitor mode you'll find that it is worth purchasing a 2nd monitor and taking it with you to work if needed to have that :)

I tried that setup once with some other software several years ago. I must say that although it's convenient I got quickly tired of travelling miles and miles with my mouse (or maybe I didn't use 2 monitors long enough to get accustomed to it). I just prefer to use the magical tab key frequently :-)