Re: [Kde-bindings] Pre-approved Languages

2008-05-01 Thread Richard Dale
On Wednesday 30 April 2008 08:42:31 Cyrille Berger wrote:
 Forwarding to kde-bindings, since they are the people who know better about
 this.

 On Wednesday 30 April 2008, Allen Winter wrote:
  On Tuesday 29 April 2008 18:34:29 Aaron J. Seigo wrote:
   of course, if bindings ever get made for another module we're going to
   be in this same boat again aren't we? i wonder if later on it might
   make sense to split up kdebindings into modules that reflect the KDE/
   modules ... so kdebindings-libs, kdebindings-base, kdebindings-pim ...
  
   i assume this would be a major pain for the bindings teams, but would
   it be feasible? if so, when would be a realistic time frame for such a
   modification?
 
  Or, maybe each current module can have a bindings subdir?
  i.e. kdelibs/bindings, kdebase/bindings, kdepimlibs/bindings, ...?
The second suggestion seems sensible to me, with subdirs for each language 
like kdelibs/bindings/python etc. Having a whole new set of modules in 
parallel with the existing libs just seems to complicate things. But I don't 
know enough about this discussion to know what problem we're trying to solve.

-- Richard

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: [Kde-bindings] Pre-approved Languages

2008-05-01 Thread Cyrille Berger
On Wednesday 30 April 2008, Richard Dale wrote:
  On Wednesday 30 April 2008, Allen Winter wrote:
   On Tuesday 29 April 2008 18:34:29 Aaron J. Seigo wrote:
of course, if bindings ever get made for another module we're going
to be in this same boat again aren't we? i wonder if later on it
might make sense to split up kdebindings into modules that reflect
the KDE/ modules ... so kdebindings-libs, kdebindings-base,
kdebindings-pim ...
   
i assume this would be a major pain for the bindings teams, but would
it be feasible? if so, when would be a realistic time frame for such
a modification?
  
   Or, maybe each current module can have a bindings subdir?
   i.e. kdelibs/bindings, kdebase/bindings, kdepimlibs/bindings, ...?

 The second suggestion seems sensible to me, with subdirs for each language
 like kdelibs/bindings/python etc. Having a whole new set of modules in
 parallel with the existing libs just seems to complicate things. But I
 don't know enough about this discussion to know what problem we're trying
 to solve.
The problem is circular dependencies. A python applet was introduced in 
kdebase, which means kdebase depends on kdebindings while kdebindings depends 
on kdebase. The issue was solved by moving the python applet to kdeutils, but 
the problem might happen again in the future.

-- 
Cyrille Berger
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Pre-approved Languages

2008-04-29 Thread Allen Winter
On Tuesday 29 April 2008 13:08:43 Jonathan Riddell wrote:
 On Tue, Apr 29, 2008 at 06:48:01PM +0200, Dirk Mueller wrote:
  On Sunday 30 March 2008, Allen Winter wrote:
   So we seem to have reached consensus on a policy (enclosed below).
 
  was the dependency issue discussed anywhere? I'm 17700 mails behind, so
  sorry about beating a dead horse, but I've just seen a python kde app
  appearing in kdebase/workspace, which is a dependency of kdebindings
  (where python kde is built). I don't think thats a great thing to do.

 Dirk said on kde-commits:
  this is a dependency loop (kdebase/workspace needed before
  kdebindings, kdebindings needed before printer-applet). any reason
  this cannot be in an addon module, like kdeutils? or kdeadmin?

 It's not something I noticed until after I put it in.  It's in
 kdebase because that's where the old one was and in /workspace because
 that's the X11 specific stuff.  I added a cmake variable that can be
 set to stop it needing pykde at build time.  But it can be moved to
 kdeutils if people prefer.


Ah, I didn't know that kdebindings had to be built after kdebase/workspace.

So, the build order is
kdesupport - kdelibs - kdepimlibs - kdebase - kdebindings - everything 
else??

If the above is true, then yes, we definitely need to move printer-applet
to either kdeutils or kdeadmin.  Either one seems ok with me..

-Allen

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Pre-approved Languages

2008-04-29 Thread Aaron J. Seigo
On Tuesday 29 April 2008, Cyrille Berger wrote:
 On Tuesday 29 April 2008, Allen Winter wrote:
   It's not something I noticed until after I put it in.  It's in
   kdebase because that's where the old one was and in /workspace because
   that's the X11 specific stuff.  I added a cmake variable that can be
   set to stop it needing pykde at build time.  But it can be moved to
   kdeutils if people prefer.
 
  Ah, I didn't know that kdebindings had to be built after
  kdebase/workspace.
 
  So, the build order is
  kdesupport - kdelibs - kdepimlibs - kdebase - kdebindings -
  everything else??
 
  If the above is true, then yes, we definitely need to move printer-applet
  to either kdeutils or kdeadmin.  Either one seems ok with me..

 Well currently kdebindings depends on kdebase, for the plasma ruby
 bindings... So indeed there is a problem :/

