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: Christian H. <ch...@gn...> - 2002-09-25 07:17:02
|
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 ch...@gn... <> 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 |
|
From: Marcel B. <ma...@ca...> - 2002-09-25 07:10:06
|
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. |
|
From: <der...@ya...> - 2002-09-25 07:06:21
|
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
|
|
From: Rob F. <ro...@ma...> - 2002-09-25 05:29:27
|
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 > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel |
|
From: Mark D. <ma...@ki...> - 2002-09-25 04:49:17
|
> > 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 |
|
From: William T. M. <wt...@du...> - 2002-09-25 04:42:40
|
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 |
|
From: Luke S. <lsc...@gm...> - 2002-09-25 03:48:49
|
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 > Gai...@li... > 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. |
|
From: William T. M. <wt...@du...> - 2002-09-25 03:41:27
|
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 |
|
From: Ethan B. <ebl...@cs...> - 2002-09-24 21:13:09
|
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"
|
|
From: Sergey V. U. <ser...@cl...> - 2002-09-24 20:42:27
|
> 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 |
|
From: Sean E. <bj...@bi...> - 2002-09-24 20:13:02
|
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. |
|
From: Nathan W. <fac...@fa...> - 2002-09-24 19:41:39
|
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 || fac...@fa... GPG Fingerprint: || http://faceprint.com/ 5509 6EF3 928B 2363 9B2B DA17 3E46 2CDC 492D DB7E |
|
From: Jeremy V. <jvi...@ao...> - 2002-09-24 16:49:26
|
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 |
|
From: Ethan B. <ebl...@cs...> - 2002-09-24 15:57:58
|
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"
|
|
From: Robert M. <rob...@de...> - 2002-09-24 14:13: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 |
|
From: Sergey V. U. <ser...@cl...> - 2002-09-24 08:10:37
|
> 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 |
|
From: Luke S. <lsc...@gm...> - 2002-09-23 22:44:44
|
On Mon, Sep 23, 2002 at 06:26:57PM -0400, 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 no. aim sends the message differently when it is an autoresponce. that AUTORESPONCE text you will notice becomes part of the screenname text, not part of the message. > 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. > > Should someone file on official feature request? there already is one. we don't like the idea of sending autoresponces when there is no built in protocol method of telling the difference. we also don't like _not_ sending them. so we have expressed not-deciding by not-having. 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. |
|
From: Kris N. <kri...@kh...> - 2002-09-23 22:27:51
|
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. Should someone file on official feature request? Kris On Mon, 2002-09-23 at 08:25, Lenny Maiorani wrote: > This is something I have thought I would like as well, but there should > definitely be some text saying this is an auto response in front of the > message... Maybe when people see this they will be enticed to ask about > it and we can all advocate Gaim to them...or Gaim for Windows! > > Lenny > > > Luke Schierer wrote: > >>If Luke's right, and you do indeed mean an autoresponse on MSN, Gaim > >>used to do that, but purposely disabled it. MSN users tend not to > >>expect responses when you're away and it confuses then when they IM you > >>and get one response back and then nothing--at least it does in my > >>experience. > > > > > > i tend to agree that its confusing on those protocols that don't have a means > > to identify an auto responce, but perhaps we could insert some text in those > > cases? or make auto-replying optional for them? > > luke > > > > > > ------------------------------------------------------- > 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 > > |
|
From: Ethan B. <ebl...@cs...> - 2002-09-23 21:47:24
|
Sergey V. Udaltsov spake unto us the following wisdom:
> > Gaim 0.59.3 should work more or less properly for the UTF-8 protocols
> > (as you say, MSN) if you have your locale set correctly. I use it
> > regularly to converse in Japanese, which is much more difficult to
> > convert than, say, KOI8-R.
>
> :) OK. I'll try. The problem is whether 0.53 converts internal unicode
> of MSN correctly into the local encoding (for me it is koi8-r). It seems
> the answer is "no" but I'll check this once again...
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).
> > we'll start seeing real improvements in that area. As Luke said, the
> > move to Gtk2/Pango is certainly going to help.
>
> Glad to hear. But at the moment Gtk1 is still alive (and GNOME 1 is more
> stable, I'd say). And it can do a lot of good things usual good old
> LANG, LC_, CHARSET variables. So do not drop it yet:)
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
last few releases should have been markedly better, but issues still
remain.
> > Thanks for your comments, and stick around for the changeover... I'll
> > need plenty of bug-testers. :-)
>
> OK. Count me in.
Great! :-)
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: Luke S. <lsc...@gm...> - 2002-09-23 21:42:48
|
On Mon, Sep 23, 2002 at 10:30:50PM +0100, Sergey V. Udaltsov wrote: > > Gaim 0.59.3 should work more or less properly for the UTF-8 protocols > > (as you say, MSN) if you have your locale set correctly. I use it > > regularly to converse in Japanese, which is much more difficult to > > convert than, say, KOI8-R. > :) OK. I'll try. The problem is whether 0.53 converts internal unicode > of MSN correctly into the local encoding (for me it is koi8-r). It seems > the answer is "no" but I'll check this once again... uumm, note the version number difference there. we said 0.59.3 you said 0.53. you should not be using a gaim that old. 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. |
|
From: Sergey V. U. <ser...@cl...> - 2002-09-23 21:34:29
|
> Gaim 0.59.3 should work more or less properly for the UTF-8 protocols > (as you say, MSN) if you have your locale set correctly. I use it > regularly to converse in Japanese, which is much more difficult to > convert than, say, KOI8-R. :) OK. I'll try. The problem is whether 0.53 converts internal unicode of MSN correctly into the local encoding (for me it is koi8-r). It seems the answer is "no" but I'll check this once again... > we'll start seeing real improvements in that area. As Luke said, the > move to Gtk2/Pango is certainly going to help. Glad to hear. But at the moment Gtk1 is still alive (and GNOME 1 is more stable, I'd say). And it can do a lot of good things usual good old LANG, LC_, CHARSET variables. So do not drop it yet:) > Thanks for your comments, and stick around for the changeover... I'll > need plenty of bug-testers. :-) OK. Count me in. Sergey |
|
From: Sergey V. U. <ser...@cl...> - 2002-09-23 21:34:27
|
> correct me if i'm wrong, but wouldn't the correct solution be to move the code > loading the gtk theme to before update_idle_time is called? looking at the > debug output, it seems to me that this is the case, that the theme is being > loaded even before protocols start to sign on... Perhaps you're quite right here. This solution (to load the theme before first update_idle_time) seems quite good. The only thing which is definitely not good is the current font setting code:) Cheers, Sergey |
|
From: Ethan B. <ebl...@cs...> - 2002-09-23 21:15:52
|
Sergey V. Udaltsov spake unto us the following wisdom:
> There is a little question about gaim architecture and non-ascii
> encoding. Currently, gaim is rather weak in this area. All the data is
> transferred "as is" (even if gaim is 8-bit clean). The only plugin which
> recodes the data for i18n purposes is well known rusconv. But this great
> plugin is good for the convertion between 2 russian encodings. And its
> usage is limited by ICQ protocol and other pure 8-bit protocols.
> Unicode-based protocols are not supported properly (for example, MSN).
Gaim 0.59.3 should work more or less properly for the UTF-8 protocols
(as you say, MSN) if you have your locale set correctly. I use it
regularly to converse in Japanese, which is much more difficult to
convert than, say, KOI8-R.
As far as ICQ and AIM, we haven't quite made it that far, yet. :-)
I haven't looked at rusconv, but I suspect it is either using an
application-specific encoding (in which case we're basically lucky
it works) or abusing the Unicode encoding as a pure 8-bit transport
(in which case we're even more lucky it works). The right answer is
to convert Oscar packets to UTF-16, and that is being worked on...
> So my major question is about internal gaim structures. Does gaim use
> unicode internally? If no - why? If yes - what is the way? Would it be
> possible to create some generic encoding handling approach with the
> following principles:
The plan is to move CVS over to using UTF-8 exclusively internally.
Basically, by the time a string leaves the protocol plugin, it should
be converted to UTF-8. For the UTF-8 protocols (MSN, Jabber, we think
Yahoo!), this is trivial. For Oscar it is less trivial due to some
design flaws, but it is not horribly difficult.
The "local client" encoding you mention is no longer necessary with
Gtk2, or will not be once everything is ported over to pango-using
widgets. The reason for this is that the "local encoding" as far as a
Gtk2 appliction is concerned is always UTF-8.
Logging presents a slight problem here, my gut instinct is that
logging should honor LC_CTYPE ... however, since logging is currently
done through gtkimhtml (which will be going all UTF-8) as best I can
tell, this may require some work.
> 3. The "internal protocol" encoding is set on per-protocol and/or
> per-buddy basis (some per-protocol default would be nice here - and gaim
> config could allow to modify this parameter). So for MSN it would be
> unicode (UTF-8?), for ICQ it can be ISO8859-1 (or Windows CP1251 for
> Russian users).
The correct answer for ICQ is to just use the Oscar Unicode transport
settings. Like I said, it's being worked on. :-) (Where "worked on"
is a nebulous concept lately...)
> I really admire gaim and would love to see it perfect. I think with the
> library like iconv, my ideas are not very difficult to implement. I
> would be happy to help here with some code but I am afraid I don't have
> enough spare time:(
I've committed to helping make gaim perfect in the i18n department.
:-) Just as soon as I have some free time to kick around, hopefully
we'll start seeing real improvements in that area. As Luke said, the
move to Gtk2/Pango is certainly going to help.
Thanks for your comments, and stick around for the changeover... I'll
need plenty of bug-testers. :-)
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: Luke S. <lsc...@re...> - 2002-09-23 21:05:46
|
correct me if i'm wrong, but wouldn't the correct solution be to move the code loading the gtk theme to before update_idle_time is called? looking at the debug output, it seems to me that this is the case, that the theme is being loaded even before protocols start to sign on... luke On Mon, Sep 23, 2002 at 09:49:59PM +0100, Sergey V. Udaltsov wrote: > Hi all > > Several days ago I offered the solution to the bug on the font used to > display buddies. Actually, the problem is that the correct font is not > taken from gtk theme because the first call to update_idle_time is > performed _before_ gtk theme is loaded, so some wrong default font is > used on style creation. I still got no answer on this report:(. Could > please anyone check my solution (using gtk_rc_get_style) and tell me > whether it actually works. Would it be possible to commit this into CVS > (at least for GTK1) > > Cheers, > > Sergey > > > > ------------------------------------------------------- > 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. -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. |
|
From: Luke S. <lsc...@re...> - 2002-09-23 21:03:48
|
Gaim is currently undergoing a ton of work in the i18n area, moving from a long running attempt to translate things interanlly (happening in part because gtk1 doesn't offer very good support for i18n) to using pango and iconv to translate. different parts of this move have been accomplished with varying ammounts of success in the gtk1-stable tree (as reflected by the 0.59.x releases) and the current cvs head, which will become 0.60. we do not expect that 0.59.x will ever have great i18n, gtk1 is just too painful in this area, but 0.6x will eventually be significantly more capable. luke On Mon, Sep 23, 2002 at 09:44:01PM +0100, Sergey V. Udaltsov wrote: > Hi all > > There is a little question about gaim architecture and non-ascii > encoding. Currently, gaim is rather weak in this area. All the data is > transferred "as is" (even if gaim is 8-bit clean). The only plugin which > recodes the data for i18n purposes is well known rusconv. But this great > plugin is good for the convertion between 2 russian encodings. And its > usage is limited by ICQ protocol and other pure 8-bit protocols. > Unicode-based protocols are not supported properly (for example, MSN). > > So my major question is about internal gaim structures. Does gaim use > unicode internally? If no - why? If yes - what is the way? Would it be > possible to create some generic encoding handling approach with the > following principles: > 1. There is a "local client" encoding and "protocol" or "remote" > encoding. All the visible character data is transcoded using them. > 2. The gaim's local client encoding is determined at run time from LANG, > LC_??? envvars and/or from gaim configuration > 3. The "internal protocol" encoding is set on per-protocol and/or > per-buddy basis (some per-protocol default would be nice here - and gaim > config could allow to modify this parameter). So for MSN it would be > unicode (UTF-8?), for ICQ it can be ISO8859-1 (or Windows CP1251 for > Russian users). > > I really admire gaim and would love to see it perfect. I think with the > library like iconv, my ideas are not very difficult to implement. I > would be happy to help here with some code but I am afraid I don't have > enough spare time:( > > Regards, > > Sergey > > > > ------------------------------------------------------- > 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. -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. |
171 messages has been excluded from this view by a project administrator.
