Hello

I committed a new Menu Designer by Howard Page-Clark in r50992. See:
http://bugs.freepascal.org/view.php?id=29205

Please test.
It has some interesting design decisions. I initially see some things that may need fixing:

1. The main menu top level items do not show any indication when selected. They need some indication although it can be different from the other menu items.

2. A popup menu for a menu item has "Create OnClick handler" and "Edit Caption" entries side by side with the Add... and Move... items. They don't make a good match. Those entries duplicate the OI functionality and could be removed, or maybe moved to another section in the popup menu.

3. "Checkmark and radioitem properties" dialog should be removed. It is a modal dialog and always goes behind the menu designer. The menu designer itself tries to stay on top.
The checkboxes can be moved to a popup menu section as checkable menu items. They also duplicate OI functionality and are not really necessary. The GroupIndex feature does not work. It can be moved to the menu designer main window (and fixed).

I tested on Linux with GTK2 and QT.
Trunk is open for new features and improvements after 1.6 was branched. Opinions of this menu designer please.

Regards,
Juha

Juha Manninen wrote

3. "Checkmark and radioitem properties" dialog should be removed. It is a modal dialog and always goes behind the menu designer. The menu designer itself tries to stay on top.

Why does the menu designer have "FormStyle = fsStayOnTop"? I don't think any non-modal IDE window should be stay-on-top.

Nevertheless, before anything else is changed, did r50993 help?

But still I think the fsStayOnTop should be removed.

Ondrej

Ondrej,

The old menu designer was stay on top as well. Stay on top is needed because the a menu designer is typically a separate non docking window (a dialog). For all users menu editing invariably consists of:

1. Creating a menu (or sub menu) item using the menu editor dialog
2. Then editing the menu item properties using the object inspector (setting the name/caption, possibly creating a click event stub)
3. Go back to step 1

These steps are repeated many times as a user creates many items while in the initial stages of developing an application. If the menu designer did not stay on top it would be a major annoyance to constantly go to some type of menu list to bring the menu designer back to the foreground. Not everyone has multiple screens, and more often than not the entire menu editor dialog would be obscured by the code window when adding events, or with docked IDE user when switches to the object inspector (which would likely be docked tot he side of the code editor) in step 2.

As such, in the case of editor menus, it makes total sense to keep the menu editor on top of other IDE windows until the time when the user closes the menu editor (clicks the X button in the menu editor title bar). Any non stay on top form style for menu editing would driver users crazy. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151222/0438f81b/attachment.html>

Anthony Walter wrote

As such, in the case of editor menus, it makes total sense to keep the menu editor on top of other IDE windows until the time when the user closes the menu editor (clicks the X button in the menu editor title bar). Any non stay on top form style for menu editing would driver users crazy.

Correct, and this becomes more important when AnchorDocking is used. Some other windows, namely Actionlisteditor and Collectionitem have the same issue.
Forum user Soner A. had a valid point here:
http://forum.lazarus.freepascal.org/index.php/topic,30663.msg195989.html#msg195989

I was already planning to check the behavior of those windows and ask for opinions.

Ondrej, r50993 makes no difference.
Anyway, I am planning to remove the whole "Checkmark and radioitem properties" dialog. Any (strong) objection?

Juha

Here is how it looks here: http://imgur.com/CN5dwQR (i use GTK+ 2 with a classic windows theme).

It seems to crash very often and i cannot see any border in the popup menus. Also i'm not sure if the right blue arrows are supposed to be there (i get it is a "placeholder" for making submenu, but it looks odd).

TBH, IMO the whole left sidebar looks like a waste of space. The "stats" are useless, at least to me as a user (maybe they are useful to someone working on LCL internals) and the buttons can be done via the right click menu. And TBH all of the commands look like they should be done via drag-drop.

Since the menu editor is redesigned, why not do it like in Windows Forms and NetBeans with the "inline editor" which is part of the form editor? These editors are IMO way more user friendly than what the classic Delphi (not sure what Delphi does today) and current Lazarus menu editor.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/5677347d/attachment.html>

Anthony Walter wrote

Ondrej, The old menu designer was stay on top as well.

Why would I need to see the menu designer when I change application to anything other than lazarus? The old behavior is why I still design my menus in delphi.

Stay on top is needed because the a menu designer is typically a separate non docking window (a dialog). For all users menu editing invariably consists of:

If you want to make sure it stays on top of the form designer use the PopupParent and PopupMode properties stop f...ing with my system, stayontop is a system wide setting not an application one, stop that.

Thanks for explanation.

