Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Sunday 30 March 2008, Alexander Dymo wrote: Because everyone here is using the word scripting language that automatically implies somewhat condescending point of view on Python, Ruby and any similar languages. Sorry, in the beginning I couldn't find the good word, but in fact I meant interpreted languages, Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Sun, Mar 30, 2008 at 3:38 AM, Aaron J. Seigo [EMAIL PROTECTED] wrote: I agree with what you have said, Alex. I think getting concerned over the use of the term scripting language is a bit unnecessary, it's just a commonly used term is all. Sure :) I just wanted to stress my point that Ruby and Python deserve to be treated as real languages, not toys or simplified tools to do some tiny stuff. Now, to deal with some of the interesting misconceptions: I completely agree with Aaron here and only would like to add that we care about disk space and dependencies too much IMHO. I think we should think about building great applications. If the app is cool, people will do whatever they need to install it - no matter how much disk space is taken and no matter whether it requires Python or not. Just two examples... Amarok is cool and lots of people use it. Does it matter it comes with Ruby dependency? Of course not, people will just use apt-get install amarok. Mediawiki is also a cool thing that has tons of optional dependencies like php accelerators and tex stuff. Does it matter? Of course not, people still install it even if that takes them to manually compile things. C'mon, people, it's not 1990's. We have tools like apt-get, aptitude, yast and so on to automate installations. Normally the user would just write one line or do one mouse click to install your application. The number and size of dependencies DO NOT matter that much these days. Nobody is forced to configure make make install for each dep anymore. Once again, we'd better concentrate on writing great software. Reusing the code, using existing free software as much as possible is one of the ways to write great software. Why care about dependencies then? Let's let people making distros think about that. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Sun, Mar 30, 2008 at 10:49 AM, Andras Mantia [EMAIL PROTECTED] wrote: Sorry, in the beginning I couldn't find the good word, but in fact I meant interpreted languages, Well, actually I never stress the fact Ruby or Python are interpreted. It doesn't matter. Currently the best implementations of them are interpreters but that can and will change. New Ruby 1.9 comes with a bytecode VM. JRuby is already mature now and they also have Ruby compiler (to Java bytecode). What matters is the languages themselves, not their implementations. Implementations will get better and better over the time (at least that's true for Ruby). But languages already allow _you_ to be a more productive programmer. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Sunday 30 March 2008, Mark Constable wrote: On 2008-03-30 10:38, Aaron J. Seigo wrote: That's true of every single dependency we have in KDE. Hardly anybody bats an eye when we pull in Yet Another Library, so doing so now is really hypocritical. Obviously, the difference is that the current KDE dependencies are mostly C/C++ libraries. Many and varied they may be but they are generally not interpreter environments. this is a largely irrelevant distinction to make. and yes, we already use them in various places, including amarok. Qt/KDE is pure binary code with minimal interpreter dependencies and I, for one, do not want to have to install perl, python, ruby, mono, java (yikes! that's 10Mb + 20Mb + 10Mb + 40Mb + 80Mb) and how ever many other scripting environemnts just to run a basic desktop system. * Dependencies are handled for you when installing from packages, and simply cause items to be skipped when they are not available. So more work is not at issue. The MB outlined above is download bandwidth, installation is 3 to 4 times that size. Then are we talking about python 2.4 or 2.5 or maybe 3.0, ruby 1.8.5 or 1.8.6, perl 5 or 6, and on and on. the python and ruby installs on my system do not take 3-4x that size. in fact, the download sizes you quote there are larger than the size they take on disk here according to rpm. and remember: you probably already have perl and python on your system. why don't you check? Sub $100 hardware and sub 100k modem/mobile links may outnumber 1st world PCs in the coming years your concerns, thankfully, do not meet up with the reality of these systems. as i've repeated a few times now, the current crop of hardware that targets this area is well capable of running python/ruby applications and many of them already come with python installed right now. in fact, the olpc uses python extensively. if today's systems are capable of it, then tomorrow's systems will only be able to do it better. as for the network link issue, that's why these systems come preloaded with the neede software. they aren't going to be downloading and installing kde apps either. they'll come on the disk already installed or on physical media. so the network link thing is pretty irrelevant for the base system. if anything, such languages are *better* for these systems because there are bound to be various hardware and OS sofware variances that make shipping binaries harder. shipping python/ruby apps makes this a non-issue. and C/C++ code is always going to perform better no matter what hardware baseline is considered. well, the always part is arguable, but what's really important is if they perform _well enough_. if the user can't tell, then it doesn't matter. and for many apps, such as guidance, that's pretty obviously the case. * We're not talking about all languages: we're specifically discussing Python. Fine, then setup a well defined kdepython area in the main repos and make sure any dependencies for python apps do not leek outside that area. Then, as a packager, I can easily avoid build, distrib and support time for anything to do with python. No problem. as a kde packager, you don't have to worry about python itself. that's provided by the OS. the only thing i can see if the bindings. and yes, we would actually like packagers to start distributing those as opposed to hiding them from the world. as for distrib and support time, in practice that time approaches 0. again, doing the cost/benefit it's very aparent that the benefits immensely outweigh any costs associated, which are actually pretty minimal. now, if the bindings are too difficult to package, then that is something we could work on. i don't know if that is the case (i would expect not, but you never know), but should be solvable if it actually is. Sure, you are specifically discussing python right now but then it'll be ruby, then... i get the sense you aren't reading my emails. =) i'll repeat myself once more, and then consider this part of the conversation done: it's not a slippery slope into a world of many languages. python and ruby are the obvious candidates as we actually have applications written in both and those are the two languages with actual meaningful interest in the desktop side of the f/oss world. java *may* enter into it, but i doubt it in the f/oss side (in the corporate / proprietary area, it might be different). so this is a strawman argument, please stop raising it as if it were a real issue. -- 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Saturday 29 March 2008, Nicolas Ternisien wrote: Yes, and where did you find your binary Qt 4.4 version to compile KDE 4 ? You compile it too from SVN. Don't get silly. Qt 4.4 IS available in binary form if you want to use it: http://download.opensuse.org/repositories/KDE:/Qt44/openSUSE_10.3/ And qt-copy is in the KDE SVN repository, while the other dependencies are not. If they would be at least mirrored in kdesupport, it would be much easier. as Aaron said, this is because something is not widely used that it is not available everywhere. How many CMake version every distributions packaged before KDE 4 decided to make it its builder ? But cmake was available when KDE 4.0 got released, and we had quite some feedback from the cmake guys to fix bugs. Are you sure all those little dependencies will be available as final releases? Would you release KDE 4.1 if Qt 4.4 final is not released? Ok, I'm exaggerating, but you cannot compare what you listed with dependencies of a single application. And why not ? Because what I said: I don't have to have running in the memory X interpreters. It is as if you think there is an unlimited pool of available developers, all with perfect skills in C++. Developers who contributes to KDE come with their skills, and you seem to close the KDE door to Python-only developer who would like to create a Clock in Python for the KDE desktop ? They are free to creating, distributing, putting in KDE svn. What I don't want is to not have a C++ clock that is installed by default. Wasn't this clear? He has to know C++ only to contribute to KDE ? You are either did not understand what I wrote or deliberately misinterpret my words. Once again, it's as if Google will always give money to KDE project for re-implement something. It was a suggestion how we could get a C++ replacement. If an application exists, is well written and respect the criteria defined previously by Allen, why not adding it ? It's not Cobol, nor C#, but a modern and clean object oriented scripting language. I already stated my reasons, I don't think I should repeat them. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Mauricio Piacentini wrote: Andras Mantia wrote: I already stated my reasons, I don't think I should repeat them. Just want to support Andras here Now that I've read the justifications for Andras' position, and while I respect the opinions given, I think we can only to agree to disagree (emphatically on my part) on this. It would be nothing but hypocritical on one hand to produce these bindings for other languages (in kdebindings), and then turn around and say that they're not good enough to actually use anywhere meaningful within kde (modulo issues wrt module interdependencies, but that's something that can be dealt with amicably). -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Mark Constable wrote: The main point is that introducing these kinds of packages intermixed with core C++ based code pollutes that environment and demands that packagers and end users MUST install dependencies they may otherwise not need. As I understand it, these were to be nothing but OPTIONAL parts, nothing proposed so far was introducing any new mandatory dependencies. -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Saturday 29 March 2008, Mark Constable wrote: On 2008-03-30 09:12, Alexander Dymo wrote: I read the whole thread today and felt a bit sad. Not because there's disagreement on whether we allow python application in KDE main module or now. But because both Guidance supporters and critics IMHO seem to have a really distorted view on modern computer programming and modern programming languages. I agree with what you have said, Alex. I think getting concerned over the use of the term scripting language is a bit unnecessary, it's just a commonly used term is all. My use of it does not bely any prejudices against them as general purpose languages. Now, to deal with some of the interesting misconceptions: The main point is that introducing these kinds of packages intermixed with core C++ based code pollutes that environment and demands that packagers and end users MUST install dependencies they may otherwise not need. That's true of every single dependency we have in KDE. Hardly anybody bats an eye when we pull in Yet Another Library, so doing so now is really hypocritical. Qt/KDE is pure binary code with minimal interpreter dependencies and I, for one, do not want to have to install perl, python, ruby, mono, java (yikes! that's 10Mb + 20Mb + 10Mb + 40Mb + 80Mb) and how ever many other scripting environemnts just to run a basic desktop system. * Dependencies are handled for you when installing from packages, and simply cause items to be skipped when they are not available. So more work is not at issue. * We're not talking about all languages: we're specifically discussing Python. Saying that it's a slippery slope to adding any language anywhere missed Allen's earlier email and completely underestimates the amount of push back there would be for some random language. I mean, we are having a hard time getting a Python app in svn, so thinking that Mono, Haskell, $whatever would get in is absurd. * Disk is so amazingly innexpensive these days that being concerned over 10-100MB of usage is a bit inane (I'll cover mobile devices below separately) * You probably already have Python on your system, so this is probably a really moot point. Perl is even more widely distributed, Java is very common and ruby is getting there. Especially so if the hardware is minimal which is also an increasing trend every bit as much as desktop PCs are getting more powerful. * Many Linux based UMPCs come with Python on them already these days including the EEE PC, N800 and the OLPC. * On devices where disk space is an issue, I really doubt you'll need things like a printer job viewer. * For resource consumption issues, UMPC devices already use Python for numerous tasks, including UI (OLPC is an example). For even smaller devices, see above comments on disk space. The truth of the matter is that hardware is actually growing in the mobile space so that we desktop people consider it now to be minimal. Storage, memory and processor power is growing in all these devices, not diminishing. UMPC devices are fully capable of running Python apps just fine. So again, we're probably back to talking about really small things like phones where these issues may remain at the present time. I have no problem if these non-binary scripted apps are in an optional separate official area but I think it would be a mistake to intermix them with core C++ libs and binaries. Of course, libraries are not a relevant part of this discussion. Btw, all the nay sayers are some 2+ years late. We already had this whole discussion at Akademy in Malaga, it was a very very well attended session and the conclusion was to bring Python/Ruby apps into KDE modules. I think it is useful to have this discussion so as to work through issues and find consensus with those who missed out the first time this was decided, but really ... it's already been decided, unless someone can bring up a really compelling reason to overturn it. That hasn't happened at this point. The benefits, as outlined by Alex, Jonathan, Rex and others are immense. We would be absolutely daft not to take advantage of progress in languages. Btw, at one of this year's Trolltech DevDays in a general session (so everyone was there) it was asked from the stage how many developers there were interested in various non-C++ languguages. Of the ~500 ppl there (iirc?) a few dozen raised their hand for python, a handful for java and (again iirc) exactly one for C#. This was at a very heavily C++ oriented event, of course, but it shows that the Java/C#/etc spectre is pretty much non-existent. There's very much a trend towards just a couple of these new languages; and historically, popular language proliferation has never happened: there's always been a few dominant languages. Right now Python and Ruby, at least in the Open Source world, are the two rising stars. C++ is not likely to wane soon, but the growth is in Python/Ruby. The
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Hi, The short answer is that I'd like to not see such apps in the main modules. With main I mean something that you must build and install to have a usable KDE. On Thursday 27 March 2008, Allen Winter wrote: Do we allow Python/Ruby/C#/Perl etc. apps in the KDE main modules? If so, which ones and why? I think kdelibs is out of question. :) For the language 1) must have a mature, working, kde binding (i.e. there isn't a working perl binding IIRC) Here is one of the main problems: those apps will work only if you have their bindings installed. But the bindings need to be generated whenever something changes in the libraries, so you might end up with a none- working app in a main module because the bindings were not yet updated. My other concern is speed and memory usage. If we start to have a mix of different scripting applications that you have to run in order to have a usable KDE... I have no problems having extensions or even full apps in those languages as long as I am not forced to run them. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Here is one of the main problems: those apps will work only if you have their bindings installed. But the bindings need to be generated whenever something changes in the libraries, so you might end up with a none- working app in a main module because the bindings were not yet updated. My other concern is speed and memory usage. If we start to have a mix of different scripting applications that you have to run in order to have a usable KDE... I have no problems having extensions or even full apps in those languages as long as I am not forced to run them. Andras -- Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. I must admit that I was sceptical the first time I heard guidance was in Python, but in any machine I used it, it always start fast. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Nicolas Ternisien wrote: Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. I never worked with the bindings, but are you sure they always work and will never break on minor releases? Or that they will be ready at the same time when a new KDE version comes out? IIRC there were many times problems with the kdebindings module in KDE3. About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. I must admit that I was sceptical the first time I heard guidance was in Python, but in any machine I used it, it always start fast. I'm pretty sure it works fast on my desktop machine as well, but what about my laptop with 192MB RAM? Yes, it is outdated, but perfectly usable for daily, none developing work. If we allow Python apps, we will have to allow other apps as well. If I can't get a usable desktop without those apps, I will end up with a bloated system. Guidance is a border case, because on most systems you can work without it as well, with the distribution provided tools. But eg. a system settings module (like desktop configuration or such), a mail client, or even the default calculator should work without external dependencies. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On 28.03.08 09:41:28, Nicolas Ternisien wrote: Here is one of the main problems: those apps will work only if you have their bindings installed. But the bindings need to be generated whenever something changes in the libraries, so you might end up with a none- working app in a main module because the bindings were not yet updated. My other concern is speed and memory usage. If we start to have a mix of different scripting applications that you have to run in order to have a usable KDE... I have no problems having extensions or even full apps in those languages as long as I am not forced to run them. Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. Did you follow PyKDE3 releases? Its always been lagging behind KDE3.x changes quite a bit due to time constraints at the authors side. And its not just the big changes of major versions that need changes in the bindings, there's plenty of API that gets added between minor releases. Thats one of the reasons why PyQt bindings are only provided for rc's and releases (and sometimes beta's) of Qt. About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. As soon as you allow one scripting language in a main KDE module you'll basically have to allow all or try to fight all those naggers that file thousands of reports asking for their preferred language. I must admit that I was sceptical the first time I heard guidance was in Python, but in any machine I used it, it always start fast. Thats also what I've seen, except a few performance problems with model/view classes in erci4 - though that was more than 6 months ago. Andreas -- You will be a winner today. Pick a fight with a four-year-old. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Andreas Pakulat wrote: On 28.03.08 09:41:28, Nicolas Ternisien wrote: Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. Did you follow PyKDE3 releases? Its always been lagging behind KDE3.x changes quite a bit due to time constraints at the authors side. And its not just the big changes of major versions that need changes in the bindings, there's plenty of API that gets added between minor releases. Thats one of the reasons why PyQt bindings are only provided for rc's and releases (and sometimes beta's) of Qt. the, to me anyways, obvious answer here is that python/ruby apps would simply not have access to all the same api the C++ apps would at the same time. no big deal, really the manpower issue is a real one, though, and it's one we only encourage by various acts of _discouraging_ their use. developer base is calculated as a fraction of the user base, after all ... so we have a kind of chicken-and-egg problem that we could solve pretty easily. and yes, i think the solution is easy because the bindings have a long track record now and apps built on them have shown that it does work very well in practice. About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. As soon as you allow one scripting language in a main KDE module you'll basically have to allow all or try to fight all those naggers that file thousands of reports asking for their preferred language. i think we can probably say these languages are ok.. and stick with it. the choices are probably pretty obvious, based on common sense things like: * primary support (runtimes, etc) being Free software * quality KDE bindings having been available and continuing to be available -- 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Andras Mantia wrote: On Friday 28 March 2008, Nicolas Ternisien wrote: Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. I never worked with the bindings, but are you sure they always work and will never break on minor releases? Or that they will be ready at the same time when a new KDE version comes out? IIRC there were many times problems with the kdebindings module in KDE3. Well there were many problems with kdebindings because there were two few applications using them, which means too few applications testing the bindings. So sure there are regressions that happen, but, it also happen in kdelibs, or other C++ applications, the best way to find those regression is to have widely use applications using those bindings. And, for the record, python-qt3/kde3 wasn't distributed in kdebindings3 ;) About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. I must admit that I was sceptical the first time I heard guidance was in Python, but in any machine I used it, it always start fast. If we allow Python apps, we will have to allow other apps as well. If I can't get a usable desktop without those apps, I will end up with a bloated system. Guidance is a border case, because on most systems you can work without it as well, with the distribution provided tools. But eg. a system settings module (like desktop configuration or such), a mail client, or even the default calculator should work without external dependencies. Since it's script-based application, once dependencies (kdebindings) is installed, isn't it easy for the user to install them if he wants to use them ? For me that would be the great force of those languages. There is of course the security issue, but maybe we can use gpg signing of those applications with an easy UI to check ? (like on windows ;) ) -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. Did you follow PyKDE3 releases? Its always been lagging behind KDE3.x changes quite a bit due to time constraints at the authors side. And its not just the big changes of major versions that need changes in the bindings, there's plenty of API that gets added between minor releases. Thats one of the reasons why PyQt bindings are only provided for rc's and releases (and sometimes beta's) of Qt. About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. As soon as you allow one scripting language in a main KDE module you'll basically have to allow all or try to fight all those naggers that file thousands of reports asking for their preferred language. I must admit that I was sceptical the first time I heard guidance was in Python, but in any machine I used it, it always start fast. Thats also what I've seen, except a few performance problems with model/view classes in erci4 - though that was more than 6 months ago. Andreas -- IMHO, it's just because no main KDE core applications uses those bindings that explains they always have some problems and are often delayed compared to current KDE API. When motivated developers will ask why the X function is not available in bindings, or why it is broken, be sure the current problems you have with binding will be fixed. And moreover, maybe those developers will also help fixing the bindings too. As Aaron said, a Python KDE apps will have some late compared to KDE C++ apps, but why not ? Is it so important ? About other scripting languages, as often seen in Open Source, it's people who code who generally decide about future improvements and choices (we already saw this when CMake replaces first choice Scons because of better support). So Python is the first in the scripting language list because Guidance exists, and because it's a cool apps suite. Other scripting languages will be accepted only because something useful for KDE exists, not just because some gurus come here to request the adding of their favorite language. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Andreas Pakulat wrote: As soon as you allow one scripting language in a main KDE module you'll basically have to allow all or try to fight all those naggers that file thousands of reports asking for their preferred language. BTW, will it be strange when I will ask to include kommander executor in kdebase? ;) Of course I will oppose to use Kommander for core apps just like I don't like to have core apps written in other scripting languages. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Updated Policy, based on 1-day's worth of discussion: For the language 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 For the app: 1) must perform: speed-wise and memory-wise 2) must follow the kde look-and-feel, widgets, etc 3) must follow all our rules (docbook, fully i18n and i10n, Krazy ...) 4) not permitted in kdelibs or kdepimlibs As is our tradition, the module coordinator, release team, and the KDE project as a whole will make the final decision about which languages and apps are appropriate. Comments? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Really clean and interesting policy. Will it be added to Techbase after comments ? On Fri, Mar 28, 2008 at 2:23 PM, Allen Winter [EMAIL PROTECTED] wrote: Updated Policy, based on 1-day's worth of discussion: For the language 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 For the app: 1) must perform: speed-wise and memory-wise 2) must follow the kde look-and-feel, widgets, etc 3) must follow all our rules (docbook, fully i18n and i10n, Krazy ...) 4) not permitted in kdelibs or kdepimlibs As is our tradition, the module coordinator, release team, and the KDE project as a whole will make the final decision about which languages and apps are appropriate. Comments? ___ 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
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Allen Winter wrote: 1) must perform: speed-wise and memory-wise I'd like to add here that those apps should not be resident apps (apps that need to run continuously). I'm not saying that such applications cannot be written in scripting languages, but they should not be installed and run by default. This means that kdebase is probably another module that should not accept script applications. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Le Friday 28 March 2008 03:21:56 pm Andras Mantia, vous avez écrit : I'd like to add here that those apps should not be resident apps (apps that need to run continuously). I'm not saying that such applications cannot be written in scripting languages, but they should not be installed and run by default. This means that kdebase is probably another module that should not accept script applications. Andras So you rule out the printing-applet which is in kdereview and intended to move to kdebase? Anne-Marie ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Andras Mantia wrote: On Friday 28 March 2008, Allen Winter wrote: 1) must perform: speed-wise and memory-wise I'd like to add here that those apps should not be resident apps (apps that need to run continuously) rationale being? (because this seems to target system-config-printer-applet that jriddell's been working on, which I'd really really like to see). -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Allen Winter wrote: That would eliminate Jonathan's print config tool from consideration. Do you really mean kdebase-runtime? I know, and this is what I meant. Of course IMO. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Rex Dieter wrote: rationale being? (because this seems to target system-config-printer-applet that jriddell's been working on, which I'd really really like to see). The rationale is that the interpreter executable needs to be permanently in the memory. And if we allow it, and allow similar tools running another interpreter, we will end up with a much higher memory usage. Andras PS: I will test this and guidance once my KDE trunk checkout finished compiling. -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Allen Winter wrote: Comments? 1) Brilliantly said 2) ... 3) Profit -- 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Allen Winter wrote: On Friday 28 March 2008 10:21:56 Andras Mantia wrote: On Friday 28 March 2008, Allen Winter wrote: 1) must perform: speed-wise and memory-wise I'd like to add here that those apps should not be resident apps (apps that need to run continuously). I'm not saying that such applications cannot be written in scripting languages, but they should not be installed and run by default. This means that kdebase is probably another module that should not accept script applications. That would eliminate Jonathan's print config tool from consideration. Do you really mean kdebase-runtime? there's probably also value to having long lived workspace apps written in compiled languages (they all are right now) as well ... so there are probably some kdebase-workspace considerations (that said, plasma will use scripting for add-ons more and more) i don't think, however, that a print configuration matters one whit as to which language (of the ones that meet the criterion you laid out) it is implemented in -- 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Andras Mantia wrote: PS: I will test this and guidance once my KDE trunk checkout finished compiling. And I failed. printer-applet has some dependencies (python-cups, hal- cups-utils) that I couldn't find for my distribution (opensuse). This is already a problem. So I read the k-c-d thread and the README file and it became clear that the app should be in playground and not kdereview: - it is not using the KDE libraries, but the Qt ones. Others were complaining it does not look like the rest of KDE. This also shows the issue with the bindings, because the reason invoked was a bug in the bindings (or wrong interaction between PyKDE and python-dbus) - it uses a different translation method - it wants to install in /usr/share/..., instead of respecting the KDE install dir Guidance is not ported to KDE4 so here there is nothing to test. My opinion did not change, but more, I believe even more that core apps need to be C++. Those can also be fixed my most of the KDE developers. :) Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Fri, Mar 28, 2008 at 05:43:23PM +0200, Andras Mantia wrote:
On Friday 28 March 2008, Andras Mantia wrote:
PS: I will test this and guidance once my KDE trunk checkout finished
compiling.
And I failed. printer-applet has some dependencies (python-cups, hal-
cups-utils) that I couldn't find for my distribution (opensuse). This is
already a problem. So I read the k-c-d thread and the README file and it
became clear that the app should be in playground and not kdereview:
- it is not using the KDE libraries, but the Qt ones. Others were
complaining it does not look like the rest of KDE. This also shows the
issue with the bindings, because the reason invoked was a bug in the
bindings (or wrong interaction between PyKDE and python-dbus)
Trolltech says the issue causing this should be fixed in Qt 4.4 RC1.
- it uses a different translation method
It uses gettext, same as kdelibs. See above for the kdelibs issue.
- it wants to install in /usr/share/..., instead of respecting the KDE
install dir
It installs to ${DATA_INSTALL_DIR}.
My opinion did not change, but more, I believe even more that core apps
need to be C++.
That attitude will mean we have less programmers and less programmes.
Jonathan
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Jonathan Riddell wrote:
bindings (or wrong interaction between PyKDE and python-dbus)
Trolltech says the issue causing this should be fixed in Qt 4.4 RC1.
That's good news.
- it uses a different translation method
It uses gettext, same as kdelibs. See above for the kdelibs issue.
As I said, I couldn't test, I relied on what was said on k-c-d (see the
post from Chusslove Illich).
- it wants to install in /usr/share/..., instead of respecting the
KDE install dir
It installs to ${DATA_INSTALL_DIR}.
That was written in the README file:
hal-cups-utils and system-config-printer like to install to
/usr/share/system-config-printer, if you put it elsewhere change the
SYSTEM_CONFIG_PRINTER_DIR variable in printer-applet.py
So I believed it. Or...is system-config-printer another dependency?
Because in that case It is a Qt port of system-config-printer by Tim
Waugh from Red Hat. is misleading.
My opinion did not change, but more, I believe even more that core
apps need to be C++.
That attitude will mean we have less programmers and less programmes.
I doubt refusing such apps in core modules will have this effect.
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Andras Mantia wrote: On Friday 28 March 2008, Andras Mantia wrote: PS: I will test this and guidance once my KDE trunk checkout finished compiling. And I failed. printer-applet has some dependencies (python-cups, hal- cups-utils) that I couldn't find for my distribution (opensuse). This is already a problem. it's no more or less a problem than any other dependencies. and we have quite a list of them. let's try to stay focussed on the real issue, scripting, rather than writing a laundry list of things that are neither here nor there when it comes to scripting. My opinion did not change, but more, I believe even more that core apps need to be C++. like all bugs, these get fixed if there is sufficient manpower and reason to apply to it. by keeping everything c++ we may as well just decide to not use scripting languages at all, ever because the level of quality and support will always be pathetic. in fact, one might say that the current state of affairs is due exactly to the position you are taking right now. as i said before, this is a chicken and egg problem ... if we simply take a little bit of pain right now, we stand a chance for things to improve dramatically with time. and seeing the state of the printer app this would be replacing (e.g. none; it's non-existent in kde4 right now), i think having something that exists totally trumps a theoretical c++ app that doesn't. -- 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Sure, but this also exposed the problem that having a Python app makes our lives not easier than I would expected, but in some ways even harder. In the particular case it has dependencies not available in a modern and widely used distribution and for some of them it is suggested to get from svn. Yes, and where did you find your binary Qt 4.4 version to compile KDE 4 ? You compile it too from SVN. as Aaron said, this is because something is not widely used that it is not available everywhere. How many CMake version every distributions packaged before KDE 4 decided to make it its builder ? There is a lot of things that could be implemented in such languages and I would not oppose to them. So I cannot believe that such an attitude scared away the developers. After all there was Guidance for KDE3, it was accepted in KDE extragear, just like K3B, KTorrent or KMPlayer was. And we can do the same now. Again, I just don't like the idea to have applications that are a must on a KDE desktop to be written in scripting languages. If they are daemon like ones, that's even worse. If there is a very good Plasma applet written in Python that I like, I may decide to use it, just don't make e.g. the clock a Python application. Or Ruby. And why not ? It is as if you think there is an unlimited pool of available developers, all with perfect skills in C++. Developers who contributes to KDE come with their skills, and you seem to close the KDE door to Python-only developer who would like to create a Clock in Python for the KDE desktop ? He has to know C++ only to contribute to KDE ? This kind of languages and the way and problems to integrate them well in KDE are the necessary brick to open more the development process to other people. and seeing the state of the printer app this would be replacing (e.g. none; it's non-existent in kde4 right now), i think having something that exists totally trumps a theoretical c++ app that doesn't. It is unfortunate that in this case there is no c++ app replacing it. Sincerely I was not aware of it. I'd rather ask for public help to either port kjobviewer to KDE4 or write a new one. Can even be a SoC project. Once again, it's as if Google will always give money to KDE project for re-implement something. If an application exists, is well written and respect the criteria defined previously by Allen, why not adding it ? It's not Cobol, nor C#, but a modern and clean object oriented scripting language. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Le Thursday 27 March 2008, Allen Winter a écrit : I think the Release Team should discuss this and provide a policy statement. Do we allow Python/Ruby/C#/Perl etc. apps in the KDE main modules? If so, which ones and why? Oh, and this is also needed for Jonathan's system-config-printer-applet Here are some off-the-cuff thoughts to get the ball rolling: For the language 1) must have a mature, working, kde binding (i.e. there isn't a working perl binding IIRC) 2) must be mature and operational on all our target platforms 3) must be able to provide full translations and internationalizations For the app: 1) must follow the kde look-and-feel, widgets, etc ... Also, per binding we probably a list of do and don't which should be followed by applications using the said binding. For instance, the use of the python dbus bindings has shortcomings (as system-config-printer-applet shown), do we allow apps like that? There's probably similar cases for other bindings. Regards. -- Kévin 'ervin' Ottens, http://ervin.ipsquad.net Ni le maître sans disciple, Ni le disciple sans maître, Ne font reculer l'ignorance. 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: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Kevin Ottens wrote: Also, per binding we probably a list of do and don't which should be followed by applications using the said binding. For instance, the use of the python dbus bindings has shortcomings (as system-config-printer-applet shown), do we allow apps like that? There's probably similar cases for other bindings. That seems to me to be an unmaintainable list. Why not use an easier criteria like app must work reliably as advertised and/or app must not suck? :) -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
