Bug 123106 - Rewrite Navigator listener reactions
Rewrite Navigator listener reactions
Status: NEW
Product: platform
Classification: Unclassified
Component: Navigator
5.x
All All
: P3 (vote)
: 6.x
Assigned To: Jan Peska
issues@platform
: PLAN
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-30 09:27 UTC by David Simonek
Modified: 2011-09-01 16:23 UTC (History)
2 users (show)

See Also:
Issue Type: TASK
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Simonek 2007-11-30 09:27:01 UTC
Rewrite all listener reactions to delegate to one task, coalesced and asynchronous updates. See URL for detailed info.
Comment 1 David Simonek 2007-11-30 09:40:29 UTC
I deleted URL and gave all info here instead:

Description
-----------
Currently Navigator reacts to lookup changes, node destroy events and top component closing asynchronously, in different
ways, with different reaction delay. This may lead to unpredictable results and random wrong updates of navigator area.

Solution is to rewrite all listener reactions to delegate to one task, which would manage all update requests and
possibly coalesce them if needed. Asynchronous update delay will be kept to improve performance when update requests are
coming too quickly.

Dependencies, Risks & Fallbacks
-------------------------------
All Navigator API clients could be possibly affected, so behavior should be preserved by test. Test should trigger
updates from various triggers and check for proper navigator infrastructure reactions.

Time Estimation: 3 man days 

Comment 2 kirillkh 2007-12-18 00:09:46 UTC
> Asynchronous update delay will be kept to improve performance when update requests are
> coming too quickly.
Does this mean that when the navigator is opened, it will idly wait for some hundreds of milliseconds before updating
first? Is this the reason why Navigator always displays "Please wait..." message for some time after opening a Java
file? If so, I suggest the following simple algorithm to improve the user experience:

State:
1. long delay = x milliseconds
2. long last_upd_time = -1
3. Timer timer = create inactive timer
4. List waiting_queue = []

Update event handling:
1. add the event to waiting_queue
2. is timer scheduled?
2.1. yes: return
2.2. no: last_update_time <= current_time - delay?
2.2.1. yes: startUpdate()
2.2.2. no: schedule the timer to run in (delay - curr_time + last_upd_time) ms

When the timer is fired:
1. start_update()

startUpdate():
1. last_upd_time = curr_time
2. perform_update(waiting_queue)
Comment 3 Lukas Hasik 2008-04-10 21:23:50 UTC
moving opened issues from TM <= 6.1 to TM=Dev