What I don't like on fsStayOnTop is the fact that fsStayOnTop-Window wants to stay on top of all windows - also those from other applications. This is IMO a seriously bad UI design. I know that Delphi behaves the same but then we need some FormStyle that makes the window stay only on top of its application windows and not system-wide.

E.g. I am writing now this email. I open Menu designer in Lazarus and then switch back to my email program - the email program is covered by the menu designer from Lazarus, which is absolutely not OK in my eyes.

Ondrej, r50993 makes no difference.

Bad :( The PopupMode should solve the problem. On Win32 it works well with PopupMode=pmAuto. On my testing Linux/Gtk2 system it works the same with pmNode and pmAuto - it correctly shows the "Checkmark and radioitem properties" dialog above Menu designer.
What OS/WS are you seeing the problem?

IMO this is a general LCL-issue. It means that you cannot show a modal dialog from window with fsStayOnTop, which is bad.

Anyway, I am planning to remove the whole "Checkmark and radioitem properties" dialog. Any (strong) objection?

No objections from my side. The properties can be set in OI.

Ondrej

stayontop is bad design for anything period. there was one single use case a couple of years back on installation applications that made sense which is no longer valid.

I know that Delphi behaves the same but then we need some FormStyle that makes the window stay only on top of its application windows and not system-wide.

No it does not, delphi's 2007 menu designer never stays on top outside the application it self and never looses its position regardless of how many times you change between delphi and other applications.

No, pmauto will autoselect the applications main form as popupparent you need to set the formdesigner as the popupparrent for all the component designers (menu, stringgrid, collections etc). This way double clicking an event will hide the designers which will be back on top when you focus the form designer.

Yes and no depends heavily which is the main form and how it changes between versions.

I was talking about FormStyle=fsStayOnTop and not about delphi's 2007 menu designer. fsStayOnTop in Delphi behaves the same as in Lazarus - it tries to keep the form above all forms system-wide.

No, you are wrong. pmAuto selects the active form as PopupParent not application's main form. See

   TPopupMode = (
     pmNone,     // default behavior - popup to mainform/taskbar window
     pmAuto, *// popup to active form and same as pmNone if no active form*
     pmExplicit  // popup to PopupParent and same as pmNone if not exists
   );

or the widgetset code, e.g. for Qt:

procedure TQtMainWindow.UpdateParent;
var
   NewParent: QWidgetH;
begin
   NewParent := nil;
   case FPopupMode of
     pmNone: ;// no popup parent
     pmAuto:
       // active form is parent
       if Screen.ActiveForm  nil then
         NewParent := TQtWidget(Screen.ActiveForm.Handle).Widget;
//...

Again, you are wrong. pmAuto doesn't have anything to do with the main form.

Ondrej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/5ff75295/attachment.html>

23.12.2015 02:39, Juha Manninen ?????:

BTW, from localizer POV 150-180 extra resource strings that were added with this patch (which is a VERY bug number) point to likely functionality duplication. :)

Yes, this is correct. Please test r51008 (also you, Juha).

stop f...ing with my system

Although I am of the same opinion as you regarding fsStayOnTop, I strongly encourage you to use a more appropriate language when presenting your fixes and ideas.

Ondrej

I thought that
fsStayOnTop - stay on top of all windows within the application fsSystemStayOnTop - stay on top of all windows within system.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/1a8464c4/attachment.html>

On Wed, Dec 23, 2015 at 11:26 AM, Dmitry Boyarintsev <

As an example.
LeakView allows a user to switch between "fsStayOnTop" and "fsNormal". And it never bothers any other application.

Screenshot: http://pasteboard.co/fDxvGHT.png

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/e08a8d9c/attachment.html>

Dmitry Boyarintsev wrote

fsStayOnTop - stay on top of all windows within the application fsSystemStayOnTop - stay on top of all windows within system.

For the sake of backwards&Delphi compatibility the other way round would be more appropriate, IMO:

fsAppStayOnTop - stay on top of all windows within the application fsStayOnTop - stay on top of all windows within system. (current behavior)

Another thing is if fsAppStayOnTop is supported natively by OSs Lazarus is targetting or has to be somehow achieved by the LCL itself and how. As taazz pointed out, for some usage PopupMenu=pmExplicit + PopupParent is good enough and maybe even a better solution.

Ondrej

Ondrej Pokorny wrote

Yes, this is correct. Please test r51008 (also you, Juha).

PopupParent and PopupMode seem to work only with LCL-Win bindings. With GTK2 and QT it behaves like any modeless IDE window. But yes, this is the right solution. On Windows it behaves perfectly, also with AnchorDocking. Support for other widgetsets can be added later. Zeljko, do you have any idea how to do it?
This solution should be used for ActionList editor and CollectionItem editor and maybe others, too.

