Re: Proposed Modules, My Take

[Bryan Clark <bclark redhat com>]

Hey ~

Here's my take on these things.  Late? maybe.  Better than never? maybe.
In your inbox? yes.

On Sun, 2005-01-16 at 11:57 +1100, Jeff Waugh wrote:
>  * gnome-schedule
>  * gnome_war_pad

Agreed, I'd say no.

>  * polypaudio

Agree with Havoc's comments on this.

>  * libgnomesu

Following Mark's comments and concerns I'd agree to say no to this.

>  * gwget

I'd say no, while I do want to improve the downloading system from
Epiphany I don't think this application has the right approach.
Wrapping a command line tool is taking an 'existing infrastructure"
approach instead of a user perspective for where file should live.

>  * gnome-doc-utils - include!

Dunno, but there seems to be consensus to add it from my view.

>  * pygtk

Doesn't seem necessary to me, I'd really like to see some pygtk
applications proposed for inclusion though.

>  * totem - include!

Yes / Agree.

>  * galago, libnotify, notification-daemon

No / Agree.  I've sent mail [1] about why I think the latter are not
good ideas.  This approach is from a framework angle instead of working
to define how our notifications will work and look from the user
perspective.  The user side of this needs to be done before we create a
library that locks our notification system into something.  The
specification defines how notifications behave in stacking and other
terms which doesn't actually allow us to design a notification system we
think is the best, but to fill in the spaces left by the spec to try and
make it "usable". [2] I'd like to work to define how we want
notifications to behave and then maybe create a spec from that.

>  * nautilus-sendto

Agree, after regular releases and testing this should be integrated with
gnome-user-share for the send/receive file model that was what the
consensus seemed to reach.

>  * goobox

I'm aligned with Havoc on parts of this.  I saw more of a consensus to
include s-j, however I think s-j needs to integrate into the desktop
more before we do that.  Integration means we define a way to link our
default music player with where s-j puts the songs it rips and have a
way of launching it from our music player.  Honestly I'd most like to
see our cd playing done from something like rhythmbox and have s-j
improve the way you rip tracks.  It could improve the way your rip
tracks by starting the ripping process immediately after s-j starts and
then having the gathering and editing of the CD track names and such
happen as s-j is ripping music.  Yes I know s-j would might have to the
back fill in the information to mp3s/oggs already written but what's
more important, the file/save model that computers work in or our
helping people work faster and more effective? (psst, it's the second
one) ;-)

>  * gnome-backgrounds - include!

Doesn't seem to controversial and I'm speaking out of my ass since I
haven't tried this one yet, but my only request would be that they limit
the number of backgrounds to a small number like 7 or so.

>  * gnome-menus - include!

No brainer, yes.

>  * gnome-user-share

I still don't really understand the controversial apache thing but I
just use the system I don't really watch to make sure it uses only
"desktop" applications and not "server" applications. ;-)  The end user
effect of this app seems like exactly what we want while the apache code
is tested, secure, and heavily maintained by someone else; maybe it's
just me. The system should get integration from the nautilus-send-to
side so perhaps we should wait to include both next time?

>  * gnome-keyring-manager

I saw Fer and others put some more work into this again and I'd like to
see something like this get in, but I think this piece isn't the first
one I want included.  I see keys as being handled exactly the same way
MIME handlers are, at each time you access the key you have the option
to edit it.  Instead of this large overwhelming key editor we should
have simple a single key editor.  I feel bad about this one, but I'd
still say no.

Cheers,
~ Bryan

[1] http://lists.freedesktop.org/pipermail/xdg/2004-September/004881.html
[2] See Seth's blog post on Design not Usability 
	http://www.gnome.org/~seth/blog/allworknoplay