Older blog entries for mpesenti (starting at number 25)

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 :/

21 Apr 2004 (updated 21 Apr 2004 at 19:09 UTC) »
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.

21 Apr 2004 (updated 21 Apr 2004 at 13:00 UTC) »
clarkbw Congratulation for your position, I was really hoping that. Now my two favourites designers works full time on linux desktop. This sounds so promising :) Btw any reason clarkbw is not on Planet Gnome ?
17 Apr 2004 (updated 17 Apr 2004 at 09:31 UTC) »

I have too many ideas floating around, too many unfinished things, too many things I'm waiting for to be finally concluded but they keep getting delayed. Need to bring back sanity...

First step cleanup bugzilla, second complete the plan for 1.4. Third start really fixing bugs.

If there is something I totally hate is to wait ... I especially blame italian mail to take two weeks (so far) to deliver 80 Km far a mail I really care about.

I'm going to have a free Sunday finally, possibly the only one until October. I really need to spend it in something else than hacking :)

15 Apr 2004 (updated 15 Apr 2004 at 10:27 UTC) »

I completed my GRE patch, waiting for a review now. Luckily I think it will still be possible to run current galeon/epiphany code with just configure changes (keep to link to libxpcom at compile time basically).

On the bad side I doubt we will be able to have multi screen support any time soon. Mozilla widget/gfx code is not multihead aware. Most of the code would be easy to fix (apart the mess of having to keep gtk 2.0 compatibility), though there are some services that are global while they should be per-screen or per-display (most notably the look and feel service). Fixing this looks .... hard :/ It's a very frustrating situation: the incompatibilities between mozilla and GNOME platforms (or more in general linux platform, see the situation with translations) are a major block to further integration work. It's so demotivating to have the whole picture easily figured out on the GNOME side and then block on hardly solvable incompatibilities.

I think it's now clear that the two communities need to merge their efforts and build a common roadmap. The sad browser situation is only one of the issues. GNOME needs several mozilla.org functionalities (rendering engine and XUL for example) and mozilla.org platform needs a desktop (as a set of technologies, an user interfaces system, a set of guidelines, a GUI design philosophy) to be grounded on. Web technologies are going to increase (even more) their importance on the desktop and we need to ensure they are properly integrated in our platform ASAP. GNOME has no resources to reimplement XUL or a rendering engine. Mozilla.org has no resources to reinvent the desktop. If you add a components system and the ability to use multiple languages on the top of it well ... that's more or less what we are looking for. A native frontend is a good solution to the browser problem, the only viable on the short time, but it only goes so far.

Brendan "proposal" is interesting and we should carefully consider it. If mozilla.org is finally considering the free desktop as a primary target, and they are willing to promote _real_ integration with the free platform, then I think there is space for a merge. It's a lot of work and not only code to write or design. There are social spaces to share, conventions, habits, tools, roadmaps to merge. Though I think it's a necessary step for linux to succeed on the desktop.

(hoping to not get out of my dream to discover this is just a marketing strategy to push some applications in Linux distributions...)

7 Apr 2004 (updated 7 Apr 2004 at 11:33 UTC) »

My immediate reaction to Brendan article is mixed. Braindump follows.


- Mozilla foundation seem to be considering Linux like a primary target ("Let those enterprises migrate to Linux if it makes sense, or defer the hefty Longhorn upgrade tax by sticking with downrev Windows for as many years as makes sense."). This is a fundamental prerequisite if we want to build the future linux platform together.

- It seem to anticipate a different approach to multiplatform where native, available technologies are reused (while filling gaps on some platforms)


- Migration to the future platform need to be gradual. For reasons that I dont fully understand mozilla.org is advocating the substitution of current linux desktop applications with XUL based counterparts. The merge need to happen on paritary basis, gnome libraries or mozilla libraries are an equally good way to write apps until Gnomzilla platform is available. I can see new Evolution features being written using the Gnomzilla platform (Mono + XUL for example) and mozilla rendering engine integrated in the old code using gtk wrapper (gtkmozembed). I cant imagine adopting Thunderbird though. The prioritary goal is to have a mail client well integrated with linux Desktop. My feeling is that what you can really share cross platform are just the engines, the UI needs to be special cased to be really integrated. But, even ignoring this, it doesnt make sense to throw away all users benefits of current solutions to adopt immediately and completely the new platform. A gradual migration path is necessary ...