BTW, I tested with Wine which apparently mimics Windows behavior accurately in this case. Amazing how far that project has got. Ten years ago it looked like a desperate project. (Almost as desperate as Lazarus. :)

The other modal dialog + PopupMode=pmAuto that we discussed earlier turned out to be a problem in my Xubuntu's XFCE window manager. It behaves odd also in other situations, for example loosing focus from source editor after a search etc.
I tested with OpenSuse Leap 42 + KDE and it worked well. However this is not very important because I want to get rid of that particular modal window.

Juha

Backwards?
fsStayOnTop and fsSystemStayOnTop has been in Lazarus for quite awhile. Changing the behavior will make it backwards incompatible.

I don't really see fsAppStayOnTop in delphi VCL either. http://docwiki.embarcadero.com/Libraries/Seattle/en/Vcl.Forms.TForm.FormStyle

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/97a0f4ee/attachment.html>

Sorry, I didn't really take a look into the Lazarus sources and expected fsStayOnTop in Lazarus behave the same as in Delphi, because LCL should be VCL compatible.

From Delphi's documentation:

/fsStayOnTop This form remains on top of the desktop and of other forms in the project, except any others that also have FormStyle set to fsStayOnTop. If one fsStayOnTop form launches another, neither form will consistently remain on top./

So it means that Lazarus' LCL and Delphi's VCL fsStayOnTop are not compatible, which I don't really understand why this decision was made. (Maybe some historic reason I am not aware of [?])

From my point-of-view, it would be a better decision to have fsStayOnTop that behaves equally with Delphi (system-wide) and another stay-on-top type application-wide just as I suggested before.

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

This is one possibility. But I remember such an option was already rejected for some dialogs in the bug tracker, AFAIR. (Sorry for not finding the issue in Mantis. If needed I can try harder.)

And it never bothers any other application.

No, this is not true. It does bother my email client such as any other fsStayOnTop window, see attachment - from the Win10 theme you can recognize that the email client window is focused and active and is still covered by "Leaks and Traces".

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/58138cc2/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: leaks-on-top.png
Type: image/png
Size: 15101 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/58138cc2/attachment-0001.png>

taazz wrote

stop f...ing with my system

Actually we are f...ing with Lazarus trunk, not with your system. If you want a stable Lazarus, you should use the fixes_1_6 branch instead. It is starting to look very good!

Juha

On Wed, Dec 23, 2015 at 11:26 AM, Dmitry Boyarintsev <

Yes, it is in Lazarus documentation as well.
http://lazarus-ccr.sourceforge.net/docs/lcl/controls/tformstyle.html

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/2e6d4a32/attachment.html>

Dmitry Boyarintsev wrote

As an example. LeakView allows a user to switch between "fsStayOnTop" and "fsNormal".

This is one possibility. But I remember such an option was already rejected for some dialogs in the bug tracker, AFAIR. (Sorry for not finding the issue in Mantis. If needed I can try harder.)

And it never bothers any other application. Screenshot: http://pasteboard.co/fDxvGHT.png

This is not true on my system. It does bother my email client such as any other fsStayOnTop window, see http://postimg.org/image/3tilmvmrx/ - from the Win10 theme you can recognize that the email client window is focused and active and is still covered by "Leaks and Traces".

Steps to reproduce: Use Alt+Tab to switch.

Ondrej

Yes, you are right. I didn't check it before. But as I stated in my last emails:
1.) fsStayOnTop is Delphi-incompatible. Delphi's fsStayOnTop corresponds with Lazarus' fsSystemStayOnTop.
2.) fsStayOnTop in Lazarus can and does overlap other application windows in Windows 10 (although not always).
3.) fsStayOnTop in Lazarus always does overlap other application windows in Linux/KDE.

According to 2+3, fsStayOnTop in Lazarus is anything else than application-wide, regardless what the documentation states :(

So either the documentation or LCL code has to be fixed - or both. The question is how:
A.) Make it backwards compatible: fsStayOnTop / fsSystemStayOnTop B.) Make it Delphi compatible: fsStayOnTop + fsAppStayOnTop (if needed and supported).

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

For the sake of the best User Interface practices and historical reasons.

"fsSystemStayOnTop" is more of an exception, rather than the rule. In most cases, an application wants to be system friendly application and only want to put a form on top of its own windows not system wide.

IIRC, at the time fsSystemStayOnTop was introduced frStayOnTop was inconsistent across widgetsets. Introducing fsSystemStayOnTop forced consistency.

Also, since Delphi doesn't have any variant of either "fsSystemStayOnTop" or "fsAppStayOnTop" it's quite clear that Delphi is not LCL compatible :)

