I've submitted a PR (https://github.com/apache/jmeter/pull/360) for the menu re-ordering. Testing, critiques and any major disagreements with my proposed order very much welcomed!
I've tried to keep it simple for the time being. We could add another item to the annotation, e.g. groups, which could then define more than the current (specifically ordered vs. the rest). The search box might take me a while, my swing GUI skills are lacking, and I might not get time before Christmas to work on it. I'm starting to like the idea of grouping plugins in their own sub-menu as this might make it more obvious for beginners and easier if you need a lot of plugins, then again, a palette with up to 10-15 things "ought to be enough for anybody". Thanks Graham On 12 December 2017 at 16:58, Vincent HERILIER <vheril...@gmail.com> wrote: > Maybe could we propose different layouts (full flat (default ?), full > grouped, plugin only... defined by a property) mixed with LRU proposition, > Search box... accordingly to user preferences/habits/needs ? > > > > Le mar. 12 déc. 2017 à 16:40, Vincent HERILIER <vheril...@gmail.com> a > écrit : > >> In the PR, I proposed, I grouped JMeter native elements as example, but >> the PR insured to let some elements at their initial place (JMEter ones to >> keep its current usability) and allow others to be grouped (3rd party ones >> if required and proposed by their related maintainers). >> So it was just allowing the feature, it didn't ordered it. >> >> Maybe it could be no more compatible with some evolutions you planned and >> that avoids it anyway. >> Or we could try to make these approaches complementary too... >> >> Anyway, I stay really interested in JMeter usability improvement. >> >> Le mar. 12 déc. 2017 à 16:15, Graham Russell <gra...@ham1.co.uk> a écrit : >> >>> Ah, I didn't appreciate the use case you had. >>> >>> I still think the additional menu groupings would be detrimental to more >>> common use cases. >>> >>> Perhaps we can keep plugin menus ordered separated from the native ones >>> this might help slightly. I will make sure I test my changes with some >>> plugins! >>> >>> I was thinking to keep a LRU list in the search box results which should >>> speed things up for most use cases. >>> >>> Graham >>> >>> >>> On 12 December 2017 at 14:15, Vincent HERILIER <vheril...@gmail.com> >>> wrote: >>> > I clearly understand your points of view. >>> > >>> > But with plugins used in my case (and average 300 testers) which bring >>> > average 40 config elements and 90 samplers, they are mixed (with JMeter >>> > native ones too) for complex and cross-protocol flows we would like to >>> > simulate (average 15 protocols - new , redefined protocols or server >>> side >>> > part - for our needs coverage). >>> > >>> > Reconfiguring a palette does not really solve my issue because the range >>> of >>> > required elements changes often or is wide each time. >>> > Loading and using a search box often will not really a gain of time too. >>> > >>> > That's why a protocol grouping is IMHO and in my specific use-case more >>> > accurate and quickly usable. >>> > I hope beiing wrong and I'm waiting for a quicker menu navigation >>> mechanism >>> > even it is not a submenu one ;). >>> > >>> > Thanks for all the work you provide to improve JMeter. >>> > >>> > Vincent >>> > >>> > Le mar. 12 déc. 2017 à 14:29, Graham Russell <gra...@ham1.co.uk> a >>> écrit : >>> > >>> >> I agree with Phillipe that adding more menus, and therefore steps to >>> >> get to items you need (key presses or mouse moves) and items to read >>> >> is not an improvement. >>> >> >>> >> I like the idea of a configurable palette (with some sensible >>> >> defaults), much easier for beginners. >>> >> >>> >> This still requires use of the mouse, so for more advanced users, what >>> >> do we think of introducing a "find/search"? >>> >> Pressing ctrl+shift+a loads a pop-up search box, as you type it >>> >> filters the list and you click/press enter on the one you want and >>> >> it's added to the tree. >>> >> >>> >> On 12 December 2017 at 13:11, Philippe Mouawad >>> >> <philippe.moua...@gmail.com> wrote: >>> >> > Hello, >>> >> > I am personally against an additional level in the popup menu as it >>> would >>> >> > be a loss of time. >>> >> > If it's about reorganizing the menu order to put most popular ones on >>> >> top, >>> >> > why not. >>> >> > >>> >> > A configurable palette in the right or bottom left (now we have >>> dropped >>> >> > workbench) might be a better alternative. User could put here the >>> >> elements >>> >> > he uses the most. >>> >> > >>> >> > Regards >>> >> > >>> >> > >>> >> > >>> >> > On Tue, Dec 12, 2017 at 2:05 PM, Vincent HERILIER < >>> vheril...@gmail.com> >>> >> > wrote: >>> >> > >>> >> >> Hi, >>> >> >> >>> >> >> I already proposed a PR in that way ( >>> >> >> https://github.com/apache/jmeter/pull/236) and I'm still >>> interested in >>> >> >> having the capability to group some elements ,per protocol class for >>> >> >> example, to reduce the amount of different menus entries shown. >>> >> >> >>> >> >> Vincent >>> >> >> >>> >> >> Le mar. 12 déc. 2017 à 10:07, Antonio Gomes Rodrigues < >>> ra0...@gmail.com> >>> >> a >>> >> >> écrit : >>> >> >> >>> >> >> > Hi, >>> >> >> > >>> >> >> > About advanced mode, some code has been written and maybe we need >>> to >>> >> >> remove >>> >> >> > it and discuss again and finish it. >>> >> >> > >>> >> >> > Yes, it's hockey. >>> >> >> > >>> >> >> > >>> >> >> > For the moment I have few free time but I probably write some blog >>> >> post >>> >> >> > (Apache provide blog) about some features. >>> >> >> > >>> >> >> > Thanks to the PR >>> >> >> > >>> >> >> > Antonio >>> >> >> > >>> >> >> > >>> >> >> > 2017-12-11 21:00 GMT+01:00 Graham Russell <gra...@ham1.co.uk>: >>> >> >> > >>> >> >> > > Ah ok, I noticed something about advanced mode and wondered what >>> it >>> >> >> > meant, >>> >> >> > > probably worth tidying up? >>> >> >> > > >>> >> >> > > I think those hotkeys should be more prominently documented, I >>> only >>> >> >> > > recently discovered them, or are there other shortcuts you were >>> >> >> referring >>> >> >> > > to? >>> >> >> > > >>> >> >> > > I will attempt a PR with a proof of concept in the coming week. >>> >> >> > > >>> >> >> > > Thanks >>> >> >> > > >>> >> >> > > Graham >>> >> >> > > >>> >> >> > > On Mon, 11 Dec 2017, 09:21 Antonio Gomes Rodrigues, < >>> >> ra0...@gmail.com> >>> >> >> > > wrote: >>> >> >> > > >>> >> >> > > > Hi, >>> >> >> > > > >>> >> >> > > > Sometime ago we have discuss to have an advanced mode with all >>> >> >> options >>> >> >> > > and >>> >> >> > > > an basic mode with only the essentials. Unfortunately there >>> was >>> no >>> >> >> > > > consensus >>> >> >> > > > >>> >> >> > > > For the moment we have shortcuts >>> >> >> > > > >>> >> >> > > > +1 for your solution >>> >> >> > > > >>> >> >> > > > Antonio >>> >> >> > > > >>> >> >> > > > >>> >> >> > > > 2017-12-10 19:36 GMT+01:00 Graham Russell <gra...@ham1.co.uk >>> >: >>> >> >> > > > >>> >> >> > > > > Hi all >>> >> >> > > > > >>> >> >> > > > > Currently the menus are ordered alphabetically, which is >>> fine >>> >> for >>> >> >> > > > > small menus, and better than not at all for the large ones, >>> >> >> however I >>> >> >> > > > > think we can do better. >>> >> >> > > > > >>> >> >> > > > > If the menu has more than 4-5 items in it I think we should >>> >> split >>> >> >> it >>> >> >> > > > > up into chunks of 5-7 with the most popular (e.g. HTTP >>> Request >>> >> >> > > > > Sampler) at the top. I hope this would ease a bit of RSI for >>> >> users >>> >> >> > and >>> >> >> > > > > help improve the usability. >>> >> >> > > > > >>> >> >> > > > > Any thoughts? >>> >> >> > > > > >>> >> >> > > > > Having looked at the code it seems the menus are built by >>> >> looking >>> >> >> at >>> >> >> > > > > the classes, does adding an annotation with "sort order" and >>> >> maybe >>> >> >> > > > > "group" make sense or is there a better way to dictate the >>> >> order of >>> >> >> > > > > items in the menus? >>> >> >> > > > > >>> >> >> > > > > Thanks >>> >> >> > > > > >>> >> >> > > > > Graham >>> >> >> > > > > >>> >> >> > > > >>> >> >> > > >>> >> >> > >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Cordialement. >>> >> > Philippe Mouawad. >>> >> >>> >>
