Recent blog entries for mpesenti

My Blog has moved to gnome.org. Link: Marco Pesenti Gritti

I started phase 2 of my mozilla SDK fight. In other words I'm starting to identify and solve problems with the embedding API. Mozilla hackers seem to be interested in feedback and that's a good start. I like how mozilla 2.0 plans are shaping up, I think mozilla has a chance to become a very good development platform on the not too long time.

One positive aspect of working in two communities is that when you are sad about how things are going in one, you can feel better about progresses on the other side ;)

I think there are a few misconceptions that are stopping the Mono debate to be productive:

• It's not Redhat VS Novell. Realistically decisional power in this case is up to big distributors since it's up to them to pick technologies they want to ship. Though the decision is going to affect not affiliated contributors and probably mainly them.
• The concerns part of the community is expressing (again, not only Redhat employers) are real fears to be moving in the wrong direction, not an attempt to spread FUD on the Mono team. Everyone loves Mono as a technology and admires the work the team is doing. Some of us are just worried about the strategical and legal implications of such technology.
• Diverging so strongly on a core part of the desktop strategy has an high cost. From an user point of view I can see that being a blocker for a top-down design of the Desktop. From a not affiliated developer point of view I have no idea on which framework I should base my next project on. Mono is tempting but the fact that an important part of the community would not use and distribute it is a blocker.

Energy can be ambivalent. It's without any doubt positive when it builds something, even incomplete or flawed. But it can also be disruptive. In which case you'd better try and control it.

Seth is expressing very well my (and I'm sure of a large part of the community) concerns about Mono. Sadly this looks already like yet another (de facto) fork of the free desktop strategy. I hope there is a way to recover but I wish we had this argument a while ago.

I landed a pair of mozilla embedding patches, and I'm waiting for another one to be checked in. The GRE work is almost complete. I guess I'll have to wait embed string/private string incompatibilities to be fixed though, even if I'm not experiencing problems on linux.

Integrating mozilla and GNOME printing is not as easy as I'd have hoped, mainly because there is not yet something like a GNOME print system (or at least something stable, that we are planning to keep supporting in the future). Though I think providing a generic, full featured, frontend that can work with multiple backends could be a good start.

I should get back hacking on Epiphany a bit more, I guess I'm just a bit demotivated and time lacking at the moment.

I'd like to give gcj a try, but I'm too lazy to bootstrap another jhbuild tree. I guess I'll just wait the whole thing to be merged in real jhbuild.

On a side note, I finally graduated, it was about time :P

My thesis discussion is near now (18 May) and I'm pretty busy organizing latest details, did not get much done in the last few days :/

The GRE work is progressing slowly but pieces are getting in place as I would like. In particular Darin will work on a fix to allow mixing nsEmbedString and private string in the same DSO. That means my GRE patch will not break mozilla static build (the hard part of mozilla development is to deal with multiple platforms and builds) and that we will be able to port epiphany code to use nsEmbedString gradually.

Had to setup a windows build of mozilla to be able to test nsComObsolete.h kill off. That was really not fun, it's so much easier to install a linux distribution with all the tools you need then setup cygwin/mingw.

jorn You are my hero. I think your   contribution to GNOME multimedia will be great, indipendently of what player will be officially distributed.

I'm doing some very boring work to cleanup epiphany mozilla inclusions and separate public api, private api, api incompatible with embed string. We are actually doing better than I thought. We are not using that much private stuff and incompatibility with embed strings looks fixable. I think this will help me figuring out stuff we need to fix in mozilla SDK.

Got approval for another Mozilla SDK bug. I have not been able to get someone to check it in so far though :/ Mozilla patch lifecycle is somewhat bloaty. I need to bug 4 different people (r, sr, a, checkin) to get a patch in. Oh well I guess at some point I'll be a mozilla guru and I'll get a cvs account ;)

This really need to be fixed. You cant have to go through 3 different private interfaces to be able to attach mouse event listeners.

Argh, need to go to civil service now, I'm late as usual ...

Very interesting thread about Mozilla cross-platformness, starring Brendan Eich and MPT.

Finally I've been able to post the gnome print integration plan bug. I think it's a great, concrete chance to work with mozilla developers on something that will affect both epiphany and firefox, let's not waste it ;)

Frustration: being on a meeting with a bunch of incredible people, having lots of things to say and not be able to get involved or even understand the conversation because you cant talk or understand their language.

Sorry, I really hope I'll find ways to be more useful :/

jorn I hope you will reconsider the backend switch. Could you explain, in detail, what are the issues with gstreamer? Bug numbers, criticisms of the framework design, blames on the maintainers to not deal with your requests... everything would be useful to identify the problem and try to solve it in a reasonable timeframe. I'm convinced a bit more communication would hugely improve the situation.

My fight with mozilla SDK continues. It's taking a lot of my time but I think it's necessary, it's not my favourite hack but someone must do it. So, since this has been the main topic of this blog lately I'm in debt of an explanation to my 3 readers. Gtkmozembed is a nice, simple widget that allows to embed mozilla renderer in GNOME applications. To be able to adopt it more widely in GNOME applications (see devhelp, yelp, evolution at least) we need to solve some issues:

• 1) DISTRIBUTION. We need better modularization. Atm you need to install the whole mozilla browser to be able to use the widget. It would be cool to be able to have mozilla-gre package with the base libraries that GNOME applications could use and mozilla-browser, firefox packages dependent on it.
• 2) STARTUP. To start up an application using the widget now you need to create a wrapper script to setup LD_LIBRARY_PATH to point to $prefix/lib/mozilla-$version. Mozilla libraries are installed in a versioned subdirectory because they are not api stable. This is probably the bigger cause of bug reports: the result of running epiphany with a different version of mozilla than it was compiled are obscure undefined references.
• 3) TOOLKITS MIX. Gtkmozembed api lack some basic functionalities. It's possible to write XPCOM code to use mozilla interfaces directly, but that's somewhat ugly code wise and anyway require to learn about XPCOM. For basic functionalities it would be desiderable to depend only on the gobject api.
• 4) API. Mozilla public apis are beings stabilized but they are still somewhat bit rotten and incomplete. I think what they really need is api users bugging them to fix this situation (and helping obviously)
• 5) COMMUNICATION. There is basically no communication between the two communities. This need to be solved ASAP, we de facto depend one on the other technologies.

Here are some of the things I'm doing and plan to do to improve the situation:

• Make gtkmozembed a GRE client. libgtkmozembed.so will be versioned and installed in system lib path so that it can be parallel installed. (This solves 1 and 2)
• Fix problems with mozilla SDK. In particular we have finally an embed string api (string api changes has been the worst mainteinance hell for epiphany and galeon so far) but there are some mozilla interfaces that doesnt support them yet
• Work with mozilla developers to add missing apis instead of just using private interfaces
• Port gnome applications to use gtkmozembed. Mikael ported devhelp already and I need to convince shaunm to let me port yelp :)
• Add api to gtkmozembed for basic functionality. Find, print and zoom come to my mind. We need a solution for preferences too (fonts for example). We could add simple get/set api but ... it would be so much more useful to bridge gconf and nsIPref :)
• Mozilla has a command handler api where you can use strings like "cmd_cut" to execute actions (and get notified about their state). The editor is heavily based on them. Probably a set_edit_mode and + command handler api wrapped in gtkmozembed could allow to acces most editing functionalities with a gobject api.

I opened bug 140713 about this. Feel free to add notes there if you are interested. It's the first of the plan tracking bugs (man, I'm slow), I'm going to post one about gnome print integration ASAP.