hackishly working OpenBlocks init#4
hackishly working OpenBlocks init#4joshgiesbrecht wants to merge 10 commits intobitcraftlab:masterfrom
Conversation
- add authors and links to github repo + website - let's start with version 0.0.1 (0)
Modify the build process, so that generated web pages get copied to a dedicated directory. The idea is to have a seperate local directory / repo for the gh-pages branch, so we can quickly update the github project website
- links to processing + tool website + tool template - development status - license info
- create missing placeholders in build.xml - create placeholder to insert license info as a multiline comment - seprate license.txt and authors.txt - custom package structure: bitcraftlab.blocks.tool
fix link to processing tool template
and a first attempt at actually loading it
total hack to see if this at least works - and it does! to test this out you'll have to either modify the two filename refs to fit your local paths, or put copies of lang_def.xml and lang_def.dtd into c:\users\josh\workspace\Processing-Blocks-Tool\data to match. BUT! This actually builds and opens up the sample OpenBlocks panel when run!
|
Very awesome. Thank you Josh! I will look into the issue with the hard coded paths + filenames. For future pull requests it would be best, if you could select the prototype branch as target, because github doesn't let me change the target branch... Looking forward to snap some blocks 👍 |
|
Bah whoops, sorry! I thought about that but didn't see it as an obvious
On Tue, Feb 19, 2013 at 10:42 AM, Martin Schneider <notifications@github.com
|
|
Openblocks interface showing up. Yeah! When trying to merge your stuff I ran into some trouble with line-ending mix-ups. I also had a look at the path problem. The reason why the tool can't find the spec files is probably because they are burried inside the jar, while the Workspace Controller is looking for a file system location ... But I was going to customize the |
|
Huh, I thought it was already set to autocrlf. Thanks for the heads-up, I'll fix that for next time. Good to know you were planning to customize the WorkspaceController anyway. For some reason I was assuming that since we're just bundling OpenBlocks as a library, that we'd be leaving all of that untouched ... totally forgot that that doesn't stop us from rewriting our own component. I was guessing that the files were being tucked into the jar, but didn't figure out how to actually confirm where they were. Is there some tool that lets you browse what's in them? |
|
Looking at this tonight to try and see where to dive in first (after ignoring it for too long). If I start on a new WorkspaceController, is there any reason not to begin by copying the existing example and just editing stuff we need changed (like the file access)? |
|
Also should I bail on commenting here, close this request and just start a new one to the Prototype branch? |
|
Hi Josh ... sorry for the long silence! |
|
I finally pushed the current state to the prototype branch. I also streamlined the build process a bit for development and created an entry point to run the tool Unfortunately I'll be very busy the next couple of weeks, so feel free to hack away! |
|
Ok cool. I'll grab what you have in the prototype branch and work on it On Sun, Mar 31, 2013 at 9:04 AM, Martin Schneider
|
2 participants
It's only working with hard-coded paths for lang_def.xml and lang_def.dtd; I've been staring hard at the sample code in the processing tool data folder README and haven't been able to match it up with what OpenBlocks is expecting for a filename.
Hoping there's something there that can work as-is, but I'm not sure if there's something unique about how a processing tool loads files from the data folder or not. Hopefully it's a small fix, otherwise we may have to modify the way OpenBlocks accesses the file(?).
That said, WOO this actually opened up an OpenBlocks window from within Processing!