> Some time ago I wanted to add an API that allowed for pluggable service
> providers for image and text branding resolution. This would also allow for
> platform apps to do things they can't currently do. The suggestion got a -1
> so I didn't pursue as far as code - it was in discussion
> Given that one of my degrees was in Graphic Design, I thought I would have a
> look at the problem.
Excellent!!
> I am currently working on building some spreadsheets of all gif, png and svg
> files in the netbeans app. This is very time consuming since none of my
> search apps allows copy
Removing Java 1.5 support from the profiler seems fine.
(And as others have pointed out, the profiler is _really_ useful! I use it
frequently.)
-- Eirik
-Original Message-
From: Laszlo Kishalmi
Sent: Friday, September 18, 2020 10:24 AM
To: Apache NetBeans
Subject: [DISCUSSION]
On 9/18/20 7:24 AM, Laszlo Kishalmi wrote:
One of the gray areas we have is the profiler support.
The NetBeans Profiler has been quite helpful in the past -- especially
for heap usage. Lately, though, I find the Async Profiler [1] to be the
best tool by far.
As an example of its utility,
Hi, Jeremy.
> I did send in an email indicating that I was looking at the problem. No
> response from anyone!
Hmm, I can't seem to find the email in question. Which one was this? (There was
one which I responded to, " Is there a single repo for all the current icons in
netbeans".)
Are you
very thanks to Jeremy and all the others to engage to find a good and
practicable way to
come to an svg iconset. I am following this topic with interst but I do know
now how to help.
> Hi All,
>
> I'm going to get a bit ratty about these exchanges over svg icons. I did
> send in an email
On Fri, 18 Sep 2020 at 17:41, Laszlo Kishalmi wrote:
> 2. Add some API around the icon names, so the place of the usage would
> be decoupled from the place of the storage.
Some time ago I wanted to add an API that allowed for pluggable
service providers for image and text branding resolution.
Would it help to do the following?
1. Create one module per cluster where we pull all the images together.
2. Add some API around the icon names, so the place of the usage would
be decoupled from the place of the storage.
3. Normalize the storage inside the icon module
3. Create some build
On Fri, 18 Sep 2020 at 17:04, Jeremy Cavanagh wrote:
> We need a different approach to the icons, they should be held in a
> single place. At the moment they are littered throughout the code like
> discarded toffee wrappers.
+1 to all of it, particularly +1 to this. I've said before I think we
Hi All,
I'm going to get a bit ratty about these exchanges over svg icons. I did
send in an email indicating that I was looking at the problem. No
response from anyone!
Yet, there is a continuous drivel of discussion about this topic and not
many people have got the point.
THIS IS NOT
It is probably pulling Java9+ from your env path.
In addition to setting nbjdk.home, try
export PATH=/usr/lib/jvm/java-1.8.0-openjdk-amd64/bin:$PATH
On Fri, Sep 18, 2020 at 1:39 AM Jack W. wrote:
> Weird. I created nbbuild/user.build.properties with one line:
>
>
NetBeans personal rust remover - I like it!!
Seriously, I really like that title!! 8-)
-brad w.
On Fri, Sep 18, 2020 at 8:24 AM Laszlo Kishalmi
wrote:
>
> Brad Walker, NetBeans personal rust remover, has offered a help to get
> rid of the 1.5 profiler support.
>
>
About
[7] NETBEANS-4791: error badges for xxx.fxml file do not propogate to
tabs or project window
depends on NETBEANS-4745 (/which has just been merged/)
Because of other problems, particularly around refactoring and modular
java, errors can be introduced into the .fxml files. Fixing
Sounds good to me.
Gj
On Fri, 18 Sep 2020 at 16:24, Laszlo Kishalmi
wrote:
> Dear all,
>
>
>
> One of the gray areas we have is the profiler support. The build does
>
> not really rebuild the source code with each release, just downloads
>
> some dusty zips and populate it's content. If we
Dear all,
One of the gray areas we have is the profiler support. The build does
not really rebuild the source code with each release, just downloads
some dusty zips and populate it's content. If we would like to move
forward from this state, I think it's time to leave some rusty parts behind.
Ahoj Sváťo,
thanks a lot for undertaking the uneasy quest of "Fixing commit validation"
and eliminating all the debris introduced since it got disabled. Validation
is important for proper ordering, behavior and smooth start without tons of
useless warnings. Unless I am mistaken it contains tens of
16 matches
Mail list logo