i'd vote for kdeadmin personally, since it seems to be more of an admin sort 
of thing?

of course, if bindings ever get made for another module we're going to be in 
this same boat again aren't we? i wonder if later on it might make sense to 
split up kdebindings into modules that reflect the KDE/ modules ... so 
kdebindings-libs, kdebindings-base, kdebindings-pim ... 

i assume this would be a major pain for the bindings teams, but would it be 
feasible? if so, when would be a realistic time frame for such a 
modification?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech


signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Pre-approved Languages

2008-04-29 Thread Allen Winter
On Tuesday 29 April 2008 18:34:29 Aaron J. Seigo wrote:
 On Tuesday 29 April 2008, Cyrille Berger wrote:
  On Tuesday 29 April 2008, Allen Winter wrote:
It's not something I noticed until after I put it in.  It's in
kdebase because that's where the old one was and in /workspace
because that's the X11 specific stuff.  I added a cmake variable that
can be set to stop it needing pykde at build time.  But it can be
moved to kdeutils if people prefer.
  
   Ah, I didn't know that kdebindings had to be built after
   kdebase/workspace.
  
   So, the build order is
   kdesupport - kdelibs - kdepimlibs - kdebase - kdebindings -
   everything else??
  
   If the above is true, then yes, we definitely need to move
   printer-applet to either kdeutils or kdeadmin.  Either one seems ok
   with me..
 
  Well currently kdebindings depends on kdebase, for the plasma ruby
  bindings... So indeed there is a problem :/

 i'd vote for kdeadmin personally, since it seems to be more of an admin
 sort of thing?

 of course, if bindings ever get made for another module we're going to be
 in this same boat again aren't we? i wonder if later on it might make sense
 to split up kdebindings into modules that reflect the KDE/ modules ... so
 kdebindings-libs, kdebindings-base, kdebindings-pim ...

 i assume this would be a major pain for the bindings teams, but would it be
 feasible? if so, when would be a realistic time frame for such a
 modification?

Or, maybe each current module can have a bindings subdir?
i.e. kdelibs/bindings, kdebase/bindings, kdepimlibs/bindings, ...?


___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Pre-approved Languages

2008-03-31 Thread Riccardo Iaconelli
On Monday 31 March 2008 13:03:20 Stephan Kulow wrote:
 The corporate world should have applications in the core of KDE?
 I don't think so.

Maybe not corporate world, but corporate programmers for sure. =)
AFAIK Java has good bindings, too... and I don't see it harming KDE in any 
ways.

So here goes my +1 for python, ruby and java.

-Riccardo
-- 
GPG key:
3D0F6376
When encrypting, please encrypt also for this subkey:
9EBD7FE1
-
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Pre-approved Languages

2008-03-30 Thread Allen Winter
Howdy,

So we seem to have reached consensus on a policy (enclosed below).

Now I think we should take on the task of pre-approving a couple
of non-C++ languages,  thereby giving the green light to anyone
thinking about using one of them = Chicken Lays Egg.

Nominations anyone?

We really need input from the kdebindings folks in order to
judge how well the nominated language meets requirement #3.


-- KDE Programming Languages Policy --
1) must be an open, free language that meets our licensing requirements
2) must be a mature, high quality language with a large, vibrant
support community and a long expected lifespan.
3) must have mature, high quality KDE bindings available
4) must be mature and operational on all our target platforms
5) must be able to provide full translations and internationalizations

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Pre-approved Languages

2008-03-30 Thread Andreas Pakulat
On 30.03.08 08:19:33, Allen Winter wrote:
 Howdy,
 
 So we seem to have reached consensus on a policy (enclosed below).
 
 Now I think we should take on the task of pre-approving a couple
 of non-C++ languages,  thereby giving the green light to anyone
 thinking about using one of them = Chicken Lays Egg.
 
 Nominations anyone?

I'm not a kdebindings person, but I did try both korundum (ruby) and
I know PyQt/PyKDE for quite some time.

Both have one drawback:

- PyQt/PyKDE are both mostly developed in private repositories of one
  person (well, one for each), which means that fixes sometimes take a
  bit longer and (especially PyQt4) don't follow our release cycles
