Re: very rough pre-gep tentative new modules list

[Luis Villa <louie ximian com>]

On Tue, 2002-09-17 at 08:38, Michael Meeks wrote:
> Hi Luis,
> 
> 	So; if I get the terminology right - we're adding these apps to the
> point where we get to support them as much as nautilus yes ? - or at
> least group them together with things like the control-center, panel,
> nautilus ?

Yes, that's roughly the plan. Note, though, that this is not a list
fixed in stone forever- we can, for example, remove an app (say,
file-roller) if a better solution provides itself in the 2.4 timeframe. 

> 	If so this concerns me quite a bit, if not the following comments are
> invalid :-)
> 
> On Fri, 2002-09-13 at 19:56, Luis Villa wrote:
> > *file roller: as many of you know, gnome-vfs and nautilus do not
> > necessarily handle tarballs and other compressed/zipped objects well.
> > File Roller (fileroller.sf.net) is a wonderful application for this
> > purpose that we hope will help bridge the gap in this area.
> 
> 	IMHO - since the long term plan has to be to fix this in gnome-vfs, in
> an integrated and seamless fashion - it would seem a retrograde step to
> have this in the 'desktop'. We should use inclusion to try and get
> people to hack on non-fragmentary solutions IMHO; regardless of their
> efficacy.

I talked about this with Seth at some length; it's his feeling (and I
agree with him) that this is an absurdly frequently requested feature,
and including it would make the desktop substantially more functional
and useful for users. Yes, it's not the 'ideal' solution, but no one is
working on gnome-vfs to solve this problem the Right Way. If you're
volunteering, or if someone else is, great, we'll yank file-roller. But
in the mean time we've got a very good solution (which everyone
acknowledges is not the Right Way) so we should use it.

> > *galeon:
> 
> 	great.

No thoughts on the mozilla dependency here? :) 

> > *rhythmbox:
> 
> 	Sounds ok; as you say we'd need gstreamer - and I'd like to have some
> hackers go over the code first; pwrt. portability, ANSI C, etc. 

Completely reasonable.

> Also, its never 'just' gstreamer; since the gstreamer core is
>  sufficiently abstract to be unable to play media by itself - we'd need
>  to work out a set of suitable stable and robust plugins that we could
>  ship as well; Quite a large task - clearly the gst guys would need to
>  tell us what they thought they could support.

wrt plugins, note that we 'only' ship tarballs ourselves, so (as I
understand the gst plugins) we're just shipping one monolithic tarball,
and specifying a minimal set of plugins that must be built for RB to
work.

> > *totem: again, this is an app rapidly reaching maturity that still needs
> 
> 	Again; if we go the GStreamer route - I'd prefer to have people hacking
> on that rather than Xine :-) then again totem works now, and scales
> properly :-) so.
> 
> 	The thing is that just pushing something into 'the desktop' and then
> popping it out again 'when GStreamer is ready' is a _massive_ time sink.
> If we spend many man years making Xine portable, accessible,
> internationalised, bug free etc. only to 'replace it' with GStreamer -
> there are going to be a lot of people breathing fire inside companies
> for whom a complete and polished product is more important than
> something that works for a few people once.

Reasonable, though (and I should be corrected if wrong) there are no
i18n or a11y issues with xine, and we already know it's extensively
portable.[1] So while in the general case I agree strongly with all of
these points I don't think any of them are actually an issue with xine,
except bugginess- and I think that's something to be assessed
differently. If it's buggy, we shouldn't sink time into it- we just punt
it. 

[1]According to their site, it is known to work on four Linux-based
platforms, one BSD, both Solaris options [sparc+intel] and Irix, though
I'm doubting that is with non-gcc compilers.

> > *gnopernicus and gok: we believe strongly that we should continue the
> > push to become a fully Accessible desktop by including the gnome
> > accessibility tools
> 
> 	My feeling is that gnopernicus has requirements (via gnome-mag) on
> unstable gtk+,

Many key apps will have requirements on unstable via the multihead
stuff. It's presumed that gkt 2.2 will be released in time. If not,
we're fucked in a whole number of ways, not just wrt gnopernicus.

>  and that the general code quality, and worse robustness
> is such that it shouldn't go into the 'desktop' as yet. 'gok' is
> considerably better in those respects.

Reasonable objections. I'd (personally) like to drive it in the 'right'
direction a bit, but if it is your feeling that it is extremely
unreasonable to expect it to be ready wrt code quality and robustness,
we can remove it.

> > we expect at least one and possibly several of these apps won't be
> > ready in time for 2.2. But because it is easy to cut them loose so
> > that they can focus on 2.4, we don't think
> 
> 	Well; 2.2 is still a while away - and I think it's right - we need to
> state clearly and decisively what we expect of a given project to be
> included in the long term.

Well, I was trying to do that some weeks ago; it got derailed with talk
of a gep, whose purpose I still don't understand, and which it curently
appears will not be written until after I leave for Africa tomorrow.

At any rate, once that gep is written, I certainly expect that all new
apps will follow those guidlines. These apps were picked at least
partially wrt their odds of meeting those guidelines.

Luis