We tried a number of variations, and personally I found any of the two-
number variations (like [10(3)]) pretty noisy and jarring, so I
actually prefer the approach where there's just a single number (total
count when all read, or unread count if some unread).
If possible, I'd recommend implementing both, using the ClientFlags
system to control which gets used. The mechanism is pretty
straighforward: there are a bunch of files in client/util/
ClientFlags. Those files appear so uniform because they were actually
generated, but we were unable to open-source the generator, so they're
now just plain source. Most of the flags in those files are obsolete,
because they apply to Google Wave not Wave In A Box. Anyhow, using
ClientFlags means that the client can be configured using URL
parameters (e.g., acmewave.org/?threadCountStyle=minimal), so you
don't have to rebuild anything to try out both variants. In code, you
just use something like:
enum Style { FULL, MINIMAL, ALWAYS_TOTAL, ... } // Different
counting style options
private final static Style style;
static {
String styleStr = ClientFlags.get().threadCountStyle(); <-- this
is how you extract a flag value.
style = Style.valueOf(); <-- Need to catch exception and use a
default, etc.
}
...
-Dave
On Nov 24, 11:04 am, Michael MacFadden <[email protected]>
wrote:
> 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.
