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

[Brian F. <bdf...@un...>]

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.

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

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

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.

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
> >=20
> > 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?
>=20
> 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!
>=20
> > > -A handy way of displaying active transfers as sub-entries in the bud=
dy
> > > list (see http://www4.ncsu.edu/~bdferris/Gaim.jpg for an example ).
> >=20
> > 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.
>=20
> 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.
>=20
> > > 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 thi=
ng
> > > 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
> >=20
> > 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.
>=20
> 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.
>=20
> Christian
>=20
> --=20
> Christian Hammond         <>  The GNUpdate Project
> ch...@gn...      <>  http://www.gnupdate.org/
>    My software never contains bugs. It just develops random features.
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: DEDICATED SERVERS only $89!
> Linux or FreeBSD, FREE setup, FAST network. Get your own server=20
> today at http://www.ServePath.com/indexfm.htm
> _______________________________________________
> Gaim-devel mailing list
> Gai...@li...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel
--=20
Privacy never seems all that important till it's gone.
For the initiated:  PGP KeyID 0xF8EA3348
For the interested: http://www.gnupg.org/