Home / Browse / Pidgin / Mail / Archive

Pidgin

Email Archive: pidgin-devel (read-only)

2002:	_Jan	_Feb	_Mar	_Apr	_May	_Jun (27)	_Jul (25)	_Aug (21)	_Sep (136)	_Oct (123)	_Nov (87)	_Dec (110)
2003:	_Jan (87)	_Feb (88)	_Mar (81)	_Apr (255)	_May (73)	_Jun (96)	_Jul (131)	_Aug (94)	_Sep (148)	_Oct (171)	_Nov (166)	_Dec (172)
2004:	_Jan (251)	_Feb (140)	_Mar (213)	_Apr (298)	_May (182)	_Jun (185)	_Jul (159)	_Aug (376)	_Sep (334)	_Oct (256)	_Nov (217)	_Dec (189)
2005:	_Jan (186)	_Feb (151)	_Mar (199)	_Apr (115)	_May (203)	_Jun (228)	_Jul (116)	_Aug (189)	_Sep (136)	_Oct (198)	_Nov (249)	_Dec (339)
2006:	_Jan (167)	_Feb (185)	_Mar (95)	_Apr (133)	_May (86)	_Jun (156)	_Jul (149)	_Aug (170)	_Sep (208)	_Oct (151)	_Nov (270)	_Dec (148)
2007:	_Jan (240)	_Feb (127)	_Mar (150)	_Apr (40)	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec


S	M	T	W	T	F	S
1	2	3	4	5	6	7
	(4)	(3)	(7)	(9)	(1)
8	9	10	11	12	13	14
(5)		(2)				(5)
15	16	17	18	19	20	21
(2)	(1)	(2)	(27)	(23)
22	23	24	25	26	27	28
	(24)	(8)	(8)		(2)	(1)
29	30
(1)	(1)

[Gaim-devel] Yet Another Oscar File Transfer Patch

From: Brian Ferris <bdferris@un...> - 2002-10-01 03:50

Attachments: Message as HTML

Like a lot of people, I've been wanting Oscar File Transfer support in
gaim.  So like fewer people, I did something about it.  Now I'm ready to
toss my patch on the file-xfer pile.

Notable features include:

-Send and receive single files, multiple files, directories, and even
have multiple OFT sessions going for the same buddy
-Threaded for your pleasure
-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 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
completely out of the oscar protocol tree, but I did make some
significant additions to core gaim code.  I'm all for joining forces
with other OFT efforts if need be.

I hope that somebody might find this patch useful.  Note:  I put the
patch up in the "Patches" area.

Thanks,
Brian Ferris
SN: Slackrat2k


Usage Notes:

Currently, saved files are automatically put in
.gaim/Downloads/BuddyName/. Right now this isn't configurable unless you
recompile (annoying, I agree, but I haven't tackled adding new
Preference options yet).

Other things to watch out for... sending directories between Windows and
*nix machines might be a bit tricky since I still refer to '/' as the
directory separator.

Beyond that it seems to work nicely. Hopefully you
will let me know. Build against 0.60cvs.

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

From: William T. Mahan <wtm2@du...> - 2002-10-01 05:52

On Mon, Sep 30, 2002 at 11:47:15PM -0400, Brian Ferris wrote:
> 
> -Send and receive single files, multiple files, directories, and even
> have multiple OFT sessions going for the same buddy

