Screenshots: documentation, pull requests

[Vladimir Sitnikov]

Hi,

JMeter heavily relies on the UI, and would probably be nice if we could
have machinery for automated screenshot generation.

I see the following issues with the current screenshots:
1) They are often out of date
2) Image quality is not always good (e.g. LowDPI image does not work for
HiDPI screen)
3) Image themes are not consistent. One screenshot can be dark, another can
be light, and so on :(

What do you think if we replace screenshots with automatically generated
ones?

I've created a draft PR: https://github.com/apache/jmeter/pull/574
I implement a small class that instantiates GUI components and generates
PNG files out of it.

So far my findings are:
a) The full set of screenshots takes ~7 megabytes (or ~3.5 after pngquant).
We would probably want to keep screenshots in another repository.
Otherwise, we could pollute the main source repository with images quite
fast.
b) Different operating systems have slightly different rendering because
the default fonts are different
c) If we use a different repository for storing screenshots, then we could
render even multiple themes and add "preferred theme" switch to the website
d) A single component might need more than one screenshot (e.g. HTTP
request have multiple tabs)


Any thoughts?

Vladimir

Re: Replacing nashorn

[Vladimir Sitnikov]

There might be yet another option.

It might be that Nashorn would be moved to a community-managed library
(e.g. like JavaFx became OpenJFX).


>Is Nashorn or its replacment needed for *all* test plans?

Some of the plans depend on Nashorn, and some of them do not.

Vladimir

Re: Replacing nashorn

[Philippe Mouawad]

If users don't follow best practices, then yes (If Controller and While
Controller use Javascript so nashorn).
But if we switch to rhino as default JS engine, it should work in 99% of
cases.

If it's overkill, maybe it's not worth investing in this.
Noting that IMO, JS is bad for JMeter performances.
The best thing would be to make IfController / While Controller use JEXL3
by default instead of JS, but how to manage transition in a clear way ?

Regards


On Wed, Mar 25, 2020 at 6:37 PM sebb  wrote:

> Is Nashorn or its replacment needed for *all* test plans?
> If not, then another alternative is to document how to download it,
> and report a suitable error if a test plan needs it.
>
> On Mon, 23 Mar 2020 at 17:57, Felix Schumacher
>  wrote:
> >
> > The third option would be to go back to rhino, which is included in
> jmeter anyhow.
> >
> > Wouldn't it?
> >
> > Felix
> >
> > Am 23. März 2020 16:59:43 MEZ schrieb Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com>:
> > >up.
> > >
> > >Graal.JS seems to be mature now.
> > >It can run on any Java machine:
> > >
> https://github.com/graalvm/graaljs/blob/master/docs/user/RunOnJDK.md#run-graalvm-javascript-on-a-stock-jdk
> > >
> > >The licenses there are MIT and/or UPL (both are permissible for Apache)
> > >
> > >The sad thing is that Graal.JS is ~20 megabytes extra.
> > >
> > >
> > >It is extremely likely Nashorn will be removed from Java 15, so we need
> > >to
> > >deal with it somehow.
> > >
> > >So the options are:
> > >a) Bundle Graal.JS (+20MiB :( )
> > >b) Document the way to add Graal.JS jars as an external dependency
> > >(everybody would need to download the file manually :( )
> > >c) Add an option to download Graal.JS on demand (not that trivial to
> > >implement, yet useful for many(!) other cases)
> > >
> > >WDYT?
> > >
> > >Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Re: Replacing nashorn

[sebb]

Is Nashorn or its replacment needed for *all* test plans?
If not, then another alternative is to document how to download it,
and report a suitable error if a test plan needs it.

On Mon, 23 Mar 2020 at 17:57, Felix Schumacher
 wrote:
>
> The third option would be to go back to rhino, which is included in jmeter 
> anyhow.
>
> Wouldn't it?
>
> Felix
>
> Am 23. März 2020 16:59:43 MEZ schrieb Vladimir Sitnikov 
> :
> >up.
> >
> >Graal.JS seems to be mature now.
> >It can run on any Java machine:
> >https://github.com/graalvm/graaljs/blob/master/docs/user/RunOnJDK.md#run-graalvm-javascript-on-a-stock-jdk
> >
> >The licenses there are MIT and/or UPL (both are permissible for Apache)
> >
> >The sad thing is that Graal.JS is ~20 megabytes extra.
> >
> >
> >It is extremely likely Nashorn will be removed from Java 15, so we need
> >to
> >deal with it somehow.
> >
> >So the options are:
> >a) Bundle Graal.JS (+20MiB :( )
> >b) Document the way to add Graal.JS jars as an external dependency
> >(everybody would need to download the file manually :( )
> >c) Add an option to download Graal.JS on demand (not that trivial to
> >implement, yet useful for many(!) other cases)
> >
> >WDYT?
> >
> >Vladimir

Jenkins build is back to normal : JMeter Windows #1641

[Apache Jenkins Server]

See 

Jenkins build is back to normal : JMeter Ubuntu #988

[Apache Jenkins Server]

See 

Re: Undo/redo: does anybody use it?

[Vladimir Sitnikov]

>Indeed, undo is only within current active selection.

Ok. I just thought we could start with `undo for edit fields within the
current tree selection`.

In other words, reset all undo history when the test plan element is
re-selected.
I guess we could be able to release that activated by default, so
people could start using undo/redo.

A bit of a problem with that is it is required to attach undo listeners to
all the fields, and the fields can even be created dynamically :-/

I see two approaches:
a) when component UI is created, we can scan the component hierarchy, and
add the listeners to all JTextField-like objects in the tree
b) require that all JTextField must pass through a special API to add undo
listeners

Any thoughts on that?
I'm inclined to #a because changing all new JTextField with new
JMeterTextField would look like changing 100500 files out of thin air.

Vladimir