Re: [Nautilus-list] harder tasks

[Darin Adler <darin bentspoon com>]

on 11/1/01 10:00 PM, Havoc Pennington at hp redhat com wrote:

> Some general harder porting
> tasks I cataloged while digging around in the code:

What an excellent list! Matches my mental one from when I put in the
GNOME2_CONVERSION_COMPLETE darned wall. Of course, then there are all the
problems that don't show up by a simple failure to compile :-)

> - what do we do about smooth fonts and various old GdkFont
>  code

The short term plan is to make the old code limp along as long as that's not
too much work. Once we have it working a bit so we can get other things
going, we port to Pango, simplifying as we go.

Things that we don't try to make work until we switch to Pango: font
preferences, icon text editing.

(Side note: We can get rid of the direct freetype dependency completely if
we switch to Pango and also port librsvg to use Pango too. Ideally, I'd like
to see that happen.)

> - how do we implement ellipsize_string and the ellipsizing
>  label

I'm hoping this is a straightforward coding job, and I'd prefer to only do
it for the real Pango version. Any code that's still using old smooth fonts
or GdkFont can just not ellipsize until it's ported over.

> - do we reapply all Nautilus hacks to 1.2 CList,
>  this time to 2.0 CList, or do we just port EelCList to 2.0
>  in-place, or do we just port all uses of CList to TreeView

Something to keep in mind is that EelList and EelCList are really a single
class right now (sorry for the horrible class names). We originally tried to
do everything in a subclass -- that was EelList. Then EelCList happened when
we just couldn't do it all without a local hacked copy of GtkCList. EelList
itself is a mishmash -- half GtkCList improvements, half Nautilus-specific
things that don't even belong in Eel (like some of the dnd stuff, that
caused other Nautilus-specific dnd stuff to get dragged into Eel).

The port to TreeView is tempting. For now, I am trying to avoid the issue as
much as possible by doing the list view later after the shell and the icon
view and some other components work.

> - there are some apparent bonobo compat issues I don't
>  know anything about

Details? This one I don't recognize.

> - fix the icon cache to not need gdk_pixbuf_set_last_unref_handler

I worry about this one. GObject may not have the right hook. The heart of
the problem is that you get a GdkPixbuf from the icon cache. And you signify
you are done with it by doing an unref. The question is then, how can the
cache know that all users outside the cache are done with a pixbuf without
letting the pixbuf get destroyed?

Maybe there is a way to do this sort of thing with GObject, but I couldn't
spot it with a brief look.

> - port to gnome_program_init

I think I did that tonight. I hope I did it right.

> - finish converting various dialog code to GtkDialog, paying
>  careful attention to the way GnomeDialog and GtkDialog are
>  differently memory managed and GtkDialog doesn't have button
>  indexes

The first step is to port the Eel dialog helper functions to GtkDialog.
Then, the actual dialogs in Nautilus.

> - not really a porting issue, but gtk_window_set_wmclass() should
>  be gtk_window_set_role() pretty much everywhere I noticed it
>  being used, see set_wmclass()/set_role() API docs in 2.0

John Harper put in all of those. Lets just fix them with a global replace,
unless there's something that he knows and I don't.

> - EelCanvasRect uses fields in GnomeCanvasRect that are now private
>  and in GnomeCanvasShape (possibly we can just use GnomeCanvasRect
>  now? it seems to have more features than before)

The only reason EelCanvasRect exists is to optimize redrawing -- it draws
only the areas that change when a rectangle is resized. Sharing the generic
shape code causes you to redraw way too much. For example when a rectangle
gets one pixel wider, you really don't have to redraw the whole thing. The
optimization belongs in libgnomecanvas. Someone familiar with the canvas
should tackle this -- it's not at all Nautilus-specific.

> - the editable icon text code for icons in the icon container has
>  been completely destroyed by Pango (also true of libgnomeui
>  icon list I think)

This is a major hassle. I'm thinking that I'm going to put this one off
until other things are already working, since it's a feature built on top of
other stuff. It's also something that's ripe for a volunteer to tackle,
since it's not really tied in tightly with anything else.

> I was thinking of trying to get a label ellipsizer going, since we
> also want that in PangoLayout eventually. Plus, it looks relatively
> limited in scope, a lot of the other things look scary. ;-)

Sounds good. I'd also love it if you'd tackle the modest requirements of
eel-stock-dialogs.c -- knowledge of GtkDialog a plus.

    -- Darin