<br><br><div class="gmail_quote">On Mon, Sep 27, 2010 at 1:36 PM, Bernhard Herzog <span dir="ltr"><<a href="mailto:bh@intevation.de" target="_blank">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>On 22.09.2010, Igor Novikov wrote:<br>
> On Wed, Sep 22, 2010 at 4:17 PM, Bernhard Herzog <<a href="mailto:bh@intevation.de" target="_blank">bh@intevation.de</a>> wrote:<br>
> > Igor Novikov <<a href="mailto:igor.e.novikov@gmail.com" target="_blank">igor.e.novikov@gmail.com</a>> writes:<br>
</div><div>> > > 4. Root "skencil" package is introduced<br>
> ><br>
> > What will that mean for Skencil users? Will their startup-scripts and<br>
> > third-party scripts and plugins still work?<br>
><br>
> Internal application structure is not changed. So all scripts and plugins<br>
> will be workable.<br>
<br>
</div>The way it has been implemented will likely lead to subtle bugs or strange<br>
exceptions later on. You can now import the Skencil modules using two<br>
different absolute module names. E.g. skencil.Sketch.UI.mainwindow and<br>
Sketch.UI.mainwindow will now be different modules imported from the same<br>
python file. If both names are used in the same problem it's likely to cause<br>
problems.<br></blockquote><div><br>Distutils build supposes that installed python application/library contains one or several <br>python packages. Skencil structure has following folders:<br><br>Lib<br>Plugins<br>Resources<br>
Script<br>Sketch<br><br>I think it's not a good idea to introduce such python packages due to possible clashes.<br>Therefore internal Skencil structure was wrapped as a single package with unique 'skencil' name.<br>
Of course all these folders could be moved inside Sketch package but this will lead to serious<br>project refactoring. Also when you import Sketch package __init__.py runs a lot of initializing code<br>including some tricks like creating runtime packages. Such behavior breaks a work of some <br>
python applications. Concerning sK1 we have received notification from package maintainers and<br>therefore we have fixed this issue a long time ago.<br clear="all"><br>Anyway I agree that current Skencil architecture is not perfect. But I don't like refactoring <br>
current branch. I think we have a chance changing this when we will port application on <br>Gtk widgetset because all UI related code should be reimplemented.<br><br>We have start sK1 1.0 branch for Gtk porting and I hope we will remove all the hacks and tricks <br>
in the process of porting on Gtk widgetset. <br><br>But actually a real reason of porting is not a project structure. We have found a lot of tk related <br>problem under Ubuntu. For example, LANG environment variable issue. In Ubuntu the variable<br>
is changed from xxx.UTF8 to xxx.utf8. But tk doesn't support such trick and as a result you<br>can type English letters only in all tk input fields including application canvas. This issue is not important<br>for Skencil because it doesn't support Unicode encoding. But for sK1 this issue is a blocker.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
And why is it
called "src" in the source tree and not "skencil"?</blockquote></div><br>"src" folder is a widely used pattern for project structure. <span id="result_box" class="short_text"><span style="" title="">A quick glance to see where is an application source code.<br>
</span></span>But there is no sense creating "skencil" folder inside src/ because src/ folder will be empty.<br><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>