First

This forum is a working group for community contributors to the LiveCode IDE included in the main LiveCode distribution.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: First

Post by mwieder » Sat Jun 01, 2013 12:15 am

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

phaworth
Posts: 592
Joined: Thu Jun 11, 2009 9:51 pm

Re: First

Post by phaworth » Sat Jun 01, 2013 12:55 am

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

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: First

Post by FourthWorld » Sat Jun 01, 2013 5:19 pm

@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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: First

Post by mwieder » Sat Jun 01, 2013 6:30 pm

@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.

phaworth
Posts: 592
Joined: Thu Jun 11, 2009 9:51 pm

Re: First

Post by phaworth » Sat Jun 01, 2013 10:00 pm

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

Pete

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: First

Post by FourthWorld » Sat Jun 01, 2013 10:50 pm

@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

phaworth
Posts: 592
Joined: Thu Jun 11, 2009 9:51 pm

Re: First

Post by phaworth » Sun Jun 02, 2013 5:33 pm

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

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: First

Post by monte » Tue Jun 04, 2013 12:39 am

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).
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Locked

Return to “IDE Contributors”