Jump to content
The Dark Mod Forums

New Colour Scheme Handling


Recommended Posts

Ok, what are our requirements for the new colour scheme code? I can think of this:

 

- Everything's stored in the registry (that was clear anyway).

- A new dialog is opened where a list of saved colour schemes are displayed. Each scheme can be edited freely and saved as a new one (Save as...).

 

The class hierarchy would be like this:

- Colour (with "item" name and its colour value), basically a struct

- Scheme (consisting of name and a map of colours)

 

Methods located in the scheme class would be load(), save(), setItemColour(item, colourvalue), getItemColour(item) and of course the constructor that loads all the existing schemes from the registry.

 

I can figure that a good deal of the work will be the scheme editor dialog with all its callbacks, but I already have a rough picture in mind of what would be necessary.

 

Any comments?

Link to comment
Share on other sites

  • Replies 72
  • Created
  • Last Reply

Top Posters In This Topic

I don't think an in-editor scheme editor is necessary. I would just have all of the colour scheme data in the XML, and have a simple submenu where you can select a scheme. People who want to customise colours or add new schemes can edit the XML.

Link to comment
Share on other sites

Wouldn't this be a step back from the current system? You can choose many colours directly with a colour picker in the misc menu - I would find it inconvenient to have the user type in vector3-floats into the XML.

Link to comment
Share on other sites

I suppose, if it's not too much work to implement.

 

Look at ModelSelector for an example of how to implement a dialog. It is encapsulated by an object which has a number of static callbacks for GTK to use, with a pointer to itself passed as the void* optional data argument. Actually the TextureChooser under ui/einspector might be a better example, because it is not implemented as a singleton.

Link to comment
Share on other sites

Just a quick update of my status:

 

So far I've got the colourscheme routines implemented and the schemes can be loaded and saved correctly from and into user.xml. A rough version of the Colourscheme Editordialog is up and running, but at the moment it's dead ugly:

 

uglycolourschemeeditorwl8.th.jpg

 

I had a hard time figuring out the importance of the gtk_main() call, and I learned quite a bit about the GTK+ widgets, that's why it took me so long to get this "far". Additionally, I had to add some functionality to the XMLRegistry functions (add named nodes, delete xml subtrees and so on), but these may come in handy in the future.

 

Still to come:

- Tweak the dialog window (I want to arrange the colour buttons in two or three columns and of course add a description) and make it nicer overall

- Add the "Copy" and "Delete Colourscheme" functionality.

- Make the colours actually being used in the right places, so that the hardcoded colours disappear. I will do this after the whole functionality of the editor is done.

Link to comment
Share on other sites

Not looking too bad at all. Two columns might indeed be a good idea, since there is typically more horizontal screen space available than vertical.

 

I look forward to having some half-decent colours in my DarkRadiant, I can barely see the "entity lime green".

Link to comment
Share on other sites

I guess once people start customising their colour schemes, we will need to find a robust way of upgrading the default user.xml without having to delete the user's local copy. Users probably won't want to upgrade if they have to delete and recreate their colour scheme.

 

EDIT: Another thought - is the list of colour buttons/labels generated from the XML, or is it hardcoded? Would it be possible to add extra "categories" at a later stage?

Link to comment
Share on other sites

I guess once people start customising their colour schemes, we will need to find a robust way of upgrading the default user.xml without having to delete the user's local copy. Users probably won't want to upgrade if they have to delete and recreate their colour scheme.

Yes, I agree. Two things that came into my mind:

1. We add an export button the colour scheme editor, so that users can export their theme and import it after upgrading (this is not too much work).

2. We find a way to merge the two user.xml files, but there will be conflicts that have to be avoided. We somehow have to tell DR which nodes are new and have to be replaced/copied and which are not (like a patch file or something similar).

 

EDIT: Another thought - is the list of colour buttons/labels generated from the XML, or is it hardcoded? Would it be possible to add extra "categories" at a later stage?

