Re: KDE/kdebase/apps/konqueror/settings/konqhtml
On Thursday 03 January 2008, Thiago Macieira wrote: DO NOT link to kdeinit_konqueror. Please find a way of writing your code without linking there. Please fix this ASAP. This is a showstopper for 4.0.0. Looks like the patch has been reverted. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE 4.0 Release Branch
Hi, a KDE 4.0 Release branch has been created: svn+ssh|https://svn.kde.org/home/kde/branches/KDE/4.0 The translations for 4.0 are currently served from /trunk/l10n-kde4. The (hopefully) final tarball set will be created from this branch. if your change is not in there then its not going to be in 4.0. /trunk/KDE is targetting 4.1 now, but please remember to focus your attention on /branches/KDE/4.0. Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: SSL, KDE and Qt
On Thursday 03 January 2008 05:31:33 Dirk Mueller wrote: On Sunday 30 December 2007, Allen Winter wrote: So we could conceivably go back to requiring Qt 4.3.3 instead of qt-copy+patches. Comments? Indeed, we can not require a patched Qt version. I think the workaround is fine and we should go back the required version. Don't worry. We did go back to the required version. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdebase/apps/konqueror/settings/konqhtml
Am Donnerstag 03 Januar 2008 schrieb Thiago Macieira: Will Stephenson wrote: Anecdotally, this commit breaks non-debug builds. I haven't investigated it, this comment is just a marker. On Thursday 03 January 2008 14:32:46 Bernhard Beschow wrote: SVN commit 756612 by beschow: It breaks debug builds too. I can confirm that applying the reverse patch makes compilation succeed in kdebase/apps. I do not know what the effects in the configuration dialog are -- I cannot load KDE 4 over a slow remote X connection. DO NOT link to kdeinit_konqueror. Please find a way of writing your code without linking there. Please fix this ASAP. This is a showstopper for 4.0.0. [x] done reverting the patch I'm sooo sorry!! If we ever meet please remind me I owe you a beer! -- Bernhard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-cvs-announce] KDE 4.0 Release Branch
On Friday 04 January 2008, Dirk Mueller wrote: Hi, a KDE 4.0 Release branch has been created: svn+ssh|https://svn.kde.org/home/kde/branches/KDE/4.0 The translations for 4.0 are currently served from /trunk/l10n-kde4. The (hopefully) final tarball set will be created from this branch. if your change is not in there then its not going to be in 4.0. /trunk/KDE is targetting 4.1 now, but please remember to focus your attention on /branches/KDE/4.0. Would it make sense to also tag/branch kdesupport together with the rest of KDE ? I always found it a bit hard to get a matching version of kdesupport when building an older version of KDE. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Thursday 03 January 2008, Luboš Luňák wrote:
SVN commit 756696 by lunakl:
Consistent naming for xf86misc - include and flag are xf86misc, lib is
Xxf86misc.
I'm not sure this change is good:
This is a source incompatible change.
Somebody may use these variables and now they don't exist anymore, so his
build may fail.
We are at the day of the tagging, IMO too late for such changes.
It makes our FindX11.cmake incompatible to the one in CMake, which makes it
harder for us to use the CMake version, since it requires more changes once
we do that (after merging differences etc.).
Did you intentionally leave the name X11_Xxf86misc_LIB as it is ?
I feel like reverting this patch both for 4.1 and 4.0 would be the best thing
to do. Since I don't know in which other places you had to commit changes to
use these new names I don't feel like doing that myself.
Alex
M +9 -9 FindX11.cmake
--- trunk/KDE/kdelibs/cmake/modules/FindX11.cmake #756695:756696
@@ -17,8 +17,8 @@
#X11_dpms_INCLUDE_PATH, (in X11_Xext_LIB),
X11_dpms_FOUND #X11_XShm_INCLUDE_PATH, (in
X11_Xext_LIB), X11_XShm_FOUND #X11_Xshape_INCLUDE_PATH,
(in X11_Xext_LIB), X11_Xshape_FOUND -#
X11_Xf86misc_INCLUDE_PATH, X11_Xxf86misc_LIB, X11_Xf86misc_FOUND -#
X11_xf86vmode_INCLUDE_PATH,
X11_Xf86vmode_FOUND +#X11_xf86misc_INCLUDE_PATH,
X11_Xxf86misc_LIB, X11_xf86misc_FOUND +#
X11_xf86vmode_INCLUDE_PATH,X11_xf86vmode_FOUND #
X11_Xfixes_INCLUDE_PATH, X11_Xfixes_LIB,
X11_Xfixes_FOUND #X11_Xft_INCLUDE_PATH,
X11_Xft_LIB,X11_Xft_FOUND #
X11_Xinerama_INCLUDE_PATH, X11_Xinerama_LIB, X11_Xinerama_FOUND @@
-80,7 +80,7 @@
FIND_PATH(X11_Xdamage_INCLUDE_PATH X11/extensions/Xdamage.h
${X11_INC_SEARCH_PATH}) FIND_PATH(X11_Xdmcp_INCLUDE_PATH X11/Xdmcp.h
${X11_INC_SEARCH_PATH}) FIND_PATH(X11_dpms_INCLUDE_PATH
X11/extensions/dpms.h ${X11_INC_SEARCH_PATH}) -
FIND_PATH(X11_Xf86misc_INCLUDE_PATH X11/extensions/xf86misc.h
${X11_INC_SEARCH_PATH}) + FIND_PATH(X11_xf86misc_INCLUDE_PATH
X11/extensions/xf86misc.h ${X11_INC_SEARCH_PATH})
FIND_PATH(X11_xf86vmode_INCLUDE_PATH X11/extensions/xf86vmode.h
${X11_INC_SEARCH_PATH}) FIND_PATH(X11_Xfixes_INCLUDE_PATH
X11/extensions/Xfixes.h ${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xft_INCLUDE_PATH X11/Xft/Xft.h
${X11_INC_SEARCH_PATH}) @@ -236,10 +236,10 @@
SET(X11_INCLUDE_DIR ${X11_INCLUDE_DIR} ${X11_Xrandr_INCLUDE_PATH})
ENDIF (X11_Xrandr_INCLUDE_PATH AND X11_Xrandr_LIB)
- IF (X11_Xxf86misc_INCLUDE_PATH AND X11_Xxf86misc_LIB)
- SET(X11_Xxf86misc_FOUND TRUE)
- SET(X11_INCLUDE_DIR ${X11_INCLUDE_DIR} ${X11_Xxf86misc_INCLUDE_PATH})
- ENDIF (X11_Xxf86misc_INCLUDE_PATH AND X11_Xxf86misc_LIB)
+ IF (X11_xf86misc_INCLUDE_PATH AND X11_Xxf86misc_LIB)
+ SET(X11_xf86misc_FOUND TRUE)
+ SET(X11_INCLUDE_DIR ${X11_INCLUDE_DIR} ${X11_xf86misc_INCLUDE_PATH})
+ ENDIF (X11_xf86misc_INCLUDE_PATH AND X11_Xxf86misc_LIB)
IF (X11_xf86vmode_INCLUDE_PATH)
SET(X11_xf86vmode_FOUND TRUE)
@@ -399,7 +399,7 @@
X11_Xrender_LIB
X11_Xrender_INCLUDE_PATH
X11_Xxf86misc_LIB
-X11_Xxf86misc_INCLUDE_PATH
+X11_xf86misc_INCLUDE_PATH
X11_xf86vmode_INCLUDE_PATH
X11_Xinerama_LIB
X11_Xinerama_INCLUDE_PATH
@@ -415,7 +415,7 @@
X11_Xaccessrules_INCLUDE_PATH
X11_Xaccessstr_INCLUDE_PATH
X11_Xdmcp_INCLUDE_PATH
-X11_Xf86misc_INCLUDE_PATH
+X11_xf86misc_INCLUDE_PATH
X11_Xkb_INCLUDE_PATH
X11_Xkblib_INCLUDE_PATH
X11_Xkbfile_INCLUDE_PATH
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: [Kde-pim] Request to exclude KMail from the KDE 4.0 release
On Friday 07 December 2007, Sebastian Kuegler wrote: Anyway... how to proceed? Simply leave out the kdepim -4.0.0 tarball? Yes. Bad luck, but PIM3 works fine in the meantime. Are we going forward with that idea of dropping kdepim from KDE 4.0 ? What about kdepimlibs? Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: [Kde-pim] Request to exclude KMail from the KDE 4.0 release
Op vrijdag 4 januari 2008 10:59 schreef u: On Friday 07 December 2007, Sebastian Kuegler wrote: Anyway... how to proceed? Simply leave out the kdepim -4.0.0 tarball? Yes. Bad luck, but PIM3 works fine in the meantime. Are we going forward with that idea of dropping kdepim from KDE 4.0 ? What about kdepimlibs? kdepimlibs needs to be released in any case and is in very good shape. -- Tom Albers ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Friday 04 January 2008, Lubos Lunak wrote: On Friday 04 of January 2008, Alexander Neundorf wrote: On Thursday 03 January 2008, Luboš Luňák wrote: SVN commit 756696 by lunakl: Consistent naming for xf86misc - include and flag are xf86misc, lib is Xxf86misc. I'm not sure this change is good: This is a source incompatible change. Somebody may use these variables and now they don't exist anymore, so his build may fail. It will at most not detect the feature, but even then that's very unlikely, as xf86misc is only very special functionality. Yes, it is very unlikely, but very unlikely != impossible. The thing is, the names were in sync with the names of the variables in the FindX11.cmake of cmake cvs since several months. So since several months some cmake cvs users may already use that variable. Ok, it is the cvs version only, but still it is there for quite some time already and changing this can break the build of somebody (you never know what somebody does with the variables). So this change means either we can never use the module from cmake or I need to add some transition logic on the cmake side. So is it really necessary to change the name ? We are at the day of the tagging, IMO too late for such changes. It was broken. In which way was it exactly broken ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-cvs-announce] KDE 4.0 Release Branch
On Friday 04 January 2008, Albert Astals Cid wrote: Just to clarify is the /branches/KDE/4.0 and /trunk/l10n-kde4 still frozen for tagging release or not? branches/KDE/4.0 is currently under release-freeze, and will return to stable-freeze (no BIC, bugfixes only, only minor string changes) after KDE 4.0.0 is released. /trunk/l10n-kde4 is currently open for last-minute translation fixes. I`m going to test the l10n tarballs now and will use the chainsaw for anything that is broken. We will branch /trunk/l10n-kde4 to branches/stable/l10n-kde4 when 4.0.0 tagging is finished (estimate tomorrow, 00:00 UTC). From that time on, scripty will work on branches/stable/l10n-kde4 and ignore /trunk (which is open for KDE 4.1 then). Separate announcement about that follows. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Tagging Freeze for KDE 4.0.0
A Divendres 04 Gener 2008, Rafael Fernández López va escriure: On Thursday 03 January 2008 21:08:50, Tom Albers wrote: Reminder: Today (2008/01/03) at midnight UTC we start the Tagging Freeze for KDE 4.0.0. Only allowed changes: compile fixes; *reviewed* fixes of blocker bugs; changes needed to build the release tarballs. Please update your application version numbers today for a 4.0.0 release. For the translators: please no more translations permitted either. We will let you know when trunk is open again for 4.0.1 bug-fixing. The Release Team. The problem with KPluginSelector has been fixed (that one was a blocker). Green light for tagging. The problem was that a bunch of .desktop files were translating a should-not-be-translated X-KDE-PluginInfo-Category field. I completely disagree here, X-KDE-PluginInfo-Category is clearly defined as translatable in ~/l10n-kde4/scripts/createdesktopcontext.pl so it's your problem asuming a field would not be translated when it is. Albert Now all of them are fixed, all KDE modules (from kdelibs to extragear and playground). Bye, Rafael Fernández López GPG Fingerprint: B9F4 4730 43F8 FFDD CC5E BA8E 724E 406E 3F01 D070 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] [Kde-cvs-announce] KDE 4.0 Release Branch
Op vrijdag 4 januari 2008 13:25 schreef u: On Friday 04 January 2008 09:14:21 Dirk Mueller wrote: Hi, a KDE 4.0 Release branch has been created: svn+ssh|https://svn.kde.org/home/kde/branches/KDE/4.0 I notice that kdepim has been included in the branch, even though it's not supposed to be released with 4.0 (unless I missed something). So you don't want to be enabled for any of the 4.0.x releases either? -- Tom Albers ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Friday 04 January 2008, Lubos Lunak wrote: On Friday 04 of January 2008, Alexander Neundorf wrote: Yes, it is very unlikely, but very unlikely != impossible. The thing is, the names were in sync with the names of the variables in the FindX11.cmake of cmake cvs since several months. So since several months some cmake cvs users may already use that variable. Ok, it is the cvs version only, but still it is there for quite some time already and changing this can break the build of somebody (you never know what somebody does with the variables). So this change means either we can never use the module from cmake or I need to add some transition logic on the cmake side. So is it really necessary to change the name ? I guess that depends on which of changing a rarely used name from cmake cvs and having a confusing rarely used name you consider to be worse. I mean, it was that way since February 23rd, 2006, and you changed it now after almost two years only hours before tagging 4.0.0 without sending a patch first. Although unlikely, this was a source incompatible change. We are at the day of the tagging, IMO too late for such changes. It was broken. In which way was it exactly broken ? Somebody got confused by the names and it didn't match in kdebase/workspace/CMakeChecks.cmake. So the fix would have been to fix that single file. Now I have to deal with that in CMake and *hope* nobody has used this already and complains that CMake constantly breaks compatibility :-/ Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] [Kde-cvs-announce] KDE 4.0 Release Branch
On Friday 04 January 2008, Tom Albers wrote: So you don't want to be enabled for any of the 4.0.x releases either? No, thats the purpose of bugfix releases to not introduce major new features. See you with KDE 4.1. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Friday 04 January 2008, Lubos Lunak wrote: On Friday 04 of January 2008, Alexander Neundorf wrote: ... In which way was it exactly broken ? Somebody got confused by the names and it didn't match in kdebase/workspace/CMakeChecks.cmake. You're wrong, there was actually an error inside FindX11.cmake, and you fixed it :-) Here it was spelled wrong: IF (X11_Xxf86misc_INCLUDE_PATH AND X11_Xxf86misc_LIB) I think this is good enough as argument to keep your change and fix/change it in cmake instead. Bye Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Friday 04 January 2008, Lubos Lunak wrote: On Friday 04 of January 2008, Alexander Neundorf wrote: On Friday 04 January 2008, Lubos Lunak wrote: On Friday 04 of January 2008, Alexander Neundorf wrote: Yes, it is very unlikely, but very unlikely != impossible. The thing is, the names were in sync with the names of the variables in the FindX11.cmake of cmake cvs since several months. So since several months some cmake cvs users may already use that variable. Ok, it is the cvs version only, but still it is there for quite some time already and changing this can break the build of somebody (you never know what somebody does with the variables). So this change means either we can never use the module from cmake or I need to add some transition logic on the cmake side. So is it really necessary to change the name ? I guess that depends on which of changing a rarely used name from cmake cvs and having a confusing rarely used name you consider to be worse. I mean, it was that way since February 23rd, 2006, and you changed it now after almost two years only hours before tagging 4.0.0 without sending a patch first. Although unlikely, this was a source incompatible change. Change it back if it's so. What's the current state of 4.0.0 tagging/packaging ? Sorry, I didn't realize we have a copy of large portion of CMake in our SVN. We have a bunch of own cmake modules (which don't exist in CMake) and we have some modified copies of CMake modules there. My goal has been to sync from time to time with cmake, so that later on we can remove some of our own modules and rely on the ones which come with cmake. FindX11.cmake is one of them. Does that mean we shouldn't touch anything under cmake/ ? No, I'm actually happy that there are so many people working on the stuff there :-) Developers just need to be aware that changing things in cmake can also mean source incompatible changes. This also means we have to make sure they stay compatible for all KDE 4.x.y just the same way as we do for the actual sources. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Friday 04 January 2008, Lubos Lunak wrote: On Friday 04 of January 2008, Alexander Neundorf wrote: ... What's the current state of 4.0.0 tagging/packaging ? I'm not sure, but I think 4.0.0 really doesn't matter that much. Can I have that signed and written on paper, please ? ;-) This xf86misc stuff is _very_ obscure, even I barely know what it is. If this gets changed for 4.1 and 4.0.1 in any way, I don't think anybody will notice. Does that mean we shouldn't touch anything under cmake/ ? No, I'm actually happy that there are so many people working on the stuff there :-) Beside that, I tried to keep an eye on the commits to the files there, which cannot have worked 100%, but I hope for a significant part of the commits. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: [Kde-pim] Request to exclude KMail from the KDE 4.0 release
On Friday 04 January 2008 04:59:04 Dirk Mueller wrote: On Friday 07 December 2007, Sebastian Kuegler wrote: Anyway... how to proceed? Simply leave out the kdepim -4.0.0 tarball? Yes. Bad luck, but PIM3 works fine in the meantime. Are we going forward with that idea of dropping kdepim from KDE 4.0 ? Yes, please don't release kdepim with KDE 4.0.0. What about kdepimlibs? Please release kdepimlibs with KDE 4.0.0. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Green light from the Oxygen team
On Thursday 03 January 2008 21:19:39 Riccardo Iaconelli wrote: Hello, as there have been some issues, I just wanted to give a green light in behalf of the whole Oxygen team: every little piece we've preventivated has fallen into its place, works nicely, and we're ready and set for a great release! =) Riccardo, Sorry for all the mis-communications and issues. We'll try to be more explicit about artwork deadlines in the future. Oxygen is beautiful, gorgeous, glowing, ... and great. All the artists should be very proud of their work. Regards, Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-cvs-announce] KDE 4.0 Release Branch
On Friday 04 January 2008 09:14:21 Dirk Mueller wrote: Hi, a KDE 4.0 Release branch has been created: svn+ssh|https://svn.kde.org/home/kde/branches/KDE/4.0 I notice that kdepim has been included in the branch, even though it's not supposed to be released with 4.0 (unless I missed something). -- David Jarvie. KAlarm author and maintainer. http://www.astrojar.org.uk/kalarm ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] [Kde-cvs-announce] KDE 4.0 Release Branch
On Friday 04 January 2008 12:29:20 Tom Albers wrote: Op vrijdag 4 januari 2008 13:25 schreef u: On Friday 04 January 2008 09:14:21 Dirk Mueller wrote: Hi, a KDE 4.0 Release branch has been created: svn+ssh|https://svn.kde.org/home/kde/branches/KDE/4.0 I notice that kdepim has been included in the branch, even though it's not supposed to be released with 4.0 (unless I missed something). So you don't want to be enabled for any of the 4.0.x releases either? I'm simply observing that kdepim was as far as I understood not to be included. I'm okay with KAlarm being included, but is KMail, for example, ready yet? -- David Jarvie. KAlarm author and maintainer. http://www.astrojar.org.uk/kalarm ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Tagging Freeze for KDE 4.0.0
Am Freitag, 4. Januar 2008 13:05:44 schrieb Albert Astals Cid: A Divendres 04 Gener 2008, Rafael Fernández López va escriure: On Thursday 03 January 2008 21:08:50, Tom Albers wrote: Reminder: Today (2008/01/03) at midnight UTC we start the Tagging Freeze for KDE 4.0.0. Only allowed changes: compile fixes; *reviewed* fixes of blocker bugs; changes needed to build the release tarballs. Please update your application version numbers today for a 4.0.0 release. For the translators: please no more translations permitted either. We will let you know when trunk is open again for 4.0.1 bug-fixing. The Release Team. The problem with KPluginSelector has been fixed (that one was a blocker). Green light for tagging. The problem was that a bunch of .desktop files were translating a should-not-be-translated X-KDE-PluginInfo-Category field. I completely disagree here, X-KDE-PluginInfo-Category is clearly defined as translatable in ~/l10n-kde4/scripts/createdesktopcontext.pl so it's your problem asuming a field would not be translated when it is. No, Albert, it was me who added the field in this file above. I did it with translation in mind because it was needed in a specific place (plasmoid chooser), but I had no idea that it could cause any problems. Bye, Thomas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Friday 04 of January 2008, Alexander Neundorf wrote: Yes, it is very unlikely, but very unlikely != impossible. The thing is, the names were in sync with the names of the variables in the FindX11.cmake of cmake cvs since several months. So since several months some cmake cvs users may already use that variable. Ok, it is the cvs version only, but still it is there for quite some time already and changing this can break the build of somebody (you never know what somebody does with the variables). So this change means either we can never use the module from cmake or I need to add some transition logic on the cmake side. So is it really necessary to change the name ? I guess that depends on which of changing a rarely used name from cmake cvs and having a confusing rarely used name you consider to be worse. We are at the day of the tagging, IMO too late for such changes. It was broken. In which way was it exactly broken ? Somebody got confused by the names and it didn't match in kdebase/workspace/CMakeChecks.cmake. -- Lubos Lunak KDE developer -- SUSE LINUX, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED] Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http//www.suse.cz ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-cvs-announce] KDE 4.0 Release Branch
On Friday 04 January 2008 12:56:27 Dirk Mueller wrote: /trunk/l10n-kde4 is currently open for last-minute translation fixes. I`m going to test the l10n tarballs now and will use the chainsaw for anything that is broken. We will branch /trunk/l10n-kde4 to branches/stable/l10n-kde4 when 4.0.0 tagging is finished (estimate tomorrow, 00:00 UTC). From that time on, scripty will work on branches/stable/l10n-kde4 and ignore /trunk (which is open for KDE 4.1 then). Separate announcement about that follows. So there will no longer be a branch for KDE 3.5 translations? Does this mean that no more translation commits can be made for KDE 3.5, even though code bug fixes can still be made? -- David Jarvie. KAlarm author and maintainer. http://www.astrojar.org.uk/kalarm ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-cvs-announce] KDE 4.0 Release Branch
On Friday 04 January 2008, David Jarvie wrote: So there will no longer be a branch for KDE 3.5 translations? Does this mean that no more translation commits can be made for KDE 3.5, even though code bug fixes can still be made? There is still a branch for 3.5 translations (/branches/stable/l10n and trunk/l10n-kde3) but spending a lot of time on those is really deprecated. We have to move on, splitting ressources between KDE3 and KDE4 is not getting us anywhere. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
branches/KDE/4.0/kdelibs/kdeui
SVN commit 757402 by ervin:
Reverting commit 757034 which was completely preventing to configure any
global shortcut. This issue will obviously require more investigation...
OK'd by Tom Albers.
We probably want that hotfix in the 4.0.0 tag. Otherwise we're shipping
a desktop where we can't configure the desktop related (kwin, krunner,
plasma) shortcuts and any other global shortcuts.
Dirk, any chance to get that in the release?
CCMAIL: [EMAIL PROTECTED]
CCMAIL: release-team@kde.org
M +1 -11 actions/kaction.h
M +8 -16 shortcuts/kglobalaccel.cpp
--- branches/KDE/4.0/kdelibs/kdeui/actions/kaction.h #757401:757402
@@ -341,7 +341,7 @@
* Unlike regular shortcuts, the application's window does not need focus
* for them to be activated.
*
- * When an action is assigned
+ * When an action, identified by main component name and text(), is
assigned
* a global shortcut for the first time on a KDE installation the
assignment will
* be saved. The shortcut will then be restored every time the action's
* globalShortcutAllowed flag becomes true.
@@ -353,16 +353,6 @@
* setGlobalShortcut(KShortcut(), KAction::ActiveShortcut |
KAction::DefaultShortcut,
* KAction::NoAutoloading)
* \endcode
- * Note that actions will be recognized by their objectName() internally.
- * In case of an empty objectName() text() will be used as a fallback.
- * This fallback should be avoided if possible because it breaks
- * when the application language is changed.
- * Inserting an action into a KActionCollection with
- * QAction *KActionCollection::addAction(const QString name, QAction
*action) or
- * KAction *KActionCollection::addAction(const QString name, KAction
*action)
- * will set the objectName() to @p name so you don't have to explicitly
set an
- * objectName after you have already done that.
-
* \param shortcut global shortcut(s) to assign
* \param type the type of shortcut to be set, whether the active
shortcut, the default shortcut,
* or both (the default).
--- branches/KDE/4.0/kdelibs/kdeui/shortcuts/kglobalaccel.cpp #757401:757402
@@ -144,15 +144,11 @@
if (oldEnabled == newEnabled)
return;
-QString actionName(action-objectName());
-if (actionName.isEmpty()) {
-if (action-text().isEmpty()) {
-return;
-}
-actionName = action-text();//### breaks badly on change of
language
-}
+if (action-text().isEmpty())
+return;
QStringList actionId(mainComponentName);
-actionId.append(actionName);
+actionId.append(action-text());
+//TODO: what about i18ned names?
if (!oldEnabled newEnabled) {
uint setterFlags = KdedGlobalAccel::SetPresent;
@@ -184,15 +180,11 @@
if (!action)
return;
-QString actionName(action-objectName());
-if (actionName.isEmpty()) {
-if (action-text().isEmpty()) {
-return;
-}
-actionName = action-text();//### breaks badly on change of
language
-}
+if (action-text().isEmpty())
+return;
QStringList actionId(mainComponentName);
-actionId.append(actionName);
+actionId.append(action-text());
+//TODO: what about i18ned names?
uint setterFlags = 0;
if (flags KAction::NoAutoloading)
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
