continued_at_new_forum The Wingnut Chronicles

[GameMonetize]

You fill my heart with joy

[Vousk-prod.]

That pull 630 page is something else.  I have never seen anything like that, before.  Thanks for showing that to me.  A complete conversation about a single commit.  I like that idea, for sure.  Really, it's imperative to have that.  I'm glad it's there.

 

That was the point I wanted to tell with "And when pull requests are sent in the projects, so many people have a look at them, check and discuss the proposal". This is one of the great features of GitHub, and a nice work of the BJS commmunity.

[Wingnut]

Yeah, the structure is hard to explain to others (and me).  I had to just tour-around in the build tools... and see what they were... before I could start to get it all in-focus.  I never realized that this kind of thing existed.  It's just... a pile of file-chowin' robots.  hehe.  With a server, too. 

 

I think my brain has sort of popped a fuse... thinking about the possibilities of nodeJS modules... and grunt.  Piping piping piping.  Phew.  It's big.  Powerful.  Drool-inducing. 

 

The guys did a good job.  I bitch about the editing interface... but... it's a trivial matter.  This "system" allows me to make my own interface to the BJS docs git repo... and I can hide or show as much of the "chatter" as I want-to.  It might be interesting to know if a LOCAL webpage can be used to build a GUI for interfacing with NodeJS.  I suspect it can, but... hmm... there's surely a security layer involved there.

 

I hope I can keep my mind on BJS... because... I got some serious demented ideas from looking at this build engine... and seeing how many npm's are available for NodeJS.  A guy could get lost for a couple of years in that toolbox. 

[Temechon]

GUYS WE DID IT !! We converted the Wingnut !! xD 

 

Edit: More seriously, of course you can create another GUI. Grab these MD, find a npm package to convert them in XML or whatever suits you, and create your own doc. If you think it will be useful for the community, do a pull-request (push request does not exist) and profit

[Wingnut]

  Don't get excited too quick, Mister T.  Just because I can finally start to understand this... doesn't mean we have a friendly interface for the public to edit and create docs.  But... it looks like another friendly-layer could be built atop this (on a users local machine).  It could be really hand-holding and only talk to the Babylon repos. (Not a universal git tool.  A specialized tool, instead.)

 

I'm still standing-by that 90% "that's not going to happen" speculated statistic.  And some of my reduced bitching is because I realized that I was being a whiny stick-in-the-mud and I should try to be kinder.    We still got issues... but... maybe things can be done.  Maybe a big fat XAML app that runs in a local IE... and can talk directly to the local NodeJS and tell it to do things. Essentially, our own GIT EXT or GIT DESKTOP... made specially for our (BJS) common tasks. 

 

Temechon, I realize that I can gen the docs in all sorts of formats... but... I'm looking for a way (a gui) to make my own Git Desktop... in a local browser.  This way we could keep our Windows context menus clean, not having to add Git EXT, Desktop, or Tortoise. 

 

Our XAML-gui'd ActiveX app could fire ANY Git or NodeJS command, tour local cloned repos, monitor the error channels... all in one app.  In other words, a curator like me doesn't even know he's doing git and nodejs commands behind the scenes... it's all wrapped in friendliness.  Our own LOCAL webpage-based Git/NodeJS/Grunt Desktop.  Yeah! 

 

I know I could do it in XUL as a FF extension... but... hmm.  A guy might have to install his nodeJS and Git... in a FF "chrome" directory... in-scope of extension perms.  It's been awhile since I built a FF extension.  But... yeah... I'm thinking of a FOR BJS-specialized layer/app... that can hide the dos stuff.  Takes the fear out of it... for the kids!  We do it for the children!!!  THE CHILDREN!!!  hehe. 

 

It LOOKS like I have to use Socket.io and actually browse to a local NodeJS server, and do form submits to it, in order to talk from the browser to nodeJS (all on a local machine).  I'd much rather use an ActiveX control or something... and talk directly to nodeJS and GIT.

 

Experiments ahead, I suppose.   But first... more reading reading reading.  I hope I didn't hurt anyone's feelings with my grumping.  I can be kind of a prick.  I often let other hassles happening in my life... pour-over into the wrong places.  Little things sometimes become snapping points... and I empty my purse (dump a bunch of emotions) onto something that doesn't deserve so much emotion.  I unload everything... when I really only wanted to unload a little bit. 

 