- Korundum4 lacks documentation and examples (the latter exist, but are
  still for KDE3 version)

But even though both bindings are in quite good shape - AFAIK and both
languages should be pre-approved.

Andreas

-- 
Blow it out your ear.


signature.asc
Description: Digital signature
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Pre-approved Languages

2008-03-30 Thread Andreas Pakulat
On 30.03.08 17:35:54, Simon Edwards wrote:
 Andreas Pakulat wrote:
  On 30.03.08 08:19:33, Allen Winter wrote:
  I'm not a kdebindings person, but I did try both korundum (ruby) and
  I know PyQt/PyKDE for quite some time.
  
  Both have one drawback:
  - PyQt/PyKDE are both mostly developed in private repositories of one
person (well, one for each), which means that fixes sometimes take a
bit longer and (especially PyQt4) don't follow our release cycles
  But even though both bindings are in quite good shape - AFAIK and both
  languages should be pre-approved.
 
 That is not entirely accurate. PyQt is developed privately at Riverbank 
 Computing and snapshots are regularly made available. (It looks like 
 Phil is publishing nightly snapshots).

Thats not something KDE can reliably depend on, because those are not
added to distributions. 

 When a new version of Qt is released, the updated PyQt release quickly
 follows in general. Usually long before the next release of KDE which
 requires the new Qt.  Phil has always been responsive to bug reports
 in my experience.

Maybe my memory is wrong, but I think the PyQt4.1 and PyQt4.2 versions
came out quite some time after the relevant Qt release. And right now I
can't try out PyQt4/PyKDE4 because there's no version that I can compile
as I don't have space for a KDE 4.0 checkout on disk.

 PyKDE is split between Jim Bublitz and myself. Jim is the main PyKDE guy 
 who does most of the big changes and tooling work for generating the 
 bindings. Jim's time and bandwidth is limited which makes it hard for 
 him to track SVN trunk. This is where I step in and manage PyKDE in 
 kdebindings and integrating Jim's work into SVN. I also do maintenance 
 work on PyKDE and update the bindings to track SVN (which I did leading 
 up to 4.0). Jim has been sharing his knowledge with me to help increase 
 PyKDE's bus factor[1].

Yes, but then Jim has to integrate those changes back into his private
repo and thats going back and forth. Its as far as I can see not a big
deal and yes both of you and also Phil are really responsive to
bugreports on the mailinglists. Still its a small drawback when
comparing that to the ruby bindings. OTOH you've got the better docs and
examples I think ;)

 PyQt and PyKDE have been around for bit a long time already and are 
 highly mature.

No doubt about that. I never intended to say that python is not a good
choice, however re-reading my last sentence I see that its quite a bit
cryptic (probably due to me having learnt german as first language ;).

Andreas

-- 
Today's weirdness is tomorrow's reason why.
-- Hunter S. Thompson
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Pre-approved Languages

2008-03-30 Thread Aaron J. Seigo
On Sunday 30 March 2008, Andreas Pakulat wrote:
 But even though both bindings are in quite good shape - AFAIK and both
 languages should be pre-approved.

+1 for python and ruby.

the fact that they've been around for some years now and apps built with them 
work well gives me enough confidence to have included-with-KDE-releases apps 
rely on them.

i agree with Andreas that there is room for improvement on both sets of 
bindings. i think these improvement will happen quicker if they actually get 
used more, just like how our libs improve much more rapidly and in useful 
directions when they get real world use.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech


signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Pre-approved Languages

2008-03-30 Thread Allen Winter
On Sunday 30 March 2008 15:11:55 Aaron J. Seigo wrote:
 On Sunday 30 March 2008, Andreas Pakulat wrote:
  But even though both bindings are in quite good shape - AFAIK and both
  languages should be pre-approved.

 +1 for python and ruby.


+1 for python and ruby

+1 for perl, when the bindings come along




___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Pre-approved Languages

2008-03-30 Thread Nicolas Ternisien
+1 for PHP ... h in fact no ;-)

But agree with Python and Ruby, and why not Perl (no experience on it)

On Sun, Mar 30, 2008 at 11:11 PM, Allen Winter [EMAIL PROTECTED] wrote:
 On Sunday 30 March 2008 15:11:55 Aaron J. Seigo wrote:
   On Sunday 30 March 2008, Andreas Pakulat wrote:
But even though both bindings are in quite good shape - AFAIK and both
languages should be pre-approved.
  
   +1 for python and ruby.
  

  +1 for python and ruby

  +1 for perl, when the bindings come along






  ___
  release-team mailing list
  release-team@kde.org
  https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team