Re: My (ongoing) analysis of the proposed modules

[Luis Villa <louie ximian com>]

On Fri, 2003-05-09 at 16:25, Jeff Waugh wrote:
>   http://www.gnome.org/~jdub/screeds/twofourmodules.html

I'm going to paste bits of this inline and add my own /personal/
thoughts and comments, after having read all the mail from while I was
away. I'd love to get a more formal version up as an update to both GEPs
in the next 24-48 hours, but I'm not sure of how to best go about that
[see some of my reservations in 'How this all works...' for why.]

Note that I'm also mostly skipping over Jeff's analysis of GEP 10, since
it basically covers (well) all the bases that I can see, except for the
'who decides' bit, which he doesn't touch on, though I know he's given
it some thought.

|Analysis
|The headers are colour-coded. Green means it should go in, red means
|it shouldn't, blue means I'm undecided, and black means I haven't |done
that bit yet. ;-)

Jeff, this is horrible UI, given that they are all dark colors, and just
fonts. Actual text and/or maybe dancing stars, xmms.org style, are
called for. ;) 

|battfink
[On inclusion, I'm ambivalent, leaning towards no.]

|Pro
|battfink is designed to replace battstat (our current battery |applet),
and is intended to provide a focus for energy saving |systems in GNOME.
It's somewhat minimal in this respect for the |moment, choosing to solve
the lowest common denominator problems |first. This is a worthy target
for applet to notification icon |conversion.

I guess my main issue here is that these seem to be fairly weak pros for
throwing away a tested (if imperfect) codebase. battstat has some
issues, like mediocre ACPI support. It seems we're potentially throwing
that out in favor of... poor/unknown ACPI support, in favor of...
slightly simpler UI, and Yet Another Capplet, copying functionality from
the xscreensaver capplet 99% of us already have.

So, basically, the 'have a notion of power management beyond the battery
applet' is a good idea, but it seems like we need much more testing and
integration of this code base before we consider throwing out something
that works, presenting us both with new testing issues and upgrade
problems (as jeff mentions in his worms.) [Aside: maybe GEP 10 needs to
explicitly say 'things replacing old, tested apps should face a higher
standard of scrutiny'?]

|epiphany & galeon
[yes, epiphany should go in]

I'm going to tackle this one while Jeff ponders. :) 

I personally feel strongly, as I've said in my previous email (see:
'browsers...') that we need a browser.Given that we (1) don't have one
now and (2) have two quite good, if not completely perfect options, I do
not see the costs of adding one now, especially if we work to make sure
that the choosing of another browser (like mozilla, for a11y reasons)
works well. [On May 6th and May 8th, Havoc and Alex explained the 'do it
now' part better than I can on d-d-l, FWIW.]

So, having convinced myself that choosing either galeon or epiphany is
good to have for 2.4, I've got to pick one. :)

I personally have to go with epiphany, for basically the reasons others
(havoc, etc.) have highlighted: More than anything else, it's clear
marco really badly wants to work with the a11y and UI teams to bring us
the best, most gnome-like browser we can have, and that means choosing
epiphany will get us the best browser, fastest.

To put it much more succintly:
Pro: feature parity, browser is 'expected' part of OS, browser is
imperfect but will improve much faster if we deploy it now, epiphany is
publicly and enthusiastically dedicated to the GNOME direction

Con: It is hard to choose another browser currently. Of course, it is
also currently hard to choose a browser, including a11y browsers. So,
basically, the desktop we currently ships is unusable for a11y users who
want to surf the web. Shipping epiphany will not change that. We /can/
fix the choice issue, though.

|fontilus, themus
[doesn't matter :)

Not really sure we need to discuss these at all, since cc is probably
going to eat them regardless :) 

| gcalctool
[yes]

Latest releases look really sweet, we should go with it. Of course, I'll
love Rich forever if he implements RPN. <running away now>

| gedit-plugins & gtksourceview

I think the discussion in the rest of this thread answers these issues
quite well.

|gnome-mag, gnome-speech, gnopernicus & gok
[yes]

I'd like to see a firm commitment from the a11y team to work on
usability/HIG issues, within the obvious constraints like the
shortcomings in theme colors and instant apply issues. I'm also worried
about the commitment to testing releases- will gnopernicus (just as an
example) do regular tarball releases, or at least work with a volunteer
to help that happen, if we can identify one?

Outside of that, I think this is all upside for everyone involved.

nutshell version:
pro: GNOME demonstrates commitment to a11y, get additional testing,
feedback, and hopefully new volunteers for the a11y team, obviously
better functionality for accessibility-impaired users

cons: don't integrate with rest of desktop very well, may have
difficulty integrating with community release schedules.

| gnomemeeting
[yes]

Jeff covers this very thoroughly, and I agree completely with his
assessment.

|gnome-system-tools
[lean yes, for 2.6]

My gut feeling is that system-tools is a huge, huge change for GNOME,
and as a result we need more a lot more time to digest it. So my gut is
that this should happen, but in 2.6, when the setup-tools will be more
robust and when our control-center and menus can be more actively and
aggressively rearranged with gst in mind.

Pros: 
*Makes integration much better across the board
*provides high-quality, necessary functionality

Cons: 
*depth/breadth of support is unknown, and hard to test
*portability issues unknown/untested
*would require total rethink of menus, control-center
*something totally/new different for GNOME, in a short time frame

|gpdf
[lean yes, but would love to see it done better, from a UI perspective]

<snip jeff's comments>

It seems that the plans for integration into a viewer-type app have bit
the dust. This is a shame, but that's life. 

Pros:
*renders pdfs really well, which we need

Cons: 
*honest question: would keeping it out be a good stick/carrot for
getting a 'real' image browser in 2.6?

|gswitchit & libxklavier

[no, but possibly because of misinformation]

There were some indications in the gswitchit thread that it would not
work on older versions of XFree. If this is correct, I think the idea
must die until it has a fallback for older or non-XFree X's; it would be
a fairly big regression for those users.

|gucharmap

[Should be in.]

All good, AFAICT. Bases covered by Jeff or in the thread.

| nautilus-cd-burner

[I lean slightly pro here.]

I share the concern about the usability of n-c-b- it was totally
non-obvious to me how it was supposed to work the one time I played with
it. 

So the question we have to ask, to me, is:
(1) are we going to get something better (either through n-c-b or some
other program) any time soon?
(2) if we are, will adding n-c-b now make it harder to have something
else later?

As far as I can see, the answer to (2) is no, since the UI is minimal.
But if I'm wrong, we should reconsider.

|seahorse
[haven't played myself, so not really qualified. nautilus integration
sounds very exciting, though. Maybe, just maybe, we should wait for 2.6
and see how this type of actual integration/usability work progresses?]

|totem
[yes, with very, very serious reservations about the xine thing]

Pros: we need a media player; it's a standard component in every OS now.
And totem is a very nice one, that plays nice with GNOME and the UI
team.

Cons: having confusion about what is 'our' media backend is very, very
bad. Either we made a mistake going with gstreamer, and we need to fix
that, or we need to work to make gstreamer more robust. I'd suggest that
xine releases from here until 2.4 use gstreamer by default, so we can
shake out the bugs and know /exactly/ where we stand. To me, knowing
where gstreamer and xine fit in our future for 2.6 and beyond is more
important than having a media player in 2.4, so I'm (effectively) saying
totem+gstreamer needs to be our testbed for that right now.

|zenity
[lean towards yes until we actually have a sysadmin tools thing]

Basically, it'd be a big regression if we nuke this functionality now.
That would be a shame.

Things Jeff ignored/forgot from the GEP thread: [May be more I've
missed, though I've tried to get everything]

|IM

It seems we agree (on the same rationale from gnomemeeting) that we need
IM. It also appears that gaim is not gnome-y enough (though it may be
improved a lot by the time 2.6 rolls around- 0.61 is what I use
personally), and gossip and gtk2 gabber are not ready yet.

I'd personally add that while defaulting to jabber (and even running our
own jabber server at gnome.org) is fine, if we don't make it utterly,
utterly easy to contact AIM users, the utility of adding this to the
core drops drastically.

|themes

GNOME, by default, has to look good; we can't just rely on RH and Ximian
to ship pretty themes. That said, I don't think nuvola is the answer or
even an answer. In my dream world, the theme picker's UI would better
handle more themes and we'd up the number in gnome-themes to 20 or so. I
agree strongly that shipping something called 'extra' in the default
desktop (particularly themes) is just... bizarre.

Anyway, that's my own, personal, two cents. 

So... who gets to collate this into the GEP? :) [I've got it started,
but only the discussion section- I've very deliberately avoided the
'conclusions' section until GEP 10 gets more discussion.]

Luis
P.S. If you've read this far... http://tieguy.org/gep.jpg - Who knew the
French were such big fans?