On 2/22/21 11:08 AM, Svata Dedic wrote:
Dne 22. 02. 21 v 17:37 Laszlo Kishalmi napsal(a):
That's Ok, though I'm going to put the dev list in the cc. There is
nothing secret on this, and I do not mind if someone else would give
feedback on the topics. But at least these discussions are open.
Perfect. I sent it off the list just as a "wake-up ping", but the tech
details should be discussed here.
1. NetBeans does not use tri-state checkboxes. Introducing one here
would be a bit alien. Combo box would be Ok for the UI.
I though we've already agreed to change the UI to a combo - I'll do
that, but if you have some preferred wording, please suggest, so we
can avoid some iterations over that.
2. I would go as simple as it can be detecting the LSP (or just
headlessness, by checking java.awt.headless property), for putting up
Then I'd propose to use the 'branding API'. We had headlessness check
on other places, either historically or introduced in early LSP
implementation, and we are already converting those checks to checks
for a brandable bundle key. A distributor assmebling the app then can
tweak the behaviour the way needed.
I'd then keep the dialog re-implementation as it is in PR#2769, but
let it include individual buttons (except cancel :) based on resource
keys; the default would be just as in NB 12.3 - OK, Turst, Cancel.
Would it be OK ?
That's a good question. First I'd like to ask what kind of usecases
do we want to support. If it just a generic Gradle build command line
For the LSP client, the usecase is just to "run user application" with
parameters specified in a way native for the client. For example
VScode has its own configuration (in ./.vscode) that its UI interacts
with somehow From the perspective of LSP client (vscode) user, she/he
may edit certain parameters in his/her favourite editor and use
standard Run/Debug actions.
For other IDE users, this makes a possibility for
maven/gradle/whatever other project to allow an action that launches
an app with specific parameters without modifying the project files.
Such an action is surely possible even now - with fully separated
implementations in Maven / Ant / Gradle. With the new API in place and
supports done, the action UI can be shared.
I do not plan to implement such features at the moment, however.
decorator, then it's probably fine. What I would like to mention,
that this might add a parallel path to the existing
ActionMappingProvider API.
I thought about the feature as a decorator. Even the API is designed
so that the ExplicitProcessParameters instructions *modify* the
existing ones (append or replace).
Could you please elaborate more on the 'parallel path' concept ?
That was meant to be as, just another way of do the things which already
can be done. It is possible for modules to register their own
GradleActionMappingProvider which can return an command line for an
action. Right now the only issue that the usage at this provider the
code treats as only one provider can be active at a given time and does
not allow fallback chaining. (Probably introducing a lookup merger would
do for that)
Also in Gradle run task does not really take arguments unless --debug-vm
parameter processing shall be done in the Gradle build file instead.
I was thinking the action mapping was much more powerful, and actually
create a complete environment for the user code execution. Application
arguments (or launcher aguments = VM params) is just a well-defined
part of such action definition, which can be passed separately; if
there was some well-defined concept of 'verbosity' or 'error level',
that would fall into the same pattern. I believe that if such things
are needed in the future, the ExplicitProcessParameters can be
compatibly extended to cover it.
Regards,
-Svata
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
