In the image below, which style do you prefer. The top or bottom?

http://cache.getlazarus.org/images/menu-patterns.gif -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160110/b999b628/attachment.html>

The bottom one. It's more "calm". Doesn't look like a circus.? -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160111/6cb9e6df/attachment.html>

Dmitry Boyarintsev wrote

The bottom one. It's more "calm". Doesn't look like a circus.?

I prefer the old one (top) :) The arrows/squares are very neat and show what you are going to do.

If you think it looks like a circus, what about using a less agressive colour for the arrows?

Ondrej

Ondrej Pokorny wrote

I prefer the old one (top) :) The arrows/squares are very neat and show what you are going to do.

Arrows: new submenu item.
Squares: new sibling menu item.

Very neat, IMO. Not to be removed, please :)

Ondrej

In my opinion the top one is kind of terrible. Just look at this video:

http://cache.getlazarus.org/videos/menu-arrows.mp4

No matter where I click it always shows the same pattern: ugly blue check board below, ugly aliased triangles to the right.

I can tell the item is going to be inserted below, because there is a rectangle below.
I can tell the items are inserted to the right, because there is a rectangle to the right.

The pattern inside the rectangle make no difference. It's purely a distraction which will probably have people wondering why it's even being drawn differently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160111/01abe7e8/attachment.html>

Anthony Walter wrote

No matter where I click it always shows the same pattern: ugly blue check board below, ugly aliased triangles to the right.

Can you please define "ugly" in an objective way?

I can say the same about your approach: "/No matter where I click it always shows the same pattern: ugly slanted gray lines below and the same to the right./"

The pattern inside the rectangle make no difference. It's purely a distraction which will probably have people wondering why it's even being drawn differently.

IMO, it is very clear, again:
- Arrows: new submenu item.
- Squares: new sibling menu item.

You have the same pattern for both submenu and siblings. If you don't like the current patterns, propose 2 different patterns (or images) for submenu/sibling as well.

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160111/cb229286/attachment-0001.html>

The point is, on a TPopupMenu if the pattern to the right is always alias arrows, and the pattern below is always check board, then it's entirely superfluous, nonessential, redundant, and unneeded. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160111/8b1e7964/attachment.html>

Dmitry Boyarintsev wrote

The bottom one. It's more "calm". Doesn't look like a circus.?

+1

Regards,
- Graeme -

The top one.

I find there is room for beauty (ugly?) and personality in programming. I find straight forward utilitarian to be ugly. I like things to be interesting.

Any way to make the pattern settable? Win-Win!

Ondrej Pokorny wrote

IMO, it is very clear, again: - Arrows: new submenu item. - Squares: new sibling menu item.

As a programmer the bottom image is equally clear to me. I simply find the bottom one more pleasing to the eye - less distracting.

If the arrows and squares must stay, then please switch to anti-aliased drawing. Why is LCL still defaulting to aliased drawing [read as really ugly and so early 90's] in this day an age.

Regards,
- Graeme -

Anthony Walter wrote

The point is, on a TPopupMenu if the pattern to the right is always alias arrows, and the pattern below is always check board, then it's entirely superfluous, nonessential, redundant, and unneeded.

The latest trunk accepts a patch which adopts Bart's suggestion of identifying the purpose of the dummy menuitem by displaying a self-descriptive text. The background is no longer patterned. Of course this can be further changed.

Howard

Howard wrote

The latest trunk accepts a patch which adopts Bart's suggestion of identifying the purpose of the dummy menuitem by displaying a self-descriptive text. The background is no longer patterned. Of course this can be further changed.

Where is the patch?

Ondrej

Anthony Walter wrote

In the image below, which style do you prefer. The top or bottom?

The bottom one.
Please add a text to it so one knows what it does.

Keep up the good work !!!

Bart

Anthony Walter wrote

In the image below, which style do you prefer. The top or bottom?

Suggestion: can you put the buttons in a grid like container? With at least vertical lines between the different groups.

Bart

It is the second patch submitted on issue 29205

Howard

Bart wrote

> In the image below, which style do you prefer. The top or bottom? The bottom one.

Looks like I have been outvoted :) No problem.

Anthony Walter wrote

ugly aliased triangles

Graeme Geldenhuys wrote

If the arrows and squares must stay, then please switch to anti-aliased drawing.

Just a technical remark: if I see correctly, Anthony doesn't use anti-aliasing either :)

Still, no problem, do whatever you want with the pattern. There are more important things in Lazarus. The user experience won't be very different with whatever pattern.

Ondrej

Howard wrote

It is the second patch submitted on issue 29205

Oops, I failed to notice it. Should it be applied? I am happy if the issue is assigned to somebody else. Bart? Ondrej? I have some other issues to look at.

Juha

Juha Manninen wrote

