[scribus-dev] Scripter2: How to create page items?
mheieis at alois.ca
Fri Jan 11 17:20:02 UTC 2013
>>> 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
> 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.
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.
More information about the scribus-dev