Posted by
Kenneth Sloan-2 on
Feb 27, 2018; 10:14pm
URL: http://imagej.273.s1.nabble.com/controlling-size-and-location-of-Console-window-tp5020161p5020174.html
I understand, and agree with, the reasoning on what the Console is, and what it is good for.
As noted - I tend to use stderr because a lot of my code is not ImageJ specific, and I like to use
the minimum number of mechanisms.
I can live with the current situation, but I look forward to the day when the Console will be just a *little* more integrated into the ImageJ environment. While I appreciate the pointer to the "Console Manipulator" - it simply involves too many new things to keep track of - for not quite enough benefit.
For *my* purposes, it would be necessary, and sufficient, to have an IJ-level call to get some sort of handle on the Console window, (call it "foo") and 4 methods:
LOCATION foo.getLocation()
void foo.setLocation(LOCATION l)
BOUNDS foo.getBounds()
void foo.setBounds(BOUNDS b)
Actually, the foo.get...() are optional; I include them for symmetry.
I'm agnostic on the form of a "location" or a "bounds". Whatever matches other, similar, ImageJ methods. If only the foo.set...() methods are implemented, I'd be happy with individual int variables (x,y,width,height). But, I'm old-school. Feel free to use nice aggregate classes. But please - do this one way or the other; not both!
Of course, other people might like other bells and whistles (fonts, colors, ...).
I'd rather have the above 4 methods ASAP (better - just the 2 foo.set...() methods), rather than waiting for the "best" implementation. For me, that's the most bang for the buck improvement over the current situation.
Actually, an interesting solution is:
LOCATION foo.setLocation(LOCATION l)
BOUNDS foo.setBounds(BOUNDS b)
Where the returned values are the OLD values - perhaps even with the twiddle that the parameters are allowed to be null (indicating no change). That gives you all possible variants on get/set in one swell foop.
One medium-priority option might be a "Save to File" button, and a corresponding Java method.
This would be a convenient way to have an end-user simply push the "Save to File" button and send me the complete log of their session.
Yes...I know...I should probably use the multi-level logging facility. See previous comments on "most of what I write is not ImageJ specific". I'm happy to use logging for the top level Java plugin code, but I can't "pollute" my foundational classes with IJ-specific stuff. This is why I'm so grateful to have a usable stderr!
That's a lot of nits to pick - please don't mis-understand. I am very glad to have the current Console, and very appreciative of the fast responses to my grumblings.
--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html