ScreenRect bug or not

[Richard Gaskin]

Mark Wieder wrote:

> Richard-
>
> Sunday, June 8, 2014, 11:28:28 AM, you wrote:
>
>> A secret is a willful attempt to conceal, but we have no indication that
>> anyone's doing that.
>
>> So before anyone runs off to the hardware store to grab pitchforks for
>> storming the castle over some imagined IDE conspiracy, please kindly
>> take a moment to consider only what I wrote
>
> Here is what you wrote:
>
>> There is an IDE rewrite underway, and a very large-scope effort to
>> improve overall rendering.

One of the problems with my admittedly-lengthy writing style is that it 
can make posts too long to read - I had also written:

     The IDE rewrite is AFAIK very early-stage, a logical necessity
     from the Open Language initiative and the implications thereof
     related to extensibility.  I imagine we'll be hearing more about
     it as it begins to move from sketchpad to code, but right now
     it's all about supporting OL so I don't believe there's much
     concrete that can be said about it until OL gets fleshed out more.

AFAIK there is no version of the engine in any usable form that supports 
Open Language (on the contrary, I would imagine there are many deep 
design decisions still being fleshed out), so it would not be possible 
for the folks at RunRev to be secretly using an IDE dependent on it.

As Jacque noted, the core dev team has been discussing plans for a new 
IDE for a long time.

Evolution of features and design are an inherent part of the process for 
all software, and a glance at the Road Map makes it clear that it will 
only become increasingly necessary for RunRev as well.

I just think it'll be more productive if we can discuss future 
development options with a presumption of good intentions.


> As you know, I've been pushing for open-sourcing the IDE for over a
> year now, but so far I've seen no move in that direction. If you're
> privy to some information that the rest of us are not, then perhaps
> you have a better word for it than "secret", because it's certainly
> news to me.

If something is merely unknown, using "unknown" may be a good choice. :)

As the current acting Community Manager, the nature of the role requires 
me to help find ways to remove obstacles that may be preventing anyone 
from doing what they want to do in this open source project.

To recap where we are with the IDE in terms of open source process:


The IDE files are on GitHub, and even better are licensed under the very 
permissive MIT license:
<https://github.com/runrev/livecode-ide/blob/master/IDE%20License.txt>

We use LiveCode because it represents a very different way of working, 
but that same benefit for us poses unique challenges as an open source 
project.

As you know better than most, off-the-shelf versioning systems don't 
handle LiveCode's unique structure for stack files, leaving it for us to 
invent our own way to make that happen.

Good work has been done along those lines (and a lot of that by you - 
thank you for helping to bring it as far as it's come), and many options 
exist for ways to do productive work even now, before we have an even 
better system in place.

But ultimately the bigger issue here isn't a technical one of all, but 
the central challenge with all open source projects:  Finding people 
with the time and skills to contribute.

The skills required go beyond just LiveCode proficiency.  As with any 
open source project, there has to be a willingness to work within a wide 
range of divergent interests and goals, and a sometimes-dizzying variety 
of design visions.

Very few of us in the LiveCode universe have much hands-on experience 
with this sort of process.  I've made only modest contributions to the 
Ubuntu project (and thankfully none of them in C++ code <g>), most of 
LiveCode's user base makes and uses only proprietary software, and 
RunRev themselves have been open source just over a year.  We're all 
learning as we go.

It complicates things further that the nature of LiveCode stack files 
currently precludes us from easily using off-the-shelf systems to help 
support the process.

But I still believe we can do it.

There are some very smart, inventive people both here in the community 
and on the core dev team, and we all share the common vision of both 
sides working together productively to make the best LiveCode the world 
has seen.

To help this along, we have the good fortune of having bugs in the IDE, 
which are of course annoying but also allow us an opportunity:

If we prioritize addressing bugs in the current IDE right now, we'll not 
only have fewer bugs, but more importantly we will have found the team 
members and processes that can guide bigger objectives.

This email has already gotten too long, so let me outline some of the 
ways we can work on the IDE today in a separate post.

-- 
    Richard Gaskin
    LiveCode Community Manager
    richard at livecode.org