For comparison, the same applies to my patch except for sending
multiple files (I'm working on that).

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

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

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

> completely out of the oscar protocol tree, but I did make some
> significant additions to core gaim code.  I'm all for joining forces
> with other OFT efforts if need be.

I'm always glad to have some friendly competition. :)  I'll try to
take a more detailed look at your code when I get a chance.

-- Wil

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

From: Christian Hammond <chipx86@gn...> - 2002-10-01 06:01

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
chipx86@...      <>  http://www.gnupdate.org/
   My software never contains bugs. It just develops random features.

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

From: Nathan Walp <faceprint@fa...> - 2002-10-01 06:25

Attachments: Message as HTML

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

If we get the start of an interface going, i'll see what I can do about
jabber file transfer.  It doesn't look to be too difficult, but I don't
feel like designing an interface.  Ball is in Rob's court, I guess.

--=20
Nathan Walp             || faceprint@...
GPG Fingerprint:        ||   http://faceprint.com/
5509 6EF3 928B 2363 9B2B  DA17 3E46 2CDC 492D DB7E

[Gaim-devel] Trivial patch: sprintf -> snprintf

From: William T. Mahan <wtm2@du...> - 2002-09-29 20:38

Attachments: sprintf.patch

Hi,

While working with the Oscar prpl I came across a few places that used
sprintf with a fixed-size buffer.  I don't think this is a big deal
because the untrusted data usually passes through the BOS server,
which probably places restrictions on the lengths of screennames and
the like.

However, it doesn't appear that Gaim checks the lengths of incoming
TLVs, and now that direct TCP connections to other clients are
supported, I think it's important to handle any outside data
carefully.  The attached patch changes the sprintf()s to snprintf()s.

Also, if this is not the best place for someone without CVS commit
access to send these sorts of small patches, just let me
know.

-- Wil

Re: [Gaim-devel] Trivial patch: sprintf -> snprintf

From: Luke Schierer <lschiere@gm...> - 2002-09-30 04:19

On Sun, Sep 29, 2002 at 04:38:54PM -0400, William T. Mahan wrote:
> Hi,
> 
> While working with the Oscar prpl I came across a few places that used
> sprintf with a fixed-size buffer.  I don't think this is a big deal
> because the untrusted data usually passes through the BOS server,
> which probably places restrictions on the lengths of screennames and
> the like.
> 
> However, it doesn't appear that Gaim checks the lengths of incoming
> TLVs, and now that direct TCP connections to other clients are
> supported, I think it's important to handle any outside data
> carefully.  The attached patch changes the sprintf()s to snprintf()s.
> 
> Also, if this is not the best place for someone without CVS commit
> access to send these sorts of small patches, just let me
> know.

sending patches here is fine, especially for bug fix patches. posting
them to sourceforge though allows people to test patches that we might
want to wait a while before committing, if, say, other things are
happening to the body of code modified at the time.
luke



-- 
-This email is made of 100% recycled electrons.
-If something can go wrong.... FIX IT!
 If it's Microsoft...delete it.
-There are three ways to get something done:
   (1) Do it yourself.
   (2) Hire someone to do it for you.
   (3) Forbid your kids to do it.

[Gaim-devel] Compiling GAim in Windows

From: Brad <braddabug@co...> - 2002-09-28 21:18

I've tried and tried and tried, but I cannot figure out how to get GAim 
to compile in Windows.

Could someone post some specific, step-by-step, idiot proof 
instructions? Remember, we're Windows users! We're idiots! ./configure, 
make, make install blows our minds!

[Gaim-devel] cvs compile error

From: Patrik Berger <KingPat@gm...> - 2002-09-27 08:56

I have problems compiling gaim cvs!

patrik@...> make
make  all-recursive
make[1]: Wechsel in das Verzeichnis Verzeichnis »/home/patrik/Apps/gaim«
Making all in m4
make[2]: Wechsel in das Verzeichnis Verzeichnis
»/home/patrik/Apps/gaim/m4«
make[2]: Für das Target »all« gibt es nichts zu tun.
make[2]: Verlassen des Verzeichnisses Verzeichnis
»/home/patrik/Apps/gaim/m4«
Making all in sounds
make[2]: Wechsel in das Verzeichnis Verzeichnis
»/home/patrik/Apps/gaim/sounds«
make[2]: Für das Target »all« gibt es nichts zu tun.
make[2]: Verlassen des Verzeichnisses Verzeichnis
»/home/patrik/Apps/gaim/sounds«
Making all in plugins
make[2]: Wechsel in das Verzeichnis Verzeichnis
»/home/patrik/Apps/gaim/plugins«
Making all in docklet
make[3]: Wechsel in das Verzeichnis Verzeichnis
»/home/patrik/Apps/gaim/plugins/docklet«
source='docklet.c' object='docklet.lo' libtool=yes \
depfile='.deps/docklet.Plo' tmpdepfile='.deps/docklet.TPlo' \
depmode=gcc /bin/sh ../../depcomp \
/bin/sh ../../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I.
-I. -I../.. -I../.. -I../../src -DVERSION=\"20020923\"
-DDATADIR=\"/home/patrik/garnome/share\"    -g -O2 -I/usr/local/include
-I/opt/include -I../..  -I/home/patrik/garnome/include/gtk-2.0
-I/home/patrik/garnome/lib/gtk-2.0/include
-I/home/patrik/garnome/include/atk-1.0
-I/home/patrik/garnome/include/pango-1.0 -I/usr/X11R6/include
-I/home/patrik/garnome/include -I/home/patrik/garnome/include/freetype2
-I/home/patrik/garnome/include/glib-2.0
-I/home/patrik/garnome/lib/glib-2.0/include   -DGTK_ENABLE_BROKEN
-I/home/patrik/garnome/include -I/opt/kde3/include/artsc -c -o
docklet.lo `test -f docklet.c || echo './'`docklet.c
In file included from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:32,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/usr/local/include/glib.h:153: warning: `G_STRUCT_OFFSET' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:160: warning: this
is the location of the previous definition
/usr/local/include/glib.h:155: warning: `G_STRUCT_MEMBER_P' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:162: warning: this
is the location of the previous definition
/usr/local/include/glib.h:240: warning: `G_GNUC_PRINTF' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:59: warning: this
is the location of the previous definition
/usr/local/include/glib.h:242: warning: `G_GNUC_SCANF' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:61: warning: this
is the location of the previous definition
/usr/local/include/glib.h:244: warning: `G_GNUC_FORMAT' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:63: warning: this
is the location of the previous definition
/usr/local/include/glib.h:246: warning: `G_GNUC_NORETURN' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:65: warning: this
is the location of the previous definition
/usr/local/include/glib.h:248: warning: `G_GNUC_CONST' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:67: warning: this
is the location of the previous definition
/usr/local/include/glib.h:250: warning: `G_GNUC_UNUSED' redefined
/home/patrik/garnome/include/glib-2.0/glib/gmacros.h:69: warning: this
is the location of the previous definition
In file included from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:32,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/usr/local/include/glib.h:491: warning: redefinition of `gssize'
/home/patrik/garnome/lib/glib-2.0/include/glibconfig.h:59: warning:
`gssize' previously declared here
/usr/local/include/glib.h:492: warning: redefinition of `gsize'
/home/patrik/garnome/lib/glib-2.0/include/glibconfig.h:60: warning:
`gsize' previously declared here
In file included from
/home/patrik/garnome/include/glib-2.0/glib-object.h:29,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-types.h:26,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-font.h:26,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-attributes.h:25,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango.h:25,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:33,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/glib-2.0/gobject/gparamspecs.h:194: parse
error before `gunichar'
/home/patrik/garnome/include/glib-2.0/gobject/gparamspecs.h:194:
warning: no semicolon at end of struct or union
/home/patrik/garnome/include/glib-2.0/gobject/gparamspecs.h:327: parse
error before `gunichar'
In file included from
/home/patrik/garnome/include/glib-2.0/glib-object.h:31,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-types.h:26,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-font.h:26,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-attributes.h:25,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango.h:25,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:33,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/glib-2.0/gobject/gsourceclosure.h:29: parse
error before `*'
In file included from
/home/patrik/garnome/include/glib-2.0/glib-object.h:36,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-types.h:26,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-font.h:26,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango-attributes.h:25,
                 from
/home/patrik/garnome/include/pango-1.0/pango/pango.h:25,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:33,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/glib-2.0/gobject/gvaluearray.h:66: parse
error before `GCompareDataFunc'
In file included from
/home/patrik/garnome/include/pango-1.0/pango/pango.h:25,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:33,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/pango-1.0/pango/pango-attributes.h:212:
parse error before `gunichar'
In file included from
/home/patrik/garnome/include/pango-1.0/pango/pango.h:35,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdktypes.h:33,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkcolor.h:4,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:30,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/pango-1.0/pango/pango-layout.h:96: parse
error before `gunichar'
In file included from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkdrawable.h:7,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:33,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf.h:133: parse
error before `GError'
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf.h:148: parse
error before `GError'
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf.h:159: parse
error before `GError'
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf.h:167: parse
error before `GError'
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf.h:263: parse
error before `GError'
In file included from
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf.h:294,
                 from
/home/patrik/garnome/include/gtk-2.0/gdk/gdkdrawable.h:7,
                 from /home/patrik/garnome/include/gtk-2.0/gdk/gdk.h:33,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:31,
                 from docklet.c:34:
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf-loader.h:69:
parse error before `GError'
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf-loader.h:73:
parse error before `GError'
/home/patrik/garnome/include/gtk-2.0/gdk-pixbuf/gdk-pixbuf-loader.h:77:
parse error before `GError'
In file included from
/home/patrik/garnome/include/atk-1.0/atk/atkeditabletext.h:24,
                 from /home/patrik/garnome/include/atk-1.0/atk/atk.h:27,
                 from
/home/patrik/garnome/include/gtk-2.0/gtk/gtkaccessible.h:23,
                 from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:35,
                 from docklet.c:34:
/home/patrik/garnome/include/atk-1.0/atk/atktext.h:178: parse error
before `gunichar'
/home/patrik/garnome/include/atk-1.0/atk/atktext.h:178: warning: no
semicolon at end of struct or union
/home/patrik/garnome/include/atk-1.0/atk/atktext.h:234: parse error
before `}'
/home/patrik/garnome/include/atk-1.0/atk/atktext.h:249: parse error
before `atk_text_get_character_at_offset'
/home/patrik/garnome/include/atk-1.0/atk/atktext.h:250: warning: data
definition has no type or storage class
In file included from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:64,
                 from docklet.c:34:
/home/patrik/garnome/include/gtk-2.0/gtk/gtkentry.h:111: parse error
before `gunichar'
/home/patrik/garnome/include/gtk-2.0/gtk/gtkentry.h:111: warning: no
semicolon at end of struct or union
/home/patrik/garnome/include/gtk-2.0/gtk/gtkentry.h:114: parse error
before `}'
/home/patrik/garnome/include/gtk-2.0/gtk/gtkentry.h:154: parse error
before `gunichar'
/home/patrik/garnome/include/gtk-2.0/gtk/gtkentry.h:155: parse error
before `gtk_entry_get_invisible_char'
/home/patrik/garnome/include/gtk-2.0/gtk/gtkentry.h:155: warning: data
definition has no type or storage class
In file included from /home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:85,
                 from docklet.c:34:
/home/patrik/garnome/include/gtk-2.0/gtk/gtkimcontextsimple.h:50: parse
error before `gunichar'
/home/patrik/garnome/include/gtk-2.0/gtk/gtkimcontextsimple.h:50:
warning: no semicolon at end of struct or union
/home/patrik/garnome/include/gtk-2.0/gtk/gtkimcontextsimple.h:53: parse
error before `:'
In file included from
/home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:128,
                 from docklet.c:34:
/home/patrik/garnome/include/gtk-2.0/gtk/gtkspinbutton.h:77: field
`entry' has incomplete type
In file included from
/home/patrik/garnome/include/gtk-2.0/gtk/gtktextbuffer.h:33,
                 from
