Discussion:
[pyxpcom] Why isn't everyone in the Python world using this?
Rasjid Wilcox
2009-02-22 09:27:45 UTC
Permalink
This is a serious question. Why isn't everyone in the Python world
using this stuff? There should be hoards of people here. XUL / pyDOM
is so much better than wxPython, it is just not funny. This stuff is
jaw dropping amazing.

I had been playing with it in spare moments for a couple of months,
but after using it for one week in earnest, I don't ever what to go
back to anything else. And combining this with SqlAlchemy gives a
killer platform for database development. I just need to find (or
create in XBL) a good data-grid control [1].

And then there is pyXPCOM - allowing you to hook into Java, Perl, Ruby
etc. So if there is a better library in Java than Python for a
particular task, I can use the Java one, and still have all the python
and XUL goodness for everything else.

Oh, and of course, it is all cross platform. Windows, Linux, Mac.

I feel like all my programming dreams have come true. I am completely
overwhelmed.

Rasjid.

[1] And then find the best way of getting at these from Python. Okay,
not a completely trivial task, but not too huge either.
Philip Semanchuk
2009-02-22 15:20:25 UTC
Permalink
Post by Rasjid Wilcox
This is a serious question. Why isn't everyone in the Python world
using this stuff? There should be hoards of people here. XUL / pyDOM
is so much better than wxPython, it is just not funny. This stuff is
jaw dropping amazing.
Hi Rasjid,
I think PyXPCOM suffers foremost from a lack of critical mass. In
other words, not enough developers use it. As a result, bugs don't get
discovered and fixed as fast as they might, community support is weak,
the documentation has holes, etc. Don't get me wrong; I don't mean to
imply indifference or laziness on the part of any of the developers or
the community. All open source projects suffer from the things I
mentioned above to some extent. But the most popular projects usually
suffer the least.

Lack of critical mass is a chicken-and-egg problem. Do people not use
it because they try it and don't like it, or do they not know about
it, or do they avoid it because the well-traveled road is often the
least risky if not always the most comfortable? I don't know the
answer here.

I like PyXPCOM and felt it was powerful once I got things assembled
correctly. But I can think of a few off-putting experiences that I had.

On the project in which I was involved, we spent a fair amount of time
developing an install that would work within an OS X Framework bundle.
After we got that done, we had to work on Windows. Neither was
trivial. That was a frustrating point. Every minute we spent doing
that was a minute spent *not* developing our app.

Our install was going to be a huge heavy thing, bundling a large chunk
of Mozilla and a complete Python alongside PyXPCOM.

Components can't be new-style classes (i.e. inherit from object). This
isn't a show-stopper, but it is annoying. It's also not that easy to
discover as the related errors are cryptic. I burned some time
debugging that.

I haven't used wxPython TkInter, PyJamas, PyQt, etc. and they might
have similar quirks. They are probably (except for perhaps PyJamas)
better supported, and once again I mean that as no knock on the
PyXPCOM developers & community. It's just a matter of popularity.

I wish you the best and hope you write the killer app that makes
everyone notice PyXPCOM. It'd be nice to see it get more traction and
build a big user base.
Post by Rasjid Wilcox
I had been playing with it in spare moments for a couple of months,
but after using it for one week in earnest, I don't ever what to go
back to anything else. And combining this with SqlAlchemy gives a
killer platform for database development. I just need to find (or
create in XBL) a good data-grid control [1].
Check out the treeview control.



