|
| This Week... |
|
DCOP Client/Server implemented for KDE win32. New videodvd:/ kioslave does on the fly decryption from DVD. Kopete implements Yahoo! Stealth feature. Opening of WebCore development yields fruit: DOMParser, and CSS fixes.
|
Changing major versions of KDE present opportunities to make the major changes needed to improve the platform. But how will third party KDE 3 applications run? Martijn Klingens started a thread entitled "Compatibility between KDE 3 and KDE 4" [1]. Here are some of the issues:
|
Please add to the list below anything that is missing. Also please correct anything that's wrong, I'm working off the top of my head now. A first incomplete start:- KDE 3 apps using DCOP expect a DCOP server using a given binary protocol. The KDE 3 DCOP server is found using ~/.DCOPserver_$hostname_$display, and uses the ICE protocol for authentication. KDE 4 will need a DCOP server that has the same semantics, or a compatibility replacement. Are there problems to be expected here, or will this stay in a way that's KDE 3 compatible?
- KDE 3 apps expect a ksycoca using a specific binary layout. ksycoca is designed to be upwards compatible within KDE versions, but not necessarily to survive major upgrades to e.g. internal representations of variables. Are there problems to be expected here wrt Qt 3/4 ?
- $KDEHOME and $KDEDIRS have a defined meanign that will have to be preserved
- $KDEDIR is scheduled for removal since KDE 2, and KDE 2 and KDE 3 both also support $KDEDIRS, so this is a special case that we can remove now after 5 years of extended support.
- Kiosk profiles are governed through /etc/kde3rc under SuSE, but not for a vanilla KDE, where it is just /etc/kderc. The profiles themselves default to /etc/kde-profile and /etc/kde-user-profile. Potential problems arise in overlapping config files (kdeglobals for KDE 3 and 4), so KDE 4 will need a more future-proof naming scheme.
- KDE libraries have to coexist alongside. That can be handled by just setting $PREFIX accordingly though, AFAICS
- kdeinit and notably kded need precautions to work with older binaries. (Which? What are the usage patterns?)
- DCOP interfaces will need to remain compatible or provide compatibility wrappers, at least for the major applications.
- kdialog will need to stay syntax compatible.
|
|
Thiago Macieira added another issue:[2]
|
|
There's the problem of Qt's datastream changing internally, but we have already solved that in the KDE4 port by explicitly setting the stream version. QDataStream and all the classes support backwards-compatible marshalling since Qt 1.x, so it is quite easy.
|
|
Maksim Orlovich who has been working on the porting effort described his experience with DCOP: [3]
|
Yep,and I've tested this to some extent early in the port (e.g. talking to KDE3 apps using a KDE4 dcop command), but not extensively. A problem is that tons of code marshalls manually, so there need to be zillions of setVersion calls (or better, the code needs to be converted to use DCOPRef). Some of the marshalling is quite sloppy, too, though.
KBuildSycoca situation is similar: with setVersion calls in place, last I checked it could open my 3.x ksycoca file. And of course ksycoca itself is designed to be expandable in a backwards compatible way, with version numbers and everything.
|
|
Thiago Macieira reminds us of the proposed direction regarding DCOP and D-BUS [4]
|
But from the ideas we got last time we discussed D-BUS here, I'd say that it is feasible to give full access to the new environment, not just a compatibility area. In other words, I think the conclusion was:- KDE4 apps will speak D-BUS natively
- KDE3 apps can talk to KDE4 apps normally, and vice-versa
- KDE3 apps cannot talk to non-KDE D-BUS apps
- non-KDE D-BUS apps can send simple messages that are to be relayed into DCOP
This would, of course, require that we have a dcopserver. In fact, if we want to support DCOP at all, we'll need dcopserver.
|
|
Obviously many of these issues are unresolved, and solutions will come when someone starts writing code.
[1] http://lists.kde.org/?l=kde-core-devel&m=111809395900396&w=2
[2] http://lists.kde.org/?l=kde-core-devel&m=111810275129133&w=2
[3] http://lists.kde.org/?l=kde-core-devel&m=111810723200064&w=2
[4] http://lists.kde.org/?l=kde-core-devel&m=111814373103246&w=2
|
|
| Statistics |
|
Commits: |
2860
by 202
developers, 53426
lines modified, 2587
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 |
|
|
stable |
|
|
extragear |
|
|
work |
|
|
www |
|
|
kdepim |
|
|
kdeedu |
|
|
koffice |
|
|
kdenonbeta |
|
|
digikam |
|
|
|
Lines
|
Developer
|
Commits
|
|
|
Laurent Montel
|
|
|
|
David Faure
|
|
|
|
Nikolas Zimmermann
|
|
|
|
Pino Toscano
|
|
|
|
Dirk Mueller
|
|
|
|
Pedro Morais
|
|
|
|
Gilles Caulier
|
|
|
|
Albert Astals Cid
|
|
|
|
Rinse de Vries
|
|
|
|
George Staikos
|
|
|
|
|
Internationalisation (i18n) Status
|
|
|
Bug Killers |
|
Bug Killer
|
Number Of Bugs Closed
|
|
Aaron J. Seigo
|
|
|
Thiago Macieira
|
|
|
Andreas Gungl
|
|
|
Andreas Beckermann
|
|
|
Luboš Luňák
|
|
|
Daniel Molkentin
|
|
|
Maks Orlovich
|
|
|
Till Adam
|
|
|
Albert Astals Cid
|
|
|
James Richard Tyrer
|
|
|
|
|
| Contents |
|
|
Bug Fixes |
Features |
Optimise |
Security |
Other |
|
Accessibility |
 |
