<br><br><div class="gmail_quote">On Sun, Nov 7, 2010 at 10:01 PM, Bernhard Herzog <span dir="ltr"><<a href="mailto:bh@intevation.de">bh@intevation.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 02.11.2010, Bernhard Herzog wrote:<br>
> On 02.11.2010, Igor Novikov wrote:<br>
</div><div class="im">> > Actually it's almost the same<br>
> > Skencil 0.6.17 structure. Take a look on following illustration:<br>
> ><br>
> > <a href="http://saveimg.ru/pictures/02-11-10/6facaf814684b114a74fb3b84a9e94f2.png" target="_blank">http://saveimg.ru/pictures/02-11-10/6facaf814684b114a74fb3b84a9e94f2.png</a><br>
> ><br>
> > Only startup script is replaced by __init__.py<br>
><br>
> There's a crucial difference. You introduced a new Pythong package above<br>
> the existing Sketch package and do some sys.path manipulation during import<br>
> that makes it possible to import the Skencil modules under their 'old'<br>
> names.<br>
<br>
</div>I should have read the sources more carefully. The path manipulation does not<br>
happen during import. It only happens when the skencil_run function is<br>
executed. This doesn't make much of a difference, though. The problem that<br>
there are two absolute names for all Sketch modules is not affected.<br>
<br>
I originally thought that now it would be possible to easily import Skencil<br>
from a program that wanted to use it as a library. It turns out that that<br>
is, in fact, not possible, because the path manipulation is necessary and<br>
only done in skencil_run which also starts the application. So, given the<br>
current implementation, there does seem to be no reason at all for the code<br>
to be installed in Python's site-packages directory.</blockquote><div><br>Hi all!<br><br>Sorry for delay in responding. I'm just arrived today to Foz do Iguassu (Brazil)<br>where will be Latinoware 2010 conference.<br>
<br>All changes in project structure (exactly moving project code into site-packages/)<br>have one common goal: to simplify project distribution and packaging (packaging<br>is equivalent for distribution through repositories). Packagers are not Python <br>
programmers but rather advanced Linux users. So complex build inhibits project<br>packaging. <br><br>All my fixes in Skencil code are point fixes just to eliminate existing issues & bugs<br>(excepting code reformatting because this procedure is a technical manipulation).<br>
There is no sense on this milestone to develop such advanced features like subpackages<br>for external use. Actually this feature is the same as to start another project because <br>such subpackages should have detailed docs, unitest coverage, specially designed <br>
architecture etc. Our main tasks for current milestone are:<br><br>1.Fix bugs<br>2.Slightly improve UI<br>3.Provide easy way for project binaries distribution<br><br>Last point is equivalent for marketing & advertising in commercial programming.<br>
Project source code only is not enough to revitalize Skencil. We need revitalizing<br>project for users and we need user's feedback but not bug fixing only. 10 years<br>ago users have no choice because there were Sketch and Sodipodi only. But now<br>
they have powerful forks: Inkscape and sK1. So on first milestone we just <br>announce a project rebirth but on next step we should selecting a correct<br>strategy for further project development.<br><br> </div></div>On my opinion Skencil has potential marketplace as a small, fast and lightweight<br>
editor only. Porting on Gtk widgetset is more preferable because:<br><br>1.Most popular distros (Ubuntu & Mint) use GNOME as desktop environment. <br>2.Gtk widgetset provides extra fast application start in GNOME DE (it's important for lightweight editor)<br>
3.C language based Gtk is closer to Python native extensions than C++ based Qt.<br>4.This way simplifies win32 porting. Actually even for win32 simple vector graphics editor is also usefult.<br><br>I don't see a reason developing reusable components inside Skencil because vector graphics issues <br>
are really specific.<br><br>-- <br>Regards,<br><br>Igor Novikov<br>sK1 Project<br><a href="http://sk1project.org" target="_blank">http://sk1project.org</a><br><br><br>