From: Evan S. <ev...@dr...> - 2006-12-08 22:09:05
|
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 |