Also, having "fsStayOnTop" is not even critical to be Delphi compatible.
1) Delphi advises NOT to change the FormStyle in run-time (thus any existing code written for Delphi, is not guaranteed to work "as expected" even in Delphi).
2) Since Lazarus doesn't use Delphi .dfm files, who ever ports an Delphi project to Lazarus need to pay attention to the flag (if it's used)

To sum things up: using fsStayOnTop in the new menu designer is not bad.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/39226bfb/attachment.html>

Juha Manninen wrote

PopupParent and PopupMode seem to work only with LCL-Win bindings. With GTK2 and QT it behaves like any modeless IDE window.

Reported: http://bugs.freepascal.org/view.php?id=29247

I hope Zeljko can find an easy way to do it. It would be a pity if we couldn't use PopupParent/PopupMode because it is not supported on Qt/Gtk2 :(

Ondrej

I also have Win10 and Mozilla Thunderbird, cannot reproduce the issue (using trunk).
Do you have any local LCL (win32) changes?

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/c3dbd309/attachment.html>

No, I have no local changes. I always commit them to trunk :)

Steps to reproduce: use Alt+Tab when switching to Thunderbird.

On Linux/KDE "Leaks and Traces" stays on top of all other application windows regardless how you switch to them.

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/9e37e5d3/attachment.html>

Ondrej Pokorny wrote

No, I have no local changes. I always commit them to trunk :) Steps to reproduce: use Alt+Tab when switching to Thunderbird.

I can only reproduce it by opening Lazarus in the front and then trying to resize (by dragging) the underlying Thunderbird screen. Actually it doesn't have to be Thunderbird application, the similar would occur for any other application.
But if I click on the Thunderbird window, it comes over the leakview... Tricky!

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/f6748fee/attachment.html>

When I switch to Thunderbird with Alt+Tab, it stays behind "Leaks and Traces". If I switch to Thunderbird by clicking its icon in the taskbar, Thunderbird is shown correctly in front of "Leaks and Traces".

Actually it doesn't have to be Thunderbird application, the similar would occur for any other application.

Yes it happens with every other application. Thunderbird was just an example.

But if I click on the Thunderbird window, it comes over the leakview... Tricky!

Not for me :(

https://drive.google.com/file/d/0Bx-flYubOTroY3BCaFlScVl2NzA/view?usp=sharing

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

What happens if you enable Windows thumbnails (shown on alt-tab by default) back?

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/9d826d53/attachment.html>

Here's the patch. Please test, It should work now for you.

Index: lcl/interfaces/win32/win32proc.pp
=================================================================== --- lcl/interfaces/win32/win32proc.pp (revision 51009) +++ lcl/interfaces/win32/win32proc.pp (working copy) @@ -870,9 +870,10 @@

     WindowInfo^.StayOnTopList := StayOnTopWindowsInfo^.StayOnTopList;
     EnumThreadWindows(GetWindowThreadProcessId(AppHandle, nil),
       @EnumStayOnTopRemove, LPARAM(StayOnTopWindowsInfo));

- for I := 0 to WindowInfo^.StayOnTopList.Count - 1 do
- SetWindowPos(HWND(WindowInfo^.StayOnTopList[I]), HWND_NOTOPMOST, 0, 0, 0, 0,
+ for I := 0 to WindowInfo^.StayOnTopList.Count - 1 do begin
+ SetWindowPos(HWND(WindowInfo^.StayOnTopList[I]), HWND_BOTTOM, 0, 0, 0, 0,
SWP_NOMOVE or SWP_NOSIZE or SWP_NOACTIVATE or SWP_NOOWNERZORDER or SWP_DRAWFRAME);
+ end;

     Dispose(StayOnTopWindowsInfo);
   end;
   inc(InRemoveStayOnTopFlags);

thanks,
Dmitry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/d8adfd4d/attachment.html>

Kostas Michalopoulos wrote

It seems to crash very often ...

How to make it crash? It does not crash here.

Juha

Dmitry Boyarintsev wrote

Here's the patch. Please test, It should work now for you.

Thanks Dmitry! It works for this issue but opened a regression: Lazarus IDE is moved to the very last place in Alt+Tab history. Steps to reproduce:
1.) Open Lazarus and "Leaks and Traces", check that it is stay-on-top 2.) Switch to another application with Alt+Tab.
3.) Try to switch back to Lazarus with Alt+Tab - you'll see that Lazarus is the very last application. It should be the second after current (in other words the first selected).

Ondrej

Ondrej Pokorny wrote

Thanks Dmitry! It works for this issue but opened a regression: Lazarus IDE is moved to the very last place in Alt+Tab history.

