Re: libomelette [was Re: glib unicode regular expression api]

[Anders Carlsson <andersca gnome org>]

m�2004-07-05 klockan 16.01 skrev Mark McLoughlin:
> 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 :-)
> 

Yeah, let's just make the best we can of the situation.

> 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 :-)
> 

I guess :)

> > 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.
> 

Good, I saw that Matthias Clasen added README files to all modules that
have been moved. Matthias, do you think it'd help to remove these
direcories altogether? 

> > * 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 :-)
> 

Actually, I was thinking about things that no-one uses here. Basically
I'd like libegg to be a place for:

* Things that we have a clear idea of where they should go (regex for
example)

* Things that we don't know where they should go/not general enough for
a library, but still used by applications (eggrecent comes to mind
here).

> * 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 libomelette should be the target for unmaintained, specialized,
unused things. And it shouldn't really be libomelette but either cvs
rm'ed from libegg, or put into a separate sub-directory.

> > 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.
> 

I'm not sure if having Owen or Matthias reviewing the API without
knowing at all if it'll go into gtk+/glib is a good idea. Sure, we'll
maybe end up with a nicely designed API, but we'll still have the
problem with where to put it.

The problem with putting it into gtk+/glib is that it'll work on Unix
only. IIRC, for example Windows has another specification for recent
files which means we'd have to get someone to review that, make sure
that the EggRecent API has the least common denominator, etc. (Which
isn't a bad thing of course, but it does add extra work). Gtk+ is
designed to be (more or less) cross-platform, gnome isn't really.

When Jonathan and I were reviewing the library dependency situation, we
came up with a bunch of functions/widgets that would depend on both
gnome-vfs and gtk+. EggRecent is a good example of this. We talked
briefly about a libgnomevfsui library (but that's a totally different
discussion :)

Anders