separate UI code from back-end logic

[acencini]

refine the back-end API such that there is a well-documented set of functions that can be called from any sort of UI (web, macos, etc.) such that the telescope logic is independent of its presentation, this way any number of front-ends may be developed for the telescope without a substantial rewrite.

[edaniszewski]

Since we had just gotten srtn to work this week, we are a bit behind schedule. I am going to move this to the next milestone so we will have more time to work on it (i.e. start working on it) over long weekend.

It looks like the UI code is tucked in a lot of places, so it may be tricky separating it out and may yet need to be pushed back more..

[acencini]

this is not mandatory and should have been under a much later milestone!

On Mon, Apr 7, 2014 at 11:50 PM, Erick Daniszewski <notifications@github.com

wrote:

Since we had just gotten srtn to work this week, we are a bit behind schedule. I am going to move this to the next milestone so we will have more time to work on it (i.e. start working on it) over long weekend.

It looks like the UI code is tucked in a lot of places, so it may be tricky separating it out and may yet need to be pushed back more..

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/16#issuecomment-39809298 .

[Berrescuda]

This would be nice to have. But we are not going to have it any time soon. #DreamLand

[edaniszewski]

I found a decent UI framework that is cross-platform, wxWidgets. I can try to re-do the UI, which would then allow us to separate out the back end to hook into the new UI, though this would be a slow task.

@theDarkLard @hcrowl -- Do you have any ideas/suggested improvements for the UI? I could make it look the same as it is now (or probably at least similar), but I think it could be improved. (some of the buttons on the top could move to the menu bar, e.g. the exit button, the help button, etc.) There could also be ways to update location/other variables directly, instead of changing it in the code and recompiling every time, etc.

If you have any ideas, suggestions, etc. you can either just describe/enumerate them in a comment, or sketch a picture of what you may want it to look like.

Never really done UI stuff, so it could end up being a total flop..

[edaniszewski]

Simple mockup using Balsamiq:

[theDarkLard]

This looks wicked cool! Would much rather use this over what the current UI is. Updating variables in srtn itself would be a lovely addition. Also this is really nit picky but something that the old java srtn did which I thought was really cool was it color coded the tracing in the power v time plot, so like the line would be red for 0-400 K, blue for 400 - 800 K, green for 800+K. I think this re-addition(?) would be really great especially because the height of the power v time plot resets every time it wraps around so instead of following the pwr readout in srtn you can get a better idea of what the power output is from the color system.

On Thu, Jun 25, 2015 at 9:04 AM, Erick Daniszewski <notifications@github.com

wrote:

Simple mockup using Balsamiq:

[image: srt mockup] https://cloud.githubusercontent.com/assets/1195651/8354840/2a58a332-1b19-11e5-86f1-a3aa9e48f091.png

— Reply to this email directly or view it on GitHub https://github.com/BenningtonCS/Telescope-2014/issues/16#issuecomment-115247905 .

[edaniszewski]

Doesn't sound nit-picky at all! It doesnt sound like it would be too difficult to implement knock on wood. Of course, it would take some time to construct the UI, and then more time hooking up the logic to the actual UI.

There is a reason this went to Dreamland, but its good to have dreams.

[hcrowl]

This is maybe Dreamland, but maybe not. If Brendon works on this for advanced work, it would be very attainable. What do you think, @vpascow?

[theDarkLard]

another welcome addition would be a text box for command entry. The java version had it but it seems like the c verison does not, and it makes assigning a command file other than the standard one (cmd.txt) annoyingly difficult. in the java version, you could enter the command file name into the text entry box and then srtn would execute it. right now, I'm trying to figure out how to get srtn to execute a command file other than the stock file. it shouldn't be this difficult!!

[theDarkLard]

Ok ao figured it out. You've gotta write it into the srt.cat file with the keyword COMMAND and then your file name. For example, like this: COMMAND cooltest.txt. Important note, it reads .txt files, not .cmd files. What happens is you put in the command file into srt.cat and it automatically executes it when you run srtn. But it shouldn't be like this...in other words, we shouldn't have to input a new command file into srt.cat and recompile the whole thing each time we want to execute a new command file in srtn. I'll put this procedure in the usage wiki for now, but this would be one of the best things to change/update.

[edaniszewski]

another welcome addition would be a text box for command entry.

@theDarkLard in the mockup I posted, my idea was that the text input box (above the log console, below the top row of buttons) could serve as this. If we want to get really fancy we could have a kind of DSL so you could type something like

cal mode=2

or

stow

or

cmdfile -> ~/proc/srtn/test_file_1.txt

