Re: GetHotNewStuff for shortcut schemes
On Thursday 04 October 2012 01:26:35 Martin Sandsmark wrote: Hi! After seeing some talk about default shortcuts in KDevelop (people wanting Visual Studio-like shortcuts by default), I thought it would be neat if users easily could download specialized shortcut schemes. Unfortunately I can't find any way to import shortcut schemes, though there seems to be support for exporting them (though trying to use it crashes KDevelop pretty instantly). Yeah, so the first step is to fix the support for importing them :) So, is this a cool idea? Should all shortcut schemes be grouped together, or should they be grouped per-app? Anything else I haven't thought about? Per app, I would say. The shortcut for kdevelop's compile action doesn't make sense in kmail :) More precisely, I would like to use a kdevelop shortcut scheme that makes it shortcut-compatible with QtCreator (I set it up locally like that), and that shouldn't affect shortcuts in other KDE applications. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5
Re: Review Request 110271: libusb-1 support in kcmusb (kinfocenter)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110271/#review32376 --- There is a Find-module for libusb in extra-cmake-modules. As long as this is not released yet, please use a copy from the one over there: http://quickgit.kde.org/?p=extra-cmake-modules.gita=blobh=eba47115f94cc2eb969f19166d6664b300864a30hb=316c7756ec1b0745f518d2f9af139812c3c5a24ff=find-modules%2FFindLibUSB1.cmake - Alexander Neundorf On May 11, 2013, 9:14 p.m., Max Brazhnikov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110271/ --- (Updated May 11, 2013, 9:14 p.m.) Review request for kde-workspace. Description --- Use libusb-1 to query info about usb devices in kinfocenter. Remove *BSD specific code: it doesn't work on all supported FreeBSD versions. In principle it can be saved for NetBSD, but NetBSD could use libusb-1, thus drop it for simplification. Remove polling and use DeviceNotifier instead. Add FindLibUSB-1.cmake Diffs - cmake/modules/FindLibUSB-1.cmake PRE-CREATION kinfocenter/Modules/usbview/CMakeLists.txt 87bb256 kinfocenter/Modules/usbview/config-kcmusb.h.cmake PRE-CREATION kinfocenter/Modules/usbview/kcmusb.cpp c598467 kinfocenter/Modules/usbview/usbdevices.h 493caeb kinfocenter/Modules/usbview/usbdevices.cpp 9bd7033 Diff: http://git.reviewboard.kde.org/r/110271/diff/ Testing --- I've tested it only on FreeBSD. It would nice to test at least FindLibUSB-1.cmake on other OSes. Thanks, Max Brazhnikov
Re: Review Request 110271: libusb-1 support in kcmusb (kinfocenter)
On May 12, 2013, 9:21 a.m., Alexander Neundorf wrote: There is a Find-module for libusb in extra-cmake-modules. As long as this is not released yet, please use a copy from the one over there: http://quickgit.kde.org/?p=extra-cmake-modules.gita=blobh=eba47115f94cc2eb969f19166d6664b300864a30hb=316c7756ec1b0745f518d2f9af139812c3c5a24ff=find-modules%2FFindLibUSB1.cmake Thanks! but I need small modification, because on FreeBSD libusb1 has no '-1' suffix: http://people.freebsd.org/~makc/patches/FindLibUSB1.cmake Shall I open new request for extra-cmake-modules? Max - Max --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110271/#review32376 --- On May 11, 2013, 9:14 p.m., Max Brazhnikov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110271/ --- (Updated May 11, 2013, 9:14 p.m.) Review request for kde-workspace. Description --- Use libusb-1 to query info about usb devices in kinfocenter. Remove *BSD specific code: it doesn't work on all supported FreeBSD versions. In principle it can be saved for NetBSD, but NetBSD could use libusb-1, thus drop it for simplification. Remove polling and use DeviceNotifier instead. Add FindLibUSB-1.cmake Diffs - cmake/modules/FindLibUSB-1.cmake PRE-CREATION kinfocenter/Modules/usbview/CMakeLists.txt 87bb256 kinfocenter/Modules/usbview/config-kcmusb.h.cmake PRE-CREATION kinfocenter/Modules/usbview/kcmusb.cpp c598467 kinfocenter/Modules/usbview/usbdevices.h 493caeb kinfocenter/Modules/usbview/usbdevices.cpp 9bd7033 Diff: http://git.reviewboard.kde.org/r/110271/diff/ Testing --- I've tested it only on FreeBSD. It would nice to test at least FindLibUSB-1.cmake on other OSes. Thanks, Max Brazhnikov
Re: Review Request 110271: libusb-1 support in kcmusb (kinfocenter)
On Sunday 12 May 2013, Max Brazhnikov wrote: On May 12, 2013, 9:21 a.m., Alexander Neundorf wrote: There is a Find-module for libusb in extra-cmake-modules. As long as this is not released yet, please use a copy from the one over there: http://quickgit.kde.org/?p=extra-cmake-modules.gita=blobh=eba47115f9 4cc2eb969f19166d6664b300864a30hb=316c7756ec1b0745f518d2f9af139812c3c5a 24ff=find-modules%2FFindLibUSB1.cmake Thanks! but I need small modification, because on FreeBSD libusb1 has no '-1' suffix: http://people.freebsd.org/~makc/patches/FindLibUSB1.cmake Shall I open new request for extra-cmake-modules? Yes, please. Or, if all you need is an additional name for the find_library() call, you can also go ahead and commit it. Alex
Re: R: Re: kde review kartesio
Hi, I think Kartesio is not ready to move: - the GUI is not so good - lack of tooltips - I am not happy with some strings and they lack context info - the standard C++ code is not so good either (this rm for example) - lack of testing I suggest you do a release first so we can test translations and you can get some users feedback and have time to move the code to Qt classes. This is my suggestion only, others may disagree Best regards, Anne-Marie
Re: GetHotNewStuff for shortcut schemes
Hi Martin, Yes, I've had many requests like that. Not only for VS users, but emacs and sublime users. I'd say it makes sense. Aleix On Thu, Oct 4, 2012 at 1:26 AM, Martin Sandsmark martin.sandsm...@kde.orgwrote: Hi! After seeing some talk about default shortcuts in KDevelop (people wanting Visual Studio-like shortcuts by default), I thought it would be neat if users easily could download specialized shortcut schemes. Unfortunately I can't find any way to import shortcut schemes, though there seems to be support for exporting them (though trying to use it crashes KDevelop pretty instantly). So, is this a cool idea? Should all shortcut schemes be grouped together, or should they be grouped per-app? Anything else I haven't thought about? -- Martin Sandsmark
Re: Review Request 110392: Do not overwrite directories inside a tar archive
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110392/#review32398 --- This review has been submitted with commit 471aa45613301ea2250fc6d815af8a65dc69a5ee by Dawit Alemayehu to branch KDE/4.10. - Commit Hook On May 12, 2013, 1:44 a.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110392/ --- (Updated May 12, 2013, 1:44 a.m.) Review request for kdelibs and David Faure. Description --- The attached patch fixes KTar so that the contents of a sample archive: d/ d/f1.txt d/ d/f2.txt are shown correctly as d/f1.txt d/f2.txt instead of d/f2.txt See the bug report for details on what kind of archives are not shown correctly in Konqueror vs Ark. This addresses bug 206994. http://bugs.kde.org/show_bug.cgi?id=206994 Diffs - kdecore/io/ktar.cpp 142a80a Diff: http://git.reviewboard.kde.org/r/110392/diff/ Testing --- Thanks, Dawit Alemayehu
Re: R: Re: kde review kartesio
Hi, I'm sorry, but I have to agree with Anne-Marie. Cheers! Sven 2013/5/12 Anne-Marie Mahfouf annemarie.mahf...@free.fr: Hi, I think Kartesio is not ready to move: - the GUI is not so good - lack of tooltips - I am not happy with some strings and they lack context info - the standard C++ code is not so good either (this rm for example) - lack of testing I suggest you do a release first so we can test translations and you can get some users feedback and have time to move the code to Qt classes. This is my suggestion only, others may disagree Best regards, Anne-Marie
Re: R: Re: kde review kartesio
El Divendres, 10 de maig de 2013, a les 14:18:43, LucaTringali va escriure: Hello, libzorbaneural can be found here: https://www.gitorious.org/zorbaneural/zorbaneural/trees/master Here are also some packages for the stable version (deb and rpm): https://www.gitorious.org/zorbaneural/zorbaneural/trees/master/binary- packages/libzorbaneural-0.1 Once you have installed it, the build should go fine. The screenshot folder and the .pro file are not needed, if they are a problem I can remove them. If they are not needed, yes, I'd kill them. Cheers, Albert Talking about the system call in calculations, this is the reason why actuallt Kartesio works only on GNU/Linux systems. Why I did it? Because it was the easier way to do that. In the next release of Kartesio, this problem will be solved. I'm not very practical with translatable strings, so I excuse for the Message. sh: is there a wiki page to understand how to write a Message.sh file? I'm writing comments on variables in header files, in the next hours I'll publish them into git. Luca Tringali Messaggio originale Da: annemarie.mahf...@free.fr Data: 10/05/2013 13.58 A: LucaTringalitringalinv...@libero.it Cc: kde-core-devel@kde.org Ogg: Re: kde review kartesio Hi, A few primary remarks: - libzorbaneural is needed but my distro does not have anything with neural in it (OpenSuse 12.3) what repo do I need to add in order to get it? The libzorbaneural website should be added to the cmake file so people can find this and packagers can add it to their distros. - I see a screenshot folder and some .pro files that probably are not needed - some doxygen comments for the variables in the .h files would be appreciated, if anyone else wants to fix bugs it'll help a lot. - Kartesio does not build for me, I get /home/kde- devel/kartesio/src/calculations.cpp:278:1: error: control reaches end of non-void function [-Werror=return-type] cc1plus: some warnings being treated as errors - I don't see a Messages.sh file to extract translatable strings. - I am not comfortable with the rm call line 181 in calculations.cpp = you can probably use more Qt classes here and in other parts of this file too. That's only a quick review as I couldn't run the app yet. Tomaz, as for the user base maybe we could start a module for advanced scientific tools? Best regards, Anne-Marie - Mail original - De: Tomaz Canabrava tcanabr...@kde.org À: Anne-Marie Mahfouf annemarie.mahf...@free.fr Cc: LucaTringali tringalinv...@libero.it, kde-core-devel@kde.org Envoyé: Vendredi 10 Mai 2013 12:28:54 Objet: Re: kde review kartesio Quite Unlikely ... It's a Solver, to fit curves into points, That's very used in any theorical research, engeniering, math, phisics, etc. 2013/5/10 Anne-Marie Mahfouf annemarie.mahf...@free.fr Hi, I am wondering what is the user base for this application as it seems quite specialized (I did not build it yet though). Can you tell us more about the potential target? Another question that comes to mind is: can't it be a feature of an existing KDE Edu apps? Best regards, Anne-Marie - Mail original - De: LucaTringali tringalinv...@libero.it À: kde-core-devel@kde.org Envoyé: Jeudi 9 Mai 2013 18:06:16 Objet: kde review kartesio Hello, I have been working on Kartesio, a program for calculating best fit curves with experimental points. I think it is ready to be moved in the KDE Edu main repo now, so I'm asking your approval. I followed the guidelines ( http://techbase.kde.org/Policies/Application_Lifecycle ) and Kartesio is actually in KDE review: https://projects.kde.org/projects/kdereview/kartesio For any question, ask me. Luca Tringali
Re: Crashes with libQtUiTools.a if linked multiple times into the same process (with Bsymbolic-functions flag)
Hi Sune, Am Samstag, 11. Mai 2013, 20:23:15 schrieb Sune Vuorela: On 2013-05-11, Friedrich W. H. Kossebau kosse...@kde.org wrote: So, anyone with more clue than me WRT symbols from static libs and the Bsymbolic-functions linker flag who could tell if that indeed should fix such problems if code from the same static lib is arriving multiple times in the same process via different libs/modules? It most likely will help on such a case. -Bsymbolic-functions ensures that functiotns are first resolved in the library/plugin itself before resolving it from outside the library. What happens, I think, is that it is sometimes using the functions from one of the static libs, other times from some of the other. I'm not sure we want libraries linking QtTools to be built with -Bsymbolic-functions because it breaks debugging and other magic using function overriding with LD_PRELOAD tricks, because they rely on being chosen first over the 'internal' functions. Bsymbolic-functions seems default for all qt/kde libs these days, no? So it would need to be removed everywhere if following your answers. In the meantime downstream (openSUSE KDE maintainers) have created a different patch which instead simply tells the linker to exclude libQtUiTools.a when generating the public symbols, by calling in all relevant places + # Do not export QtUiTools internal symbols + set_target_properties(krossmoduleforms PROPERTIES LINK_FLAGS -Wl,-- exclude-libs -Wl,libQtUiTools.a) See request https://build.opensuse.org/package/view_file?file=exclude-qtuitools-symbols-from-public-libraries.patchpackage=kdelibs4project=KDE%3ADistro%3AFactory Hopefully that will soon make it upstream if it proves to be the right fix (tm). Cheers Friedrich
Re: Crashes with libQtUiTools.a if linked multiple times into the same process (with Bsymbolic-functions flag)
On domingo, 12 de maio de 2013 22.47.35, Friedrich W. H. Kossebau wrote: + # Do not export QtUiTools internal symbols + set_target_properties(krossmoduleforms PROPERTIES LINK_FLAGS -Wl,-- exclude-libs -Wl,libQtUiTools.a) It seems the correct fix would be to compile libQtUiTools.a with - fvisibility=hidden in Qt. It's already the case in Qt 5, so it should not be a problem anymore. For Qt 4, I could investigate, but does it help if it only applies to Qt 4.8.5 or 4.8.6? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Review Request 108802: Switch Delete/Move To Trash actions when Shift key is pressed in Konqueror context menu
On May 5, 2013, 10:16 p.m., David Faure wrote: dolphin/src/dolphinpart.cpp, line 623 http://git.reviewboard.kde.org/r/108802/diff/2/?file=142264#file142264line623 Same code as in dolphincontextmenu. If it can't be shared, at least there should be a comment about where the code comes from, for easier maintainance. I will look to see if this code can be refactored and shared between these two classes. On May 5, 2013, 10:16 p.m., David Faure wrote: dolphin/src/dolphinpart.cpp, line 664 http://git.reviewboard.kde.org/r/108802/diff/2/?file=142264#file142264line664 There are other ways to bring the context menu than the right button. There's the context key, too. So better watch for the QEvent::ContextMenu event instead of hardcoding release of right button, if it really has to be done with the event filter. QEvent::ContextMenu won't work. That is the first thing I tried. I think the context menu event is consumed by some widget that emits its own specialized signal signal (requestContextMenu). Anyhow, that does not matter. I realized it is not need in this instance. See updated patch. - Dawit --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108802/#review32111 --- On May 5, 2013, 1:53 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108802/ --- (Updated May 5, 2013, 1:53 p.m.) Review request for KDE Base Apps, David Faure and Frank Reininghaus. Description --- This patch fixes DolphinPart such that the Delete/Move To Trash actions are automatically toggled if the user presses the Shift key and allows https://git.reviewboard.kde.org/r/107509/ to be applied. The code is completely based on what Dolphin's context menu does. Even though this works as planned, I still have reservations about the use of KModifierKeyInfo since every key press event from any application is sent to the application that connects to its signals. In my code and unlike what is done in Dolphin's context menu, I try to mitigate the impact of that by ignoring the signal when the part does not have the focus. Still if there is a better way to capture key press events at the part level I would like to use that instead. Any ideas ? Diffs - dolphin/src/dolphinpart.h 7881ded dolphin/src/dolphinpart.cpp 627ba79 Diff: http://git.reviewboard.kde.org/r/108802/diff/ Testing --- Thanks, Dawit Alemayehu
Re: Review Request 108802: Switch Delete/Move To Trash actions when Shift key is pressed in Konqueror context menu
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108802/ --- (Updated May 13, 2013, 1:35 a.m.) Review request for KDE Base Apps, David Faure and Frank Reininghaus. Changes --- - Factored out the Delete/Move To Trash action into own class, DolphinRemoveAction. - Updated both the DolphinPart and DolphinContextMenu to use this new DolphinRemoveAction class to manage Delete/Move to Trash actions. The only thing I am unsure of is whether or not the new shared action class should be added to libdolphinprivate or not. It seemed to me to be the logical place to put it since it is shared by both the Dolphin binary as well as the kpart. Otherwise, this seems to work well for both Konqueror as well as Dolphin. It is also much cleaner to look at. Description --- This patch fixes DolphinPart such that the Delete/Move To Trash actions are automatically toggled if the user presses the Shift key and allows https://git.reviewboard.kde.org/r/107509/ to be applied. The code is completely based on what Dolphin's context menu does. Even though this works as planned, I still have reservations about the use of KModifierKeyInfo since every key press event from any application is sent to the application that connects to its signals. In my code and unlike what is done in Dolphin's context menu, I try to mitigate the impact of that by ignoring the signal when the part does not have the focus. Still if there is a better way to capture key press events at the part level I would like to use that instead. Any ideas ? Diffs (updated) - dolphin/src/CMakeLists.txt ffb232c dolphin/src/dolphincontextmenu.h 1c65fab dolphin/src/dolphincontextmenu.cpp 89a169f dolphin/src/dolphinpart.h 7881ded dolphin/src/dolphinpart.cpp 627ba79 dolphin/src/dolphinremoveaction.h PRE-CREATION dolphin/src/dolphinremoveaction.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/108802/diff/ Testing --- Thanks, Dawit Alemayehu
Re: Review Request 108802: Switch Delete/Move To Trash actions when Shift key is pressed in Konqueror context menu
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108802/ --- (Updated May 13, 2013, 1:38 a.m.) Review request for KDE Base Apps, David Faure and Frank Reininghaus. Changes --- Removed trailing white spaces from the newly added implementation/header files. Description --- This patch fixes DolphinPart such that the Delete/Move To Trash actions are automatically toggled if the user presses the Shift key and allows https://git.reviewboard.kde.org/r/107509/ to be applied. The code is completely based on what Dolphin's context menu does. Even though this works as planned, I still have reservations about the use of KModifierKeyInfo since every key press event from any application is sent to the application that connects to its signals. In my code and unlike what is done in Dolphin's context menu, I try to mitigate the impact of that by ignoring the signal when the part does not have the focus. Still if there is a better way to capture key press events at the part level I would like to use that instead. Any ideas ? Diffs (updated) - dolphin/src/CMakeLists.txt ffb232c dolphin/src/dolphincontextmenu.h 1c65fab dolphin/src/dolphincontextmenu.cpp 89a169f dolphin/src/dolphinpart.h 7881ded dolphin/src/dolphinpart.cpp 627ba79 dolphin/src/dolphinremoveaction.h PRE-CREATION dolphin/src/dolphinremoveaction.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/108802/diff/ Testing --- Thanks, Dawit Alemayehu
