search

imagej / imagej-launcher

The ImageJ native launcher
https://imagej.net/learn/launcher
BSD 2-Clause "Simplified" License
21 stars 18 forks source link

Build ImageJ as GUI app #73

Closed hinerm closed 4 years ago

hinerm commented 4 years ago

This patch fixes a mistake in the transition from nar to CMake, when we started building ImageJ as a console application, which makes the console always pop up when the app is launched e.g. by double-clicking the icon.

See https://github.com/fiji/fiji/issues/257

hinerm commented 4 years ago

@ctrueden I tested this on linux and the WIN32 flag doesn't seem to cause any problems. Can you test on OSX?

Interestingly, setting this flag and launching with just IJ1.x changed the taskbar icon to be that of IJ1. So if that is objectionable we would need to do more work here.

Using this launcher in Fiji still preserves the Fiji icon (except when pinned, as noted in https://github.com/imagej/imagej-launcher/issues/71)

ctrueden commented 4 years ago

@hinerm I tested the win-console-fix branch on macOS, and it works fine. Thanks.

Does the --console flag still work on Windows? I.e. can you still attach to a console?

hinerm commented 4 years ago

@ctrueden

Does the --console flag still work on Windows? I.e. can you still attach to a console?

Nope, it doesn't seem to work. :( But it doesn't seem like we're calling AttachConsole anywhere..

hinerm commented 4 years ago

@ctrueden oh ok, I guess we are calling AttachConsole, but we don't get that far because of this initialization check

hinerm commented 4 years ago

@ctrueden Do you think it's essential, when running with --console from a terminal, to attach to that console, as opposed to popping a new dedicated console?

Connecting to an existing console is done with AttachConsole, but when I use this and run from e.g. Command Prompt, it appears to attach output to the console but doesn't "block" the way it would with a console application... I can still provide input to the console.

OTOH if I use AllocConsole to create a new, dedicated console, it creates an intermittent console that's tied to the life of the app. I think that's technically what's supposed to happen here - but was missing the essential steps of re-opening the standard channels.

Note that the difference in behavior only seems to apply when running from a windows terminal. If running from a shell prompt on Windows (e.g. MINGW or Visual Studio Code terminal) the parent console remains attached no matter what - even after a FreeConsole call!

I personally dislike the bheavior of AttachConsole and can't find a way to make Command Prompt block while the app is open (as it does on the shell consoles).. so I'm wondering if just always allocating a console is acceptable?

ctrueden commented 4 years ago

Thanks for the detailed explanation, @hinerm. I don't have a strong opinion. Maybe ask in the imagej/imagej Gitter channel? If no one else feels strongly, I'd say go ahead and make it work however you think is best. We can update the docs accordingly (assuming there are even any docs to update on this flag, which there might not be).

ctrueden commented 4 years ago

@hinerm What if we added --attach-console and --alloc-console flags? And made --console do --attach-console by default because that's what it did previously? (And yes: the behavior where it doesn't block the console was normal and consistent with before.)

hinerm commented 4 years ago

@ctrueden

@hinerm What if we added --attach-console and --alloc-console flags? And made --console do --attach-console by default because that's what it did previously?

done as of 0fd050d9c15bca3728bee8a639f4ba5d3515d0ce. I'm happy with it if you are! :)