It's a little bit different regression, the fsStayOnTop window is moved to the bottom. Which also not good, since it should remain on top of the application windows itself. Just more work needed.

Did you try restoring thumbnail mode for Alt-tab?

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151223/610be3bb/attachment-0001.html>

23.12.2015 21:32, Dmitry Boyarintsev ?????:

Also see:

http://bugs.freepascal.org/view.php?id=18036

Seems to be related. :)

Maxim Ganetsky wrote

Also see: http://bugs.freepascal.org/view.php?id=18036

and these:
http://bugs.freepascal.org/view.php?id=24546
http://bugs.freepascal.org/view.php?id=24711

Juha

Not only related, but exactly the same one :)

Ondrej

Dmitry Boyarintsev wrote

To sum things up: using fsStayOnTop in the new menu designer is not bad.

If fsStayOnTop worked as it is documented, I would be all for it. But
1.) it has issues on Windows.
2.) it completely fails on Linux/KDE.

So, no, it is bad :(

Ondrej

Ondrej Pokorny wrote

I hope Zeljko can find an easy way to do it. It would be a pity if we couldn't use PopupParent/PopupMode because it is not supported on Qt/Gtk2 :(

Zeljko fixed support of PopupParent/PopupMode in Qt and me in Gtk2 in r51022, r51023.
Please test. It works well on my Kubuntu/KDE testing desktop with both Qt and Gtk2.

If you confirm that menu designer works on your configuration as well, r51008 is the way to go with other dialogs that have to stay on top of the object inspector or its form parent in docked environment.

Please don't use fsStayOnTop because it is buggy (doesn't behave as documented/intended both on my Win10 and Linux desktop).

Ondrej

Dmitry Boyarintsev wrote

Did you try restoring thumbnail mode for Alt-tab?

It works well in thumbnail mode. The fsStayOnTop-window gets correctly hidden behind the new external (Thunderbird, whatever) window when switched to it with Alt+Tab.

But this is not a solution. The old Alt+Tab dialog is by default used in up to Win7 with themes disabled. It also can be set up in Win10 (as I do). Everybody running Win7 with themes disabled (I know a lot of people) are affected by this bug.

Ondrej

Hi!

2015-12-23 12:31 keltez?ssel, Maxim Ganetsky ?rta:

BTW, from localizer POV 150-180 extra resource strings that were added with this patch (which is a VERY bug number) point to likely functionality duplication. :)

Some examples of resourcestrings that can/must be merged

Editing %s.%s - no menu item selected
Editing %s.%s - no menuitem selected

<no shortcut conflicts found>
<no shortcut conflicts remain>
<no shortcut conflicts to resolve>

Resolved conflicts: %d
Resolved conflicts: 0

Shortcut items: %d
Shortcut items: n/a

%s: Shortcuts & accelerator keys
%s: Shortcuts and accelerator keys

.. and there may be a lot more.

Also a question: can this (new) menu designer implemented as a separate/installable package to allow the usage of old one?

(an example of what I'm talking about is Sparta Docked Form Editor in components/sparta/)

P?ter G?bor wrote

Some examples of resourcestrings that can/must be merged ...

Yes, I didn't even notice that.

Also a question: can this (new) menu designer implemented as a separate/installable package to allow the usage of old one?

No, my idea was to replace the old menu designer with a new one. Something is wrong with the design of the old one. Everybody who has modified and improved it says the same. Some improvements just feel impossible without a complete rewrite.
So, this was the rewrite we were asking for.

I was hoping the author Howard Page-Clark would participate in the discussion and improve his designer based on feedback. Maintenance is always an important part of any code.
I have not studied details of the code yet but I plan to do it soon. In any case, if I will be a sole maintainer of this code then I am disappointed. I was hoping for a shared effort.

Juha

I was waiting for more feedback about the design/functionality, and for responses to settle into some sort of consensus about what needs to be changed/improved/removed. (I had nothing to add to the fsStayOnTop discussion). I am perfectly happy to amend the code in line with what is agreed here. The resourcestrings, for instance, need the attention Peter indicated, plus more. This was a clear oversight on my part.

However, if functionality is to be removed, the pruning of the resourcestrings would be more drastic. Is it agreed to remove the RadioItem/CheckMark dialog? Is the left panel not needed at all? The redundancy of duplicated items in that panel was part of the design, a bit of hand-holding for beginners, but perhaps it out of place.

The opening mini-wizard-style question when dropping a new menu on a form could be handled differently, or additionally have a section in the main IDE Options dialog, for instance that provided a default, and a choice of whether the wizard were ever shown.

I certainly expect to share in the maintainance of anything I contribute. However, you will realize that I am a hobbyist, not a professional programmer, and so my skills are limited compared to most of those who read this list, and I am hampered by little experience of operating systems other than Windows variants.

If there are reproducible crashes arising from the new editor, that certainly requires diagnosis and attention. I don't get them here, but if others do...

yours

Howard

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Howard, as the author you also have voting power over the GUI. Besides GUI design is difficult, there is never a "right" solution that everybody would agree upon.
Yet I feel some things should be changed. All settings that duplicate OI properties should either be moved to a bottom section of a popup menu, or they should be removed completely.
Then the remaing GroupIndex feature from "Checkmark and radioitem properties" dialog could be moved to the main window of menu designer and the dialog then removed completely.

There are other usability issues, too.

I haven't seen crashes either. How to reproduce?

From Kostas: Since the menu editor is redesigned, why not do it like in Windows Forms and NetBeans with the "inline editor" which is part of the form editor?

Good idea but how to implement it? It may not be a trivial task. We can plan a future third iteration of menu designer to be an "inline editor".

Juha

Juha Manninen wrote

Howard, as the author you also have voting power over the GUI. Besides GUI design is difficult, there is never a "right" solution that everybody would agree upon.

Yes, dictatorship is far more efficient than democracy.

OK, I will work on a suitable patch that addresses these and the other issues that e.g. P?ter and Maxim raised.

There are other usability issues, too.

Namely...?

I'm not familiar either with Windows Forms or Netbeans. I'll do some research on this idea next year.

Howard

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Howard Page-Clark wrote

Yes, dictatorship is far more efficient than democracy.

True, but this is neither dictatorship nor democracy. This is more like meritocracy. :)

