Re: [Gaim-devel] Yet Another Oscar File Transfer Patch

[Luke S. <lsc...@gm...>]

On Tue, Oct 01, 2002 at 08:44:54AM -0400, Brian Ferris wrote:
> On the issue of threading, moving data handler out from its own thread
> and back into the g_main_loop io handler is a relatively easy task for
> my patch, as this is how I originally had it working.  However, file
> transfer tended to dominate the loop in that case, thus non-blocking
> sockets.

non-blocking sockets are most certainly needed for gaim in general.

> 
> As for the UI concerns, I would say this.  First, the only two pieces of
> information I care about in a given transfer is the percent complete and
> how much longer I have to go.  I keep my buddy list pretty narrow and in
> those cases, that's all I see (the file name is truncated, perhaps
> right-justifying that field would indicate enough of the unique file
> name on long paths to still be useful).  If I want to know more about
> the transfer, I do a mouse-over on the transfer entry, which brings up a
> tooltip with more extensive info (I couldn't figure out how to screen
> cap a tooltip to show this).

tooltips are a pain.

> 
> Secondly, though my buddy list is already pretty long, I can see how it
> would be nice to have transfer info in a dialog as well.  Mark Doliner
> suggested that a dialog similar to the one used by Galeon (he sent me
> this as an example:  http://www4.ncsu.edu/~bdferris/Thing.jpg ).  I

this looks good.

> think this could whipped up pretty quickly using the current code I have
> written, so I will attempt to do so.  I'd still like to leave the option
> of the nested UI elements, since I'm a big fan of not-so-many-dialogs.

that's fine, but make the separate dialog the default. 

> 
> Thirdly, it sounds like major changes are being made to the buddy list
> UI model.  In light of ever-growing buddy lists, how hard would it be to
> implement sorted buddy lists?  Aka, all active buddies float to the top
> of the list while my buddy who has been idle for three days is hidden at
> the bottom.  Just a thought.

the buddy list is being entirely redone. sorting members on the current model is
possible, but not worth the effort at this point. as things progress, sorting will be
added in as well.
luke

> 
> Brian Ferris
> 
> On Tue, 2002-10-01 at 02:01, Christian Hammond wrote:
> > On Tue, Oct 01, 2002 at 01:52:02AM -0400, William T. Mahan wrote:
> > > On Mon, Sep 30, 2002 at 11:47:15PM -0400, Brian Ferris wrote:
> > > > -Threaded for your pleasure
> > > 
> > > Mine isn't threaded, mainly because I didn't see any other threading
> > > in the Gaim code.  Is anyone strongly for or against using threads?
> > 
> > Threading presents all kinds of fun little problems, especially with
> > debugging. What we would prefer is a setup for non-blocking sockets.
> > This is not easy, though, which is why we're giving the job to Ethan
> > Blanton!
> > 
> > > > -A handy way of displaying active transfers as sub-entries in the buddy
> > > > list (see http://www4.ncsu.edu/~bdferris/Gaim.jpg for an example ).
> > > 
> > > This looks nice--Brian's patch obviously has a more advanced GUI than
> > > mine right now.  I don't have a progress bar, ETA, etc., although I
> > > think Rob Flynn said he had some ideas about a generic file transfer
> > > interface.
> > 
> > Though this interface does indeed look nice, it requires a wide buddy
> > list, which most people do not prefer. It may be better in the long
> > run to just have a file transfer dialog, though it'd be nice if this
> > was made an option (if it wasn't too much work, that is). I think if
> > we had a different model for the buddy list (internal and API), it
> > could be worked in a bit better, but I don't want to go into detail
> > about that.
> > 
> > > > This patch is different from the one under development by "wmahan".
> > > > Instead of fixing the code in ft.c, I went from scratch. The only thing
> > > > this patch offers in the way of innovation (oft is oft is oft) is the
> > > > nested transfer UI element.  As far as I can tell, I kept the UI
> > > > code
> > > 
> > > Yes, it looks like our approaches our fairly different.  But I've
> > > already talked to Brian about possible future collaboration, in the
> > > hope that Gaim will benefit regardless of which patch is ultimately
> > > accepted.
> > 
> > It's good that you two are discussing this together. I don't know what
> > Sean and Rob's stance on the incorporation of file transfer patches
> > is, but I would imagine it would help if there were people working
> > with you on developing file transfer support for other protocols.
> > 
> > Christian
> > 
> > -- 
> > Christian Hammond         <>  The GNUpdate Project
> > ch...@gn...      <>  http://www.gnupdate.org/
> >    My software never contains bugs. It just develops random features.
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by: DEDICATED SERVERS only $89!
> > Linux or FreeBSD, FREE setup, FAST network. Get your own server 
> > today at http://www.ServePath.com/indexfm.htm
> > _______________________________________________
> > Gaim-devel mailing list
> > Gai...@li...
> > https://lists.sourceforge.net/lists/listinfo/gaim-devel
> -- 
> Privacy never seems all that important till it's gone.
> For the initiated:  PGP KeyID 0xF8EA3348
> For the interested: http://www.gnupg.org/



-- 
-This email is made of 100% recycled electrons.