Bryce, are you going to update the roadmap?
Hi!
I've had an eye on Inkscape for some time now as an interesting project that I might want to get involved in. As I've started to get some more time on my hands lately, I guess now might be a good time to jump in :) I've got about 6 years of C++ inexperience (the last 4 professionally) and I've done quite a bit of UI code (gtkmm in the beginning, but Qt for the past 4 years).
I've got some comments/questions first though, related to the quoted text above:
- An updated roadmap/tasklist would be very nice, looking forward to that.
- I'd be interested in helping out with the Gtkmm work, so I'm curious about the state of affairs in that department. Does the current gtkmm stuff live in a separate branch in CVS? I've done some gtkmm/libsigc++ code in the past (will have to read up on the API's again :)). I'll read through the Rearchitecture discussion in the Wiki later tonight to try to get a better understanding of where you're headed (are these documents fairly up to date btw?).
- Cairo is something else I'm interested in, but I'm guessing this is a bit further down the road?
- It would be nice to have faster rendering of the documents under windows (I think I read a bug report on this). Is there any interest in profiling and optimising the current code, or is the move to Cairo as a vector drawing backend meant to take care of this so that it would just be a waste of time?
In any case, I'll start out with familiarising myself with the current codebase first. If any of you current developers have any small/minor tasks I could get my feet wet in that would be great (speaking of which: is the InkscapeJanitors page in the Wiki still valid?)
Cheers, -- Tarjei Knapstad
I'm only lurking here for a short time but will try to answer:
You wrote
No. It's compiled in and can be accessed with inkscape --new-gui
to try to get a better understanding of where you're headed (are these documents fairly up to date btw?).
I think you'll find the latest with searching in the dev archives.
I've heard it's already working but the plan is to wait until the speed is in inkscape's order of magnitude.
Cannot comment on that but the code has several strata and I doubt a short-time effort will result in overall (!) speedups.
Yes, and the bug tracker, too. After two patches, you'll get the blessings. Good luck!
ralf
On Wed, Jul 27, 2005 at 02:35:17PM +0200, Tarjei Knapstad wrote:
Hi Tarjei, welcome aboard! :-)
Hopefully I'll get to that soon, but if anyone else is interested in working on updating, go for it. Basically we just need to mark the stuff that's done, done, reorganize tasks a bit based on what people are actually working on, and add in tasks that we know need to be done in the near/medium term. We need to keep the scope of the 0.43 work well controlled, though, because we want to push out the release relatively soon, so won't have time this go around for anything super ambitious. Hopefully, though, we can knock off some low hanging fruit and fix some of the more troublesome bugs.
Actually all the gtkmm stuff is integrated into the mainline codebase now. At this point it's probably more correct to speak not of "the gtkmm work" as a single thing, but actually to identify the discrete gtkmm projects, because they're all relatively independent now.
First is the gtkmm dialog work. This is actually pretty far along and received a lot of attention in 0.42. A number of dialogs are now 100% gtkmm, some are mostly gtkmm, and others still haven't been converted. The remaining dialogs are the harder to convert, however the ones that have been converted should give good examples on how to do it. A lot of the work in this area will be straightforward refactoring. The one thing that might be a bit of a challenge is that we want all the dialogs to conform to the same style; since gtkmm leaves a lot of options open, you may have different ideas for implementing a given dialog, but it's important to maintain consistency across all dialogs in order to make future maintenance easier. The number one goal of converting dialogs to gtkmm is to make them easier to maintain, and if they share a common implementation style, then for future developers, once they've worked on one dialog they should be able to easily come up to speed on working on other dialogs.
Next is the main window work. This involves conversion of two code objects: SPView and SPDesktop. Each of those also have a variety of accessory classes to convert as well. This is the area I've been working on, and I'm trying to do it by first refactoring these from C to C++. If anyone's interested in working on this, I can give more details.
Third is the Canvas object. This is the code that wrappers the underlying rendering system. Ideally, this would be wrapped and packaged in a way that it could be used separately from Inkscape, but this looks to me like it'd be a huge challenge. Fortunately, I think we can get most of the other gtkmm stuff done without touching this code. This also potentially ties in with the Cairo work. I personally would like to see this developed in a way that'd allow "pluggable" renderers, so we could allow switching between livarot and cairo for testing / compatibility purposes, but I know others prefer just switching to cairo directly, without adding an abstraction layer, so this may not happen. In any case, a distinct Canvas object usable independently from Inkscape would be a boon for a lot of other projects.
Fourth, there are several main window components such as the statusbar, context menu, and so on that have not received any attention so far. We have the gtk+ code for these items, and they just need to be converted to gtkmm. I suspect the best approach is to refactor them in place. The current statusbar code is pretty good, although it could use a few enhancements. The current context menu is okay but could use a lot more attention to make it more usable.
Anyway, each of the above can be worked on independently of the others, so if one sounds interesting, you can go ahead and focus on working on that.
Sort of. Here are my thoughts.
Cairo is not ready to drop into Inkscape right now at present. It needs optimization work, plus testing.
However, I think we could have a big impact on bringing Cairo closer to production by experimenting with it. For example, I've been testing its renderer against Inkscape's and communicating the issues back to Carl Worth. So even though this is being done independently of Inkscape, it will help resolve issues we would otherwise run into, before we get around to incorporating it.
As well, I also think there is a LOT of intermediary work needed to investigate how to interface an Inkscape-style document model with a Cairo-style rendering API. This API is different from livarot's renderer, and I think some prototyping and raw experimentation would go a long way to helping close this gap. I have further ideas about how this could be done, that I'd be happy to share if someone is interested in working on it.
Anyway, so while we're not at a point where we could plug Cairo into Inkscape at this moment, there is certainly a lot of fun and necessary work that could be done right now to help accelerate our ability to adopt it.
We don't have anyone actively maintaining the livarot renderer, so yes, profiling energies would be more effectively focused on optimizing Cairo IMHO.
Great! Yes, the Janitor's page is still relevant, I last updated it a few weeks ago IIRC. Also, you could dig through the bug tracker for gtkmm dialog issues - I think people were able to close all the serious ones but there may be some minor glitches needed that may be good learning projects. In any case, ask questions here or on IRC if you get stuck.
Bryce
On 7/27/05, Bryce Harrington <bryce@...260...> wrote:
Thanks, and thanks for the feedback, both you and Ralph!
I see, will take a look at what's done and not and hopefully start playing around with the code some more during the weekend.
Decoupling is almost always a good idea in my experience, so I support your view here. I don't know if it's as easy as making a virtual canvas interface class which you could just inherit from and reimplement, but it's an appealing thought to me at least. Benchmarking would become a lot easier with something like that in place, and you wouldn't be tied into Cairo as much. With an implementation like that you could change renderers runtime if you liked, or do things like split the view in two and run two renderers in parallell to get a very good feel for the performance.
Thanks for all the details, I'll probably try to start out with what I feel are quite easy tasks to begin with.
Yes, I remember reading on various mailing lists that Cairo wasn't quite up to snuff performance wise yet (there was some concern on the Fedora lists that a switch to Cairo as the desktop rendering backend would bog things down for users with older equipment).
I'll have to plead ignorance here for now, but I assume that Inkscape documents are represented as SVG throughout? I had a look at the Cairo CVS repo last night, and noticed that there's a libsvg-cairo which renderes SVG documents (either from disk or from a buffer) through Cairo. Is this something you've had a look at? One possible problem that springs to mind is that this library is not flexible enough to handle realtime editing of SVG docs, but this is just speculation at the moment...
Noted.
Thanks again, will do!
Enjoy your week-end, -- Tarjei
On Fri, Jul 29, 2005 at 03:11:14PM +0200, Tarjei Knapstad wrote:
I see, will take a look at what's done and not and hopefully start playing around with the code some more during the weekend.
Great, make sure to pop onto IRC to ask questions.
I'll have to plead ignorance here for now, but I assume that Inkscape documents are represented as SVG throughout?
There is an XML parser that reads the SVG and creates a big tree of all the elements, their styles, referenced elements, etc. etc. This tree is called the "Repr" (I think it's short for Representation).
This Repr is used as the "input" to the renderer that generates the rasterized version for the screen or PNG, and it can be interactively tweaked, altered, and so forth. The undo system is also tied in with the Repr to allow "journalling" of changes so the user can easily go backwards or forwards in the change history. The Repr can also be run through a command to write it out as SVG.
Thus, the SVG is represented in memory in a fashion directly analogous to the SVG file, but it's not literally SVG at that point, but rather an expanded structure that is easier to interact with programmatically.
Yes, I've looked at this, although not recently. I think it is definitely worth additional study. When I looked at it a year ago it was not in a form that we could use in Inkscape except as an example of one way to hook SVG and cairo together, because it didn't allow for interactive, dynamic updating of the view. However, much has changed in recent months and I think it needs to be reexamined. I'd love it if we could reuse it instead of creating our own svg wrapper on Cairo, but since Inkscape's needs here are pretty intensive it may make more sense for us to have the wrapper code inside Inkscape where we can work on it directly.
However, this is all just my guesses from very brief looks at all this code, I think it will really require someone to experiment with all these components to see what can be done with them.
Bryce
I noticed this:
Bryce, are you going to update the roadmap?
And please show us how to fold it. That's always the hard part.
You guys are getting far too serious. You're forgetting the "Have Fun" core goal of Inkscape :-)
Buy your sysadmin a bagel today: http://www.sysadminday.com/
Bob (ishmal)
participants (4)
-
Bob Jamison -
Bryce Harrington -
Ralf Stephan -
Tarjei Knapstad