Oops, I failed to notice it. Should it be applied?

I'll apply it manually. The patch won't apply because I fixed some issues recently.

Ondrej

Ondrej Pokorny wrote

I'll apply it manually. The patch won't apply because I fixed some issues recently.

Assigned the issue to you. Thanks. :)

Juha

Howard wrote

It is the second patch submitted on issue 29205

Applied. IMO the discussion about the pattern is now solved :)

Ondrej

Very nice. I like the new design.

Side note: Who wrote that FScroller for the new menu editor? It acts very erratic for me on Gtk2. I don't know about on other widget sets. See issue 29369. Why not use TScrollBox or make TShadowMenu a TScrollingWinControl?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160111/325928c6/attachment.html>

Anthony Walter wrote

Side note: Who wrote that FScroller for the new menu editor? It acts very erratic for me on Gtk2. I don't know about on other widget sets. See issue 29369.

You can easily check by yourself in the SVN history. I don't know.

Why not use TScrollBox or make TShadowMenu a TScrollingWinControl?

Yes, it behaves strangely on win32 as well. You are welcome to create a patch.

Ondrej

I wrote it. It is definitely the weakest part of the new designer. I hate to reinvent the wheel. However, I could not get a TScrollBox container to work correctly for TShadowMenu, perhaps because its size calculation and painting is rather non-standard. Whatever the reason I was unable to get a TScrollBox container to respond correctly to TShadowMenu size changes when there were more than a screenful of menuitems. I'm honestly not sure if the best approach to sorting it out is to mend (or rewrite) FScroller, or to figure out a way for TScrollBox to parent TShadowMenu correctly. I did not try making TShadowMenu a TScrollingWinControl descendant. Perhaps that would be a better option. What would others advise?

Howard

On my system suddenly all is well with the new menu editor. Nice work :)

The docked form designer still has the issue where it's not being realigned/repainted when a TMainMenu is placed on it. Issue 29370. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160111/cebe854a/attachment.html>

Howard, good job on the new menu designer. It's working very nicely right now. I'll take a look at modifying TShadowMenu to be a scrolling control without the need for a TScrollBox.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160111/f44b0270/attachment-0001.html>

Anthony Walter wrote

Howard, good job on the new menu designer. It's working very nicely right now. I'll take a look at modifying TShadowMenu to be a scrolling control without the need for a TScrollBox.

Thanks. Yes, Ondrej's introduction of TSiblingFake and TFirstFake are a neat improvement.

Howard

Howard wrote

Yes, Ondrej's introduction of TSiblingFake and TFirstFake are a neat improvement.

Thanks! You did a nice job with the menu designer!

I would ask you to omit the with statement, though. IIRC there are even nested with statements in the code.

Withs can easily be sources of unnecessary bugs and errors.

Ondrej

Hello i testet SVN Revision 51256 of the Menu designer and it looks really cool.

But i miss the Feature

"If you doubleclick on the Menu Entry the IDE Jumps to the corresponding OnCLick Event"

Which worked in the old version e.g. 50469

Could you please reactivate this ?

Corpsman

Hello Lazarus List,

I Updated to the last Lazarus Version 51265 to test and see the new menu Editor, and it looks great.

But i miss the "Clone to new Window" option. Normaly when i click the right mouse over the Sourcecode tabs, there had been a popupmenu that offers this and some other options, the menu is gone now ;(. is there a way to get it back ?

If i get back to SVN Revision 50469 the feature is aviable ;), as you can see in the atteched picture.

Corpsman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Clone_to_new_window_option.png
Type: image/png
Size: 24096 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160113/a0ed4ab4/attachment-0001.png>

You did not mention your widgetset but I guess it is GTK2. All other widgetsets seem to work but GTK2 indeed has a problem. Can you please bisect the code and find the exact revision that broke it.

Regards,
Juha

See
http://bugs.freepascal.org/view.php?id=29195
It happened with GTK2. The popup menu has disappeared after it.

If you find the guilty revision, please add comment in that report or open a new report.

Juha

It is caused by r51169
"ide: sourcenotebook better PopupMenu handling. Fixes also issue 29295" by reopened the relevant issue
http://bugs.freepascal.org/view.php?id=29295

Juha

What were your problems? In r51298 I removed all the Scroller code and simply used TScrollBox for TShadowMenu and it works without any problems
- much better than your Scroller experiment. I tested win32 and Linux+Gtk2.

Ondrej

Ondrej Pokorny wrote

What were your problems? In r51298 I removed all the Scroller code and simply used TScrollBox for TShadowMenu and it works without any problems - much better than your Scroller experiment. I tested win32 and Linux+Gtk2.

Forgot to say, please test :)

Ondrej

Sorry, my apologies - I missed that you didn't try it.

Ondrej

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.

