|
| This Week... |
|
Konqueror defaults to "smart" popup blocking. KTouch adds a russian keyboard and training file. New nxfish ioslave which allows sharing between local NX Client and the remote NX server without requiring Samba. Wallpapers and background tiles were "cleaned up" for the 3.5 release.
|
Three threads on kde-core-devel are worth considering. The future direction of KDE has been discussed over the last week or so at Malaga, and Stephan Kulow kindly brought the discussion to the wider audience.
|
The first thread is titled Malaga Discussions I [1]. Stephan wrote:
|
So we came together in the afternoon and discussed some issues that we consider interesting enough to discuss.
The first one was IPC. We once again summarized the benefits of KDE switching to DBUS (among the lines of 'well maintained', 'support from toolkits and other desktops', 'distribution support already very high') and what bothers us with it ('C API', 'unsolved performance problems', 'unknown upgrade path').
So it was pretty clear, that we do should switch, but what we discussed in a pretty long and heated discussion was: how and on what level should we support applications accessing the KDE3 dcop interface. And so far we only found one use case that we consider important enough to support it: kpresenter/kdetv for KDE3 wants to disable the screensaver running within KDE4. All other dcop3<->dcop3 conversations have to be supported in a way as we do now when KDE applications started under twm. In that area KDE4 just has to make sure not to get in the way of KDE3 (e.g. different file names for communication sockets).
|
|
There was some discussion whether it is worth working on dcop scripting now, and some expressions wondering why adopt a slow and undefined protocol. It looks like d-bus is going to be part of KDE4, the implementation details will be interesting to say the least.
|
Stephan continued with a thread called Malaga Discussions II [2]. This is about scripting interfaces to KDE.
|
We all agreed, that scripting will be a major component of KDE4 and that we need to make sure it's as good as possible.
The discussion went a bit back and forth on the topics 'Do we support only one or several languages?' and 'If one, what language will that be?'. I was actually the strongest supporter of having a multi-language strategy, but in the end we left it to the developers there representing the actual kdebindings authors (Ian, Rich and Richard Dale) and they kind of agreed that one excellent binding is more than enough work. During the discussion on the numbers of languages to support it was already obvious that the majority of developers wants kjs/qsa (which are said to differ only in details so far) to be _that_ language.
Please note though that this whole discussion was just about scripting applicatins, neither about application development nor about heavy plugins. There is still something left to discuss, but we did a start.
|
|
Sebastian Sauer commented: [3]
|
Quit funny cause the feedback I got last year from majority of users and developers is, that they would like to have python or <put your fav interpreter her> as preferred language instead of ecma like scripts. Anyway, that's personal taste and shows one more time, that we maybe should provide at least an optional way to leave the decision up to the potential developer who decides that he likes to write some other binding and got frustrated by rewritting everything cause the existing scripting-solution is qsa/kjs only and couldn't be reused and, more worse, applications are bind to qsa/kjs only.
As already sayed above that doesn't mean to maintain a bunch of equivalent solutions for all existing interpreterlanguages like done today, rather then providing a plugin-framework where somebody is able to put his own scripting-binding in and use it as first class citizen even if not official supported by the KDE-project.
|
|
A third thread [4] summarizes what Stephan called "another heated discussion". This one is about the organisation of kdelibs and kdebase. The discussion takes place in this thread [5]. Anyone using trunk needs to be aware of this:
|
|
And to make application development/porting in any way reasonable I branched kdelibs to /branches/work/kdelibs4_snapshot - you should use that one if you're not interested in developing kdelibs. Expect trunk/KDE/kdelibs to be broken at any random time (for now).
|
|
What is this all about? Stephan explains:
|
kdebase in it's current form is too strictly bound to the UNIX desktop we developed so far. Many in the past raised the concern that you don't need kicker on Windows, but you still would like to have the ioslaves and the helpcenter on it - still both are bound together in one SVN module. So we decided to split kdebase into two subsets: those apps that are foundation for other applicatins and those apps that make up the KDE desktop. This wasn't really controversial.
The other aspect was much more controversial as it related to kdelibs. The idea presented was to split kdelibs into the parts that only rely on Qt each (most widgets, some of our kdecore parts) and those parts that are either grouped together to make up KDE's framework and the parts that rely on that KDE framework.
|
|
The heated discussions came from what I would call 'creative tension'. KDE has many different interests involved in the development, each trying to make sure that their needs are met. On one end you have Trolltech with a cross platform toolkit, and developers (customers) using their toolkit to write applications that fit specific needs. They would like some of the KDE technologies to be available to Qt users. Another interest are those who would like to see the porting of KDE and it's components to OSX and Windows, but would like to easily exclude technologies that would be duplicated where the host has a suitable implementation. The third (loosely) group are those who look at these ideas, and say as Rhett Butler: Frankly, my dear, I don't give a damn. And don't want to complicate or create maintenance for something they are not interested in.
|
Benjamin Meyer explained the goals of this exercise: [6]
|
With more and more companies adopting Qt having a set of tools from KDE that only require Qt gives them a way to try out KDE's technology and hopefully then utilize our entire framework. This will give us more testers, contributors etc. The best example is a lot of the KDE widgets that you find in designer and a bunch of small helper classes in kdecore.
From a more fundimental level there is a heck of a lot of interdependencies in kdelibs that aren't needed at the moment. The thicker the graph the harder it is to debug. A lot of us wish to implement unit tests. Reducing the number of unnecessary dependencies will make this job easier. This also makes giving maintainership over to new developers a lot more easier. There has been a lot of talk about maintainers here at akademy also. Right now there seems to be only a few people who really understand and maintain kdelibs.
The concensus at the end of the meeting was not that we definitly were going to do this fyi, but to at least give it a shot and see how far we could get.
|
|
[1] http://lists.kde.org/?l=kde-core-devel&m=112522690717601&w=2
[2] http://lists.kde.org/?l=kde-core-devel&m=112524270027657&w=2
[3] http://lists.kde.org/?l=kde-core-devel&m=112526102816806&w=2
[4] http://lists.kde.org/?l=kde-core-devel&m=112548113617951&w=2
[5] http://lists.kde.org/?l=kde-core-devel&m=112513238424281&w=2
[6] http://lists.kde.org/?l=kde-core-devel&m=112565459811357&w=2
|
|
| Statistics |
|
Commits: |
2615
by 218
developers, 61958
lines modified, 1683
new files. |
|
Open Bugs:
|
8988
|
|
Open Wishes:
|
8402
|
|
Bugs Opened:
|
321 in the last 7 days. |
|
Bugs Closed:
|
325 in the last 7 days. |
|
|
Commit Summary |
|
Module
|
Commits
|
|
l10n |
|
|
extragear |
|
|
www |
|
|
work |
|
|
stable |
|
|
playground |
|
|
kdenonbeta |
|
|
kdenetwork |
|
|
kdelibs |
|
|
kdebase |
|
|
|
Lines
|
Developer
|
Commits
|
|
|
Frerich Raabe
|
|
|
|
Ludovic Grossard
|
|
|
|
Nikolas Zimmermann
|
|
|
|
Laurent Montel
|
|
|
|
Christoph Cullmann
|
|
|
|
Nicolas Goutte
|
|
|
|
Grzegorz Jaskiewicz
|
|
|
|
Frans Englich
|
|
|
|
Gilles Caulier
|
|
|
|
Jose Nuno Coelho Pires
|
|
|
|
|
Internationalisation (i18n) Status
|
|
|
Bug Killers |
|
Bug Killer
|
Number Of Bugs Closed
|
|
Olivier Goffart
|
|
|
Bram Schoenmakers
|
|
|
Matt Rogers
|
|
|
Alexandre Pereira de Oliveira
|
|
|
Tommi Tervo
|
|
|
Thiago Macieira
|
|
|
Albert Astals Cid
|
|
|
Oliver Kellogg
|
|
|
Andreas Beckermann
|
|
|
Joris Guisson
|
|
|
|
|
| Contents |
|
|
Bug Fixes |
Features |
Optimise |
Security |
Other |
|
Accessibility |
 |
