Posted by
ctrueden on
Feb 27, 2018; 11:05pm
URL: http://imagej.273.s1.nabble.com/controlling-size-and-location-of-Console-window-tp5020161p5020175.html
Hi Ken,
> have an IJ-level call to get some sort of handle on the Console window
Not technically possible. The ij.IJ class is ImageJ 1.x, while the
UIService is ImageJ2.
> I appreciate the pointer to the "Console Manipulator"
It was not just a pointer -- I wrote it specifically for your benefit.
> it simply involves too many new things to keep track of - for not
> quite enough benefit.
What is there to "keep track of"? You can copy and paste the code, no? The
only thing I did not do for you was code it as an ImageJ 1.x style plugin.
Instead, I wrote an ImageJ2 command as a gentle nudge in that direction --
especially since you would be requiring ImageJ2 regardless should you add
code that manipulates the console window directly.
But if you must stick with ImageJ 1.x plugins for some reason, the magic
invocation is:
Context context = (Context) IJ.runPlugIn("org.scijava.Context", "");
UIService uiService = context.service(UIService.class);
And then go from there, in the same way as the ConsoleManipulator code. But
know that this is a hack.
> other people might like other bells and whistles (fonts, colors, ...).
> One medium-priority option might be a "Save to File" button
Feel free to file feature requests at
https://github.com/scijava/scijava-ui-swing/issues/new.
> Yes...I know...I should probably use the multi-level logging facility.
If you go that route, see the SciJava LogService. There is a fancy SciJava
Log window that has more capabilities than the basic Console.
> I can't "pollute" my foundational classes with IJ-specific stuff.
If you use a logging framework such as SLF4J or even Java's built-in
logging package, the SciJava LogService can integrate with that seamlessly,
without inflicting any ImageJ or SciJava dependencies on your foundational
code.
--
Curtis Rueden
LOCI software architect -
https://loci.wisc.edu/softwareImageJ2 lead, Fiji maintainer -
https://imagej.net/User:RuedenDid you know ImageJ has a forum?
http://forum.imagej.net/On Tue, Feb 27, 2018 at 4:14 PM, Kenneth Sloan <
[hidden email]>
wrote:
> 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>
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html