controlling size and location of Console window

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

controlling size and location of Console window

Kenneth Sloan-3
I would like to be able to control the visibility, location, and bounds of the Console window, in a Java plugin.

Is this possible?

I'm making heavy use of the Console during development and debugging, but I'm trying to layout the screen
for the end user so that the Console is tucked into a corner where it can be seen, but is neither obtrusive nor mostly hidden by other windows.  Screen space is at a premium.

I have looked, but can't find a way to get a handle on the Console window from Java code.  Ideally, I'd like
to make it visible by default, and control its size and location.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: controlling size and location of Console window

ctrueden
Hi Ken,

> I would like to be able to control the visibility, location, and
> bounds of the Console window, in a Java plugin.

Assuming you are talking about ImageJ2's Console window, I post a gist
illustrating how to do it here:

    https://gist.github.com/ctrueden/29355778db5343b08266dba8d456a790

Just note that doing this will explicitly tie you to an AWT/Swing UI
scenario (won't work headless or with alternative UIs).

Regards,
Curtis


--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Mon, Feb 26, 2018 at 1:57 PM, Kenneth Sloan <[hidden email]>
wrote:

> I would like to be able to control the visibility, location, and bounds of
> the Console window, in a Java plugin.
>
> Is this possible?
>
> I'm making heavy use of the Console during development and debugging, but
> I'm trying to layout the screen
> for the end user so that the Console is tucked into a corner where it can
> be seen, but is neither obtrusive nor mostly hidden by other windows.
> Screen space is at a premium.
>
> I have looked, but can't find a way to get a handle on the Console window
> from Java code.  Ideally, I'd like
> to make it visible by default, and control its size and location.
>
> --
> 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
Reply | Threaded
Open this post in threaded view
|

Re: controlling size and location of Console window

Kenneth Sloan-3
Thanks.

Now, I just need to make sure that my customers have upgraded to ImageJ2.

I confess to not tracking this closely - I just noticed that stderr was popping up in the Console window, and could not find any documentation on how to control it.

I saw some threads on making it invisible - that's NOT what I want to do.  I want it visible, but I also want it in a corner, out of the way of the main content windows.  Putting it at (0,0) is probably the WORST location for my purposes - and I'd just as soon have it display only a few lines (no more than the last 10), unless and until someone pulls it up and enlarges it.

My plugins seem to always be "under development", and I've become addicted to leaving in extensive tracing/logging output to stderr in even the "production" version of the plugin.  Also, many of my foundational tools are used in non-ImageJ contexts, so stderr is a kind of standard place to put this stuff.

I don't mind the specific gui - but I do wish this kind of documentation were easier to find!

Again - thank you very much for your prompt reply.  Now, I have something to keep me occupied this evening.

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.





> On 26 Feb 2018, at 16:40 , Curtis Rueden <[hidden email]> wrote:
>
> Hi Ken,
>
>> I would like to be able to control the visibility, location, and
>> bounds of the Console window, in a Java plugin.
>
> Assuming you are talking about ImageJ2's Console window, I post a gist
> illustrating how to do it here:
>
>    https://gist.github.com/ctrueden/29355778db5343b08266dba8d456a790
>
> Just note that doing this will explicitly tie you to an AWT/Swing UI
> scenario (won't work headless or with alternative UIs).
>
> Regards,
> Curtis
>
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
> Did you know ImageJ has a forum? http://forum.imagej.net/
>
>
> On Mon, Feb 26, 2018 at 1:57 PM, Kenneth Sloan <[hidden email]>
> wrote:
>
>> I would like to be able to control the visibility, location, and bounds of
>> the Console window, in a Java plugin.
>>
>> Is this possible?
>>
>> I'm making heavy use of the Console during development and debugging, but
>> I'm trying to layout the screen
>> for the end user so that the Console is tucked into a corner where it can
>> be seen, but is neither obtrusive nor mostly hidden by other windows.
>> Screen space is at a premium.
>>
>> I have looked, but can't find a way to get a handle on the Console window
>> from Java code.  Ideally, I'd like
>> to make it visible by default, and control its size and location.
>>
>> --
>> 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

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: controlling size and location of Console window

John Hayes
Hi Kenneth,

You may want to grep the ImageJ code for where stderr is being piped to this console window. Some of the keywords in this example may be helpful:
http://www.avajava.com/tutorials/lessons/how-do-i-redirect-standard-error-to-a-file.html
When you find it, IJ is probably just using a TextWindow (https://imagej.nih.gov/ij/developer/api/ij/text/TextWindow.html), which is kind of a one-shot object. By that I mean, when it’s instantiated I think the window is displayed and the reference to it lost to the larger IJ code but the stderr could indefinitely be piped to it from the local reference.
Good luck, and I’d be curious what you find.

Best,
John

> On Feb 26, 2018, at 9:14 PM, Kenneth Sloan <[hidden email]> wrote:
>
> Thanks.
>
> Now, I just need to make sure that my customers have upgraded to ImageJ2.
>
> I confess to not tracking this closely - I just noticed that stderr was popping up in the Console window, and could not find any documentation on how to control it.
>
> I saw some threads on making it invisible - that's NOT what I want to do.  I want it visible, but I also want it in a corner, out of the way of the main content windows.  Putting it at (0,0) is probably the WORST location for my purposes - and I'd just as soon have it display only a few lines (no more than the last 10), unless and until someone pulls it up and enlarges it.
>
> My plugins seem to always be "under development", and I've become addicted to leaving in extensive tracing/logging output to stderr in even the "production" version of the plugin.  Also, many of my foundational tools are used in non-ImageJ contexts, so stderr is a kind of standard place to put this stuff.
>
> I don't mind the specific gui - but I do wish this kind of documentation were easier to find!
>
> Again - thank you very much for your prompt reply.  Now, I have something to keep me occupied this evening.
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
>
>
>
>
>> On 26 Feb 2018, at 16:40 , Curtis Rueden <[hidden email]> wrote:
>>
>> Hi Ken,
>>
>>> I would like to be able to control the visibility, location, and
>>> bounds of the Console window, in a Java plugin.
>>
>> Assuming you are talking about ImageJ2's Console window, I post a gist
>> illustrating how to do it here:
>>
>>   https://gist.github.com/ctrueden/29355778db5343b08266dba8d456a790
>>
>> Just note that doing this will explicitly tie you to an AWT/Swing UI
>> scenario (won't work headless or with alternative UIs).
>>
>> Regards,
>> Curtis
>>
>>
>> --
>> Curtis Rueden
>> LOCI software architect - https://loci.wisc.edu/software
>> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>> Did you know ImageJ has a forum? http://forum.imagej.net/
>>
>>
>> On Mon, Feb 26, 2018 at 1:57 PM, Kenneth Sloan <[hidden email]>
>> wrote:
>>
>>> I would like to be able to control the visibility, location, and bounds of
>>> the Console window, in a Java plugin.
>>>
>>> Is this possible?
>>>
>>> I'm making heavy use of the Console during development and debugging, but
>>> I'm trying to layout the screen
>>> for the end user so that the Console is tucked into a corner where it can
>>> be seen, but is neither obtrusive nor mostly hidden by other windows.
>>> Screen space is at a premium.
>>>
>>> I have looked, but can't find a way to get a handle on the Console window
>>> from Java code.  Ideally, I'd like
>>> to make it visible by default, and control its size and location.
>>>
>>> --
>>> 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
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: controlling size and location of Console window

ctrueden
In reply to this post by Kenneth Sloan-3
Hi John & Ken,

SciJava's default ConsoleService implementation overrides the system stdout
and stderr [1].

It creates a MultiOutputStream [2] for each, and adds a mechanism so that
stdout and stderr listeners can be registered.

> IJ is probably just using a TextWindow

Nope, it's a JFrame [3] containing an extension of JPanel [4].

Kenneth Sloan wrote:
> I've become addicted to leaving in extensive tracing/logging output to
> stderr in even the "production" version of the plugin.

Before the creation of the Console window, there were bug reports from
users saying things like "When I perform XYZ action, nothing happens."
Often, an error message or stack trace was being dumped on stderr, which
the user never saw, because they didn't launch ImageJ from the command
line. In order to prevent this situation, and ensure users do not "miss"
important error messages, I added the Console window. Whenever output to
stderr happens, the Console window appears.

Using stderr to report the progress of an operation is not its intended
purpose. But there are good options for reporting progress, including the
Log window (IJ.log) and the status bar (IJ.showStatus or using the SciJava
StatusService).

> Putting it at (0,0) is probably the WORST location for my purposes -
> and I'd just as soon have it display only a few lines (no more than
> the last 10), unless and until someone pulls it up and enlarges it.

I agree. It is at (0, 0) right now because that is the default, and no one
coded anything better. Please feel welcome to file a PR improving matters.
The initial position of the window could be set in LegacyUI [3], and the
default height could be changed at [5]. For the initial position, it might
make sense to align it directly below the main window, for instance.

Regards,
Curtis

[1] https://github.com/scijava/scijava-common/blob/scijava-
common-2.69.0/src/main/java/org/scijava/console/DefaultConsoleService.java#
L148-L156
[2] https://github.com/scijava/scijava-common/blob/scijava-
common-2.69.0/src/main/java/org/scijava/console/
MultiOutputStream.java#L41-L52
[3] https://github.com/imagej/imagej-legacy/blob/imagej-
legacy-0.29.0/src/main/java/net/imagej/legacy/ui/LegacyUI.java#L149-L160
[4] https://github.com/scijava/scijava-ui-swing/blob/scijava-
ui-swing-0.9.5/src/main/java/org/scijava/ui/swing/console/
SwingConsolePane.java#L50-L60
[5] https://github.com/scijava/scijava-ui-swing/blob/scijava-
ui-swing-0.9.5/src/main/java/org/scijava/ui/swing/console/
ConsolePanel.java#L130

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Tue, Feb 27, 2018 at 9:22 AM, John Hayes <[hidden email]> wrote:

> Hi Kenneth,
>
> You may want to grep the ImageJ code for where stderr is being piped to
> this console window. Some of the keywords in this example may be helpful:
> http://www.avajava.com/tutorials/lessons/how-do-i-redirect-
> standard-error-to-a-file.html
> When you find it, IJ is probably just using a TextWindow (
> https://imagej.nih.gov/ij/developer/api/ij/text/TextWindow.html), which
> is kind of a one-shot object. By that I mean, when it’s instantiated I
> think the window is displayed and the reference to it lost to the larger IJ
> code but the stderr could indefinitely be piped to it from the local
> reference.
> Good luck, and I’d be curious what you find.
>
> Best,
> John
>
> > On Feb 26, 2018, at 9:14 PM, Kenneth Sloan <[hidden email]>
> wrote:
> >
> > Thanks.
> >
> > Now, I just need to make sure that my customers have upgraded to ImageJ2.
> >
> > I confess to not tracking this closely - I just noticed that stderr was
> popping up in the Console window, and could not find any documentation on
> how to control it.
> >
> > I saw some threads on making it invisible - that's NOT what I want to
> do.  I want it visible, but I also want it in a corner, out of the way of
> the main content windows.  Putting it at (0,0) is probably the WORST
> location for my purposes - and I'd just as soon have it display only a few
> lines (no more than the last 10), unless and until someone pulls it up and
> enlarges it.
> >
> > My plugins seem to always be "under development", and I've become
> addicted to leaving in extensive tracing/logging output to stderr in even
> the "production" version of the plugin.  Also, many of my foundational
> tools are used in non-ImageJ contexts, so stderr is a kind of standard
> place to put this stuff.
> >
> > I don't mind the specific gui - but I do wish this kind of documentation
> were easier to find!
> >
> > Again - thank you very much for your prompt reply.  Now, I have
> something to keep me occupied this evening.
> >
> > --
> > 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
Reply | Threaded
Open this post in threaded view
|

Re: controlling size and location of Console window

Kenneth Sloan-3
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
Reply | Threaded
Open this post in threaded view
|

Re: controlling size and location of Console window

ctrueden
In reply to this post by ctrueden
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/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
Did 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
Reply | Threaded
Open this post in threaded view
|

Re: controlling size and location of Console window

John Hayes
Hi Kenneth and Curtis,

Sorry, I’m a bit confused, I was under the impression from this statement that Kenneth you were referring to the “Log” window in IJ1 as the “Console":
> On Feb 26, 2018, at 9:14 PM, Kenneth Sloan <[hidden email]> wrote:
>
> Now, I just need to make sure that my customers have upgraded to ImageJ2.
If that were the case, I believe the solution to your original comment can be implemented roughly as the following which just uses AWT in IJ1:

import ij.*;
import ij.process.*;
import ij.gui.*;
import java.awt.*;
import ij.plugin.*;
import ij.plugin.frame.*;
import ij.io.LogStream;

public class My_Plugin implements PlugIn {

        public void run(String arg) {
           IJ.log("Test1");
           LogStream.redirectSystem();
           Frame log = WindowManager.getFrame("Log");
           System.err.println("Hello World!");
           log.setLocation(250,250);
           IJ.log("Test2");
        }
}

The ij.io.LogStream class can redirect stderr similar to the link I sent, and ij.IJ uses this with a TextWindow as I suggested. However, if you really were referring to the IJ2 Console window, obviously Curtis knows better about it. :)

HTH,
John
--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: controlling size and location of Console window

Kenneth Sloan-3
Ah...this may be the solution I need, this year.  Re-directing stderr (and stdout) to the Log window will work for me.

Thank you very much.


--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.





> On 27 Feb 2018, at 18:15 , John Hayes <[hidden email]> wrote:
>
> Hi Kenneth and Curtis,
>
> Sorry, I’m a bit confused, I was under the impression from this statement that Kenneth you were referring to the “Log” window in IJ1 as the “Console":
>> On Feb 26, 2018, at 9:14 PM, Kenneth Sloan <[hidden email]> wrote:
>>
>> Now, I just need to make sure that my customers have upgraded to ImageJ2.
> If that were the case, I believe the solution to your original comment can be implemented roughly as the following which just uses AWT in IJ1:
>
> import ij.*;
> import ij.process.*;
> import ij.gui.*;
> import java.awt.*;
> import ij.plugin.*;
> import ij.plugin.frame.*;
> import ij.io.LogStream;
>
> public class My_Plugin implements PlugIn {
>
>        public void run(String arg) {
>           IJ.log("Test1");
>           LogStream.redirectSystem();
>           Frame log = WindowManager.getFrame("Log");
>           System.err.println("Hello World!");
>           log.setLocation(250,250);
>           IJ.log("Test2");
>        }
> }
>
> The ij.io.LogStream class can redirect stderr similar to the link I sent, and ij.IJ uses this with a TextWindow as I suggested. However, if you really were referring to the IJ2 Console window, obviously Curtis knows better about it. :)
>
> HTH,
> John
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html