[MODIFICATION] AGS v.3.3.2.0 Draconian Themed Code Editor

[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++).

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

[ChamberOfFear]

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.

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++).

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]

#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]

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

[Calin Leafshade]

Here's visual studio's dark theme as a guide.

[ChamberOfFear]

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]

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]

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]

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]

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.

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

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]

<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.

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.

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

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]

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]

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.

[ChamberOfFear]

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).

My thinking / reasoning was that the editor should provide two default themes, a light and a dark one. However in retrospect the default light theme is probably enough, especially since it's built into the Windows Forms.

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:

No this is not OK. It shouldn't be like this if it can be avoided. I have to admit this is the result of getting increasingly frustrated of not making some aspects of the implementation work as I wanted it to. I don't remember specifics but the conclusion is that it should be redone so that there are no if-sentences in the implementation. Also the entire function "LoadColorTheme()" that I call in various GUI code-behinds should probably be split up and moved in the GUI Designer code file instead. Makes more sense from an implementation perspective.

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?

All of this sounds feasible I think, although it's a lot bigger task than I originally intended, so it will probably be a while before I find the time to take a look at it.

[monkey0506]

although it's a lot bigger task than I originally intended

Creating the multi-platform interface for the editor turned out to be a lot more work than I had originally anticipated too, but CW steered me in the right direction by not letting me take messy shortcuts (even if I promised to clean them up later). What he's said isn't a simple, quick fix, but it's worth doing the right way. And don't worry if it takes time, that's why we're not paying you!

[jwalts37]

I actually did the same thing recently, except I had added an option to change themes from the preferences menu. The thing that bugged me was that whenever you switched it, the script had to be reopened in order for changes to take effect. I finally figured out how to "refresh" it real time. Its been so long since I was in there but if you'd like to get together and work on this feature or something ChamberOfFear, let me know. I was always too afraid to post my changes here for fear of all the exceptional programmers being like "THIS IS GOD AWFUL SHIT" even though I know they wouldnt. Let me know!
-Josh

[jwalts37]

Also, the 3.3.3 version doesnt seem to be working.

[ChamberOfFear]

I actually did the same thing recently, except I had added an option to change themes from the preferences menu.

Note sure what you mean, this option exists, at least in the later versions. Don't remember if had this option in the older ones.

Also, the 3.3.3 version doesnt seem to be working.

Please check that you changed the theme in preferences. I fairly certain the v3.3.3 should be working as that is the one I'm using myself.

[ChamberOfFear]

1) Reading theme from file (XML?); alternatively support plugin interface for custom theme class.

How should I go about handling this? I imagine that having a default location on disk dedicated for said xml files would be convenient. Say there is a folder "Color Themes" in the AGS installation directory which contains xml files, each file is a theme that can be loaded into Preferences, and then be chosen by the user. Where on the disk would it be conventional to put these files?

Also, if I'm going to solve this with xml it would be convenient to have access to LINQ or lambda expressions which is currently not supported since the editor uses .NET 2.0. (Actually that would be convenient just in general.) I noticed there was a discussion some time ago about upgrading to .NET 3.5 but the discussion didn't seem to reach a conclusion http://www.adventuregamestudio.co.uk/forums/index.php?topic=50995.0
Could we do the upgrade?

I finally figured out how to "refresh" it real time.

This sounds interesting, do you have the code online somewhere for reading?

[Crimson Wizard]

1) Reading theme from file (XML?); alternatively support plugin interface for custom theme class.

How should I go about handling this? I imagine that having a default location on disk dedicated for said xml files would be convenient. Say there is a folder "Color Themes" in the AGS installation directory which contains xml files, each file is a theme that can be loaded into Preferences, and then be chosen by the user. Where on the disk would it be conventional to put these files?

Just "Themes" maybe (?); it sounds shorter and more generic .
Regarding the location... we may consider that in future there will be an integrated theme designer (or plugin); or anyway the user should be able to modify them or upload new ones. I think therefore it won't be convenient to place them in the installation folder, because a) user may have several versions installed, b) latest Windows does not like files modified in Program Files. Perhaps find a new location in %AppData%? We could move game and room templates there too later.
Are there any files that AGS saves to AppData already?

