From: Sean E. <sea...@gm...> - 2006-09-21 17:32:31
|
On 9/21/06, nos...@us... <nos...@us...> wrote: > My gdk doesn't support writing gif files (do any of them?) and "jpeg" is the > required identifier for jpeg images, jpg just doesn't cut it. It supports writing .ico. Should we use that? The problem is that lots of people use icons with alpha, and we wind up removing that and giving them all black backgrounds. |
From: Sean E. <sea...@gm...> - 2006-12-07 19:24:23
|
On 12/7/06, ev...@us... <ev...@us...> wrote: > oscar_encoding_extract() is useful for a plugin or UI doing oscar prpl specific things, such as getting a contact's profile directly (rather than the full formatted info text sent to gaim_notify_userinfo()). Removed the static so it can be used elsewhere. As a rule, we generally don't like non-static functions in prpls other than plugin_init. When you say "used elsewhere." A much better approach would be an abstracted "get info" function that doesn't spawn UI. -s. |
From: Evan S. <ev...@dr...> - 2006-12-07 19:36:09
Attachments:
PGP.sig
|
On Dec 7, 2006, at 2:17 PM, Sean Egan wrote: >> oscar_encoding_extract() is useful for a plugin or UI doing oscar >> prpl specific things, such as getting a contact's profile directly >> (rather than the full formatted info text sent to >> gaim_notify_userinfo()). Removed the static so it can be used >> elsewhere. > > As a rule, we generally don't like non-static functions in prpls other > than plugin_init. When you say "used elsewhere." > Ah. I figured it was okay because many of the other functions in oscar.c are also non-static; for example, just below it is gchar * oscar_encoding_to_utf8(const char *encoding, const char *text, int textlen) > A much better approach would be an abstracted "get info" function that > doesn't spawn UI. The problem is not spawning of UI -- I'm actually using the notify_userinfo() callback which gtk gaim uses to spawn UI to be notified that the information is available and associate it with the contact. The problem is that I wanted direct access to the profile information without the full Screenname: someguy Warning Level: 0% Away message: yadda profile: blah string... What if rather than returning a string from the get info function, an array of objects were returned each of which specified a label and a string? The UI could then assemble the information in any way it wanted.... and a plugin (or picky UI) knowing what it's looking for could get specific information out easily. -Evan |
From: Ethan B. <ebl...@cs...> - 2006-12-08 00:52:32
|
Evan Schoenberg spake unto us the following wisdom: > On Dec 7, 2006, at 2:17 PM, Sean Egan wrote: > >As a rule, we generally don't like non-static functions in prpls other > >than plugin_init. When you say "used elsewhere." > > Ah. I figured it was okay because many of the other functions in =20 > oscar.c are also non-static; for example, just below it is > gchar * > oscar_encoding_to_utf8(const char *encoding, const char *text, int =20 > textlen) This is an artifact of the way C (and the standard Unix linker) works; in this case, what we *really* want is a function which is static in the scope of the prpl, not static in the scope of the compilation unit (oscar.o). However, we don't have that tool in our toolbox, so we simply make the function non-static and sort of don't refer to it outside of liboscar.so by convention. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Evan S. <ev...@dr...> - 2006-12-08 00:56:28
Attachments:
PGP.sig
|
On Dec 7, 2006, at 7:49 PM, Ethan Blanton wrote: > Evan Schoenberg spake unto us the following wisdom: >> On Dec 7, 2006, at 2:17 PM, Sean Egan wrote: >>> As a rule, we generally don't like non-static functions in prpls >>> other >>> than plugin_init. When you say "used elsewhere." >> >> Ah. I figured it was okay because many of the other functions in >> oscar.c are also non-static; for example, just below it is >> gchar * >> oscar_encoding_to_utf8(const char *encoding, const char *text, int >> textlen) > > This is an artifact of the way C (and the standard Unix linker) works; > in this case, what we *really* want is a function which is static in > the scope of the prpl, not static in the scope of the compilation unit > (oscar.o). However, we don't have that tool in our toolbox, so we > simply make the function non-static and sort of don't refer to it > outside of liboscar.so by convention. Thanks for the clarification -- that makes perfect sense. Sean's a fan of my suggestion at the end of my previous email: > What if rather than returning a string from the get info function, > an array of objects were returned each of which specified a label > and a string? The UI could then assemble the information in any > way it wanted.... and a plugin (or picky UI) knowing what it's > looking for could get specific information out easily. so if there aren't any objections, I'll do that when I have a chance, and I'll revert the removal of static at the same time. -Evan |
From: Allan C. <al...@ch...> - 2006-12-08 09:34:32
|
On 12/8/06, Ethan Blanton <ebl...@cs...> wrote: > Evan Schoenberg spake unto us the following wisdom: > > On Dec 7, 2006, at 2:17 PM, Sean Egan wrote: > > >As a rule, we generally don't like non-static functions in prpls other > > >than plugin_init. When you say "used elsewhere." > > > > Ah. I figured it was okay because many of the other functions in > > oscar.c are also non-static; for example, just below it is > > gchar * > > oscar_encoding_to_utf8(const char *encoding, const char *text, int > > textlen) > > This is an artifact of the way C (and the standard Unix linker) works; > in this case, what we *really* want is a function which is static in > the scope of the prpl, not static in the scope of the compilation unit > (oscar.o). However, we don't have that tool in our toolbox, so we > simply make the function non-static and sort of don't refer to it > outside of liboscar.so by convention. Possible to enforce this with .map files in linux, right? { global: plugin_init; local:*; } A single .map file can be used as: gcc -o ... -Wl,--version-script=../../gaim-prpl.map If so, it would ensure that the code stays clean for non-linux non-UNIX builds (ie Windows) that might not have this ability. Impossible to accidentally cheat Allan -- al...@ch... http://dr.chickenandporn.com/ |
From: Ethan B. <ebl...@cs...> - 2006-12-08 14:41:35
|
Allan Clark spake unto us the following wisdom: > On 12/8/06, Ethan Blanton <ebl...@cs...> wrote: > > This is an artifact of the way C (and the standard Unix linker) works; > > in this case, what we *really* want is a function which is static in > > the scope of the prpl, not static in the scope of the compilation unit > > (oscar.o). However, we don't have that tool in our toolbox, so we > > simply make the function non-static and sort of don't refer to it > > outside of liboscar.so by convention. >=20 > Possible to enforce this with .map files in linux, right? I should have been more clear; *most* systems have a way to work around this, but there isn't a *standard* way that works across many Unix platforms (that I'm aware of, anyway). In addition, Windows has a mechanism for dealing with this in .dll files, and I'm sure OSX has something for .dylib files. However, rather than engineering a solution for each platform we support (and, indeed, we don't even know what they all are!), the convention method has worked pretty well for us. ;-) Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Ethan B. <ebl...@cs...> - 2006-12-08 14:53:54
|
Ethan Blanton spake unto us the following wisdom: > I should have been more clear; *most* systems have a way to work > around this, but there isn't a *standard* way that works across many > Unix platforms (that I'm aware of, anyway). In addition, Windows has > a mechanism for dealing with this in .dll files, and I'm sure OSX has > something for .dylib files. However, rather than engineering a > solution for each platform we support (and, indeed, we don't even know > what they all are!), the convention method has worked pretty well for > us. ;-) I should note further that if, for example, there is a libtool solution for this which either Just Works on platforms with support or Doesn't Hurt Anything on platforms without, we should probably adopt it. I am not aware of such a thing, but I haven't looked. Generally speaking, as Allan pointed out, removing these things from the realm of accidental violation is a good idea. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Allan C. <al...@ch...> - 2006-12-08 17:19:11
|
On 12/8/06, Ethan Blanton <ebl...@cs...> wrote: > Allan Clark spake unto us the following wisdom: > > On 12/8/06, Ethan Blanton <ebl...@cs...> wrote: > > > This is an artifact of the way C (and the standard Unix linker) works; > > > in this case, what we *really* want is a function which is static in > > > the scope of the prpl, not static in the scope of the compilation unit > > > (oscar.o). However, we don't have that tool in our toolbox, so we > > > simply make the function non-static and sort of don't refer to it > > > outside of liboscar.so by convention. > > > > Possible to enforce this with .map files in linux, right? > > I should have been more clear; *most* systems have a way to work > around this, but there isn't a *standard* way that works across many > Unix platforms (that I'm aware of, anyway). In addition, Windows has > a mechanism for dealing with this in .dll files, and I'm sure OSX has > something for .dylib files. However, rather than engineering a > solution for each platform we support (and, indeed, we don't even know > what they all are!), the convention method has worked pretty well for > us. ;-) Yup, I understand. Thing is, if the XXX platform (Mac, Linux, Windows, another) flashes warning lights, and it's common code, the XXX-check indirectly checks the other non-XXX platforms... not so much need to do so, and (this is a problem normally with international corporations) not everyone always knows all the convention, has read 100% of the FAQ(s), and thinks to ask, but everyone uses the same code. ...if an error creeps in, the build finds it. Allan |
From: Evan S. <ev...@dr...> - 2006-12-08 22:09:05
Attachments:
PGP.sig
|
On Dec 7, 2006, at 7:56 PM, Evan Schoenberg wrote: > Sean's a fan of my suggestion at the end of my previous email: >> What if rather than returning a string from the get info function, >> an array of objects were returned each of which specified a label >> and a string? The UI could then assemble the information in any >> way it wanted.... and a plugin (or picky UI) knowing what it's >> looking for could get specific information out easily. I'm nearly done making the changes across all prpls... I'm happy with the results. notify.c will have an GaimNotifyUserInfo object and appropriate accessors for getting either (1) a textual representation of its contents (which will look pretty much exactly like the Get Info does on most protocols... except generated in a single place so that the formatting and spacing is guaranteed to be standardized and could be changed or presented differently easily) or (2) a GList of GaimNotifyUserInfoEntry objects. Each GaimNotifyUserInfoEntry currently has a label and a name - other properties, such as section_header, will be added before I'm done. Using (2), the UI can extract particular pieces of information, display the info in a two column table, completely ignore it and display random characters, or whatever else it wants to do. The result in prpls is nice, too; rather than appending ("<b>%s</b>: %s<br />"), _("label"), value to a string then passing it to the notify_user_info() function, they do: gaim_notify_user_info_add_pair(user_info, tag, value); to build up the user_info and then pass that along. Should tooltips work this way, as well? It'd mean that all the code can continue to share functions (as currently profile generation for many prpls calls the tooltip text function). It does mean that displaying a tooltip causes more object allocations and destructions than it did previously... the code duplication of doing otherwise, though, makes me a sad panda. Also, any thoughts or suggestions before I finish this up? -Evan |
From: Sean E. <sea...@gm...> - 2006-12-08 22:16:47
|
On 12/8/06, Evan Schoenberg <ev...@dr...> wrote: > to build up the user_info and then pass that along. That sounds great. I presume everything in this struct should be html by convention? > Should tooltips work this way, as well? It'd mean that all the code can > continue to share functions (as currently profile generation for many prpls > calls the tooltip text function). It does mean that displaying a tooltip > causes more object allocations and destructions than it did previously... > the code duplication of doing otherwise, though, makes me a sad panda. Yeah, that sounds like a good idea -s. |
From: Evan S. <ev...@dr...> - 2006-12-08 22:37:45
Attachments:
PGP.sig
|
On Dec 8, 2006, at 5:16 PM, Sean Egan wrote: > That sounds great. I presume everything in this struct should be html > by convention? Affirmative :) |
From: Sean E. <sea...@gm...> - 2006-12-08 22:45:40
|
On 12/8/06, Evan Schoenberg <ev...@dr...> wrote: > That sounds great. I presume everything in this struct should be html Out of curiousity, how does Adium use these? Does it know all the fields for each protocol, and parse them out that way? Are you planning to use the "section header" property to determine what goes where? Will there be standard, well-known, section headers so UI's don't need to special case anything? |
From: Evan S. <ev...@dr...> - 2006-12-09 21:23:18
Attachments:
PGP.sig
|
On Dec 8, 2006, at 5:45 PM, Sean Egan wrote: > On 12/8/06, Evan Schoenberg <ev...@dr...> wrote: >> That sounds great. I presume everything in this struct should be html > > Out of curiousity, how does Adium use these? Does it know all the > fields for each protocol, and parse them out that way? Are you > planning to use the "section header" property to determine what goes > where? Will there be standard, well-known, section headers so UI's > don't need to special case anything? It doesn't, yet, because parsing information out of a big block of text which could have any possible text was basically impossible and certainly not time-effective to implement. Off the top of my head, there are three things which will be advantageous for Adium with the new setup: 1) AIM profile information can be independently extracted without delving into oscar prpl internal structures - we want this on its own 2) prpls can now provide tooltip strings and have them displayed. Adium doesn't have an HTML-based tooltip which is formatted as <b>label</b>: value but rather provides label and value strings separately for the tooltip to be constructed. I can now ask an account for this information and get it back as an array of label- value pairs for display... and I can remove any pairs which aren't wanted. 3) Labels can now be translated by the UI, important since Adium can't use libgaim's .po files for translation. I'm confident that with this information available in a reasonably standardized way other potential uses -- such as perhaps populating a window's fields which present contact information in a non-block-of- text way -- will be found. Not all the prpls use 'sections', and I hadn't thought about having a standard set of headers... that would be nice to do, if for no other reason than to provide a consistent experience across prpls. -Evan |
From: Sean E. <sea...@gm...> - 2006-12-09 21:47:50
|
On 12/9/06, Evan Schoenberg <ev...@dr...> wrote: > 1) AIM profile information can be independently extracted without delving > into oscar prpl internal structures - we want this on its own Last I remember, Adium showed the "profile" part of an AIM info message in an HTML box, and the rest of it in above it in normal labels, and I'm assuming that behavior is the inspiration for this change. How will you decide what goes where in a protocol-independent way? -s. |
From: Luke S. <lsc...@us...> - 2006-12-20 21:00:16
|
On Wed, Dec 20, 2006 at 12:06:48PM -0800, ev...@us... wrote: > Revision: 18031 > http://svn.sourceforge.net/gaim/?rev=18031&view=rev > Author: evands > Date: 2006-12-20 12:06:47 -0800 (Wed, 20 Dec 2006) > > Log Message: > ----------- > * Improved gaim_plugin_oscar_decode_im_part()'s error message; "the buddy you are talking to" is awkward and wrong, and "the buddy to whom you are talking" is just silly. Use the buddy's screenname instead. > * Pass the screen name to gaim_plugin_oscar_decode_im_part() in incomingim_chan4() as is done elsewhere rather than passing "1" as the name. That error usually triggers for ICQ. The screenname in that case is a useless UIN. If we want to go this route, we should grab alias or server nick if available. luke |
From: Kevin M S. <ke...@si...> - 2006-09-21 17:43:36
Attachments:
signature.asc
|
Sean Egan wrote: > On 9/21/06, nos...@us... > <nos...@us...> wrote: >> My gdk doesn't support writing gif files (do any of them?) and "jpeg" = is the >> required identifier for jpeg images, jpg just doesn't cut it. >=20 > It supports writing .ico. Should we use that? The problem is that lots > of people use icons with alpha, and we wind up removing that and > giving them all black backgrounds. >=20 Seems to me we should prefer the gif format if it's available. Will it automatically fall back to jpeg if gif isn't available? If not, that might be nice. I wonder if the GDK code for ico supports high color icons or standard palleted transparency. Though ico does support support those things, not everything acknowledges them. Kevin |