Re: Review Request: Konqueror: add option to hide/show status bar
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105337/#review15189 --- Ship it! Looks good. One might argue that statusbar visibility should also be part of view profiles (KonqViewManager::loadItem already has support for a ShowStatusBar config key, but in KonqFrame::saveConfig the code was commented out for lack of a GUI to control it). However the use case you describe is really the user showing the statusbar again after a website hid it, not the user wants to get rid of all statusbars, so I'd say let's not save this into the profile. - David Faure On June 23, 2012, 8:51 p.m., Jonathan Marten wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105337/ --- (Updated June 23, 2012, 8:51 p.m.) Review request for KDE Base Apps and David Faure. Description --- The referenced bug suggested this option to cover the case where web sites opened new windows (via JS) without user interface elements, if this is the case there is no way to bring back the status bar which can show important information. A patch was posted (http://lists.kde.org/?l=kfm-develm=122885401907547w=2) a long time ago, but it was rejected because Konqueror's handling of the status bar is special (each view has its own status bar) and the patch took no account of that. Hopefully this updated patch does. The menu option only toggles the status bar of the current view - I did think about making it do the status bars of all of the views simultaneously but was not sure whether this would be the right thing to do. Of course, for a single view in the window, the option does what is expected anyway. There are GUI changes but no I18N strings (the KStandardAction is used). This addresses bug 62. http://bugs.kde.org/show_bug.cgi?id=62 Diffs - konqueror/src/konqmainwindow.h 1666370 konqueror/src/konqmainwindow.cpp 0b49be5 konqueror/src/konqueror.rc f788484 Diff: http://git.reviewboard.kde.org/r/105337/diff/ Testing --- Built Konqueror with these changes, tested with file management and web browsing profiles with various window splits. Thanks, Jonathan Marten
Re: Default file manager and folder associations
On Sunday 17 June 2012 12:49:46 Ambroz Bizjak wrote: That doesn't quite work, for me at least. See the bug I reported https://bugs.kde.org/show_bug.cgi?id=297720 Nobody seems to care though. I posted a fix for that bug on June 18, and asked for testing. Nobody seems to care, though :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
Re: Review Request: Added fallback for real username in kcm module to use KUser::FullName
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104965/ --- (Updated June 27, 2012, 4:29 p.m.) Review request for KDE Base Apps. Changes --- Applied both suggestions. Description --- Added fallback for real username in kcm module. Really helps in issues like this: http://bugs.rosalinux.ru/show_bug.cgi?id=179 Besides, such method seems natural, considering that change of real username in kcm module calls chfn to change real name in finger db, which will be reflected back in KUser::FullName. Diffs (updated) - kdepasswd/kcm/main.cpp 2471444 Diff: http://git.reviewboard.kde.org/r/104965/diff/ Testing --- Tested by QA crew of ROSA Desktop for ROSA Desktop 2012 LTS. Thanks, Aleksey Yermakov
Re: Review Request: Added fallback for real username in kcm module to use KUser::FullName
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104965/#review15206 --- Ship it! Makes sense, please commit to master. - Raphael Kubo da Costa On June 27, 2012, 4:29 p.m., Aleksey Yermakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104965/ --- (Updated June 27, 2012, 4:29 p.m.) Review request for KDE Base Apps. Description --- Added fallback for real username in kcm module. Really helps in issues like this: http://bugs.rosalinux.ru/show_bug.cgi?id=179 Besides, such method seems natural, considering that change of real username in kcm module calls chfn to change real name in finger db, which will be reflected back in KUser::FullName. Diffs - kdepasswd/kcm/main.cpp 2471444 Diff: http://git.reviewboard.kde.org/r/104965/diff/ Testing --- Tested by QA crew of ROSA Desktop for ROSA Desktop 2012 LTS. Thanks, Aleksey Yermakov
Re: Review Request: Added fallback for real username in kcm module to use KUser::FullName
On June 27, 2012, 4:50 p.m., Raphael Kubo da Costa wrote: Makes sense, please commit to master. I'm afraid, I don't have write rights. Could you please point me to some documentation which will help me commit this patch? - Aleksey --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104965/#review15206 --- On June 27, 2012, 4:29 p.m., Aleksey Yermakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104965/ --- (Updated June 27, 2012, 4:29 p.m.) Review request for KDE Base Apps. Description --- Added fallback for real username in kcm module. Really helps in issues like this: http://bugs.rosalinux.ru/show_bug.cgi?id=179 Besides, such method seems natural, considering that change of real username in kcm module calls chfn to change real name in finger db, which will be reflected back in KUser::FullName. Diffs - kdepasswd/kcm/main.cpp 2471444 Diff: http://git.reviewboard.kde.org/r/104965/diff/ Testing --- Tested by QA crew of ROSA Desktop for ROSA Desktop 2012 LTS. Thanks, Aleksey Yermakov
Re: Review Request: Added fallback for real username in kcm module to use KUser::FullName
On June 27, 2012, 4:50 p.m., Raphael Kubo da Costa wrote: Makes sense, please commit to master. Aleksey Yermakov wrote: I'm afraid, I don't have write rights. Could you please point me to some documentation which will help me commit this patch? I will commit this one for you then. The basic documentation is this one: http://techbase.kde.org/Contribute/Get_a_Contributor_Account. In short, if you send a few more patches and show that you're interested in keeping contributing, people will encourage you to apply for an account and second the nomination (it may sound pompous but it's really simple :-) - Raphael --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104965/#review15206 --- On June 27, 2012, 4:29 p.m., Aleksey Yermakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104965/ --- (Updated June 27, 2012, 4:29 p.m.) Review request for KDE Base Apps. Description --- Added fallback for real username in kcm module. Really helps in issues like this: http://bugs.rosalinux.ru/show_bug.cgi?id=179 Besides, such method seems natural, considering that change of real username in kcm module calls chfn to change real name in finger db, which will be reflected back in KUser::FullName. Diffs - kdepasswd/kcm/main.cpp 2471444 Diff: http://git.reviewboard.kde.org/r/104965/diff/ Testing --- Tested by QA crew of ROSA Desktop for ROSA Desktop 2012 LTS. Thanks, Aleksey Yermakov
Re: Review Request: Added fallback for real username in kcm module to use KUser::FullName
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104965/#review15211 --- This review has been submitted with commit a277b80df8c5fc2ac1689a5afbb68b3f39321cf4 by Raphael Kubo da Costa to branch master. - Commit Hook On June 27, 2012, 4:29 p.m., Aleksey Yermakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104965/ --- (Updated June 27, 2012, 4:29 p.m.) Review request for KDE Base Apps. Description --- Added fallback for real username in kcm module. Really helps in issues like this: http://bugs.rosalinux.ru/show_bug.cgi?id=179 Besides, such method seems natural, considering that change of real username in kcm module calls chfn to change real name in finger db, which will be reflected back in KUser::FullName. Diffs - kdepasswd/kcm/main.cpp 2471444 Diff: http://git.reviewboard.kde.org/r/104965/diff/ Testing --- Tested by QA crew of ROSA Desktop for ROSA Desktop 2012 LTS. Thanks, Aleksey Yermakov
Compiler version
Hi all, I've tested the waters some time ago [1] what would people say if we started asking for more modern compilers. I've stated there I'll start the discussion on k-c-d once we branch out 4.9, so I'm doing as promised. The post was only about kactivities, but the same could be applied to more stuff. Mainly, the responses were positive (from both users and developers). Now, my proposal here is to update the required versions for Frameworks 4 to reflect those of KDE Frameworks 5 / Qt 5. Now, I've found different information for this - skelly says [2] the requirement is GCC 4.6 while some other places state it is GCC 4.5, so I'm not sure whether it was a typing error or not. The other thing I'd like to discuss is whether we should have the same requirements for libraries and applications. For example, while I intend to require at least GCC 4.5 for the kactivities daemon (and would like to require even 4.6, but will not) I intend to keep the library compatible with old GCCs. As an additional argument for raising the bar, here are the GCC versions in most modern distros (collected by other people, didn't check): - Debian - 4.7 (testing) - openSuse 12.1 - 4.6 - Kubuntu - 4.6 - Fedora 16 - 4.6 - Gentoo - 4.5 (stable) - FreeBSD 10 - Clang 3.1 (*very* modern) -- Cheerio, Ivan [1] http://tinyurl.com/kcd-compiler-version [2] http://www.kdab.com/last-week-in-qt-development-week-17-2012/ The compiler requirement has been updated to GCC 4.6, which is consistent with the compiler requirement on other platforms using GCC. p.s. Currently, I'm not checking for = specific version, but the compiler features which I think is more versatile. See: https://projects.kde.org/projects/kde/kdelibs/kactivities/repository/revisions/f25763502b5c92794a66651bd60e624efa15d51b/entry/service/CMakeLists.txt -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun
Re: Compiler version
Hi all, I've tested the waters some time ago [1] what would people say if we started asking for more modern compilers. I've stated there I'll start the discussion on k-c-d once we branch out 4.9, so I'm doing as promised. The post was only about kactivities, but the same could be applied to more stuff. That reminds me of a question I always wanted to ask: is there any reason why we don't use '#pragma once', i.e. is there a supported compiler that can't handle this? Mainly, the responses were positive (from both users and developers). What is the current minimum requirement? As an additional argument for raising the bar, here are the GCC versions in most modern distros (collected by other people, didn't check): - Debian - 4.7 (testing) - openSuse 12.1 - 4.6 openSUSE 11.4 - 4.5 openSUSE 12.2 (upcoming) - 4.7 Eike
Re: Compiler version
On Wednesday 27 June 2012 23:28:30 Ivan Čukić wrote: Hi all, I've tested the waters some time ago [1] what would people say if we started asking for more modern compilers. I've stated there I'll start the discussion on k-c-d once we branch out 4.9, so I'm doing as promised. The post was only about kactivities, but the same could be applied to more stuff. Thanks for bringing up the issue, I actually intended to write a similar mail tomorrow to request that applications are allowed to require compilers supporting C++11 features. So +1 for a minimum requirement of gcc 4.6 or clang 3.1 Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Compiler version
Ivan Čukić ivan.cu...@kde.org writes: Now, my proposal here is to update the required versions for Frameworks 4 to reflect those of KDE Frameworks 5 / Qt 5. Now, I've found different information for this - skelly says [2] the requirement is GCC 4.6 while some other places state it is GCC 4.5, so I'm not sure whether it was a typing error or not. The most up-to-date discussion I can find about defining a lowest common denominator is [1]. In short, if I understand it correctly we (as well as Qt) are still supposed to support Apple with gcc 4.2.1. This also happens to help the situation on FreeBSD, where the default compiler is also gcc 4.2.1 + patches (the latest GPLv2 release), even though it is possible to require a more recent version from its ports system. Apple (as well as FreeBSD) seems to be moving towards clang, however I do not know if they have made it their default compiler in some release of theirs. - FreeBSD 10 - Clang 3.1 (*very* modern) FreeBSD 10 is the development version, and even there clang is not the default compiler yet. For the foreseeable future we're still having gcc 4.2.1 used by default, but, as I said, we could require another version even if a few users complain (I'd prefer if the requirements for KDE 4 were not changed, though). [1] http://article.gmane.org/gmane.comp.kde.devel.buildsystem/7133
Re: Compiler version
Mainly, the responses were positive (from both users and developers). What is the current minimum requirement? Can't find anything similar for the later versions of KDE SC, but for 4.4 it is quite a list (even gcc 3.3 [1]): http://techbase.kde.org/Schedules/KDE4/4.4_Requirements Cheerio, Ivan [1] http://gcc.gnu.org/gcc-3.3/ -- I don't really trust a sane person. -- Lyle Alzado
Re: Compiler version
On Wednesday 27 June 2012, Ivan Čukić wrote: Hi all, ... As an additional argument for raising the bar, here are the GCC versions in most modern distros (collected by other people, didn't check): - Debian - 4.7 (testing) - openSuse 12.1 - 4.6 - Kubuntu - 4.6 - Fedora 16 - 4.6 - Gentoo - 4.5 (stable) - FreeBSD 10 - Clang 3.1 (*very* modern) Slackware 13.37: gcc 4.5.2 Alex
Re: Compiler version
El Dimecres, 27 de juny de 2012, a les 23:28:30, Ivan Čukić va escriure: Hi all, Hi I've tested the waters some time ago [1] what would people say if we started asking for more modern compilers. Can you explain why you need a more modern version, I see a good analysis of what the current situation regarding compiler availability but i fail to see why we need a newer compiler. Cheers, Albert I've stated there I'll start the discussion on k-c-d once we branch out 4.9, so I'm doing as promised. The post was only about kactivities, but the same could be applied to more stuff. Mainly, the responses were positive (from both users and developers). Now, my proposal here is to update the required versions for Frameworks 4 to reflect those of KDE Frameworks 5 / Qt 5. Now, I've found different information for this - skelly says [2] the requirement is GCC 4.6 while some other places state it is GCC 4.5, so I'm not sure whether it was a typing error or not. The other thing I'd like to discuss is whether we should have the same requirements for libraries and applications. For example, while I intend to require at least GCC 4.5 for the kactivities daemon (and would like to require even 4.6, but will not) I intend to keep the library compatible with old GCCs. As an additional argument for raising the bar, here are the GCC versions in most modern distros (collected by other people, didn't check): - Debian - 4.7 (testing) - openSuse 12.1 - 4.6 - Kubuntu - 4.6 - Fedora 16 - 4.6 - Gentoo - 4.5 (stable) - FreeBSD 10 - Clang 3.1 (*very* modern)
Re: Compiler version
Am 27.06.2012, 23:52 Uhr, schrieb Alexander Neundorf neund...@kde.org: On Wednesday 27 June 2012, Ivan Čukić wrote: Hi all, ... As an additional argument for raising the bar, here are the GCC versions in most modern distros (collected by other people, didn't check): - Debian - 4.7 (testing) - openSuse 12.1 - 4.6 - Kubuntu - 4.6 - Fedora 16 - 4.6 - Gentoo - 4.5 (stable) - FreeBSD 10 - Clang 3.1 (*very* modern) Slackware 13.37: gcc 4.5.2 - Arch: 4.7.1 / Clang 3.1 - 4.6 is still available Cheers, Thomas
Re: Compiler version
On Thu, Jun 28, 2012 at 9:49 AM, Raphael Kubo da Costa rak...@freebsd.org wrote: Ivan Čukić ivan.cu...@kde.org writes: Now, my proposal here is to update the required versions for Frameworks 4 to reflect those of KDE Frameworks 5 / Qt 5. Now, I've found different information for this - skelly says [2] the requirement is GCC 4.6 while some other places state it is GCC 4.5, so I'm not sure whether it was a typing error or not. The most up-to-date discussion I can find about defining a lowest common denominator is [1]. In short, if I understand it correctly we (as well as Qt) are still supposed to support Apple with gcc 4.2.1. This also happens to help the situation on FreeBSD, where the default compiler is also gcc 4.2.1 + patches (the latest GPLv2 release), even though it is possible to require a more recent version from its ports system. Debian Squeeze has gcc 4.4.5, and this is the base of build.kde.org. It would be appreciated if we did not have to run Debian Testing on the build slaves. Apple (as well as FreeBSD) seems to be moving towards clang, however I do not know if they have made it their default compiler in some release of theirs. - FreeBSD 10 - Clang 3.1 (*very* modern) FreeBSD 10 is the development version, and even there clang is not the default compiler yet. For the foreseeable future we're still having gcc 4.2.1 used by default, but, as I said, we could require another version even if a few users complain (I'd prefer if the requirements for KDE 4 were not changed, though). [1] http://article.gmane.org/gmane.comp.kde.devel.buildsystem/7133 Regards, Ben
Re: Compiler version
On quarta-feira, 27 de junho de 2012 23.28.30, Ivan Čukić wrote: Now, my proposal here is to update the required versions for Frameworks 4 to reflect those of KDE Frameworks 5 / Qt 5. Now, I've found different information for this - skelly says [2] the requirement is GCC 4.6 while some other places state it is GCC 4.5, so I'm not sure whether it was a typing error or not. I'd love to raise the minimum for Qt to 4.5, but it's not going to happen. We're saying 4.4 everywhere, except Mac where gcc 4.2.1 by Apple is ok. That does not include FreeBSD. They'll have to upgrade. -- 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: Compiler version
Can you explain why you need a more modern version, I see a good analysis of what the current situation regarding compiler availability but i fail to see why we need a newer compiler. For me, the main reasons for this request are: - lambdas (gcc 4.5) - variadic templates (4.3 / 4.4) - auto (4.4) - nullptr (4.6) - =default, =delete (4.4) - explicit override (4.7) - unique/shared_ptr (?? works in 4.5) nullptr and override are really useful while developing, even as enabled-if- possible - so I can live without hard-requiring them (macro-based switch), but lambdas are not so easily replaceable while making the life much easier and a lot of methods shorter :) Cheerio, Ivan -- Acting is merely the art of keeping a large group of people from coughing. -- Sir Ralph Richardson
Re: Compiler version
From Ben Cooksley: Debian Squeeze has gcc 4.4.5, and this is the base of build.kde.org. It would be appreciated if we did not have to run Debian Testing on the build slaves. Honestly, while having Jenkins around is quite neat, I don't see a helper tool as a valid reason to make the development more difficult. Anyhow, guessing that we will not agree about raising the requirement for the libraries, not for the forseable future, and that is more or less fine for me. Libraries are always a special case. The second are applications. To quote Martin: Thanks for bringing up the issue, I actually intended to write a similar mail tomorrow to request that applications are allowed to require compilers supporting C++11 features. IMO, application developers should choose which range of systems they want to target. For example, for core things that should run (kded, kwallet, etc.???) on Lin/Win/Mac, ok, the requirement can't be above 4.2. For applications that are not essential to the rest of the environment to function properly, this shouldn't be the case. If KSomeApp developers decide they don't care about Mac, they shouldn't be under the above restrictions. Workspace applications (kwin, activity manager, and more) are not meant for /strange/ platforms like windows/mac, so they should belong to the later category. So, in a nutshell, the more important for other components something is, the lower should be the required gcc version. Cheerio, Ivan -- Money can't buy happiness, but neither can poverty. -- Leo Rosten
Re: Compiler version
On Thu, Jun 28, 2012 at 10:55 AM, Ivan Cukic ivan.cu...@kde.org wrote: From Ben Cooksley: Debian Squeeze has gcc 4.4.5, and this is the base of build.kde.org. It would be appreciated if we did not have to run Debian Testing on the build slaves. Honestly, while having Jenkins around is quite neat, I don't see a helper tool as a valid reason to make the development more difficult. I was simply requesting that the dependency is not raised unnecessarily (lambdas seem to definitely be desirable). I understand however that 4.4.5 is indeed quite old and that a different underlying base may be needed however to be able to build some components of KDE. Anyhow, guessing that we will not agree about raising the requirement for the libraries, not for the forseable future, and that is more or less fine for me. Libraries are always a special case. The second are applications. To quote Martin: Thanks for bringing up the issue, I actually intended to write a similar mail tomorrow to request that applications are allowed to require compilers supporting C++11 features. IMO, application developers should choose which range of systems they want to target. For example, for core things that should run (kded, kwallet, etc.???) on Lin/Win/Mac, ok, the requirement can't be above 4.2. For applications that are not essential to the rest of the environment to function properly, this shouldn't be the case. If KSomeApp developers decide they don't care about Mac, they shouldn't be under the above restrictions. Workspace applications (kwin, activity manager, and more) are not meant for /strange/ platforms like windows/mac, so they should belong to the later category. So, in a nutshell, the more important for other components something is, the lower should be the required gcc version. Cheerio, Ivan -- Money can't buy happiness, but neither can poverty. -- Leo Rosten Regards, Ben
Review Request: Remove image/x-wmf and image/x-xfig from image thumbnailer's supported mimetypes
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105371/
---
Review request for KDE Runtime.
Description
---
The declared-as-supported mimetypes of the image thumbnailer are quite broad,
assuming a lot of QImageIOPlugin existing and installed. But at least for x-fig
and wmf there are no such plugins known, by what I can tell. So the claim of
support is wrong.
Worse: There is no safe way to install an own, better thumbnailer, that one
would be only chosen by pure luck. Reason is that the thumbnail creation
invoking code just greps the first in the list of found thumbnail plugins, see
the code in kde-runtime/kioslave/thumbnail/thumbnail.cpp:
QString ThumbnailProtocol::pluginForMimeType(const QString mimeType) {
KService::List offers = KMimeTypeTrader::self()-query( mimeType,
QLatin1String(ThumbCreator));
if (!offers.isEmpty()) {
KService::Ptr serv;
serv = offers.first();
return serv-library();
}
[...]
E.g. trying to install an own xfig thumbnailer failed for me.
While changing the above code to use KMimeTypeTrader::preferredService(...)
surely might be also good to do, I have no idea about the impact.
For now I just would like to have those two wrong claims removed.
Okay to backport to 4.9 (and 4.8)?
Diffs
-
kioslave/thumbnail/imagethumbnail.desktop 53c9a33
Diff: http://git.reviewboard.kde.org/r/105371/diff/
Testing
---
Thanks,
Friedrich W. H. Kossebau
