[scribus-dev] Scripter2: How to create page items?

[Mark Heieis]

>>> Maybe it would be good if there was a table on wiki that listed the
>>> new and the old commands and then the missing ones would be obvious?
>>>
>> you can create such a table if you think it's useful.
>>
>> personally, i prefer to put my energy in creating a good documentation
>> for the new commands.
>> in my eyes, having them well documented is more useful when porting
>> scripts than a table listing all the commands. and the result will still
>> useful when the people will have forgotten that there was an older
>> scripter...
>>
> But we will probably need something for people when they are trying to
> fix a script written with the old scripter, so they know what the new
> equivalents are.
>
> Greg
>
>
>
Hi,

Here's my perspective. I've been looking for a project that interests me 
and to where I think I can contribute. My interests have always been 
with the ability to extend tools and their behaviour with scripting 
technology beyond what the originators may have ever considered.

I'm also new to this project. So my approach is one that I usually take: 
The perspective of a "new" end-user and new SW engineering graduate who 
I just hired. So how do I bring a new grad up to speed with a project 
mid-steam, so that they can become productive? Use the code, read the 
code, read the design docs, understand the project plan, test the code, 
experiment with the code and document the code, so that they can get the 
understanding required to become good contributors.

Unfortunately, most of those pieces aren't readily available or out of 
date, additionally, the Scripter code is not documented. There really 
aren't any supporting design/flow/architecture docs nor any docs that 
indicate what's been done, what's been worked on, what's missing, and 
more importantly, what's not being worked on, which would really help 
someone new to the project. All of these make it a real challenge for a 
project newbie. (BTW - I understand why this is so and appreciate all of 
the volunteer efforts).

So in this particular case, the new Scripter2 approach makes much more 
sense to me. The syntax is much easier to understand and implement than 
the original. So with a few examples (also good for function and 
regression testing) and documentation of the implemented API, someone 
would have enough to build on. What's been catching me is expected API's 
that aren't "implemented", which doesn't bother me. However, I don't 
want to spend time working on it, only to find out someone else is.

In summary, I would say with limited resources, putting efforts into 
documentation would be the best approach, as it would provide the 
broadest appeal. In terms of a matrix between old and new, I would 
rather see something that indicates the functionality that has been 
implemented vs what is still to be done. And both should be easy to find 
and verify against available code.

I apologize if material exits and I just haven't found it.

Cheers,

mrh.