API/ABI
We have maintained API and ABI backward compatibility throughout the 2.x series.
Planned library/module removals (deprecated during the 2.x series):
- audiofile
- esound
- libart_lgpl
- libbonoboui
- libgnome
- libgnomecanvas
- libgnomeui
Things we should (dramatically?) revise:
DanielBrodie: Wasn't there also some discussion about getting a generic iostream style API into glib and then getting gnome-vfs to use it. There were more people interested in using it then just the gnome-vfs guys (like for ole in gnumeric and other uses)
pkgconfig - remove "lib" from all .pc filenames
# pkg-config --list-all | sort
This command will show a list of libraries that are available; to make applciations development (especially dependency management) easier for developers we should either call all the .pc files libfoo.pc (or libfoo-3.0.pc) or all .pc files foo.pc (or foo-3.0.pc), I prefer the last one because it should be clear that we're taling about libraries here. At the moment there are lots of ugly passages like PKG_CHECK_MODULES(CRIAWIPS, [gtk-2.0 libgnomecanvas-2.0]) in the applications' configure.in files.
The Extended C API
RyanMcDougall: Breaking API compatablity is an excellent time to ensure the longevity of the developer community by totally rethinking what we present to new developers. Something consistent, easy to follow, and simple, will attract more new blood, and keep Gnome vibrant. But we need to look beyond just the "core, stable" APIs, and look closely at what people need to use just to write Gnome apps.
1. Savagely remove all deprecated APIs, consolidate functionality spread all over (ie libegg, libgnomeui, ...), basically get rid of cruft
2. Reexamine the API for consistency, and refactor for cleanliness and simplicity. Havoc wrote on this here.
3. Rethink the design assumptions in hindsight with an eye to making things simpler. Ask "can we hide this stuff from the programmer if we just change the assumptions or abstractions?"
Common API description for Language bindings
FedericoMenaQuintero: introspection for GObject is in progress. See the "gobject-introspection" module on CVS. Also, see gnomebug:139486.
Manuel Corrales: i dont want to get flame for this please, but i think the platform or framework should be more consistent. Is too spread all over in several libraries. I think th way to go is something like Qt framework wich is divided into modules like QtGui( graphical interfaces), QtCore (implementation of QString usable on the user interfaces of QtGui, implementation of several data structures like lists, maps, etc..), QtSql (connection to any database with a driver), QtGL (openGl support), etc. All this modules should be very well integrated.