Everything is generated from the XML file, even the descriptions. The addition of new colours is no problem at all, but one has to definitely touch the code if the newly defined colours are to be used in the right places as well.

Link to comment
Share on other sites

Ok, we definitely need a plan regarding the XML file conflicts. Right now I'm running into this problem: I can delete an existing colour scheme using the scheme editor and it gets correctly deleted from the registry. The correct structure is saved into the user's user.xml as well.

 

The problem is: as soon as I restart DarkRadiant, the ColourSchemeManager searches the XMLRegistry for colour schemes and now the schemes stored in the install/user.xml are found as well, and the formerly deleted scheme gets re-imported, which is annoying.

 

Possible solutions that I can think of:

 

- Don't import colour schemes from the install/user.xml, unless the user.xml file is empty. This would be some kind of "hardcoded" feature, and we might run into the same problem with other registry structures.

 

- Don't import anything from the install/user.xml if there is a copy in the user settings folder. The user.xml is copied into the user settings folder only once after installation and after that this is the only copy DarkRadiant is working with. Here, we have to address the problem of how to import settings that are added in later DR releases.

 

The advantage of the latter version would be that conflicts are impossible, perhaps we could import new registry values with some kind of upgrade.xml that gets deleted after importing the new values into both copies?

Link to comment
Share on other sites

Can it be done on a datestamp basis? I.e., read .darkradiant/user.xml unless install/user.xml is newer, in which case read install/user.xml and overwrite the .darkradiant/user.xml on exit.

 

It might be necessary to display a warning on startup if this is the case, to confirm with the user that it is OK to overwrite the local user.xml with the upgraded install copy.

 

Another option would be to change the design so that both user.xml version are merged, so all of the colour schemes in the local copy would be added to those in the install copy. In this case, DarkRadiant would have to write out the local user.xml containing just the modified/new nodes, rather than the entire structure (otherwise you would end up with two copies of everything).

Link to comment
Share on other sites

Personally I don't like relying on datestamps if at all possible - what if the user copies their profile and their DR install between computers, for example, but does so in the "wrong" order? Then the DR install has a later timestamp than the profile, and stuff gets overwritten. Okay, it's not really a big deal, but I'm convinced there's a cleaner solution. :)

 

I haven't been keeping up with the updates so I don't know how the XML registry works, but would it be possible to only put settings into .darkradiant/user.xml when they're changed, and then refer to install/user.xml for settings that don't exist in the .darkradiant/user.xml? i.e. when it comes time to save the XML file, first clear .darkradiant/user.xml. Then recursively compare the in-memory XML tree to install/user.xml. If the corresponding values are different, then write them into .darkradiant/user.xml; but if they're the same, then don't.

 

This way, new stuff from DR updates is always seamlessly made available, but user prefs are never overwritten, and there's no need to rely on the filesystem's datestamps.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

Personally I don't like relying on datestamps if at all possible - what if the user copies their profile and their DR install between computers, for example, but does so in the "wrong" order? Then the DR install has a later timestamp than the profile, and stuff gets overwritten. Okay, it's not really a big deal, but I'm convinced there's a cleaner solution. :)

 

I haven't been keeping up with the updates so I don't know how the XML registry works, but would it be possible to only put settings into .darkradiant/user.xml when they're changed, and then refer to install/user.xml for settings that don't exist in the .darkradiant/user.xml? i.e. when it comes time to save the XML file, first clear .darkradiant/user.xml. Then recursively compare the in-memory XML tree to install/user.xml. If the corresponding values are different, then write them into .darkradiant/user.xml; but if they're the same, then don't.

 

This way, new stuff from DR updates is always seamlessly made available, but user prefs are never overwritten, and there's no need to rely on the filesystem's datestamps.

I see what you mean, but this would still not solve the problem with deleted colour schemes being re-imported on startup. With changed registry values this solution would work out fine, but as soon as keys get deleted, the XMLRegistry has a hard time distinguishing between items that are deleted on purpose and therefore missing and items that should be newly imported because they were never there.

 

