Re: [netlogo-devel] "Open from Modeling Commons" Netlogo functionality using web view

15 views
Skip to first unread message

Jason Bertsche

unread,
Apr 26, 2013, 5:47:40 PM4/26/13
to benjaminra...@u.northwestern.edu, netlog...@googlegroups.com, reu...@lerner.co.il
It's a decent idea, but you should be aware that NetLogo needs to run on Java 5+.  With a bit of digging, I was able to find a JavaFX version (2.0.2, I think it was) that had compatibility with Java 6, but I wasn't able to find one that worked with Java 5—though, I found nothing to positively suggest that no such version of JavaFX exists.  So, overall, if you're going with JavaFX, you're going to need to use some older version with sufficient Java backwards-compatibility.

Now, that isn't to say that being unable to find any JavaFX version that works on Java 5 will kill off the option of using JavaFX, but it will complicate things.  I'm not sure how many people are still on Java 5, so it's perfectly conceivable that we could disable the Modeling Commons-oriented features on versions of Java 5, but that means you'll then have to worry making sure that the option is disabled for them, and you'll also have to make sure that the 'java5' branch of NetLogo continues to compile with your changes—however you might want to go about making that happen, just so long as nothing related to the Modeling Commons explodes next time I go to that branch to make a release.

If you can pull all of that off, you're free to submit a pull request with such changes.  I actually kind of favor such a thing; if you can keep your UIs out of the NetLogo codebase, so much the better.  Otherwise, if that's not feasible, I'm not terribly opposed to you continuing to make the UIs in Swing.
Jason Bertsche
Software Developer - NetLogo
On 04/25/2013 02:31 PM, benjaminra...@u.northwestern.edu wrote:
Reuven and I have been discussing how we want the open from Modeling Commons functionality to work.  One of the problems I see right now with the current save to Modeling Commons is that it requires the development of two different UIs for the same features (ie the modelingcommons.org html web app and the Java Swing UI in Netlogo).  I propose that the Modeling Commons functionality in Netlogo switches to using a web view like this that uses HTML and CSS instead of a Java Swing GUI.  This has a couple of major benefits:
  • More consistent Modeling Commons user interface: when opening or saving a model, users would get the ease of uploading or downloading straight from Netlogo without going through a web browser, but would get the same look and feel as the Modeling Commons site
  • Removed reliance on Netlogo release cycle: right now, any minor changes or feature additions to the modeling commons potentially could require changes to the Netlogo code, which puts a burden on everyone.  Using a web view, the user interface would be downloaded as html directly from the Modeling Commons site, allowing the Modeling Commons to make minor UI changes and feature additions without having to burden the Netlogo release cycle
Basically the user would see a cut down version of the Modeling Commons page instead of a Swing dialog.  For example, when saving a new model to the modeling commons, the user would see a simplified version of http://modelingcommons.org/upload/new_model.  The navigation and search bar would probably be removed, but the login/logout bar, banner, and look and feel of widgets would be the same or similar.  

The most full featured web view for Java seems to be the JavaFX one that I linked to above.  Does this seem like a good idea?
--
You received this message because you are subscribed to the Google Groups "netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netlogo-deve...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Seth Tisue

unread,
Apr 29, 2013, 11:58:38 AM4/29/13
to benjaminra...@u.northwestern.edu, Jason Bertsche, netlog...@googlegroups.com, reu...@lerner.co.il

Agree with Jason -- compatibility, packaging, and deployment issues are
key here, and might end up chewing up more of your time than the coding
itself.

I would suggest not taking too much time on the HTML5 interface-building
part of this before you've done the integration part end-to-end,
including testing the result in InstallAnywhere-built NetLogo
installers, using a minimal initial example UI (with perhaps just, like,
one button in it and nothing else), so that you're sure in advance that
whatever it is you end up building is actually deliverable in the
context of NetLogo as it actually exists.

--
Seth Tisue | http://tisue.net
Reply all
Reply to author
Forward
0 new messages