Stuff Michael Meeks is doing

• Size - the deprecated pieces in gtk+ have little-to-no real performance cost on the desktop - particularly compared to the other (slowly fading) deprecated libraries higher up the stack. Presumably for Mobile devices, a tweaked build that removes deprecated functionality is possible.
• Application realities - tookits (no matter how beautiful) need applications. Unfortunately, applications have a fairly slow uptake of new toolkit features for several reasons:
  • Ignorance - often app authors just don't know about the latest, coolest new toolkit feature.
  • Feature gaps - eg. E-Table vs. GtkTreeView performance is apparently -still- an issue (years on).
  • Compatibility - maintaining updated applications (security fixes, critical features etc.) can be done -far- more effectively for 'Enterprise' platforms, when there are no strong dependencies on new technologies in newer versions. This saved energy makes the 'cutting edge' sharper too cf. problems with Firefox, Evolution, OO.o.
  • Time - changing a toolkit to beautify it is a small cost. Changing all the users of that toolkit to match is a huge cost. Applications often have far more code, spread over fewer developers - since code sharing happens more readily lower in the stack. It took until ~last year to finally distribute the last Gnome 1.x app: gnucash.
• Duplication cost - a huge problem with Gnome 2.x with the uncertainty around it, the need to ship product on the old platform & so on was feature duplication. We saw the birth of multiple redundant technologies: CamelObject vs. GObject, E-Table vs. GtkTreeView eg. and these decisions still bite us (albeit quite gently) years later. What features will be vital in gtk 3.x ? they will also be need for 2.x apps.
• A clear rational - the only clear rational I can see for ABI breakage, is compelling proof that critical features cannot reasonably be implemented inside gtk+. That may well be the case already; certainly I can believe that some esthetic contortions may be required to accomodate some. I'd love to see some really clear examples of where our currently exposed ABI is making things impossible going forward.

• The LGPLv3 is a fine license; as I said five months ago; Novell welcomes & supports the GPLv3 and intends to include code licensed under it in our distribution. Of course, ooo-build will be switching to this too (as soon as Sun manages to get the huge license-header-change CWS nominated & we include that build).
• I'm pleased the Lesser GPLv3 was retained, the LGPL allows ISVs to write proprietary plugins & components, and re-use OO.o via it's sexy UNO component technology in ways that that are also possible with MS Office: with which we obviously compete for mind-share & developers - that is good for the project.
• On the other hand, by sticking with the SCA, Sun appears to only be accepting half of the license itself. When will Sun be willing to accept code under the terms of the LGPLv3 into OpenOffice.org ? then again there is a glimmer of hope on this front too (for 'non-core' code):
• There are some titillating hints that this sorry situation might improve (which if so is clearly to be applauded) in the OpenOffice SCA variant, in section 7. we hear of Exempted contribution guidelines. I look forward to reading them: will they contain satisfying change & real movement towards the strong, transparent and fair community process that Jim promised ? a bland re-statement of the status-quo would be extremely disappointing.
• Finally, from the announcement: "The new license is a major reason to exchange the Joint Copyright Assignment(JCA) with the Sun Contributor Agreement (SCA)." - where is the major reason ? apparently a number of steps in the 'major' reasoning were omitted for brevity - can someone expand ? Why does the LGPLv3 mean people have to assign stronger rights to Sun ? (or is the SCA friendlier ? the most critical piece referenced in the agreement appears to be missing in action).

typedef struct { char *name, *id, *url; } TeamSpace;
...
    GPtrArray *spaces;
    dbind_context_method_call (ctx, NULL, DESKICE_PATH, DESKICE_NAMESPACE,
                               "GetTeamList", &error,
                               "=>a(sss)", &spaces);
    for (i = 0; i < spaces->len; i++) {
        TeamSpace *space = spaces->pdata[i];
        fprintf (stderr, "\t%d: %s, %s, %s\n", i, space->name, space->id, space->url);
    }