Implement tickmark indicator showing message state

[timsueberkrueb]

What do you think about this design? It mainly shows up if you are sending an image (and x messages after the image :)).

[StuntsPT]

Looks good to me. How does it stack up with the touch-keyboard?

[timsueberkrueb]

@StuntsPT It's above the bottom panel with the text field. I just got the advice that I should use the tickmarks like in Telegram/WhatsApp. This would be then just used for messages that take very long or maybe not at all?

[StuntsPT]

@tim-sueberkrueb thanks! I don't know about the arrows, it doesn't make much difference to me. But when stacked up with the keyboard, it seems to be taking up a lot of "real estate", even though it's sort of transparent. Maybe it could be placed somewhere else? Would it be possible to put it next to the (i) and the "+"? In there, maybe a fading green arrow would make sense. If that's not possible, maybe placing it on the top edge would clutter the screen less, as it will be covering up "older" messages, which you are less likely to be paying attention to (which sort of works around the problem). Just my opinion. _-)

[timsueberkrueb]

@StuntsPT sorry, meant tickmarks at the messages not an arrow. That'd be an option as well though.

[timsueberkrueb]

Like this:

[StuntsPT]

That would be far less intrusive. Especially if after sending there is a "sending" animation, that then gets turned into a tickmark after success. You could further "enhance" the process by fading the tickmark away after a few seconds (since google hangouts doesn't have that) or leaving a red X in case of failure which would remain there and not fade away. Thoughts?

[bittner]

+1 for the tickmark. Can stay there (who cares about Google?!).

The "I'm currently working" animation next to the (i) in addition could be nice too. As a general indicator of the state of the application (not a specific message).

[timsueberkrueb]

@tdryer Is it possible to get something like latest_read_timestamp for specific users? I searched for it but couldn't find anything. It seems like myconv._conversation holds only 0 as timestamp in read_state or am I wrong? Otherwise I can only mark notifications as read when a watermark_notification occurs ...

conversation_id {
  id: "someid"
}
type: CONVERSATION_TYPE_ONE_TO_ONE
self_conversation_state {
  self_read_state {
    participant_id {
      gaia_id: "106125894943795709448"
      chat_id: "106125894943795709448"
    }
    latest_read_timestamp: 1420370479351225           <--- my read timestamp, right?
  }
  status: CONVERSATION_STATUS_ACTIVE
  notification_level: NOTIFICATION_LEVEL_RING
  view: CONVERSATION_VIEW_INBOX
  inviter_id {
    gaia_id: "106125894943795709448"
    chat_id: "106125894943795709448"
  }
  invite_timestamp: 1399895384345000
  sort_timestamp: 1420370479351225
  active_timestamp: 1399895384345000
  delivery_medium_option {
    delivery_medium {
      medium_type: DELIVERY_MEDIUM_BABEL
    }
    current_default: true
  }
}
read_state {
  participant_id {
    gaia_id: "someid"
    chat_id: "someid"
  }
  latest_read_timestamp: 0     <-- ?
}
read_state {
  participant_id {
    gaia_id: "someid"
    chat_id: "someid"
  }
  latest_read_timestamp: 1420370479351225
}

[tdryer]

Is it possible to get something like latest_read_timestamp for specific users? I searched for it but couldn't find anything.

It is, but it isn't currently being exposed in the high level API that hangups provides.

It seems like myconv._conversation holds only 0 as timestamp in read_state or am I wrong?

It's probably getting set to zero there sometimes because the conversation is updated using deltas (messages only containing the fields that changed). This is a bit of a design flaw in hangups.Conversation, there's a workaround there just for the fields that hangups is using.

[timsueberkrueb]

@tdryer ah, okay, thank you.

It is, but it isn't currently being exposed in the high level API that hangups provides.

May I create a feature request for this? :)

[tdryer]

Sure.

[timsueberkrueb]

I'll move this to v0.4. An maintenance update for the current store version is required (as e.g. image sending doesn't work any more in v0.2) and thus I'll release v0.3 soon. I'll implement this feature as soon as it's implemented upstream :)