[Lazarus] New menu designer. which style do you prefer?

[Howard]

On 16/01/2016 21:08, Ondrej Pokorny wrote:
> On 15.01.2016 23:30, Howard wrote:
>>> Sorry, my apologies - I missed that you didn't try it.
>>>
>> Yes working fine for me (Windows 7 32bit and Linux 64 bit).
>> I'm relieved that such a simple change has had such a good effect, 
>> and that no further tinkering with TShadowMenu size and positioning 
>> code was required; and that my poorly implemented scrolling code can 
>> therefore be dumped entirely.
>
> Yes, you must have wasted a lot of time on the extra scrolling code :(
> + Could you take a look also at this one?: 
> http://mantis.freepascal.org/view.php?id=29399
> Basically you should use a simple parented TEdit and not a modal 
> dialog. Take a look at grids in-place editor.

I'll have a look later next week.
>
> To me it seems that you have taken hard and complicated routes at a 
> lot of places in the new menu editor, which are very bug-prone, hard 
> to maintain and hard to understand - instead of using easy and simple 
> ways. As a result, you wasted your time and also mine and others that 
> tried to understand what's going wrong in the unnecessary code and 
> tried to fix it.
>
> This is also the case of resource strings. Take a look e.g. at r51249 
> and r51305. Why was the dialog so complicated with duplicate strings? 
> Yes and No as answers are clear enough.
> It stated:
> "Deleting this item will delete all subitems too.
> Delete this item and its subitems?"
> You use the word delete three times, (sub)items 2+2 times. Why? (And I 
> don't count the dialog title and former buttons.)
> Why not only the second line?: "Delete this item and its subitems?" -> 
> again it is clear enough. Furthermore, using the same words and 
> phrases over and over again is stylistically wrong.
In this particular instance of deleting a submenu (not just a single 
item) my motivation was not to make it overly complicated (though I 
appreciate it may seem so).
It is quite possible a user may have spent 10 minutes designing a 
submenu with half a dozen items, and then hits the delete key 
accidentally. With a simple Yes/No dialog (especially if the the default 
button is Yes) it is all to easy to hit the wrong button and lose the 
last few minutes' work; and there is no undo facility implemented.
I may have written that dialog clumsily, but I wanted to avoid the 
possibility of an 'automatic' response which was disastrous. I quite 
agree a straightforward Yes/No dialog is simpler and more elegant, but 
it may not give a hurried user sufficient 'pause' to avoid accidentally 
losing valuable work.
>
> Honestly, the new menu editor is a translator's nightmare. Although I 
> do like what the new designer does, I don't really like how it is 
> written :( I tried to fix some code but I am somehow already tired to 
> go through all the issues.
>
> Please don't get me wrong - I don't want to offend you in any way. I 
> just want to explain that you should use the KISS-principle whereever 
> possible. It will not only save everybody's time but also lead to 
> better code. (I know, I also have hard time to apply KISS.)
>
> Ondrej
>
> PS: Just for comparison:
> BEFORE:
>
>
> AFTER:
>
>
> Even as a user, I need much more time to understand what's going on in 
> the first dialog...
No offence taken. I appreciate you taking the time to give constructive 
feedback, as well as tracing through code you find poorly written in 
order to improve it.

You'll realise I'm on a learning curve. This is my first significant 
code contribution to an open source project. I actually never thought I 
had the skill to offer a new menueditor. It was a forum comment by the 
late BigChimp some years ago about the previous menueditor which first 
got me thinking about its shortcomings, why it was so difficult to 
improve/maintain, and how a replacement might be designed to be better 
in that respect; and several developers said a complete rewrite was the 
only way forward. Months became years and no one as far as I could see 
was working on a replacement. So I decided to bite the bullet, and 
started to look at relevant bits of the IDE code (much of which I still 
don't understand). I've been learning on the job, as you plainly see...

Howard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160116/c4f3d14e/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3020 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160116/c4f3d14e/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1869 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160116/c4f3d14e/attachment-0007.png>