Re: Proposed Modules, My Take

[Ryan McDougall <NQG24419 nifty com>]

My 2 cents. 

Since I agreed with most of all that Bryan said, I thought I'd use his
reply as a template and just point where I disagree.

Comments intertwined below.

On Wed, 2005-19-01 at 12:29 -0500, Bryan Clark wrote:
> 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.

Abstain, not enough info.
> 
> >  * 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.

Abstain.
> 
> >  * 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) ;-)

Is S-J 0.5 good enough for inclusion as a stand alone ripper until the
UI gets stabilized?

> >  * 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-user-share looks great, and I'd lose NO sleep if it went in, but
I'm not yet convinced that g-u-s is the best that we as a community can
do. Maybe by 2.12 we'll have changed our minds, or Alex will have a
better argument? I think we can afford to wait for the best, so long as
Alex wants to pursue g-u-s for 2.12. I only hope that this doesn't
become one of those perpetually punted things. :(

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

Abstain.
> 
> 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
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list