I think you are correct, that we need something more clear. I think the "Total Visible (Total Visible Unread), e.g. 10 (4)" approach sounds like a good place to start. We can start there and see if that works. If not we can tweak it.
~Michael On Nov 22, 10:59 pm, David Wang <[email protected]> wrote: > On Tue, Nov 23, 2010 at 4:27 PM, Michael MacFadden < > > [email protected]> wrote: > > And yes, I saw the mock ups that got checked in. I started digging to > > see how I would figure out how many blips were there and what was read > > and non read. I traced the code and started debugging. That is when > > I ran in to this issue. > > > As a side comment, I couldn't tell from the mock ups if the number in > > toggle shows how many total sub blips, or the number of unread ones. > > I assume the total number of blips in the inline thread. Thanks. > > The current implementation we took is that when there are unread blips in > the sub tree from the inline reply, the number represents the number of > unread blips in the sub tree. When everything is read in the subtree, the > number is the total count of blips in the sub tree. > > Having said that I've personally always found that confusing. I would have > much preferred to always show the total number of blips always and maybe in > parenthesis the number of unread blips if any. > > What's your opinion on this? > > Kind Regards > > > > > > > > > > > > > ~Michael > > > On Nov 22, 9:22 pm, Michael MacFadden <[email protected]> > > wrote: > > > I actually switched the code back: > > > > What was this: > > > > // Either use fake backing, or create UDW. The latter is racy, but > > > usually what we want. > > > // TODO: restore lines below, after issue 154 has been fixed. See: > > > //http://code.google.com/p/wave-protocol/issues/detail?id=154 > > > // udw = getWave().createUserData(); > > > // supplement = WaveletBasedSupplement.create(udw); > > > // supplement = new PrimitiveSupplementImpl(); > > > > is now this in my local: > > > > // Either use fake backing, or create UDW. The latter is racy, but > > > usually what we want. > > > // TODO: restore lines below, after issue 154 has been fixed. See: > > > //http://code.google.com/p/wave-protocol/issues/detail?id=154 > > > udw = getWave().createUserData(); > > > supplement = WaveletBasedSupplement.create(udw); > > > // supplement = new PrimitiveSupplementImpl(); > > > > I remember the other bugs related to issue 154. Those don't seem to > > > be an issue when I switch back to the wavelet base supplement. > > > However, the operations on the wavelet (through the supplement) don't > > > seem to get synced down to the server. > > > > ~Michael > > > > On Nov 22, 4:24 pm, David Hearnden <[email protected]> wrote: > > > > > You're not barking up the wrong tree :) What's happening is as > > follows. > > > > > On any wave you open, a wavelet with just you as a participant gets > > > > created to track your user data (UDW). There was a period of > > > > indecision about whether the client or the server should create this > > > > wavelet (Google Wave does both, but there are unresolved race > > > > conditions). In Wave-in-a-box, we decided to go with client-created > > > > UDWs, but have not wired them up completely. The data structure that > > > > the UDW provides is exposed as an interface called > > > > PrimitiveSupplement. There is also a pojo implementation of that > > > > structure (PrimitiveSupplementImpl). > > > > > You jumped straight to the right place in the code. That logic there > > is saying: > > > > 1. If a UDW already exists (getWave().getUserData() != null), then > > > > build the supplement structure on it, exposing it as a > > > > PrimitiveSupplement. > > > > 2a. If a UDW does not exist, create one now, and then do 1. > > > > 2b. If a UDW does not exist, create a fake in-memory version of the > > > > data (PrimitiveSupplementImpl) and carry on. > > > > > 2a is what it should be, 2b is what it is currently. Last time we > > > > used 2a it exposed some other bugs in the client/server protocol. > > > > Those are fixed, so today I'll try again to switch from 2b to 2a so > > > > UDWs are used properly. > > > > The in-memory data structure is thrown away when you close a wave, so > > > > read/unread state currently exists while you have a wave open, but if > > > > you re-open that wave, even within the same client session, a new > > > > PrimitiveSupplementImpl is created. That explains the behaviour > > > > you're seeing regarding persistence of user state. > > > > > What is surprising though is that createUserData() is getting called. > > > > If that is occurring, then the UDW should be working, and > > > > getWave().getUserData() should be non-null. I'll investigate today. > > > > > In the meantime, did you see the blip counter HTML mocks I checked in? > > > > > -Dave > > > > > On Tue, Nov 23, 2010 at 10:07 AM, Michael MacFadden > > > > > <[email protected]> wrote: > > > > > All, > > > > > > I am looking into implementing the inline thread toggle which shows > > > > > how many blips are in the inline thread as well as an indication to > > > > > how many are read / not. > > > > > > To do this I believe we need working User Data Wavelets. I was > > taking > > > > > a look at where these are created when creating a new wave. Looks > > > > > like this is happening in the StageTwo class here (circa line 390): > > > > > > === > > > > > > protected ObservableSupplementedWave createSupplement() { > > > > > Wavelet udw = getWave().getUserData(); > > > > > ObservablePrimitiveSupplement supplement; > > > > > if (udw != null) { > > > > > supplement = WaveletBasedSupplement.create(udw); > > > > > } else { > > > > > // Either use fake backing, or create UDW. The latter is > > > > > racy, but usually what we want. > > > > > // TODO: restore lines below, after issue 154 has been fixed. > > > > > See: > > > > > //http://code.google.com/p/wave-protocol/issues/detail?id=154 > > > > > udw = getWave().createUserData(); > > > > > supplement = WaveletBasedSupplement.create(udw); > > > > > // supplement = new PrimitiveSupplementImpl(); > > > > > > } > > > > > return new LiveSupplementedWaveImpl( > > > > > supplement, getWave(), getSignedInUser(), > > > > > DefaultFollow.ALWAYS, getConversations()); > > > > > } > > > > > > === > > > > > > This line specifically "Wavelet udw = getWave().getUserData()" always > > > > > comes back null. This code seems to get executed when a wave is > > > > > loaded in to the client. It seems that: > > > > > > getWave().createUserData(); > > > > > > does get called and execute after clicking the "New Wave" button. If > > > > > you debug you will see that the wave now has a new wavelet for the > > > > > user data. But immediately after if you click on the wave again, the > > > > > getWave().getUserData() will return null. The wave no longer > > contains > > > > > the wavelet for the user data. Is the creation of the user data > > > > > wavelet only happening on the client side and not getting persisted > > to > > > > > there server? > > > > > > I think I need to get this working first, if I am barking up the > > wrong > > > > > tree let me know. > > > > > > Regards, > > > > > ~Michael > > > -- > > You received this message because you are subscribed to the Google Groups > > "Wave Protocol" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<wave-protocol%2bunsubscr...@goog > > legroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/wave-protocol?hl=en. > > -- > David Wang -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
