Diamond: How committed to Settings as a structure

[seasoned_geek]

Hello,

As part of my tire kicking of CopperSpice I wanted to try adding some enhancements/functionality to Diamond. Some of you might have read all or part of the post series.

https://www.logikalsolutions.com/wordpress/uncategorized/copperspice-and-diamond/

One of the first things I wanted to do was give it themes. Everybody seems to want to change colors to match mood or whatever. Now that I'm older, sometimes I need to do it just because of my eyes. I finally got around to looking at the code today.

Just how much religious conviction is there behind keeping Settings a structure and passing it around like a satchel?

Part of the following rambling is my mental process. I haven't actually tried any of this yet nor do I have any religious conviction about it.

My knee-jerk design impulse was to use a QMap<QString, ThemAttributes> but that means gutting the existing Settings logic to use a class (by reference hopefully).

I could keep it mostly the same by moving the QMap outside of Settings and just keeping the values for the CurrentTheme in Settings. The dialog would have to request a reference/pointer to the QMap so it could list all settings, change/copy/delete.

Would like to know your thoughts before I start writing lots of stuff that won't be accepted.

Is there a link to the coding standards for Diamond?

[barbara]

One of the first things I wanted to do was give it themes. Everybody seems to want to change colors to match mood or whatever. Now that I'm older, sometimes I need to do it just because of my eyes.

Diamond does have settings for changing the basic colors and syntax highlighting. Do you think themes would add much? Or do we just need more color options?

Just how much religious conviction is there behind keeping Settings a structure and passing it around like a satchel?

There are multiple settings I need access to so it made sense to have them all in one structure. Is the desire to change this do to your preferences, speed improvement, or improved readability?

My knee-jerk design impulse was to use a QMap<QString, ThemAttributes> but that means gutting the existing Settings logic to use a class (by reference hopefully).

This is a good conversation. Since not every setting is related to the colors, maybe you are only talking about changing those that are about the colors and syntax highlighting.

Would like to know your thoughts before I start writing lots of stuff that won't be accepted.

Diamond was originally a Qt project and then I moved it to CopperSpice. Sort of a fun project that turned into my primary editor. So this is wild to have someone want to contribute. Seems that you might be starting to look at what could be enhanced, so let's keep the dialog open and figure out what the program needs the most. I am interested in your ideas and changing the program to make it better is a good idea.

Is there a link to the coding standards for Diamond?

We created an internal style guide the team is using for all our libraries and projects. From the bottom of the following page is our "Style Guide". As per the notation, this is a living document.

https://www.copperspice.com/code.html

Barbara

[seasoned_geek]

One of the first things I wanted to do was give it themes. Everybody seems to want to change colors to match mood or whatever. Now that I'm older, sometimes I need to do it just because of my eyes.

Diamond does have settings for changing the basic colors and syntax highlighting. Do you think themes would add much? Or do we just need more color options?

Not more colors, actual color themes with a series of them provided by default. During my yoot I never understood why people used or needed themes. I used the default QtCreator look and feel for a very long time. The I became diabetic and learned that what strains your eyes changes with the sugar level in your body. Now there are days when I flip between a light theme and a dark theme multiple times. There are also strings of days where I leave it set in one place.

Just how much religious conviction is there behind keeping Settings a structure and passing it around like a satchel?

There are multiple settings I need access to so it made sense to have them all in one structure. Is the desire to change this do to your preferences, speed improvement, or improved readability?

I haven't read through all of the code, was just looking at the settings and the read/write logic a bit. My medical device background had a bit of a coughing fit at passing a big structure around instead of a pointer or reference to a class. I wanted the class to contain the read/write logic as well.

My knee-jerk design impulse was to use a QMap<QString, ThemAttributes> but that means gutting the existing Settings logic to use a class (by reference hopefully).

This is a good conversation. Since not every setting is related to the colors, maybe you are only talking about changing those that are about the colors and syntax highlighting.

Would like to know your thoughts before I start writing lots of stuff that won't be accepted.

Diamond was originally a Qt project and then I moved it to CopperSpice. Sort of a fun project that turned into my primary editor. So this is wild to have someone want to contribute. Seems that you might be starting to look at what could be enhanced, so let's keep the dialog open and figure out what the program needs the most. I am interested in your ideas and changing the program to make it better is a good idea.

Trouble is I started writing yesterday between helping spraying soybeans.

I will be adding themes that group color+weight+italic forcing in a defaults that cannot be deleted, only copied to change.

I'm also adding in a QMap of Keymaps. Haven't gotten very far with that yet. Focusing more on the themes to start. Keymap was a late afternoon idea to make it easier to implement EDT Keypad navigation.

Is there a link to the coding standards for Diamond?

http://www.logikalsolutions.com/wordpress/wp-content/uploads/2020/06/cover-3.png

)(*&^)(*&)(&*()*&ing in-line image handling

We created an internal style guide the team is using for all our libraries and projects. From the bottom of the following page is our "Style Guide". As per the notation, this is a living document.

https://www.copperspice.com/code.html

Barbara
[/quote]