Cheers
Philip
Rasjid Wilcox
2009-02-22 21:42:40 UTC
Permalink
Post by Philip Semanchuk
I think PyXPCOM suffers foremost from a lack of critical mass. In
other words, not enough developers use it. As a result, bugs don't get
discovered and fixed as fast as they might, community support is weak,
the documentation has holes, etc. Don't get me wrong; I don't mean to
imply indifference or laziness on the part of any of the developers or
the community. All open source projects suffer from the things I
mentioned above to some extent. But the most popular projects usually
suffer the least.
Lack of critical mass is a chicken-and-egg problem. Do people not use
it because they try it and don't like it, or do they not know about
it, or do they avoid it because the well-traveled road is often the
least risky if not always the most comfortable? I don't know the
answer here.
Yes, I do understand that. With wxPython (for example) you have the
comfort that there are dozens or even hundreds of python programmers
using it so if you get stuck you have lots of people to turn to.
There are at least 5 posts to the wxPython list every day, and
sometimes quite a bit more. There is sometimes less than 5 in a month
here, although I guess many questions get asked elsewhere (like
mozilla.dev.platform etc) if they are not particularly python
specific.

<snip>
Post by Philip Semanchuk
Components can't be new-style classes (i.e. inherit from object). This
isn't a show-stopper, but it is annoying. It's also not that easy to
discover as the related errors are cryptic. I burned some time
debugging that.
Is that still the case? I admit that my testing of xpcom objects has
been limited (not much more than hello world with a couple of extra
methods), but I've been using 'object' classes and they seem to work
fine.
Post by Philip Semanchuk
I haven't used wxPython TkInter, PyJamas, PyQt, etc. and they might
have similar quirks. They are probably (except for perhaps PyJamas)
better supported, and once again I mean that as no knock on the
PyXPCOM developers & community. It's just a matter of popularity.
I wish you the best and hope you write the killer app that makes
everyone notice PyXPCOM. It'd be nice to see it get more traction and
build a big user base.
Thanks for the encouragement. :-)
Post by Philip Semanchuk
Post by Rasjid Wilcox
And combining this with SqlAlchemy gives a
killer platform for database development. I just need to find (or
create in XBL) a good data-grid control [1].
Check out the treeview control.
Yes, I've looked at the treeview control. Great for viewing data, but
I could not get it to behave anything close to like I wanted for data
entry. Maybe there is a way that I have not found yet - it is still
early days.

Cheers,

Rasjid.
Shane Caraveo
2009-02-22 22:42:47 UTC
Permalink
Post by Rasjid Wilcox
<snip>
Post by Philip Semanchuk
Components can't be new-style classes (i.e. inherit from object). This
isn't a show-stopper, but it is annoying. It's also not that easy to
discover as the related errors are cryptic. I burned some time
debugging that.
Is that still the case? I admit that my testing of xpcom objects has
been limited (not much more than hello world with a couple of extra
methods), but I've been using 'object' classes and they seem to work
fine.
We have patches for that already, I'm not certain if (but believe they
are) they are in pyxpcomext. I also did a bunch of work on the pyxpcom
exception object a while back that makes cross-language exception
reporting a bit better.
Post by Rasjid Wilcox
Post by Philip Semanchuk
Post by Rasjid Wilcox
And combining this with SqlAlchemy gives a
killer platform for database development. I just need to find (or
create in XBL) a good data-grid control [1].
Check out the treeview control.
Yes, I've looked at the treeview control. Great for viewing data, but
I could not get it to behave anything close to like I wanted for data
entry. Maybe there is a way that I have not found yet - it is still
early days.
There may be a grid somewhere in some application, but otherwise you'd
probably want to build it in xbl using the richlistbox element.

Regards,
Shane
Alek Puanov
2009-02-26 11:35:13 UTC
Permalink
Hi Philip, Hi Rasjid,

There are already at least one killer PyXPCOM application with open
source: Komodo Edit. We, the rest of the public here, just are too lazy
or too busy to roll things forward. Personally, I am living with plans
to start work for quality data editing client from exactly 3 years.

@Rasjid:

Like Philip, I am also thinking that right way to building efficient
databound control for mozilla is to use xul:tree visualizing sqlite
datacache (client side recordsets):

1) sqlite recordsets: query to DB (or Data service in general) and
store resulting recordsets in sqlite table(s). Additionally, make
mechanism for additional "live" querying during pagination/searching for
filling the cache tables on demand, for data sources which can support
this efficient (live) mode of operation (which support offset/page and
search queries).

