First
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: First
Yeah... there'd be nothing but chaos if we all just got what we wanted...
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 9856
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: First
@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.
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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: First
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.@mwieder: The triggering of mouseDown when using menu shortcuts is a feature, not a bug.
Re the recent files list, note that it's also stored in two separate custom properties for some reason.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 9856
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: First
@Pete: See File->Open Recent File
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: First
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...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.
The IDE is MIT licensed so it's even possible to sell a fork (still requires a LC license though).As a GPL'd work, we can make as many forks as we like.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/