Stuff Michael Meeks is doing
|
|
This is my (in)activity log. You might like to visit
Collabora
Productivity a subsidiary of Collabora focusing on LibreOffice support and
services for whom I work.
Also if you have the time to read this sort of stuff you could enlighten
yourself by going to Unraveling Wittgenstein's net or if
you are feeling objectionable perhaps here.
Failing that, there are all manner of interesting things to read on
the LibreOffice Planet news
feed.
Older items:
2023: (
J
F
M
A
M
J
),
2022: (
J
F
M
A
M
J
J
A
S
O
N
D
),
2021,
2019,
2018,
2017,
2016,
2015,
2014,
2013,
2012,
2011,
2010,
2009,
2009,
2008,
2007,
2006,
2005,
2004,
2003,
2002,
2001,
2000,
1999,
legacy html
- Dropped H. to school, poked mail. Interested by the discussions
around ABI compatibility in gtk+, and a hypothetical gtk 3. While there is
much that I think is good in Imendio's vision - pwrt. more aggressive
deprecation of bad ideas (such as exposing struct members), and describing
the API with an IDL (roll on the day that D-BUS developers do this),
I'm concerned. Clearly I have a desktop focus, perhaps that is my problem,
but some points for thought:
- 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.
In conclusion (and I'm not a gtk+ hacker, so please be patient) -
there are no-doubt lots of exciting cleanups that can be done, to make
the code look more beautiful and flexible: but there are huge dangers
lurking here. I'd love (as an API user) to hear some compelling specifics
around the main areas of breakage presented. Of course all the good
ideas around deprecating struct accesses & providing accessors for
everything is a great direction independant of the worries. Ultimately,
one day we'll have to evolve the ABI in some way - lets hope that is
well after the knock-on changes from toolkit deprecations necessary to make
that work have pushed their way across all applications.
- Back to E-mail, got SLED10 booting again & switched back
to that. Plagued by
svn: This client is too old to work with working
copy '.'; please get a newer Subversion client everywhere; if only
there were some 'downgrade' feature.
- Somehow annoyingly missed out on a demo with Brady & co,
but eventually managed to get my icecore & deskice working together:
nice.
My content in this blog and associated images / data under
images/ and data/ directories are (usually)
created by me and (unless obviously labelled otherwise) are licensed under
the public domain, and/or if that doesn't float your boat a CC0
license. I encourage linking back (of course) to help people decide for
themselves, in context, in the battle for ideas, and I love fixes /
improvements / corrections by private mail.
In case it's not painfully obvious: the reflections reflected here are my
own; mine, all mine ! and don't reflect the views of Collabora, SUSE,
Novell, The Document Foundation, Spaghetti Hurlers (International),
or anyone else.
It's also important to realise that I'm not in on the Swedish Conspiracy.
Occasionally people ask for formal photos for conferences
or fun.
Michael Meeks (michael.meeks@collabora.com)