/home/patrik/garnome/include/gtk-2.0/gtk/gtk.h:135,
                 from docklet.c:34:
/home/patrik/garnome/include/gtk-2.0/gtk/gtktextiter.h:106: parse error
before `gtk_text_iter_get_char'
/home/patrik/garnome/include/gtk-2.0/gtk/gtktextiter.h:106: warning:
data definition has no type or storage class
/home/patrik/garnome/include/gtk-2.0/gtk/gtktextiter.h:239: parse error
before `ch'
docklet.c: In function `docklet_update_icon':
docklet.c:194: warning: assignment makes pointer from integer without a
cast
docklet.c:197: warning: assignment makes pointer from integer without a
cast
docklet.c:200: warning: assignment makes pointer from integer without a
cast
docklet.c:204: warning: assignment makes pointer from integer without a
cast
docklet.c:207: warning: assignment makes pointer from integer without a
cast
docklet.c:210: warning: assignment makes pointer from integer without a
cast
docklet.c: At top level:
docklet.c:231: warning: `docklet_update_status' was declared implicitly
`extern' and later `static'
docklet.c:175: warning: previous declaration of `docklet_update_status'
docklet.c:231: warning: type mismatch with previous implicit declaration
docklet.c:175: warning: previous implicit declaration of
`docklet_update_status'
docklet.c:231: warning: `docklet_update_status' was previously
implicitly declared to return `int'
make[3]: *** [docklet.lo] Fehler 1
make[3]: Verlassen des Verzeichnisses Verzeichnis
»/home/patrik/Apps/gaim/plugins/docklet«
make[2]: *** [all-recursive] Fehler 1
make[2]: Verlassen des Verzeichnisses Verzeichnis
»/home/patrik/Apps/gaim/plugins«
make[1]: *** [all-recursive] Fehler 1
make[1]: Verlassen des Verzeichnisses Verzeichnis
»/home/patrik/Apps/gaim«
make: *** [all] Fehler 2
patrik@...> 

