<div>I may not be understanding this right, but what if the CollapsedEntry, when it got the signal, checked if it was actually going to have to change the jobject, and if it was already kept, it would just abort? This would quash the signal the second time around - one step more than strictly necessary/ideal, but I don't know how to convince gtk not to send the signal if it was already pressed, which is what would be necessary to quash it exactly the first time.</div> <div> </div> <div>Either that or on this step:</div> <div> </div> <div>and updates the entry as required.  This includes setting the keep property </div> <div> </div> <div>you check the keep property before you set it, and do not touch it if you are not going to change it.  </div> <div>On 4/24/08, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hello, my name is Eben Eliason, and I have a problem... Symptom: The keep buttons in the Journal (the stars) take 1 second or so between being clicked and visually reflecting that change.  This is, admittedly, a rather minor problem, but as you'll see, it spells out a larger underlying ugliness.  I expect the feedback to be instant both because it's better that way, and also because the identical (well, nearly so, as shown below) favorite icons used in the list view of the new Home already function perfectly, and quickly. Diagnosis: Upon inspection, the KeepIcon class used in the Journal differs from the FavoriteIcon class used in Home in one crucial way. The former does not connect to a button-release-event at all, and instead depends on the code which uses it to do so for it, take the necessary actions based on the toggle, and then tell the KeepIcon itself that it has been clicked on in order to update its internal state and reflect that with visual changes.  This is obviously the incorrect approach to the problem, as the KeepIcon should abide by all the wonderful properties that makes object oriented programming useful, manage its internal state so that, if nothing else, it remains consistent when clicked (it's basically a checkbox....a boolean toggle), and notify anything that may happen to care about its value when it changes. Treatment: Take the object oriented approach above, which works nicely in Home, and should also work nicely in the Journal.  This cleans up the code, and allows the KeepIcon to update its internal state immediately before emitting the signal, thus redrawing before anything which wishes to be notified of its state has a chance to waste lots of time, slowing feedback. Side-effects: This is where things get ugly.  The above changes were trivial, but they create an ugly signal loop which makes the treatment worthless in its purest state as described above.  Here's what goes down: When a KeepIcon is clicked, its button-release-event handler updates its internal state, including its keep property, which thus emits a notify::keep signal.  The CollapsedEntry object which contains the KeepIcon connects to this signal in order to update the value of the keep key in the metadata of the associated JObject.  So far so good. The DS then emits an updated signal, which includes a reference to the JObject which has been updated.  Off in Never-Never-Land, query.py is listening for the update signal from the DS, and the handler for this signal replaces the JObject in its internal dict, and then emits its own modified signal.  The listview.py connects to the modified signal, and its handler then calls self._do_scroll, which in turn calls self._refresh_view.  The latter of these functions takes it upon itself to loop over all of the CollapsedEntry objects visible on screen, updating a match for the changed JObject by setting its corresponding jobject property.  The method responsible for handling the setting of this jobject property within the CollapsedEntry then reads all of the info out of the newly passed JObject, and updates the entry as required.  This includes setting the keep property of the KeepIcon within the entry, which cannot assume that it has previously been set, since this is also the function that gets called to initialize the CollapsedEntry in the first place.  This, of course, triggers the do_set_property of the KeepIcon, which in turn emits a notify::keep signal. Hooray. Treatment of side-effects: Anyone know the best way to handle this issue?  I'm fairly convinced that the fundamental changes to the KeepIcon class suggested above are the correct approach logically and semantically.  I'm unsure about the correct way to sever the recursive loop, however.  Any thoughts are very much appreciated, since I've now spent considerable time messing with an issue that I thought would have a 10 minute fix. - Eben PS.  Thanks for listening! _______________________________________________ Sugar mailing list <a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a> <a href="http://lists.laptop.org/listinfo/sugar">http://lists.laptop.org/listinfo/sugar</a> </blockquote></div>