You get the idea... This would essentially be creating a kind of shell emulator for srtn. Not an overly complex problem, but doing it right takes time and planning. (if you've ever used the rhino 3d modeling software, they have a similar feature. works well, IMO)

[edaniszewski]

This is maybe Dreamland, but maybe not. If Brendon works on this for advanced work, it would be very attainable. What do you think, @vpascow?

Definitely attainable. I don't know a TON about UI stuff, but its a bittersweet thing to dabble around in (it really should be easier to create UIs at this point in the game....) The laying out and design isn't too bad, though can be finicky. The more challenging aspects are event handling, fault tolerance (who wants a UI that crashes every 2 minutes), etc. Thick clients like this seem (in my limited experience) to be on the decline though, since the big hype nowadays is having a thin web client (HTML5, CSS, JS, etc). Big hype for good reason though. If we had a web client for this, and used a campus server, maybe got a cool site for it (astro.bennington.edu, eh @hcrowl ?), we could push batch jobs to a server-side scheduler, so you could make observations from anywhere at any time.

[hcrowl]

astro.bennington.edu

yaesu.bennington.edu

[edaniszewski]

I'll donate $1000 to the physics/astro/let-hugh-do-whatever-he-wants-with-this-fund fund if this happens.

[theDarkLard]

HAHA! and yeah I'm a total idiot how did I miss that...I was just raging hard over how srtn just loves to not work the way it's supposed to.

[edaniszewski]

It has begun..

[acencini]

hugh,

i will work on securing a second yaesu hat for engineer daniszewski.

sent from 36,000 feet. --andrew

On Jun 26, 2015, at 10:13 PM, Erick Daniszewski notifications@github.com wrote:

It has begun..

https://cloud.githubusercontent.com/assets/1195651/8390051/88727136-1c50-11e5-965f-69456f9d6aaa.png — Reply to this email directly or view it on GitHub https://github.com/BenningtonCS/Telescope-2014/issues/16#issuecomment-115936787.

[edaniszewski]

never too early for some yaesu stocking stuffers

http://www.amazon.com/YAESU-NO-SAKABA-Crown-Japan/dp/B00Z7SNNT0/ref=sr_1_51?ie=UTF8&qid=1435373835&sr=8-51&keywords=yaesu http://www.amazon.com/CafePress-yaesu-shirt-Light-T-Shirt/dp/B00WZ75H2W/ref=sr_1_59?ie=UTF8&qid=1435373852&sr=8-59&keywords=yaesu&pebp=1435373903865&perid=00EJ1B8H4B0J1HGQKG8T http://www.amazon.com/Vintage-Advertising-Postcard-Oakland-California/dp/B00PB98552/ref=sr_1_105?ie=UTF8&qid=1435373935&sr=8-105&keywords=yaesu

[edaniszewski]

@theDarkLard progress on in-UI customizable properties -- the future is near

[theDarkLard]

Oh my god all my dreams coming true!!

On Jun 27, 2015, at 12:14 PM, Erick Daniszewski notifications@github.com wrote:

@theDarkLard progress on in-UI customizable properties -- the future is near

― Reply to this email directly or view it on GitHub.

[edaniszewski]

related: #115

still a bit of work to be done, but.. progress

[edaniszewski]

also not seen: some work on having session state, so (hopefully) any values/UI state can be saved when the UI quits, and gets reloaded when the ui starts.

might push to future version, since it seems more important to figure out how to display/draw graphs.

[theDarkLard]

ur a g e n i u s

[edaniszewski]

ur a g e n i u s n e r d

fixed that for you

[edaniszewski]

stole some code, got a graph

gotta figure out the sky plot thing, clean up a few things, add some configurability, then the next big step would be integrating with the backend..

[edaniszewski]

started branch ui-dev which I am going to push nightly (or whenever-I-have-timely) builds to, instead of posting screenshots all the time.

to run the in-development UI, assuming all files are pulled down from the branch, simply run

$ python main.py

requirements: Python 2.7, wxPython, OpenCV, matplotlib, numpy, pylab

for wxPython and OpenCV, see websites/google on how to install. For others, I believe they can be installed via pip. Haven't tested, but should be compatible with MacOS, Linux, and Windows (assuming using Python 2.7)

further documentation + instructions can be added if needed.

[theDarkLard]

@edaniszewski you're the man.

[edaniszewski]

Haven't tested, but should be compatible with MacOS, Linux, and Windows (assuming using Python 2.7)

Oh how I spoke too soon. Tried it on windows today. There are some problems getting the library dependencies with windows (particularly numpy, but since almost every other library depends on numpy, there isnt really a workaround). Sooo, lets just say that it should work on *nix systems? Maybe..

[acencini]

if you're using windows, you shouldn't be looking at the universe

$0.02

On Jul 1, 2015, at 6:02 PM, Erick Daniszewski notifications@github.com wrote:

Haven't tested, but should be compatible with MacOS, Linux, and Windows (assuming using Python 2.7)

Oh how I spoke too soon. Tried it on windows today. There are some problems getting the library dependencies with windows (particularly numpy, but since almost every other library depends on numpy, there isnt really a workaround). Sooo, lets just say that it should work on *nix systems? Maybe..

— Reply to this email directly or view it on GitHub https://github.com/BenningtonCS/Telescope-2014/issues/16#issuecomment-117837357.

[edaniszewski]

I think we found the new tagline for srtn