Deploy app for multiple systems

[Robert Leach]

NOTE: This issue has been split up into 2 issues (this one and issue #482). Issue #482 has been separated to be specifically about the app icon and name while this issue is about multiple system deployment (i.e. "bundling" & packaging) and is intended to group all the relevant issues related to deploying an app with a seamless integrated experience for user, whether they are on mac, windows, or some flavor of linux.

USE CASE: WHAT DO YOU WANT TO DO?

I as the user want a seamless app experience on my system of choice.

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

n/a

CURRENT BEHAVIOR

None of the steps in the EXPECTED BEHAVIOR section currently work as a (mac) user would expect.

EXPECTED BEHAVIOR

A seamless integrated app experience as itemized here:

• See a named app icon in the dock
• Double-click an app-specific file to open it in the app
• Click the file name in the title bar to see its system location and get to encompassing folders (or the analogous windows/linux methods of doing that)
• Access the About window in the system-conventional location
• About window should have the app icon
• Perform system-provided app functions, such as "quit" without deleterious/unexpected/different affects in the app

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

All of the specific changes depend on what tool we use for system integration. This issue is about getting that system running and then using it to implement the items listed in "EXPECTED BEHAVIOR". Here is the suggestion for the system to use:

This Gradle plugin could serve us best to create native setups for all 3 major OS: https://plugins.gradle.org/plugin/de.inetsoftware.setupbuilder

And here are the associated issues for the specific system integration items mentioned:

• Issue #482: Have TreeView3's app icon and name appear in the dock and in the Finder/Explorer
• Issue #481: Call storeState() when user quits via command-q or app menu quit item
• Issue #135: Title-bar access to encompassing finder folder
• Issue #457: Titlebar should only have file name (not path and app name)
• Issue #83: About Window Info Update
• Issue #191: Double-click to open cdt (et al) files

FILES AFFECTED (where the changes will be implemented) - developers only

unknown

LEVEL OF EFFORT - developers only

medium

COMMENTS

Old description:

We have a working treeview icon that needs to be attached to the jar file in some cross-plaform way. See comments below on OS deployment.

LEVEL OF EFFORT - developers only

medium

[Robert Leach]

There's been talk about making the background squares larger too...

[Robert Leach]

I've been working on this from home and I don't have a copy of illustrator at work. There is a charge for Illustrator. It's $36. It's charged to something called "chartstrings":

https://puwebp.princeton.edu/ows/priv/web_store/web_store_home.jsf

I guess I'll work on it from home.

[Robert Leach]

Hey @TreeView3Dev , You mentioned that you found some documentation on how to integrate an icon into the app. Could you give me a link or tell me what format & dimensions etc, to make the icon?

[Robert Leach]

Looks like the old treeview uses a .icns file which contains the icon at 4 resolutions. 2 of the resolutions have a back & white version.

[Christopher Keil]

@hepcat72 I just sent you the old email with all the info I gathered in November.

[Robert Leach]

For documentation purposes, I'm pasting the relevant portion of that email here:

*I have found some decent resources about getting the software out for all OSs.

There is an Eclipse extension called 'Delta Pack' which allows product export for multiple target systems and it seems like one good way to do this. You first need the PDE Plus pack (Plug-in development) from the Eclipse marketplace.

Here are some links and instruction on how to set a custom docker icon for OSX and more: https://stackoverflow.com/questions/6006173/how-do-you-change-the-dock-icon-of-a-java-program http://aniefer.blogspot.co.uk/2009/06/using-deltapack-in-eclipse-35.html http://www.vogella.com/tutorials/EclipseProductDeployment/article.html http://howlingmoonsoftware.com/wordpress/make-an-mac-osx-app-bundle-for-your-java-application/ Official Apple: https://developer.apple.com/library/mac/documentation/Java/Conceptual/Java14Development/03-JavaDeployment/JavaDeployment.html If Delta Pack for Eclipse works, then we could set it up for all OSs, otherwise Jarbundler seems to be the way to go for OSX at least.*

[Robert Leach]

I have attached the adobe illustrator version of the latest icon to the issue.

[Christopher Keil]

Since we are now moving to properly build using Gradle, I think this Gradle plugin could serve us best to create native setups for all 3 major OS: https://plugins.gradle.org/plugin/de.inetsoftware.setupbuilder It uses Java 8 though, I am not sure yet if that matters for users.

[Anastasia Baryshnikova]

Looks great. I think we could ask all the users to have the latest version of Java installed, if it's for a very good cause.

[Christopher Keil]

After some more reading, it looks like just the devs who run the Gradle build script need Java 8 installed due to the implementation of the plugin.

[Robert Leach]

Are this issue and #313 duplicates?

[Christopher Keil]

No, building with Gradle and bundling for multiple systems with Gradle is not the same thing, but these two issues have overlapped a lot in terms of discussion. The "deploy for multiple systems" is basically extra stuff in Gradle.

[Robert Leach]

Removing milestone: Packaging (automated comment)

[Christopher Keil]

@hepcat72 I'd argue the point "Double-click an app-specific file to open it in the app" is only semi-related to this deployment issue. The reason are:

1) apps exist which you have to specifically choose for certain file types. Clicking on a ".txt" or ".csv" does not invoke your favorite text editing app by default, but an OS-default which the user can change (but the setup is on the user side).

2) We do not have a "TreeView3" file type yet. We already specified the .trv extension but this is a separate issue, as you have mentioned (#191)

3) You can assign existing apps on your system to be the default for open certain file types. This relates to 1), but the user may still tell his OS to open a ".cdt" file with TreeView3. Not massively convenient, but my point is that "double click app-specific file type" is not a blocker for the deployment issue.

[Robert Leach]

Of course, we couldn't do something like .txt or others that are defaults for other apps, but I think it would be reasonable to at least do .cdt. Was .cdt created by the original treeview? And yes, the user can do it themselves once there's a .app file recognized by the Finder to which to associate a file extension, but I don't think most users know how to do that.

No - you're right, these issues aren't blockers. Sorry, didn't mean to imply that. They're just all related to multiple system deployment. Personally, I'd like to see them all done for the first beta.

I'm happy to look into that one when I get to that milestone.

[Christopher Keil]

Yea, the .txt was only an example that I think we can go ahead with deployment without fully implementing a clickable file format first. [.cdt|.atr|.gtr] is a file group created by Cluster 3.0 which TreeView3 specifically reads. It's where label types such as GID, AID, GWEIGHT, EWEIGHT etc. come from.

[Robert Leach]

I guess, by editing this issue, I was concerned with granularity and some issues falling through the cracks, like the app icon. The goal of this issue had been unclear because the title and description didn't really match. If you want, we can split off incorporation of gradle from this more general issue of seamless app experience and we can decide which integration app experience things are necessary for the beta. That way, gradle can be marked as completed and we still have the app experience issue to focus efforts on fully packaging/bundling which doesn't have to be resolved before beta.