Community
Participate
Working Groups
While attempting to get the new min/max behavior to work with the Intro I was chagrined to see that it's current implementation is -very- quirky: - Maximizing -any- stack that contains the IntroView causes the CBanner to be hidden (i.e. no Main toolbar or perspective switcher...). - It won't display its contents if opened with the ctrl-E mechanism (i.e. showView). - Using the 'Help -> Welcome' menu entry in one window of a multi-window session can cause it to show up in the other one. Also, it relies on a variety of internal hacks (magic internal property changes, direct manipulation of the WorkbenchWindow layout...) to get what it wants. I've just committed changes to bug 161312 which, while making the basic workflows for Intro look OK, does nothing to address these issues because of the depth of the changes necessary to get the Intro handling into a sane state. In short, the current implementation needs to be re-thought (and implemented) from scratch...
The first guess at a better approach would be to: - Make the IntroView non-special so it works like any other view - Change the WB behavior so that it opens an Intro -Perspective- which contains the IntroView as its only contents - Have the IntroView perspecive 'auto-switch' to the default perspective (i.e. Java in most cases) when the view closes. Another approach is to have the IntroView replace the current 'no perspective open' display and simply open new workspaces with no perspective open.
*** Bug 195008 has been marked as a duplicate of this bug. ***
Eric, do you believe that we can make Intro share more of the code with views while preserving the intro APIs? I totally agree with the approach of reducing the amount of code that is unique to Intro but wonder to what extent we are constrained by the existing API.
Chris, I'm not so familiar with all the various API's but to a great extent my problems don't stem from the 'content'; they're almost all related to the 'maximized' and 'standby' states getting out of synch (which also causes problems with ending up with no main Toolbar...). Can you point me at any API's that you think might be affected here? Note that now that we have trim elements all around the outside (potentially) that the current code is broken in any case...it just hides the main TB when I think the correct behavior would be to hide -all- trim (except perhaps the StatusLine).
Moving to 4.0 for a re-write of some kind...
Removing outdated target milestone.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
