On 7/27/05, Bryce Harrington <bryce@...260...> wrote:

On Wed, Jul 27, 2005 at 02:35:17PM +0200, Tarjei Knapstad wrote:

...

...

...

Bryce, are you going to update the roadmap?

...

Yes. It would be nice if someone could go through and mark all the completed stuff done, and/or delete tasks that are no longer needed.

I"m also hoping to continue working on the test system and continuing the gtkmm work on SPView over the next few months. I"m also playing with Cairo a bit, but only experimentally.

Hi!

Hi Tarjei, welcome aboard! :-)

Thanks, and thanks for the feedback, both you and Ralph!

...

• 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?).

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.

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.

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.

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.

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.

Thanks for all the details, I'll probably try to start out with what I feel are quite easy tasks to begin with.

...

• Cairo is something else I'm interested in, but I'm guessing this is

a bit further down the road?

Sort of. Here are my thoughts.

Cairo is not ready to drop into Inkscape right now at present. It needs optimization work, plus testing.

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).

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.

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...

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.

...

• 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?

We don't have anyone actively maintaining the livarot renderer, so yes, profiling energies would be more effectively focused on optimizing Cairo IMHO.

Noted.

...

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?)

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.

Thanks again, will do!

Enjoy your week-end, -- Tarjei