|
|
|
![[*]](/images/standard/other.png) |
|
Development Tools |
![[*]](/images/standard/bugfixes.png) |
![[*]](/images/standard/features.png) |
|
|
|
|
Educational |
|
|
|
|
|
|
Graphics |
|
|
![[*]](/images/standard/optimise.png) |
|
|
|
KDE-Base |
|
|
|
|
|
|
KDE-PIM |
|
|
|
|
|
|
Office |
|
|
|
|
|
|
Konqueror |
|
|
|
|
|
|
Multimedia |
|
|
|
|
|
|
Networking Tools |
|
|
|
|
|
|
User Interface |
|
|
|
|
|
|
Utilities |
|
|
|
|
|
|
Games |
|
|
|
|
|
|
Other |
|
|
|
|
|
|
There are 220 selections this week.
|
|
Bug Fixes |
|
|
|
Christoph Cullmann committed changes in /trunk/KDE/kdelibs/kate/part:
|
|
fix crash on cursor out of range, but the other stuff looks like pure bloat :( why not just save the cursors per bufblock, 2000 lines shouldn't be that much or? we could even break that down inside the buf block, but this current design doesn't look that clever, needing to sync even more internal parts, beside, is the edit history really needed in addition to undo? |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Koos Vriezen committed a change to /trunk/extragear/multimedia/kmplayer/src/kmplayer_part.cpp:
|
Fix resizing part to 0x0 on www.3fm.nl when click 'Luister Live' in top-left
flash element. Normally kmplayer tries to resize itself to the movie size
when no WIDTH/HEIGHT tags were passed. Of course this should not be done if
size is 0x0, like here for an audio only stream.
Thanks Gordon Mackay for reporting this one! |
|
|
|
|
|
|
|
|
|
|
|
|
|
