Mercurial > pidgin
view PROGRAMMING_NOTES @ 9460:eae7e049d639
[gaim-migrate @ 10285]
" This patch completely eliminates the use of the old
numeric prpl identifiers.
I've noticed that some plugins (both in gaim's cvs and
external) continue to use the constants even though
they are essentially no longer valid - code that relies
on them being unique will fail - the new built-in prpls
(SILC and novell) ,and any recent external prpls don't
have numeric values.
The once side effect that the removal causes is that
the code for importing of the old .gaimrc and *.blist
files is a little more kludgy (using magic numbers
instead of the old constants). IMHO this isn't a big
deal as the code will go away eventually anyway.
**This patch also fixes the raw plugin so that i
compiles once again.
**Someone should make sure that the gaim-remote and raw
plugins still work. (If the raw doesn't work, it may be
unrelated as it hasn't been updated since the latest
significant MSN changes - i just made a minor change to
make it compile)" --Daniel Atallah
(13:44:44) Me: what think you of getting rid of prpl numbers?
(13:45:05) Sean: what do you mean?
(13:45:27) Me: right now they are listed as deprecated, but still used in a
few of our own plugins as well as in some 3rd party stuff
(13:45:32) Me: and the enum still exists in the core
(13:45:44) Me: and the newwer prpls such as novell don't use them
(13:45:59) Me: datallah has submitted a patch to get rid of them entirely
(13:46:31) Me: the only thing it would break would be the old blist import,
which he hacked into working with magic numbers, but which i tend to think
we could remove entirely anyway
(13:50:03) Sean: Let's get rid of them, then.
(13:50:10) Sean: and take out old .blist code too
(13:50:14) Me: cool
(13:52:37) Sean: we should get rid of .gaimrc code too, sometime.
(13:53:02) Sean: If anyone's seriously just now upgrading from 0.59.x, or
whatever, they deserve to lose their preferences.
(12:27:56) LSchiere: Paco-Paco: what do you think of getting rid of the
deprecated prpl numbers?
(12:28:14) Paco-Paco: LSchiere: I think it shouldh ave happened long ago
committer: Tailor Script <tailor@pidgin.im>
author | Luke Schierer <lschiere@pidgin.im> |
---|---|
date | Tue, 06 Jul 2004 18:06:43 +0000 |
parents | 10b5ac17fdd6 |
children | da88e2cd5c53 |
line wrap: on
line source
Notes on keeping GAIM OS independant ------------------------------------ General ------- - Use G_DIR_SEPARATOR_S and G_DIR_SEPARATOR for paths - Use g_getenv, g_snprintf, g_vsnprintf - Use gaim_home_dir instead of g_get_home_dir or g_getenv("HOME") - Make sure when including win32dep.h that it is the last header to be included. - Open binary files when reading or writing with 'b' mode. e.g: fopen("somefile", "wb"); Not doing so will open files in windows using defaut translation mode. i.e. newline -> <CR><LF> Paths ----- - DATADIR, LOCALEDIR & LIBDIR are defined in wingaim as functions. Doing the following will therefore break the windows build: printf("File in DATADIR is: %s\n", DATADIR G_DIR_SEPARATOR_S "pic.png"); it should be: printf("File in DATADIR is: %s%s%s\n", DATADIR, G_DIR_SEPARATOR_S, "pic.png"); - When writing out paths to .gaimrc, use wgaim_escape_dirsep. This is necessary because the Windows dir separator '\' is being used to escape characters, when paths are read in from the .gaimrc file. PLUGINS & PROTOS ---------------- - G_MODULE_EXPORT all functions which are to be accessed from outside the scope of its "dll" or "so". (E.G. gaim_plugin_init) - G_MODULE_IMPORT all global variables which are located outside your dynamic library. (E.G. connections) (Not doing this will cause "Memory Access Violations" in Win32)