Also, if I'm going to solve this with xml it would be convenient to have access to LINQ or lambda expressions which is currently not supported since the editor uses .NET 2.0. (Actually that would be convenient just in general.) I noticed there was a discussion some time ago about upgrading to .NET 3.5 but the discussion didn't seem to reach a conclusion http://www.adventuregamestudio.co.uk/forums/index.php?topic=50995.0
Could we do the upgrade?

I recall trying that out by simply changing NET version in a project:

Well, changed all projects including native lib to 3.5, it compiles and runs, did not notice anything bad.

I'd say we could changing it and make test runs. I think it should be tested on WinXP to see if it still works. Additionally, we could do tests on Wine and whichever thing Mac users use to run Windows apps (Wineskin?); I heard number of users run AGS on Linux & Mac.

[ChamberOfFear]

Perhaps find a new location in %AppData%?

That works, thank you.

Are there any files that AGS saves to AppData already?

On my computer I found a file named Layout.xml. I think it contains savedata on the docking layout of the editor.

I'd say we could changing it and make test runs. I think it should be tested on WinXP to see if it still works. Additionally, we could do tests on Wine and whichever thing Mac users use to run Windows apps (Wineskin?); I heard number of users run AGS on Linux & Mac.

I don't really have access to WinXP or Mac, and is somewhat inexperienced in Linux, so I may not be that helpful in testing if it works. However it would be great if this upgrade got realized as .NET 3.5 has more convenient tools than .NET 2.0.

[Monsieur OUXX]

Careful if you start using %AppData%. That's for custom settings, that are saved after the game's first execution (typically: the position of docking windows, in layout.xml). Big fancy apps like Photoshop will copy their default brushes there (at installation time), to demonstrate that they are all still custom in essence, but that's only for showing off.

The default themes, however, would probably be shipped along with AGS. Hence their location should be the Editor's folder (inside /Themes subfolder).

Maybe what I wrote above is utter bullshit ^ Please ignore it if it turns out I made a complete fool out of myself.

[ChamberOfFear]

Well the one and only default theme, which I so far have just referred to as the Vanilla theme, comes from the code itself(Windows Forms), not xml-files. The custom themes works independently from that, so I don't think it should be a problem. In fact, the way you describe it makes %AppData% the perfect location to store these files if the implementation turns out as I have intended it.

[jwalts37]

Haha I guess now Im confused. I had added an option in preferences to change the theme.

At the time I couldn't figure out how to refresh real-time so the current script had to be reopened. But I actually ended up figuring out how to redraw/fresh it. I dont remember this option being in any of the major releases. Is that what you meant?

[Dave Gilbert]

Sorry to necropost! Lately I've been getting annoyed by the light-blue text on the white background (in the dialog editor specifically) and was hoping there was a way to change the colors. Has there been any further attempts to merge this with the latest version of AGS?

[Crimson Wizard]

Two years ago I was suggesting to improve the code, but since the development of Editor has since stopped, I guess there is not much sense to aim code beauty. So, yes, let's put this in.

[Dave Gilbert]

Sweet!

[AnasAbdin]

Sorry to bump this, I'm using "v3.3.3, December 2014"..
is there a way I can get the dark theme with/without a patch that I don't know about?
MY RETINAS GOT BLEACHED FROM THE WHITE BACKGROUND

[Crimson Wizard]

IDK if we should continue in the same topic, but there is a new pull request by persn (aka ChamberOfFear) with the new version of this feature: https://github.com/adventuregamestudio/ags/pull/427

[Crimson Wizard]

Compiled editor for those who'd like to test: https://www.dropbox.com/s/4peq0unk29grqrs/ags-editor-themes.zip?dl=0

WARNING: This is built over master branch, which is WIP code. I do not remember if AGS game format was changed there compared to 3.4.1. Maybe not, but make backups if you are opening your real game projects.

