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 ?
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
