First

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

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

First

Post by malte » Fri May 31, 2013 3:21 pm

Hi all,

looking forward to the discussion here. What would be the best way to organize the effort to make changes to the IDE?

Cheers,

Malte

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

Re: First

Post by phaworth » Fri May 31, 2013 4:48 pm

I'm sure there'll be no shortage of ideas posted on this forum as soon as the word gets out!

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.

Pete

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

Re: First

Post by mwieder » Fri May 31, 2013 5:25 pm

@Pete- I think that's a main reason why the IDE isn't ready to accept pull requests yet.

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

Re: First

Post by mwieder » Fri May 31, 2013 5:41 pm

As a high-level overview, one of the problems with the current design of the IDE is that there are way too many dependencies among the various stacks.
What I'd like to see is a well-thought-out API that defines the contract for stack interaction, and the IDE components made as autonomous as possible. This will minimize the interactions between system stacks and place those interactions into a documented
In the long run, this will make it possible to have mix-and-match IDE components, where the IDE is just a framework for the plugin components.

As an example, my PowerTools stack is a drop-in replacement for the tools palette. But other system stacks reference certain components of the tools palette, so I had to maintain some existing names of controls and groups, even though I didn't have a need for them myself. What I'd like to see instead of

Code: Select all

send "mouseUp" to button "xyzzy" of stack "someIDEstack"
is something like

Code: Select all

dispatch "aSystemEvent" to stack "someIDEstack"
The debugger stack is a good example of this. There are something like five points of contact between the debugger and anything else in the system. These aren't well documented, but they are well defined and modifications in the debugger or in other system stacks are independent of each other - there are no weird interactions to deal with.

Even better would be to have the IDE framework implement a publish-and-subscribe model and dispatch events to the relevant components:

Code: Select all

dispatch "aSystemEvent"

-- in ideDispatcher:
-- look up which components are interested in the "aSystemEvent" message
-- dispatch the message to those components and let them handle it


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

Re: First

Post by FourthWorld » Fri May 31, 2013 7:19 pm

mwieder wrote:As a high-level overview, one of the problems with the current design of the IDE is that there are way too many dependencies among the various stacks.
What I'd like to see is a well-thought-out API that defines the contract for stack interaction, and the IDE components made as autonomous as possible.
I would second that.

In fact, it may be a good idea to write a new IDE completely from scratch, migrating some elements from the old IDE one at a time in a fresh way that conforms with the new, lighter framework.

This would mean that there would be a period in which the new IDE is in development while the current one remains in use and still has many opportunities for refinement. For example, something very wrong is going on with the mouseDown handler in the menu group, as it takes a looooooooooooooong time to respond. Until a new IDE is available, that and many other issues will need to be addressed.

So in terms of community, it may be helpful to set up two teams: one team coordinating the new architecture, and the other doing the less glamorous work of taking care of issues in the current IDE until the new one is available.

I would be happy to contribute to either or both of those efforts.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

Re: First

Post by malte » Fri May 31, 2013 7:31 pm

Sound just right to me. I also would love a good API with components that can subscribe. In the meantime would it be a good idea to list pet peeves with the current IDE in seperate threads?

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

Re: First

Post by phaworth » Fri May 31, 2013 8:08 pm

I guess I'm not sure of RunRev's plans re the IDE. We have the current code available to us now but isn't there an effort to "tidy up" the code base with a release date of around September, or is that just the engine? If it does include the IDE, I wonder what "tidy up" means. I'd hate to spend a lot of time fixing things in the existing IDE code only to find it's all changed come September.

Having said that, I do like the idea of a subscribe capability.

Pete

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

Re: First

Post by FourthWorld » Fri May 31, 2013 8:12 pm

malte wrote:In the meantime would it be a good idea to list pet peeves with the current IDE in seperate threads?
I suspect there will be many. Ideally they'd go into the RQCC, but in every community I see people just use whatever venue they happen to be in at the moment when they feel the need to vent, so at least separating requests about the current IDE into another thread will keep architectural discussions a little more readable.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

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

Re: First

Post by mwieder » Fri May 31, 2013 8:17 pm

@Pete- yes, this discussion is prior to being able to submit changes in the IDE, and a lot depends on how the team wants to move forward.
I wanted this forum open so that we can begin to discuss some of the high-level things we'd like to see in an ideal IDE with the possible goal of having some input into the direction of the actual IDE, but also to bounce around some ideas that might result in some alternatives. Mats Wilstrand has already started on an alternative IDE framework, rIDE, and I see fertile ground for mutiple ideas here, but I'd like to see some interoperability, or at least as much as is feasible.

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