Update:  Looks like Electron might be something.  Also maybe Node-Webkit or "NW".  Interesting. 

[Wingnut]

Ok, hi again, TWC fans... I'm going to remain off-topic for a while, and chronicle my slow trip into the world of NodeJS.

 

Lately, my goal has been this... https://github.com/thom-nic/electron-demo  (a variance of this... https://github.com/atom/electron/blob/master/docs/tutorial/quick-start.md

 

But... trying to run that demo... requires all sorts of "side knowledge" that Wingy is missing.  Want to hear the story so far?  I knew you did.

 

First, paths.  I DL'd a little util called Path Manager... and its very cool.  Then I started reading about ~ and $HOME and $NODE_PATH  and I thought about modifying my context menus trying "NodeJs Cmd Prompt here" and open-with, and sendTo... and hacked around in my Windows registry.

 

Meanwhile, I'm reading about "setting up a NodeJS environment on Windows 7" and that drifted me over into Windows Power Shell, and then I finally got back to getting the Babel module installed, which was a problem in the Electron demo.  And now... I still think I have plenty of path problems to/from NodeJS... and a lack of understanding WHAT is "global" and what is "local".  I understand packaging a bit... and setting $root to the base address of the package sometimes... but... it's all good and foggy yet.

 

We old people don't understand Windows perms very well, and, generally speaking, if some permission problem gets in our way, we either take ownership of the folder and subs, or we add "Everyone" and full-access to the folder security.  Pretty dangerous, eh?  Not so bad for us non-public single-user folk, I suppose.

 

Lots of fun learning ahead... all suggestions welcome, thanks!

 

Back on the subject of GIT, I recently fired-up GitGui... and managed to browse my local clone of the new docs repo.  Then I found a "visualize recent activity" choice, and cooooooool... I was shown all these fancy merge and commit and pull request lines... nice.  It was fun.  I didn't understand much of what I was looking-at.... but if I ever WANTED to understand GIT ops... that visualizer is a toy I would keep handy.  I bet there are many repo activity visualizers available.  Just what I need... yet another distraction and learning-tangent. 

 

Tangents.  sigh.  Windows Power Shell... I think it's probably pretty amazing... and a guy could get lost in that.  NodeJS... we all know it's big time amazing.  Electron... cool... powerful.  I love the idea of using HTML for the gui on desktop/mobile apps.

 

NO Wingy... don't go there!  Stay on target... getting your paths in order... and figuring out what to do with "NodeJS Here" (on context menus for JS files).  So far, my tries-at adding things to context menus for JsFile class... have failed.  But, I'm still learning all that. 

 

The most dependable NodeJs fire-up of the index.js for the Electron demo...  is dragging the index.js onto the NodeJs Cmd Prompt icon, and dropping it.  That NodeJs Cmd Prompt icon... is set cmd.exe /k in its shortcut... so the nodeJS-active dos window remains open... and let's me see the errors nicely.  I'm quite happy getting the Electron demo to TRY to run.  YAY!!!

 

Paths.  erf.  And... has anyone seen a way to use control-v pasting... in dos windows?  I need control-v in dos/nodeJS window, or I'm going to go crazy. 

 

Be well, everyone.  Path on!

[Wingnut]

Hi again!  Wow, 4 days of playing with paths... and trying to put nodejs module babel/register (babel-core) in a place where it can be found.  What a beast!  I hate paths!  hehe.

 

But look...

 

http://urbanproductions.com/wingy/babylon/misc/awakening.jpg

 

(Exciting output for Wingy!  Probably boring for everyone else.  Windows 7 platform.  Big fonts, eh?  Big fonts = less scary.)

 

Wow, huh?  I still have some problems with this Electron demo, a little strict mode hassle, but I'm close!  Yay!  The NodeJS error "cannot find module Babel/Register"... really slowed me down.  But it was because of...  well... newbie-ness.  heh.  Incompetence on my part.  Still, ouch.

 

You should have seen the npm install command go (for that demo).  Man, there were piles of stuff spewing across my screen... unreal.    I had to quickly fill-up the pixel-ink tanks... they almost ran dry. 

 

