When I tried it under Windows Mono, I got no output whatsoever, unless I used mono -v in which case it just logged the creation of the default Exception instances (OutOfMemoryException, NullReferenceException, etc.).  It took me a bit to realize that was just runtime logging and not related to Sphere Studio specifically.

I'll try installing Mono on my Ubuntu VM and see what happens there.  That might let me use gdb too.

Well, I'm getting decent output in Mono under Ubuntu, so:

Code: [Select]

vincent@corine-Aspire-5538G ~/D/p/s/S/SphereStudio-1.2.1> mono Sphere\ Studio.exe
SendMessage (100663336, 0x101f, (nil), (nil))
SendMessage (100663336, 0x1003, 0x3, (nil))
SendMessage (100663336, 0x109b, (nil), 0x7fffd6c882b0)
SendMessage (100663336, 0x1036, 0x2000000, 0x2000002)
SendMessage (100663336, 0x1027, (nil), (nil))

Unhandled Exception:
System.EntryPointNotFoundException: GetScrollInfo
  at (wrapper managed-to-native) BrightIdeasSoftware.NativeMethods:GetScrollInfo (intptr,int,BrightIdeasSoftware.NativeMethods/SCROLLINFO)
  at BrightIdeasSoftware.NativeMethods.GetScrollPosition (System.Windows.Forms.ListView lv, Boolean horizontalBar) [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.get_LowLevelScrollPosition () [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.BuildList (Boolean shouldPreserveState) [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.BuildList () [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.DoUnfreeze () [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.Unfreeze () [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.set_Frozen (Boolean value) [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.System.ComponentModel.ISupportInitialize.EndInit () [0x00000] in <filename unknown>:0 
  at SphereStudio.Plugins.TaskList.InitializeComponent () [0x00000] in <filename unknown>:0 
  at SphereStudio.Plugins.TaskList..ctor () [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) SphereStudio.Plugins.TaskList:.ctor ()
  at SphereStudio.Plugins.PluginMain.Initialize (ISettings conf) [0x00000] in <filename unknown>:0 
  at SphereStudio.PluginShim.Activate () [0x00000] in <filename unknown>:0 
  at SphereStudio.PluginShim.set_Enabled (Boolean value) [0x00000] in <filename unknown>:0 
  at SphereStudio.CoreSettings.Apply () [0x00000] in <filename unknown>:0 
  at SphereStudio.Forms.IDEForm..ctor () [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) SphereStudio.Forms.IDEForm:.ctor ()
  at SphereStudio.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.EntryPointNotFoundException: GetScrollInfo
  at (wrapper managed-to-native) BrightIdeasSoftware.NativeMethods:GetScrollInfo (intptr,int,BrightIdeasSoftware.NativeMethods/SCROLLINFO)
  at BrightIdeasSoftware.NativeMethods.GetScrollPosition (System.Windows.Forms.ListView lv, Boolean horizontalBar) [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.get_LowLevelScrollPosition () [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.BuildList (Boolean shouldPreserveState) [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.BuildList () [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.DoUnfreeze () [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.Unfreeze () [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.set_Frozen (Boolean value) [0x00000] in <filename unknown>:0 
  at BrightIdeasSoftware.ObjectListView.System.ComponentModel.ISupportInitialize.EndInit () [0x00000] in <filename unknown>:0 
  at SphereStudio.Plugins.TaskList.InitializeComponent () [0x00000] in <filename unknown>:0 
  at SphereStudio.Plugins.TaskList..ctor () [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) SphereStudio.Plugins.TaskList:.ctor ()
  at SphereStudio.Plugins.PluginMain.Initialize (ISettings conf) [0x00000] in <filename unknown>:0 
  at SphereStudio.PluginShim.Activate () [0x00000] in <filename unknown>:0 
  at SphereStudio.PluginShim.set_Enabled (Boolean value) [0x00000] in <filename unknown>:0 
  at SphereStudio.CoreSettings.Apply () [0x00000] in <filename unknown>:0 
  at SphereStudio.Forms.IDEForm..ctor () [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) SphereStudio.Forms.IDEForm:.ctor ()
  at SphereStudio.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0 

Dunno if I'm missing any crucial dependencies, but I notice this error is different than ones I have posted before.

What happens if you delete TaskListPlugin.dll?

Oh wow. Oh my god. It actually opens. A lot doesn't do anything/is bugged/makes it freeze, but I can actually change the settings, and even open a project and view its files. Didn't expect that whatsoever.

So far, what didn't work:
- The Open icon in the task bar just does nothing
- Using File > Open Project, I have to manually type game.sgm in a game folder in order to actually open the project.
- Double-clicking any file just makes the interface freeze until I close the program.

In any case, I didn't expect it to run natively at all, so this is quite nice!

Thats great, it'll give me a basis to start debugging from.  I wonder if the freezes/crashes are the same thing that happens under Wine... in any case this is good that it opens - I can probably use GDB to track down the rest of the bugs.

Regarding the manual open by typing game.sgm: That's actually not a bug, but by design in v1.2 - you're intended to upgrade SGM projects to .ssproj (there's a menu item for that) which allows using all the new project features, like building for minisphere with Cell, selecting different engines, etc.

I'm actually surprised it opened the project at all without an .ssproj file present!

Oh, okay. From a usability standpoint, might it not be better to display the SGM files anyway and show a dialog to convert it to .ssproj right away when trying to open them, and then opening that? There's so many Sphere games out there with just an sgm, so...

That's probably a good idea, I'll see about fixing that.

@Radnen: I'm currently looking into upgrading the script plugin to use the latest Scintilla from NuGet, which would allow the Scintilla DLLs to be removed from the repo.  It's not going to be easy though: You thought the Scintilla API was bad before?  They somehow managed to make it even worse!   They completely reorganized and refactored all the methods and properties and somehow it's NOT an improvement at all.  I was about to give up to be honest, but I figure this will probably be needed now in order to support syntax highlighting for TypeScript and CoffeeScript code (especially the latter--TS can probably get by for now with standard JS highlighting).

By the way, what is the license for Sphere Studio?  The main LICENSE file says GPL3, but I also remember finding an MIT license in there somewhere.  So I'm not sure.

@Radnen: I'm currently looking into upgrading the script plugin to use the latest Scintilla from NuGet, which would allow the Scintilla DLLs to be removed from the repo.  It's not going to be easy though: You thought the Scintilla API was bad before?  They somehow managed to make it even worse!   They completely reorganized and refactored all the methods and properties and somehow it's NOT an improvement at all.  I was about to give up to be honest, but I figure this will probably be needed now in order to support syntax highlighting for TypeScript and CoffeeScript code (especially the latter--TS can probably get by for now with standard JS highlighting).

Yeah, I saw that too. Then I realized how much of a pain the new API became. I just didn't have the time to learn it all. I mean, I felt good after cracking the old API. Now... eh, no thanks. Did you notice any feature improvements? Or is the API too convoluted to not notice XD. One thing I want to see someday is a style editor. Because I've been preferring darker text editors than white/light editors. It's easier on the eyes.

By the way, what is the license for Sphere Studio?  The main LICENSE file says GPL3, but I also remember finding an MIT license in there somewhere.  So I'm not sure.

I'm not sure about the license either! I wanted GPL3 because I could bundle it with Sphere. But then I thought MIT was very attractive and wanted to use it too.

Ugh... I'd go with MIT License since I don't care anymore about bundling this with Legacy Sphere.

edit: I hope you... agree? I'll need your consent in writing I think. I'm changing it now to MIT. BTW, I think we need to start copy-pasta the MIT all over the codebase. Ugh... I hate doing that. <cringes>

Oh right, I contributed a bunch of code. . I don't mind at all, I'll gladly relicense my contributions under MIT.  I prefer that over GPL anyway.

As for Scintilla, the new version does seem to have much better syntax highlighting features at least, I was experimenting with it before.  We'll be able to have it highlight Sphere API function names and stuff like that in a different color, which was previously impossible.  It also seems to have basic Intellisense too, but I haven't figured out how to use it properly.

Here's a screenshot of my progress on the Scintilla conversion so far.  A few things are broken right now: Stupid things like Ctrl+F doesn't open the Find dialog, etc. that I will have to figure out.  But the syntax highlighting in this version is much, much better!

Awesome! Is there an xml that can be configured. Because one of these days adding a style editor would be fantastic.

Also, I wonder how much trouble it is to use a parser like ANTLR to do code formatting and intellisense?

The keyword list for Sphere API functions is stored as a separate text file (Dictionary/SphereAPI.txt), my next step was to put the default coloring and font parameters into its own XML file too, but I didn't do that yet because I'm still experimenting and figuring out which colors work best for which keywords.  My current scheme:

* Blue - JS keywords (like MSVC)
* Purple - "pseudo-keywords" which have special meaning but might be redefined, e.g. eval, global, undefined (!)
* Cyan - Sphere API (current to minisphere 3.0rc6)
* Dark red - strings and number literals
* Green - comments
* Pale yellow - Current Line highlight

This is going to be a bigger undertaking than I thought: it seems the new control was recoded from the ground up and lost a lot of functionality it had previously.  For instance Find/Replace is no longer built-in so I'd have to implement that myself.  Since I don't feel like going down that road right now I moved the changes thus far onto a separate branch to avoid loss of functionality in the master builds.

I agree about the style editor.  I've dabbled with dark themes myself, and if the syntax highlighting colors are well chosen, it's really a lot easier on the eyes than the typical white-on-black.  A lot of that I think is that, with a dark theme, you don't need to have a lot of contrast to be usable: You can have silver text on a gray background and it's fine, whereas with a white background you need black or very dark colors in order for everything to remain readable.

But yeah, I'm not really up to coding in the missing features right now, so we can maybe revisit this some other time.

Just to clarify, I still want to go through with the change, but noting that it requires extra effort to be made and so will likely take a while longer.  That said, having Sphere API calls highlighted in the source is really nice, as you can see in the screenshot below.  If you make a typo, you'll know because the function won't turn purple.

Anyway, being forced to rewrite the Find/Replace dialog might not be such a bad thing, though.  The huge Find dialog is kind of an anachronism at this point.  It would be nice to take a leaf from MSVC and modern browsers and implement a mini search bar that pops up at the top of the script view when you press Ctrl+F and highlights text as you type.