[Skencil-devel] Join forces for skencil1/sK1? (was: [Skencil-users] sK1)

[Igor Novikov]

Hi Bernhard,

>Why not join forces on a tcl/tk based Skencil1/sK1 development?

We absolutely agree that it will be the best way. But on this moment our
team is "in stream" i.e. in active prerelease stage. If we start projects
joining we lost development speed. More over we should stop development
because in joined project new roadmap, coding conventions etc. should be
created. Therefore our opinion is to try join forces after sK1 v0.9 release.

sK1 summer preview was commonly announced into russian and ukrainian Linux
community, therefore many users are waiting for the release. We hope
involving
the community into sK1 development.

>The main common interest is that Skencil has been not seen
>much development in the last years and applications like inkscape
>have drawn more attention from the users and developers community.

Inkscape project has several weakness. First is SVG primary format which is
useful for screen graphics only. Second is pure C++ core codebase which
delimits
slow development. Third - very slow "livarot" engine. In our tests with
hardware
accelerated XRender sK1 renders complex drawing faster than Inkscape.

>The stability and design of the Skencil tcl/tk version shows that
>there is a place for such an application and the GTK port has never
>reached a usable state.

Yes, we known this fact that tk-based Python applications have ultimate
stability
under unix-like systems. The application works until main thread is live.
Such stability is unusual for pure C/C++ applications and very imortant for
day-by-day working in vector editor, for example in prepress.

>Skencil/sK1 is still a strong application,
>so joining forces would help to grow the community.
>Packaging and documentation efforts would be reduced and all this.

Practically there is only one potential competitor - XaraXtreme. But this
application is
not a favorite under Win32 platform, because it's not suitable for printing
industry.
As you can see sK1 interface and behavior is highly similar to Corel or
Illustrator.
We plan that our potential users (first of all, designers) will find in sK1
a friendly
enviroment like under Win. Therefore we don't plan any extended help system
for
first release (only short application description). But we have professional
experience
in DocBook documentation. For example, we contributed some efforts in
tkZinc project documentation (we tried to use this OpenGL canvas as a
primary
canvas for sK1):

http://www.tkzinc.org/tkzinc/pmwiki.php?n=Main.Documentation

>Personally I am quite open regarding the name, maybe sK1 would even
>be the better one, given that it resembles Skencil1 closely enough.

I think it is not a main issue in this project :)

>We have wondered why the fork has happened in the first place without
>some more communication from your side.

The first reason is that Internet communications in Ukraine were primitive
in
2003-2004 years. We has only dial-up connection, therefore there was no way
for active community collaboration. Now, personal LAN connection is usual
thing.

Second reason is our experience in OSS world. When we start fork we were
"newbe" in the community.

Also there is commonly held view in Linux community that Skencil development
is
something like "closed private club". Even this fact is reflected in
wikipedia.org,
at least in russian article about Inkscape. The project should be more open
and
more active to increase popularity.

>So what do you think about the general idea?

We like this idea! :)

Sincerely,

Igor Novikov
sK1 Team
http://sk1.sf.net


On 11/19/06, Bernhard Reiter <bernhard at intevation.de> wrote:
>
> Hi Igor,
>
> On Saturday 11 November 2006 15:19, Igor Novikov wrote:
> > GTK migration wasn't a main fork cause.
>
> I have chatted a bit with Bernhard (Herzog) and my idea was:
> Why not join forces on a tcl/tk based Skencil1/sK1 development?
> Bernhard's initial reaction was quite positive.
>
> The main common interest is that Skencil has been not seen
> much development in the last years and applications like inkscape
> have drawn more attention from the users and developers community.
> The stability and design of the Skencil tcl/tk version shows that
> there is a place for such an application and the GTK port has never
> reached a usable state.
> Skencil/sK1 is still a strong application,
> so joining forces would help to grow the community.
> Packaging and documentation efforts would be reduced and all this.
>
> We can offer a development plattform based on a free software (gforge),
> hosted by Intevation with trackers, svn. mailinglists and more.
> See https://wald.intevation.org/projects/skencil
>
> Personally I am quite open regarding the name, maybe sK1 would even
> be the better one, given that it resembles Skencil1 closely enough.
>
> > In 2003 before Orange Revolution
> > Microsoft initiated in Ukraine hard software legacy inspections across
> > printing firms and we were forced quickly migrate on Linux. Sketch
> > 0.6.15was selected as a most useful software to substitute CorelDRAW
> > (ai and cmx
> > import was a most impotant point). The codebase was slightly extended
> > (resize, rotate, move dialogs etc.). User interface was adopted to usual
> > Corel layout: http://sk1.sf.net/screenshots/sk1.png
>
> We have wondered why the fork has happened in the first place without
> some more communication from your side.
> As Bernhard H. was open for more patches and
> to consider the development strategy as well.
> The changes up to 0.6.17 (and the upcoming 0.6.18) should be interesting
> for your as well.
>
> So what do you think about the general idea?
>
> Best Regards,
> Bernhard (R.)
>
> --
> Managing Director - Owner, www.intevation.net       (Free Software
> Company)
> Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free
> Software)
> www.kolab-konsortium.com   (Email/Groupware Solution, Professional
> Service)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/skencil-devel/attachments/20061120/7ac14adc/attachment.htm