Community
Participate
Working Groups
This defect is created to track modifications made to UI Forms in 3.3 (see related bug 152912). The changes will include the following: 1) Enhancement of the header area 1a) Rework of the message rendering mechanism 1b) Changes to the layout 1c) Addition of the hot title and drop-down menu capability 1d) Addition of the title area drag and drop capability 2) Subtle changes of the section title rendering 3) Changes in color computation for better visuals on Vista and better look across all platforms 4) Addition of the 'stable header' multi-page editor (multiple pages, single header)
Notice to the community: we expect first cut of the implementation done in a few days, together with instructions on how to see them using org.eclipse.ui.forms.examples project. That way you will be able to play with the new capabilities and see the code that takes advantage of them. Thank you for your patience :-). BTW, since this work involves some new APIs, the target is M5 since it is API freeze.
What's the M5 date? The 3.3 release plan has not been updated here: http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html Is there another URL to check for the milestone dates? I apologize for using the bug to ask that, but you did mention M5. :-) --Lee Anne
Created attachment 56760 [details] Images of 3.3 forms UI updates (In reply to comment #0) Images attached to illustrate the updates listed by Dejan.
(In reply to comment #2) > What's the M5 date? Lee-Anne, the remaining dates for 3.3 have not been posted yet, but I am using the 'prior art' knowledge to extrapolate that: 1) The milestones are spaced about 1.5 months 2) We shipped M4 and of Dec therefore M5 should be somewhere mid Feb 3) There are six milestones in 3.3 4) M6 (the final) will be function-complete freeze 5) We always freeze APIs one milestone before function-complete to let upstream users stabilize That's my story and I am sticking to it :-). Note that even if the reasoning above turns out not to be correct for Eclipse release as a whole, it will still hold for UI Forms - we are aiming at mid Feb as the end of futzing with Forms to let upstream users absorb the changes. Again, note that if you do nothing to your code built on top of Forms, it will continue to work and will not be or look broken.
Created attachment 56783 [details] Form with tabs at top (new tab widget) Moving discussion from bug 152912: Its probably way late in the 3.3 cycle for suggestions, but I have one. I'm working with some folks who are new to Eclipse and they always get confused in form editors because they don't see the tabs at the bottom. It would be nice to have a new paradigm where the tabs for the different pages are closer to the top. The look and feel of CTabFolder wouldn't look great this way. So I'm thinking a new tab folder widget. I'd be more than happy to contribute one that looks better for this scenario if you guys would like to go this way. I'll attach a sample pic.
Many thanks for the "prior art" Dejan! It is more than I had hoped for when I asked the question, so thank you for that. :-) --Lee Anne
(In reply to comment #5) > Form with tabs at top (new tab widgets) Chris, FormEditor extends UI's MultiPageEditorPart. We made that decision a long time ago in order to 'eat our own dog food' and take advantage of many lifecycle issues related to nesting simple editors in a multi-page editor. Unfortunately, we don't get to pick the widget that is used to select individual editors, so we need to leave with whatever MultiPageEditorPart gives us. I would suggest opening a feature request against the Platform UI team and linking it to this defect.
Chris, You might also want to connect with the Eclipse User Interface Best Practices Working Group (http://wiki.eclipse.org/index.php/User_Interface_Best_Practices_Working_Group). "Tabs at the bottom" is a general UI motif used in the Eclipse platform since V1. Given the growth of Eclipse since that time, there might be fruitful discussion to be had in that area. My teams have also gotten usability feedback from our customers about location of the tabs. Once you know they are there, you remember; but new users tend to have trouble discovering them easily. --Lee Anne
I see the problem with using MultiPageEditorPart. I'm sure it could be altered to allow for different tab representations but that would be a larger issue and more complicated. I imagine its too late in the cycle for that. The UI best practices group would be a good place to discuss this item, but honestly I don't have the bandwidth to devote to championing this change right now. It was really an idea off the top of my head based on a fellow developer having difficulty with the PDE editor just yesterday. Perhaps we can pick this discussion back up post 3.3.
The first batch of changes has been released into today's integration build and HEAD. You will see them in PDE editors and Dynamic Help view. To play with the code, do the following: 1) Check out org.eclipse.ui.forms.examples from CVS 2) Launch second eclipse 3) Enable 'Forms Examples' action set in 'Customize Perspective' 4) Open the sample editor from the main menu The first page has the independent elements of the form header that can be turned on and off using check boxes. You can take a look at the code in 'NewStylePage' class.
(In reply to comment #43, comment #44, comment #46, and comment #47 in bug 152912) * Single keyline like that in SHORT_TITLE_BAR would be fine. * Kevin's suggestions are also fine though don't look that different from the proposed curved design. It's that extra bit under the top keyline that seems to be causing the problem, so a simple keyline would be a straight forward simple way to go.
(In reply to comment #11) Simple keyline is in HEAD (also updated the map file in case there is a build).
Created attachment 57284 [details] An alternative rendering of the closed section using the gradient.
A summary of new features in forms for 3.3 has been documented in a proposal now available at http://www.eclipse.org/eclipse/platform-ua/proposals/forms/enhancements-3.3/index.html.
For refresh is done - any further requests should be submitted as either new bugs or enhancement requests against Platform>User Assistance component.
