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

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:

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 LiaisonLiveCode development, training, and consulting services: Fourth World Systems:http://FourthWorld.comLiveCode User Group on Facebook :http://FaceBook.com/groups/LiveCodeUsers/

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.

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 LiaisonLiveCode development, training, and consulting services: Fourth World Systems:http://FourthWorld.comLiveCode User Group on Facebook :http://FaceBook.com/groups/LiveCodeUsers/

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

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

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.

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.

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

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

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