[PyKDE] drag'n drop in pykless.

[Jim Bublitz]

On 23-Aug-02 Richard Jones wrote:
> On Fri, 23 Aug 2002 3:42 pm, Jim Bublitz wrote:
>> On 22-Aug-02 Richard Jones wrote:
>> > On Fri, 23 Aug 2002 12:52 am, Jim Bublitz wrote:
>> >> Thanks for the input! I'm just about to write another message
>> >> to
>> >> the list announcing the next release and apologizing for the
>> >> quality of the stuff in examples/ and test/. I hope to have
>> >> this
>> >> stuff cleaned up and a number of additions by the next major
>> >> KDE
>> >> release (3.1), probably later this fall.

>> > Is there any chance of this stuff making it into the actual
>> > KDE CVS, and hence KDE releases? That would be sweet, and
>> > given that there's (minimal) python support already in
>> > there, it seems logical to me. That would enable a _lot_ 
>> > more users to hack up KDE applications who otherwise
>> > haven't heard of PyKDE (*shock*, but I'm sure they exist :)

>> The short answer is that doesn't work very well for me (can't
>> speak for Phil, and he owns sip and PyQt which are also
>> required, and still has rights to big chunks of PyKDE). I can
>> provide the long answer (I'm still trying to quit smoking) if
>> you're interested.
 
> You realise that your brain is subconsciously relating discussing
> PyKDE and a lack of nicotene, don't you :)

That and I cut way back on caffeine/sugar, so I'm really desperate.
I'm amazed I can still code (no cheap shots, please).
 
>> I don't necessarily think this is a bad idea - especially being
>> on the KDE ftp sites. CVS is what I have problems with, and
>> it's unlikely that PyKDE will ever keep up with the KDE release
>> schedule while I'm maintaining it. My understanding is you
>> only get KDE ftp if you use KDE CVS.
 
> I presume the CVS issue is due to a lack of control? Guidelines
> may be written (even if they say "oi, it's under my control!"
> and that's all) and if it all goes awry, they end up with a
> half-finished fork version :)

Yeah, that's part of it. Synchronization with KDE releases is
another problem - it'd need to be on more of a KOffice-like
schedule decoupled from the KDE releases - which defeats some of
what you want to accomplish; maintaining CVS is another problem -
I'm not very good at it, it's really slow, and the way PyKDE gets
developed doesn't make CVS useful for anything. My uplink is really
slow (satellite - d/l's at >100KB/s though) - right now I mail
releases, which is even slower but happens transparently via the
mail server. There might be concerns about the way PyKDE builds - I
don't want to go back to autoconfig, etc. Patch releases are another
concern, lack of adequete testing is another.

This also needs Phil's input, since sip and PyQt are pre-requisite
to PyKDE. I hate it when projects have half the libs you need and
you have to go out and search for the other half (KDE has done some
of that over the years, but seems better now). riverbankcomputing
offers "one-stop" shopping. I haven't discussed it with Phil, but I
suspect he has some legitimate concerns/objections as well.

The bottom line is that I can't guarantee delivery on schedule,
don't want to spend the extra time/work, can't promise a complete
package, and don't want to deal with (perhaps imaginary) additional
restrictions and politics. If someone else wants to pursue it
though, I'm willing to assist with the understanding that I don't
plan to change the things I do much from the way I do them now. 
 
>> If there's really a lot of interest in this, the way to make it
>> happen is to have someone fork PyKDE development and work out a
>> deal with KDE.
> 
> I personally can't stand programming in Java, let alone the
> horror (to me)  that is C++ :) ... if I could just start
> plugging away at KDE/Qt apps right there using my KDE install.
> Wow. And I'm going to make a wild, unfounded statement -- I'm
> sure there's other people out there who are in a similar frame
> of mind :)

If there aren't already there should be IMHO. I think the other
thing that impacts this is having available some better examples,
templates for getting started, and similar things, so I intend to
work on some of that in the near future.
 
>> I'll be happy to provide assistance. This isn't some
>> "I'll take my ball and go home" - I personally am not
>> comfortable with putting PyKDE on KDE's CVS, but I am
>> comfortable with forking the project.

> Perhaps it'd be enough for you to import the latest "stable"
> version of PyKDE into their CVS?

That's always somewhat of a moving target :)

I think that might be workable, but don't know how the KDE people
would feel about. 


Jim