[reportlab-users] Visual editor: Licenses

[will at phototropia.org]

Friends:
     We have used pyqt and it works really well.  It is fast to develop
in, and where the documentation is weak, qt is well documented.  If
the only issue is functionlality, pyqt will be fine. We are in the
process of changing over to pygtk because of the below issues. 
However, if you chose either pyqt or pygtk, I'm in, and it might sway
us to stay with pyqt generally as it's tough to walk away from
something that works.
     We just looked through the code of Skencil(once Sketch) that uses
pdfgen while planning the move to pygtk.  From looking at that, and
the slightly increased documentation for pygtk, I think it would work
fine for  what you want to do as well.  However, pygtk has added alot
of functionality since 2.0, and if it was used, you would have to
make larger decisions about how the app. is set up, and which
functionality is used.
     As for wxpython, that would be a labor issue.  As mentioned I think
by someone else, the documentation just isn't there for wxpython. 
However, so many python coders like it so, if one stepped up with
this familiarity, maybe that would be best.

Will

> I think there's one more issue before going with PyQT.  We've never had
> a flame war yet on this list but who knows, maybe this will start one :-)
>
> It is available under a GPL and a commercial license.  This is
> very different to the ReportLab library so far.  So a PyQT GUI would
> have to be very carefully separated from our library itself to
> avoid 'GPL infection'.
>
> GPL has turned out to be quite 'good for business' for TrollTech,
> BerkeleyDB  and MySQL.  This is because anyone who wants to embed it in
> a closed source product has to negotiate a license - and enough people
> want to use databases and GUI toolkits in their apps.  Other companies
> giving stuff away more liberally have often struggled and ended up
> as little more than support operations.
>
> So, one possibility is that we start a new 'reportlab2' package
> under GPL, with a graphical designer to go with it; and that we could
> then release more of our proprietary software like elements
> of RML and PageCatcher, offering much higher productivity.  This would
> provide an open source document framework which was easy to use, and
> easy to embed.  A market for embedding would incentivize us strongly to
> produce a packaged, easy-to-deploy library edition, rather than our
> current focus on enterprise solutions which tends to leave open source
> features undocumented :-(.  And if it did well then anyone maintaining a
> graphical editor would have a route to sell that too and thus to invest
> more time in it; I know of several specialist areas where it could be
> customised easily for a vertical market.
>
> On the other hand, this is not the way major Python libraries have
> worked in the past.  I have long liked the ability to just use code
> anywhere.
>
> How would people feel if the existing code base stayed available as it
> was, but a new version came out under GPL with a lot more functionality?
>
> I cannot promise this is likely, and it wouldn't be a community
> decision, but it would be interesting to get peoples' reactions...
>
> Best Regards,
>
>
> Andy Robinson
> CEO/Chief Architect
> ReportLab Europe Ltd.
>
>
>
>
>
>
>
>
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
>