How to test: go to %USERPROFILE%/AppData/Local/AGS and manually create "Themes" folder there (there is a small bug in the editor, so you need to do that by hand).
Then, download this: https://github.com/adventuregamestudio/ags/files/1613027/VisualStudioDark.zip
Unpack and place the VisualStudioDark.json into the folder.

Start the Editor, open Preferences and change Color Themes option in "Editor Appearance" group.

[Alan v.Drake]

Compiled editor for those who'd like to test: https://www.dropbox.com/s/4peq0unk29grqrs/ags-editor-themes.zip?dl=0

You should include "Newtonsoft.Json.dll" in the archive, or else no one but us, who hold the knowledge of gods, will be able to try it out. 

- Alan

[Crimson Wizard]

Added.

[Crimson Wizard]

Updated version from the latest source (with some fixes): https://www.dropbox.com/s/4peq0unk29grqrs/ags-editor-themes.zip?dl=0

Reminder: DO NOT SAVE YOUR ACTUAL GAME PROJECT in that editor (yet), because it is based on untested post-3.4.1 version.

How to:
Download this: https://github.com/adventuregamestudio/ags/files/1613027/VisualStudioDark.zip and unpack somewhere.
Open the Editor, go to File -> Preferences: Editor Appearance - Import Color Theme. Choose the theme file you unpacked. Make sure it is selected in the combo box. Press OK.
Now restart the Editor.

Pull request on github: https://github.com/adventuregamestudio/ags/pull/427

[Crimson Wizard]

Come on, people kept asking to add Draconian dark theme to the "official" AGS editor, and when we have an actual test build no one wants to try out

PS. Hmm, maybe we should update the first post and topic title?

[Dave Gilbert]

I think there might be some confusion. This is an update to AGS 3.4.1 that you released recently? Or is it an update to the Draconian version of the editor? The name of the thread is confusing. Since I use 3.4.1 exclusively, I don't want to mess anything up.

[Crimson Wizard]

Yes, you are right, this is too confusing. I guess I did a mistake posting this.

[Dave Gilbert]

So... which is it?

[Crimson Wizard]

The one mentioned in the first post is an old update to 3.3.2, which was never officially released.

The one I posted in the recent post here is a new update to 3.4.1 which ChamberOfFear made recently. It is a completely new version, that works differently, in theory even letting you edit colors of the theme yourself.

It just that I cannot advise to use it with real 3.4.1 projects yet, because it's based on further development branch (after 3.4.1).
Actually, I might check which changes editor has got, maybe it may be safe to use with 3.4.1 games too.

I posted this simply wishing other people played with it a little, because there is an open pull request which we may merge to our master.

In fact, we could just merge it, assuming there will be new period of beta test anyway.

[Dave Gilbert]

Ah. OK. In that case I will hold off testing it. Thanks.

[selmiak]

This is really interesting and confusing. Just merge it. The editor colors from the main brain CW just linked seems more interesting to me as it might become part of a stable AGS version sooner...? Or be tested sooner?! yeah, confusing, just give us a stable AGS editor with dark color theme (to play around with)

[Alan v.Drake]

I think this thread should be closed and a new one opened.

- Alan

[NicolaGs]

Come on, people kept asking to add Draconian dark theme to the "official" AGS editor, and when we have an actual test build no one wants to try out

Found some time to test it. It works fine.

[Crimson Wizard]

Ok, ok. Sorry for confusion.

There is just one set of issues I found, related to the bad JSON format (it crashes editor hard): https://github.com/adventuregamestudio/ags/pull/427#issuecomment-360509823

So long as the theme is provided by a skilled human this won't be critical for WIP release, but has to be fixed before version may be called stable.

[m0rph84]

Holding my breath for it

[ChamberOfFear]

Merged to master. Hooray

[Crimson Wizard]

Added in the WIP release: http://www.adventuregamestudio.co.uk/forums/index.php?topic=55829.0

I would like to close this thread, because it was started years ago. Maybe create a new one for further discussion (if necessary).