Additionally, IMO one of the strengths of using an XML tree is that I don't have to do tedious recursions when looking up or saving values. I would prefer a solution that does not require to walk the whole tree and touch every single XML node.

 

I agree with you that the time-stamp method would introduce more problems. If we want to use time-stamps, we'd have to store them directly into the registry files, which can also be problematic or at least unconvenient to implement. I also thought of adding a "dirty" attribute to changed registry values, but I'm not sure if this would be practical or not.

 

Another option would be to change the design so that both user.xml version are merged, so all of the colour schemes in the local copy would be added to those in the install copy. In this case, DarkRadiant would have to write out the local user.xml containing just the modified/new nodes, rather than the entire structure (otherwise you would end up with two copies of everything).

I think we should avoid altering the install/user.xml file, as all the default values are stored there. If we need to change this base file, we wouldn't need a local copy of the user.xml in the first place, would we?

 

(Sorry, if I sound repulsive in this post, I don't mean to :).)

 

I'm somehow inclined to the option where we leave the base install/user.xml untouched after the initial import. We would need to add some version stamp to the base XML file (e.g. 0.6.0), so that the local user.xml is recognized as being outdated and the user can be warned that his/her changes are going to be overridden. Little changes could also be imported via a upgrade.xml file that could be added to the local user.xml. Would this produce any problems?

Link to comment
Share on other sites

I'm somehow inclined to the option where we leave the base install/user.xml untouched after the initial import. We would need to add some version stamp to the base XML file (e.g. 0.6.0), so that the local user.xml is recognized as being outdated and the user can be warned that his/her changes are going to be overridden. Little changes could also be imported via a upgrade.xml file that could be added to the local user.xml. Would this produce any problems?

 

That's more or less what I meant - I wasn't suggesting that the install/user.xml should be overwritten (except when a new version of DR is installed). Having a version stamp in the file would be just as effective as using the file date but would avoid the problems Crispy mentioned with moving files around.

Link to comment
Share on other sites

The Colour Scheme Editor is now on SVN, along with some changes to the XMLRegistry class. The colours aren't used yet (still to come), but the colours can be edited and saved correctly.

 

Could Orbweaver or New Horizon test if I got everything right and DR compiles without glitches?

Link to comment
Share on other sites

Compiles and runs OK. However, you've got double free in there somewhere, DarkRadiant segfaults with an error if I press the Cancel or OK buttons in the Colour Scheme Editor dialog.

 

*** glibc detected *** free(): invalid pointer: 0xbfd2220c ***
Aborted

Link to comment
Share on other sites

Can't reproduce this on Windows, what do you mean by "double free"? Do I destroy a widget that's already destroyed (that would be catched by GTK+, wouldn't it?)? Can you see any schemes in the editor list?

Link to comment
Share on other sites

OK, the problem is that you have a function ColourSchemeEditor::destroy() which calls "delete this". You must never destroy something with delete unless it was first allocated with new, which in this case it wasn't, hence the double free.

 

It is best never to use "delete this" at all, it is dangerous and almost never needed. Your ColourSchemeEditor instance is automatically deleted at the end of EditColourScheme() since it is a local object.

 

I think in this case you would be better off not using a recursive gtk_main() loop. The recursive loop is used when a dialog must block until a specific value is selected by the user, after which the main function can resume (such as when a Model selection is required). The ColourSchemeEditor does not return a value, it just allows the user to modify values that are held in the XML registry, therefore it does not need to block the calling function.

 

I can explain in more detail if this is not clear.

Link to comment
Share on other sites

Thanks, I will try to fix this! (Strange, why doesn't it crash on Windows?)

 

Concerning the gtk_main() loop: I only implemented this, because I got some really weird crashes when I don't call the loop. For example, the signal "changed" got called only once and crashed DR immediately when it got called the second time. Perhaps I did something wrong (most probably I did :)), but the problem magically disappeared after using gtk_main(), so I thought this call was vital for GTK dialogs to function correctly.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...