wiki.netbeans.org backup was: Heads-up: netbeans.org EOL on March 6th

[Jaroslav Tulach]

Dne středa 24. února 2021 7:04:40 CET, antonio napsal(a):
> About the wiki.netbeans.org backup, quoting from [1]:
> 
> Well, this was expected, of course. Would it be possible to get a copy
> of the wikimedia archive from Oracle, anyone?

I'll try to get the backup. This would be the manual: 
https://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki

-jt


> [1]
> https://issues.apache.org/jira/browse/INFRA-21463?page=com.atlassian.jira.pl
> ugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=17289643#comm
> ent-17289643





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

QuickPick API was: Gradle fixes & heads up

[Jaroslav Tulach]

> Maybe (after this PR discussion!) there's also a need to consider
> adding more NotifyDescriptor types with this in mind?  eg. something
> like NotifyDescriptor.Choices?

+1

There is a `QuickPick` support used in `java.lsp.server` - having a standard 
Swing/VSCode abstraction would be great:

https://github.com/apache/netbeans/blob/
f82594d88acf58c14722d3460558d19c0d6744d7/java/java.lsp.server/src/org/
netbeans/modules/java/lsp/server/protocol/DelegateMethodGenerator.java#L186

-jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Dark title bar in NetBeans 12.3

[Mark Herkrath]

Hi all,

Now that NetBeans 12.3 is using a recent FlatLaf version, it would be possible 
to have a dark title bar under Windows 10. In beta 3, it’s still not enabled 
though. I always felt the Windows 10 default, light title bar with FlatLaf dark 
theme to be pretty distracting, especially in full screen mode. It’s also light 
if Windows itself is running in dark mode.

More information on the dark title bar with FlatLaf can be found here: 
https://github.com/JFormDesigner/FlatLaf/releases/tag/0.37 


I have tweaked my NB dev version accordingly. Please see screenshots at 
https://i.imgur.com/P0Xmp6T.png  (I think it’s 
not possible to send images to here). My current version is not mergeable 
though, as it’s just a quick PoC. It’s just about calling
JFrame.setDefaultLookAndFeelDecorated(true);
JDialog.setDefaultLookAndFeelDecorated(true);

and setting
TitlePane.menuBarEmbedded=false

If desired, I could provide a merge request but I would need some questions to 
be answered first. Likely it is easier if someone with knowledge about NetBeans 
L&Fs would just add it.

Regards,
Mark

Re: Heads-up: netbeans.org EOL on March 6th

[Bertrand Delacretaz]

Hi,

On Tue, Feb 23, 2021 at 3:26 PM Jiří Kovalský  wrote:
> ...Long live to https://netbeans.apache.org domain! :) ...

FWIW, it might be good to create a "what happened to netbeans.org"
page or FAQ entry on http://netbeans.apache.org/

I bet that would save many explanations in the future, by pointing any
questions to that URL.

-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Gradle fixes & heads up

[Neil C Smith]

On Mon, 22 Feb 2021 at 16:37, Laszlo Kishalmi  wrote:
> On 2/22/21 12:53 AM, Svata Dedic wrote:
> > In particular I need to finalize one of the solutions outlined in
> > https://github.com/apache/netbeans/pull/2769 --
>
> 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
> the trust dialog.

FWIW, I think moving to dialogs that don't use custom Swing components
wherever possible is a good move, both for uniformity as well as
headless / non-Swing usage.

Maybe (after this PR discussion!) there's also a need to consider
adding more NotifyDescriptor types with this in mind?  eg. something
like NotifyDescriptor.Choices?

Best wishes,

Neil

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Gradle "Run with Parameters" [was: Re: Gradle fixes & heads up]

[Svata Dedic]

A sidenote: splitting the conversation, as it really deserves two 
threads. This one should discuss the proposed "Run with Parameters 
feature for gradle.


But the original thread ("Gradle fixes & heads up") contains also other 
stuff related to the existing stalled PRs[2],[3] - Laszlo, would you 
please look at the mail[1] again - I think there are still some 
questions unanswered that would help me to finish the implementation.


=

Dne 23. 02. 21 v 6:50 Laszlo Kishalmi napsal(a):


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 


GradleActionMappingProvider ... I could only find 
ProjectActionMappingProvider and GradleActionsProvider; I suppose it's 
ProjectActionMappingProvider as that one actually creates the 
implementation.


I saw a complete replacement as quite heavyweight ... but looking at the 
ProjectActionMappingProviderImpl, the impl is very lightweight (unlike 
Maven ;)).


So at worst, a supposed "LSP Gradle" module would provide a replacement 
for project run, debug, profile actions + suck (somehow) the rest of 
actions from standard Gradle support ?


Still I could need (somehow) to tunnel down to GradleDaemonExecutor so I 
could eventually affect its buildLauncher.setEnvironmentVariables() [see 
below]. Can you think of a feasible way ?


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.


Well, I though that --args="application arguments" can be passed on the 
commandline (documented since Gradle 4.9).


For client JVM arguments, this will be tougher. Searching through 
documentation, it MAY be possible to use JAVA_OPTS environemnt variable. 
According to the documentation, gradle daaemon would use that one when 
launching client JVM. Granted, this approach would be only applicable 
for Java execution at the moment.


The question is how can the IDE know / parse the default JVM args 
(applicationDefaultJvmArgs) so it can decorate it ?


Anyway, I am going to prototype it (somehow), maybe I've misunderstood 
the docs.


Let me put the question other way around. Imagine an action that allows 
the user to parametrize the application ad-hoc:


+-+
| |
| Mode:[Run v]}
| App parameters:  [.]|
| Extra VM params: [.]|
|
|[  OK  ]   [ Cancel] |
+-+

but written in a way *that can be scripted, or automated* from another 
module, so no GUI is displayed by the action itself (if it gets right 
instructions) - perhaps the caller has its own GUI. Can execute run, 
debug, profile, eventually even debug-single (if run on a file).


This action can now be implemented, depending on Project API + Execution 
API only and will work for Maven projects. I guess I could (and probably 
should, for consistency) change Ant projects to support the abstract 
'parameters' interface.


So let's try to explore how that could be achieved with Gradle. It may 
even require some specific property to be introduced in the project (its 
build.gradle), so this level of integration could work ! But that's 
"just" a matter of documentation for the supposed action (well, in our 
current case for the VSCode client).


Cheers,
-Svata

[1] 
https://lists.apache.org/thread.html/rdcf2ce3f11ee4a46bdeb030f9b8309570d9f5007a8b099f77445c06c%40%3Cdev.netbeans.apache.org%3E

[2] https://github.com/apache/netbeans/pull/2769
[3] https://github.com/apache/netbeans/pull/2768

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists