[MODIFICATION] AGS v.3.3.2.0 Draconian Themed Code Editor

Started by ChamberOfFear, Wed 10/12/2014 05:55:34

Previous topic - Next topic

ChamberOfFear

This isn't really neither a Module or a Plugin, but it seemed the best related place to put it.

Couple of years ago I briefly tried the AGS Draconian Edition, and I was a big fan of the slick dark colors in the code editor. Since I didn't see a dark theme making its way into the official AGS anytime soon I took the matters into my own hands and built a modified .exe file which does a color swap exactly like the one in the Draconian Edition. I'll share it here for others with similar interests to enjoy.

Sample:



Instructions:
Unzip the file "AGSEditorDraconian.exe" into your "Adventure Game Studio 3.3.2" folder, run that instead of the original "AGSEditor.exe".

Note:

  • This is only tested on, AGS 3.3.2.0, which is the version of the source code that I modified.
  • This should not change any project settings or similar. It only does a color re skin, to my knowledge it should work exactly the same as vanilla would.

Credits:
Based on the code of Alan v.Drake for color reskin.

Download.

Off-topic:
I was thinking I could have a fun holiday project with building an AGS plugin which changes the color theme of the AGS editor. Is this at all possible with the current AGS Editor plugin API? In order to do color swaps on the code editor I had to fork the project and do my own modification in "ScintillaWrapper.cs" by changing code lines like this
Code: ags
this.scintillaControl1.StyleSetBack(Cpp.Default, DefaultBackColor);

Is it possible to access "scintillaControl" from the Editor Plugin API? Is there any other way I could attack this problem to customize colors?

By default I think an IDE or similar should provide at least two color skins, a light one, which would be the vanilla theme, and a dark one, which in this case would be the Draconian theme.

BigMc

Why don't you just do this in a way that the theme can be switched and send the patch (or pull request) to the others to review and include?

Gurok

I can think of a third skin. If the default is the Windows Visual Studio standard, it would be nice to have a theme that mimicked the blue-backed DOS editors (e.g. Turbo C++). :D

Ultimately, it would be nice to have external skin files with colour schemes in them.
[img]http://7d4iqnx.gif;rWRLUuw.gi

ChamberOfFear

Quote from: BigMc on Sun 14/12/2014 21:08:45
Why don't you just do this in a way that the theme can be switched and send the patch (or pull request) to the others to review and include?

Hmm, I might just do that.

Quote from: Gurok on Sun 14/12/2014 21:19:56
I can think of a third skin. If the default is the Windows Visual Studio standard, it would be nice to have a theme that mimicked the blue-backed DOS editors (e.g. Turbo C++). :D

Ultimately, it would be nice to have external skin files with colour schemes in them.

Ahh, you mean the blue background with the bright neon-like coloring for code. Not my cup of tea I have to admit, but still I might look into it.

I agree that having external skin files for custom coloring is ideal, but I imagine it would increase the workload of this project a great deal. I think that dividing the implementation into steps would be a good way to go. If I ever finish step #1, me or maybe someone else will be inspired into looking into resolving step #2 later, where the steps would be:

  • Implement a color theme switcher between light and dark for the Code Editor.
  • Implement a color theme switcher between light and dark for the whole AGS Editor. After all, this, looks better than this.
  • Implement a custom color chooser which store user choices in a file, and lets them load it into the editor, share them online, etc.
Couple of things I need to figure out though.

#1 Preferences extension
Is it okay if I extend the Preferences GUI with another option for color theme like this? I've noticed that there already is a group box for the script editor. But keeping in mind that I might want to test and see if I can make similar color swaps with the rest of the AGS editor GUI components.


#2 Git branch
Which branch should I base my work on? develop-3.4.0?

#3 Color themes
The vanilla theme is cemented as far as I'm concerned. However since the vanilla theme follows the Visual Studio coloring, should I try to do the same for the dark theme for AGS? So that it follows the same coloring that Visual Studio uses for its dark theme?

selmiak

Quote from: ChamberOfFear on Mon 15/12/2014 09:08:01
#3 Color themes
The vanilla theme is cemented as far as I'm concerned. However since the vanilla theme follows the Visual Studio coloring, should I try to do the same for the dark theme for AGS? So that it follows the same coloring that Visual Studio uses for its dark theme?
who needs an exact replica of a MS colorscheme, they are not adobe, just make it look cool and easy on the eyes. I prefer a dark theme for nightly session over a bright theme. If you want to earn some nerdy MS fanboy kudos though, mimic the MS colorscheme, and maybe add a metro theme for ags ;)

Calin Leafshade

Ideally I'd like a much more flexible preferences system. A key/value system similar to visual studio.

But having the ability to switch between a light and dark theme for AGS would be great in the interim.

ChamberOfFear

#6
Guess I've progressed far enough now to show off what I have at this point.


Calin Leafshade


