Re: Visualization of NetBeans packages

There aren't supposed to be any dependency cycles so I wonder what would happen if you rendered it as a DAG? On 05/13/18 20:56, Tim Boudreau wrote: If you took out a few apis used by almost everything - filesystems, utilities, progress, data systems in particular, it's not actually that bad.

Re: Visualization of NetBeans packages

If you took out a few apis used by almost everything - filesystems, utilities, progress, data systems in particular, it's not actually that bad. -Tim On Sun, May 13, 2018 at 6:55 PM Dmitry Avtonomov < dmitriy.avtono...@gmail.com> wrote: > And that horrendous glob of interdependencies is

Re: Visualization of NetBeans packages

And that horrendous glob of interdependencies is supposed to be a "loosely coupled system"? com.oracle.javafx cluster is nicely disconnected though :) On Sun, May 13, 2018 at 12:51 PM, Efrem Mc wrote: > Hi Tim, that is pretty awesome! > > The 3d graph is nicely connected

Re: AW: AW: (Git) Diff Window horizontal space rescue

> Hmm. Developers who want to do real coding should use real hardware. > > > > Seriously though, there is some minimum screen real-estate we should > > design for. iPads and 13" monitors are a non-target in my opinion. > > Portability comes at a cost of productivity. People using such devices

Re: Visualization of NetBeans packages

Hi Tim, that is pretty awesome! The 3d graph is nicely connected and with all the 3d effects. You give is a top level input for the master node, and it follows all the dependencies? Thanks for sharing. Efrem McCrimon On Sun, May 13, 2018 at 1:52 PM, Tim Boudreau

Visualization of NetBeans packages

I was playing with the code that used to live in contrib/callgraph - something I wrote when I was working on graph analytics stuff for Oracle Labs, and added d3-friendly output to it. Then ran across a library that does 3d visualization on top of that. Here is a graph of package dependencies for

Re: AW: AW: (Git) Diff Window horizontal space rescue

Hmm. Developers who want to do real coding should use real hardware. Seriously though, there is some minimum screen real-estate we should design for. iPads and 13" monitors are a non-target in my opinion. Portability comes at a cost of productivity. People using such devices should expect

Re: Expose Caret Settings in Editor Options

I dunno, I can't really compare -- last I heard about caret blink rate was years ago. I guess we could look at votes in the old Bugzilla to see the most requested features and such? Anyhow, I'm not really bothered by this config being added, but the idea is not to add UI for everything. >

Re: AW: AW: (Git) Diff Window horizontal space rescue

Too bad we don't have any statistics about NetBeans usage anymore. I also only use my 15" MacBook Pro without any external display. I briefly used an external display for a Linux VM where I had another NetBeans running :-) So, I never use NetBeans in a true multi-display setup. At least for

AW: AW: (Git) Diff Window horizontal space rescue

I think this is a real Problem, not everyone have big enough Monitors. Sure if you are working with a Docking Station, this is Maybe not a big Problem but if you have your Laptop with your, e.g. on a coding session at a conference, then this is a Problem. I can Show you some other Problems with

AW: Expose Caret Settings in Editor Options

The Options window, should similar and consistent to the Project properties. This is not only to make it consistent, it is a UX Thing, because now you can’t see the Options and Sub Options of each Option. But sure this is an other Topic. But I saw this discussion here and wanted to jump in.

AW: Expose Caret Settings in Editor Options

There can’t be enough Options to customize to your Needs. There are lot of Options missing (Change Code completion dleay e.g.). So we can’t fit any Needs, but we can customize a lot of Features via Options, but the current Option window is not good to have this. This is where we should care

Re: Expose Caret Settings in Editor Options

I get your point and I think it's a very difficult balance to make. We don't want to overload the IDE with UI. However, at the same time, I don't see there being hundreds of requests for new configuration options, instead, I have seen about three or four coming up again and again, really, in

Re: Expose Caret Settings in Editor Options

-0.5 This seems like something a plugin could easily provide. Normal users would just use NetBeans and have a clean UI while users that search for more customisations just use the plugin. The important part is having the API support for this (which we do), not adding more and more UI. I feel