Re: mention of updating the colors interface in https://forums.mirc.com/ubbthreads.php/topics/261963/Re:_[beta]_/color_@name_@index#Post261963
Updating the Alt-K dialog to refer to color index 16-98, some changes not all necessarily related to the new colors, but would probably be easier to make along with them rather than at a different time:
1. I'm guessing the arrangement of the color shades means Alt-K dialog's support for index 16-98 would involve adding 7 additional rows of 12 squares across and leave the current 16 indexes in 2 rows of 8.
It would be nice if each index square, including the original 16, could be large enough to include the index number itself in a contrasting black-or-white color. Makes it easier to identify index numbers for use with the /echo N or /draw* or /cline commands. If people didn't like the numbers, they could just toggle them off.
Since colors 0-98 is too many colors for a dropdown, this updated dialog grid could then replace the dropdown list in places like nick colors. For dialogs like 'highlight' which have a 17th 'no color' choice, they could have the 'no color' choice either be above index 0-7 in a row by itself, or in the position where index 99 would otherwise be.
2. Either the Alt-K heading "Appearance:" or the Titlebar could change to indicate which text area is selected. i.e. something like "Appearance: Quit Text" or "Using Index 14, Selected Item: Background".
When you enter the Alt-K dialog, the 'focus' border remembers the index color used when the dialog was previously open. The dialog also remembers the previous event, but isn't showing a focus border until after clicking on an event. It should either initialize focus border to the event or take no action until one is selected.
If the "Appearance:" also mentions the same 'name' used in $color(name), makes it easier to know what $color(name) to use, such as for the 3 background colors that don't have descriptions.
Without a header label, there's only a faint gray 'focus' border around a selected event, and it's harder to notice the border when the background areas are selected. Click 'Reset' moves the focus border away from the event, which doesn't happen when clicking on an index square.
3. It would be nice if the index color squares had a tooltip. It could inform people they can right-click on that index color squares to reach the Custom Colors template, or show the RGB colors currently used by that index. To see the RGB setting for 03 Green, I now need to right-click on the 4th index icon 03 green square, then click again to open the extended portion where the RGB values are shown, then 'cancel' back to the original dialog.
Or, it could save the extra click and have right-click open the full custom colors area too, avoiding the need for the 'define custom colors' button.
4. In the Basic Colors dialog that expands to editing the RGB Custom Palette, perhaps the titlebar could also show which color index numbers is being changed by clicking OK. i.e:
Editing: Color Index# 14 from 127,127,127
Possibly also a 'prev/next index' button letting you change the active Color Index without closing the 2nd dialog.
5. Also in Define Custom Colors, it would nice to have the Custom squares labeled as 'A' through 'P', and the Basic Colors could be labeled something like A1 through F8, distinguishing them from being actual color indexes.
This allows changing the button 'Add to Custom Colors' to be 'Add as Custom Color A'.
6. Also, add the ability to right-click on a custom color square to select it without changing the RGB colors as when you left-clicked there.
Currently, there's no 'focus' indicator when you open the Define Custom Colors side-window showing where 'Add to Custom Colors' puts the current RGB numbers, and it always goes back to the 1st square each time you open that dialog. Even if you do click on a custom square to change the destination for 'Add', the focus border doesn't move to point at the next active square after you clicked 'Add'.
Without this right-click, there's no way to skip past a defined custom color box you want to keep without clicking on the new square and resetting your RGB colors to the black colors already there.
It's also more intuitive for the active Custom Color to move right instead of down, but having the focus Move or have the button say which Label gets changed should make that a non-issue.
7. Documentation not clear:
"... or you can click the reset button which will reset the colors back to the default mIRC colors."
This is easy to read as if the "Reset" button restores defaults back to either the original default definitions for that scheme or to the colors as when mirc.exe was last started, instead of just a reset to the state when Alt-K was currently opened. Or, the Reset button could be disabled until there are changes that can be reversed.
8. To defend against someone accidentally clicking on 'Delete' and not realizing they can save their scheme by clicking "Cancel", perhaps adding a confirm-delete prompt when someone clicks on 'Delete'. Either that, or have clicking 'Reset' also reset the Scheme list back to the previous state.
9. Something to make it easier to import and export color schemes. Next to the Save button could be an 'export' button to export the active scheme's [colors] and [palettes] settings to a file that could be sent to someone else, who could click an 'import' button to import it to their own mIRC.
To avoid problems with Scheme names containing invalid filename characters, exports could be added to a standard filename like Schemes.ini, letting an importer pick which Scheme they wish to add if the import file contains more than 1 scheme.