My favorites | Sign in
Logo
                
Details: Show all Hide all

Today

  • 15 hours ago
    issue 49 (how to translate the program?) commented on by russel.omua   -   want translate to Russian. if you can send to me *.po file please. <russel.omua(at)gmail.com>
    want translate to Russian. if you can send to me *.po file please. <russel.omua(at)gmail.com>

Yesterday

  • 38 hours ago
    issue 49 (how to translate the program?) changed by geekysuavo   -  
    Owner: geekysuavo
    Labels: Type-Enhancement Priority-Low OpSys-Linux Component-UI Usability
    Owner: geekysuavo
    Labels: Type-Enhancement Priority-Low OpSys-Linux Component-UI Usability
  • 38 hours ago
    issue 49 (how to translate the program?) commented on by geekysuavo   -   ok, what language? the notifier is pretty much set up to use gettext, so i would look over the *.po file syntax for that as well as the gnome localization guide. ~ brad.
    ok, what language? the notifier is pretty much set up to use gettext, so i would look over the *.po file syntax for that as well as the gnome localization guide. ~ brad.
  • 39 hours ago
    issue 49 (how to translate the program?) reported by russel.omua   -   i want to localize the program. do you have some language API ??
    i want to localize the program. do you have some language API ??

Last 30 days

  • Dec 08, 2009
    issue 46 ([Feature Request]: monitoring gmail labels too) Status changed by geekysuavo   -   after thinking seriously about this feature, i've decided it's a non-starter. my reasons: 1. the notifier monitors new mail in your _inbox_. i use filters to automatically label my messages without moving them out of my inbox, and then i can archive what i want later. works fine. 2. adding this capability would mean using another source entirely for inbox information, instead of the atom feed google so generously provides already. 3. the notifier is a simple notifier, not a mail client, so there is not enough justification at this point for implementing (2) in the sake of staying compatible with odd filter settings. sorry, but it's outside the scope of the project. :( i'm changing this issue's status to 'wontfix'. ~ brad.
    Status: WontFix
    after thinking seriously about this feature, i've decided it's a non-starter. my reasons: 1. the notifier monitors new mail in your _inbox_. i use filters to automatically label my messages without moving them out of my inbox, and then i can archive what i want later. works fine. 2. adding this capability would mean using another source entirely for inbox information, instead of the atom feed google so generously provides already. 3. the notifier is a simple notifier, not a mail client, so there is not enough justification at this point for implementing (2) in the sake of staying compatible with odd filter settings. sorry, but it's outside the scope of the project. :( i'm changing this issue's status to 'wontfix'. ~ brad.
    Status: WontFix
  • Dec 08, 2009
    issue 47 (The subject and sender address should be shown on alert) changed by geekysuavo   -   as finals weeks lend themselves to conceptual thinking more than programming, i hashed out what i think should be the new GgnAccount behavior: IDEA: differentiate between unread and new messages. 1.) upon first check, all unread are new. 2.) upon subsequent checks, compare in-memory entry array with the atom feed entries. a.) exists only in array (read) => remove. b.) exists in both locations (unread, old) => keep and unflag. c.) exists only in atom feed (unread, new) => add and flag as new. from here, the GgnAccountList relays both unread and new message counts up the chain of command to the GgnManager, where the display logic takes place. the question here is: how many new messages should be displayed in sender/subject format until the notifier should just default to showing the number of new messages? is three a charm? any longer than 5 messages * 5 seconds and we're getting a bit ridiculous, considering the check rate is minimally 1 minute. _what do you guys think?_ ~ brad.
    Status: Accepted
    Labels: Priority-Medium Component-Logic Priority-Low
    as finals weeks lend themselves to conceptual thinking more than programming, i hashed out what i think should be the new GgnAccount behavior: IDEA: differentiate between unread and new messages. 1.) upon first check, all unread are new. 2.) upon subsequent checks, compare in-memory entry array with the atom feed entries. a.) exists only in array (read) => remove. b.) exists in both locations (unread, old) => keep and unflag. c.) exists only in atom feed (unread, new) => add and flag as new. from here, the GgnAccountList relays both unread and new message counts up the chain of command to the GgnManager, where the display logic takes place. the question here is: how many new messages should be displayed in sender/subject format until the notifier should just default to showing the number of new messages? is three a charm? any longer than 5 messages * 5 seconds and we're getting a bit ridiculous, considering the check rate is minimally 1 minute. _what do you guys think?_ ~ brad.
    Status: Accepted
    Labels: Priority-Medium Component-Logic Priority-Low
  • Dec 05, 2009
    issue 48 (gnome-gmail-notifier never recovers from an error when launc...) changed by geekysuavo   -   the latest release still does this, as it uses libsoup-2.2, the source of the anomalous behavior. the ggn-20090606 branch of the notifier in the googlecode subversion fixes this issue. also, the upcoming release version will also be fixed with regards to this issue. thanks, ~ brad.
    Status: Fixed
    Owner: geekysuavo
    Cc: shiny.nickel
    Labels: Type-Defect Priority-Low OpSys-Linux Component-Logic Performance Usability
    the latest release still does this, as it uses libsoup-2.2, the source of the anomalous behavior. the ggn-20090606 branch of the notifier in the googlecode subversion fixes this issue. also, the upcoming release version will also be fixed with regards to this issue. thanks, ~ brad.
    Status: Fixed
    Owner: geekysuavo
    Cc: shiny.nickel
    Labels: Type-Defect Priority-Low OpSys-Linux Component-Logic Performance Usability
  • Dec 05, 2009
    issue 48 (gnome-gmail-notifier never recovers from an error when launc...) reported by Monica.VillanuevaiMateu   -   What steps will reproduce the problem? 1. Launch gnome-gmail-notifier on login by inserting it in Gnomes "startup applications". 2. gnome-gmail-notifier tries to connect before the wifi connection is established. This results in an error. 3. After the wifi connect is established, this error persists, i.e. waiting or right clicking on the icon and choosing 'Check Mail' still results in an error. Expected behavior: Once the connection is there a recheck (after time interval or by right-click) should work (say new mail/ no new mail). Instead: The error persists, hovering over the icon with the mouse says "Unable to check mail", right click and choosing "Check mail" does nothing. What version of the product are you using? On what operating system? Version: 0.9.4 (Karmic repositories), OS: Ubuntu Karmic 9.10 amd64 Computer: Lenovo Thinkpad T60, Intel wireless card Please provide any additional information below. - Quitting and restarting the application resolves this problem. - waiting upon login until wifi is up (e.g. calling gnome-gmail-notifier with a script) remedies this issue - error also occurs when the wifi is down (disabled) when gnome-gmail-notifier is launched and the connection is established afterwards. - the error does not occur when a wifi connection was previously established, is lost and is reestablished.
    What steps will reproduce the problem? 1. Launch gnome-gmail-notifier on login by inserting it in Gnomes "startup applications". 2. gnome-gmail-notifier tries to connect before the wifi connection is established. This results in an error. 3. After the wifi connect is established, this error persists, i.e. waiting or right clicking on the icon and choosing 'Check Mail' still results in an error. Expected behavior: Once the connection is there a recheck (after time interval or by right-click) should work (say new mail/ no new mail). Instead: The error persists, hovering over the icon with the mouse says "Unable to check mail", right click and choosing "Check mail" does nothing. What version of the product are you using? On what operating system? Version: 0.9.4 (Karmic repositories), OS: Ubuntu Karmic 9.10 amd64 Computer: Lenovo Thinkpad T60, Intel wireless card Please provide any additional information below. - Quitting and restarting the application resolves this problem. - waiting upon login until wifi is up (e.g. calling gnome-gmail-notifier with a script) remedies this issue - error also occurs when the wifi is down (disabled) when gnome-gmail-notifier is launched and the connection is established afterwards. - the error does not occur when a wifi connection was previously established, is lost and is reestablished.

