Re: [PATCH 1/3] Drop KDE_NO_PHONON, Phonon works on Qt5 now.
Hi Jon,
What's the status on phonon-for-Qt5? If all changes got merged in, maybe this
patch can be applied to kdelibs-frameworks?
Thanks!
On Sunday 07 October 2012 01:27:13 Jon Severinsson wrote:
---
CMakeLists.txt| 10 +-
interfaces/CMakeLists.txt |4 +---
knotify/config/knotifyconfigactionswidget.cpp |2 --
3 filer ändrade, 2 tillägg(+), 14 borttagningar(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index e8f3ea0..a44727e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -362,12 +362,6 @@ endif(STATIC_LIBRARY)
configure_file(config-prefix.h.cmake
${CMAKE_CURRENT_BINARY_DIR}/config-prefix.h )
configure_file(config-compiler.h.cmake
${CMAKE_CURRENT_BINARY_DIR}/config-compiler.h )
-# TODO: Port away from this:
-if (QT5_BUILD)
- add_definitions(-DKDE_NO_PHONON)
- set(KDE_NO_PHONON True)
-endif()
-
# Needed for the calls to kconfig_add_kcfg_files in some modules
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
${CMAKE_SOURCE_DIR}/tier2/kconfig/cmake) set(KCONFIG_KCFGC_EXECUTABLE
kconfig_compiler)
@@ -407,9 +401,7 @@ endif(NOT WINCE)
add_subdirectory( kioslave )
add_subdirectory( kparts )
add_subdirectory( kunitconversion )
-if(NOT KDE_NO_PHONON)
-add_subdirectory( khtml )
-endif()
+add_subdirectory( khtml )
add_subdirectory( interfaces )
if (NOT QT5_BUILD) # TODO: Qt5UiTools_FOUND
add_subdirectory( kross )
diff --git a/interfaces/CMakeLists.txt b/interfaces/CMakeLists.txt
index d496d01..1e0eff1 100644
--- a/interfaces/CMakeLists.txt
+++ b/interfaces/CMakeLists.txt
@@ -3,9 +3,7 @@
project(interfaces)
add_subdirectory( kregexpeditor )
-if (NOT KDE_NO_PHONON)
- add_subdirectory( kmediaplayer )
-endif()
+add_subdirectory( kmediaplayer )
add_subdirectory( kio )
add_subdirectory( terminal )
add_subdirectory( khexedit )
diff --git a/knotify/config/knotifyconfigactionswidget.cpp
b/knotify/config/knotifyconfigactionswidget.cpp index de892fe..5791c62
100644
--- a/knotify/config/knotifyconfigactionswidget.cpp
+++ b/knotify/config/knotifyconfigactionswidget.cpp
@@ -134,11 +134,9 @@ void KNotifyConfigActionsWidget::slotPlay( )
if ( search.isEmpty() )*/
soundURL = QUrl::fromLocalFile(KStandardDirs::locate(sound,
soundString)); }
-#ifndef KDE_NO_PHONON
Phonon::MediaObject* media = Phonon::createPlayer(
Phonon::NotificationCategory, soundURL ); media-play();
connect(media, SIGNAL(finished()), media, SLOT(deleteLater()));
-#endif
}
void KNotifyConfigActionsWidget::slotKTTSComboChanged()
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Build failure with Qt 5
On Friday 26 October 2012 16:52:29 Stephen Kelly wrote: Hi, A recent patch of mine makes the frameworks branch fail to build with Qt 5: https://codereview.qt-project.org/#change,37624 I made it not possible to emit the aboutToQuit signal, which apparently KApplication tries to do. I don't know the X code that KApplication is using which tries to emit that signal in response (iceIOErrorHandler). libICE is used for session management, and was also used in KDE3 for DCOP. Is that something that should be done in Qt itself? Yes, whenever session management gets implemented again in Qt... right now it's completely missing in Qt5 :-( For now I think it's ok to just ignore that error handler, the complete lack of session management code is the bigger problem that this issue is part of. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KWallet plugin logic implementation inside frameworks
Hello Valentin, Sorry for the delayed reply, too many conferences this month ;) On Sunday 04 November 2012 16:03:12 Valentin Rusu wrote: Hello, Now that I'm using a plug-in version of the KWallet API on my system, I think it would be the time to put it at the right place inside the frameworks branch, if you don't mind. Sounds good. The logic actually lives inside kdelibs/ksecretsservice branch and, despite that branch's name, the only changes it brings to kdelibs for the moment is the kwallet plugin logic. Ah, OK. Indeed, I wouldn't have guessed :) KWallet class actually lives inside kdeui. I modified it to load a plugin and delegate all the method calls to a plugin it loads when first called. I also added a new header file intended for plugin implementers, declaring the needed methods. See also [1] My first reaction was, do we really need plugins, if secret-service is the way forward. But indeed on Windows and Mac OS, I presume another backend will be necessary, so this is probably a good design for this issue. A bit like QPA, in fact :) First question (and proposed answer) : which tier should KWallet class live in? staging, for now :-) I already think it's a functional kind of class and because it needs plugin loading Beep, incompatibility here. The type functional means it's only a library. Plugins are runtime dependencies, so this is an integration framework (confirmed by the fact that it aims at integrating with the OS wallet service). But anyway, type classification is only to make Kévin happy, for now, it's not used anywhere yet. , it should go to tier3. Possible. Depends on its dependencies, really. Make the framework first, in staging, then we can look at its dependencies. When grepping for kwallet includes inside frameworks branch, I find that ./kdewebkit/kwebwallet.cpp:#include kwallet.h ./kdeui/tests/kwallettest.cpp:#include kwallet.h ./kdeui/util/kwallet.cpp:#include kwallet.h ./kdeui/util/kwallet.cpp:#include config-kwallet.h ./kdeui/util/kwallet_mac.cpp:#include kwallet.h ./khtml/html/html_formimpl.cpp:#include kwallet.h ./kio/kssl/ksslkeygen.cpp:#include kwallet.h ./plasma/remote/authorizationmanager.cpp:#include kwallet.h All these classes, if I understand correctly, will also live in tier3, so the dependency rule will not be broken [2]. Probably right. So I propose to: - move KWallet API inside the tier3/kwallet to be created library - update the dependencies to reflect that Make it staging/kwallet for now. And make sure to respect the directory structure described at http://community.kde.org/Frameworks/Policies#Framework_directory_structure Second issue (and proposal): where should go the kwalletdefaultplugin? This plugin actually contains the old KWallet API implementation, the one which calls the kwalletd. I think the best place for kwalletdefaultplugin should be kde-runtime/kwalletd. This way, this plugin will get installed at the same time as the daemon it communicates with. In a different subdirectory of the same framework, as Jon said. If the plugin doesn't exist in 4.x, then there's no merging issue, though, you can put it in the framework already. He's right about the existing kde-runtime code though, it would be best not to touch that one yet. I guess this might make it difficult for you to test the whole thing, though... Unless the daemon is mostly unchanged, for now? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [PATCH 1/3] Drop KDE_NO_PHONON, Phonon works on Qt5 now.
David Faure wrote: Hi Jon, What's the status on phonon-for-Qt5? If all changes got merged in, maybe this patch can be applied to kdelibs-frameworks? I think KDE_NO_PHONON still has value anyway. It makes it easier to do things in the frameworks branch because you don't have to build all 'kdelibs dependencies' first. That makes it easier to do eg buildsystem stuff, splitting kdeui etc. If you remove KDE_NO_PHONON, please make it possible to build the rest of the frameworks branch without requiring phonon. Eg using if(PHONON_FOUND) add_subdirectory(foo) endif() That would be actual progress toward what we want to do anyway. Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KWallet plugin logic implementation inside frameworks
On Wednesday 21 November 2012 13:28:28 David Faure wrote: Beep, incompatibility here. The type functional means it's only a library. Plugins are runtime dependencies, so this is an integration framework (confirmed by the fact that it aims at integrating with the OS wallet service). But anyway, type classification is only to make Kévin happy, for now, it's not used anywhere yet. LOL. :-) Well, not only to make me happy, it also means that no functional framework can use that one. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KWallet plugin logic implementation inside frameworks
On 11/21/2012 01:28 PM, David Faure wrote: Second issue (and proposal): where should go the kwalletdefaultplugin? This plugin actually contains the old KWallet API implementation, the one which calls the kwalletd. I think the best place for kwalletdefaultplugin should be kde-runtime/kwalletd. This way, this plugin will get installed at the same time as the daemon it communicates with. In a different subdirectory of the same framework, as Jon said. If the plugin doesn't exist in 4.x, then there's no merging issue, though, you can put it in the framework already. He's right about the existing kde-runtime code though, it would be best not to touch that one yet. I guess this might make it difficult for you to test the whole thing, though... Unless the daemon is mostly unchanged, for now? The daemon *will* stay unchanged. There's no need for touching it. Letting it where it is will not prevent me to test the plug-in logic, especially the daemon not found case -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Sonnet status?
On Fri, Nov 09, 2012 at 01:15:49AM +0100, David Faure wrote: From a frameworks point of view, sonnet has had its core moved into staging (as you can see in a frameworks checkout). It needs simple porting from i18n to QCoreApplication::translate(, ...) to have no more kdecore dependency, and then the core framework is done, iirc. https://git.reviewboard.kde.org/r/107412/ It's just that it currently depends on KConfig for *one* setting, maybe this could be done differently so as not to have this dependency. Could I just use QSettings there? Or is there a better solution? -- Martin Sandsmark ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: cmake 2.8.10.1 will be required in the next days for the frameworks branch
On Sunday 18 November 2012, Alexander Neundorf wrote: Hi, in the next days I'll update the required cmake version for e-c-m and the kdelibs framework branch to 2.8.10.1 (http://www.cmake.org/cmake/resources/software.html). 2.8.10.1 is required now, I just pushed it. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Sonnet status?
On Wed, Nov 21, 2012 at 09:00:27PM +0100, Martin Sandsmark wrote: https://git.reviewboard.kde.org/r/107412/ Bah, I'm stupid, I didn't see the usage of KLocale to get localized country and language names. Which is going to be much harder to replace, I think it might need improvements in QLocale itself. -- Martin Sandsmark ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request: Don't append 0- when dragging and dropping from trash
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105078/#review22311
---
Ship it!
Starting to look good :-)
Just one minor code issue, and then commit.
I see that the trash.protocol change isn't included, we'll look at that
separately? (probably a good idea)
kioslave/trash/kio_trash.cpp
http://git.reviewboard.kde.org/r/105078/#comment17146
Can you rename it to fileDisplayName, if that's what it's used for? This
will make it more consistent with listDir.
Even better: move this to a common helper file-static function in the .cpp
file.
Input: relativePath, fileId
Output: fileDisplayName
= static QString makeDisplayName(const QString relativePath, const
QString fileId) { ... }
- David Faure
On Nov. 16, 2012, 2:19 a.m., Michael Reeves wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105078/
---
(Updated Nov. 16, 2012, 2:19 a.m.)
Review request for KDE Runtime.
Description
---
This patch makes drag-and-drop and cut/paste from trash preserve the orginal
filename instead of appending 0-.
This addresses bug 183403.
http://bugs.kde.org/show_bug.cgi?id=183403
Diffs
-
kioslave/trash/kio_trash.cpp 138bab3
Diff: http://git.reviewboard.kde.org/r/105078/diff/
Testing
---
I have used the modified io_trash module on my machine since before the KDE
4.8 release and still use it under KDE 4.8.3.
Thanks,
Michael Reeves
ABI break -- kdepimlims 4.9.3
Hello,
while packaging kdepimlibs 4.9.3 I found what I think it's an ABI break in
libkabc; looks like the ABI break was introduced in this commit:
https://projects.kde.org/projects/kde/kdepimlibs/repository/revisions/da16f7d5
The attached patch applies to 4.9.3 and solves the problem. If the patch is
acceptable for you I can commit and push it to git.
Thank you for your time.
--- a/kabc/scripts/addressee.src.cpp
+++ b/kabc/scripts/addressee.src.cpp
@@ -544,7 +544,7 @@ void Addressee::removeKey( const Key ke
}
}
-Key Addressee::key( Key::Type type, const QString customTypeString ) const
+Key Addressee::key( Key::Type type, QString customTypeString ) const
{
Key::List::ConstIterator it;
Key::List::ConstIterator end(d-mKeys.constEnd());
@@ -575,7 +575,7 @@ Key::List Addressee::keys() const
return d-mKeys;
}
-Key::List Addressee::keys( Key::Type type, const QString customTypeString ) const
+Key::List Addressee::keys( Key::Type type, QString customTypeString ) const
{
Key::List list;
--- a/kabc/scripts/addressee.src.h
+++ b/kabc/scripts/addressee.src.h
@@ -276,7 +276,7 @@ class KABC_EXPORT Addressee
@param customTypeString A string to match custom keys against when
@p type is @c Key::Custom
*/
-Key key( Key::Type type, const QString customTypeString = QString() ) const;
+Key key( Key::Type type, QString customTypeString = QString() ) const;
/**
Return list of all keys.
@@ -299,7 +299,7 @@ class KABC_EXPORT Addressee
@param customTypeString A string to match custom keys against when
@p type is @c Key::Custom
*/
-Key::List keys( Key::Type type, const QString customTypeString = QString() ) const;
+Key::List keys( Key::Type type, QString customTypeString = QString() ) const;
/**
Return key with the given id.
signature.asc
Description: This is a digitally signed message part.
Moving Trojitá to extragear
Hi, thanks for your encouragement. Trojitá, a fast IMAP e-mail client (homepage [1], more in-depth look [2], the KDE project page [3]) has spent the last week or so under playground and was just moved to kdereview (thanks to sysadmins for their excellent turnaround time). I'd appreciate people taking a look at the code [4]; I'm looking forward to your feedback. I'm hereby requesting a review for a move below the extragear/pim. I've got a few questions or comments: 1) User's docs. Is it a hard requirement to have a documentation basically describing how the menus look like? 2) Krazy issues. I'm in the process of fixing many of them, but there are quite a few false positives. I've been told by the maintainers that some of them (like calling a QByteArray::startsWith(const char *)) are basically unfixable in the current Krazy. My opinion is that maintaining explicit excludes for these kinds of issues is not something which I would love to do. What's the consensus in KDE -- are these issues showstoppers? 3) Internationalization. The applciation uses QObject::tr(), not i18n() calls as it does not link to the KDE libraries. As I've outlined in my original e-mail, being able to build without KDE is something that I do not want to break. I've heard that there are options for making this work, I plan to investigate this in depth. Looking forward to your comments and feedback. With kind regards, Jan [1] http://trojita.flaska.net/ [2] https://projects.flaska.net/projects/trojita/wiki/Trojita [3] https://projects.kde.org/projects/kdereview/trojita [4] http://quickgit.kde.org/?p=trojita.git
Re: ABI break -- kdepimlims 4.9.3
On Wednesday 21 November 2012 12:32:45 PM José Manuel Santamaría Lema wrote: Hello, while packaging kdepimlibs 4.9.3 I found what I think it's an ABI break in libkabc; looks like the ABI break was introduced in this commit: https://projects.kde.org/projects/kde/kdepimlibs/repository/revisions/da16f7d5 The attached patch applies to 4.9.3 and solves the problem. If the patch is acceptable for you I can commit and push it to git. Thank you for your time. Yep. Thanks for finding and fixing. -Allen
Review Request: port sonnet away from i18nc
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107412/ --- Review request for kdelibs and David Faure. Description --- port sonnet away from i18nc. Diffs - staging/sonnet/src/core/loader.cpp 887aee5 Diff: http://git.reviewboard.kde.org/r/107412/diff/ Testing --- it builds. Thanks, Martin Tobias Holmedahl Sandsmark
Re: Review Request: port sonnet away from i18nc
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107412/ --- (Updated Nov. 21, 2012, 7:47 p.m.) Review request for kdelibs and David Faure. Description --- port sonnet away from i18nc. Diffs - staging/sonnet/src/core/loader.cpp 887aee5 Diff: http://git.reviewboard.kde.org/r/107412/diff/ Testing --- it builds. Thanks, Martin Tobias Holmedahl Sandsmark
Re: Moving Trojitá to extragear
El Dimecres, 21 de novembre de 2012, a les 19:43:13, Jan Kundrát va escriure: Hi, thanks for your encouragement. Trojitá, a fast IMAP e-mail client (homepage [1], more in-depth look [2], the KDE project page [3]) has spent the last week or so under playground and was just moved to kdereview (thanks to sysadmins for their excellent turnaround time). I'd appreciate people taking a look at the code [4]; I'm looking forward to your feedback. I'm hereby requesting a review for a move below the extragear/pim. I've got a few questions or comments: 1) User's docs. Is it a hard requirement to have a documentation basically describing how the menus look like? 2) Krazy issues. I'm in the process of fixing many of them, but there are quite a few false positives. I've been told by the maintainers that some of them (like calling a QByteArray::startsWith(const char *)) are basically unfixable in the current Krazy. My opinion is that maintaining explicit excludes for these kinds of issues is not something which I would love to do. What's the consensus in KDE -- are these issues showstoppers? 3) Internationalization. The applciation uses QObject::tr(), not i18n() calls as it does not link to the KDE libraries. As I've outlined in my original e-mail, being able to build without KDE is something that I do not want to break. I've heard that there are options for making this work, I plan to investigate this in depth. No, at the moment our workflow does not support translations of applications that don't use kdecore. I.e. if you don't use i18n() or tr() + kdecore (and actually this one has a missing feature because someone in Qt decided to make a method not virtual) you can't get our .po/.mo system work-flow to work. Not having translations seems a big issue to me. Cheers, Albert Looking forward to your comments and feedback. With kind regards, Jan [1] http://trojita.flaska.net/ [2] https://projects.flaska.net/projects/trojita/wiki/Trojita [3] https://projects.kde.org/projects/kdereview/trojita [4] http://quickgit.kde.org/?p=trojita.git
Re: Moving Trojitá to extragear
On Mittwoch, 21. November 2012 20:53:14 CEST, Albert Astals Cid wrote: I.e. if you don't use i18n() or tr() + kdecore (and actually this one has a missing feature because someone in Qt decided to make a method not virtual) you can't get our .po/.mo system work-flow to work. Not having translations seems a big issue to me. Could this be sedfixed? Ie. the .po and .ts files have different structure but afaics similar content (location, string, translation), so would it be possible to auto-generate the .ts out of the .po for the Qt only build or has this been tryfailed before? Cheers, Thomas
Re: Review Request: port sonnet away from i18nc
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107412/#review22346 --- staging/sonnet/src/core/loader.cpp http://git.reviewboard.kde.org/r/107412/#comment17157 You're mixing context (= class name in Qt itself, empty in KF5) and disambiguation (= comment). This should be QCoreApplication::translate(, variantEnglish, dictionary variant). Same for all other i18nc calls ported to translate... - David Faure On Nov. 21, 2012, 7:47 p.m., Martin Tobias Holmedahl Sandsmark wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107412/ --- (Updated Nov. 21, 2012, 7:47 p.m.) Review request for kdelibs and David Faure. Description --- port sonnet away from i18nc. Diffs - staging/sonnet/src/core/loader.cpp 887aee5 Diff: http://git.reviewboard.kde.org/r/107412/diff/ Testing --- it builds. Thanks, Martin Tobias Holmedahl Sandsmark
Re: Moving Trojitá to extragear
написане Wed, 21 Nov 2012 20:43:13 +0200, Jan Kundrát j...@flaska.net: 1) User's docs. Is it a hard requirement to have a documentation basically describing how the menus look like? No. But it's a good practice [0]. Nobody needs to know how the menu looks like (if you do not mind about accessibility) but it is good to know if there are non-obvious features or some advices about workflow and configuration. ;) As you do not have i18n (why it can be like in other pure-Qt and Gettext-based applications like LyX or Marble?), it is of no sense to have DocBook docs, but you can consider to put something (at least a link on [1]) on UserBase [2]. Just my 2 cents. Best regards, Yuri [0] http://techbase.kde.org/Projects/Documentation/KDE4_(health_table)#Extragear [1] http://userbase.kde.org/Applications/Office [2] http://userbase.kde.org
Re: Moving Trojitá to extragear
El Dimecres, 21 de novembre de 2012, a les 21:52:43, Thomas Lübking va escriure: On Mittwoch, 21. November 2012 20:53:14 CEST, Albert Astals Cid wrote: I.e. if you don't use i18n() or tr() + kdecore (and actually this one has a missing feature because someone in Qt decided to make a method not virtual) you can't get our .po/.mo system work-flow to work. Not having translations seems a big issue to me. Could this be sedfixed? po2ts might be actually a better solution than using sed Ie. the .po and .ts files have different structure but afaics similar content (location, string, translation), so would it be possible to auto-generate the .ts out of the .po for the Qt only build or has this been tryfailed before? It might work yes, but to be honest I have a workload big enough for now that supporting people that doesn't want to use kdecore. On the other hand we will have to support something like this since the frameworks effort has decided their first tier needs translations and can't use i18n() so if anyone was to work on this it'd be useful for KF5 too. Cheers, Albert Cheers, Thomas
Review Request: Use static KNS3::DownloadDialog in PlasmoidPackage
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107413/ --- Review request for kdelibs. Description --- Switch from QWeakPointer to staticaly created KNS3::DownloadDialog like in some KControl modules (i.e color scheme) to fix the problem when the list with widgets is not downloaded every time you open it. Should fix this issue https://bugzilla.redhat.com/show_bug.cgi?id=877021 Diffs - plasma/private/packages.cpp 2519341 plasma/private/packages_p.h 15fde41 Diff: http://git.reviewboard.kde.org/r/107413/diff/ Testing --- Thanks, Jan Grulich
Re: Review Request: Use static KNS3::DownloadDialog in PlasmoidPackage
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107413/ --- (Updated Nov. 22, 2012, 12:25 a.m.) Review request for kdelibs. Description --- Switch from QWeakPointer to staticaly created KNS3::DownloadDialog like in some KControl modules (i.e color scheme) to fix the problem when the list with widgets is not downloaded every time you open it. Should fix this issue https://bugzilla.redhat.com/show_bug.cgi?id=877021 Diffs - plasma/private/packages.cpp 2519341 plasma/private/packages_p.h 15fde41 Diff: http://git.reviewboard.kde.org/r/107413/diff/ Testing --- Thanks, Jan Grulich
Re: Nepomuk Tags kioslave - Please Review
On Wednesday 07 November 2012 02:27:17 Albert Astals Cid wrote: Ahh, you mean copying from file: to tags: Moving from file: to tags:, rather. I see... I'd like to hear David's opinion on how that is going to be fixed at the kio/kioslave level. Not at that level. Apps should be able to call move and end up with a move. But the fix is to let drag-n-drop trigger a copy rather than allowing the user to select move. The quick fix for that is http://www.davidfaure.fr/2012/konq_operations.cpp.diff Which hardcodes the protocol name, but at least it gets the job done. If we agree about this on principle, then the next step to make it generic could be to add another field in .protocol files, say forceDropAction=(copy|move) The fact that kio_trash needs forceDropAction=move shows that this might make sense, we already have two users for this setting. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
[PATCH] Fix buttons accessibility in KMenuEdit (Bug296682)
Hi, This is a patch for the bug https://bugs.kde.org/show_bug.cgi?id=296682 It prevents to make buttons as inactive after having deleted or cutted an item. Thus, this bug does not only concern the delete button after having deleted an item, but also the following buttons : cut and copy, after having deleted OR cutted an item. It's my first patch submit :), I wanted to post it in the ReviewBoard, but it seems that the Kmenuedit group does not exist. Thanks patch.diff Description: Binary data Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: KStandardAction source code
On Friday, 2012-11-09, Jan Kalcic wrote: On 11/08/2012 07:04 AM, Kevin Krammer wrote: Hi, On Wednesday, 2012-11-07, Jan Kalcic wrote: Hi, I have a Qt app which I am little-by-little moving to KDE, with this I mean I am switching from Qt classes to KDE ones where possible. With this I am now adding new KStandardAction(s), very quick and easy, but AFAIU these only provides predefined menu items via XMLGUI technology, but not the slot implementation code. So for example, if I want to use the copy KStandardAction, I anyway need to write the source code for the slot this action is connected to. Yes, because what copy means is very much dependent on what I fully the application does, i.e. what kind of content your application is editing. A file manager will copy a list of file URLs to the clipboard, a text editor would copy some plain text, a web browser might copy plain text and/or HTML, an image editor some pixel data. The classes holding the data will have different API, different variable names, etc. There is just no way to share this in a generic way. I understand, it really makes sense to me. However my wondering was because of the behavior of copy and paste, for example, which just copy and paste what selected whatever and whereever it is, like if it was over the applications and shared by them. Trying to say it with different words, in my app I can easily do Ctrl+C and Ctrl-C and this simply work. However, if I want the same for my actions I have to write the whole code while it seems it is already there somewhere :-) It is more likely that whatever widget you are dealing with has built-in support for clipboard operations. For example QTextEdit does. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Nepomuk Tags kioslave - Please Review
El Dimecres, 21 de novembre de 2012, a les 16:15:01, David Faure va escriure: On Wednesday 07 November 2012 02:27:17 Albert Astals Cid wrote: Ahh, you mean copying from file: to tags: Moving from file: to tags:, rather. Right I see... I'd like to hear David's opinion on how that is going to be fixed at the kio/kioslave level. Not at that level. Apps should be able to call move and end up with a move. Even if that means destroying the file into hyperspace? But the fix is to let drag-n-drop trigger a copy rather than allowing the user to select move. The quick fix for that is http://www.davidfaure.fr/2012/konq_operations.cpp.diff Which hardcodes the protocol name, but at least it gets the job done. If we agree about this on principle, then the next step to make it generic could be to add another field in .protocol files, say forceDropAction=(copy|move) The fact that kio_trash needs forceDropAction=move shows that this might make sense, we already have two users for this setting. I guess that works for me, since apps won't probably ever call move into a tags: url Cheers, Albert Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [PATCH] Fix buttons accessibility in KMenuEdit (Bug296682)
El Dimecres, 21 de novembre de 2012, a les 19:05:18, Julien va escriure: Hi, This is a patch for the bug https://bugs.kde.org/show_bug.cgi?id=296682 It prevents to make buttons as inactive after having deleted or cutted an item. Thus, this bug does not only concern the delete button after having deleted an item, but also the following buttons : cut and copy, after having deleted OR cutted an item. It's my first patch submit :), I wanted to post it in the ReviewBoard, but it seems that the Kmenuedit group does not exist. Since kmenuedit is in kde-workspace that is the group you have to use the kde- workspace group Oh wait, there's no kde-workspace group :D Maybe kde-baseapps? Anyway, i had a look at the patch and gave it a quick test and it works for me. If noone disagrees i'll commit it in about 24 hours. Cheers, Albert Thanks Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [PATCH] Fix buttons accessibility in KMenuEdit (Bug296682)
于 2012年11月22日 02:05, Julien 写道: Hi, This is a patch for the bug https://bugs.kde.org/show_bug.cgi?id=296682 It prevents to make buttons as inactive after having deleted or cutted an item. Thus, this bug does not only concern the delete button after having deleted an item, but also the following buttons : cut and copy, after having deleted OR cutted an item. It's my first patch submit :), I wanted to post it in the ReviewBoard, but it seems that the Kmenuedit group does not exist. Thanks Aha. Just for the record, I posted a similar review request a few weeks ago at https://git.reviewboard.kde.org/r/105778/ . Unfortunately, nobody gave a single comment :( So there are two problems : 1. there is no dedicated maintainer for kmenuedit. Is there? 2. there is no appropriate group for kmenuedit on reviewboard. Plasma devs are neither suitable nor interested in reviewing patches for kmenuedit. As for the patch, no objection from me. Regards Jekyll Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [PATCH] Fix buttons accessibility in KMenuEdit (Bug296682)
On Wednesday 21 November 2012 19:05:18 Julien wrote: Hi, This is a patch for the bug https://bugs.kde.org/show_bug.cgi?id=296682 It prevents to make buttons as inactive after having deleted or cutted an item. Thus, this bug does not only concern the delete button after having deleted an item, but also the following buttons : cut and copy, after having deleted OR cutted an item. It's my first patch submit :), I wanted to post it in the ReviewBoard, but it seems that the Kmenuedit group does not exist. Thanks Thanks for the investigation. The patch is wrong, though. In TreeView::itemSelected() the actions are explictely re-enabled. Due to a Qt3 - Qt4 porting regression, the connection (see line 210), is wrong. To keep track of newly selected items, you should connect to itemSelectionChanged, not currentItemChanged signal. Also, the setCurrentItem calls are probably wrong, too. In Qt4, current != selected, so to reselect the next item after cut/delete, you have to use the overload that accepts the QItemSelectionModel::SelectionFlags command. Christoph Feck (kdepepo) KDE Quality Team Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [Kde-hardware-devel] Review Request: Handle unsupported actions quietly
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107257/ --- (Updated Nov. 21, 2012, 7:20 p.m.) Review request for Solid. Changes --- Record an appropriate error code during action initialisation. Add error codes for the other ways initialisation might fail. Description (updated) --- Handle unsupported actions quietly Attempting to load a configured action on a machine where it is not supported (e.g. DPMS when the display doesn't support it or it is not compiled in) fails and brings up a notification, something that is particularly intrusive during login. Provide a method for ActionPool::loadAction callers to ask why the load failed. PowerDevil::Core::loadProfile uses this check to decide whether to warn to stderr rather than notifying the user of a misconfiguration. Other loadAction callers are unchanged. Action loading failure may be due to an error during initialisation or simply because no such action exits. In the former case the error must be recorded so that it is available to pass on to later loadAction callers. NB: A more complete fix might involve detecting whether the action is supportable when loading the action configuration and/or in the profile generator. However that may not turn out to be a feasible approach. BUG: 302846 Diffs (updated) - powerdevil/daemon/powerdevilactionpool.h 8a94eacc8ef2c2aead8cb075cbc80b783c1aeb4c powerdevil/daemon/powerdevilactionpool.cpp a9950f174fe184b8faa54c54fc00654984c65b3f powerdevil/daemon/powerdevilcore.cpp 2dcdbc62236d5c1fae384fdb9111825a2ebf5204 Diff: http://git.reviewboard.kde.org/r/107257/diff/ Testing (updated) --- Tested in VM with cirrus/vnc (dpms) and qxl/spice (non-dpms) graphics. Tested the NoAction and LoadFailed cases act as expected. Tested nothing horrible happens when disabling and re-enabling powerdevil in kded Services Manager. Thanks, Oliver Henshaw ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Review Request: Silence Profile foo could not activate bar which is a non-existent action message
On Nov. 18, 2012, 1:23 p.m., Kai Uwe Broulik wrote: Great! Now that I have tested the Keyboard brightness support patch that is on Review Board atm, I get two error messages simultaneously on startup: One for DPMS, the other for Keyboard brightness. This really needs to be fixed/silenced … I'm not sure what the Keyboard brightness problem is - that doesn't have a isSupported implementation as far as I can see. If you mean you've still got it in your config after removing the patch, isn't that the kind of misconfiguration that the notification is meant to warn about? Maybe invalid KConfigGroups shouldn't be persisted back to the configuration? Though maybe only for the NoAction case from the other review request, not for LoadFailed or NotSupported. Not really sure enough of how KConfigGroups work to tell whether that's a promising approach, though. - Oliver --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106863/#review22166 --- On Nov. 3, 2012, 2:46 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106863/ --- (Updated Nov. 3, 2012, 2:46 p.m.) Review request for Solid. Description --- That message usually appears when starting before the Desktop is up, causing an ugly 1990's passivepopup dialog on the screen, and its contents are not really novice-user-resolvable. On my machine it always claims The profile Battery tried to activate DPMSControl which is a non-existent action., which is when I compile powerdevil myself that DPMS stuff is not compiled (DPMS build requirements not met here) and so the action floats around in the config but cannot be triggered anyways. (Imho this is a really infamous message, have seen it quite often on other machines *duck*). All the other actions seem to be installed anyways, so this missing action poses no threat. I guess a kWarning would be sufficient for this. Diffs - powerdevil/daemon/actions/CMakeLists.txt db9ca47 powerdevil/daemon/actions/dpms/powerdevildpmsaction.cpp 55689b5 powerdevil/daemon/powerdevilactionpool.cpp a9950f1 Diff: http://git.reviewboard.kde.org/r/106863/diff/ Testing --- Compiles. The previous passivepopup does not appear anymore. Did not test whether the kwarning is triggered, though. (Dunno how to get powerdevil debug console output) Thanks, Kai Uwe Broulik ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
[Kde-hardware-devel] Review Request: Handle unsupported actions quietly
Hello, I bought a ACER netbook ref 0531H a couple of years ago. I installed the successive versions of Kubuntu without problems, especially with the integrated webcam (Suyin, Crystal Eye). Skype, Cheese and Camorama worked fine with it. After upgrading to Kubuntu Precise (not sure), the webcam was not more correctly recognized by the kernel. Now the webcam looks to be recognized sometimes as a Sonix device, with error messages about UVC compliance. Sometimes it isn't recognized at all. I tried many things without success. That the reason why, I post this mail on the list, even if I am not sure that it is the right place. Any support to help me is welcome. Thank you for your feedback. Cheers. Xavier Detailed information : Sometimes lsusb provides: Bus 001 Device 060: ID 0c45:6310 Microdia Sonix USB 2.0 Camera Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Sometimes, the webcam didn't appear. I tried with many kernels such as for Quantal or Raring (Dev): uname -rvpoi 3.2.0-24-generic #37-Ubuntu SMP Wed Apr 25 08:43:52 UTC 2012 i686 i386 GNU/Linux and uname -rvpoi 3.7.0-3-generic #9-Ubuntu SMP Tue Nov 20 22:40:43 UTC 2012 i686 i686 GNU/Linux In any case, the message in dmesg is similar : dmesg | grep video [0.241729] pci :00:02.0: Boot video device [ 15.772698] acer_wmi: Disabling ACPI video driver [ 508.803505] Linux video capture interface: v2.00 [ 509.004525] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (0c45:6310) [ 509.007843] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround. [ 509.008838] uvcvideo: Failed to query (129) UVC probe control : -32 (exp. 26). [ 509.008850] uvcvideo: Failed to initialize the device (-5). [ 509.010150] usbcore: registered new interface driver uvcvideo [11441.142956] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (0c45:6310) [11441.144825] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround. [11441.145821] uvcvideo: Failed to query (129) UVC probe control : -32 (exp. 26). [11441.145833] uvcvideo: Failed to initialize the device (-5). I tried to install the last version of the UVC driver but without any change: No correct recognization of the webcam (esp. no /dev/video0 device). http://git.linuxtv.org/media_build.git ./build sudo make install sudo camorama == device not found I tried to create manually the /dev/video0 device by: xavier@mercure:/dev$ sudo mknod /dev/video0 c 81 0 xavier@mercure:/dev$ sudo chmod 666 /dev/video0 xavier@mercure:/dev$ sudo ln -s /dev/video0 /dev/video xavier@mercure:/dev$ sudo camorama == device not found ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Review Request: Silence Profile foo could not activate bar which is a non-existent action message
On Nov. 18, 2012, 1:23 p.m., Kai Uwe Broulik wrote: Great! Now that I have tested the Keyboard brightness support patch that is on Review Board atm, I get two error messages simultaneously on startup: One for DPMS, the other for Keyboard brightness. This really needs to be fixed/silenced … Oliver Henshaw wrote: I'm not sure what the Keyboard brightness problem is - that doesn't have a isSupported implementation as far as I can see. If you mean you've still got it in your config after removing the patch, isn't that the kind of misconfiguration that the notification is meant to warn about? Maybe invalid KConfigGroups shouldn't be persisted back to the configuration? Though maybe only for the NoAction case from the other review request, not for LoadFailed or NotSupported. Not really sure enough of how KConfigGroups work to tell whether that's a promising approach, though. I think I will discard this request in favor of your implementation since yours also gives a feedback what happened and looks nicer :P And yes, I think non-existent actions (ie. the config file references an action that is not availble due to not being compiled) should be dropped from the config file. - Kai Uwe --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106863/#review22166 --- On Nov. 3, 2012, 2:46 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106863/ --- (Updated Nov. 3, 2012, 2:46 p.m.) Review request for Solid. Description --- That message usually appears when starting before the Desktop is up, causing an ugly 1990's passivepopup dialog on the screen, and its contents are not really novice-user-resolvable. On my machine it always claims The profile Battery tried to activate DPMSControl which is a non-existent action., which is when I compile powerdevil myself that DPMS stuff is not compiled (DPMS build requirements not met here) and so the action floats around in the config but cannot be triggered anyways. (Imho this is a really infamous message, have seen it quite often on other machines *duck*). All the other actions seem to be installed anyways, so this missing action poses no threat. I guess a kWarning would be sufficient for this. Diffs - powerdevil/daemon/actions/CMakeLists.txt db9ca47 powerdevil/daemon/actions/dpms/powerdevildpmsaction.cpp 55689b5 powerdevil/daemon/powerdevilactionpool.cpp a9950f1 Diff: http://git.reviewboard.kde.org/r/106863/diff/ Testing --- Compiles. The previous passivepopup does not appear anymore. Did not test whether the kwarning is triggered, though. (Dunno how to get powerdevil debug console output) Thanks, Kai Uwe Broulik ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
