Community
Participate
Working Groups
It would be handy (hence the P5) to be able to include keywords in the bugzilla repository queries.
Wayne, when you submitted this report, did you select P5 in the new bug editor? If you did and it didn't result in P5 on the new report then we have a bug. I thought I had this happen once before so if you could confirm, I'll create new bug and investigate. Thanks!
I'm pretty sure that at some point Denis disabled setting priorities on new bugs for bugs.eclipse.org.
That would explain it. :)
UI should probably be similar to the web UI, but we could provide with [Select] button that would bring up same dialog as from the task editor. If that helps, I can create a patch for such entry field for the BugzillaSearchPage...
Created attachment 74607 [details] mylyn/context/zip
*** Bug 197840 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > UI should probably be similar to the web UI, but we could provide with [Select] > button that would bring up same dialog as from the task editor. If that helps, I > can create a patch for such entry field for the BugzillaSearchPage... +1 for the proposed UI, simple and consistency with task editor is good.
Created attachment 74850 [details] redesigned search page Here is the proposed redesign of the bugzilla query page next to the original layout. Besides added keywords field, optimized UI density and added sashforms between all list widgets. If this UI looks ok, I'll attach patch for this that also include working query by keywords. No tests though, because there is no really query model in bugzilla. It is really amasing how much more information you can be fit into the same window size...
I think that the redesigned page is much better than before. For what it's worth, the two-lines of product text etc. on the old page never really worked well on the Mac; the scrollbar doesn't really fit into two-lines of text. What's the blank space between the 'finish/cancel' buttons and the 'keywords/all/search' line? BTW the default bugzilla page uses 'all' for the keywords, whereas this page has 'any' selected. Personally, I think 'any' is more sensible but I thought it worth observing.
+1 on the new design. Much cleaner and no longer feels as crowded because none of the fields are cramped.
(In reply to comment #9) > What's the blank space between the 'finish/cancel' buttons and the > 'keywords/all/search' line? That is a wizard status aream which is beyond control of the query configuration form. Please file a separate bug report for this. > BTW the default bugzilla page uses 'all' for the keywords, whereas this page has > 'any' selected. Personally, I think 'any' is more sensible but I thought it > worth observing. The default is still "all" like on the web UI. I just took a screenshot while testing the functionality.
+1
Regarding the new keywords field: +1 Apart from that, the dialog now very much resembles the Bugzilla query web form, which is a pain with respect to usability IMO. In terms of usability and joy of use, Bugzilla is so much inferior in comparison to e.g. Jira... But then, that's not your fault.
(In reply to comment #8) > It is really amasing how much more information you can be fit into the same > window size... Certainly is more dense! I'm liking this new design. For legibility I'd like to see some amount of small separation between the Status, Resolution, Priority... labels and the boxes above for Product, Component etc. In order to solidify the association between the email field and the reporter, owner... check boxes perhaps keywords row could be moved above "only bugs changed sinc.." and update attributes button row (since keywords are included in that update of attributes anyway). Thoughts?
Created attachment 74864 [details] redesigned search page (In reply to comment #14) > For legibility I'd like to see some amount of small separation between the Status, Resolution, > Priority... labels and the boxes above for Product, Component etc. check > In order to solidify the association between the email field and the reporter, owner... > check boxes perhaps keywords row could be moved above "only bugs changed sinc.." > and update attributes button row (since keywords are included in that update of > attributes anyway). Thoughts? I am not sure I completely understood what you've tried to say, but here is what I got now.
Created attachment 74865 [details] redesign I'm leaning towards leaving the text entry fields at the top so user can get they query out (paste it type it) then move on to scope. Is still compact and puts the action buttons in bottom right (update attributes button is at least in proximity to finish and cancel). Also it is less different from our previous Bugzilla query layout. Thoughts?
The reason I moved search fields after scope params is that for the most of the queries you only need to set attributes (project, component and status), and perhaps only searches would need other details. Another reason is that in the current api, it is practically impossible to align query label like you draw it without scraping it off.
(In reply to comment #17) > The reason I moved search fields after scope params is that for the most of the > queries you only need to set attributes (project, component and status), and > perhaps only searches would need other details. Another reason is that in the > current api, it is practically impossible to align query label like you draw it > without scraping it off. Yes it may be the case that when forming queries those text fields are used less. But since this page is also used in the search dialog my thinking is that it should ideally resemble that of other search pages: search parameters follow by scope. Since upon re-opening a search the previous search parameters are filled in, more often than not I think the user wants to refine the search parameters so I think this is their motivation for placing these fields at the top. Thoughts?
Created attachment 75068 [details] patch I've moved search fields above attribute lists as requested.
Created attachment 75069 [details] mylyn/context/zip
Awesome! Patch applied. I realize how difficult any changes to BugzillaSearchPage are at this point. It has become a real beast! Added null check to restoreWidgetValues() where restoring keywords to avoid null argument exception. Should we move the bug owner, reporter, cclist and commenter check boxes up in between Email text field and the substring combo? This could help associate those check boxes with the email field while keeping the nice vertical alignment of the combo boxes on the right.
(In reply to comment #21) > Awesome! Patch applied. Thanks Rob. > I realize how difficult any changes to BugzillaSearchPage > are at this point. It has become a real beast! Not too difficult if you'll use the right tool. :-) > Added null check to restoreWidgetValues() where restoring > keywords to avoid null argument exception. Cool. I missed that. > Should we move the bug owner, reporter, cclist and commenter check > boxes up in between Email text field and the substring combo? This could help > associate those check boxes with the email field while keeping the nice > vertical alignment of the combo boxes on the right. It was like that before, but it wasn't looking good. You can try it of course.
BTW, right-aligning labels in dialogs is rather unusual for Eclipse UI. See Find dialog, CVS repo configuration, Mylar's own issue tracker repo configuration, Preferences / network configuration, and endless number of others standard Eclipse dialogs. Also, it seem like labels for all lists should have ":".
(In reply to comment #22) > > Should we move the bug owner, reporter, cclist and commenter check > > boxes up in between Email text field and the substring combo? This could help > > associate those check boxes with the email field while keeping the nice > > vertical alignment of the combo boxes on the right. > > It was like that before, but it wasn't looking good. You can try it of course. Tried it but didn't like it. Perhaps we need a different widget here. (In reply to comment #23) > BTW, right-aligning labels in dialogs is rather unusual for Eclipse UI. See Find > dialog, CVS repo configuration, Mylar's own issue tracker repo configuration, > Preferences / network configuration, and endless number of others standard > Eclipse dialogs. Hmm yes, which is unfortunate because it seems a lot less legible. Reverting. > Also, it seem like labels for all lists should have ":". Done.
Excellent! Added to New & Noteworthy.
btw, when's the next version of Mylyn ship?
Every freakin' Friday :-) but official plan is right here http://wiki.eclipse.org/Mylyn_3.0_Plan
As mentioned at the top of that page, that plan is still tentative, and I just updated the 2.1M1 release to Monday (will post to mylyn-dev about this shortly, might change all the build dates to Mondays since we have always tended to announce on Monday). As Eugene points out a new build is available every Friday and we encourage users to get the latest: http://www.eclipse.org/mylyn/downloads/builds.php
The updated code has the slight regression of not remember the dialog's size (e.g. height). This is important to fix because it is common to make the task search dialog taller and annoying to have to do it repeatedly, and because it resets other search page's setting of the height. Rob: please investigate.
(In reply to comment #29) > Rob: please investigate. This was done to resolve bug#198493. Closing this one and reopening 198493.