- I fear the complexity of the merge is heavily understimated. Given the current status of mozilla SDK I'd be positively surprised if by "2nd half of this year" we would have something that can easily work outside mozilla tree, based on stable API etc. Let alone how much time really merging it with GNOME technologies will take. Because of this reason gradual migration is even more important.

Anyway I think it's crucial that the two communities start to communicate and cooperate. (Got my first epiphany patch by a mozilla hacker, yay !)

I feel like we are at an important time for the linux desktop future. I really hope the result will be reduction of the fragmentation rather than increasing.

BTW the gtkmozembed GRE work is progressing thanks to the feedback, the help and more importantly the patience of people like bsmedberg, blizzard, darin, biesi. But yeah yeah this isnt really exciting anymore, everyone wants Gnomzilla now, I'll see what I can do :P

31 Mar 2004 (updated 31 Mar 2004 at 10:51 UTC) »

I have got a basic version of gtkmozembed working with the GRE. I had to strip out some features because I cannot use mozilla internal api. I think using the SDK is a better approach then having an interface in the middle to work around the problems with the SDK itself. The interface in the middle solution is a bit like claim mozilla failure to provide an usable SDK :) The API problems seem to be solvable to me, I'm more worried about mixing glib and mozilla api for the strings, especially because memory allocation is not compatible. Maybe the minimal embed string api should have a way to do unicode conversions (utf8 <-> utf16). Oh well let's see if there is interest in this approach at least.

Now that I have figured out the GRE thing I'll be back working on multi screen. Mark suggested me a way to test with software only. Rocks !

Xnest -ac -scrns 2 :1

Today I have to meet with my thesis co-relator. Hope everything goes well. Wish me luck :)

30 Mar 2004 (updated 30 Mar 2004 at 11:14 UTC) »

We've finally been able to publish 1.4 plan: abstract and concrete, very much a work in progress.

My personal fight with mozilla SDK continues, well at least we are progressing.

Did some basic work on multi screen, my problem is that I cant really test it. Synap promised to help though. Anyway is there a way to do test without hardware ? Alternatively, could someone send me the required hardware :P

Finally a few day out of civil service. Staying 6 hours a day with old people is ... well ... stressing ;) I went to skying yesterday and this morning, I got some photos but I've been too lazy to put them online so far.

28 Mar 2004 (updated 28 Mar 2004 at 10:06 UTC) »
Open source contest 2004 is a very admirable effort to reward Italian Open source developers. The decision to involve also school projects is interesting, it would be great to improve connections and cooperation between the acamedic world and free software. Obviously I subscribed Epiphany :)

We have a plan for Epiphany 1.4. Unfortunately because of post hacked widget problems we have not been able to publish it yet.

I'm trying to make gtkmozembed an interface to GRE. That way I think it will become a much more viable candidate to be used in other desktop apps. Immediate advantages are the ability to use it without ugly wrapper scripts with the mozilla libraries directory hardcoded and to not depend anymore on the whole mozilla browser installation. In the process I found an interesting bug in the SDK. Well the request for blocking 1.7 sounds promising. Thanks bsmedberg ! (I wonder if mozilla guys reads planet gnome).

Mark cleared my confusion on multihead. Next week I should be able to add multi screen support to Epiphany.

Seth posted a patch to add non local uri support to epiphany file pickers. Unfortunately mozilla support for gnome-vfs uris is still not complete and we had to delay it post GNOME 2.6.0. For 2.8 I think the way to go is pretty clear: complete mozilla gnome-vfs support and allow non local uri for almost all file pickers. On the short time (2.6.x) I'm not sure what's the best solution though. Mozilla 1.7 can already open all gnome-vfs protocols but not save them. The most conservative approach would be to enable local uri for open mode file pickers only if compiled with Mozilla 1.7. Otherwise we could make sure the operation doesnt fail silently when saving/opening a not supported protocol and show a warning to the user. Is the ability to save to webdav and sftp worth the confusion of showing smb mounts in the filepicker and then failing to save in them ?

I love the new bugzilla. Thanks to everyone that worked on it :)

16 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!