Earlier this year

  • Nov 08, 2009
    issue 47 (The subject and sender address should be shown on alert) commented on by geekysuavo   -   again, i will look into the feasibility of adding this into a future release version. your patience is appreciated, and attachments of patches instead of screenshots are always welcome. ~ brad.
    again, i will look into the feasibility of adding this into a future release version. your patience is appreciated, and attachments of patches instead of screenshots are always welcome. ~ brad.
  • Nov 08, 2009
    issue 47 (The subject and sender address should be shown on alert) commented on by kurtkraut   -   I'm not expecting a notify of 256 unread messages. On the first run, a notifier should tell me the amount of unread messages indeed. But the new messages that just arrived while the notifier is already running should be alerted with sender address, subject and even a excerpt of the first line. This is exactly how other mail notification programs behave.
    I'm not expecting a notify of 256 unread messages. On the first run, a notifier should tell me the amount of unread messages indeed. But the new messages that just arrived while the notifier is already running should be alerted with sender address, subject and even a excerpt of the first line. This is exactly how other mail notification programs behave.
  • Nov 08, 2009
    issue 46 ([Feature Request]: monitoring gmail labels too) changed by geekysuavo   -   i'll look into it. ~ brad.
    Owner: geekysuavo
    Labels: Type-Enhancement Priority-Low OpSys-Linux Component-Logic Usability
    i'll look into it. ~ brad.
    Owner: geekysuavo
    Labels: Type-Enhancement Priority-Low OpSys-Linux Component-Logic Usability
  • Nov 08, 2009
    issue 47 (The subject and sender address should be shown on alert) changed by geekysuavo   -   i will look into adding this to the next release of the notifier. if i may ask, on a practical note, how would you expect the notifier to tell you the sender and subject of your 256 unread messages in a manner that is as pithy as the way in which it does so currently? my second question, perhaps more to the point: do you READ your emails? ~ brad.
    Owner: geekysuavo
    Labels: Type-Enhancement Priority-Low OpSys-Linux Component-UI Usability
    i will look into adding this to the next release of the notifier. if i may ask, on a practical note, how would you expect the notifier to tell you the sender and subject of your 256 unread messages in a manner that is as pithy as the way in which it does so currently? my second question, perhaps more to the point: do you READ your emails? ~ brad.
    Owner: geekysuavo
    Labels: Type-Enhancement Priority-Low OpSys-Linux Component-UI Usability
  • Nov 08, 2009
    issue 47 (The subject and sender address should be shown on alert) reported by kurtkraut   -   I'm using gnome-gmail-notifier on Ubuntu 9.10 (Karmic). Unfortunately, the alerts provided by this software only shows the total number of unread e-mail I have. If a new e-mail arrives, it only shows that the amount of unread e-mail increased. I cannot understand how a notification system could be really useful by only giving a number. I'd like to be alerted on WHAT I've just received by e-mail and not HOW MANY pending e-mails I have. What I expect from a e-mail notifier is an desktop alert showing the new e-mail subject and the sender address. I'd like to request it as a feature for gnome-gmail-notifier.
    I'm using gnome-gmail-notifier on Ubuntu 9.10 (Karmic). Unfortunately, the alerts provided by this software only shows the total number of unread e-mail I have. If a new e-mail arrives, it only shows that the amount of unread e-mail increased. I cannot understand how a notification system could be really useful by only giving a number. I'd like to be alerted on WHAT I've just received by e-mail and not HOW MANY pending e-mails I have. What I expect from a e-mail notifier is an desktop alert showing the new e-mail subject and the sender address. I'd like to request it as a feature for gnome-gmail-notifier.
  • Nov 08, 2009
    issue 37 (Change email server) commented on by kurtkraut   -   I also have kurtkraut.net domain e-mail handled by Gmail (Google Apps) and I'm seeking for a e-mail notification program that could give me alerts.
    I also have kurtkraut.net domain e-mail handled by Gmail (Google Apps) and I'm seeking for a e-mail notification program that could give me alerts.
  • Nov 04, 2009
    issue 37 (Change email server) commented on by poajex   -   hello, i just hope being able to use this app with Google Apps own domains. GNOME doesn't seem to have nice Gmail gadgets but this app ;)
    hello, i just hope being able to use this app with Google Apps own domains. GNOME doesn't seem to have nice Gmail gadgets but this app ;)
  • Oct 31, 2009
    issue 46 ([Feature Request]: monitoring gmail labels too) reported by jelmorini   -   GMail works well with labels that act like folders. I can create a filter that move incoming messages directly to one label instead of keep the message in the Inbox folder. There is a problem with gnome-gmail-notifier: it monitor only the Inbox folder and not other existing labels. Perhaps the solution can be a list of labels per gmail account where the user can check the labels he want to monitor.
    GMail works well with labels that act like folders. I can create a filter that move incoming messages directly to one label instead of keep the message in the Inbox folder. There is a problem with gnome-gmail-notifier: it monitor only the Inbox folder and not other existing labels. Perhaps the solution can be a list of labels per gmail account where the user can check the labels he want to monitor.
  • Oct 26, 2009
    r233 ([broken] added GgnPrefsWindow header.) committed by geekysuavo   -   [broken] added GgnPrefsWindow header.
    [broken] added GgnPrefsWindow header.
  • Oct 26, 2009
    r232 ([broken] addition of GgnPrefsWindowPriv, really broken.) committed by geekysuavo   -   [broken] addition of GgnPrefsWindowPriv, really broken.
    [broken] addition of GgnPrefsWindowPriv, really broken.
  • Oct 26, 2009
    r231 ([broken] cosmetic changes to enum tab-spacing.) committed by geekysuavo   -   [broken] cosmetic changes to enum tab-spacing.
    [broken] cosmetic changes to enum tab-spacing.
  • Oct 26, 2009
    r230 ([broken] manager callbacks for the icon actions.) committed by geekysuavo   -   [broken] manager callbacks for the icon actions.
    [broken] manager callbacks for the icon actions.
  • Oct 26, 2009
    issue 41 (how much spaghetti code is too much? (notifier rewrite discu...) commented on by geekysuavo   -   ok revision 229 has complete GgnAccountList support, as well as a bit of integration into the GgnManager object built in. i'll start work on the GgnPrefsWindow soon. ~ brad.
    ok revision 229 has complete GgnAccountList support, as well as a bit of integration into the GgnManager object built in. i'll start work on the GgnPrefsWindow soon. ~ brad.
  • Oct 26, 2009
    r229 ([broken] addition of ggn_account_list_del(), works.) committed by geekysuavo   -   [broken] addition of ggn_account_list_del(), works.
    [broken] addition of ggn_account_list_del(), works.
  • Oct 26, 2009
    About (About Gnome Gmail Notifier) Wiki page edited by geekysuavo   -   Revision r228 Edited wiki page through web user interface.
    Revision r228 Edited wiki page through web user interface.
  • Oct 26, 2009
    issue 27 (Act as Default Mail Reader) commented on by geekysuavo   -   ok, this issue has a home at the wiki section of google code as well, and integration into the rewrite is imminent, once work on the GgnManager starts. the gconf setting accessed by the GgnPrefs object (GGN_PREF_ACCOUNT_DEFAULT) has been integrated in already, and is managed alongside the other account properties, so all that is required is linking this into the GUI and checking our argv[][] on startup. i'll have it in svn soon. ~ brad.
    ok, this issue has a home at the wiki section of google code as well, and integration into the rewrite is imminent, once work on the GgnManager starts. the gconf setting accessed by the GgnPrefs object (GGN_PREF_ACCOUNT_DEFAULT) has been integrated in already, and is managed alongside the other account properties, so all that is required is linking this into the GUI and checking our argv[][] on startup. i'll have it in svn soon. ~ brad.
  • Oct 25, 2009
    issue 41 (how much spaghetti code is too much? (notifier rewrite discu...) commented on by geekysuavo   -   well, ten commits later and i'm still working on getting the GgnAccountList functional. really i just need to implement ggn_account_list_del() and that object should be good. i went back and tested all the previously untested code additions i made up to this point, and they work now (after some minor fixes). i've also added bits and peices of functionality and substance to the GgnManager as i've gone, and i'd have to say i'm really happy with the new way accounts are managed. it's really going to seem like effortless, seamless magic when contrasted to the crap i had written previously. the next obvious step will be to write the GgnPrefsWindow and to then tie all the bits of code together in a meaningful way through the GgnManager. ~ brad.
    well, ten commits later and i'm still working on getting the GgnAccountList functional. really i just need to implement ggn_account_list_del() and that object should be good. i went back and tested all the previously untested code additions i made up to this point, and they work now (after some minor fixes). i've also added bits and peices of functionality and substance to the GgnManager as i've gone, and i'd have to say i'm really happy with the new way accounts are managed. it's really going to seem like effortless, seamless magic when contrasted to the crap i had written previously. the next obvious step will be to write the GgnPrefsWindow and to then tie all the bits of code together in a meaningful way through the GgnManager. ~ brad.
  • Oct 25, 2009
    r227 ([broken] fix of hosted account check login difference.) committed by geekysuavo   -   [broken] fix of hosted account check login difference.
    [broken] fix of hosted account check login difference.
  • Oct 25, 2009
    r226 ([broken] further untested GgnAccountList additions.) committed by geekysuavo   -   [broken] further untested GgnAccountList additions.
    [broken] further untested GgnAccountList additions.
  • Oct 25, 2009
    r225 ([broken] use of GgnAccount private functions for GgnAccountL...) committed by geekysuavo   -   [broken] use of GgnAccount private functions for GgnAccountList.
    [broken] use of GgnAccount private functions for GgnAccountList.
  • Oct 25, 2009
    r224 ([broken] untested addition of ggn_account_list_account_updat...) committed by geekysuavo   -   [broken] untested addition of ggn_account_list_account_updated().
    [broken] untested addition of ggn_account_list_account_updated().
  • Oct 25, 2009
    r223 ([broken] minor change to Makefile.am) committed by geekysuavo   -   [broken] minor change to Makefile.am
    [broken] minor change to Makefile.am
  • Oct 25, 2009
    r222 ([broken] added selectivity in ggn_account_list_check() for e...) committed by geekysuavo   -   [broken] added selectivity in ggn_account_list_check() for enabled accounts only.
    [broken] added selectivity in ggn_account_list_check() for enabled accounts only.
  • Oct 25, 2009
    r221 ([broken] quick add of ggn_account_list_check(), should test.) committed by geekysuavo   -   [broken] quick add of ggn_account_list_check(), should test.
    [broken] quick add of ggn_account_list_check(), should test.
  • Oct 25, 2009
    r220 ([broken] allocation/free routines for GgnManager.) committed by geekysuavo   -   [broken] allocation/free routines for GgnManager.
    [broken] allocation/free routines for GgnManager.
  • Oct 25, 2009
    r219 ([broken] partial GgnAccountList code addition.) committed by geekysuavo   -   [broken] partial GgnAccountList code addition.
    [broken] partial GgnAccountList code addition.
  • Oct 24, 2009
    r218 ([broken] addition of ggn_account_new_from_prefs()) committed by geekysuavo   -   [broken] addition of ggn_account_new_from_prefs()
    [broken] addition of ggn_account_new_from_prefs()
  • Oct 24, 2009
    issue 41 (how much spaghetti code is too much? (notifier rewrite discu...) commented on by geekysuavo   -   ok, revision 216 and 217 both incorporate the essentially complete GgnAccount object, but inbox/compose browser open functions still require the user to retype their password. i think i'll close the issue regarding the "open correct inbox" and open a "have to retype password" issue once the release version is out. other than the above, it seems like the rest of the account object functionality is spot-on. preferences are automatically updated behind the scenes, without any explicit calls to ggn_prefs*(), and email checking is much simpler: ggn_account_check() is called on the account, a "checked" or "failed" callback is received, and a for() loop is made through the GgnEntry objects the account holds. i'm moving on to GgnAccountList, which is where the real magic regarding accounts will take place, but keep in mind the GALX issue still persists. the modified notes file is attached. ~ brad.
    ok, revision 216 and 217 both incorporate the essentially complete GgnAccount object, but inbox/compose browser open functions still require the user to retype their password. i think i'll close the issue regarding the "open correct inbox" and open a "have to retype password" issue once the release version is out. other than the above, it seems like the rest of the account object functionality is spot-on. preferences are automatically updated behind the scenes, without any explicit calls to ggn_prefs*(), and email checking is much simpler: ggn_account_check() is called on the account, a "checked" or "failed" callback is received, and a for() loop is made through the GgnEntry objects the account holds. i'm moving on to GgnAccountList, which is where the real magic regarding accounts will take place, but keep in mind the GALX issue still persists. the modified notes file is attached. ~ brad.
  • Oct 24, 2009
    r217 ([broken] addition of some GgnAccountList code elements, comp...) committed by geekysuavo   -   [broken] addition of some GgnAccountList code elements, completely incomplete.
    [broken] addition of some GgnAccountList code elements, completely incomplete.
  • Oct 24, 2009
    r216 ([broken] mostly final GgnAccount code additions.) committed by geekysuavo   -   [broken] mostly final GgnAccount code additions.
    [broken] mostly final GgnAccount code additions.
  • Oct 22, 2009
    issue 37 (Change email server) commented on by geekysuavo   -   ok, it seems like there is a ServiceLogin page which sets the GALX cookie, but it returns a different GALX value for the notifier than the cookie the browser is using... anybody? ~ brad.
    ok, it seems like there is a ServiceLogin page which sets the GALX cookie, but it returns a different GALX value for the notifier than the cookie the browser is using... anybody? ~ brad.
  • Oct 22, 2009
    issue 37 (Change email server) commented on by geekysuavo   -   Issue 45 has been merged into this issue.
    Issue 45 has been merged into this issue.
  • Oct 22, 2009
    issue 45 (choose which mail account to open on icon click, support goo...) changed by geekysuavo   -   this is a pre-existing issue. see issue 37. i do need some help to fix this one. anybody up for figuring out how to get around the google login GALX cookie thingie? ~ brad.
    Status: Duplicate
    Owner: geekysuavo
    this is a pre-existing issue. see issue 37. i do need some help to fix this one. anybody up for figuring out how to get around the google login GALX cookie thingie? ~ brad.
    Status: Duplicate
    Owner: geekysuavo
  • Oct 22, 2009
    issue 45 (choose which mail account to open on icon click, support goo...) reported by deignacio   -   if you have two google email accounts: *foobar@gmail.com *me@foobar.com i'd like to be able to determine which account has new mail and if it is a gmail domain, open http://mail.google.com/mail/, however if me@foobar.com had new mail, open http://mail.google.com/a/foobar.com/ or perhaps on click if multiple domains are given (regardless of new mail status) give a drop down to select which target to open.
    if you have two google email accounts: *foobar@gmail.com *me@foobar.com i'd like to be able to determine which account has new mail and if it is a gmail domain, open http://mail.google.com/mail/, however if me@foobar.com had new mail, open http://mail.google.com/a/foobar.com/ or perhaps on click if multiple domains are given (regardless of new mail status) give a drop down to select which target to open.
  • Oct 22, 2009
    issue 44 (Launch while wireless network is connecting) changed by geekysuavo   -   this is a duplicate bug. see issue 16 .
    Status: Duplicate
    Owner: geekysuavo
    this is a duplicate bug. see issue 16 .
    Status: Duplicate
    Owner: geekysuavo
  • Oct 22, 2009
    issue 16 (status locked in "unable to check mail") commented on by geekysuavo   -   Issue 44 has been merged into this issue.
    Issue 44 has been merged into this issue.
  • Oct 21, 2009
    issue 44 (Launch while wireless network is connecting) commented on by kill.krt   -   Ouch!!! I've forgotten to say one important thing! Thank you!!!
    Ouch!!! I've forgotten to say one important thing! Thank you!!!
  • Oct 21, 2009
    issue 44 (Launch while wireless network is connecting) reported by kill.krt   -   It seems that if the applet is started while wireless network is connecting the applet always fails to access to the mail account, even after the connection has been correctly established. The work-around is to close the applet and restart it. To generate this issue I've included the applet in the "Startup Applications" list of Ubuntu. Technical Details: gnome-gmail-notifier v0.9.4. Kernel: 2.6.31-14-generic (32bit) Distribution: Ubuntu 9.10 Beta I've "used" only official repositories
    It seems that if the applet is started while wireless network is connecting the applet always fails to access to the mail account, even after the connection has been correctly established. The work-around is to close the applet and restart it. To generate this issue I've included the applet in the "Startup Applications" list of Ubuntu. Technical Details: gnome-gmail-notifier v0.9.4. Kernel: 2.6.31-14-generic (32bit) Distribution: Ubuntu 9.10 Beta I've "used" only official repositories
  • Oct 12, 2009
    issue 41 (how much spaghetti code is too much? (notifier rewrite discu...) commented on by geekysuavo   -   i've started writing the GgnAccount object, which has gone pretty much according to its planned course, except the inbox and compose browser launching functions don't work due to issue 37. i also still need to finish (AND TEST!) the mail-checking functionality, as well as an in-depth memory and logic analysis of the feed parsing and message entry storage behavior, to ensure that nothing is leaking. the GgnAccount is a *CRITICAL* section of code for plugging leaks, as i can imagine many could arise from here. more to come, ~ brad.
    i've started writing the GgnAccount object, which has gone pretty much according to its planned course, except the inbox and compose browser launching functions don't work due to issue 37. i also still need to finish (AND TEST!) the mail-checking functionality, as well as an in-depth memory and logic analysis of the feed parsing and message entry storage behavior, to ensure that nothing is leaking. the GgnAccount is a *CRITICAL* section of code for plugging leaks, as i can imagine many could arise from here. more to come, ~ brad.
  • Oct 12, 2009
    r215 ([broken] addition of more GgnAccount code, still nonfunction...) committed by geekysuavo   -   [broken] addition of more GgnAccount code, still nonfunctional for now
    [broken] addition of more GgnAccount code, still nonfunctional for now
  • Oct 12, 2009
    r214 ([No log message]) committed by geekysuavo   -   [No log message]
    [No log message]
  • Oct 12, 2009
    issue 37 (Change email server) commented on by patricio...@ic.uach.cl   -   Hi, Sorry I was hidden 4 a while My best skills aren't in web programing or some in relations with emails server or security or some thing else. So. googling I found this web http://gist.github.com/ raw/87550/507191572f0f9ce5365e7e0c5fb74ef4e7834779/x. (HTH) btw I can contact with the manager to my domain and create a temporally account to extract info. thnks,
    Hi, Sorry I was hidden 4 a while My best skills aren't in web programing or some in relations with emails server or security or some thing else. So. googling I found this web http://gist.github.com/ raw/87550/507191572f0f9ce5365e7e0c5fb74ef4e7834779/x. (HTH) btw I can contact with the manager to my domain and create a temporally account to extract info. thnks,
 
Hosted by Google Code