ChamberOfFear

Quote from: Calin Leafshade on Wed 17/12/2014 23:36:22
Here's visual studio's dark theme as a guide.

Thank you, but I have Visual Studio with Dark Theme installed on my computer :) It is in fact what I'm using while I'm doing these changes. I've literally been color picking from VS Dark Theme when I've chosen dark colors for AGS. Did you post the picture because because you were thinking of something specific?

selmiak

Looking cool already. If you manage to darken the scrollbars and dropdown menues too then it should be done I guess (not seeing other editor parts...)

ChamberOfFear

Quote from: selmiak on Thu 18/12/2014 21:30:19
Looking cool already. If you manage to darken the scrollbars and dropdown menues too then it should be done I guess (not seeing other editor parts...)

Drop down menus:
Already taken care of.

Scroll bars:
That's a no-go I'm afraid. Since Windows forms components acts as containers that are sent out to Windows to deal with. Windows will receive those components and wrap its stuff around them, including scroll bars, I have no control of that one and it annoys me endlessly.

Other editor parts:
I haven't dealt with those yet. I will be be moving on to each individual tool in the project tree once I'm satisfied with everything in the main editor.


tzachs

Quote from: ChamberOfFear
Scroll bars:
That's a no-go I'm afraid. Since Windows forms components acts as containers that are sent out to Windows to deal with. Windows will receive those components and wrap its stuff around them, including scroll bars, I have no control of that one and it annoys me endlessly.
you can use a custom scrollbar to replace the default one.

ChamberOfFear

Quote from: tzachs on Fri 19/12/2014 13:06:04
you can use a custom scrollbar to replace the default one.

Thank you for the suggestion, but I was unable to make it work properly. I'm not sure exactly why but there might be a conflict with the AGS docking mechanism and associated auto-size functions, as the solution in the link you provided doesn't actually replace anything, it just hides the windows component and puts its own GUI component on top. I might have been able to figure out a solution for it eventually, however I'm afraid my attention span for this little project is starting to run out.

But still, let me wish the AGS community a merry Christmas and show off my work so far.

Gallery

Test Build

Source code

I will probably just leave this lying around for a couple of days, if there is no specific feedback I'll ask for a pull request.

Crimson Wizard

#13
Before anything else, I want to say that I will probably use this dark theme :).

However, to prevent possible future misunderstanding I think I must jump in here.
Quote from: ChamberOfFear on Wed 24/12/2014 05:52:52
I will probably just leave this lying around for a couple of days, if there is no specific feedback I'll ask for a pull request.


First of all, please refer to the pull request & commit convention I wrote for us to use:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.0

I might have choosen a wrong place to put the topic, so it could go unnoticed to those who usually read Editor development section of the forums. But I could not find a solution to this at the time. Probably I'd need to move the text to Wiki.

Anyways, how is that important in regards to your work:
1) You were working directly in "develop-3.4.0" branch, and merged your work with latest changes in the central repository, creating redundant "merge" commit that would now go into the pull request. It is not critical, of course, but we usually try to avoid such dummy commits by creating a separate working branch and rebasing it instead of merging (or simply not updating at all if the changes to central repo do not conflict with your work).

2) I can't tell for certain without closely examining the code, but from the descriptions of your commits I may suggest you were doing some "dirty" solution first, and "clear" solution later. This is too something we try to avoid when possible, because it will get unnecessary code history in the repository (your "dirty" solution that was never actually used).
Besides the convention I referenced earlier, here I tried to explain the reasons for such rule on one recent occasion:
https://github.com/adventuregamestudio/ags/pull/207#issuecomment-61423098
Quote
If you are making a sequential changes to the project, like some logical steps, each of which adds a part of feature or a group of features, or a change, each of which has particular meaning on its own, - that's pretty much okay for a pull request.

However, if you are making some temporary changes for a test, or write some big piece of code, then scrap/overwrite large parts of it later, then it is probably not good for a pull request, because that would be a history of you devising some concept, rather than history of changes to a project.

Again, I can't tell from the first glance how much this is applicable to your case; basically, the idea is that if you change the same place in code more than once for the only reason of first version being incorrect, then it is better to re-create a cleaner branch without "dirty" commits.


I may propose to do following:
1) Create a new working branch at your latest commit (call it as you prefer, it does not really matters).
2) Rebase this new branch over develop-3.4.0 of "adventuregamestudio/ags" (not yours develop-3.4.0).
3) What you will have now is a clear working branch on top of central develop-3.4.0, which contains only your commits in a sequence.
4) Now you may delete your local "develop-3.4.0" (or rename it if you are afraid to loose some code by mistake), and checkout the central one again to have a matching branch.

If you feel like this needs further cleaning, you may then create a second working branch from "develop-3.4.0" and copy/rework commits from the first working one.

ChamberOfFear

