[Skencil-devel] Revitalising Skencil

[Igor Novikov]

On Sun, Nov 7, 2010 at 10:01 PM, Bernhard Herzog <bh at intevation.de> wrote:

> On 02.11.2010, Bernhard Herzog wrote:
> > On 02.11.2010, Igor Novikov wrote:
> > > Actually it's almost the same
> > >    Skencil 0.6.17 structure. Take a look on following illustration:
> > >
> > >
> http://saveimg.ru/pictures/02-11-10/6facaf814684b114a74fb3b84a9e94f2.png
> > >
> > >    Only startup script is replaced by __init__.py
> >
> > There's a crucial difference.  You introduced a new Pythong package above
> > the existing Sketch package and do some sys.path manipulation during
> import
> > that makes it possible to import the Skencil modules under their 'old'
> > names.
>
> I should have read the sources more carefully.  The path manipulation does
> not
> happen during import.  It only happens when the skencil_run function is
> executed.  This doesn't make much of a difference, though.  The problem
> that
> there are two absolute names for all Sketch modules is not affected.
>
> I originally thought that now it would be possible to easily import Skencil
> from a program that wanted to use it as a library.  It turns out that that
> is, in fact, not possible, because the path manipulation is necessary and
> only done in skencil_run which also starts the application. So, given the
> current implementation, there does seem to be no reason at all for the code
> to be installed in Python's site-packages directory.


Hi all!

Sorry for delay in responding. I'm just arrived today to Foz do Iguassu
(Brazil)
where will be Latinoware 2010 conference.

All changes in project structure (exactly moving project code into
site-packages/)
have one common goal: to simplify project distribution and packaging
(packaging
is equivalent for distribution through repositories). Packagers are not
Python
programmers but rather advanced Linux users. So complex build inhibits
project
packaging.

All my fixes in Skencil code are point fixes just to eliminate existing
issues & bugs
(excepting code reformatting because this procedure is a technical
manipulation).
There is no sense on this milestone to develop such advanced features like
subpackages
for external use. Actually this feature is the same as to start another
project because
such subpackages should have detailed docs, unitest coverage, specially
designed
architecture etc. Our main tasks for current milestone are:

1.Fix bugs
2.Slightly improve UI
3.Provide easy way for project binaries distribution

Last point is equivalent for marketing & advertising in commercial
programming.
Project source code only is not enough to revitalize Skencil. We need
revitalizing
project for users and we need user's feedback but not bug fixing only. 10
years
ago users have no choice because there were Sketch and Sodipodi only. But
now
they have powerful forks: Inkscape and sK1. So on first milestone we just
announce a project rebirth but on next step we should selecting a correct
strategy for further project development.

On my opinion Skencil has potential marketplace as a small, fast and
lightweight
editor only. Porting on Gtk widgetset is more preferable because:

1.Most popular distros (Ubuntu & Mint) use GNOME as desktop environment.
2.Gtk widgetset provides extra fast application start in GNOME DE (it's
important for lightweight editor)
3.C language based Gtk is closer to Python native extensions than C++ based
Qt.
4.This way simplifies win32 porting. Actually even for win32 simple vector
graphics editor is also usefult.

I don't see a reason developing reusable components inside Skencil because
vector graphics issues
are really specific.

-- 
Regards,

Igor Novikov
sK1 Project
http://sk1project.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/skencil-devel/attachments/20101109/cb71f3a8/attachment.html