LiveCode Forums

Yeah... there'd be nothing but chaos if we all just got what we wanted...

mwieder wrote:Yeah... there'd be nothing but chaos if we all just got what we wanted...

Yeah, but just once..... that's all I ask
Pete

@mwieder: The triggering of mouseDown when using menu shortcuts is a feature, not a bug. Or at least it's supposed to be. The goal there was to provide a single message a menu bar can respond to to update its menus before processing the key event.

Either mousing down in the menu bar or triggering a menu item via a keyboard shortcut may or may not do what you need depending on whether the menu item is enabled.

In the olden days (before this mouseDown event was added in response to menu shortcuts) we had to resort to all manner of odd workarounds to keep our menu items in synch with the environment they represent. With this addition, the hope is that we can now write one update handler for the menu bar, and know that it'll be processed when either the mouse goes down on the menu bar or a menu item is triggered with a shortcut.

In my testing here I've found that when I switch toplevel stacks (by bringing one in front of the other) the menus take longer to render than when the stack layering remains the same. Commenting out the routines that update the File and Edit menus saves significant time, though of course at the cost of not having updated items in those menus.

In the File menu the big time waster is the complete rebuilding of the Recent Files list, which really only needs to be done when a file is closed and then stored somewhere for use during the menu rebuild. When we sort out the IDE contributor process I'll address that.

The Edit menu requires more in-the-moment updating, but I still think there are some ways to optimize that one too.

@mwieder: The triggering of mouseDown when using menu shortcuts is a feature, not a bug.

yes, that's why I check to see if the mouse is really down in the mouseDown handler. If it's not, then I handle the commands myself, and that avoids whatever it is that's causing the long delay.

Re the recent files list, note that it's also stored in two separate custom properties for some reason.

Wait - LC maintains a recent files list somewhere? You mean it's own stackfiles or files opened via an application's file menu?

Pete

@Pete: See File->Open Recent File

FourthWorld wrote:@Pete: See File->Open Recent File

Sure, I know about that one - thought the reference was to files opened from an application's file menu and I'd wasted time writing code to do it myself.
Pete

Aside from that, it seems that some sort of vcs will be required so I'm wondering if Monte is checking this board and might comment on his recent efforts to put one in place.

I'm not sure if I will have time to be very involved here... too many projects on the go at the moment but I'm happy to work closely with RunRev should they want to try out lcVCS with IDE components. The process would be good for both the IDE and lcVCS but the decision needs to come from Edinburgh and they will need to dedicate some resources (staff) to it. Because they have many stack files it would be possible to move them one at a time to using lcVCS. Some of the newer libraries etc could move to lcVCS in a few minutes. Some of the older ones like revMenubar would want some cleanup because there's lots of buttons with icons set to images that no longer exist and lcVCS chokes on that ... Also the more UI there is to a stack the more work will need to happen in the lcVCSExport handler. Still... probably no more than a few days and the IDE would be under proper version control which would allow merging in all your work...

As a GPL'd work, we can make as many forks as we like.

The IDE is MIT licensed so it's even possible to sell a fork (still requires a LC license though).