Thanks for your advices, Pelle. I saw something similar with your idea on the Inkscape roadmap but is far ahead. However, I'm OK if the developers think we should start to work on  it now.
Regards,
Minglangjun Li

2017年3月21日 17:57,"Pelle Nilsson" <pellenilsson@...400...>写道:
Hi,

(I am not a inkscape developer, just an extension developer, the
following is just my own opinions.)

Probably a lot or all of those ideas would  be great additions (some
real dev would have to judge) even if I have not had many issues with
unstable extensions.

Including some more details in the XML for extensions to work with
would be a good thing as well. Like how the current selection is
included, it would be nice to get information about the filename of
the current drawing (if it has been saved/loaded) and... there was
some more things I have thought of would be nice to have for my
extensions but I can't remember right now.

What I also would really like to see though (in addition) would be a
new way to make extensions that gives them a (python) api to hook
directly into Inkscape and modify the drawing. The current system is
good for a few things (and for allowing extensions in other
languages), but almost everything non-trivial requires using python
modules to duplicate functionality that already exists in Inkscape,
and it is very easy to miss some detail. For instance something simple
as moving an object, that Inkscape can already do in different ways
(with or without translating patterns or gradients for instance)
becomes rather complex to get right the way extensions are currently
made. Essentially the burden of parsing SVG and creating a valid SVG
document (including Inkscape specific additions) is all on the
extension developer.

Looking at the design of FreeCAD or Blender, both those open source
applications have nice friendly python APIs, and built in script
consoles. It would be fantastic to see something like that in
Inkscape. An extension could have both access to low-level
modification of SVG/XML attributes, as well as a higher level API to
do things like moving or resizing objects without worrying about
transforms etc.

Starting simple with just a few basic functions might be possible to
do in a summer, even if it would not be by far a complete API.

https://docs.blender.org/api/blender_python_api_2_77_0/info_overview.html

https://www.freecadweb.org/wiki/Python_scripting_tutorial

I'm sure there has been some serious discussions about that in the
past, but I am not sure about if there are any plans or even for some
odd reason a decision to not wanting something like that.