> There are other usability issues, too. Namely...?

Top level menuitems in a MainMenu can be selected but there is no indication about it. Other items get a blue rectancle.

There is a graph at right and bottom side of a selected item. A new item gets created when it is clicked. It happens so easily that items will be created by accident. Maybe a new item could become "real" only after some property is changed. On the other hand the accidental item is easy to delete.
The graph itself looks interesting and maybe too strong. It is a matter of opinion of course.

Juha

Juha Manninen wrote

Top level menuitems in a MainMenu can be selected but there is no indication about it. Other items get a blue rectancle.

Highlighting works fine on Windows. It doesn't work on Linux. I haven't checked OSX.

Ondrej

Ondrej Pokorny wrote

Highlighting works fine on Windows. It doesn't work on Linux. I haven't checked OSX.

Strange. I have tested with GTK2 and QT on Linux and the Windows version using Wine. They all behave identically in this respect.

There was talk about the left sidebar. I don't see a problem having it. Its usability can be fine-tuned of course.
We have space to use. The GroupIndex feature should fit there, too.

Juha

Don't forget that Linux+Wine is not Windows+win32 :)

Ondrej

In the undocked IDE there is absolutely no problem when the menu designer is not stay-on-top. You can switch from OI to ME there and back without any problems.
-> Stay on top is not needed. IMO on the contrary it is bad.

I added PopupParent to Actionlisteditor and Collectionitem as well. But only in the docked IDE. r51051, r51052.

Ondrej

The LCL implementation of themes (based on the work of Mike Lischke) for mainmenu highlighting in GTK2 and QT appears to work differently from the Windows implementation.
I will work on providing a custom-drawn mainmenu highlight across the board, and not depend on themeservices to display this, whether the needed highlight is for a main menu or a popupmenu, as a workaround in this case of the menu editor.

A better long term solution would be to make the highlight theming for TMainMenu and TPopupMenu fully consistent across all widgetsets. However, that is a task beyond me.

Howard

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Can we implement it so that adding a sumnenu to a Separator (a menuItem with '-' as caption) will either be disallowed, or a warning will be shown because several widgetsets crash on that. (Same for setting Caption to '-' of an existing item with a submenu.)

See http://bugs.freepascal.org/view.php?id=24476

Bart

In the new menu editor adding a submenu to a separator is already disallowed (popup menu option/toolbutton is disabled if a separator is highlighted). Do you not find this?
However, the rename Caption function presently ignores this loophole. I will close this loophole in the patch I am working on (and hope to submit later this week).

Howard

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Howard Page-Clark wrote

In the new menu editor adding a submenu to a separator is already disallowed (popup menu option/toolbutton is disabled if a separator is highlighted). Do you not find this?

Shamefully admits: I did not check that.

However, the rename Caption function presently ignores this loophole. I will close this loophole in the patch I am working on (and hope to submit later this week).

Nice.

Thanks,

Bart

Checked it. Fine.

Can I make a suggestion about the "colored space" right and below menu-items. I found out (by chance) that clicking on it would create a submenu. That is awesome!
A text inside the space saying so, would be a nice feature IMO.

