libomelette [was Re: glib unicode regular expression api]

[Mark McLoughlin <markmc redhat com>]

Hi Anders,

	(One thing - we all know that libegg sucks, and that copying and
pasting code sucks. But there's no obvious alternative that doesn't suck
and that still addresses the original cause for libegg existing. We all
really need to just suck it up and make it work as best we can :-)

On Mon, 2004-07-05 at 09:41, Anders Carlsson wrote:
> m�2004-07-05 klockan 09.56 skrev Mark McLoughlin:
> > Hey,
> > 
> > On Mon, 2004-07-05 at 07:51, Matthias Clasen wrote:
> > 
> > > Speaking about libegg, I wonder about the status and destination of some
> > > modules: background-monitor and recent-files don't have any obvious
> > > destinations, what is their status ? background-monitor seems pretty
> > > uninteresting, but recent-files seems to have found broad use, and
> > > should probably be moved into a platform library (considering that
> > > federico already presented it as "Gnome API" in his fashion show).
> > 
> > 	We need a maintainer for libegg - someone who'll push uninteresting
> > bits out of the module, ensure people are making progress towards
> > getting it included in the destination library etc.
> > 
> 
> We do have maintainers for libegg, they're supposed to be Jonathan and
> me :)

	Ah ... maybe we just need to send you guys on an a course of
ass-hardening treatments :-)

> Anyway, we discussed what to do with libegg at GUADEC. I think it was
> something like this:
> 
> * Things from libegg that have gone into the platform libraries should  
> be removed or moved to another directory.

	Yeah, I've just now removed the screen-exec stuff.

> * Things that are old, broken or that have been rewritten (combo-old for
> example) should be treated in the same way, removed or moved to
> "broken-eggs" or whatever :)

	libomelette ! Has the nice side effect that "omelette" is a pain in the
ass to type which should discourage people from using it or, indeed,
encourage people to fix it :-)

> * As for getting things into the destination library, that's really up
> to the author of the particular code. (But I think that's what you're
> suggesting)

	Well, what I was suggesting was the if the process of getting it into a
destination library stalls and no-one is working on it we should move
even those to libomelette. I'd put recent-files into libomelette right
now - at least it would make it clear that things have stalled ...

> I think we have another issue here as well. What to do about things that
> have no obvious target? The things that come to mind here are the dock
> (which is more of an IDE kind of dock than BonoboDock) and the column
> chooser. We could say that anything that doesn't have a target platform
> library shouldn't be put into libegg, but on the other hand we do have
> some things that are actually used in a few places but without a good
> target.

	I think one important thing is that development shouldn't stall on the
"there's no obvious target library" problem. If the API sounds like it
makes sense *somewhere* in the platform, it'd be really nice if it could
be developed with the maintainer of a *potential* target keeping an eye
on things and offering feedback. The process only needs to stall on the
"no obvious target" problem when the API is actually completely
finished.

	e.g. it would have been nice if recent-files development had continued
with (perhaps) Owen or Matthias reviewing the API and implementation
without actually needing to make a commitment that it makes sense in
glib.

> Mark, feel free to flame me if I'm sending this to the wrong list... ;)

	If this isn't on topic I don't know what is :-)

Cheers,
Mark.