Am Sonntag, den 29.05.2005, 09:48 -0400 schrieb Nathan Conrad:
> On Sun, May 29, 2005 at 11:57:25AM +0200, Lars Lindner wrote:
> > I thought a while over the tray icon counter and
> > found some serious design problems we still have.
> > First some facts:
> > - We want to count newly downloaded items.
> > - We want to decrease the counter when newly downloaded
> > items are dropped due to feed cache limitations.
> > (This is the cause of the current tray icon counting error)
> > - We want to reset the counter on the first feed list action.
> > - We also want to issue these new items in the mini popup windows.
> > - We do not want to issue a newly downloaded item twice.
> > The problem: to realize this we use exactly one state,
> > a "newStatus" flag stored in the item structure. The design
> > problem is obvious: two different state machines with different
> > cycles trying to use the same state. This cannot work and is
> > poorly implemented (partly in the ui_tray_* interface and
> > partly with the item state).
> > My conclusions:
> > - Rewrite now to make it work with 1.0.
> > - Isolate both notification features
> > => two item states instead of one
> > - Change ui_tray_add_new(count) to something like
> > ui_tray_update(item) using state #1
> > - Keep ui_notification(feed) interface but change
> > implementation to using state #2
> What about have a call (something like
> notif_item_new(itemPtr)) that gets triggered when there is a new
> item. And then a call like notif_item_removed(itemPtr) that gets
> called when items are removed. And then a notif_item_old(itemPtr) that
> gets called when new items are read. These functions would call the
> proper functions in the popup and tray code. And these would not get
> called for vfolders. The actual notification code would decide what to
> do with these messages.
No problem we can do a add/remove pair for both interface,
is the same like checking the state in an update method called
upon state change. That they are not called for vfolders is
already implicit in the code by not setting the new flag for
vfolder item copies.
> > Further ideas:
> > - Rewrite of the item state setting interface. Instead
> > of having item_set_xxxx introduce an
> > item_set_state(ITEM_STATE_XXXX, value) interface. I think
> > this makes the code more readable and will not impact on
> > the current stability.
> I don't like this. How do you support having values that are integers
> and values that are strings?
I only though of collapsing the
methods into one. Anyway that is not very important.
More important is if the general idea of having two
independent states is the right way. If yes, I'll change
it that way.