AtingTot / wave-protocol

Automatically exported from code.google.com/p/wave-protocol
0 stars 0 forks source link

Add search panel to WIAB (UI only so far) #193

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Wiab needs search functionality, and imho the first step would be to add search 
toolbar UI on the left panel.

Original issue reported on code.google.com by vega113 on 25 Dec 2010 at 6:30

GoogleCodeExporter commented 9 years ago
I am currently investigating how to implement this.

Original comment by vega113 on 25 Dec 2010 at 6:32

GoogleCodeExporter commented 9 years ago
I see the following approaches to implement this:
1) By re-using and adapting the undercurrent architecture/logic for the Wave 
panel and Toolbar
  advantages:
  -some reuse of existing code for rendering elements
  -very flexible and efficient rendering and event capturing
  -pluggable toolbar
  -may support styling (i.e. annotations also for the waves feed (list)
  disadvantages: 
  -it may be overkill, i.e. to much for simple goal of rendering mostly static or text content.
  -requires much effort
2)Implementing using GWT widgets
  advantages: 
  -simple to implement and understand
  disadvantages:
  -rendering need to be implemented from scratch
  -much simpler support for pluggable controls on the toolbar
  -simple text waves feed
3)Some kind of hybrid, where some rendering done by adapting and reusing 
undercurrent UiBuilders for the frame and EditorToolbar, but say events are 
handled in more simple way, and the waves feed is not changed - i.e. just text 
snippets as it is now.

I would like to get any input/ideas on the issue, especially taking in account 
that my knowledge/understanding of the Undercurrent architecture is very 
limited.

Original comment by vega113 on 27 Dec 2010 at 6:35

GoogleCodeExporter commented 9 years ago
I believe re-using the "doodad" registration and event mechanism has been the 
winning suggestion when I've discussed this with people experienced in the 
client, so mostly your option 1).

Note that search results will likely have some liveness. For example, when 
someone is typing in a wave the digest should update to reflect their 
additions. When viewing or editing a wave the message and unread counts should 
change to reflect that. It's not super-complex, agreed, but it's not all 
static. Also there's lots of room to make the entries better looking than the 
plain text they are currently.

Original comment by ano...@google.com on 29 Dec 2010 at 2:40

GoogleCodeExporter commented 9 years ago
After trying both ways I am leaning toward pure widget approach. The "doodad" 
approach is unnecessary complex to implement and maintain. It also requires 
complex event handling mechanism which imho is unjustified for the left panel 
where basically there are only 3 types of events - search query request, click 
on toolbar and wave selection. And since there will be no stages mechanism the 
complexity of doodads use here is not justified by performance improvement. 

Original comment by vega113 on 30 Dec 2010 at 7:26

GoogleCodeExporter commented 9 years ago
I also planning to replace the Waves snippet list with CellList widget. It has 
built in support for paging and works nicely with huge lists. 

Original comment by vega113 on 30 Dec 2010 at 10:33

GoogleCodeExporter commented 9 years ago
If you're willing to implement it then that sounds good to me. Other client 
developers may weigh in too.

Do attempt to send us incremental changes for review so we get an early 
opportunity for feedback.

Original comment by ano...@google.com on 4 Jan 2011 at 12:18

GoogleCodeExporter commented 9 years ago
First patch version is available at:
http://codereview.waveprotocol.org/490001
It includes:
1) Addition of bread crumb, panel and toolbar to the wave list panel (so it 
looks similar to the wave panel)
2) Waves snippet list is implemented as Cell list - that enables paging support.
3) Added range label - to display the current range and current wave list size.

Original comment by vega113 on 11 Jan 2011 at 10:36

GoogleCodeExporter commented 9 years ago

Original comment by vega113 on 12 Jan 2011 at 11:08

GoogleCodeExporter commented 9 years ago
fixed by rev 17eb65ad40

Original comment by vega113 on 21 Jan 2011 at 7:28