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)