Sorry for the long message, but I thought it would be better if i post
the whole log!
What have I done wrong?
-- 
Patrik Berger <KingPat@...>

Re: [Gaim-devel] cvs compile error

From: <lschiere@re...> - 2002-09-27 11:31

/home/patrik/garnome/include/gtk-2.0/gtk/gtktextiter.h:239: parse error
before `ch'

that looks like the only actually erroneous part. looks like your gnome install
has issues.
luke
-- 
-This email is made of 100% recycled electrons.

[Gaim-devel] transparency patch

From: Marcel Birthelmer <marcel@ca...> - 2002-09-25 07:10

Is anyone working on Chip's transparency patch right now? I use it even
though it crashes about 2 or 3 times a day, and I'd gladly provide some
bt's for anyone interested in fixing it.
Thanks,
Marcel B.

Re: [Gaim-devel] transparency patch

From: Christian Hammond <chipx86@gn...> - 2002-09-25 07:17

On Wed, Sep 25, 2002 at 12:09:58AM -0700, Marcel Birthelmer wrote:
> Is anyone working on Chip's transparency patch right now? I use it even
> though it crashes about 2 or 3 times a day, and I'd gladly provide some
> bt's for anyone interested in fixing it.
> Thanks,
> Marcel B.

Nobody is working on it, including me. It's just too unstable, and it
will most likely break with the updates that will be soon made to the
gtkimhtml widget. It was primarily an experiment, as I wanted to learn
how applications provided pseudo-transparency. Unfortunately, it just
did not work right in gtkimhtml.

So far, the backtraces have been useless. I have not been able to
reproduce most of the problems, and unable to fix others. I will,
however, accept patches, so if you fix a problem, feel free to e-mail
me.

Christian

-- 
Christian Hammond         <>  The GNUpdate Project
chipx86@...      <>  http://www.gnupdate.org/
   "Many of life's failures are people who did not realize how close they
   were to success when they gave up."
      -- Thomas A. Edison

[Gaim-devel] docklet patch: update status on first rcvd message

From: <derek_w_ireland@ya...> - 2002-09-25 07:06

Hello,

I have been using the CVS version of gaim (0.60cvs)
with the docklet and noticed that it does not
update to the unread_pending state on the arrival
of only one message.

The code in docklet.c that checks reads
                if (unread_message_queue) {
                        status = unread_pending;
                } else if (awaymessage) {

now, the docklet plugin registers to get
event_im_recv events, which are sent
by function serv_got_im in server.c
*before* the unread_message_queue is updated.

Thats bad.

However after the unread_message_queue is
updated serv_got_im sends an 
event_im_displayed_rcvd.

Thats good.

But the event is not registered by the docklet.

Thats bad.

So, here is what I did to fix it.

RCS file:
/cvsroot/gaim/gaim/plugins/docklet/docklet.c,v
retrieving revision 1.5
diff -u -r1.5 docklet.c
--- docklet.c	16 Sep 2002 08:35:16 -0000	1.5
+++ docklet.c	25 Sep 2002 06:47:26 -0000
@@ -332,6 +332,7 @@
 	gaim_signal_connect(handle, event_connecting,
gaim_connecting, NULL);
 	gaim_signal_connect(handle, event_away, gaim_away,
NULL);
 	gaim_signal_connect(handle, event_im_recv,
gaim_im_recv, NULL);
+	gaim_signal_connect(handle, event_im_displayed_rcvd,
gaim_im_recv, NULL);
 	gaim_signal_connect(handle, event_buddy_signon,
gaim_buddy_signon, NULL);
 	gaim_signal_connect(handle, event_buddy_signoff,
gaim_buddy_signoff, NULL);
 	gaim_signal_connect(handle, event_buddy_away,
gaim_buddy_away, NULL);


I hope its good?

Derek


http://mobile.yahoo.com.au - Yahoo! Messenger for SMS
- Always be connected to your Messenger Friends

[Gaim-devel] Oscar file transfer patch v0.3

From: William T. Mahan <wtm2@du...> - 2002-09-25 03:41

Hi all,

This is just a brief notice that I have uploaded a new version of my
Oscar file transfer patch to the patches area of
http://sf.net/projects/gaim .  This patch provides support for
transferring files using Gaim's Oscar protocol; it uses a generic
user interface designed to avoid introducing any GTK into the protocol
handlers.

This version adds preliminary support for sending files; it is now
possible to transfer a file between two patched Gaim clients.  See the
download page for details.  Please note, however, that this is nowhere
near production quality yet.  I just wanted to inform anyone who may
be willing to give feedback.

Also, if anyone is planning major changes to the Oscar protocol
handler in the near future, I would be interested in knowing about it,
so that I don't waste effort on code that will be useless later.
Thanks.

-- Wil

Re: [Gaim-devel] Oscar file transfer patch v0.3

From: Luke Schierer <lschiere@gm...> - 2002-09-25 03:48

On Tue, Sep 24, 2002 at 11:41:22PM -0400, William T. Mahan wrote:
> Hi all,
> 
> This is just a brief notice that I have uploaded a new version of my
> Oscar file transfer patch to the patches area of
> http://sf.net/projects/gaim .  This patch provides support for
> transferring files using Gaim's Oscar protocol; it uses a generic
> user interface designed to avoid introducing any GTK into the protocol
> handlers.

this is good :-)

> 
> This version adds preliminary support for sending files; it is now
> possible to transfer a file between two patched Gaim clients.  See the

how does it work for between gaim and winaim?

> download page for details.  Please note, however, that this is nowhere
> near production quality yet.  I just wanted to inform anyone who may
> be willing to give feedback.

i've sent a couple people to see the patch and told them to leave any
comments there in the tracker attached to the patch. i haven't checked to
see if they have. 

> 
> Also, if anyone is planning major changes to the Oscar protocol
> handler in the near future, I would be interested in knowing about it,
> so that I don't waste effort on code that will be useless later.
> Thanks.

work is being done on oscar, but not with the file transfer code. kingant
is working on server stored lists and authorization stuff for icq via
oscar.
luke

> 
> -- Wil
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel

-- 
-This email is made of 100% recycled electrons.
-If something can go wrong.... FIX IT!
 If it's Microsoft...delete it.
-There are three ways to get something done:
   (1) Do it yourself.
   (2) Hire someone to do it for you.
   (3) Forbid your kids to do it.

Re: [Gaim-devel] Oscar file transfer patch v0.3

From: William T. Mahan <wtm2@du...> - 2002-09-25 04:42

Attachments: Message as HTML

On Tue, Sep 24, 2002 at 11:48:34PM -0400, Luke Schierer wrote:
>
> > This version adds preliminary support for sending files; it is now
> > possible to transfer a file between two patched Gaim clients.  See the
>=20
> how does it work for between gaim and winaim?

Oh, Winaim to Gaim transfers have been my primary focus (obviously,
that's what I had to use for the initial development).  It just
happens that I was able to emulate the OFT protocol faithfully enough
that Gaim-Gaim transfers also work. :-)

>=20
> i've sent a couple people to see the patch and told them to leave any
> comments there in the tracker attached to the patch. i haven't checked to
> see if they have.=20

Thanks.  I have gotten some useful feedback from a few users, but it
never hurts to have more.

>
> work is being done on oscar, but not with the file transfer code. kingant
> is working on server stored lists and authorization stuff for icq via
> oscar.

That doesn't sound like it would conflict with my work.  I chatted
with Rob Flynn tonight about how to better generalize the user
interface (by adding hooks to prpl.[hc]), so it looks like there is
plenty for me to do that will not conflict with other peoples'
changes. :-)

-- Wil

Re: [Gaim-devel] Oscar file transfer patch v0.3

From: Mark Doliner <mark@ki...> - 2002-09-25 04:49

> > work is being done on oscar, but not with the file transfer code. kingant
> > is working on server stored lists and authorization stuff for icq via
> > oscar.
> 
> That doesn't sound like it would conflict with my work.  I chatted
> with Rob Flynn tonight about how to better generalize the user
> interface (by adding hooks to prpl.[hc]), so it looks like there is
> plenty for me to do that will not conflict with other peoples'
> changes. :-)

Yeah, the stuff I work on not-often-enough shouldn't interfere at all.  
The only thing I can think of that might overlap would be non-direct 
connect typing notification.  It involves adding support for a few more 
snacs to im.c.  But at the rate you're going, you'll probably have that 
finished before that becomes an issue (and a minor issue, at that).
-Mark

Re: [Gaim-devel] Oscar file transfer patch v0.3

From: Rob Flynn <rob@ma...> - 2002-09-25 05:29

If anyone wants to make any suggestions as to how the prpl interface for
file transfer should exist then I'd like to hear them.  

On Wed, 2002-09-25 at 00:49, Mark Doliner wrote:
> > > work is being done on oscar, but not with the file transfer code. kingant
> > > is working on server stored lists and authorization stuff for icq via
> > > oscar.
> > 
> > That doesn't sound like it would conflict with my work.  I chatted
> > with Rob Flynn tonight about how to better generalize the user
> > interface (by adding hooks to prpl.[hc]), so it looks like there is
> > plenty for me to do that will not conflict with other peoples'
> > changes. :-)
> 
> Yeah, the stuff I work on not-often-enough shouldn't interfere at all.  
> The only thing I can think of that might overlap would be non-direct 
> connect typing notification.  It involves adding support for a few more 
> snacs to im.c.  But at the rate you're going, you'll probably have that 
> finished before that becomes an issue (and a minor issue, at that).
> -Mark
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel

Re: [Gaim-devel] encodings in gaim

From: Sergey V. Udaltsov <sergey.oudaltsov@cl...> - 2002-09-24 08:10

> If your LANG and/or LC_CTYPE are set to ru_RU (or ru_RU.koi8-r or
> whatever), it should work fine.  AIM/ICQ will not (yet).
My LANG is ru_RU.KOI8-R. And it does not work. When I send russian to my
partner - it sees it as a russian. But in wrong encoding. He uses
standard MSN client, I use gaim. Should I submit it as a bug report or
what? Can this be caused by useage of rusconv?
 
> I agree ... unfortunately internationalization in Gtk1 (especially
> given the current state of the gaim codebase, which was not written
> with i18n in mind at *all*) is going to be difficult at best.  The
I do believe. But many programs still manage to be good in i18n
department. So I hope gaim can do too.

> last few releases should have been markedly better, but issues still
> remain.
I see myself:)

Regards,

Sergey

Re: [Gaim-devel] encodings in gaim

From: Ethan Blanton <eblanton@cs...> - 2002-09-24 15:57

Attachments: Message as HTML

Sergey V. Udaltsov spake unto us the following wisdom:
> My LANG is ru_RU.KOI8-R. And it does not work. When I send russian to my
> partner - it sees it as a russian. But in wrong encoding. He uses
> standard MSN client, I use gaim. Should I submit it as a bug report or
> what? Can this be caused by useage of rusconv?

Oh, yes!  You should *not* be using rusconv with 0.59.3 over MSN...
That would certainly cause it to be in the wrong encoding on the other
end.

Ethan

--=20
And if I claim to be a wise man / it surely means that I don't know.
                -- Kansas, "Carry on Wayward Son"

Re: [Gaim-devel] encodings in gaim

From: Sergey V. Udaltsov <sergey.oudaltsov@cl...> - 2002-09-24 20:42

> Oh, yes!  You should *not* be using rusconv with 0.59.3 over MSN...
> That would certainly cause it to be in the wrong encoding on the other
> end.
OK. But if I want to use rusconv with AIM/ICQ account? I cannot say "use
rusconv for ICQ, do not use for MSN", can I? So what would be solution
for me (and other russians)?

Cheers,

Sergey

Re: [Gaim-devel] encodings in gaim

From: Ethan Blanton <eblanton@cs...> - 2002-09-24 21:13

Attachments: Message as HTML

Sergey V. Udaltsov spake unto us the following wisdom:
> > Oh, yes!  You should *not* be using rusconv with 0.59.3 over MSN...
> > That would certainly cause it to be in the wrong encoding on the other
> > end.
>
> OK. But if I want to use rusconv with AIM/ICQ account? I cannot say "use
> rusconv for ICQ, do not use for MSN", can I? So what would be solution
> for me (and other russians)?

The current solution (sorry) is wait for gaim to be fixed right.
Hopefully that won't be *too* long now...

Ethan

--=20
And if I claim to be a wise man / it surely means that I don't know.
                -- Kansas, "Carry on Wayward Son"

Re: [Gaim-devel] A question and an offer, re: MSN functionality

From: Sean Egan <bj91704@bi...> - 2002-09-24 20:13

On Mon, 2002-09-23 at 18:26, Kris Newman wrote:
> Well, seeing as how that's exactly how it works (Text sent is prefaced
> by AUTORESPONSE) with the AIM protocol, it really shouldn't be a big
> issue (Wow, listen to the non-programmer talk about ease of
> implementation!!!) to add that back in. I've already patched my version,
> and will be testing it out as soon as my WinDoze box sees fit to boot.

Well, that's what you see ;)  A winaim user sees some <HR>s and stuff...
AIM has a special "Away message" flag-- MSN does not.

Anyway, this can be very easily added as a plugin--I'd like to avoid
adding more options that nobody ever changes and start removing them...
like "Ignore Automated TiK messages"  Nobody even knows what it means,
much less uses it ;)

-s.

[Gaim-devel] no rule to make target msgunread.png

From: Jeremy Vinding <jvinding@ao...> - 2002-09-24 16:49

hi... i'm getting the following error when trying to build the nightly
tarball:
*** No rule to make target `msgunread.png', needed by `all-am'.

