The API for plugins is simple:

Code: (csharp) [Select]

var my_style_group = new StyleGroup();

my_style_group.Label = new Style();
// ...

StyleSettings.addStyle("CoolTheme", my_style_group);

// ...

StyleSettings.removeStyle("CoolTheme");

BTW I just expanded the style options (latest github code), now status bars, toolbars, and menu bars are styleable. The style system I use is not automatic, all controls need to be manually told what things get styled. I don't think that's bad considering the plugin author / I can choose what gets styled and what does not to prevent some weird style artifacts from happening: such as the awkward black text on black background.

There is still one issue: the settings editor does not enumerate a list of all styles. So far it just enumerates the built-in styles. But that will change shortly (it's not like we suddenly get a new style plugin tomorrow, lol).

Just tried out the updated version, looks really nice with the toolbars and menus styled as well.  If I had to say one thing though, it's that the green theme is a bit too bright.  Might want to go for a darker shade, closer to the green in my avatar.  Bright lime green is a bit distracting.

How about a 64-bit build?

Soon, there are changes that I want to finalize before I make an official v1.7. But you can use the 32 bit build in the meantime. The irrklang audio player plugin won't be available in the 64 bit build, however.

How about a 64-bit build?

I honestly don't see what 64-bit gains us at this stage of development.  Nothing in it uses ludicrous amounts of memory (seriously, if I start seeing 2+ GB maps I'm running for the hills) and it's an IDE so there are no CPU-intensive tasks it does that would benefit from the extra registers/expanded instruction set.  A 64-bit engine makes sense, but it just seems like overkill for an editor.  Maybe that's just me, though.

Edit: 64-bit is also harder to debug.  VS essentially has to start a remote debugging session since the CPU is so locked down in long mode that you can't debug natively (this is why Sharpdevelop won't debug x64 apps). Not only does that take longer to start up a debugging session, but you lose some debugger features as well I think...

Lord English: I agree with your sentiments; that's precisely the reason why you don't see a 64 bit build of IrrKlang. In this day there is still little reason to go 64 bit, it was only pushed to the consumer market as a business strategy since "32 bits" was basically sounding too old.

But I mean, I can make such a build, even if it doesn't make a lot of sense it's really just a button click away.

@Radnen: I just made an edit to my post re:debugging that you might want to know.  It didn't warn me when I made the edit that you ninja'd me...

How about a 64-bit build?

I honestly don't see what 64-bit gains us at this stage of development.  Nothing in it uses ludicrous amounts of memory (seriously, if I start seeing 2+ GB maps I'm running for the hills) and it's an IDE so there are no CPU-intensive tasks it does that would benefit from the extra registers/expanded instruction set.  A 64-bit engine makes sense, but it just seems like overkill for an editor.  Maybe that's just me, though.

In this day there is still little reason to go 64 bit, it was only pushed to the consumer market as a business strategy since "32 bits" was basically sounding too old.

But I mean, I can make such a build, even if it doesn't make a lot of sense it's really just a button click away.

I for one would like to see a 64-bit build. I have a 64-bit machine with a 64-bit OS, I much prefer to use 64-bit software whenever possible.

For Mono, there is a good reason to offer 64-bit as well. I wouldn't have to install all the 32-bit Mono stuff along side the 64-bit version.

That doesn't stop me or discourage me from using a 32-bit version if that's all there is, mind you.

If a given app doesn't do anything that warrants full 64-bit support, you're just adding bloat (larger pointers, etc.) by compiling it to x64.  Of course, this argument is only for applications.  For middleware like irrklang, there's no excuse in my eyes for not providing a 64-bit build, since you can't link a 64-bit app (which may indeed have a good reason for being so) against a 32-bit DLL.

It also might be worth mentioning that, as far as I know, MS still recommends everyday end-users install the 32-bit version of Office, even on 64-bit machines.

That said, there will be a 64-bit build of Sphere Studio eventually, we just have to find a different audio engine than IrrKlang.  As mentioned earlier in the thread, I tried BASS, but the .NET wrapper for it is horrible--it's literally a verbatim transcription of the C API.  I really don't have the patience to deal with that at the moment.