Hey, remember how I was wishing I had control-v pasting in dos-like windows?  Well here we go.  I had to install a gruesome monster called AutoHotKey... as mentioned at that URL.  Then I ran the guy's script, and boom, control-v works in DOS.  Yay!

 

Off-topic?  Proudly so.  But actually, I am still interested in Electron's abilities to let me use HTML for GUI (and do all nodeJS commands from within it).  As mentioned earlier, I want to make a local Windows (ANY os) app... that makes dealing-with the Babylon GIT repos... super easy and safer-feeling. 

 

Oh, and did you see the big-time beefy scripting language in AutoHotKey?  Nice.  AND... they have GUI, built into it (or they are calling native Windows gui).  Unreal!  Powerful.

 

I would almost have to say that I could write a friendly local front-end to BJS GIT... with AutoHotKey ONLY.  It wouldn't be in HTML like it would with Electron... but it would still be plenty of GUI to get the job done.  One problem.  Cross platform.  AutoHotKey looks like it's Windows only.  Electron's HTML GUI... seems much more cross-plat.  Maybe.  Electron DOES use an .exe.  I'm not sure what the story is.  Still learning. 

 

I think Windows Power Shell would give me quite a bit of goods and likely some native gui, too.  But again, the result would be a Windows-only local app... and I would prefer a BJS GIT-helper app that would work on any platform.

 

I'm SO out of my league, eh?  (I am un-qualified for this kind of dos madness).    Two more years... I'll have it.  Ok, maybe three.   Even if I never get this helper app built, I'm spending time with NodeJS, and that's...  good, I suspect.  Comments gladly welcomed and encouraged.  Script on! 

[Vousk-prod.]

Glad to see you surfing this dos/prompt/scripts wave with more and more confidence each day !

[Wingnut]

Thanks vp, that's nice of you to say.  There's probably no need to do any of this, as DK's tutorial/method surely works just fine.  But I still wanted to see what options are available for automating the process.  Actually, de-automating, and then re-automating... essentially trying to make my own cross-platform Tortoise.  GRUNTin', GULPin' and GITin'.  Sounds like my normal morning wake-up routine. 

 

I sure wish there were more web pages about folks setting-up their NodeJS environments on Windows.  But I suspect that once a person DOES successfully get their node module paths set perfectly and understand the differences of nodeJS local vs -g global... they are then too exhausted to write their story.  heh.

 

It's always the same when learning new things.  First, learn the terminology.  Get out the flash cards, kids!  (index cards with terms to learn... written on them).  Once you get the terminology mastered, then the web posts ABOUT that subject... make much more sense.  Needing to look-up terms while reading tutorials... really slows-down a person and screws-up the learning flow.  And I fear that I'm losing old learned things from my memory... as I add new learned things.  I think I forgot how to make a basic BJS scene. 

[Vousk-prod.]

Yep, too exhausted, or more simply you CANNOT write the story, because you made so many tries-errors-redo-go-other-way-then-go-back-and-retry you don't really know how you manage to do it and how to proceed to do it again :D.

Anyway that's my case  . And that's the same "boring" story for every environnements I need (coding, music recording / mastering, video editing, 2D and 3D image producing, etc, with all the compatibility problems always happening and the thousands of plugins you need days and weeks to find and install... ), working with a computer is so powerfull but a true never ending story, that's why I never reinstall my computer I always keep it the cleaner I can and make regular ghosts - really too scared to redo all those installs   

[Wingnut]

Hi gang!  Still off-topic, but I promise to bring it back onto the rails soon.

 

As some of you know, I've been on a quest to dev-ify my new mid-range Windows 7 box... and today, I took quite a left turn.

 

First, I changed to ioJS.  No big deal, it's so close to nodeJS that it's just not a very important change.  ioJS operates just like nodeJS.

 

Next, I found a file manager called 'Far Manager'... which was nice, but the best part... it integrates perfectly with my new console window/cmd.exe called 'ConEmu'.  It's like control-v for dos prompt... on steroids.  Serious integration... like best friends.  The two systems (Far Manager and ConEmu) are written by the same folk, I believe. 

 

Lastly, I finally installed the Atom text editor... which looks pretty cool.

 

Ok, that wasn't quite lastly, yet.  Somewhere along the line, I also installed Python 3.4.

 

