Provide a way to save results from swing table about scijava-ui-swing

[tferr]

when a table display window is active, the main application menu bar is also active. So no ping ponging should be needed.

I was thinking of Windows OS and some Linux distributions where the main menu bar is on the main ImageJ frame.

Are those functions only accessible via right click?

I think so. Have a look at this example:

#@PlotService plotService
#@UIService uiService
plot = plotService.newXYPlot()
series = plot.addXYSeries()
series.setValues(0..3, 4..7)
uiService.show(plot)

The plot is displayed without any menu or buttons. Only by right-clicking on its canvas you can access export functions via contextual menu.

Are they macro recordable?

That is a good point. I don't think so. Then yes. we should have them as a proper menu command then.

I just want to make sure that users can find the functionality.

That is also a good point.

So this would be by suggestion:

• Adopt a menu command. If it can be macro recordable while being on the table frame, place it on the table frame. Otherwise move it to the main Application menu.
• Add a contextual menu nevertheless!?

[ctrueden]

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]

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...)

[ctrueden]

I'd think the possibility of panels/windows to provide their own, context-specific menu is essential.

I have mixed feelings. ImageJ2's Console window also has its own (very sparse) menu bar. But I personally think this is confusing. I guess there is no chance of reconciling the Script Editor's menu bar with the main ImageJ window though, so you are probably right: we need to support it.

In the short term, we could achieve what's needed in a couple of different ways:

1. Add an Export button to the table UI outside the menu structure.
2. Add a File > Export > Table... command to the main application menu structure.

@imagejan @tferr @hadim Does that sound good?

[tferr]

I think a contextual (righ-click or pop-up menu) would be better than both those options: It is out of the way (the button would make the table window bulkier). I don't like the command on the main application because if one has multiple tables open, one would have to ping pong between them and the application menu for each of them. Also, the context menu is already being used by other non-image displays (e.g, plots from the plot-service). That being said, if you guys think the context menu is a no-go than I would be fine with either.

[ctrueden]

I have historically avoided context menus in UIs for ImageJ2 because it seems like a sizable fraction of UX recommendations say not to use them that way. E.g., from the Apple Human Interface Guidelines:

Avoid providing access to features only in toolbars or contextual menus. Because toolbars and contextual menus may be hidden, the commands they contain should always be available in menu bar menus as well.

one would have to ping pong between them and the application menu for each of them

The current intent of the design is that when a table display window is active, the main application menu bar is also active. So no ping ponging should be needed.

Another advantage of making a menu entry like File > Export > Table... is that it will be automatically macro recordable etc.

Also, the context menu is already being used by other non-image displays (e.g, plots from the plot-service).

I wasn't aware of that. Are those functions only accessible via right click? Are they macro recordable?

if you guys think the context menu is a no-go than I would be fine with either.

The recommendations I've seen say that it's fine to have functions in a right-click menu, as long as they are also accessible via some other means.

However, I don't feel strongly. I just want to make sure that users can find the functionality. If you think most users would discover it within a right-click menu, then we can do it that way.

[adaerr]

I just stumbled across this issue as the Pendent Drop plugin is affected by it since the migration of tables to sci-java, and a user just brought to my attention that there is no way to save the output table except through copy/pasting elsewhere.

So just to add my 2 cents:

• I also think that while context menus are usefull (typically quicker to reach when you know it's there), having menu entries in the main application menu or a local menu is important both for discoverability and for macro recordability.

• Concerning tables, as I think saving/exporting is by far the most critical missing functionality, I'm all for @ctrueden 's short term solution of creating a command in the main application menu. Instead of File > Export > Table..., why not overload File > Save ?

• In the main application menu, the Image submenu could be replaced on the fly by appropriate menus according to the type of active window : Table, Text etc, providing room for the specific commands (or specific implementations, e.g. of the Rename... command).

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/snt-sholl-analysis-how-to-store-data-from-multiple-sholl-analyses-in-the-same-image/51707/31

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/snt-sholl-analysis-how-to-store-data-from-multiple-sholl-analyses-in-the-same-image/51707/33