Skip to main content

News

Topic: QtSphere IDE (working title) 0.2.3 (Read 3069 times) previous topic - next topic

Re: QtSphere IDE (working title) 0.2.3
Reply #60
The worst part is that I'll have to come up with a new name, since QtSphere IDE without Qt obviously makes no sense.
ElectroSphere? ElectroSphere IDE? That sounds like an IDE for something called ElectroSphere. Sphere Zapper?
Any other ideas?

Simplistic suggestion: Spheretron?

IonoSphere (both referencing Ionized air and the Ionosphere itself)
StatiSphere (Static + Sphere)
BlitSphere/BlitzSphere (Blitz, German for Lightning, + Sphere)

Re: QtSphere IDE (working title) 0.2.3
Reply #61
I would actually like to make a VSCode plugin for Sphere v2.  It would support the entire toolchain: miniSphere, Cell and SSj.  I have to learn how to make extensions for it first, though.
I did consider that for a while, but I haven't seen any painting related plugins, so I'm not sure if it would be very feasible. JavaScript is so ubiquitous that I can easily find stuff to add widgets and things, making it much less uncertain.

Simplistic suggestion: Spheretron?

IonoSphere (both referencing Ionized air and the Ionosphere itself)
StatiSphere (Static + Sphere)
BlitSphere/BlitzSphere (Blitz, German for Lightning, + Sphere)
Hmm, those could work

Re: QtSphere IDE (working title) 0.2.3
Reply #62
IonoSphere (both referencing Ionized air and the Ionosphere itself)
StatiSphere (Static + Sphere)
BlitSphere/BlitzSphere (Blitz, German for Lightning, + Sphere)
Hmm, those could work

You are for sure welcome to any of them. :)

Re: QtSphere IDE (working title) 0.2.3
Reply #63
@Fat Cerberus I asked about VS Code and drawing/mouseclick events on StackOverflow. If I get a good lead and it turns out that it isn't too difficult, I'll just make a plugin or plugins. If not, I'll probably go back to the electron plan. It sucks that all the time spent with Qt was wasted, but I had been meaning to learn more C++ anyway so I guess it wasn't a total loss, even if that might be a little selfish.

Re: QtSphere IDE (working title) 0.2.3
Reply #64
By searching around the internet and peeking through the API, I'm fairly certain by now that Code doesn't provide anything like I described. It does make it possible to embed a browser, so I still might be able to make an extension for Sphere editing

Re: QtSphere IDE (working title) 0.2.3
Reply #65
Damn, it looks like the embedded browser can't execute JavaScript. Looks like it's back to electron then.

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: QtSphere IDE (working title) 0.2.3
Reply #66
Electron + Sphere... Hmmm, maybe a name related to Tesla coils? You know, because of plasma globes. :)

As for your experiments with Electron, it looks interesting, and I think it's a clever idea to speed up development! It even allows for some code reuse as I'm sure miniSphere has some file reading scripts you could use here.
  • Last Edit: September 10, 2017, 06:33:50 am by DaVince

  • Rhuan
  • [*][*][*][*]
Re: QtSphere IDE (working title) 0.2.3
Reply #67
A key reason I'm sticking with QT Creator at the moment is that it has some useful automatic JS checking for me.

E.g. it points out if I declare the same variable twice or if I use an undefined variable or have a missing comma etc.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: QtSphere IDE (working title) 0.2.3
Reply #68
One thing I like about ES6 is that if you do this:

Code: (javascript) [Select]
let pig = 812;
/* .......... */
let pig = 1208;

You get a runtime error.  Also modules are strict mode by default so if you forget to declare a variable that's an error too.  It's still indeed nice if the IDE catches it first, though. :)

Also nice: let is block-scoped, like in C, and the variable is not hoisted so if you use it before the declaration, you *also* get a runtime error.  The JS community has given that phenomenon a name: the variable is said to be in the "temporal dead zone".  Pretty goofy, huh? :P
miniSphere 5.0b2 (stable: 4.8.8) - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enormous man-eating pigs ~Rhuan

Re: QtSphere IDE (working title) 0.2.3
Reply #69
I'll probably make a poll or something when this gets off the ground and I can confirm that it's going to replace QtSphere IDE. If that is the case, should I just lock this thread and make a new one? Or can a mod split this thread, starting at my first post about electron?

One thing I like about ES6 is that if you do this:

Code: (javascript) [Select]
let pig = 812;
/* .......... */
let pig = 1208;