Take a look at a screen-grab of this new Wingnut "dev environment" if you please... http://urbanproductions.com/wingy/babylon/misc/FarMan_ConEmu_Atom.jpg

 

Talk about a complete change of direction, eh?  I'm SO proud.    The FarManager/ConEmu package looks (and works) great, so far.  Things are starting to come alive.  Sure, it's just another thing that will need dusting, but... I felt something today.  I had a strange feeling... like bytes surging through my veins.   Maybe it was the coffee.

 

Things are looking much brighter.  I'm not promoting or endorsing Far Manager, ConEmu, Atom, or ioJS... but I am saying that it all feels pretty good from where I'm standing.  Party on.

[Vousk-prod.]

Woww, FarManager has instantly brought me back to the '80s !!

[Wingnut]

haha  *nod*  I was having some trouble reading the docs with their default theme, so I grabbed one from the list that was handy... Windows Default Colors.  That, along with my big fonts... really gives it that old dossy look, huh?  Ain't it great?

 

But believe me, that SOB has WAY more power than any 1980's dos app I've ever seen.  Fully mouse-active, and hotkeys by the tons.  I'm going to need two days just to set prefs! 

 

You got projects going, VP?  Do tell, if ya want. 

[Wingnut]

Hi gang!  Continuing on the off-topic subject of... studying ways to interface with our new git-based docs repo.  Dealing with GIT scares old people like me, and so, this curator freaked-out and began a quest.  The quest is to build a cross-platform on-user-machine webpage... that could take the fear (the dos) out-of interacting with GIT. 

 

There are many GUI interfaces to GIT already existing... but I chose to ATTEMPT to make my own, using HTML for the GUI.  I want to get real talkie/hand-holding, telling youngsters (and old people) what's happening in our GIT repo with every button press.  I want to teach about GIT and OUR repo... in this BJS-specific GIT app... for the children!  (Ok, ok, for me, too.)    Other than that objective, I have no game plan.  I can't establish a gameplan until I learn how ready the tech world is... for this kind of "browser bastardization"  hehe

 

Once, when I was trying to use Perl piping to a browser window as GUI for Perl, my old genius friend Roy Silvernail, God rest his typing fingers...  used-to say to me "But THAT is no longer a 'browser', by definition." 

 

By definition.  What a strange phrase.  I think Roy probably understands, now, that "by definition" has never stood in the way of a mad scientist.  Node-webkit seems "mad scientist" to me, and it definitely stretches the definition of a 'browser'.  Sure, there's issues.  How many desktop apps can browse-away from the app to view a website?  How many desktop apps have a forward/back button, and allow the same prefs-settings as a browser would?  Is it a program?  Is it a webpage?  We just can't tell anymore... and I love that.  Sure, it's an app state-management and session-management nightmare, but so what?  That's part of the fun!    (right up until I need to code it)  heh

 

None of this BJS Git-Manager app is necessary, as DK's docs takes care of basic needs and beyond.  But really... I want to become a Repo Wrangler.  I want to learn about the new 'build system' used in our docs repo.  Only unfamiliarity stands in my way.  Far Manager and ConEmu have still been pleasing me, and have made working with paths and other dos-things... pretty easy.  It will be even easier once I learn how to drive them.  Uncle Wingy's Git Ranch is slowly coming into existence... and boy... does it have power.  Power... both gives me confidence and adds more fear.  Yay!  errr.

 

I can't sum-up the quest as well as this webpage about nodeJS (and GIT) desktop apps.  The more I read, the more I think node-webkit is what I need.

 

 

node-webkit has a major advantage to Chrome applications, as both DOM manipulation and Node.js API calls can be used in the same context without needing to run a separate server. The only caveat to this is that modules pulled into the application via require only have access to the Node.js context, not the web view's. This means that Node.js modules must exclusively use functions and classes provided by Node.js or modules from npm, as the DOM is off limits. To get around this, you can include JavaScript using script tags.

 