i dunno enough about autoconf/automake to tell it to ignore that file...
any suggestions would be appreciated.

just out of curiosity, am i the only one to encounter this, or am i the
only one who doesn't know how to fix it :)?


Thx,

jjv

Re: [Gaim-devel] no rule to make target msgunread.png

From: Nathan Walp <faceprint@fa...> - 2002-09-24 19:41

Attachments: Message as HTML

On Tue, Sep 24, 2002 at 10:51:55AM -0600, Jeremy Vinding wrote:
> hi... i'm getting the following error when trying to build the nightly
> tarball:
> *** No rule to make target `msgunread.png', needed by `all-am'.

Not just you.  The nightlies (aka once-in-a-whiles) are broken atm.
I'll see if I can pester Sean into fixing them ;-)

--=20
Nathan Walp             || faceprint@...
GPG Fingerprint:        ||   http://faceprint.com/
5509 6EF3 928B 2363 9B2B  DA17 3E46 2CDC 492D DB7E

[Gaim-devel] Re: Gaim docklet.

From: Robert McQueen <robot101@de...> - 2002-09-24 14:13

On Tue, Sep 24, 2002 at 12:48:03AM -0400, Zack Rusin wrote:
> On Monday 23 September 2002 14:03, you wrote:
> > Even whilst the message passing stuff is in the air, the docking
> > itself is easy enough to support and would be great to see in 3.1 for
> > Gaim users - I'm not using any notification stuff until the
> > standard's support for it is finalised.
> 
> FYI, it was just committed, so all Gaim uses will see the docklet in KDE 
> 3.1.
> 
> Zack

Excellent news, thanks very much. I've CC'd this on to the gaim-devel
list.

Regards,
Rob

Next Messages