jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milamber <>
Subject Re: Proposal for some changes in Menus
Date Fri, 29 Apr 2016 19:31:48 GMT

On 29/04/2016 20:06, Philippe Mouawad wrote:
> Hi,
> >From the 3 proposals, can we retain only the move of Function Helper Dialog
> to Help menu ?

No, I thinks that is a bad idea. Help menu is use generally for the 
help, about product, etc., not to an option like FHD (kind of function 

Perhaps, the Options menu would be rename Tools menu...

> Thanks
> On Wed, Apr 27, 2016 at 11:11 PM, Epp, Jeremiah W (Contractor) <
>> wrote:
>>> -----Original Message-----
>>> From: Philippe Mouawad []
>>> Sent: Wednesday, April 27, 2016 16:47
>>> To:
>>> Subject: Re: Proposal for some changes in Menus
>>> On Wed, Apr 27, 2016 at 10:40 PM, Epp, Jeremiah W (Contractor)
>>> <
>>>> wrote:
>>>>> -----Original Message-----
>>>>> From: Philippe Mouawad []
>>>>> Sent: Wednesday, April 27, 2016 15:27
>>>>> To:
>>>>> Subject: Re: Proposal for some changes in Menus
>>>>> Either we spend time on fixing it but IMO it is not worth the
>> investment.
>>>> Is the issue really that bad?
>>> No but I don't like "buggy features" :-)
>> I was thinking more about the actual bug that causes the deferred/partial
>> update of the UI.  That is, are you sure it would be a major time sink that
>> touches a lot of code?  Or could it be a relatively simple fix?  (I could
>> see it going either way depending on how it's all set up, but I haven't
>> looked at all.)
>>>> It's far better to have something janky that users might have a chance
>> of
>>>> finding when they need it.
>>> I think a bug in a feature does not help reputation of a product.
>> More than the apparent lack of the feature? ;)
>>>> Please, no, properties seriously suck.  They're about as opaque as you
>> can
>>>> possibly get for configuring a GUI application.  They're basically a
>>>> non-mechanism from a user standpoint.
>>> They will soon be fully documented.
>> How will that be exposed/communicated to users, though?  That's possibly
>> even more important.
>> Most users have the mindset that nothing can change and they suffer
>> through whatever the defaults are.  It's much worse when the option is all
>> but invisible.
>>> But I agree properties are not optimal
>> I think the biggest issue they have is that you can't actually set them
>> from within the application itself.  Even if it's an option that "(Requires
>> Restart)", that's something people understand.
>>> Happy to know I am not the only user to face it.
>>> In the future, please report any issue you face don't live with it .
>> Yeah, I figured it was already known (or maybe fixed seeing as we're in
>> the 3.0 RC phase) and there was a lot of other stuff going on.  I'll try to
>> get some time set aside for reporting a bunch of bugs, though.
>>>> It's just, burying things in properties is a sure way to ensure the
>>>> options never even get used at all.
>>> What do you think about my proposal to at least display a popup message
>> to
>>> tell user to restart JMeter ?
>> Yeah, a warning that things might be weird until they restart would be a
>> good call.
>> Regards,
>> Wyatt
>> Confidentiality Notice: This electronic message transmission, including
>> any attachment(s), may contain confidential, proprietary, or privileged
>> information from Chemical Abstracts Service ("CAS"), a division of the
>> American Chemical Society ("ACS"). If you have received this transmission
>> in error, be advised that any disclosure, copying, distribution, or use of
>> the contents of this information is strictly prohibited. Please destroy all
>> copies of the message and contact the sender immediately by either replying
>> to this message or calling 614-447-3600.

View raw message