Hey Radnen, I noticed a glitch where, on startup, the panes on the start page are misaligned.  I've tried several things to fix it (Refresh, PerformLayout, etc. and at several levels of the docking hierarchy), but to no avail.  I initially suspected a bug in DockPanelSuite, but then I realized it's only the start page that's messed up, the rest of the UI seems fine.  Any idea what's causing it?

I have seen that too. I have the faintest idea of what's happening. It never used to do that prior to the move to .net 4.0. I do notice that if you jiggle the divider between the start page and the project file list, it will realign. So it has to be a docking issue. Also, hiding it and showing it will realign the panel. I think a quick n' dirty workaround is to show/hide it.

Edit: I fixed it.
What did the trick was to rearrange the order in which the panels popped into view. Which is a strange but it seems to work.

Also, sometimes the style colors did not update for the panels in the start page (still hold the old color until you did the two things above). The labels did update fine, however. But after this fix it all seems to work properly now.

@Radnen: I just implemented custom style selection in prefs; check your pull requests on GitHub.

Love the new style changes, Lord English. I just pushed some other changes too. I now added 'secondary' styling. It's basically a catch-all styler for nested components. The useful thing here is that foreground, nested controls can stand out with a custom backing. The next step is to go through each plugin and have them implement the IStyleable interface - which basically says "this control has been given the ability to style itself", even though there is technically no manager that does it. I just think it's cleaner from a code point of view to have standardized a single method into an interface for styling - kinda like how IDisposable works for disposing.

Anyways, some neat themes are coming along. Oh, I also tweaked the colors so they look softer/more natural. I even gave the light theme a light secondary color for labels since an all-white theme was a bit too overwhelming (thanks MS for creating such a crappy theme for VS2012 ), I hope the slight change makes it easier on the eyes.

Tell me what you think of this 'secondary styling option'.

Also, I modified the editor settings to use a more styled presets menu, then I added an Apply button so you can 'try before you buy' kind of thing. But you actually end up buying since it works like all apply buttons do and saves all the others changes right there and then without leaving the dialog box.

Hm, not sure I like the list backgrounds being muted like that, especially since almost every other app uses white for the back of lists (a dull background is usually an instinctive visual cue that the control is disabled).  We can make custom themes later that use a different back color for the lists, but the built-in ones should stick to white, I think.  As for the secondary style, it seems like a good idea, but I'm not entirely sure I understand its purpose... is it like, if no style is defined for a given control type, you apply the secondary style?

Oh, and the Apply button is in an awkward position.  Almost every Windows app I've ever used puts the buttons in this order: OK, Cancel, Apply.

And regarding VS2012: They added more color to the icons in VS2013 (folders are back to being manilla, and the toolbar icons are more colorful and stand out more), and the VS2010-style "Blue" theme seems to be the default now.  I guess they learned from their mistake.

Hm, not sure I like the list backgrounds being muted like that, especially since almost every other app uses white for the back of lists (a dull background is usually an instinctive visual cue that the control is disabled).

But the trick here is that people know this is themed; plus the disabled style is bad taste on MS for locking it down like that: they should have given people the ability to style that coloring as well. Look at Photoshop, it's all kinds of colors but it doesn't use .NET controls. I'll not style the list view then. But you are right I don't want the built-in styles to be too exotic.

We can make custom themes later that use a different back color for the lists, but the built-in ones should stick to white, I think.  As for the secondary style, it seems like a good idea, but I'm not entirely sure I understand its purpose.

The purpose of the secondary style is to highlight nested controls. Without it everything else would be white. Look, I can style all panels, but what happens if I want a panel to be of a secondary color? It couldn't happen, secondary is intended for styling the other control, and as I said is usually a nested control.

Oh, and the Apply button is in an awkward position.  Almost every Windows app I've ever used puts the buttons in this order: OK, Cancel, Apply.

I actually was thinking it to move to the far left. But ok, I guess to the right is alright. That said I am going to change OK to "Save" as because that sounds more informative.

And regarding VS2012: They added more color to the icons in VS2013 (folders are back to being manilla, and the toolbar icons are more colorful and stand out more), and the VS2010-style "Blue" theme seems to be the default now.  I guess they learned from their mistake.

I'm really happy to hear that.