platform-ui-home/R3_1/dynamic_teams/dynamic_teams.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.20 - (view) (download) (as text)

1 : mvanmeek 1.1 <html>
2 :     <head>
3 :     <title>Platform UI 3.1</title>
4 :     <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
5 :     <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
6 : mvanmeek 1.2
7 : mvanmeek 1.5 <style type="text/css">
8 :     <!--
9 :     .style1 {
10 :     color: #FF3333;
11 :     font-weight: bold;
12 :     }
13 :     -->
14 :     </style>
15 : mvanmeek 1.1 </head>
16 :    
17 :     <body bgcolor="#FFFFFF" text="#000000">
18 :     <table border=0 cellspacing=5 cellpadding=2 width="100%" >
19 :     <tr>
20 : mvanmeek 1.3 <td align=left width="72%"> <font class=indextop>&nbsp; </font>
21 : mvanmeek 1.1 <font class=indexsub> platform user Interface</font></td>
22 :     <td width="28%">
23 :     <img src="http://dev.eclipse.org/images/Idea.jpg" height=86 width=120
24 :     alt="Eclipse documentation banner"
25 :     ></td>
26 :     </tr>
27 :     </table>
28 : mvanmeek 1.3 <h3 align="left">Dynamic Teams</h3>
29 :     <ul>
30 : nick 1.12 <li><a href="dynamic_teams.html#preferences">Preferences</a></li>
31 :     <li><a href="dynamic_teams.html#actionContributions">Action Contributions</a></li>
32 :     <li><a href="dynamic_teams.html#navigatorFramework">Navigator Framework</a></li>
33 : mvanmeek 1.3 </ul>
34 : mvanmeek 1.1 <table border=0 cellspacing=5 cellpadding=2 width="100%" >
35 : nick 1.12 <tr> <a NAME="preferences"> </a>
36 : mvanmeek 1.6 <td width="96%" height="25" colspan="2" align=LEFT valign=TOP bgcolor="#0080C0"><strong><a name="team1"><font color="#FFFFFF" face="Arial,Helvetica">Preference</font></a><font color="#FFFFFF" face="Arial,Helvetica">s</font><font color="#FFFFFF"></font></strong></td>
37 : nick 1.12 </tr>
38 : mvanmeek 1.1 <tr>
39 : mvanmeek 1.7 <td><p><strong>Team Goals in no particular order:</strong></p>
40 : mvanmeek 1.1 <ol>
41 : mvanmeek 1.2 <li>Simplify the preferences UI</li>
42 : mvanmeek 1.7 <li>Establish the approach for adopting the R3.0 Core support for preferences
43 : mvanmeek 1.2 <ol>
44 : mvanmeek 1.7 <li>define the compatibility story for both UI and Core existing API
45 :     </li>
46 :     <li>document a model that plug-ins should use when using preference
47 :     scopes</li>
48 :     <li>Import/Export - define strategy to be used for import and export
49 :     re: scopes </li>
50 : mvanmeek 1.1 </ol>
51 :     </li>
52 : mvanmeek 1.4 <li>Support better ways to make preferences available throughout the UI</li>
53 : mvanmeek 1.1 </ol>
54 : mvanmeek 1.2 <p><strong>Team:</strong></p>
55 :     <ul>
56 :     <li>Tod Creasey</li>
57 : mvanmeek 1.16 <li>DJ Houghten</li>
58 : mvanmeek 1.2 <li>Tom Eicher</li>
59 :     <li>Martin Aeschlimann</li>
60 :     <li>Michael Van Meekeren </li>
61 : mvanmeek 1.7 </ul>
62 : mvanmeek 1.2 <p><strong>Planned Work for M3 (committed items): </strong></p>
63 :     <ol>
64 : mvanmeek 1.7 <li> <img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
65 :     Functional high level category view in preference dialog <strong>(Goal
66 :     #1)</strong>
67 :     <ol>
68 :     <li> Iterate over a <strong>Prototype </strong> new Preferences Dialog/Demo
69 :     to dynamic team, to have something new in M3 with regards to functional
70 :     top level preference categories </li>
71 : mvanmeek 1.2 <li>Simplified presentation for preferences and preference catagories</li>
72 :     <li>Easier navigation of the preference pages </li>
73 : mvanmeek 1.7 <li>Oct 19 - 26 - think of issues with high vs wide pref pages. Can
74 :     we use the width better
75 : mvanmeek 1.5 <ol>
76 :     <li>move icons along the top </li>
77 : mvanmeek 1.7 <li>how do we deal with pref pages of the same name (e.g. Editors)
78 :     </li>
79 :     </ol>
80 :     </li>
81 :     <li><strong>Oct 26 - Nov 2 </strong> Prototype #2 with list with large
82 :     icons on left and expandable list on right
83 :     <ol>
84 :     <li>need a design review</li>
85 : mvanmeek 1.5 </ol>
86 :     </li>
87 : mvanmeek 1.10 <li><strong>Nov 9</strong>
88 :     <ol>
89 : tod 1.15 <li>sent <a href="prefs4.gif">samples snapshot to designers</a></li>
90 : mvanmeek 1.10 <li>*** TC and MVM - how will catagorization work, how will it
91 :     be flexible from the product level</li>
92 :     <li>what about advanced being a dumping grounds for all other
93 :     options?</li>
94 :     <li>what about having an advanced button on each group so you
95 :     can get all options?</li>
96 :     <li>should not introduce another scope here (i.e. advanced).</li>
97 :     <li>plan to finish for M4</li>
98 :     </ol>
99 :     </li>
100 : mvanmeek 1.14 <li><strong>Nov 18</strong>
101 :     <ol>
102 :     <li>waiting on designers </li>
103 :     </ol>
104 :     </li>
105 : mvanmeek 1.5 <li>Owner: TC (OTT Platform UI)</li>
106 : mvanmeek 1.2 </ol>
107 :     </li>
108 : mvanmeek 1.9 <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
109 : mvanmeek 1.7 Initiate instrumentation work to help provide data for preference cleanup,
110 :     goal is to have information by beginning of M4<strong> (Goal #1) </strong>
111 : mvanmeek 1.2 <ol>
112 : mvanmeek 1.7 <li>Oct 19 - instrumentation plugins working on R3.0 and R3.0 M2</li>
113 :     <li>Oct 19 - 22 - decide on date when information can be obtained
114 :     if possible </li>
115 :     <li><strong>Oct 26 - Nov 2 </strong>
116 :     <ol>
117 :     <li>Instrumentation is under way</li>
118 : mvanmeek 1.5 </ol>
119 :     </li>
120 : mvanmeek 1.14 <li><strong>Nov 18 - </strong>Pilot instrumentation survey to be run
121 :     this coming week</li>
122 : mvanmeek 1.7 <li>Owner: Michael (OTT Platform UI) </li>
123 : mvanmeek 1.2 </ol>
124 :     </li>
125 : mvanmeek 1.7 <li> <img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
126 : mvanmeek 1.9 Preference page sharing/navigation:
127 : mvanmeek 1.7 <ol>
128 :     <li>editing multiple preference pages simultaneously /preference page
129 :     dependancies
130 :     <ol>
131 :     <li>Oct 19 - 26 Martin to investigate this as well as details
132 :     related to how to keep information that is shared accross pages
133 :     in sync</li>
134 :     <li><strong>Oct 26 - Nov 2 </strong>
135 :     <ol>
136 : mvanmeek 1.9 <li><a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-ui-home/r3_1/proposals/preferences/usability-improvement-suggestions.html">See
137 :     Tom and Martins documentation on overall preference navigation/usability/sharing</a>
138 : mvanmeek 1.10 <ol>
139 :     <li>linking style is supported but can be different per
140 :     page</li>
141 :     <li>will take up less space, need some guidelines for
142 :     commonly used links like &quot;advanced&quot;</li>
143 :     <li>need history controls to move back and forth</li>
144 :     <li>what about jumping around in the lists when the selection
145 :     changes </li>
146 :     <li>how do you open a linked page on specific information</li>
147 :     <li>searching, need to have a prototype</li>
148 :     <li>working copy, need to have a prototype</li>
149 :     </ol>
150 : mvanmeek 1.9 </li>
151 : mvanmeek 1.7 <li>Example 1. Java build path affects other applications
152 :     build path</li>
153 :     <li>Example 2. pages show a preview but preview is affected
154 :     by other pages</li>
155 :     <li>Example 3. project options inherits from instance settings</li>
156 :     <li>pages don't share information
157 :     <ol>
158 :     <li>force apply when page left?</li>
159 :     <li>working copy which is a copy of preferences that all
160 :     pages are working on?</li>
161 :     <li>pages should be organized better, combine pages via
162 :     links or combining the</li>
163 :     </ol>
164 :     </li>
165 :     <li>Important to list the scenarios</li>
166 :     </ol>
167 :     </li>
168 : mvanmeek 1.10 <li><strong>Nov 9 - 16</strong>
169 :     <ol>
170 :     <li>prototype/patch implementation</li>
171 :     <li>first pass for linking between pages behaviour is the
172 :     same as R3.0</li>
173 :     <li>ability to browse back and forward in response to this.</li>
174 :     </ol>
175 :     </li>
176 : mvanmeek 1.19 <li><img src="../../images/ok.gif" nosave="" height="20" width="20" border="0">
177 :     <strong>Nov 18</strong>
178 : mvanmeek 1.14 <ol>
179 :     <li>committed to JDT UI</li>
180 :     <li>looking at forms code</li>
181 :     <li>submitted a patch to <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=78878">bug
182 : mvanmeek 1.19 78878</a>
183 : mvanmeek 1.16 <ol>
184 : mvanmeek 1.19 <li>TC or MVM to look at the patch</li>
185 :     </ol>
186 :     </li>
187 :     </ol>
188 :     </li>
189 :     <li><strong>Nov 23</strong>
190 :     <ol>
191 :     <li>TC - establish a story for the link widget</li>
192 :     <li>make an example use case for this in the UI</li>
193 :     <li>Non-internal version of preference page opening
194 :     <ol>
195 :     <li>i.e. API to open on a page or switch to a page</li>
196 :     <li>take an Object argument as well</li>
197 :     <li>experimental for now</li>
198 :     <li>wait to see what the solution is for filtering/highlighting
199 :     pages to see what to do here</li>
200 : mvanmeek 1.16 </ol>
201 :     </li>
202 : mvanmeek 1.14 </ol>
203 :     </li>
204 : mvanmeek 1.7 <li> Owner: MA (ZRH) </li>
205 :     </ol>
206 :     </li>
207 :     <li>preference sharing (teams contribute similar prefs to a common
208 :     page)
209 :     <ol>
210 : mvanmeek 1.9 <li>Owner: None</li>
211 : mvanmeek 1.7 </ol>
212 :     </li>
213 : mvanmeek 1.19 <li>Tree support in the Project Properties view bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=54128">54128</a></li>
214 : mvanmeek 1.7 </ol>
215 :     </li>
216 : mvanmeek 1.9 <li> <img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
217 : mvanmeek 1.7 Re-catagorize preferences to see if this solves the problems with finding
218 :     the preferences
219 :     <ol>
220 : mvanmeek 1.10 <li>Investigate links between pages
221 :     <ol>
222 :     <li>searching and linking are usefull for managing lots of data
223 :     but also good if someone tends to prefer it over reading the
224 :     pages etc...</li>
225 :     <li>Alternatives
226 :     <ol>
227 :     <li>suggest that we provide examples/API to support links
228 :     but not add to pref ext. pt. schema or bottom of a pref
229 :     page by default</li>
230 :     </ol>
231 :     </li>
232 :     </ol>
233 :     </li>
234 : mvanmeek 1.7 <li>Investigate combining pages that have common information
235 :     <ol>
236 : mvanmeek 1.10 <li><strong>Nov 9 - 16</strong>
237 :     <ol>
238 :     <li>Seems like our three examples (label decorations, colors
239 :     and fonts, editor properties) are very different</li>
240 :     <li>suggest linking should solve this</li>
241 : mvanmeek 1.14 <li>need back&lt;-&gt;forward navigation support in the Preference
242 :     Dialog so the user is not lost</li>
243 : mvanmeek 1.10 </ol>
244 :     </li>
245 : mvanmeek 1.7 <li>Owner: TC,MVM (OTT)</li>
246 :     </ol>
247 :     </li>
248 : mvanmeek 1.19 <li><strong>Nov 23</strong>
249 :     <ol>
250 :     <li>UI to review <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-ui-home/r3_1/proposals/preferences/page-regrouping.html">suggestions
251 :     on page regrouping </a>by TE and MA on pref pages
252 :     <ol>
253 :     <li>DJ, TC and MVM to review the JDT team pref pages</li>
254 :     </ol>
255 :     </li>
256 :     <li>MA to fabricate some screen shots on hiding advanced pages</li>
257 :     </ol>
258 :     </li>
259 : mvanmeek 1.10 </ol>
260 :     </li>
261 :     <li> <img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
262 :     Pass through the preferences to see which ones should be view only preferences
263 :     <ol>
264 :     <li>need some guidelines for views (MA - ZRH)</li>
265 : mvanmeek 1.16 <li><strong>Nov 18</strong>
266 : mvanmeek 1.14 <ol>
267 :     <li>TE to check with MA to see if this really is what he was working
268 :     on.</li>
269 : mvanmeek 1.19 </ol>
270 :     </li>
271 :     <li><strong>Nov 26</strong>
272 :     <ol>
273 :     <li>Search is an example here, how do we deal with view instance
274 :     settings</li>
275 :     <li>MA - to investigate</li>
276 : mvanmeek 1.14 </ol>
277 :     </li>
278 : mvanmeek 1.9 </ol>
279 :     </li>
280 :     </ol>
281 :     <h2><strong>Completed</strong></h2>
282 :     <ol>
283 :     <li><img src="../../images/ok.gif" nosave="" height="20" width="20" border="0">
284 :     Core API backwards compatibility <strong>(Goal #2) </strong>
285 :     <ol>
286 :     <li> Document a plan with respect to the new API based on dyn. team
287 :     input, document what that story is, publish to mailing lists for
288 :     added visibility</li>
289 :     <li>Oct 19 - 26 (THREE issues) <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/user_settings/pref_apis.html">
290 :     See DJs doc on this </a>
291 :     <ol>
292 :     <li>ONE typed events </li>
293 :     <li>TWO - some CORE API for setting prefs. (putValue) does not
294 :     send prop. change events which ends up not updating the caches
295 :     as the caches is changed as a result of an event, what should
296 :     we do for cases where prefs are cached for example and no event
297 :     is sent to update the value
298 :     <ol>
299 :     <li>can not back out as this is API</li>
300 :     <li>log bug reports checking uses of putValue as no event
301 :     is sent </li>
302 :     <li>update doc with hint that only non-API prefs should be
303 :     used in this way if at all</li>
304 :     </ol>
305 :     </li>
306 :     <li>THREE
307 :     <ol>
308 :     <li>plug-ins in RCP should be aware of the no data (no workspace)
309 :     case.</li>
310 :     <li>need to put some changes in workbench</li>
311 :     </ol>
312 :     </li>
313 :     </ol>
314 :     </li>
315 :     <li><strong>Oct 26 - Nov 2</strong>
316 :     <ol>
317 :     <li>DJ to send note to mailing lists with potential problem areas</li>
318 :     <li>porting guide</li>
319 :     </ol>
320 :     </li>
321 :     <li>Owner: DJ (OTT Core) </li>
322 :     </ol>
323 :     </li>
324 :     <li><img src="../../images/ok.gif" nosave="" height="20" width="20" border="0">
325 :     In-line opening of preference pages <strong>(Goal #3)</strong>
326 :     <ol>
327 :     <li> Produce a patch to prototype version of direct preference page
328 :     opening, Platform UI to evaluate agree on final version and implement
329 :     </li>
330 :     <li>Oct 19 - 26
331 :     <ol>
332 :     <li>DP to cleanup a few issues around this work. Some API public
333 :     yet, need to get Tom to try</li>
334 :     </ol>
335 :     </li>
336 :     <li> Owner: Tom (ZRH), Doug Pollock (OTT) </li>
337 : mvanmeek 1.7 </ol>
338 :     </li>
339 :     </ol>
340 :     <p>&nbsp;</p>
341 :     <p><strong>Full list of issues that were discussed (note: these are not
342 :     all committed items):</strong></p>
343 : mvanmeek 1.2 <p>* low priority<br>
344 :     ** medium priority<br>
345 :     *** high priority<br>
346 : mvanmeek 1.7 </p>
347 : mvanmeek 1.2 <ol>
348 : mvanmeek 1.7 <li>*** Make the UI simpler, current solution does not scale well, encourages
349 :     too many categories
350 : mvanmeek 1.2 <ol>
351 : mvanmeek 1.7 <li> UI model with leaning towards few logical/functional groupings
352 :     at the top level</li>
353 :     <li>The Import/Export support should only talk about being able to
354 :     export things to the same extent that it can provide a human readable
355 :     string for the items</li>
356 : mvanmeek 1.2 <li>Currently categorized by plug-in</li>
357 : mvanmeek 1.7 <li>Is there any way to enforce/restrict these categories on downstream
358 :     products?</li>
359 : mvanmeek 1.2 </ol>
360 :     </li>
361 : mvanmeek 1.7 <li> *** Clean up
362 : mvanmeek 1.2 <ol>
363 :     <li>Remove legacy, unneeded, confusing preferences, advanced</li>
364 : mvanmeek 1.7 <li>Use instrumentation tools to found out unused preferences vs frequently
365 :     used</li>
366 : mvanmeek 1.2 </ol>
367 :     </li>
368 : mvanmeek 1.7 <li>*** Backwards Compatibility
369 : mvanmeek 1.2 <ol>
370 : mvanmeek 1.7 <li>Need to clearly define what we do/do not support in terms of backward
371 :     compatibility for the Core API</li>
372 : mvanmeek 1.2 <li>Write more tests?</li>
373 :     <li>Scoped preference store tests</li>
374 :     <li>Are we allowed to break APIs?</li>
375 :     </ol>
376 :     </li>
377 : mvanmeek 1.7 <li>*** Sharing
378 : mvanmeek 1.2 <ol>
379 :     <li>Other teams contribute &quot;pages&quot; to a shared page</li>
380 :     <li>Decorators on three pages </li>
381 : mvanmeek 1.7 <li>E.g. workbench contributes a category and other teams contribute
382 :     (e.g. appearance)
383 : mvanmeek 1.2 <ol>
384 :     <li>Not a hardcoded list</li>
385 :     </ol>
386 :     </li>
387 : mvanmeek 1.7 <li>Sharing an individual preference
388 : mvanmeek 1.2 <ol>
389 : mvanmeek 1.7 <li>e.g. print margin is shared for all editors
390 : mvanmeek 1.2 <ol>
391 :     <li> text font, overriding inherited prefs in some cases</li>
392 :     </ol>
393 :     </li>
394 :     </ol>
395 :     </li>
396 :     </ol>
397 :     </li>
398 : mvanmeek 1.7 <li>** Support to directly open a preference page (or open all prefs.
399 :     but to a specific page)
400 : mvanmeek 1.2 <ol>
401 :     <li>On a specific page</li>
402 : mvanmeek 1.7 <li>Page might switch to a specific tab or group (i.e. don't talk
403 :     in terms of the UI, but rather what is to be shown and the page
404 :     figures it out)</li>
405 : mvanmeek 1.2 <li>Option to show all pages, one page, or a part of the page</li>
406 : mvanmeek 1.7 <li>Opening a single page or portion of the preferences
407 : mvanmeek 1.2 <ol>
408 :     <li>ZRH has a prototype</li>
409 :     </ol>
410 :     </li>
411 :     </ol>
412 :     </li>
413 : mvanmeek 1.7 <li>** Scalable
414 : mvanmeek 1.2 <ol>
415 :     <li>Enable search for preferences</li>
416 : mvanmeek 1.7 <li>Enable highlighting of
417 : mvanmeek 1.2 <ol>
418 :     <li> pages in the tree</li>
419 :     <li>controls (checkboxes...) on a page</li>
420 : mvanmeek 1.7 <li>enable different navigation controls on the LHS of the preference
421 :     dialog (see screenshots)</li>
422 : mvanmeek 1.2 <li>ability to have a different view on the preferences</li>
423 :     <li>should we keep the existing structure?</li>
424 :     <li>How do we contribute this information? XML?</li>
425 :     <li>Does the extension point mechanism scale that well?</li>
426 :     <li>Don't want to aggressively activate plug-ins. (when searching)</li>
427 :     </ol>
428 :     </li>
429 :     </ol>
430 :     </li>
431 : mvanmeek 1.7 <li>* Locking/Access Control
432 : mvanmeek 1.2 <ol>
433 : mvanmeek 1.7 <li>Requirements?
434 : mvanmeek 1.2 <ol>
435 :     <li>Locking = remove from the UI? At the granularity of a page?</li>
436 :     <li>Preferences that are not displayed in the UI</li>
437 :     </ol>
438 :     </li>
439 :     </ol>
440 :     </li>
441 : mvanmeek 1.7 <li>*Ability to apply preferences between page switch to help with inconsistent
442 :     preferences
443 :     <ol>
444 :     <li>Need a working copy of the preferences root</li>
445 :     </ol>
446 : mvanmeek 1.2 </li>
447 : mvanmeek 1.7 <li>* API
448 : mvanmeek 1.2 <ol>
449 : mvanmeek 1.7 <li> Do we need new API for associating human readable strings with
450 :     preferences, or categories?</li>
451 : mvanmeek 1.2 <li>Can we simplify the current API?</li>
452 : mvanmeek 1.7 <li> Does this live in Core? UI? Could be at the Preference Page level
453 :     </li>
454 : mvanmeek 1.2 </ol>
455 :     </li>
456 : mvanmeek 1.7 <li>* Running background operations from a preference dialog<span class="style1">
457 :     (NEW ON OCT 19)</span>
458 : mvanmeek 1.5 <ol>
459 : mvanmeek 1.7 <li>E.g. ask for a build twice</li>
460 : mvanmeek 1.5 </ol>
461 :     </li>
462 : mvanmeek 1.7 <li> Theme support on various levels
463 : mvanmeek 1.2 <ol>
464 :     <li>(e.g. syntax highlighting themes, formatting themes, overall themes</li>
465 :     </ol>
466 :     </li>
467 : mvanmeek 1.7 <li>Allow Export to export random preferences, not all preferences are
468 :     stored in core</li>
469 : mvanmeek 1.2 <li>non-exportable preference/non sharable preferences</li>
470 :     <li>Need to deal with the three core layers that we have? Project, configuration...</li>
471 : mvanmeek 1.7 <li>Batched property change events</li>
472 :     <li>Bug 54392 </li>
473 :     </ol>
474 :     <p><strong>Other Future Ideas: </strong></p>
475 : mvanmeek 1.2 <ul>
476 : mvanmeek 1.7 <li>Auto-page generation based on preference types and predifined behaviour
477 :     (e.g. boolean pref gets a check box and a label)</li>
478 :     <li>Metadata for preferences? Store: user-readable name, groupings/dependencies,
479 :     category, exportable flag, sharable flag </li>
480 :     <li> When you export, it might not be exporting what you think you are
481 :     since preference pages aren't explicitly linked to the preference store.
482 :     </li>
483 :     <li> Movement between tabs in preference pages -&gt; marked as dirty until
484 : mvanmeek 1.14 OK or APPLY is hit. Everyone implements their own ?working copy? strategy
485 : mvanmeek 1.2 <ul>
486 : mvanmeek 1.7 <li>Maybe work with a preference tree and then apply it to the real
487 :     preferences? (note: the import/export mechanism at the Core level
488 :     allows manipulation of a preferences tree and then apply it to the
489 :     real tree) </li>
490 : mvanmeek 1.2 </ul>
491 :     </li>
492 :     <li> Displaying scopes in the UI </li>
493 : mvanmeek 1.7 <li>Import/Export of project preferences -&gt; When you import, you really
494 :     want to apply these preferences to a specific group of projects in your
495 :     workspace (underlying mechanism doesn't allow for this right now) </li>
496 : mvanmeek 1.2 </ul></td>
497 : mvanmeek 1.7 <td>&nbsp;</td>
498 : mvanmeek 1.2 </tr>
499 : mvanmeek 1.1 </table>
500 :    
501 :     <table border="0" cellspacing="5" cellpadding="2" width="100%">
502 :     <tbody>
503 :     <tr>
504 : mvanmeek 1.6 <td width="96%" height="23" colspan="2" align="left" valign="top" bgcolor="#0080c0"><b><font face="Arial,Helvetica"><font color="#ffffff">
505 : nick 1.12 <a name="actionContributions"></a>
506 :     Action Contributions</font></font></b></td>
507 : mvanmeek 1.1 </tr>
508 : mvanmeek 1.6 <tr>
509 : nick 1.11 <td height="232" colspan="2" valign="top">
510 :     <p><strong>Team Goals:</strong></p>
511 :     <ul>
512 :     <li>P1: Simplify the programming model for contributing menu and toolbar items to the workbench (and their corresponding appearance and behaviour).</li>
513 :     <li>P1: Improved control over menu definition and item ordering. Scenario: Search and Run menus.</li>
514 :     <li>P1: Allow the selected object in a view to override an action, e.g. Rename in Navigator on Java element yields refactoring rename</li>
515 :     <li>P1: Maintain a strong separation between a command, its handler(s) and its placement(s) in the UI</li>
516 :     <li>P2: Address difficulty in determining keybindings to show for context menu items.</li>
517 :     <li>P2: Support dynamic entries in (top-level) menus, e.g. File > New submenu, window list, recent file list, Run > Run As..., QuickDiffToggleAction </li>
518 :     <li>P2: Keybindings for object contributions</li>
519 :     <li>P2: Ability to define a default command handler</li>
520 :     <li>P2: Provide a localized command service for parts to use (generalize IKeyBindingService), and support nesting of parts.</li>
521 :     <li>P2: Improve support for contributing items to nested parts/pages (e.g. console view scenario, bug 75737).</li>
522 :     <li>P2: Resolve problems with object contributions in editors (new and experimental in 3.1). See bug 75273.</li>
523 :     <li>P3: Allow the same item to be placed in the UI in multiple places, while minimizing duplication (e.g. of XML enablement expressions).</li>
524 :     <li>P3: Look up and execute existing behaviour in the interface by identifier, e.g. to support welcome, cheat sheets, macros, scripting</li>
525 :     <li>P3: Address JFace impedence mismatch: no notion of commands or keybindings at JFace layer</li>
526 :     <li>P4: Make workbench actions available for others to place elsewhere in IDE.&nbsp; Bug 71028.</li>
527 :     </ul>
528 : mvanmeek 1.6 <p><strong>Team:</strong></p>
529 :     <ul>
530 :     <li>Nick Edgar</li>
531 :     <li>Kai-Uwe Maetzel</li>
532 :     <li>Douglas Pollock</li>
533 :     <li>Michael Van Meekeren </li>
534 :     </ul>
535 : nick 1.11 <p><strong>Principles:</strong></p>
536 :     The work on simplifying the programming model will follow these principles:
537 :     <ul>
538 :     <li>Model/UI separation. Commands and command handlers/actions are specified independently of their placement in the UI.</li>
539 :     <li>Universal extensibility. Every menu and toolbar can be extended - structurally and content wise. Explicit sealing of menus may be an option.</li>
540 :     <li>Universal keybindings. From user's point of view, every menu item and tool item can have a user defined keybinding. From the system's perspective, every command can be triggered by a key binding.</li>
541 :     <li>Separation of structure content. The structure of menus (i.e. which groups they contain) is defined independently from the content of the menus (i.e. the concrete items).
542 :     Everything must be explicitly defined (e.g., there is no implicit definition of new groups in menus).</li>
543 :     <li>Fine-grained control over visibility. Items can specify their visibility based on a context and its properties (think of core expressions).</li>
544 :     <li>Container-managed enablement. Allow the container for an item to choose whether enablement of the item is computed eagerly or on-demand. E.g. menus items can be done on demand, but tool items will need to be done more eagerly. Items determine their enablement based on the associated command handler. This may also apply to visibility.</li>
545 :     </ul>
546 :    
547 :     <p><strong>Documents:</strong></p>
548 :     <ul>
549 : nick 1.17 <li><a href="../contributions-proposal/scenarios.html">Scenarios for contributing menu items and toolbar items in the Workbench</a>.</li>
550 :     <li>Actions in the Navigator view (presentation, applicability, etc): <a href="../contributions-proposal/NavigatorActions.html">HTML</a>, <a href="../contributions-proposal/NavigatorActions.xls">Excel spreadsheet</a>.</li>
551 :     <li><a href="../contributions-proposal/design.xml">Sketch of proposed changes to commands schema, with examples.</a></li>
552 :     <li><a href="../contributions-proposal/nick_navigator.xml">Sketch of changes to Navigator view's extensions (does not correspond exactly with schema above).</a></li>
553 : dpollock 1.18 <li><a href="../contributions-proposal/old-style.xml">Collecton of old XML for some plug-ins' contributions</a></li>
554 :     <li><a href="../contributions-proposal/porting.xml">Port of the contributions to the proposed schema</a></li>
555 : dpollock 1.20 <li>On ottcvs1 (IBM internal), there is a plug-in called "org.eclipse.commands". Looks there for continuing development.</li>
556 : nick 1.11 </ul>
557 : nick 1.17
558 : nick 1.11 <p><strong>Planned Work for M5:</strong></p>
559 : mvanmeek 1.6 <ul>
560 : nick 1.11 <li>Investigate pushing down refactoring participants mechanism to workbench and generalizing it to a general operation participants model.(db/ne/jml)
561 :     </li>
562 :     </ul>
563 : nick 1.17
564 : nick 1.11 <p><strong>Planned Work for M4:</strong></p>
565 :     <ul>
566 :     <li> <img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
567 :     Prototype sample API designed to unify/simplify and clarify (see bug
568 :     36968) the current set of contribution API's
569 : mvanmeek 1.6 <ul>
570 : nick 1.11 <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
571 :     API should fix the following among others:
572 :     <ul>
573 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
574 :     difficulty determining keybindings to show for context menu
575 :     items.</li>
576 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
577 :     understand and plan for support of ordering of items (eg. action
578 :     sets)</li>
579 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
580 :     ability to declare a command and handler once, and support
581 :     placement of the command separately.
582 :     <ul>
583 :     <li>Enablement is defined by the handler</li>
584 :     </ul>
585 :     </li>
586 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
587 :     see proposal coming soon</li>
588 :     </ul>
589 :     </li>
590 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
591 :     write regression tests</li>
592 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
593 :     build sample/example test plug-ins</li>
594 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
595 :     investigate lower level (e.g. JFace) related existing API to ensure
596 :     consistancy</li>
597 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
598 :     minimally support new API based on the existing code
599 :     <ul>
600 :     <li>time permitting enhance or re-write portions of the existing
601 :     code for the following reasons:
602 :     <ul>
603 :     <li>does not support lazy updating in the UI</li>
604 :     <li>poor performance</li>
605 :     <li>complex submenu manager code</li>
606 :     </ul>
607 :     </li>
608 :     </ul>
609 :     </li>
610 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0">
611 :     ISV doc showing migration steps and introducing the new API (ac,
612 :     dp) </li>
613 : mvanmeek 1.6 </ul>
614 :     </li>
615 : nick 1.11 </ul>
616 :     <p><strong>Completed Work for M3:</strong></p>
617 :     <ul>
618 :     <li><img src="../../images/ok.gif" nosave="" height="12" width="12" border="0"> Document scenarios for use cases for Actions (ne)</li>
619 : mvanmeek 1.6 </ul>
620 :     <p>&nbsp;</p></td>
621 :     </tr>
622 :     <tr>
623 :     <td width="96%" height="23" colspan="2" align="left" valign="top" bgcolor="#0080c0"><b><font face="Arial,Helvetica"><font color="#ffffff">
624 : nick 1.12 <a name="navigatorFramework"></a>Navigator Framework</font></font></b></td>
625 : mvanmeek 1.6 </tr>
626 : mvanmeek 1.1 <tr>
627 : mvanmeek 1.6 <td height="232" colspan="2" valign="top"><p><strong>Team Goals in no particular order:</strong></p>
628 :     <ol>
629 :     <li>Provide a general framework for developing navigator views in the context of RCP or the Workbench </li>
630 :     <li>Framework should act as a test bed for new support for:
631 :     <ol>
632 :     <li>retargetable actions</li>
633 :     <li>operations framework</li>
634 :     <li>working set enhancements for large workspaces</li>
635 :     <li> </li>
636 :     </ol>
637 :     non-resource based navigator support </li>
638 :     </ol>
639 :     <p><strong>Team:</strong></p>
640 :     <ul>
641 :     <li>Billy Biggs</li>
642 :     <li>Nick Edgar</li>
643 :     <li>Dirk Baeumer</li>
644 :     <li>Michael Van Meekeren </li>
645 :     </ul>
646 :     <p><strong>Planned Work for M3:</strong></p>
647 :     <ul>
648 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0"> Implement prototype generic navigator framework based on original <a href="../../navigator-proposal/general_purpose_navigator_proposal.html">&quot;Generic Navigator&quot; proposal</a> <ul>
649 :     <li>Owner BB (OTT) </li>
650 :     </ul>
651 :     </li>
652 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0"> Investigate supporting working groups and filters (namely M3 additions in Package Explorer for managing large workspaces) in generic layer
653 :     <ul>
654 :     <li>Owner BB (OTT, DB to send pointers to code)</li>
655 :     </ul>
656 :     </li>
657 :     <li> <img src="../../images/ok.gif" nosave="" height="20" width="20" border="0"> Move re-targetable action work to Action Contributions dyn. team
658 :     <ul>
659 :     <li>Owner MVM (OTT) </li>
660 :     </ul>
661 :     </li>
662 :     <li>OTHER ITEMS
663 :     <ul>
664 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0"> Operations (side note, not officially part of this work but recorded here)
665 :     <ul>
666 :     <li>NOTE JM (OTT) and DB (ZRH) to investigate a prototype for this then to come back in M4 with requirements for UI </li>
667 :     <li>Generalize Operations and push code down from LTK DB (ZRH) </li>
668 :     </ul>
669 :     </li>
670 :     <li><img src="../../images/progress.gif" nosave="" height="5" width="14" border="0"> Work on removing needed for LegacyResourceSupport class JM (OTT) </li>
671 :     </ul>
672 :     </li>
673 :     </ul>
674 :     <blockquote>
675 :     <p>&nbsp;</p>
676 :     </blockquote> <p><strong>Ideas/Possible future work:</strong></p>
677 :     <p>- </p></td>
678 : mvanmeek 1.1 </tr>
679 :     <tr>
680 : mvanmeek 1.6 <td width="96%"> </tr>
681 : mvanmeek 1.1 </tbody>
682 :     </table>
683 :     </body>
684 :     </html>