Community
Participate
Working Groups
Build: 3.2 M2 1) Window > Hide Toolbar 2) Shutdown and restart the workbench -> The toolbar is back. This should be persisted as part of my workbench state.
*** Bug 170347 has been marked as a duplicate of this bug. ***
Is this on the plan for M7?
Not at the moment. Resources are tight. We'll entertain patches for M7, however.
I would like to try to fix this one. Seems like a nice little bug to get me started contributing to the project. Anything I should know?
Andreas, first thing I'd look for is overlap between the code executed by the current command and the set of existing API. I'm pretty sure that one of the RCP 'advisors' can also inhibit the display of the main toolbar (actually it's a CoolBar). Kim, I couldn't find this with a quick search, do you know where it is? My suspicion is that you should be looking to re-implement the Show/Hide implementation to use a preference (either re-use an existing preference if there is one or create an 'internal' one). The reason I mention the RCP advisor is that if the advisor has specified that there should be 'no toolbar' then the command should be disabled (i.e. you shouldn't be able to use the command to 'over-ride' the behavior defined by the workbench configuration code). Go to it ! We'll all be glad to help where we can...
The attached patch stores coolbar and perspectivebar visibility to internal preferences. I tried to keep it as simple as possible and look forward to any comments you might have. Changes to preferences are made in the WorkbenchWindow#toggleToolbarVisibility() method only, which means they can be 'over-ridden' using the setCoolBarVisible/setPerspectiveBarVisible methods. This is necessary since the intropage temporarily hides the toolbar when shown. Changes was made to the intropage to properly restore the toolbar.
Created attachment 94615 [details] Patch to persist the toolbar visibility
Eric, do you want to look at this? You had some thoughts on the subject the other day...
After sleeping on it, I think I might have a better solution than the patch I submitted. How about using the WorkbenchWindow's save/restore (memento) mechanism? This will require less modifications of existing code and thus a smaller chance of introducing new bugs. There will still be issues with the IntroPart, but that can be handled by making the IntroPart aware of the current state of the coolbar/perspectivebar (ie. query the state on IntroPart#init and restore it on IntroPart#dispose). The IntroPart also needs to persist this state on the off-chance that the user closes the workbench with the IntroPart still active. Any thought/comments?
Andreas, can you turn the second approach into a patch as well? Then I'll go over both and comment. So far I'm impressed, many folks would have forgotten about the Intro 'edge conditions;.
Created attachment 94726 [details] Implementation using memento Here it is. I do need to test this a little bit more.
Tested using the RCP Mail sample application and I've found an issue where the initial perspectivebar visibility value is not synchronized between the WorkbenchWindow class and it's IWorkbenchWindowConfigurer implementation. The API in IWorkbenchWindowConfigurer specifies that the initial value of this field should be 'false' but the workbenchwindow class initializes it to 'true'. The problem with this is that you must call #setShowPerspectiveBar(false) in the RCP advisors to properly synchronize them. If you do not, the ToggleCoolbarHandler command will not be able to update it's label since the toolbar check always returns true. Setting the WorkbenchWindow#perspectiveBarVisible = false should fix this. The next problem I encountered was that the toggle-command's updateElement() method was called before the workbenchwindow's restoreState() method, which resulted in the wrong label being displayed for the command on startup. So with this in mind, maybe the memento approach wasn't such a good idea after all?
Created attachment 95189 [details] using preferences and fixes toggle command issues This patch uses preferences and fixes the issues described in #12. Take a look at it and let me know what you think..
*** Bug 279384 has been marked as a duplicate of this bug. ***
Back to inbox you go...
Assigning to Eric since this bug has a patch attached.
Marking for a look in 3.6.
I've removed the milestone because after spending a day on this it's not as trivial as expected and it's of relatively low impact. The 'helpwanted' flag is set and I'll gladly review any patches that folks in the community want to supply.
I'm going to very gently :) disagree that it is that low impact. 1. I think it goes to a subtle but noticeable aspect of user experience. If I get my workspace setup just as I like it and then the next time I launch the application part of it is back to where it was that's going to impact my perception of quality. Every major end-user application persists the toolbar state across sessions. 2. There are four votes for it -- any votes for a bug are unusual. 3. P3 4. Over 3 years old and if there was going to be community contribution it would have presumably been done by now. Genuinely curious, how often does community contribute to Platform UI? There are so many internals involved.. And OTOH Andreas did contribute a patch a year and half ago and it's just now getting reviewed. That is if anything actually discouraging outside contribution.. :) cheers, Miles
For how long this KNOWN bug haven't been fixed? Reported: 2006-09-25 15:27... Wow! That's why I'm happy to use IntelliJ IDEA! Their beta has less bugs than the curent stable Eclipse version (I'm not kidding). Modified: 2009-11-25 14:39 EST (but still unfixed) And that's why I know why I'm using IDEA! If fixing such a low impact bug is so difficult... "this it's not as trivial as expected" -- Eric Moffatt ...the underlying Eclipse architecture is just $%#$!
Alexander, I don't think that's really fair either, or polite. ;) Ask yourself if you would say the same thing to a team member in person, or find a more constructive way to contribute to the discussion. I just looked and platform UI has fixed 3998 bugs (!?) in the same period. This bug is in no way a show stopper, in fact some would probably see it as an enhancement. With Eclipse if you have a question about the underlying architecture then you can understand and discuss specific issues. Needless to say, other platforms don't have this level of transparency. Personally I find the Eclipse platform quite solid, very extensible and well thought out though YMMV of course. (And I should mention that I was a dedicated IntelliJ user for many years before adopting Eclipse.) Finally, this bug does actually implicate a number of different systems and one of the issues with a very mature platform is being really careful about mucking with behavior that people rely on. The worst case would be to throw a breaking fix out. On the other hand, I do agree in the sense that I think that usability, L&F and related issues sometimes take a back seat to underlying platform mechanics in the Eclipse IDE. If something actually doesn't work then it get's really rapid attention, but if it's "just" a UI usability issue it can languish. Not to say that there hasn't been a lot of innovation and that the UI doesn't have very powerful features, but it does sometimes miss those elegant little touches that add up to a more polished user experience. I'd say the traditional if you don't like it, file a bug report or fix it yourself, though this case is somewhat of a counter-example.
(In reply to comment #21) > Alexander, I don't think that's really fair either, or polite. ;) Ask yourself > if you would say the same thing to a team member in person, or find a more > constructive way to contribute to the discussion. Miles, I had no intention to offend or even insult any of the users nor developers of Eclipse. I just wondered for how long such a "simple" bug remains unfixed. Also I've criticized the underlying platform that makes such fixes such a time consuming issue?! To bring it to the point it's not about people, it's about the plattform! We should try to take criticism of the tools we use and the projects we work on not personal. May be not simple... but we should try :)
(In reply to comment #18) > I've removed the milestone because after spending a day on this it's not as > trivial as expected and it's of relatively low impact. Eric, what are the concrete problems you encountered with the latest patch? Without this information, how is anybody going to be able to improve the patch?
Boris, when I tried to do this I ran into a conflict between the preference-based solution and the WorkbenchWindowConfigurer (which also thinks it owns the visibility of the Coolbar/PerspectiveBar). What's the story for this; do the pref values override the configurer, vice versa or is it ad hoc? Let me get back to the state where the preference was implemented and post at least that part of the fix along with whatever I can tell about why the approach isn't working.
Created attachment 154806 [details] Updated version of Andreas' last patch Blame it on the Sudafed. Andreas your patch works like a charm. When I first looked at this last month it was on a day where I was working from home due to a bad head cold. In any case I'll tag this for 3.6 M5, thanks! As for why this stayed in the queue for so long (especially with a valid patch) my only explanation would be that I was likely focused on other issues and simply missed it, my apologies. So many bugs, so little time <sigh>
Marking for 3.6M5. The only oddity I've seen is that if you dock the PerspectiveBar on the left, then hide the Toolbar and then try to dock it on either 'top left' or 'top right' it disappears. Since this would only affect folks who've already used the command to hide the toolbar I don't think this is unreasonable (it appears fine on a 'show').
Committed in >20091218. Applied the patch.
Andreas, when we apply an external patch we always add an attribution in the affected files indicating your contribution to the eclipse source. The format is loosely: My Name <myEmail@some.com> - bug # If you want to supply an email fine, if not I'll just go with your name...
I'm happy to see that my patch worked. Hopefully I will be able to do more work next year. Use the following for the affected files: Andreas Bjoru <andreas@bjoru.com> - bug 158642 thanks..
(In reply to comment #29) > I'm happy to see that my patch worked. Hopefully I will be able to do more work > next year. Sounds great! If you find yourself in a similar situation (patches not being applied in a timely manner), please make some noise on the bug to get noticed (or failing that, put me on the cc list). Unfortunately, because we are heavily resource-constrained, all too often bugs don't get the deserved attention.
No Prob, my thanks are to you..;-).
Marking as FIXED.
Verified in N20100117-2000.
*** Bug 206634 has been marked as a duplicate of this bug. ***
