GtkFileChooser

We need to make a public GtkPlacesBar that both Nautilus and the file chooser can share for the shortcuts pane. This will clean up the file chooser a lot, as the shortcuts code is interleaved with the rest of the code, and it's pretty messy by itself. Do we need a GtkPlacesModel that GtkFileChooserButton can use for its combo box, and for other things to share as well?

We should drop the file system backends entirely and code against GIO directly. This would give us more flexibility in the long run. The GtkFileSystem API sucks, anyway. We could then drop the reliance of libgnomeui, and also the Win32 file system would not need to be kept in sync with the Unix stuff.

Lockdown. Sayamindu implemented lockdown for the file chooser in the form of an "allowed directories" list. This way you can hide most of the file system from users. (As a side note, the mechanism is shared with Nautilus, whose corresponding patch also needs to be integrated.)

Extended layout

What's the status of this? What's blocking the merge into the mainline?

This could simplify the (ugly) sizing situation in the file chooser and in many apps that have to jump through hoops to get a decent geometries.

Exercise: remove all the custom sizing code in the file chooser, and see if it Just Works(tm) with the extended layout branch.

Improve the locality of libgtk.so

Reducing the the size of readonly/shared data is pretty hard, *but* we could try to reduce the .rodata working set and have better locality to avoid disk seeks.

The first thing your program does is instantiate a GtkWindow. This causes:

• gtk_window_get_type() gets paged in from the .text section.

• The "GtkWindow" string gets paged in from the .rodata section ...

• ... which is intermingled with a bunch of strings that came from gtkwindow.c --- property names, blurbs, etc.

• All of GtkWindow's superclasses get paged in...

• ... plus their corresponding strings, which are scattered all over libgtk-x11.so's huge .rodata section.
• Etc.

Code reordering... resurrect this project? Widgets chain up to their parent handlers all the time, and yet all the vmethod implementations are spread far apart in the library (e.g. realize a container and all of its subwidgets get realized - this touches a bunch of code pages).

Michael Meeks's iogrind could help to actually measure this stuff.