Community
Participate
Working Groups
Use trim bar to show pause button and currently active task
Let's leave this on the table for 1.0 for now.
Too big a UI change. Consider post 1.0.
Would it be less bigger change it it will be just a toolbar buttons?
Yes, that's an easy change. But I'm worried that there hasn't been a single request for that, and some Eclipse users ignore the toolbar entirely, especially when it gets bloated from other plug-ins. Also, it will put it physically further from the Task List if the Task List is not docked at the top of the screen. So while that is definitely worth reconsidering, and there is a good argument for it belonging there since the editor back-button is there, I think that we should delay this post 1.0 where we can dedicate some time to rethinking the UI design here..
More suggestions for the trim: * Display context menu for active task on trim widget * Display a history of the last 5 active tasks in a menu for quick multi-tasking * Quick access to pause and deactivate a task
*** Bug 128981 has been marked as a duplicate of this bug. ***
I think that we should keep the pause button off this, because it is an artifact of the fact that task contexts are not instant to activate (bug 145876, blocked by Platform bug 138666).
Jean-Michel: CC'ing you since we chatted about this. We're about to start on an implementation since we need this UI change in Mylar 2.0M3. If there are specific requirements you have, or a patch that you want us to start from, please post.
Here is our current stab at the design. Default location is bottom-right corner, which shoves over the status bar but that's OK because the status bar is good at bringing attention to itself. The down side to bottom-right is that it is pretty far way to mouse from the editor and the top of the Task List. 1) Action on back button (<-) is to activate the task at the top of the list. 2) Back button has pull-down to show the 10 previously active tasks, same as the current Back button on the Task List or the Activate Task Dialog (Ctrl+F9). The semantics of "Back" would be the same as we've always used, which are almost identical to those in IE 7 (one list, with check box indicating current position in history). 3) On top of the list we re-rank "In Progress" tasks and add a separator. By default this is tasks with outgoing changes in the Synchronize view, but a team provider could specify a different definition of "In Progress". 4) To avoid the need for third parties to add additional active task-specific trim items, additional composites can be contributed (<contribs> below). [ <- v | 144161: Use trim bar to.. | <contribs>] pull-down menu: ------------------- <in progress t1> <in progress t2> ------------------- <last active t3> <last active t4> ... <last active t8> ------------------- Deactivate (Ctrl+Shift+F9) -------------------
Thanks for the ping Mik. I'll talk with the current owners of our active task trim and we will work on a list for you.
(In reply to comment #7) > I think that we should keep the pause button off this, because it is an artifact > of the fact that task contexts are not instant to activate (bug 145876, blocked > by Platform bug 138666). I don't think it is completely related. There are several activities when it does not make sense to close task (it is just not natural). I.e. when picking up large update from version control or from the external changes. So, if you don't think that pause should be inside drop down, then please put it into the trim itself. Though it would of been nice to have quick-trim, similarly to Alt-Shift-N.
I implemented the first cut at this (just moving the active task link and back button and menu to trim). Still a work in progress.
I can add some enhancements to this so that it can support the contributions listed in comment #9.
(In reply to comment #12) > I implemented the first cut at this (just moving the active task link and back > button and menu to trim). Still a work in progress. Mik, can you please attach context? It would be nice to have an option to remove task link (similar to "show text" on the dock bar). It takes too much of the statusbar. Personally I'd prefer an icon that would have a menu to deactivate/pause/open task and show all task info in the tooltip, similar to one from the tasklist. BTW, dropdown button don't work to well at the bottom because its menu shown over the button icon, so you have 50/50 chance to click at the first menu item. I reported bug 156734 but it doesn't seem getting much attention.
After playing around with this a little bit, I figured out how additional contributions can be added to a trim bar and it does not require changes to your code Mik. Since you've already defined a toolbar (org.eclipse.mylar.tasks.ui.trim.container), additions will have to define their locationURI as "toolbar:org.eclipse.mylar.tasks.ui.trim.container?<before or after>=<command or control id>". Then instead of defining their own toolbar, they merely have to define their own commands or controls. An entry in the PDE might look something like this: org.eclipse.ui.menus --> toolbar:org.eclipse.mylar.tasks.ui.trim.container?after=org.eclipse.mylar.tasks.ui.trim.control --> --> my.example.myTrim.control or in xml: <extension point="org.eclipse.ui.menus"> <menuContribution locationURI="toolbar:org.eclipse.mylar.tasks.ui.trim.container?after=org.eclipse.mylar.tasks.ui.trim.control"> <control class="my.example.MyTrimWidget" id="my.example.myTrim.control"> </control> </menuContribution> </extension> Maybe this information was already obvious to some, but having expressed some confusion in private about the ability to contribute additional controls to trim bars, I thought this might be helpful to post.
Sorry about the text formatting. I hope my point came across regardless.
Created attachment 70259 [details] patch for review I've made some improvements to the size & layout of the trim widget. I've also added a 'Deactivate Task' action to the drop down menu that appears when a task is activate.
Created attachment 70260 [details] mylar/context/zip
Patch applied, nice progress Leo. Some fixes: * Reversing the order of the menu, since we are placing it at the bottom and it is very likely to show above the widget not below. This might need to be configurable so make it a flag on the menu. * Add an "Activate Task..." action in the place of "Deactivate Task" when there is no task active (class is ActivateTaskDialogAction). Let's try working with that and after we have some experience figure out what should be improved or configurable.
Could a context menu similar to the one on the task list be added? This would very useful for deactivating the task etc.
(In reply to comment #19) The width is better now, but that text label on that link is weird (with ... in the middle). But there is some unused space on a right side of that label. Also, what that thing on a left side of dropdown supposed to be? I see some "." with "." tooltip. There is something with the height. Current trim is higher then fast view and progress trims. At least on windows with win 2000 theme. > * Reversing the order of the menu, since we are placing it at the bottom and it > is very likely to show above the widget not below. This might need to be > configurable so make it a flag on the menu. Menu reordering could be confusing. You also need to think about cases when task bar is shown on the top (I know it is not a default) or even on a side. BTW, docking to a left or right side is completely ugly now. You may want to look at the implementation of the Progress trim and either turn text 90 degrees or disable it for vertical orientation. Personally I think popup tooltip would be sufficient and it should be posible to disable text. With inceased use of newly introduced minimized trims there isn't really much space for text anywhere.
> (In reply to comment #19) > > The width is better now, but that text label on that link is weird (with ... in > the middle). But there is some unused space on a right side of that label. That seems to be a Hyperlink's standard behaviour. I noticed the extra unused space as well, and wasn't too pleased with it. I can try to implement it as a standard Label and truncate it at the end if that's what people would prefer to see. > Also, what that thing on a left side of dropdown supposed to be? I see some "." > with "." tooltip. It's a dummy command to enable the trim on non-Windows platforms. See bug 177818 and bug 183003 for existing trim issues. > There is something with the height. Current trim is higher then fast view and > progress trims. At least on windows with win 2000 theme. Can anybody else on Windows confirm this? I'm working on a Mac right now and it seems fine. I can check on our Linux machine tomorrow. But I've found that trim height on Windows is less forgiving. > Menu reordering could be confusing. You also need to think about cases when task > bar is shown on the top (I know it is not a default) or even on a side. Trim widgets know what side of the trim they are docked on, so it would be fairly easy to order the menu based on the widget's location. > BTW, docking to a left or right side is completely ugly now. You may want to > look at the implementation of the Progress trim and either turn text 90 degrees > or disable it for vertical orientation. Personally I think popup tooltip would > be sufficient and it should be posible to disable text. With inceased use of > newly introduced minimized trims there isn't really much space for text > anywhere. Since the trim widget knows what side of the trim tit is docked on, it would be easy to draw it differently if it happened to be in one of the side trims. I probably won't try to draw it vertically, but the appearance can be changed in other ways. I guess it's just a matter of what people want to see from the trim widget if it's docked on the side. We have a couple of requests for seeing the contextual menu menu from the task list in the trim widget. How would people feel if it was invoked with a right-click over the task label?
(In reply to comment #22) > That seems to be a Hyperlink's standard behaviour. I noticed the extra unused > space as well, and wasn't too pleased with it. I can try to implement it as a > standard Label and truncate it at the end if that's what people would > prefer to see. You may want to look how that link is implemented on task list toolbar. Though it is not pretty there either. > Can anybody else on Windows confirm this? I'm working on a Mac right now > and it seems fine. I can check on our Linux machine tomorrow. But I've > found that trim height on Windows is less forgiving. It is off maybe 1 or 2 pixels. But I can see it here when dragging trim on and off statusbar. > Trim widgets know what side of the trim they are docked on, so it would be > fairly easy to order the menu based on the widget's location. Great! Though there could be issues with multiple monitors too... i.e. second monitor is below the current one. > We have a couple of requests for seeing the contextual menu menu from the > task list in the trim widget. How would people feel if it was invoked with a > right-click over the task label? If my voice counts, it seems like a good idea and it does make sense to show the same menu as in the task list. BTW, it would be neat to show fully decorated task icon, including incoming/outgoing changes indication. Also, can you please align tooltip (I still hope it will look the same as one in task list) to some fixed position outside of trim widget?
Created attachment 71222 [details] trim patch v2 Still a work in progress. I've added a contextual menu that can be invoked from the task label when a task is active, and I've truncated the task label at the end instead of the middle. The previous task action popup now has an activate/deactive action, which you can also see from the task list toolbar. Feedback is welcome.
Looking good. Patch applied.
The trim widget does not appear in my workspace although I installing the dev build. It disappeared in my bootstrapped workspace a few days ago as well. Is there a way to disable/enable it?
I disabled the trim widget for the dev builds because we are still not doing a good job using real-estate for it. Also, it has been hard to use at the bottom of the screen, so I wonder if we should stop showing the label for the active task and try a different location, such as the upper-right. Were you using it? If so, what location did you have it in and what screen resolution or perspective were you finding it useful for? Note that there is some related working going on with bug 186493.
I put the trim it in the upper right corner. I use it to quickly switch between tasks and to deactivate the active task if I need to browse code unrelated to the active task. I usually have the tasklist in fast view so it takes an extra click to switch tasks there. On my notebook which has a resolution of 1024 x 768 I have the trim in lower right-corner since the tool bar takes up too much space to have the trim on the top as well. I would get rid of displaying the active task in the task list which would make it look cleaner and free up some space there.
Part of the design constraint is that we need to have something useful to the right of the "Find: [ ]" box because that control can not be moved to the view's toolbar without a bunch of custom widget work, and could be questionable even then. So we need to make good use of that extremely expensive real-estate. What we did is to create a bread-crumb style switcher for both tasks and working sets (bug 186493). Try it out and see what you think. For continued experimentation I have removed the label from the working set and put it into the upper-right so that we get a sense.
(In reply to comment #28) > I would get rid of displaying the active task in the task list which would make > it look cleaner and free up some space there. +1
(In reply to comment #30) > +1 If suggesting or voting for removing that link please provide a design alternative to the points outlined in comment#29. Also note the new breadcrumb style UI that's nearly complete (bug 186493 and bug 193005) which in my opinion makes great use of that space while making both working sets, and addressed the problem of the Platform no longer having the Window Working Set switcher visible by default. It also allowed us to entirely remove the back arrow active task switcher from the Task List toolbar. Regarding switching tasks, I have removed the label from the trim widget. Any variation of the label seemed to look ugly and take up more trim that it was worth. If others like it we could consider making the showing of the label an option. Note that without the label we open up the question of whether this should be a trim widget at all, or whether it should go onto the toolbar. I realize that the toolbar can be overloaded, but overloading trim is no better. If we put it on the toolbar it should probably go to the right of the editor switchers. I'm going to give that a try for the purpose of experimentation.
Thanks for the explanations Mik. I would get rid of the find box entirely and provide a pop-up like input field as soon as the user starts typing in the task list. I would put the icon for switching working sets in the tool bar of the task list and display the active task in a trim-widget. The latter (having the name of the task displayed) is important to me since I have the task list in fast view and it is inconvenient to open it to see which task is active. As a compromise we could have an auto-hide option for the find bar in the task list. The bar would only be displayed if text was entered and hidden otherwise. The trim widget could be disabled by default and optionally turned on in the preferences.
(In reply to comment #32) > Thanks for the explanations Mik. I would get rid of the find box entirely and > provide a pop-up like input field as soon as the user starts typing in the task > list. Ben Pasero did something like this for RSS OWL (with a Firefox like UI where it appears on the bottom). I find that it works quite well. However, we are reusing the filter tree mechanism and filter box from the workbench so this is not an option for 2.0. I'm not entirely sure that it is a good idea either because finding is a very common operation on the Task List, which I think warrants it being visible by default (we could make it hide). Regarding location, I think that as long as it is visible top is better because it is easier to aim for. Please make a new bug report where we can brainstorm ideas on how to improve the UI post 2.0 and push for and help with getting the additional extensibility needed from Platform for filtered trees. For 2.0 we are stuck with using that space well. > I would put the icon for switching working sets in the tool bar of the > task list and display the active task in a trim-widget. The latter (having the > name of the task displayed) is important to me since I have the task list in > fast view and it is inconvenient to open it to see which task is active. Yes, I can see these use case for wanting the name of the task displayed, and that is a large part of this bug report. Btw, do you want the fast view title to change to the Active Task's label so that you can see it via mouse-over? > As a compromise we could have an auto-hide option for the find bar in the task > list. The bar would only be displayed if text was entered and hidden otherwise. > The trim widget could be disabled by default and optionally turned on in the > preferences. Yup, I think that this is a good thing to consider, please file a new bug. Note that this has never been asked for to date, which is another data point for the fact that "Find" is used very frequently.
> Please make a new bug report where we can brainstorm ideas on how to improve the > UI post 2.0 and push for and help with getting the additional extensibility > needed from Platform for filtered trees. For 2.0 we are stuck with using that > space well. Created bug 193010. > Yes, I can see these use case for wanting the name of the task displayed, and > that is a large part of this bug report. Btw, do you want the fast view title > to change to the Active Task's label so that you can see it via mouse-over? That is an interesting idea but it won't help much since it still requires taking the hands of the key board and moving the mouse. If we can't agree to have the trim widget in the default distribution it would be great to make it installable from the sandbox to collect more feedback from users.
(In reply to comment #31) > If suggesting or voting for removing that link please provide a design > alternative to the points outlined in comment#29. At the risk repeating myself, I'd suggest to move some of the toolbar buttons into that space. > Regarding switching tasks, I have removed the label from the trim widget. Hurrah! (In reply to comment #32) > ... I would get rid of the find box entirely and provide a pop-up like > input field as soon as the user starts typing in the task list. It would be awesome if we could do something like that, somehow similar to page search in FireFox, when search bar appear when you start typing. > I would put the icon for switching working sets in the tool bar of the > task list and display the active task in a trim-widget. For the working sets, I am also not sure if they need to be such noticeable. So, window toolbar, of view menu are sufficient for switching working sets (see Package Explorer and other Eclipse views).
(In reply to comment #33) > > The latter (having the name of the task displayed) is important to me > > since I have the task list in fast view and it is inconvenient to open > > it to see which task is active. > > Yes, I can see these use case for wanting the name of the task displayed, and > that is a large part of this bug report. Btw, do you want the fast view > title to change to the Active Task's label so that you can see it via > mouse-over? Can we have tooltip for the button on toolbar or trim show title of current task, or even better show same popup with all the task detals like it is shown in Task List view?
(In reply to comment #35) > > Regarding switching tasks, I have removed the label from the trim widget. > > Hurrah! Not quite yet, because Steffen still is still pushing for this (comment#34 and earlier) and he has some good points. But we can be flexible here, e.g. have it label be an option on the widget, especially if we put it in the Sandbox. The thing I'm still trying to figure out is that if we don't have it on trim whether we should have it on the toolbar next to the editor navigation actions, which it is partly analogous to. > It would be awesome if we could do something like that, somehow similar to page > search in FireFox, when search bar appear when you start typing. See comment#33. > For the working sets, I am also not sure if they need to be such noticeable. So, > window toolbar, of view menu are sufficient for switching working sets (see > Package Explorer and other Eclipse views). Discussion about this is on bug 186493.
What is the advantage of a trim that has a single button over a toolbar button except that it allows flexible positioning? I am not sure that would justify making it a trim which seems rarely used in Eclipse. Having the toolbar button next to the other history buttons makes sense to me.
(In reply to comment #38) > Having the toolbar button next to the other history buttons makes sense to me. +1. Somehow I am under impression that I've tried to suggest that while back.
I've given this more thought too and it is sounding like the discussion has converged. I'm starting on implementing the following, so please holler if you see any problems with it. 1) Put the global task history drop down on the toolbar in an action set to the right of the editor history switchers. If a task is active mousing over will show it's description. 2) Put the trim that shows the active task into the Sandbox UI since users who do not have the Task List visible might still benefit enough from it. The button will be redundant with the toolbar so it might make sense to remove. But I'll keep it since those who like the trim might want to remove the action from their toolbar.
All 2.0 work for this is complete. To summarize: * On the Task List we have a new bread-crumb style UI for showing and toggling the active task and active task working set. * The activate button has moved to the navigate portion of the toolbar. * The trim widget that shows the active task is available by installing the Sandbox UI. Leaving open in case we want to consider moving the trim widget into the distribution for 2.0.
(In reply to comment #40) > 1) Put the global task history drop down on the toolbar in an action set to > the right of the editor history switchers. If a task is active mousing over > will show it's description. Please not just description but all info like you can see in the task list tooltips. Icon, better then left arrow would also make sense (especially for the color-blind people). > 2) Put the trim that shows the active task into the Sandbox UI since users > who do not have the Task List visible might still benefit enough from it. > The button will be redundant with the toolbar so it might make sense to > remove. But I'll keep it since those who like the trim might want to remove > the action from their toolbar. Make it possible to enable/disable that trim and please do something about that ugly dot and unnecessary spacing (at least on windows).
(In reply to comment #41) > All 2.0 work for this is complete. Just for the record. I think that this kind of work should be done at the beginning of the dev cycle and not at the end when there is no time to get feedback from the community. > * On the Task List we have a new bread-crumb style UI for showing and > toggling the active task and active task working set. Can you please remind me how bread crumb would show two active working sets? > * The trim widget that shows the active task is available by installing the > Sandbox UI. Is it still possible to turn it on and off? There are bunch of other sandbox features that are good on their own, so trim widget at its current stage might not be interesting for the users of those other features.
(In reply to comment #42) > Icon, better then left arrow would also make sense (especially for the > color-blind people). I'm still not convinced that we need this switcher and would love to avoid having a toolbar contribution since they are so 'expensive' in terms of Platform real-estate. It is only useful if the Task List is not visible or if it is in fast view mode. I wonder if we could make it only appear in that scenario? > Make it possible to enable/disable that trim and please do something about that > ugly dot and unnecessary spacing (at least on windows). As Leo pointed out in a reply to you on comment#22 the dot is unfortunately necessary for positioning trim contributions on some platforms (bug 177818). Thankfully this is back in the Sandbox because it does look bad. > Just for the record. I think that this kind of work should be done at the > beginning of the dev cycle and not at the end when there is no time to get > feedback from the community. Yup, one reason why the trim is staying in the Sandbox. There are other significant UI changes coming late in the game though and ideally they would have been done sooner. > Can you please remind me how bread crumb would show two active working sets? Try it. It currently changes the label to "<multiple>". If you have alternate suggestions please comment on the corresponding bug. > Is it still possible to turn it on and off? There are bunch of other sandbox > features that are good on their own, so trim widget at its current stage might > not be interesting for the users of those other features. No current plans to implement the preference for turning on and off since the trim is in the Sandbox, but if someone wants this they could contribute it. Yes, I've been wondering about this. The only current way to support this is to have a feature and plug-in per Sandbox UI Tweak. I was originally thinking this was overkill, but I'm not inherently opposed to this kind of 'pollution' of the Sandbox directory, just of our top-level directory. Please open a new bug if you want a different line of granularity.
(In reply to comment #44) > > Make it possible to enable/disable that trim and please do something about that > > ugly dot and unnecessary spacing (at least on windows). > As Leo pointed out in a reply to you on comment#22 the dot is unfortunately > necessary for positioning trim contributions on some platforms (bug 177818). > Thankfully this is back in the Sandbox because it does look bad. That dot is taking space of the whole icon. If you saying that it is not possible to make it work, then just drop it. Even from the sandbox, because sandbox have several other useful features of the high quality. > > Just for the record. I think that this kind of work should be done at the > > beginning of the dev cycle and not at the end when there is no time to get > > feedback from the community. > > Yup, one reason why the trim is staying in the Sandbox. There are other > significant UI changes coming late in the game though and ideally they would > have been done sooner. I was actually referring to the "breadcrumb" stuff, which is kinda obscure in my taste. > No current plans to implement the preference for turning on and off since the > trim is in the Sandbox, but if someone wants this they could contribute it. Very nice. > Please open a new bug if you want a different line of granularity. I don't want granularity. I just want to be able to disable things I don't need and configure UI to my own convenience.
(In reply to comment #45) > (In reply to comment #44) > That dot is taking space of the whole icon. If you saying that it is not > possible to make it work, then just drop it. Even from the sandbox, because > sandbox have several other useful features of the high quality. Can we only enable the dot on the affected platforms?
Not as far as I know since it is put there via extension points. Leo: if we give up on positioning it in a sensible spot can we get rid of the dot?
If you want to get rid of if that's fine. What will happen though is that on Linux and Mac the space for the trim will be allocated, but nothing will be drawn in it. An alternative is to give the command an icon, if that makes it less ugly for some.
(In reply to comment #48) > If you want to get rid of if that's fine. What will happen though is that on > Linux and Mac the space for the trim will be allocated, but nothing will be > drawn in it. Hmm. I don't see any dots on the Progress trim, not on fast view trim. How did they do that? > An alternative is to give the command an icon, if that makes it > less ugly for some. Such icon could show currently active task and could have correspond tooltip that could resemble one from the Task List view.
(In reply to comment #49) > Hmm. I don't see any dots on the Progress trim, not on fast view trim. How did > they do that? As far as I can tell none of the trim in the platform are contributions, so the same bugs may not apply.
(In reply to comment #48) > An alternative is to give the command an icon, if that makes it > less ugly for some. This seems like a reasonable approach to me too. We could try a transparent GIF too.
(In reply to comment #50) > As far as I can tell none of the trim in the platform are contributions, so the > same bugs may not apply. Can you please remind me why this one need to be contribution?
Created attachment 72268 [details] removed dummy control Instead of dummy control, drop down button is now contributed trough extension point. Also made attempt to add some ui to hide/disable trim (settings, ui and custom property tester is working, but can't figure out how to hide toolbar contribution) Accidentally fixed decoration prefs (bug 193872). Mik, when you moving settings into sanbox, you need to adjust pref store you are reading from to the plugin that does the work. Seem like that Java feature in sandbox have the same issue, I am not sure which plugin is doing the job, so left todo in sandbox prefs page class for you
Created attachment 72269 [details] mylyn/context/zip
Created attachment 72327 [details] updated patch
(In reply to comment #53) > Also made attempt to add some ui to hide/disable trim (settings, ui and custom > property tester is working, but can't figure out how to hide toolbar > contribution) The only way I've figured out how to hide the toolbar that hosts the trim is to get the IWorkbenchWindow, cast it to WorkbenchWindow, call getTrimManager().getTrim(ID_CONTAINER); and set the visibility on that.
(In reply to comment #56) > The only way I've figured out how to hide the toolbar that hosts the trim is to > get the IWorkbenchWindow, cast it to WorkbenchWindow, call > getTrimManager().getTrim(ID_CONTAINER); and set the visibility on that. Cool! By the way, do you know by any chance how to add custom actions to the trim menu? The one that has "Dock On" menu.
Any chance this patch would make into 2.0 this week?
If I can get an updated patch I should be able to get it in tonight (after that it will have to wait until 2.0). The preference should be stored in the Sandbox UI plug-in.
Created attachment 72439 [details] updated patch Here is updated patch. Mik, sawing setting in sandbox prefs won't work, because actual components are sitting in tasks.ui plugin. Since there is overlap in sandbox prefs page I kept fix for bug 193872 in this patch. The only thing I can't figure out, is how to not show trim on startup if settings for it aren't enabled. Maybe we should try action group, in a hope that perspective configuration UI would handle it... though I am out of time now.
Created attachment 72440 [details] mylyn/context/zip
Created attachment 72442 [details] updated patch This one is the same as previous + fix for restoring/saving hightlighter settings.
Created attachment 72443 [details] mylyn/context/zip
(In reply to comment #57) > Cool! By the way, do you know by any chance how to add custom actions to the > trim menu? The one that has "Dock On" menu. > Do you mean adding the 'Dock On' command from the perspective bar and other places, to the trim's menu? I'm not sure where to find those actions unfortunately. (In reply to comment #60) > The only thing I can't figure out, is how to not show trim on startup if > settings for it aren't enabled. Maybe we should try action group, in a hope > that perspective configuration UI would handle it... though I am out of time > now. > You could try to set the visibility on the trim when the plugin starts up.
(In reply to comment #64) > Do you mean adding the 'Dock On' command from the perspective bar and other > places, to the trim's menu? I'm not sure where to find those actions > unfortunately. No. There is another menu on trim (called from that thick vertical separator bar) and it has Dock On... already. I was thinking to add hide action in there. Similar to heap status and perspective switcher trims. > (In reply to comment #60) > You could try to set the visibility on the trim when the plugin starts up. That doesn't work, because trim isn't created yet at that time, so trim manager can't find it.
(In reply to comment #65) > No. There is another menu on trim (called from that thick vertical separator > bar) and it has Dock On... already. I was thinking to add hide action in there. > Similar to heap status and perspective switcher trims. > Okay. No, I don't know how to add actions to that menu. > That doesn't work, because trim isn't created yet at that time, so trim manager > can't find it. > Trim should force the plugin its in to start up, but I believe you'd have to have that preference check in the plugin where the trim is defined in plugin.xml
(In reply to comment #66) > Trim should force the plugin its in to start up, but I believe you'd have to > have that preference check in the plugin where the trim is defined in > plugin.xml It is started. The problem is that even when trim component is instantiated, the trim itself isn't yet loaded from plugin.xml. At least that is what I saw.
Patch applied. On very quick inspection I found the following bugs which should be fixed even though this functionality is sandbox quality. The main reason I applied this is that it fixes bug 193872, but the following needs to be addressed: 1) The preference page setting is unchecked at startup even when the widget is showing. 2) The widget fails to stop loading at startup as you know, but at least (1) should be addressed 3) The widget looks considerably worse because the active task label is no longer vertically aligned correctly Also, please note that I am going to update the contribution guidelines to be indicate that for the typical case we will no longer accept patches that introduce this amount of duplicate code into non-Sandbox elements. Doing so makes our codebase more difficult to maintain. With this patch I accepted it because the TrimWidget is a Sandbox component whose core classes happen to be in Tasks UI internals.
Created attachment 72480 [details] fix for link alignment (In reply to comment #68) > 1) The preference page setting is unchecked at startup even when the widget is > showing. See my comment #60. I am out of ideas how to address that. > 2) The widget fails to stop loading at startup as you know, but at least (1) > should be addressed Not sure what you mean here. > 3) The widget looks considerably worse because the active task label is no > longer vertically aligned correctly Fix attached > Also, please note that I am going to update the contribution guidelines to be > indicate that for the typical case we will no longer accept patches that > introduce this amount of duplicate code into non-Sandbox elements. Doing so > makes our codebase more difficult to maintain. With this patch I accepted it > because the TrimWidget is a Sandbox component whose core classes happen to be in > Tasks UI internals. I had to minimize number of affected classes included into the patch to reduce number of conflicts that are making patches go stale...
Patch applied and positioning fix verified. What I meant is that on initial startup with a workspace (including clean workspace) if the checkbox is off (either because never checked off or because checked off by the user) the trim bar will show, which is inconsistent with the checkbox.
In other words issues 1 and 2 is the same thing and like I said, I don't know how to address this. Maybe someone from Platform could help us with that?
Sorry, I was not being clear enough in comment#68: for now address it by always enabling the checkbox on startup so that the preference reflects what the user sees.
Created attachment 72489 [details] set trim on on startup > Sorry, I was not being clear enough in comment#68: for now address it > by always enabling the checkbox on startup so that the preference > reflects what the user sees. I see... Here is patch for this (one of a kind that waste both your and my time). BTW, I'd be happy to hear ideas how to supply tests for patches like this or those are ok without tests?
Patch applied. I'll clarify the conventions for tests for core and UI component contributions on the Contributors Reference once 2.0 is out.
Created attachment 85104 [details] support for disabling task trim I had a chat with Paul Webster and he pointed out that there is bug 201589 that didn't make to Eclipse 3.3 and still not fixed in 3.4. Paul suggested a workaround which I implemented in the attached patch. Basically, the sanbdox plugin will use org.eclipse.ui.startup extension to call setTrimVisible() after workbench window have been created.
Created attachment 85105 [details] mylyn/context/zip
I would like us to revisit the UI for this for 2.3. We need to start it off with a UI discussion on the call because there are several things to work out before proceeding with an implementation: * Overlap with the Task List's working set and active task UI * Potential of supporting this with standard trim * Potential of supporting this with custom minimized trim
I never use the back button when a task is active. I frequently use "Deactivate Task" from the menu though which requires two precise clicks. I would like to make task deactivation a single click on the task trim allowing to quickly switching between activation and deactivation of a task. Comments?
Sounds reasonable but I'm not certain how the history button will still work into the widget since the button itself I imagine would have to be the same as the one used in the tasklist.
(In reply to comment #79) > Sounds reasonable but I'm not certain how the history button will still work > into the widget since the button itself I imagine would have to be the same as > the one used in the tasklist. Button could just reflect currently active task state: active, inactive and paused using the same icons as used by the corresponding actions in the Navigate and other places. When clicking on inactive one (without dropdown) it would activate the previous task, clicking on active it would deactivate it. Also, clicking on paused could unpause context (I personally use pause a lot). BTW, does anyone have anything to say about contributed patch that actually allow to disable trim bar?
Just fyi, here is a related blog comment from me (still awaiting moderation): http://dev.eclipse.org/blogs/jdtui/2008/02/11/34-m5-new-and-noteworthy-the-breadcrumb/ As part of the design review, I think it would be good to keep a couple of points in mind that are not mentioned above: 1) For the significant number of developers using Mylyn, Eclipse doesn’t look much like the screenshot above. Instead we see a concise view of only the relevant paths within the containment hierarchy, making mouse navigation to these elements quick. The breadcrumb UI overlaps with the Alt+click mechanism (and keyboard equivalent) that we have for showing all elements under a given project, folder, or type. I haven’t used it enough yet to know, but the editor breadcrumb could be a good alternate way of doing this in case its faster for some use cases. http://www.eclipse.org/mylyn/images/mylyn-2.0.png http://live.eclipse.org/node/412 2) Since the Europa we already have an instance of a view that has a breadcrumb trail which is unrelated to editor navigation in the EPP packagings, i.e. Mylyn’s Task List. I think that both consistency and an interaction design that makes room for additional breadcrumb UIs is important. For example, for developers using the Task List’s working set and task switching, this bread-crumb drives which projects are visible and which editors and elements open, and as such feels more primary. For those users moving this to trim could could cause a usability problem. In addition, Mylyn has been trying to put the Task List breadcrumb switcher on the trim for the better part of a year now and we have had experimental support for it for quite some time. It has turned out to be so tricky given the already overcrowded trim and toolbars that we might end up making this vertical trim for Mylyn 3.0 / Ganymede. http://www.eclipse.org/mylyn/new/images/2.0/working-sets-switch.gif 144161: [patch] Use trim bar to show currently active task https://bugs.eclipse.org/bugs/show_bug.cgi?id=144161
(In reply to comment #81) Mik, it is all great, but can you please review and apply or explicitly reject patch for restoring trim state as per saved user's settings.
Eugene: I looked at the patch, and while I'm OK with our adding the startup extension to ..mylyn.sandbox.ui, in general we are trying hard to keep the number of startup extensions to a bare minimum. A trim extension should cause the bundle to activate. So I'm wondering, is this extension needed in order to trigger the activation when the trim is not present?
(In reply to comment #83) > Eugene: I looked at the patch, and while I'm OK with our adding the startup > extension to ..mylyn.sandbox.ui, in general we are trying hard to keep the > number of startup extensions to a bare minimum. A trim extension should cause > the bundle to activate. So I'm wondering, is this extension needed in order to > trigger the activation when the trim is not present? Sorry, I don't understand you question. UI startup extension is used to disable trim *after* workbench UI is on. At the time bundle is activated there is no workbench, so trim haven't been created yet and hence can't be disabled.
Mik, when applying the patch please note that it uses the deprecated form of specifying startup extensions. Tasks UI will always activate the sandbox plug-in during its startup when it is reading task list presentations (the trim widget class is in tasks ui so it won't trigger bundle activation). Eugene, would it work to schedule the job from the start() method of the sandbox plug-in?
(In reply to comment #85) > Tasks UI will always activate the sandbox plug-in during its startup when it is > reading task list presentations (the trim widget class is in tasks ui so it > won't trigger bundle activation). Eugene, would it work to schedule the job from > the start() method of the sandbox plug-in? UI startup is invoked at the exactly right time, but I don't know reliable way to detect when workbench UI is started from background job.
Eugene: is it possible to encapsulate your running of the trim visibility setting in TaskTrimWidget? I.e., moving the following code at the end of TaskTrimWidget.createControl(..) or something of that sort? Let us know if it doesn't work that way in case it makes sense for us to hook into into the earlyStart of TasksUiPlugin. public void earlyStartup() { UIJob taskTrimJob = new UIJob("Configuring Task Trim") { public IStatus runInUIThread(IProgressMonitor monitor) { IPreferenceStore uiPreferenceStore = TasksUiPlugin.getDefault().getPreferenceStore(); TaskTrimWidget.setTrimVisible(uiPreferenceStore.getBoolean(TasksUiPreferenceConstants.SHOW_TRIM)); return Status.OK_STATUS; } }; taskTrimJob.schedule(); }
(In reply to comment #87) > Eugene: is it possible to encapsulate your running of the trim visibility > setting in TaskTrimWidget? > I.e., moving the following code at the end of > TaskTrimWidget.createControl(..) or something of that sort? Let us know if it > doesn't work that way It doesn't. At the time createControl() is called, the widget is not placed in the layout yet, so getTrimManager().setTrimVisible() doesn't work at that point. > in case it makes sense for us to hook into into the earlyStart of TasksUiPlugin. What do you mean? The patch puts it into earlyStartup for the SandbixUIPlugin because TaskTrimWidget is registered in sandbox's plugin.xml
Created attachment 90284 [details] simplified patch This patch disabled the for me. Eugene, is there any reason why this would not work?
Created attachment 90285 [details] mylyn/context/zip
(In reply to comment #89) > This patch disabled the for me. Eugene, is there any reason why this would not work? You are making assumptions that async exec would run after workbench is initialized. Perhaps it is the case, but I think it is a coincidence and there is a potential for the racing conditions. On a contrary, earlyStartup() is invoked after workbench is initialized and that is by the API contract.
This assumption is save to make for current versions of Eclipse: http://pookzilla.net/wp/2007/08/eclipse-33-startup-changes/ In future versions the trim enablement will hopefully be fixed.
Seem like that is the case. Thanks for the pointer.
Applied simplified patch.
(In reply to comment #94) > Applied simplified patch. Thanks Steffen.
Implemented behavior outlined in comment 78. Mik, can we close this bug and create bugs for any remaining problems of future trim development?
Sounds good.