2) Create additional "live" (added and/or appended on demand) tables
for different (at least main) row orders, because custom view mode of
xul:tree (which must be used) queries implementation with absolute row
index like (1,2,3 or 23456) (for first tests you may skip this, using
sqlite offset selects)

3) treeview haven't editing, but it is enough to stack xul:tree with
flaying "editing carets" (like divs with higher z-index in html) for
different editor types (combo boxes, date/number text fields, etc ...).
Believe me - stack approach (editing caret over base view "canvas")
for data editing, gives you many more possibilities, than out of the box
scoped MS Access datasheet for example. (By the way, list part of combo
box of course can also be realized with xul:tree with same databinding
mechanism as datagrid).

For all work that need to be done for datagrid, there are also tons of
reference source around - sqlite manager extension [1], modern ajax
frameworks (for cell editors implementation), etc ...

By the way, datagrid and data bound combo-box are not enough to assemble
high quality data interfaces - that is the just MS Access level, other
mandatory "library" (not application specific) components include:
inter-control mutual data binding/synchronization, drill-down report
component, and a number of other small things, but anyway, I also think
that easiest platform to achieve this level is exactly Mozilla/PyXCPOM.

Rasjid (and other data-centric people here), if you are going to start
something in direction of data bound controls on top of the XUL/PyXPCOM
you can place your work at Bitbucket [2] or some of other DVCS services
and I (probably not only) will at least following your work.

Cheers,
Alek

[1] http://code.google.com/p/sqlite-manager/
[2] http://bitbucket.org/. GitHub is great also of course, but Mercurial
is more appropriate for Mozilla/Python related list and effort, doesn't
it :-)

Please forgive me the pain from my English :-)
Post by Philip Semanchuk
I wish you the best and hope you write the killer app that makes
everyone notice PyXPCOM. It'd be nice to see it get more traction and
build a big user base.
Lauri Kainulainen
2009-03-03 07:58:46 UTC
Permalink
Hi all,
Post by Rasjid Wilcox
This is a serious question. Why isn't everyone in the Python world
using this stuff? There should be hoards of people here. XUL / pyDOM
is so much better than wxPython, it is just not funny. This stuff is
jaw dropping amazing.
I just want to share my experiences as well. We've used
XULRunner+PyXPCOM here in an art school research group context to build
a collaboration platform that has heavy emphasis on video content. We've
been using this technology for a year now and we have a few months left
on the project.

I have to say that I'm still happy with the choice on XULRunner +
PyXPCOM: it let's us do CSS, JS, XUL/XHTML - very inclusive technologies
in a group where nobody has an engineering background, and allows the
use of Python for backend work while keeping it all cross-platform.

There is however a weak point and that is multimedia. Surely we can use
flash or whatever video players that have mozilla plugins available
(currently the only viable alternative is VLC), but they really don't
cut it and developing one's own requires C/C++ work (please correct me
if I'm wrong!).

Oh how I dream of a day when I could just grab my old rusty gstreamer
python tools and make them work easily inside XULRunner. Now that would
be cool! If embedding other stuff would be that easy... then we'd surely
have a killer platform on our hands :)

Anyhow, big, big thanks to all the people who work on these technologies
and especially those who've helped me while I've struggled with the
first steps of getting XULRunner+Python working together!



Cheers,
Lauri
--
Lauri Kainulainen
..:: Tech.lead/P2P-Fusion/TAIK
Mark Hammond
2009-02-23 12:48:46 UTC
Permalink
Post by Rasjid Wilcox
This is a serious question. Why isn't everyone in the Python world
using this stuff? There should be hoards of people here.
That's exactly what I keep thinking :) As Philip mentioned, it would seem
too many eggs, not enough chickens.

Or-was-that-too-many-chickens-not-enough-eggs...

Mark
Loading...