Thanks Crimson. I'll give your suggestions a thorough read through once Christmas Eve has ended and post the result for review again.

Monsieur OUXX

<annoying message>I strongly advise not to create any custom GUI controls, especially "standard" ones like scrollbars. 99% of the time they are much, much more complex to implement than they seem, and it does nothing else than introducing bugs.</annoying message>
 

Calin Leafshade

Re: scrollbars

simply take the scrollbar control and override OnPaint

Re: the theme

The reason I linked the Visual Studio one is to demonstrate the contrast. In your version the dividing lines are essentially white and so the contrast is high. The point of a dark theme is generally to reduce contrast.

ChamberOfFear

Quote from: Monsieur OUXX on Wed 24/12/2014 16:17:07
<annoying message>I strongly advise not to create any custom GUI controls, especially "standard" ones like scrollbars. 99% of the time they are much, much more complex to implement than they seem, and it does nothing else than introducing bugs.</annoying message>
Don't worry, I completely agree with you. I've made it a priority to only extend with new code and not to tamper/modify with already existing code unless it was extremely minor and absolutely necessary. Replacing old GUI components with new custom ones goes far beyond the scope of a color re-skin. The custom scroll bar was only reviewed because the default one annoys me a little bit.

Quote from: Calin Leafshade on Wed 24/12/2014 18:42:15
Re: scrollbars
simply take the scrollbar control and override OnPaint
Would you care to elaborate a little? How do I "take" the scroll bar control? The closest looking Properties I've found are HScroll and VScroll which are bools for if the scroll bars should be visible or not, or VerticalScroll and HorizontalScroll which makes simple behavior stuff like positioning of the bar happen.

Quote from: Calin Leafshade on Wed 24/12/2014 18:42:15
Re: the theme
The reason I linked the Visual Studio one is to demonstrate the contrast. In your version the dividing lines are essentially white and so the contrast is high. The point of a dark theme is generally to reduce contrast.
Ahh, that's fair. Just to be clear, you're speaking now of how the layout looked when you posted the image or how it is now? I think it is somewhat more pleasing to the eyes after I reworked the output panels and the combo boxes. I feel like I'm running out of non-hack ways to make the dark theme even better, nevertheless your post inspired me to give several of the components a second third fourth fifth look. I probably wouldn't have thought to make these changes if you didn't make the post, so big thanks to you :-D

Main Editor Window:
The key difference here is the tool bar, it used to have a white line under it, but I finally figured out how to remove it.


Tree Views:
I removed the white line that showed indentation in the tree structure. It now looks more like the tree structure in Visual Studio.


Menu:
Separator lines are now gray instead of white.


Text Boxes:
The borders of the text boxes are no longer thick white and is replaced with a thin gray/white solution. I was only able to set border style and not coloring so the color "choice" will likely remain as it is. Incidentally the combo boxes still have a white frame around them, if anyone knows how to remove this I would be grateful.


ChamberOfFear

Quote from: ChamberOfFear on Thu 25/12/2014 04:36:12
Incidentally the combo boxes still have a white frame around them, if anyone knows how to remove this I would be grateful.

I finally found a fix for this


This is a good time to re upload the gallery and the executable build if anyone wants to see my latest changes in its entirety.

Gallery

Test Build

Crimson Wizard

#19
Ok, I terribly apologize for the delay. I am checking this pull request now. I think the color schemes are generally working (aside from few minor issues like scrollbars), but I've got a serious question regarding the implementation.

This really bugs me, whether is it alright to have these schemes hardcoded? And not just color numbers, there are even subclassed controls for particular theme (like DraconianComboBox).
Even more, some of the GUI classes now have a behavior selection in them, depending on chosen theme. For example, here's an excrept from "SpriteSelector" class:
Code: csharp

        private void LoadColorTheme()
        {
            ColorTheme colorTheme = Factory.GUIController.UserColorTheme;
            colorTheme.Color_UserControl(this);
            colorTheme.Color_TreeView(this.folderList);
            if (colorTheme is DraconianTheme)
            {
                this.spriteList.BackColor = (colorTheme as DraconianTheme).PanelColor;
                this.spriteList.ForeColor = (colorTheme as DraconianTheme).White;
            }
        }


May there be a way to generalize this somehow, without letting particular panel classes "know" which theme is selected and accessing their innards?

I understand this is just an experiment to bring the theme switching to AGS, but there's really no pressure for getting the feature ASAP; perhaps this all could be worked out more before merging into the main branch?

I do not do Editor design, but I would ask to consider those two ideas:
1) Reading theme from file (XML?); alternatively support plugin interface for custom theme class.
2) Hiding theme specific behavior under generalized interfaces.

Is this possible?

PS. I really hope that other people involved in Editor development (tzachs, monkey, Calin) would be able to check this too, because, as I mentioned, I was not acquainted with how Editor works very well.

SMF spam blocked by CleanTalk