New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to save results from swing table #37

Open
imagejan opened this Issue Mar 19, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@imagejan
Copy link
Member

imagejan commented Mar 19, 2018

When using script output, such as those in this script:

#@output a
#@output b

a = 2.17
b = "Foobar"

the outputs are displayed in a new table window without any menu. Let's add some possibility to save the table contents to file, similar to how it works for IJ1 ResultsTables.

@ctrueden

This comment has been minimized.

Copy link
Member

ctrueden commented Aug 25, 2018

This brings to light a substantial design limitation of ImageJ2: it is not really feasible for DisplayWindow instances to have custom menus. The original intent of the design was that all displays of all types would share the same application menu structure with ImageJ. It is (arguably) confusing for some windows such as the Script Editor to have their own menus, while others such as image windows share the same menu structure as the main application window.

Now is a good time to decide exactly how we want menus to behave in SciJava applications, since I want to work on scijava/scijava-common#157 soon. There might be an opportunity to enhance the menu system to accommodate this and other per-display menu customizations.

@imagejan

This comment has been minimized.

Copy link
Member Author

imagejan commented Aug 25, 2018

It is (arguably) confusing for some windows such as the Script Editor to have their own menus

Script Editor is not the only (and not the first) component with an own menu. ImageJ1's text windows (Plugins > New > Text Window...) and ResultsTables have their own menus, too.

I'd think the possibility of panels/windows to provide their own, context-specific menu is essential. The alternative would be to gray out (disable) certain menu entries when they're not applicable to a given context, right? But I don't see how the menu structure can be substantially changed without giving up some of the backward compatibility (regarding UI) to ImageJ1.

image windows share the same menu structure as the main application window.

Ah, you mean the fact that images don't have their "own" menu, different from that of the main window, is what's confusing? One could argue that the main application menu wouldn't have to contain all the image-specific commands, but that's what you usually want, since most of the time you're working with images, not with tables, wouldn't you? (But this aspect might change in the future, when the menu might be different for different image types even, e.g. depending on their dimensionality...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment