Hi,<br><br>First post etc.<br><br>I started playing with Trellis in order to use it for managing GUI events, but I don't use it at all presently. I like to follow the mailing list though, since its an interesting library and in sync with my own views as how programs should be composed.<br>
<br>I am considering using Trellis as the glue layer between the main application (which will be mostly non-Python) and a plugin system (which will be pure Python) of my current project.<br><br>Probably not much use to you. ;-) I am pleased to see people are interested in maintaining this library though!<br>
<br>Dan.<br><br><div class="gmail_quote">2009/6/12 Sergey Schetinin <span dir="ltr"><<a href="mailto:maluke@gmail.com">maluke@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
I was thinking about it for months, but I think it's time to fork<br>
Trellis -- Phillip is busy with other things and I don't want to<br>
bother him with endless requests. Trellis the way it is now is a great<br>
start but it could use a lot more work -- I'm willing to put that work<br>
in and I think Andrew Svetlov would participate as well.<br>
<br>
I'm about to launch a number of projects into production and I want to<br>
make sure all of the dependencies are well maintained -- for Trellis<br>
that seems to mean it needs forking. I also think Trellis needs more<br>
that just bugfixing, so I'm not sure if there's way not to fork it.<br>
Well, maybe except for taking over it completely, but it's unlikely<br>
anyone would want that and I still want to see where Phillip want to<br>
take Trellis himself -- clearly I can't pretend I'm as good as he is.<br>
<br>
To avoid conflicts I'd change the import names to<br>
<br>
from trellis import *<br>
from trellis.activity import *<br>
<br>
etc.<br>
<br>
Some things I think I'll do right away after forking:<br>
* apply the bugfixes I've sent before<br>
* drop py2.3 support<br>
* add more comments to source code to make it easier to understand<br>
for people just learning the system (and when coming back to it after<br>
a while), I'd also rewrite some parts for clarity but without<br>
compromising performance.<br>
* add some more practical examples<br>
* reorganize source code:<br>
* comment out some classes not reported to be used in actual<br>
projects: testing is good but not enough.<br>
* add utility modules, for example wx utilities (WXEventLoop would<br>
move there as well)<br>
* reorganize test suite<br>
<br>
There's plenty more, but that's enough for a start I think.<br>
<br>
So my questions are:<br>
* any reasons I shouldn't do this?<br>
* is "trellis" as package name ok? (it would be trellis-fork on pypi<br>
and similar)<br>
* can this mailing list be used for discussion of this fork?<br>
<br>
<br>
I also wonder how many users Trellis has. If you use it, please say a<br>
few words about your project at least if it's in a hobby / academia /<br>
business software / other class. Thanks.<br>
<br>
I use it for GUI in end-user software and async networking on the server.<br>
<br>
<br>
<br>
<br>
--<br>
Best Regards,<br>
Sergey Schetinin<br>
<br>
<a href="http://s3bk.com/" target="_blank">http://s3bk.com/</a> -- S3 Backup<br>
<a href="http://word-to-html.com/" target="_blank">http://word-to-html.com/</a> -- Word to HTML Converter<br>
_______________________________________________<br>
PEAK mailing list<br>
<a href="mailto:PEAK@eby-sarna.com">PEAK@eby-sarna.com</a><br>
<a href="http://www.eby-sarna.com/mailman/listinfo/peak" target="_blank">http://www.eby-sarna.com/mailman/listinfo/peak</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Daniel Kersten.<br>Leveraging dynamic paradigms since the synergies of 1985.<br>