I have tried basic apps using atom shell, which is now called Electron.  But every Electron "hello world" app that I have tested so far... requires that I start a localhost web server... and "browser reloading" (re-browsing my webby nodeJS control center) is the only way to access the browser's DOM.  I have to run a web server.  That, sucks.  I don't want to run a localhost webserver.  (nor a grunt server, but we'll talk about that later.)   And, I don't want to keep doing control-r for updating HTML GUI changes that the nodeJS-powered webpage-maker needs to do (such as update the local view of a repo-clone folder after it has been refreshed by GIT).

 

Everyone and one other person... knows that there are multiple ways to get a webpage to render in a browser.  You can fill the DOM with a visit to a website, or by loading a local webpage from a file, or by using JS to dynamically "poke" HTML into the DOM tree.  Only one of these ways... requires a web server. 

 

Ok, ok, it's true that we still need to serve the JS from somewhere, but that can be a file server (load a webpage/js).   The last way, the node-webkit way... APPEARS to place the browser's DOM (or a shadow-thereof) into scope of NodeJS (somewhat). 

 

 

Node.js modules must exclusively use functions and classes provided by Node.js or modules from npm, as the DOM is off limits. To get around this, you can include JavaScript using script tags.

 

Although that line worries me, I HOPE that the DOM tree becomes in-scope of NodeJS.  Using this method, maybe a NodeJS app can both listen for DOM events like button presses, AND make LIVE adjustments to the GUI for our app (do DOM tree pokes).  (maybe.)  I'm not sure exactly how to do that... yet.  According to that quote above, nodeJS modules can't access the DOM directly, but maybe the "to get around this" thing... will work for my needs.  Maybe NodeJS can generate standard JS files that can be included-in LIVE, and then THOSE can make changes to the DOM.

 

I should give my new unwritten app... a name, yes?   WebbyNodeJS.  Or, WNJS Radio.  A TRANSceiver... transmit and receive... HTML nodes and browser events... to and from a browser window.  The events... can call NodeJS/ioJS code and npm modules, and those modules can query things and make changes to the webpage that sent the events.  Super yum!

 

So today, I begin studying node-webkit.  Over the next few days, if you hear some explosions... or see some fireballs in this section of the forum, could you please call the fire department?  Thanks.    Sorry for the off-topic... but I'll bring it home... I promise.  Comments and suggestions welcome, as always.  Party on!

[Wingnut]

Hi girls!  Another quick update and a screenshot. 

 

http://urbanproductions.com/wingy/babylon/misc/atom_nw.jpg

 

Finally, my first demo (from https://github.com/nwjs/nw.js/wiki/node-main )... works!  I spent all day yesterday... fighting with it.  Hello World would show up in the Chromium web window, but no address/toolbar across the top, and NO script would run, no matter how I tried.  Without the top toolbar... there is no Chromium dev tools (like console.log).  It was a "stupid window". 

 

But then I read this... https://github.com/nwjs/nw.js/wiki/How-to-run-apps and other things... and I found out that NW (node-webkit) is a combination of Node and webkit (duh).  By doing this... Node and webkit... run in the same Javascript "context" (scope).  Well, I had NW (node-webkit) installed on my desktop, and although I set my paths correctly, or did drag'n'drops of app folder onto nw.exe... I was out of "context" from the app. 

 

As soon as I "installed" node-webkit INTO the app's folder... and ran THAT nw.exe... kaboom... good toolbar, JS started working, dev tools console working... hooray!  Node's "process" could now be found from within the script.  Process.version reports being v1.2.0.  I have communicated-to NodeJS (ioJS for me) from within the webpage... and I (could) use Node(js) to BUILD the webpage, too.  Coooooool!    Totally circular, dudes!  JS contexts... weird... but understandable. 

 

You can see in the center window of the picture... that I placed a shortcut to nw.exe beside the app's root folder.  Believe it or not, that shortcut points to a nw.exe that is inside that folder.  Drag the folder onto the shortcut, and that runs the app.  I have another problem, though.  Closing the Chromium browser window... does not end the Windows process that started it.  I need to run my task manager and clean-up old processes, sometimes.  I'll figure that out, soon.

 

Dragging/dropping a folder onto a shortcut to an exe inside of that folder.  That's just strange. 

 

Another note:  Installation of Google's Chrome browser is not required... to use NW (node-webkit).  A non-commercial "chunk" of it... is built-into NW, and it is rumored to be a bit fat when packaging a NW app into being a platform-specific .exe.  I hear the NW team is working on slimming it down.

 

Ok, that's all I have to report at this time.  Hope everyone is well.  Party on!

[Vousk-prod.]

And now what you're really starting to need is a bigger screen (or a second one)

[Wingnut]

  Nah.  I've found that if you move your monitor really close to your face, it becomes a HUGE screen with space for many windows (use smaller fonts than before).  It's all a matter of perspective.... literally.  heh.

[Vousk-prod.]

:lol:

[Wingnut]

Hi guys.  Continuing my off-topic adventures of making GIT easier to deal-with, I started looking carefully at Tortoise, which is a GUI Windows interface to GitHub.  Man oh man, there are many many GIT commands, aren't there?  After weighing the situation carefully, I estimate it will take me 2 years to create something similar, with node-webkit.

 

*sigh*  I think I'm going to jump ship on it.  I foresee someone smarter than me... beating me to the punch by about 18 months.    I really wanted to find some way to make it easier for the GIT-impaired... something real teachy... something that doesn't JUST do the needed commands, but teaches GIT as you use it.  But a decent tutorial should be able to do the same thing.

 

I need to learn about GIT, that's all there is to it.  (I learned the term "remote", yesterday.  yay!  It seems like a stupid name. Should be GitNode, maybe, but the existence of node/nodeJS probably ruined that idea.)

 

One of the questions I have... is... once a pull request is submitted, does YOUR edited docs need to stay connected to the internet... until the pull happens?  Can that be hours?  Days?  Does the grunt server need to run the whole time?  What the heck IS a grunt server?  When do I need to be served grunts?    SO much to learn!  ouch! 

 

Maybe a grunt server makes a git branch... instantly, and thus doesn't need to be active very long.  I haven't learned about branches, yet.

 

Yep, time to do more reading... and more reading... and more reading.  I need to let-go-of my hopes for a friendly desktop node-webkit app... and get-on-with just trying to get my first GIT-interaction done without having a nervous breakdown.    (Actually, I've done a couple of GitHub interactions already, and each one scared the dog, which is weird, because I don't have any pets.) 

 

By eliminating the reading needed to drive conEmu, Far Manager, and node-webkit, I can concentrate my focus on nodeJS, GIT, gulp, grunt, the basic things needed to get an edit done.

 

Yep, it's time to de-stump and de-rock a fresh chunk of land... to be used as MY docs repo corral... and start learning to wrangle the cattle.md.  I haven't tried the h_ttp://localhost:3000 thing mentioned in DK's docs, yet, either. That sounds like fun, but it sounds like a server.  We're scared of servers 'round these parts, but I guess 'localhost' has our butts covered for that one.    Party on.

[Ahiru]

Hey Wingnut,

 

I like your chronicles, and I finally finished reading the complete "story"

 

But now I have difficulties to find certain examples you did - have you ever thought about collecting them somewhere, so it would be easy to find something again? Need not to be fancy, just a title and a very small description maybe together with the link? (I would prefer a complete searchable playground plus foldable functions in there, so it would also make sense to have larger code-examples in there capsuled in functions that are folded first - but that's all maybe difficult to realize?)

[Wingnut]

Hi again, Ahiru!  You do me great honor by reading TWC.  As you now know, it's been just a whole lot of Wingnut whining and mistakes. 

 

Probably the first 1/3 of this thread... happened before there was a BabylonJS Playground... so those demos are hosted at my buddy's webserver... urbanproductions.com.  And man, are they badly coded.  Back then, I used a "GO object"  (global object)  ...so that I could get things within scope of each other.  This is a truly crappy programming practice used only by crappy programmers.  Those demos... I want to hide.  Certainly YOU have no need to see them... as you... are a coding God!

 

http://www.babylonjs-playground.com/#YRIPX#8 - look at you... diving right into advanced camera work.  Pfft... there's not a thing I can teach you about JS, that's for sure.  You are certainly more qualified to be a helper than I am.  Truth.  But I may take your advice and build a list of demos that reside on my buddy's server.  It will give us something to laugh-at, that's for sure. 

 

By the time the Playground came into existence... I was starting to pull my head out of my butt, and I had seen some of Temechon's demos, and demos/projects on the BJS main website... that were done right... with OOP in mind.  And, I started to promote that way of coding... to others... though still, none of MY demos were ever done right. 

 

After the PG (playground) showed-up, I fell in love with it... and the createScene function.  Eventually I wrote the playground docs and a demented doc called The Babylon Primer... all of which promoted the 'createScene' way of building playgrounds (easy paste - o - function), and it all worked out pretty well.  Playground usage went up, (thanks to others, too)... and we all had great discussions about playground demos... and learned tons from each other.  Still happening.

 

Through the ages, a few have asked for lists of demos, just like you.  So, one day, Wingnut got a wild idea to try to coax admin... to provide us with a list of stored playground scenes.  That conversation began here...  http://www.html5gamedevs.com/topic/4983-tutorial-talk/page-8#entry88809 ...and eventually, after a bunch more Wingnut whining... we got the playground DB... in three file formats.  I made a basic webpage out of the XML version, and I was hoping others would "massage" those DB's into more usable lists.... possibly searchable (not for tags, but for keywords within the PG code itself).  That hasn't happened, yet.

 

The best I have accomplished so far... is http://urbanproductions.com/wingy/babylon/misc/pgs3.xml ...a very slow-loading monster xml file that is "live-transformed" (at display-time) into a basic webpage... by XSL.  (possibly Firefox Only)  It shows a link to every playground in the Azure DB as of mid-July 2015.  I might be able to improve it, and do better grepping and pre-processing... with the help of NodeJS and its NPM modules... which I am learning at this time... slowly.

 

Yep, I like your thoughts/ideas, Ahiru, and your enthusiasm is excellent, in everything I've seen from you so far.  I think it's going to be fun having you hang around with us, so, try not to go too far away, eh?  We could sure use your help and knowledge... and fine suggestions... and your friendliness.  Plus, you're a friggin' tasty coder, too.  Yay!

 

I'll get to work on that list of demos from the urbanproductions.com site, but you must promise to never use or promote any of my terrible coding techniques.  Deal?    We need to avoid corrupting the children with bad Wingnut code.  heh

 

Be well, Ahiru!  Tell us (more) about your projects and hopes, if you want.  Right here in TWC is fine, or anywhere else is fine, too.  And thanks again for reading TWC... I am definitely honored by that, though it probably wasted some hours of your life that you will never get back.    Sorry about that.  The Wingnut Chronicles is really an essay of what NOT to do.    (Unless someone is studying how to talk aimlessly for hours and hours.)  Party on!

[Temechon]

I love your idea Wingnut: what about creating a webapplication where a user could :

 

- save a playground link, and associate a title (or some kind of metadata) to it

- browse all playground link

- search a playground link by keyword

- see all versions of this PG example (#1, #2, ...)

- maybe he can comment a PG ?

 

I would call it babylonjs-examples.com (i love originality).

 

What do you think about this ? Hey, I might want to create it actually, I'm sure it would be very very useful for the community and for newcomers.

Like codepen.io is doing for HTMl/CSS/JS: it would be the same site but for PG snippets.

 

I love this! I already want it to be done actually  

 

PS : If I work on this, no XML/XSL, but Markdown Sorry Wingy

[Wingnut]

Excellent!  Kick it's butt, T-doggy... I don't care what format it lands-in... just so folks can tour PG's and maybe have some search power.  I haven't moved the project forward whatsoever... so, yeah, PLEASE advance the situation using any method.  I'm really glad you are interested in this, Temechon!  I would guess that you want to integrate it with the new docs site, yes?  *nod*  Love it!

 

Temechon... while I have your ear... did you see the bad links at http://doc.babylonjs.com/tutorials/02._Discover_Basic_Elements#side-orientation  ?  (three links have   hanging-onto the end of their URLs). 

 

I imagine that is caused by a build script.  I still need a few more months before I can fix that myself, so I figured I had better ask you to take a look.

 

If/When you do fix those links, can you show me what part of the build engine... caused it?  thanks!

[Vousk-prod.]

That a brilliant idea Temechon !

I'm currently bookmarking in my browser all interesting PG with many tags (keywords), to easily find them afterward, but I can search only among those I one day have noticed. It would be far more interseting to be able to to search among every created PG.

 

People who create a PG should be advised to carefully tag it (for instance a PG about camera manipulation, but where a a little trick is used to rescale something with scaleInPlace method, should be tagged with every keyword relative to the purpose of the PG but also with "rescale" or "scaling" because a "not so usual" function has been used) and to properly comment it : "Function to move camera this way, for this reason. And a little trick to rescale that thing because... etc".

 

As you said it would be nice to search by keywords. I think also by author, comments content, and, why not, used methods (so anyone could search how and in which situation others use a particular function). Just imagine... you're stuck in a situation, no hint in the doc or the tutos to guide you, and suddenly, by looking at the BJS source code, you intuitively guess that this ImHereToSaveYourAssButImReallyWeird(name, wrappedObject, field1, field2, isReusable, scene) function will be helpfull but you absolutly don't get any little piece of it... Well, no problem, a little PG search, and billions examples using this function appear in front of your tired eyes !! tadaa ! so coool, is'n it ?

[Wingnut]

 

People who create a PG should be advised to carefully tag it

 

I don't think that's going to happen very much.  Playgrounds are sometimes built fast, from a previous playground, testing a concept... ooops, accidentally hit save instead of zip/run, there's yet another un-tagged PG demo.  User is in a hurry, I better get this URL out to the forum so they can get the help they need and move their projects forward.  Think-up tags for this PG?  No time.  Select from a list of tags that would apply to this PG?  No time.  We got four more forum questions to make playgrounds-for... this morning. 

 

I think you get my point.  I think various types of pre-processing should be used to automatically generate the tags field.  Where will they be stored?  Azure?  Add a field to each PG record?  We're at about what... 16000 PG demos?  That's probably a good estimate.  And that's why I suggested we work at home.  We use our own processing time, and search word by word, or by tags we each generated with a batch pre-process... or anything else.  Folks can choose their own tag names... and their pre-processors can choose which PG's to apply them-to.  (like how many occurrences of a term... does it take to trigger a tag being added FOR that term?)

 

Yep, VP, you are talking about a "regimentation".  Only use CERTAIN tag names, and you're asking PG authors to follow rules that they never signed-up-for.  It is my opinion that it is better for some string-munging fuzzy-logic AI to iterate-through all the playgrounds, and establish a tags field based upon findings.  And then change the criteria for the mungers, and try it again.  Then adjust something and try it again.  Tag-triggering criteria.  When is it worth tagging as xxxx and when doesn't it have enough criteria to warrant the tagging.  Auto-tagger, ya know?    Multiple versions.  Then folks can take these auto-tagger funcs home, and apply them to their own local DB's... using their own preferred tag names, and adjusting the tag-add triggering logic as wanted (as in... sensitivity setting).

 

Hard call, huh?  Nod.  Put it on line... and you will need to railroad folks into choosing tag additions from a list of "approved tag names". 

 

Let's pretend the progger started a playground from a godrays demo, but they changed it SO MUCH that there's not a single mention of godrays or vls anywhere in the code.  Does the new save automatically get the "godrays" and "vls" tags from its previous save?  Does the author need to remove them before the save?  Troubles troubles troubles.  Sorry to be a downer... but there's issues. 

 

I'd say step one, get a TAGS field added to each PG record... and why not a DATE field, too.  Don't bother with author, as many playgrounds have numerous authors.  Now export all three DB object types again, and then start playing.  Ideally, attack the DB objects with NodeJS scripts... munching thru the db.json, and filling the tags field... and then saving the new JSON db.  Then see how well your auto-tagger worked.  If its cool, share the auto-tagger code... not the new json DB.  Others will want to use different tag names and different "trigger a tag addition" criteria.  When we code the NodeJS auto-tagger script, we must try to let others adjust the tag names and the add-criteria... to their liking.

 

Then, the searcher... the thing that finds tags or keywords in the JSON db.  How about a node-webkit app for that?  User can choose fast tags search or slow word-by-word search... its all done on the user's machine and not at Azure.

 

If online tag search is done, then it should NOT be the ONLY way to search.  Some folks want to find "transformCoordinates".    Does that term qualify as a decent tag name?  No.  But I could be wrong.  Ideally, we have word-by-word search, too.

 

Just my opinion.  Based-upon... well... ok... MY GUESS... is that the json db object of all playgrounds... WITH the new tags and date fields added... at the end of year 2017... will be about 100 megs in size.     We got trouble... right here in River City.  heh.  But I have faith in the "big data" wranglers that are nearby.  I think we'll be bouncing that 100 megger on our noses like a trained seal... by that time.  And besides, when you are looking for an answer to a scene problem... a 5-minute search through your local playground database... is no big deal, right?  nod.