2017-11-02 18:48 GMT+01:00 tim Rowledge <tim@rowledge.org>:

> On 02-11-2017, at 10:38 AM, Bernhard Pieber <bernhard@pieber.com> wrote:
> Hi Eliot, Hi Marcel,
> IMO refactoring support is one of those features that belong to trunk. I am not suggesting that any one of you should do the work. I just want to find out what you and others think about this? Would any one object and if yes, why?

I have a small objection, not specifically to the refactoring stuff but to the effect adding more facilities will have on the more general problem of giant menus and overfilled tables of hotkeys.

Generally our menus are horribly poorly arranged. Some are hierarchical menus, some fake it badly with the “fooble…” entries that open another menu, or sometimes a different UI widget. The code side of menus is even worse with approximately 42 classes involved in making a once-simple menu concept.

So whilst I’d like to see refactoring support included by default in the tools, let’s try to make use of that to refactor our really messy, untidy, badly in need of refactoring, UI framework(s)

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
If you don't pay the exorcist do you get repossessed?

IOW, what we need is a tool for understanding those legacy messy untidy codes which is a preamble to applying any refactoring...
Something like a brain, but better than the poor one we have.
Precisely because we started to complexify that code once we lost the overall picture of the problem/solution...
And we stopped modifying once it was humanely impossible to add a feature without breaking two others.
Such code is a sort of local optimum...