Another suggestion: the button that deletes an item: the icon could be changed to a trashcan (we have at least one icon of a trashcan about somewhere). I suggest this because the minus-sign to me also suggests adding a separator (since that means setting caption to '-').

About the "renaming caption to '-' loophole": maybe this should be forbidden for all cases. If user tries to, then show a message saying: "use insert separator instead", or something alike.

Overall first impression: very nice improvement (I dons'use docking).

Bart

2015-12-26 20:37 keltez?ssel, Howard Page-Clark ?rta:

Please use complete sentences as much as possible and avoid storing of partial sentences in resourcestrings.
I mean don't compose complete sentences in run/compile time from words or partial sentences. Such resourcestrings makes localization harder or completely impossible in languages that have different grammar: word order, system of prefixes/suffixes, agglutination, inflection, and other things that I can't imagine.

An example of how NOT to fragment sentences:

msgid "<no shortcut conflicts%s"
msgid " remain>"
msgid " to resolve>"

Also fragments can have different meaning and translations depending on that they are used combined or not.

P?ter G?bor wrote

Please use complete sentences as much as possible and avoid storing > of partial sentences in resourcestrings. I mean don't compose >

complete sentences in run/compile time from words or partial > sentences. Such resourcestrings makes localization harder or > completely impossible in languages that have different grammar: word > order, system of prefixes/suffixes, agglutination, inflection, and > other things that I can't imagine. > An example of how NOT to fragment sentences: msgid "<no shortcut > conflicts%s" msgid " remain>" msgid " to resolve>" Also fragments can > have different meaning and translations depending on that they are > used combined or not.

OK, point taken. I will amend the offending resourcestrings in a patch. I'm not a linguist nor a translator, so did not appreciate that this would cause difficulty.
My motive was simply to reduce the overall number of resourcestrings required by reuse of phrase "atoms", which I see now works satisfactorily only if a single language is ever employed.

Howard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160112/8b3719d0/attachment.html>

2016-01-12 15:26 keltez?ssel, Howard ?rta:

I know :) and thanks for your work!

I have attached a third small patch to issue 29205, to address the infelicity in some menu editor resourcestrings identified by P?ter. Could Ondrej or Juha review this?

Howard

12.01.2016 22:17, Howard ?????:

String "composing" is still present e. g. in "Insert from template" dialog ("Choose template to ..." groupbox caption) and in main menu creation form in "add menu item" fields captions.

Also lismenueditororclickheadertosortbythatcolumn string looks suspicious from this POV.

As for lismenueditormoveseparatedeleteinsertitems: you shouldn't try to align text with buttons this way. It won't work with other than Windows' fonts/font sizes (e.g. on Linux) and other languages. Better change this string to regular caption like "Menu Item actions".

Also I noticed that e. g. "Insert from template" dialog is not resizable. It is better to have resizable dialogs in order to fit longer translation captions (e. g. combobox caption in this case).

2016-01-15 00:27 keltez?ssel, Maxim Ganetsky ?rta:

I started typing about this when your message landed here :)

Another problem I found is that sometimes if I click in the designer area it scrolls the content and the bottom scrollbar is fully covered. Scrolling down with the scrollbar on the side will slowly reveal the bottom scrollbar. Linux/GTK2 screenshot attached...

2016-01-15 08:50 keltez?ssel, P?ter G?bor ?rta:

Also when I drag the bottom scrollbar the content will cover/reveal the scrollbar on the side of the designer...

I have submitted a patch (29411) which I hope addresses these issues, except for the issue:
'String "composing" is still present ... in main menu creation form in "add menu item" fields captions'

I am not clear about which string(s) you are identifying here. Can you give a specific line number in the source that exemplifies the problem you see?

Howard

Its a windows thing yes, it only has 2 groups of windows, normal and on top, each group can handle its own z-order. As you say you should never use it especialy when there is a working alternative that does the job far better.

True sorry it seems my knowledge is outdated on this subject but I believe on being specific when it comes to programming, make sure that the popuform is set to the correct window my self and all that.

Using fsstayontop you are f.......ing with my system! never mind I'll extend the old designer as a package to do what I want and disable the build in one.

:D

Me and you were wrong. fsStayOnTop in Lazarus is different from fsStayOnTop in Delphi. See:
http://lazarus-ccr.sourceforge.net/docs/lcl/controls/tformstyle.html

Yes, there were bugs in fsStayOnTop (accross different WS) in Lazarus that made me (and probably also you) think that fsStayOnTop is system-wide - because it appeared so. But it isn't. And most of the bugs have been already solved, so you can use fsStayOnTop also pretty safely (PopupParent has also its bugs, so it is now about 50:50 depending what you want).