You get a runtime error.  Also modules are strict mode by default so if you forget to declare a variable that's an error too.  It's still indeed nice if the IDE catches it first, though. :)
Honestly, I've never really used lets, just because I never saw much of a point in them. With the errors, that should be something that the programmer is responsible for, shouldn't it?

Also nice: let is block-scoped, like in C, and the variable is not hoisted so if you use it before the declaration, you *also* get a runtime error.  The JS community has given that phenomenon a name: the variable is said to be in the "temporal dead zone".  Pretty goofy, huh? :P
So it treats it like use strict? And how is it goofy? Is "temporal dead zone" a reference to something?
  • Last Edit: September 14, 2017, 02:31:31 pm by Eggbertx

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: QtSphere IDE (working title) 0.2.3
Reply #70
I think a lot of new JS programmers get thrown off by the hoisting behavior of var.  For example, this is confusing:

Code: (javascript) [Select]
// console.log(y);  // strict mode error
console.log(x);  // undefined (!)
var x = 812;
console.log(x);  // 812

Versus:
Code: (javascript) [Select]
// console.log(x);  // error (TDZ)
let x = 812;
console.log(x);  // 812

And block-scoping means that if you have a let in an inner block, such as an if condition or loop, it doesn't get hoisted outside like a var would.  That one catches a lot of people off-guard, myself included when I first started learning JS, because it differs from how scoping works in almost every other C-like language.

...which brings me to the goofiness of the "temporal dead zone" terminology.  For that I'll just quote a post I saw a year or so ago:
Quote
I can't begin to guess why someone decided to add "Temporal Dead Zone" to our vocabulary, other than that it probably followed a 17-hour binge-watch of ST:TNG accompanied by too much hipster brew.

Those of us who have been programming in Java, C++, and the like for the last two decades or so just call those "the place where I haven't yet declared the variable I want to use." I think life would have been better for all concerned if braces defined block scope and we could just be done with it. (Maybe not better for Brendan back in the day, but better now, IMHO.)
miniSphere 5.0b2 (stable: 4.8.8) - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enormous man-eating pigs ~Rhuan

Re: QtSphere IDE (working title) 0.2.3
Reply #71
I somehow never noticed that hoisting behavior. I always always (almost) always declare my variables at the beginning of the script or source file, immediately after the imports, aside from temporary variables in if/for blocks, and to avoid confusion, I generally don't use those temporary variable names outside of those blocks. I just tested that with
Code: (javascript) [Select]
var a = true;
if(a) {
var b = 43;
let c = 44;
}
console.log(b); // 43
console.log(c); // error
and I see what you mean now. That doesn't make any logical sense why the above code is the way it is.
  • Last Edit: September 14, 2017, 01:17:21 pm by Eggbertx

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: QtSphere IDE (working title) 0.2.3
Reply #72
A key reason I'm sticking with QT Creator at the moment is that it has some useful automatic JS checking for me.
Honestly, as long as it stays maintainable (unlike the original Sphere engine/editor at a certain point), I'm fine with either idea of it being Qt-based or Electron based. I'd just really like to see a cross-platform editor solution.

I do think it'd be more likely for more people to contribute directly to the project if it were coded in HTML/CSS/JS though, even for just tiny additions/fixes. Simply because the barrier of entry is that much lower.

  • Rhuan
  • [*][*][*][*]
Re: QtSphere IDE (working title) 0.2.3
Reply #73
A key reason I'm sticking with QT Creator at the moment is that it has some useful automatic JS checking for me.
Honestly, as long as it stays maintainable (unlike the original Sphere engine/editor at a certain point), I'm fine with either idea of it being Qt-based or Electron based. I'd just really like to see a cross-platform editor solution.

I do think it'd be more likely for more people to contribute directly to the project if it were coded in HTML/CSS/JS though, even for just tiny additions/fixes. Simply because the barrier of entry is that much lower.
Quick note, when I said that I'm "sticking with QT Creator" I did not mean I was developing an editor with it or particularly suggesting that anyone should, I was simply using QT Creator as my javascript editor of choice.

I'm now trying out Atom which seems quite nice too (I note that it's built on the aforementioned Elctron)
  • Last Edit: September 16, 2017, 08:44:07 am by Rhuan

Re: QtSphere IDE (working title) 0.2.3
Reply #74
Atom is nice, but I always felt like VS Code is a bit snappier and has less cruft. Which is surprising, considering the developer :P