Re: Review Request: Write to the correct xmlFile in KToolBar::Private::slotContextShowText()
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103812/#review10444 --- I was surprised that there was no way to go from the action to its collection, but indeed, it's not possible, because an action could be in multiple collections. In such a case, your patch might do the wrong thing, picking the wrong collection. But indeed the xmlguiclient member variable isn't much help either, it's the last xmlgui client that had a toolbar tag pointing to this toolbar (no misuse there btw). I think the cleanest solution would be to search for the action in the N xmlguiclients that added actions to this toolbar. Which means, deprecating KToolBar::setXMLGuiClient and adding a KToolBar::addXMLGuiClient, calling that from kxmlguibuilder instead, and keeping a list internally. Then you can iterate over that list to find the action, which will prevent finding it in completely unrelated action collections (e.g. the one used for a popup menu, like in konqueror). - David Faure On Jan. 28, 2012, 3:28 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103812/ --- (Updated Jan. 28, 2012, 3:28 p.m.) Review request for kdelibs and David Faure. Description --- KToolBar::Private::slotContextShowText() was assuming that the xmlgui file it had to write was KGlobal::mainComponent.componentName() + ui.rc; which is obviously wrong since we have a setXMLFile function for a reason. I tried using xmlguiClient-xmlFile() directly but in Okular we use the same the same toolbar name defined in two xml files, so that still did not work because this means we end up with just one KToolbar (yes i know that might be a misuse of the API). So i ended up going through the actioncollections to find the action and get the correct client from there. This addresses bug 292574. http://bugs.kde.org/show_bug.cgi?id=292574 Diffs - kdeui/widgets/ktoolbar.cpp cce242b Diff: http://git.reviewboard.kde.org/r/103812/diff/diff Testing --- Fixes the issue in Okular, i tested it does still work with Kate that is using the ui.rc scheme. Thanks, Albert Astals Cid
Re: phonon javascript
On Thu, Feb 9, 2012 at 4:39 AM, Shaun Reich shaun.re...@kdemail.net wrote: anyone know how can i access phonon through javascript? javascript? qtscript you mean? I think you will need http://code.google.com/p/qtscriptgenerator/ for that
Re: Review Request: Fix KConfigDialogManager fails to handle subclasses of QComboBox with custom property
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103909/ --- (Updated Feb. 9, 2012, 11:28 p.m.) Review request for kdelibs, Eike Hein, Christoph Feck, and Jeremy Paul Whiting. Description --- https://git.reviewboard.kde.org/r/101486/ broke subclasses of QComboBox that have a USER property like KColorCombo, this patch reverts this change and introduces a different code path to ignore the USER property of QComboBox and KComboBox and make it use our custom code. This addresses bug 293702. http://bugs.kde.org/show_bug.cgi?id=293702 Diffs (updated) - kdeui/tests/CMakeLists.txt 63788f6 kdeui/tests/kconfigdialog_unittest.cpp PRE-CREATION kdeui/dialogs/kconfigdialogmanager.cpp 0890c0b Diff: http://git.reviewboard.kde.org/r/103909/diff/diff Testing --- Ran the attached test, everything worked. Without moving the userproperty = getUserProperty(w); the KColorCombo fails Without adding the s_propertyMap-insert( KComboBox, ); the editable KComboBox fails Thanks, Albert Astals Cid
Re: Review Request: Fix KConfigDialogManager fails to handle subclasses of QComboBox with custom property
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103909/ --- (Updated Feb. 9, 2012, 11:28 p.m.) Review request for kdelibs, Ben Cooksley, Eike Hein, Christoph Feck, and Jeremy Paul Whiting. Description --- https://git.reviewboard.kde.org/r/101486/ broke subclasses of QComboBox that have a USER property like KColorCombo, this patch reverts this change and introduces a different code path to ignore the USER property of QComboBox and KComboBox and make it use our custom code. This addresses bug 293702. http://bugs.kde.org/show_bug.cgi?id=293702 Diffs - kdeui/tests/CMakeLists.txt 63788f6 kdeui/tests/kconfigdialog_unittest.cpp PRE-CREATION kdeui/dialogs/kconfigdialogmanager.cpp 0890c0b Diff: http://git.reviewboard.kde.org/r/103909/diff/diff Testing --- Ran the attached test, everything worked. Without moving the userproperty = getUserProperty(w); the KColorCombo fails Without adding the s_propertyMap-insert( KComboBox, ); the editable KComboBox fails Thanks, Albert Astals Cid
Re: Review Request: Fix KConfigDialogManager fails to handle subclasses of QComboBox with custom property
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103909/#review10470 --- Thanks Albert for looking at it. Not sure if I understand everything correctly, but what happens, when I have a subclass of Q/KComboBox, that does not have its own user property? I am considering the following possible cases: 1) plain QComboBox 2) subclassed QComboBox without custom user property 3) subclassed QComboBox with custom user property 4) plain KComboBox 5) subclassed KComboBox without custom user property 6) subclassed KComboBox with custom user property (e.g. KColorCombo) For 1) 2) 4) 5) it should ignore the new 4.8 user property, and use our custom code. For 3) 6) it should respect the custom user property. If I am following code paths correctly, the patch fails for cases 2) and 5). It does not find the class name in the map, falls back to user property (what Qt provides now since 4.8), and thus not handle our custom code. - Christoph Feck On Feb. 9, 2012, 11:28 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103909/ --- (Updated Feb. 9, 2012, 11:28 p.m.) Review request for kdelibs, Ben Cooksley, Eike Hein, Christoph Feck, and Jeremy Paul Whiting. Description --- https://git.reviewboard.kde.org/r/101486/ broke subclasses of QComboBox that have a USER property like KColorCombo, this patch reverts this change and introduces a different code path to ignore the USER property of QComboBox and KComboBox and make it use our custom code. This addresses bug 293702. http://bugs.kde.org/show_bug.cgi?id=293702 Diffs - kdeui/tests/CMakeLists.txt 63788f6 kdeui/tests/kconfigdialog_unittest.cpp PRE-CREATION kdeui/dialogs/kconfigdialogmanager.cpp 0890c0b Diff: http://git.reviewboard.kde.org/r/103909/diff/diff Testing --- Ran the attached test, everything worked. Without moving the userproperty = getUserProperty(w); the KColorCombo fails Without adding the s_propertyMap-insert( KComboBox, ); the editable KComboBox fails Thanks, Albert Astals Cid