Nevertheless, the new designer DOES NOT use fsStayOnTop any more. You could easily check it by yourself if you had taken the time.

Please stop crying that "we are f.......ing with your system!" We are not. And if you don't like something, you can easily suggest changes and send patches.

Ondrej

Well I'm stuck on lazarus 1.4.4 for the foreseeable future mostly because 1.6 made a pretty aggressive jump to utf8 and I do not have the time nor the inclination to retest every line of code that I have based on unicodestring and widestring and partly because testing new lazarus versions gets longer and longer each year. So I'm going to change the old one to fit my needs, although I like the look and feel of the new one. As for the fsStayontop even if it works as advertised aka stays on top of all application windows only, it is still a bad GUI design, for example if I double click the menu item to write an onclick event I do expect the designer to not obscure my code editor nor the object inspector or other designers that might be open. If I select the form designer I do expect to see the menu designer and not search for it, so yeah fsStayontop is not my cup of tea sorry, then again I do not like nor use the docked form designer either, I prefer the free floating one.

I am trying to clear some disk space to allow for a trunk installation but It will probably not happen any time soon (aka no testing for the time being). for some reason I have ended with too many IDEs installed.

Please stop crying that "we are f.......ing with your system!" We are not. And if you don't like something, you can easily suggest changes and send patches.

Its not crying, is clarifying what I mend (not elegantly I admit). I had too many people "pouting words in my mouth" lately and its a sensitive spot.

I found some Format calls that seems to be unneded: the first parameter for them contains only formatting symbols and the second an array of resourcestrings.

If no one else is currently working on the resourcestrings issue I will try to finish my patch and post it on mantis...
This is more simpler than writing a lot of letter about what and how to fix to be translation friendly.

Do you agree?

2016-01-15 23:19 keltez?ssel, Howard ?rta:

There is a patch from Howard:
http://bugs.freepascal.org/view.php?id=29411
Actually I thought somebody else will take care of it. Now I assigned it to myself.
P?ter, can you please look at it and maybe attach your improved patch to the same report.

Howard, for curiosity, your patch has:
LCLVersion = '1.6.0.2'
The menu editor is developed in trunk 1.7. Are you using a fixex_1_6 version for editing?

Juha

2016-01-17 14:00 keltez?ssel, Juha Manninen ?rta:

There is a patch from Howard: http://bugs.freepascal.org/view.php?id=29411

I did not notice it yet.

P?ter, can you please look at it and maybe attach your improved patch to the same report.

Okay, now I'm working on it...

Sure, fine by me. Go ahead.

Howard

On 17/01/2016 13:00, Juha Manninen wrote:
...

Howard, for curiosity, your patch has: LCLVersion = '1.6.0.2' The menu editor is developed in trunk 1.7. Are you using a fixex_1_6 version for editing? Juha

Yes, the code I worked on was the latest trunk (well perhaps it was from the day before). The IDE I used was 1.6.0. Does this matter?

Howard

I think we can use one resourcestring ('<no shortcut conflicts>') instead of three:

'<no shortcut conflicts>';
'<no shortcut conflicts to resolve>';
'<no shortcut conflicts remain>';

Yes or No?

2016-01-17 17:33 keltez?ssel, P?ter G?bor ?rta:

Yes, I agree with you.

Howard

16.01.2016 1:19, Howard ?????:

Please see attached screenshots.

I think a recent revision by Ondrej resolved this.

Howard

20.01.2016 17:15, Howard Page-Clark ?????:

Yes.

Width of the designed menu must be calculated using the length of captions including the lenght of actual translation of "Add menuitem"... Otherwise if the menu captions are too short the command's caption will not fit.
See the attached screenshot.

Yes, in the original code the minimum length was based on the (English) resourcestring length.
I don't know anything about the translation process, or at what stage in the IDE initialization captions are replaced with translated resourcestrings.
Is there a standard notification, or other means to respond to a different-length translated string and force a repaint? Ondrej introduced an overridden TextChanged method, but this seems not to be called at the moment it is needed for the translated strings, because for this it clearly has no effect.

Howard

It is not only translated strings, but other themes as well. In general all labels should use AutoSize:=true.
See here:
http://wiki.lazarus.freepascal.org/LCL_AutoSizing

Mattias

OK. I've submitted a small patch (29468) which I hope will resolve this particular issue.

Howard

I forgot to answer this earlier.
No it does not matter. It only means that you must open 2 different IDE versions, one for editing and one for testing your changes. I personally use the same binary where I did my changes. Usually it works well enough. Sometimes rarely I break it badly and then I use a backup binary which I have copied to another name.

Juha