Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 50723 - [Preferences] Autorefresh polling preference presentation
Summary: [Preferences] Autorefresh polling preference presentation
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: PC All
: P2 normal (vote)
Target Milestone: 3.0 M9   Edit
Assignee: Tod Creasey CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 55546 (view as bug list)
Depends on:
Blocks: 36962
  Show dependency tree
 
Reported: 2004-01-27 17:48 EST by Jared Burns CLA
Modified: 2004-05-18 13:06 EDT (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jared Burns CLA 2004-01-27 17:48:39 EST 
Build 20040127

The way the polling preference is presented makes it look like the autorefresh feature relies on 
polling to do its job. Unless things have changed since Jed wrote it, however, autorefresh normally 
doesn't poll at all, but relies on natives for "interrupt-driven" updates.

The polling preference should somehow let the user know that it will only be used if the native 
notifications fail. Ideally, the autorefresh plug-in should know whether or not the native support is 
there, so it should be able to tell the user whether or not the preference will have any effect. 
Maybe, the preference could even be hidden if the autorefresh plug-in detects that it won't be 
used? At the very least, though, there should be text there (even if it has to be verbose) to inform 
the user of the setting's implications.
Comment 1 John Arthorne CLA 2004-01-28 16:58:32 EST 
True (that's why it's under "Work in Progress :))
Comment 2 John Arthorne CLA 2004-02-11 16:16:23 EST 
Removing target milestone. We'll move this out of "work in progress" after M7.
Comment 3 John Arthorne CLA 2004-03-22 12:25:48 EST 
*** Bug 55546 has been marked as a duplicate of this bug. ***
Comment 4 John Arthorne CLA 2004-03-22 12:28:47 EST 
Update: this has remained as work in progress due to its instability on Linux
(bug 52859). I will probably recommend removing the polling frequency preference
from the UI altogether, and try to come up with a smarter heuristic for polling
frequency. No point adding user confusion for this when it's not even clear if
the polling frequency preference is needed.
Comment 5 John Arthorne CLA 2004-03-31 17:29:29 EST 
I have removed support for the polling preference altogether, and made the
polling monitor smarter.  It now breaks the polling work into chunks of 100ms
with breaks in between.  This should make polling inobtrusive but still
performant.  I've tested on a machine with all core+test+ui projects as source,
and it seems like acceptable performance.

Moving this to the UI to remove the polling preference.  I also recommend moving
the "auto-refresh" preference to the main Workbench preference page, and
changing the name to something more descriptive,

"Refresh Workspace automatically in the background"
Comment 6 Tod Creasey CLA 2004-04-05 13:18:26 EDT 
Changed as suggested by John for builds >20040405