Howard

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.

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.

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160116/a0b161a1/attachment.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: fiacfche.png
Type: image/png
Size: 3020 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160116/a0b161a1/attachment.png> -------------- next part --------------
A non-text attachment was scrubbed...
Name: gchfchdc.png
Type: image/png
Size: 1869 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160116/a0b161a1/attachment-0001.png>

I'll have a look later next week.

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.

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.freepascal.org/pipermail/lazarus/attachments/20160116/c4f3d14e/attachment.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.freepascal.org/pipermail/lazarus/attachments/20160116/c4f3d14e/attachment.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.freepascal.org/pipermail/lazarus/attachments/20160116/c4f3d14e/attachment-0001.png>

IMO we shouldn't think people don't know what they are doing. If I hit DELETE on a menu item, I usually want to delete it :)

I agree! +1.

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160117/4e629f3c/attachment.html>

Talking about BigChimp, there is an open bug report from him: http://bugs.freepascal.org/view.php?id=25457
I think it can be resolved already. He may have confused Name and Caption. The visible property is Caption and the WYSIWYG editor must modify it, which it now does. Other properties should be left for Object Inspector. The KISS principle applies here, too.

Anyway we have a good situation now as many people work on the menu designer. At least its structure allows it to be modified. The old menu designer was weird. Many people tried to improve it but finally gave up and noted that it should be rewritten. Usually I can refactor code to make it more modular and easier to maintain but with that code I didn't know how. So yes, this had to be done. I believe after some initial pain we get a good menu designer.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160117/b01142fa/attachment-0001.html>

On 16/01/16 23:11, Howard wrote:
[...]

Then maybe make the 'No' answer default here?

Long sentences are not always a good enough incentive to stop people from accidentally pressing ENTER ...

But if someone actively pressed TAB to change to yes, then enter, or used their mouse to click Yes, you can safely assume, that yes they meant it ;)

Howard

el es

Lukasz Sokol wrote

Then maybe make the 'No' answer default here?

No. If I hit delete, I want to delete the button. The prompt is OK there but the default action should always be what you want to do -> "yes". Don't assume that people are dumb :)

Btw. Howard had the "No" button default but I changed it.

Ondrej

Actually the default button depends on the OS/widgetset. For example on OS X the default for a destructive action should be "No". On Windows the default is typically Yes/Ok.
Same for button order.

Don't assume that people are dumb :)

People are creatures of habit.

Mattias

I am not...

However seeing that I am perfectly able to slip a finger off my Enter key on MY keyboard and/or hit 'del' key and then Enter in one move,puts some perspective here ;) (https://www.google.com/search?q=dell+rt7D50+keyboard) (that actually happened to me, I do not always look at my keyboard while typing fast ;) )

Also, no, people are not dumb, their ability to invent new ways to cut corners is a fast moving target ;) (especially if they think software is slowing them down)

Btw. Howard had the "No" button default but I changed it.

I'm with Howard here (and Matthias). It should be a default No if a change can not be reversed by just Ctrl-Z or Undo.

Ondrej

Lukasz Sokol wrote

I'm with Howard here (and Matthias). It should be a default No if a change can not be reversed by just Ctrl-Z or Undo.

Obey widgetset behaviour.

if a change can not be reversed by just Ctrl-Z or Undo.

Implement Undo for the menu-desgner will be on the wish list then.

Bart

Lukasz Sokol wrote

> Btw. Howard had the "No" button default but I changed it. > I'm with Howard here (and Matthias

As far as I understood Mattias' email, he did not say the dialog should default to "Yes".

Btw. I checked when deleting files in the default file manager (with DEL and also with SHIFT+DEL for permanent delete) and the results are the following:

Windows 10: default is "Yes" for both actions.
Kubuntu: DEL - no prompt by default, you can enamble the prompt, then it defaults to "Yes".
SHIFT+DEL - default is "Yes".

Bart wrote

Implement Undo for the menu-desgner will be on the wish list then.

+1. Changing properties in OI and deleting components already are supported by the Undo function. The menu editor should support it as well.

Ondrej

Heh you're right, he did not.

[...]

So all OS I tested are pretty consistent, the default action is always the destructive one.

OK.

In development, maybe you're right. All is fair in software development ;)

I just happen to have a system here, where I have to log users actions. But no amount of 'breadcrumbs' (action logging) is going to stop people from complaining about default actions taken by just pressing 'yes' or enter all the time... that they perceive as 'wrong answer'.

Their supervisors tend to tell us then, 'you should have stopped them from blindly selecting the wrong answer by default'...

We (still) get complaints that it's slowing them down, but then, it's now 'by design'.

At some point we resorted to disabling the default button mappings to keyboard, so they HAVE to click buttons by mouse.

And they aren't 'dumb' people, oh no.

el es