|
|
|
|
|
Development Tools |
![[*]](/images/standard/bugfixes.png) |
|
|
|
![[*]](/images/standard/other.png) |
|
Educational |
|
![[*]](/images/standard/features.png) |
|
|
|
|
Graphics |
|
|
|
|
|
|
KDE-Base |
|
|
![[*]](/images/standard/optimise.png) |
|
|
|
KDE-PIM |
|
|
|
|
|
|
Office |
|
|
|
|
|
|
Konqueror |
|
|
|
|
|
|
Multimedia |
|
|
|
|
|
|
Networking Tools |
|
|
|
|
|
|
User Interface |
|
|
|
|
|
|
Utilities |
|
|
|
|
|
|
Games |
|
|
|
|
|
|
Other |
|
|
|
|
|
|
There are 120 selections this week.
|
|
Bug Fixes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Graphics |
|
Albert Astals Cid committed changes in /trunk/KDE/kdegraphics/kpdf:
|
Fix crash on documents like the one on 106767, we must not check for a imagelink if we found a normal link that points to another document because the imagelink does not exists anymore, this was not present on 3.4 but yes on 3.4.1, backporting on a moment
Fix bug on 106767, need to relayout the pages when opening a document
Enrico please check that both things are "correct" and if they are remove the TODO i added for you ;-)
BUGS: 106767 |
|
|
|
|
|
|
|
|
|
|
|
|
George Staikos committed a change to /trunk/KDE/kdelibs/kio/ksslcccc:
|
Untested fix for hostnames being case sensitive. Please test this patch
and provide feedback so I know if I should backport. Apply, recompile
all of kio/ and make install. Then log out of KDE and log back in.
BUG: 107002
|
|
|
|
|
|
|
|
|
|
|
KDE-PIM |
|
Till Adam committed a change to /trunk/KDE/kdepim/kresources/kolab/kcal/resourcekolab.cpp:
|
Add some extra safety by explicitely adjusting the sernum from KMail as
early as possible. Due to the interaction with korgac there could
otherwise be races. I have yet to find out why/how korgac triggers
updates, but this seems to fix the symptom of spontaneously duplicated
events and tasks. |
|
|
|
|
|
|
Till Adam committed a change to /trunk/KDE/kdepim/kmail/imapjob.cpp:
|
When a mail is selected in an imap based search folder that was
previously not, three individual searches of the mail are triggered,
from updateAttachementState, updateSignatureState and
updateEncryptionState. Unfortunately they are precisely triggered from
ImapJob::slotGetMessageData which calls msg->fromByteArray with the data
it received from the server as a result of the message being fetched
after selection. During that fromByteArray the message has no UID
header, since the raw mail returned from the server doesn't, and
therefore KMMessage::UID() returns 0, which causes the first (and only
the first) of the three searches mentioned above to fail. The others
succeed, since they are executed asynchronously and already find
the restored uid in KMMessage::UID() when to get to asking for it. This
results in the message being removed from the search folder and
immediately re-added, which makes imap based search folders virtually
unusable.
Should only be a problem in trunk, I think, since only there are search
folders hooked up to messageHeaderChanged(). Right, Carsten?
Now I can read my kdepim commits search folder again. Rainy Saturday well
spent, I guess. Back to Kolab. ;)
|
|
|
|
|
|
|
|
|
|
|
Adriaan de Groot committed changes in /trunk/KDE/kdepim/kpilot:
|
Normalize various "magic 15s and 16s", use one defined constant everywhere.
Patch by Dylan G., fixed for typo's and occasional off-by-ones by [ade].
BUG: 104085 |
|
|
|
|
|
|
Thomas Zander committed changes in /trunk/KDE/kdepim/libkdepim:
|
Add 'clear' button next to the search dialog.
Implement several ideas from bug:67036, which I reported 1+1/2 years ago myself :)
BUG: 67036 |
|
|
|
|
|
|
Thomas Zander committed a change to /trunk/KDE/kdepim/certmanager/lib/uipppp:
|
Add 'clear search' button
Work around bug in Qt where disabling and reenabling the widget that has focus does
not properly make it refocus. This solves the problem that you had to click in the
search line (even while the cursor wash flashing there) to make it editable. |
|
|
| | |
