Organizing Work on the Krypton Toolkit

[giduac]

Hi @Wagnerp & @Smurf-IV,

I’d like to kick-off this discussion to see if we can come to a more structured way of working and regaining control of the Toolkit.

At the moment, June 2024, we have:

• Close to 200 open tickets.
• 70 bugs, some that are open for several months or even longer.
• The fact that while working on the current code, regularly more bugs or incomplete work is found which adds to the workload.

Things I see:

• The Toolkit is currently not in a state that more new functionality can be added, as this will only increase the possibility of complicating the state further and remaining out of control.
• The number of bugs need reducing to at most 10. If such a limit is exceeded reducing the bugs will receive full attention.
• Look more at feature completeness. For example RTL compatibility is an area that partly functions.
• Investigate current features and see if they are complete.
• Fine tuning of themes takes up much time over and over again.
• We need to organize things better to regain and keep control of the state.

This, of course, is only a starting point and the current state speaks for itself.
I find it unworkable in that it mostly revolves around putting out fires and could do with more structure. More discussion between the members to plan, schedule, execute and review work will likely be beneficial.

What do you all think, is this something we can discuss and take further ???

[Smurf-IV]

@giduac I think you "Nailed it".
So, what propositions could be discussed as part of this ?

[giduac]

@giduac I think you "Nailed it". So, what propositions could be discussed as part of this ?
@Smurf-IV & @Wagnerp

The ones listed already and of course things from both your side.....
Don't hold back with ideas and comments...

[tobitege]

Hello,
just from my past experience with themes, and seeing your workload, I thought to provide an idea.
In Visual Studio there's some "Color Themes" extention (by MS, iirc) that even allows editing themes in detail.
That looks like this:

IF you had a similar way to display everything for a theme and maybe even a 2nd column to compare it to another theme, it might help in fine-tuning issues and locate sources for visual bugs.

One issue about themes I see, is in that colors can be "optional" and then something gets mixed with an value that is coming from somewhere else, even at runtime programmatically and on and on... pretty impossible to debug. 😔

This to me needs a paradigm shift to get a grip on this, imho:
any theme should define all colors, for everything, determinalistically, no loop holes. And IF values have to be inherited, then assure that that way is clearly tracable and doesn't depend on secondary or tertiary color properties.

I know, MS themes work differently compared to others, but in the end they all are supposed to cover all the same components.

This could mean a big rewrite of parts of it or it's main engine all together, but the current structure doesn't seem maintainable and causes repeat efforts and frustration.

I hope you guys can find a feasible way to make your development lifes easier in this alltogether! 🤗

End of rant, thanks again for all your work!!! ❤️

[PWagner1]

Hi @tobitege

Is it possible to share the theme extension link for future use? Of course, new themes won't be developed until v100.

[tobitege]

Hello,
this should be it: https://marketplace.visualstudio.com/items?itemName=VisualStudioPlatformTeam.VisualStudio2019ColorThemeEditor

There's a 2022 version too.

It is only a VS theming tool, not for anything else. I just used it as an example. 😀

[PWagner1]

Hi @Smurf-IV & @giduac

I think the existing themes need some TLC (especially colours). There are some bugs such as #1573 which needs looking at. I also don't know what your thoughts are on the RTL bugs.

[Smurf-IV]

My $0.02

• This is supposed to be a Winform(s) Themes suite first
  • Controls from "old" Winform Framework, that this makes work to be the "same" in a core app
  • There are still some missing (like the error info)
• Then add some helpful options to allow those controls to be easier to use
• Then add "Better" controls when they become mature enough (See Extended kit)

As for the RTL, That has been broken since before it became FOSS, so I think that can remain (At the moment) low priority; i.e. v100

[PWagner1]

If we can make an inventory of missing controls first, then go from there... The WinForms repo can help out

[giduac]

My $0.02

• This is supposed to be a Winform(s) Themes suite first

  • Controls from "old" Winform Framework, that this makes work to be the "same" in a core app
  • There are still some missing (like the error info)

• Then add some helpful options to allow those controls to be easier to use

• Then add "Better" controls when they become mature enough (See Extended kit)

As for the RTL, That has been broken since before it became FOSS, so I think that can remain (At the moment) low priority; i.e. v100

@Smurf-IV & @Wagnerp

First

If others are following don't hesitate to join or comment...all input is welcome.

Imo, what needs discussing first:

• how to go about solving the current state.
• structuring and organizing the work
• the work itself can be addressed later on

It is very important imo that we are all on the same page about this going forward

This might take a bit of time to get it all worked out

Everybody please give your views on this matter

[PWagner1]

Hi @giduac & @Smurf-IV

The O2k7 & O2k10 (extra themes) need working on. I've fixed the black dark mode themes, please can you test these themes in tomorrows nightly (01/07/2024)?

The issue I'm facing is that I can't seem to alter the ribbon back colour in the O2k7 & O2k10 (extra themes)?

[giduac]

Hi @giduac & @Smurf-IV

The O2k7 & O2k10 (extra themes) need working on. I've fixed the black dark mode themes, please can you test these themes in tomorrows nightly (01/07/2024)?

The issue I'm facing is that I can't seem to alter the ribbon back colour in the O2k7 & O2k10 (extra themes)?

See if I have a bit of time later this week.

Coming weeks in general there won't be much happening.
But there will be time to discuss this further.

[giduac]

Hi @Smurf-IV, @Wagnerp & @NicodemusU,
cc: @tobitege (if you have ideas/comments please let them be heard)

Imo we don't have to go into Change Management equivalent processes but can rather do with a small set of agreements to regain control and keep it there.

To move the discussion further, how about if we address the first point:

Bringing the current state of the Toolkit under control

Which consist of:

• Bringing the number of bugs back to less than 10.
• Put a stop on the introduction of new code.
• Define a clear overview/list of what needs to be in V90 at a minimum.
• Define what can go into V100
• What to do if we discover (new ) bugs in alpha which are part of new code for V90 (code that does not originate from V80).

Your input please as all is up for debate...
Thanks.

[PWagner1]

Hi @Smurf-IV, @giduac & @tobitege

Done a quick count on theme bugs, there are 23 open tickets. I think this is where the focus should be.

https://github.com/Krypton-Suite/Standard-Toolkit/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%3Athemes+label%3Abug

[giduac]

Hi @Smurf-IV, @giduac & @tobitege

Done a quick count on theme bugs, there are 23 open tickets. I think this is where the focus should be.

https://github.com/Krypton-Suite/Standard-Toolkit/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%3Athemes+label%3Abug

@Wagnerp
First go through the list from old to new and see which of those tickets still need solving.
Also only two of them are tagged with the V90 label...

[giduac]

@Smurf-IV & @Wagnerp

Can both of you please go trough the list of tickets you've created and see:

• which can be closed
• assign those open to either V90 or V100

Smurf: https://github.com/Krypton-Suite/Standard-Toolkit/issues/created_by/Smurf-IV
Wagnerp: https://github.com/Krypton-Suite/Standard-Toolkit/issues/created_by/Wagnerp

Thanks.