Re: First

Post by mwieder » Fri May 31, 2013 8:20 pm

@Richard- yes, I agree. Until we know some more about runrev's future plans for the "official" IDE, existing bugs and pet peeves should be a separate issue. Although (changing my mind a bit) if the pet peeves about the existing IDE contribute to shaping a direction for the future then I think they're appropriate here. I hesitate to open a thread for that discussion, though, because it can easily degenerate into rants about existing bugs.

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

Re: First

Post by phaworth » Fri May 31, 2013 8:23 pm

FourthWorld wrote:
So in terms of community, it may be helpful to set up two teams: one team coordinating the new architecture, and the other doing the less glamorous work of taking care of issues in the current IDE until the new one is available.
So I guess I have to ask this question, not being familiar with the FOSS world. Is it really the case that "we" would get into writing a completely new IDE? That's a huge task that I would have thought RunRev should be managing.

Pete

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

Re: First

Post by FourthWorld » Fri May 31, 2013 8:45 pm

phaworth wrote:
FourthWorld wrote:Is it really the case that "we" would get into writing a completely new IDE? That's a huge task that I would have thought RunRev should be managing.
As a GPL'd work, we can make as many forks as we like. :)

But of course seriously cool contributions should find their way into the Commercial Edition, and so yes, it would be best if RunRev were managing the project.

The Ubuntu project is in a circumstance similar to RunRev, and their model may be worth following. In both cases there's a private company providing engineering and other resources, and whose livelihood is dependent on the project. And in both cases there's a tremendous opportunity in coordinating with contributors from the community, to accomplish more than either could do without the other.

Ubuntu has a position of Community Manager, enormously well executed by Canonical's Jono Bacon. His role is sort of "central cat herder" among other things, a liaison between the corporate and community worlds to coordinate the efforts of both for their mutual benefit.

I would imagine RunRev has someone in mind on their staff for such a position, and hopefully we'll learn more as their plans for the IDE are shared here.

In the meantime, anyone interested in helping this project may benefit from Jono's experience he shared in his book, "The Art of Community":
http://www.artofcommunityonline.org/

In the spirit of free-and-open, you can purchase the book through O'Reilly if you want to show your support for the effort, and the book can also be downloaded at no cost in PDF form from that site.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

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

Re: First

Post by mwieder » Fri May 31, 2013 8:56 pm

@Pete- FOSS doesn't necessarily imply "unmanaged". Runrev would indeed be managing the project, and while Mark Waddingham has said that he supports delgating first-pass approval of pull requests to a team of volunteers, the ultimate responsibility for what goes into the "real" build is up to runrev itself.

While I wouldn't be upset by multiple forks of the IDE to support customization, I think, as Richard said, that the cool stuff would and should make its way into the main branch of the code for everyone to share. I don't really see other forks gaining much traction - MetaCard is the only real alternative to the existing IDE right now, and I'm afraid its usage numbers are dwindling as the runrev IDE becomes more robust.

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

Re: First

Post by mwieder » Fri May 31, 2013 9:06 pm

@Richard- try placing this code in the mouseDown handler of your menubar. It's how I got past the menubar-mouseDown problem in glx2. Bug report 9850 was closed because the team couldn't reproduce the problem, but this fixed it for me. It's sidestepping the problem because I don't know what the real cause is, but there seems to be a confustion between mouseDown and keyDown messages in menubars which ended up causing 800ms delays for me.

Code: Select all

    -- necessary because control-key sequences trigger a mouseDown event
    -- in menuBars (bugs 9850, 9851).
    if the mouse is not down then
        if 99 is in the keysDown then -- control-C
            copy
        else if 120 is in the keysDown then -- control-X
            -- do stuff to support undo here
           cut
        else if 118 is in the keysDown then -- control-V
            paste
            exit to top -- resolves tmControl conflict
        end if
        exit mouseDown
    end if

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

Re: First

Post by phaworth » Fri May 31, 2013 11:55 pm

Thanks Richard and Mark for the explanations. I'm certainly glad to hear that it's at least likely that there will be a central manager for this.
Pete

Post Reply

Return to “IDE Contributors”