Menu
▾
▴
pidgin-devel — DO NOT USE. See https://pidgin.im/cgi-bin/mailman/listinfo/devel
You can subscribe to this list here.
| 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
|
|
From: Luke S. <lsc...@gm...> - 2002-10-15 20:54:07
|
On Tue, Oct 15, 2002 at 04:31:04PM -0400, Daniel Drown wrote: > On Tue, 15 Oct 2002, Luke Schierer wrote: > > is this against cvs or 0.59.4? if against cvs, is it against HEAD or > > gtk1-stable? > > luke > > ah, sorry. 0.59.4. Looks like CVS already has it in HEAD(yahoo.c 1.54)/ > gtk1-stable(yahoo.c 1.43.2.6). if both HEAD and gtk1-stable already have the fix, then just wait for 0.59.5 luke > > -- > It's looking like if MySQL AB doesn't make a movie based on the manual, > nobody's ever gonna learn how to use a database. > - r. > > > ------------------------------------------------------- > This sf.net email is sponsored by: viaVerio will pay you up to > $1,000 for every account that you consolidate with us. > http://ad.doubleclick.net/clk;4749864;7604308;v?http://www.viaverio.com/ > consolidator/osdn.cfm > > > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel -- -This email is made of 100% recycled electrons. |
|
From: Daniel D. <dan...@dr...> - 2002-10-15 20:45:07
|
On Tue, 15 Oct 2002, Luke Schierer wrote:
> is this against cvs or 0.59.4? if against cvs, is it against HEAD or
> gtk1-stable?
> luke
ah, sorry. 0.59.4. Looks like CVS already has it in HEAD(yahoo.c 1.54)/
gtk1-stable(yahoo.c 1.43.2.6).
--
It's looking like if MySQL AB doesn't make a movie based on the manual,
nobody's ever gonna learn how to use a database.
- r.
|
|
From: Luke S. <lsc...@gm...> - 2002-10-15 20:38:11
|
is this against cvs or 0.59.4? if against cvs, is it against HEAD or
gtk1-stable?
luke
On Tue, Oct 15, 2002 at 03:53:25PM -0400, Daniel Drown wrote:
> I get the following backtrace when trying to use YIM + gaim 0.59.4:
>
> #0 0x40579310 in __strncasecmp (s1=0x0, s2=0x407c2d1a "TYPING", n=6)
> at ../sysdeps/generic/strncase.c:68
> #1 0x40476a90 in g_strncasecmp (s1=0x0, s2=0x407c2d1a "TYPING", n=6)
> at gstrfuncs.c:1226
> #2 0x407bcfc3 in yahoo_process_notify (gc=0x820b400, pkt=0x8233650)
> at yahoo.c:528
> ...
>
> it looks like yahoo is sending out notifications without a msg field, so the
> following patch just aborts the notification processing for such packets:
>
> I am able to use YIM after this patch is applied
>
> --- src/protocols/yahoo/yahoo.c.orig Tue Oct 1 15:36:23 2002
> +++ src/protocols/yahoo/yahoo.c Tue Oct 15 15:47:23 2002
> @@ -524,7 +524,10 @@
> game = pair->value;
> l = l->next;
> }
> -
> +
> + if (!msg)
> + return;
> +
> if (!g_strncasecmp(msg, "TYPING", strlen("TYPING"))) {
> if (*stat == '1')
> serv_got_typing(gc, from, 0);
>
> --
> It's looking like if MySQL AB doesn't make a movie based on the manual,
> nobody's ever gonna learn how to use a database.
> - r.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gaim-devel mailing list
> Gai...@li...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel
--
-This email is made of 100% recycled electrons.
|
|
From: Levi R. <lr...@st...> - 2002-10-15 20:34:51
|
On Tue Oct 15 10:23 -0400, Mike Wohlgemuth wrote: > I also have one other thing that seems to be more of an issue between > MetaCity and gaim. I would like my gaim windows to always come up > sticky. Sawfish used to have a setting to always make a window sticky, > but MetaCity doesn't, and from what I can tell by Googling, it's not > likely that it will. Havoc seems to think that this should be that > application's job. Do you guys have any plans along these lines? You do realize that you can still use sawfish with GNOME2 instead of metacity? killall metacity && sawfish & -- Levi Ramsey lr...@st... le...@cy... Love lies in pools of questions. GPG Key Fingerprint: 354C 7A02 77C5 9EE7 8538 4E8D DCD9 B4B0 DC35 67CD Currently playing: Metallica - Slither Linux 2.4.19-16mdk 16:30:01 up 12 days, 14:55, 15 users, load average: 2.15, 2.10, 1.44 |
|
From: Ethan B. <ebl...@cs...> - 2002-10-15 20:22:13
|
David Odin spake unto us the following wisdom:
> On Tue, Oct 15, 2002 at 10:56:39AM -0500, Ethan Blanton wrote:
> > David Odin spake unto us the following wisdom:
> > > + buf2 =3D g_locale_to_utf8(buf2, -1, NULL, NULL, NULL);*/
> >
> Obviously, this one is inside a comment...
Oops. :-)
> > > + write_to_conv(c, g_locale_from_utf8(buf, -1, NULL, NULL, NULL),=
WFLAG_SEND, NULL, time(NULL), -1);
> >=20
> To send the message, we need to convert it from utf8 to locale, since
> the peer may not understand the utf8 encoding. But any way, this is not
> the reason for this (see below.) [1]
No, this is not correct. The peer should understand the encoding of
the protocol, whatever that happens to be; at the UI level we have no
idea what this encoding is. The protocol plugin will handle that, and
the interface between the rest of gaim and a protocol plugin is now
strictly UTF-8. For protocols that do not speak native UTF-8, e.g.
Oscar, the character set conversion occurs in the protocol plugin.
> > > + buf2 =3D g_locale_to_utf8(buf2, -1, NULL, NULL, NULL);
> >=20
> > > + write_to_conv(c, g_locale_from_utf8(buf, -1, NULL, NULL, NULL),=
WFLAG_SEND, NULL, time(NULL), -1);
> >=20
> These last two line are inside a function that shouldn't be called
> anyway, since the old c->entry isn't shown anymore.
Fair enough.
> > > + textutf8 =3D g_locale_to_utf8(text, -1, NULL, NULL, NULL);
> >=20
> This is from gtkimhtml.c. Without this, any text I receive from a
> buddy is truncated at the first non-ascii character, because the text is
> certainly send as non-utf8 (fr_FR in this case...)
No. This should not be happening. If you are receiving fr_FR
(probably ISO-8859-1) text from a buddy, then either our prpl for that
service is broken or your buddy is sending invalid IMs that just
happened to work before because of our broken character set handling
(or lack thereof). Personally, at this point I suspect your buddy's
IMer.
What program is your buddy using? If it is gaim pre-0.59.1 it is
certainly broken. Other OSS IM clients are probably also broken.
> And since this code is also used to display the text I type, I had to
> transform the text I type into locale from utf8, hence the change in [1]
See the above. :-)
> > These make me nervous ... input taken from a native gtk2 widget should
> > *already* be UTF-8, and shouldn't have to be converted... If this
> > isn't the case, something funky is going on here.
> >=20
> Yes, the input taken from the GtkTextBuffer is utf8, but the input
> taken from the aim buddies isn't. :-(
It most certainly is, and anything otherwise indicates a bug in one of
the clients involved.
Ethan
--=20
And if I claim to be a wise man / it surely means that I don't know.
-- Kansas, "Carry on Wayward Son"
|
|
From: Daniel D. <dan...@dr...> - 2002-10-15 20:07:28
|
I get the following backtrace when trying to use YIM + gaim 0.59.4:
#0 0x40579310 in __strncasecmp (s1=0x0, s2=0x407c2d1a "TYPING", n=6)
at ../sysdeps/generic/strncase.c:68
#1 0x40476a90 in g_strncasecmp (s1=0x0, s2=0x407c2d1a "TYPING", n=6)
at gstrfuncs.c:1226
#2 0x407bcfc3 in yahoo_process_notify (gc=0x820b400, pkt=0x8233650)
at yahoo.c:528
...
it looks like yahoo is sending out notifications without a msg field, so the
following patch just aborts the notification processing for such packets:
I am able to use YIM after this patch is applied
--- src/protocols/yahoo/yahoo.c.orig Tue Oct 1 15:36:23 2002
+++ src/protocols/yahoo/yahoo.c Tue Oct 15 15:47:23 2002
@@ -524,7 +524,10 @@
game = pair->value;
l = l->next;
}
-
+
+ if (!msg)
+ return;
+
if (!g_strncasecmp(msg, "TYPING", strlen("TYPING"))) {
if (*stat == '1')
serv_got_typing(gc, from, 0);
--
It's looking like if MySQL AB doesn't make a movie based on the manual,
nobody's ever gonna learn how to use a database.
- r.
|
|
From: David O. <Da...@di...> - 2002-10-15 17:29:48
|
On Tue, Oct 15, 2002 at 10:56:39AM -0500, Ethan Blanton wrote:
> David Odin spake unto us the following wisdom:
> > + buf2 = g_locale_to_utf8(buf2, -1, NULL, NULL, NULL);*/
>
Obviously, this one is inside a comment...
> > + write_to_conv(c, g_locale_from_utf8(buf, -1, NULL, NULL, NULL), WFLAG_SEND, NULL, time(NULL), -1);
>
To send the message, we need to convert it from utf8 to locale, since
the peer may not understand the utf8 encoding. But any way, this is not
the reason for this (see below.) [1]
> > + buf2 = g_locale_to_utf8(buf2, -1, NULL, NULL, NULL);
>
> > + write_to_conv(c, g_locale_from_utf8(buf, -1, NULL, NULL, NULL), WFLAG_SEND, NULL, time(NULL), -1);
>
These last two line are inside a function that shouldn't be called
anyway, since the old c->entry isn't shown anymore.
> > + textutf8 = g_locale_to_utf8(text, -1, NULL, NULL, NULL);
>
This is from gtkimhtml.c. Without this, any text I receive from a
buddy is truncated at the first non-ascii character, because the text is
certainly send as non-utf8 (fr_FR in this case...)
And since this code is also used to display the text I type, I had to
transform the text I type into locale from utf8, hence the change in [1]
> These make me nervous ... input taken from a native gtk2 widget should
> *already* be UTF-8, and shouldn't have to be converted... If this
> isn't the case, something funky is going on here.
>
Yes, the input taken from the GtkTextBuffer is utf8, but the input
taken from the aim buddies isn't. :-(
Regards,
DindinX
--
Da...@di...
To the systems programmer, users and applications serve only to provide a
test load.
|
|
From: Mike W. <mj...@wo...> - 2002-10-15 16:49:14
|
On Tue, 2002-10-15 at 10:34, Luke Schierer wrote: > On Tue, Oct 15, 2002 at 10:23:09AM -0400, Mike Wohlgemuth wrote: > > file->close in a conversation, or you can enable escape to close or > control-w in preferences. Man, I thought I tried that and it closed everything, but thanks. > this by the way, is great for people who want to help out by submitting > patches. I would be more than happy to submit a patch, but since I haven't written any GUI code since my senior project on a Sun 3/50 with SunViews, I'm not sure I'll have a patch ready any time soon. I am trying to figure out the code, though, so maybe something will come of it. Thanks again for the tip. Woogie |
|
From: Ethan B. <ebl...@cs...> - 2002-10-15 15:58:47
|
David Odin spake unto us the following wisdom:
> + buf2 =3D g_locale_to_utf8(buf2, -1, NULL, NULL, NULL);*/
> + write_to_conv(c, g_locale_from_utf8(buf, -1, NULL, NULL, NULL), WFL=
AG_SEND, NULL, time(NULL), -1);
> + buf2 =3D g_locale_to_utf8(buf2, -1, NULL, NULL, NULL);
> + write_to_conv(c, g_locale_from_utf8(buf, -1, NULL, NULL, NULL), WFL=
AG_SEND, NULL, time(NULL), -1);
> + textutf8 =3D g_locale_to_utf8(text, -1, NULL, NULL, NULL);
These make me nervous ... input taken from a native gtk2 widget should
*already* be UTF-8, and shouldn't have to be converted... If this
isn't the case, something funky is going on here.
Ethan
--=20
And if I claim to be a wise man / it surely means that I don't know.
-- Kansas, "Carry on Wayward Son"
|
|
From: David O. <Da...@di...> - 2002-10-15 15:37:01
|
Hi,
Just as I promise the other day, here is my first attempt to replace the
entry part of a chat window (which is currently a GtkText) with a
GtkTextBuffer/GtkTextView pair.
I know it is ugly. I know it is work in progress. But, for basic text
edition, it Works-For-Me(tm).
Please let me know if it's ok for you too.
I go back to work and add all the features the previous entry has...
Regards,
DindinX
--
Da...@di...
I think I'm schizophrenic. One half of me's paranoid and the other half's
out to get him.
|
|
From: Robert M. <rob...@de...> - 2002-10-15 15:17:22
|
On Tue, Oct 15, 2002 at 10:34:15AM -0400, Luke Schierer wrote: > robot101 has talked of writting a plugin to interact with a session > manager, but i'm not sure if what you describe would become possible with > that. Nope. =) > luke Regards, Rob |
|
From: Luke S. <lsc...@gm...> - 2002-10-15 14:34:23
|
On Tue, Oct 15, 2002 at 10:23:09AM -0400, Mike Wohlgemuth wrote: > I have just built gaim .60 for the first time and am new to this list, > so forgive me if this is a know issue, but I didn't see anything about > it in the bugs database or on the list. I have all my chats & IMs in its been discussed heavily in #gaim on irc.freenode.net ;-) > one window. My problem is that there doesn't seem to be a way to close > just one of the tabs. With older versions, there was an "X" in the file->close in a conversation, or you can enable escape to close or control-w in preferences. > lower right corner of the window, which isn't there anymore. I first > built from CVS yesterday morning, but I just updated and rebuilt it and > am still seeing the same results. yes, the close button was removed, we are planning on putting an x button in each tab like galeon has, but rob hasn't had a chance yet. cvs is a work in progress, and now that we have more than 2 developers, is actually being used for its intended purpose: development, and letting multiple developers have access to the most recent version of each file at any given time. this by the way, is great for people who want to help out by submitting patches. > > I also have one other thing that seems to be more of an issue between > MetaCity and gaim. I would like my gaim windows to always come up > sticky. Sawfish used to have a setting to always make a window sticky, > but MetaCity doesn't, and from what I can tell by Googling, it's not > likely that it will. Havoc seems to think that this should be that > application's job. Do you guys have any plans along these lines? robot101 has talked of writting a plugin to interact with a session manager, but i'm not sure if what you describe would become possible with that. luke -- -This email is made of 100% recycled electrons. |
|
From: Mike W. <mj...@wo...> - 2002-10-15 14:23:15
|
I have just built gaim .60 for the first time and am new to this list, so forgive me if this is a know issue, but I didn't see anything about it in the bugs database or on the list. I have all my chats & IMs in one window. My problem is that there doesn't seem to be a way to close just one of the tabs. With older versions, there was an "X" in the lower right corner of the window, which isn't there anymore. I first built from CVS yesterday morning, but I just updated and rebuilt it and am still seeing the same results. I also have one other thing that seems to be more of an issue between MetaCity and gaim. I would like my gaim windows to always come up sticky. Sawfish used to have a setting to always make a window sticky, but MetaCity doesn't, and from what I can tell by Googling, it's not likely that it will. Havoc seems to think that this should be that application's job. Do you guys have any plans along these lines? Thanks Woogie |
|
From: Jesse W. <bea...@fa...> - 2002-10-15 13:01:16
|
I'm running Mandrake 9.0. The Gaim CVS snapshot from Tue Oct 15 will not make. Heres the output: perl.c:773: `items' undeclared (first use in this function) perl.c:776: warning: assignment makes pointer from integer without a cast perl.c:777: warning: assignment makes pointer from integer without a cast perl.c: At top level: perl.c:795: redefinition of `XS' perl.c:766: `XS' previously defined here perl.c: In function `XS': perl.c:802: `dXSARGS' undeclared (first use in this function) perl.c:803: `items' undeclared (first use in this function) perl.c:807: warning: assignment makes pointer from integer without a cast perl.c: In function `perl_event': perl.c:831: `SV' undeclared (first use in this function) perl.c:831: `handler_return' undeclared (first use in this function) perl.c: At top level: perl.c:972: redefinition of `XS' perl.c:795: `XS' previously defined here perl.c: In function `XS': perl.c:978: `dXSARGS' undeclared (first use in this function) perl.c:979: `items' undeclared (first use in this function) perl.c:981: warning: assignment makes pointer from integer without a cast perl.c:991: warning: passing arg 1 of `g_strdup' makes pointer from integer without a cast perl.c:992: warning: passing arg 1 of `g_strdup' makes pointer from integer without a cast perl.c:1000: `XSRETURN_EMPTY' undeclared (first use in this function) perl.c: At top level: perl.c:1004: redefinition of `XS' perl.c:972: `XS' previously defined here perl.c: In function `XS': perl.c:1008: `dXSARGS' undeclared (first use in this function) perl.c:1014: warning: passing arg 1 of `strlen' makes pointer from integer without a cast perl.c:1014: warning: passing arg 1 of `strlen' makes pointer from integer without a cast perl.c:1014: warning: passing arg 2 of `strcmp' makes pointer from integer without a cast perl.c:1015: warning: passing arg 1 of `strlen' makes pointer from integer without a cast perl.c:1015: warning: passing arg 1 of `strlen' makes pointer from integer without a cast perl.c:1015: warning: passing arg 2 of `strcmp' makes pointer from integer without a cast perl.c: At top level: perl.c:1040: redefinition of `XS' perl.c:1004: `XS' previously defined here perl.c: In function `XS': perl.c:1048: `dXSARGS' undeclared (first use in this function) perl.c:1049: `items' undeclared (first use in this function) perl.c:1051: warning: assignment makes pointer from integer without a cast perl.c:1064: warning: passing arg 1 of `g_strdup' makes pointer from integer without a cast perl.c:1065: warning: passing arg 1 of `g_strdup' makes pointer from integer without a cast perl.c:1071: `XSRETURN_EMPTY' undeclared (first use in this function) perl.c: At top level: perl.c:1075: redefinition of `XS' perl.c:1040: `XS' previously defined here perl.c: In function `XS': perl.c:1077: `dXSARGS' undeclared (first use in this function) perl.c:1083: `XSRETURN_EMPTY' undeclared (first use in this function) make[3]: *** [perl.o] Error 1 make[3]: Leaving directory `/home/jesse/compile/gaim-20021005/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jesse/compile/gaim-20021005/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jesse/compile/gaim-20021005' make: *** [all] Error 2 [jesse@dr-proton gaim-20021005]$ -- http://fastmail.fm/ - The professional email service |
|
From: <der...@ya...> - 2002-10-15 04:47:17
|
I have been having problems with the docklet
not hiding the IM window until I click on the
docklet. So I fixed it. Here is what I did.
Hope it helps. Sorry about the formatting, I am
using a web based mail thingo.
diff -u -r1.245 server.c
--- src/server.c 9 Oct 2002 16:31:33 -0000 1.245
+++ src/server.c 15 Oct 2002 04:41:22 -0000
@@ -730,8 +730,8 @@
play_sound(SND_FIRST_RECEIVE);
else if (new_conv || cnv->makesound)
play_sound(SND_RECEIVE);
-
- if (away_options & OPT_AWAY_QUEUE_UNREAD &&
!find_conversation(name) && docklet_count) {
+
+ if (away_options & OPT_AWAY_QUEUE_UNREAD &&
new_conv && docklet_count) {
/* We're gonna queue it up and wait for the user
to ask for it... probably
* by clicking the docklet or windows tray icon.
*/
struct queued_message *qm;
diff -u -r1.17 notify.c
--- plugins/notify.c 28 Sep 2002 21:39:44 -0000 1.17
+++ plugins/notify.c 15 Oct 2002 04:40:32 -0000
@@ -71,7 +71,8 @@
if (cnv == NULL)
{
- if (away_options & OPT_AWAY_QUEUE)
+ if (away_options & OPT_AWAY_QUEUE ||
+ away_options & OPT_AWAY_QUEUE_UNREAD)
return 0;
http://mobile.yahoo.com.au - Yahoo! Messenger for SMS
- Always be connected to your Messenger Friends
|
|
From: Luke S. <lsc...@gm...> - 2002-10-14 21:41:51
|
On Mon, Oct 14, 2002 at 10:36:08PM +0100, Adam Feakin wrote: > I cvs updated 0.59 today, and since doing that I have noticed that when > anyone using trillian with yim tries to talk to me it crashes trillian > on their machines. Has anyone else noticed that? It only happens with > yahoo, and did not happen to people before I cvs updated. I'm surprised it isn't crashing you as well. yahoo recently changed the protocol, and gaim, everybuddy, trialian, and yahoo's own linux client all crash when they recieve the new packet. gaim should be releasing a new version to handle this better some time this week. i have no clue when other projects will do so (trillian, eb, et al). luke > > -- > Adam > ad...@sn... > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel -- -This email is made of 100% recycled electrons. |
|
From: Adam F. <ad...@sn...> - 2002-10-14 21:36:12
|
I cvs updated 0.59 today, and since doing that I have noticed that when anyone using trillian with yim tries to talk to me it crashes trillian on their machines. Has anyone else noticed that? It only happens with yahoo, and did not happen to people before I cvs updated. -- Adam ad...@sn... |
|
From: David O. <Da...@di...> - 2002-10-14 17:01:02
|
On Mon, Oct 14, 2002 at 11:45:30AM -0500, Ethan Blanton wrote:
> David Odin spake unto us the following wisdom:
> > > Please just be patient with us ... This patch does temporarily solve
> > > the problem in some places, but we are working on the Right Fix. :-)
> > > It shouldn't be long now.
> > >
> > I'm also working on the Right Fix which, imho, is to use the gtk2
> > widgets (gtktextview/gtktextbuffer). I've already done some of the work
> > to replace the GtkText edit zone by a GtkTextView. It works well for
> > basic editing (I've still to port many of the features the old c->entry)
> > has.
>
> Yes, that is the Right Fix. :-)
>
> > Tell me if you're interested or if I should just give up and be
> > patient. I have a pretty good knowledge of gtk, so I guess I can help.
>
> I'm not sure if that's a duplication of effort or not... I now others
> have been working on that conversion, but I don't know what kind of
> progress has been made.
>
Ok. So I'll make my patch clean and send it there soon. If no progress
is made elsewhere, it will always be a good place to go on from.
Regards,
DindinX
--
Da...@di...
If it weren't for the last minute, nothing would ever get done.
|
|
From: Luke S. <lsc...@gm...> - 2002-10-14 16:47:44
|
On Mon, Oct 14, 2002 at 06:33:46PM +0200, David Odin wrote: > On Mon, Oct 14, 2002 at 11:17:08AM -0500, Ethan Blanton wrote: > > Cyril Bellot spake unto us the following wisdom: > > > I have had problems in the current CVS release with UTF8 handle of gtk2 > > > in entry area and gtkimhtml area causing bad interpretations of non > > > ascii characters. > > > > Yes. This is a known issue, and one that will be going away soon. > > The problem is that our display widget has moved to UTF-8, but the > > input widget remains locale-specific. > > > > > So here is a patch from David Odin fixing it. > > > This workaround is probably in progress but the patch may help > > > > Please just be patient with us ... This patch does temporarily solve > > the problem in some places, but we are working on the Right Fix. :-) > > It shouldn't be long now. > > > I'm also working on the Right Fix which, imho, is to use the gtk2 > widgets (gtktextview/gtktextbuffer). I've already done some of the work > to replace the GtkText edit zone by a GtkTextView. It works well for > basic editing (I've still to port many of the features the old c->entry) > has. yes, using gtk2 widgets is the right fix. no i do not know how close sean/rob/whoever is to this, so i can't advise you to continue working or be patient. luke > > Tell me if you're interested or if I should just give up and be > patient. I have a pretty good knowledge of gtk, so I guess I can help. > > Regards, > > DindinX > > -- > Da...@di... > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel -- -This email is made of 100% recycled electrons. |
|
From: Ethan B. <ebl...@cs...> - 2002-10-14 16:45:57
|
David Odin spake unto us the following wisdom:
> > Please just be patient with us ... This patch does temporarily solve
> > the problem in some places, but we are working on the Right Fix. :-)
> > It shouldn't be long now.
> >=20
> I'm also working on the Right Fix which, imho, is to use the gtk2
> widgets (gtktextview/gtktextbuffer). I've already done some of the work
> to replace the GtkText edit zone by a GtkTextView. It works well for
> basic editing (I've still to port many of the features the old c->entry)
> has.
Yes, that is the Right Fix. :-)
> Tell me if you're interested or if I should just give up and be
> patient. I have a pretty good knowledge of gtk, so I guess I can help.
I'm not sure if that's a duplication of effort or not... I now others
have been working on that conversion, but I don't know what kind of
progress has been made.
Ethan
--=20
And if I claim to be a wise man / it surely means that I don't know.
-- Kansas, "Carry on Wayward Son"
|
|
From: David O. <Da...@di...> - 2002-10-14 16:33:54
|
On Mon, Oct 14, 2002 at 11:17:08AM -0500, Ethan Blanton wrote:
> Cyril Bellot spake unto us the following wisdom:
> > I have had problems in the current CVS release with UTF8 handle of gtk2
> > in entry area and gtkimhtml area causing bad interpretations of non
> > ascii characters.
>
> Yes. This is a known issue, and one that will be going away soon.
> The problem is that our display widget has moved to UTF-8, but the
> input widget remains locale-specific.
>
> > So here is a patch from David Odin fixing it.
> > This workaround is probably in progress but the patch may help
>
> Please just be patient with us ... This patch does temporarily solve
> the problem in some places, but we are working on the Right Fix. :-)
> It shouldn't be long now.
>
I'm also working on the Right Fix which, imho, is to use the gtk2
widgets (gtktextview/gtktextbuffer). I've already done some of the work
to replace the GtkText edit zone by a GtkTextView. It works well for
basic editing (I've still to port many of the features the old c->entry)
has.
Tell me if you're interested or if I should just give up and be
patient. I have a pretty good knowledge of gtk, so I guess I can help.
Regards,
DindinX
--
Da...@di...
|
|
From: Ethan B. <ebl...@cs...> - 2002-10-14 16:17:37
|
Cyril Bellot spake unto us the following wisdom:
> I have had problems in the current CVS release with UTF8 handle of gtk2
> in entry area and gtkimhtml area causing bad interpretations of non
> ascii characters.
Yes. This is a known issue, and one that will be going away soon.
The problem is that our display widget has moved to UTF-8, but the
input widget remains locale-specific.
> So here is a patch from David Odin fixing it.
> This workaround is probably in progress but the patch may help
Please just be patient with us ... This patch does temporarily solve
the problem in some places, but we are working on the Right Fix. :-)
It shouldn't be 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"
|
|
From: Cyril B. <cyr...@sk...> - 2002-10-14 10:46:16
|
I have had problems in the current CVS release with UTF8 handle of gtk2 in entry area and gtkimhtml area causing bad interpretations of non ascii characters. So here is a patch from David Odin fixing it. This workaround is probably in progress but the patch may help -- Cyril Bellot <cyr...@sk...> |
|
From: Kris N. <kn...@kh...> - 2002-10-13 00:33:21
|
Running under RH8, latest CVS checkout of Gaim (which compiled wonderfully, and the docklet is everything I hoped it would be), the iconaway plugin doesn't seem to work anymore. My away message stays on screen, with no way to minimize. Am I missing something? Kris |
|
From: Luke S. <lsc...@gm...> - 2002-10-11 01:34:22
|
On Thu, Oct 10, 2002 at 09:00:00PM -0400, John B. Silvestri wrote: > There's some merit to the idea of a passkey to unlock your encrypted keys - > this takes care of the problem I was just going to mention. Barring this > idea, encryption in the rc file is completely moot based on the fact that you > could just copy it to another account, run Gaim, and change the passwords, > without ever seeing, or trying to decrypt the 'encrypted passwords.' again, the biggest problems this would cause are for those who don't to remember a pass phrase, and for those who enable it and then latter decide they no longer wish to use it. you could secure the .gaimrc this way, but you probly couldn't do it in a way that wouldn't be annoying. luke > > John Silvestri > > On Thursday 10 October 2002 06:44 pm, Michael Lasevich wrote: > > What is being asked is a bit of obfuscation , not perfect bulletproof > > encryption. A dedicated person can always get around any encryption scheme > > there is. If someone has physical access to my linux box they can have > > root-level permissions in minutes - that does not mean I leave my root > > password on a post it note glued to my monitor. Just because someone can > > easily find means of decoding the passwords, does not mean they should be > > available in plain view to anyone who happens to glance at the rc file. > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel -- -This email is made of 100% recycled electrons. |
171 messages has been excluded from this view by a project administrator.