On Tue, Mar 21, 2017 at 9:47 AM, Minglangjun Li <liminglangjun@...400...> wrote:
> I manually wrapped the text. So in case the format is corrupted, I upload a
> plain text version.
>
> On Tue, Mar 21, 2017 at 4:35 PM, Minglangjun Li <liminglangjun@...400...>
> wrote:
>>
>> Hi all,
>>
>> I'm a student at Xidian University, of Xi'an, China. This is my first time
>> to
>> apply for GSoC. Since I haven't applied before and don't know how to write
>> a
>> good enough application, I decide to follow the Inkscape SOC application
>> template on the website. I'll try to cover all the points in brief.  Also,
>> English is not my mother tongue. Please excuse any errors on my part.
>>
>> I use Inkscape mainly for technical drawings (e.g. flow charts, neural
>> networks structures) and app icons. The most complex two I created are a
>> convolutional neural network and an anime character[1]. I love it for
>> being
>> powerful, easy-to-use and off course, open source. Being a contributor to
>> it
>> would definitely be exciting. I'm browsing the source code recently and
>> have
>> submitted two patches[2,3].
>>
>> I code in C++ and Python. My favourite programming tools are Vim and Git.
>> Projects I completed include a COOL compiler [4] which is the course
>> project
>> of Stanford compiler course and an Android client [5] for the NHK easy
>> news
>> website. My contributions to other open source projects are:
>> 1. I fixed a bug in the implementation of the Felzenszwalb segmentation
>> algorithm in scikit-image[6]. Old implementation does not update the sizes
>> of
>> merged regions which causes small regions to be merged into only a few
>> large
>> regions. [7]
>> 2. I extended the Python binding of the Dlib library [8] to support
>> discontiguous Numpy arrays. [9]
>>
>> Q: Why should you pick me?
>> A: I use Inkscape and I would like to help it become better. I'm
>> particularly
>>    interested in improving the performance of Inkscape which has been
>>    complained by many users [10,11] and hope to learn from it as well as
>>    sharpen my programming skills.
>>
>>
>> The statements and adjudgements below are according to my current
>> knowledge
>> of Inkscape. If there's any mistake, please let me know.  Any advice for
>> improving this proposal will be greatly appreciated.
>>
>>
>> The Proposal
>> ============
>>
>> Project: Robust Extension System
>>
>> Abstract
>>
>> The extension system is a way to extend Inkscape's functionality.  My
>> project
>> aims to improve the performance of the subsystem and make extension
>> development reliable through creating a specific unit test framework.
>>
>> Goals:
>>
>> 1. Check extensions' availabilities in a top-down strategy to avoid
>>    unnecessary rechecking in the case of cascading failure.  This also
>> makes
>>    the dependency check faster. (May 30 - June 20)
>>
>> 2. Implement a universal expiration time manager for all the extensions
>> which
>>    uses less memory and is easier to maintain.  (June 21 - July 20)
>>
>> 3. Create a test suite for extensions. Build infrastructures like document
>>    builder, extension loading, node and attribute lookup, etc.(July 21 -
>>    August 20)
>>
>> 4. Other miscellaneous tasks. (If time allows)
>>    - Implement an INX builder for internal extensions, making the code
>> more
>>      readable and maintainable.
>>    - Release an extension if it gets deactivated to save memory.  This
>>      follows the observation that deactiveated extensions are never
>> activated
>>      again.
>>    - ...
>>
>> Details:
>>
>> 1. To check extensions' availabilities in a top-down strategy, we should
>> use
>>    a data structure like disjoint sets to represent the relationships
>> between
>>    extensions. We then assign ranks to extensions in the following way: If
>> an
>>    extension has no dependency, we call it a root extension and assign a
>> rank
>>    of 0 to it. Otherwise, we set its rank to the maximum rank of all its
>>    dependencies plus one. With the help of ranks, we're able to check
>>    extensions' availabilities in the order of their ranks. This ensures
>> that
>>    an extension's dependencies have been checked before it is checked.
>>
>> 2. Inkscape trunk uses a circular linked list to manage extensions'
>>    expiration times. It is not well designed and do bad things (calling
>>    'delete this' in the member).  We can improve this by introduce a
>>    universal expiration time manager.  The expiration time of each
>> extension
>>    is inserted into a min heap (or priority queue) on load. When the
>> manager
>>    timeouts, it removes all the time that have expired and unloads those
>>    extensions. This is similar to how Nginx manages its event timers.
>> Unlike
>>    Nginx, we set the timeout of the timer according to the minimal
>> expiration
>>    time instead of a constant interval and update it once the queue is
>>    updated.
>>
>> 3. Testing an extension is straightforward. We read or elaborate some
>>    documents, load the extension and test it against those documents. For
>>    most of the input/output extensions, we can do nothing but check if
>> they
>>    finish without error and assume that third-party libraries do what they
>>    are supposed to do.  For effect extensions, we apply them to the
>> documents
>>    and examine if the objects are corretly modified in the returned
>> document.
>>    Some helper functions should make writing test cases easier.  I noticed
>>    that there're some bare-bone tests located in the test subdirectory of
>> the
>>    extensions folder. Testing Python extensions separately using unittest
>> is
>>    a good idea, but what about extensions written in other languages? This
>>    needs further consideration.
>>
>>
>> [1] https://drive.google.com/open?id=0B1hNZ1rY1_c4RUJ5b3N5Z0gtODA
>> [2] https://code.launchpad.net/~mljli/inkscape/fix-1670688
>> [3] https://code.launchpad.net/~mljli/inkscape/cmake_arch
>> [4] https://github.com/mljli/compilers-004
>> [5] http://nekotachi.github.io/easynews
>> [6] https://github.com/scikit-image/scikit-image
>> [7] https://github.com/scikit-image/scikit-image/pull/2164
>> [8] http://dlib.net/
>> [9] https://github.com/davisking/dlib/pull/155
>> [10] https://bugs.launchpad.net/inkscape/+bug/1198317
>> [11] https://bugs.launchpad.net/inkscape/+bug/367779
>>
>> Regard,
>> Minglangjun Li
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...1784...sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>



--
/Pelle