KAr class - No support for writing
Hi, I have a short question about the matter in the topic. :) I have just realized: there is no implementation for writing inside the KAr class. May I ask what the reason is for this situation ? Personally, based on the fact that KTar and KZip, which are also subclasses of KArchive, both support reading and writing, I think an implementation for writing in KAr might make sense. I am asking because we would like to write "ar" files in our KDE project, so there is a need for this on our side. I can also help with this task to implement it (as I have already done similar previously, but in a very low-level way with C (: ), if it is not against the design in some way. Is it a design decision to not support this functionality this way ? Thank you in advance! Best Regards, Laszlo Papp
Compilation issue with Mobile profile on Harmattan/Maemo6
Hi, I would like to ask for help with this issue becauseI have run out of the ideas. The inconsistent "selectionClipboardUrlPasted" is a signal. I guess with "Mobile" profile (no deprecated mode), it should not occur that way in the moc file. It is just a guess-work though. I am trying to build the active-development/4.7 branch. This is the hash of the last commit in my local folder: d1a3ccd. I did also try to regenerate this file after a manual removal, but that did apparently not help. I tried to build it after removing the whole debian folder content. The "Mobile" profile compilation worked just fine for my host PC with the same "active-development/4.7." branch, That is the exact command I was trying to run from my build directory: "cmake ../ -DKDE_PLATFORM_PROFILE=Mobile" Thank you in advance! Best Regards, Laszlo Papp /scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdewebkit/kwebwallet.cpp:133: instantiated from here /usr/include/qt4/QtCore/qlist.h:399: warning: cast from 'QList::Node*' to 'QVariant*' increases required alignment of target type /usr/include/qt4/QtCore/qlist.h:405: warning: cast from 'QList::Node*' to 'QVariant*' increases required alignment of target type /targets/maemo6-armv7/usr/bin/cmake -E cmake_progress_report /scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/build/CMakeFiles [ 97%] Building CXX object kdewebkit/CMakeFiles/kdewebkit.dir/kgraphicswebview.o cd /scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/build/kdewebkit && /scratchbox/compilers/bin/c++ -DMAKE_KDEWEBKIT_LIB -D_BSD_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=43 -DQT_USE_FAST_CONCATENATION -DQT_USE_FAST_OPERATOR_PLUS -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -O2 -g -DNDEBUG -DQT_NO_DEBUG -fPIC -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/build/kdewebkit -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdewebkit -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/build -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/interfaces -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kjs -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/build/kjs -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/build/kdecore -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/compression -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/config -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/date -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/io -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/jobs -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/kernel -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/auth -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/network -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/services -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/localization -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/sycoca -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/text -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/util -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdecore/sonnet -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/actions -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/colors -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/config -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/dialogs -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/findreplace -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/fonts -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/icons -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/itemviews -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/jobs -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/kernel -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/notifications -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/paged -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/plotting -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/shortcuts -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/sonnet -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/util -I/scratchbox/users/lpapp/home/lpapp/kde_test/kdelibs/kdeui/widgets -I/scratchbox/users/lpapp/home/lpapp/kde_test/kd
Re: Review Request: Only include nepomuk directories if nepomuk is available
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101949/#review4755 --- Ship it! The compilation issue was not personally talkative enough when I tried to build kdelibs without sdo installed (it has not been packaged for this architecture that time). I have tested it more times in scratchbox for Harmattan, N9 and it works just fine without shared-desktop-ontologies installed. - Laszlo On July 14, 2011, 2:40 p.m., Bjoern Ricks wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101949/ > --- > > (Updated July 14, 2011, 2:40 p.m.) > > > Review request for kdelibs. > > > Summary > --- > > kdelibs build fails if sdo and/or soprano aren't available > > > Diffs > - > > kparts/CMakeLists.txt db76613 > > Diff: http://git.reviewboard.kde.org/r/101949/diff > > > Testing > --- > > > Thanks, > > Bjoern > >
Re: Compilation issue with Mobile profile on Harmattan/Maemo6
Hi, > Looks like the issue David fixed here: > https://projects.kde.org/projects/kdesupport/automoc/repository/revisions/a003654d36b9e409931d15af68091d1f366bd46e Thank you for the link, Volker. That solved one of my issues. I could build and then package kdelibs for Harmattan after all (it will take me a while to get it also working on the Community OBS). Best Regards, Laszlo Papp
Re: KF5 & Qt5 - QtCS Session
Hi, > A draft list was made of some areas for focus with names drafted in against > them: > ... > * KJob - Qt-Addon for 5.1 Is the lack of manpower the reason or something else it is not planned against 5.0 ? I have made some simple modifications in our project where it is now KDE dependency free. > This is by no means complete yet so please suggest other areas and names. How about these classes ? http://api.kde.org/4.5-api/kdelibs-apidocs/kdecore/html/classKArchive.html There have been many times that I have experience the need for archiving operations inside Qt framework, in various pure Qt projects. This has also been the feedback from more friends about their projects. Here you can find an example in this thread: http://lists.kde.org/?l=kde-devel&m=130762214616848&w=2. It currently requires more things to port prior to getting it work. It uses KSaveFile for atomic file operation and some dependencies from kde_file.h and kde_file_win.h. The subclasses of KArchive also use the KFilterDev class internally and KMimeType. As we can see, mimetypes are on the way, at least it is in your list. ;-) I have been trying to experiment with them in our pure Qt codebase for a while, and there is some progress. It might be that, it is a bit late. Unfortunately, I have just only now found the time to answer. I am not sure about the legal part of kde codebase reuse, but let me know if there is anything i can do to help. Thank you in advance! :) Best Regards, Laszlo Papp
Re: How to get krazy check playground/ksecretservice ?
Hi, > In playground/base (SVN) create a file called .krazy with the line: > EXTRASUBS ksecretservice > > then commit playground/base/.krazy Are there any plans to parse some xml on projects.kde.org so as to get rid of SVN entries, if your project is on projects.kde.org ? Best Regards, Laszlo Papp
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
Hi, > kdeinit can be replaced by prelinking, assuming you are not a user of the > NVidia binary drivers. If you are, you can't prelink, so kdeinit is a help: > > /usr/sbin/prelink: /usr/bin/gears: Cannot prelink against non-PIC shared > library /usr/lib/nvidia-current/libGL.so.1 The nvidia driver does a lot of tricks and libGL is not a PIC library, but that does not matter. My understanding was that kdeinit cannot be replaced by prelinking in any case since they are two different things. In harmattan the preloader is called booster, and it basically does a dlopen() on important libraries and we also use prelinking. They live together. I think prelink and kdeinit could work together, but please fix me. Prelink or cross-prelink could just be used by the distributions (but it should be done after install, just like debian does, prelink is setup in cron) to make it clear. :) Unfortunately I missed this session because of the football match. I think kdeinit is a nice thing over there. PIE executables had some different purpose, mostly security related. For some reason, some people started abusing them. There was an article by Jakub explaining this. I can not seem to find it right now. In any case, the main advantage of PIE executables was that the executable address space could be randomized, and ldconfig does randomize the address. Basically, this makes buffer-overruns more difficult. One thing is that ld.so ignores prelink information for PIE executables. Other than this I really see no point in them Best Regards, Laszlo Papp
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
> There was an article by Jakub explaining this. I can not seem to find it > right now. Found! :) The first one: http://lwn.net/Articles/190495/ Why PIE should not be prelinked and in general about the main purpose of PIE. > btw, why cannot non-pic libs be prelinked? works for non-pie executables, > after all. Well, by definition, non-pic libraries cannot be prelinked since the symbols are at fixed addresses. You can not change the symbols using prelink. It is mentioned in the prelink manual [1], and prelink goes out of its way to find non-pic libraries and ignore them. You can just read the preface where it says why the libraries should be PIC, and how only PIC libraries can actually be prelinked. Oh, and one point. I am not familiar with systemd, but AFAIK too bloated as it is. It has a lot of code in it that should not be in the startup program, for instance: it has code to plymouth in it. That is a bit funny, but it might be just that I am lacking something... :) Best Regards, Laszlo Papp [1] http://docs.google.com/viewer?url=http%3A%2F%2Fpeople.redhat.com%2Fjakub%2Fprelink.pdf
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
> Also: we need to be sure that prelinkers do prelink PIE, despite the article > that Laszlo linked to. 1) prelink tries very very hard to skip PIE 2) ld.so ignores prelink information for PIE anyways so even if you force a PIE prelink you don't get anything There is no point in prelinking PIE since the prelink information is ignored. Best Regards, Laszlo Papp
Re: Where is kmix hidden?
http://www.kde.org/applications/multimedia/kmix/development On Fri, Aug 19, 2011 at 3:40 PM, Mark wrote: > Hi, > > In git i can only find some kmix scratch repos, but it seems nowhere > to be found on http://quickgit.kde.org/. > > What i want to do (or try) is looking at the kmix code that is in the > system settings and i want to look at the kmix plasmoid that you see > in the notification area. (some pointers where to look would be > awesome) > I sadly can't find any of those besides an ancient kdemultimedia git > repo from 2007: http://repo.or.cz/w/kdemultimedia.git > > Kind regards, > Mark >
Review Request: Replicate the existing KConfigDialog constructor and change one argument type
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103716/ --- Review request for kdelibs and Jeremy Paul Whiting. Description --- Use case: there are applications like kanagram which would be nice to have running on several platforms, like handsets; for instance Harmattan on N9. It would be nice to use the same settings code generation in certain cases for all the platforms since the additions of KConfigSkeleton on the top of KCoreConfigSkeleton are the font and color settings. These are currently not used in many KDE applications. Hence, it should not be mandatory. The kdeui module is unlikely welcome on mobile platforms, especially in appstores with its sizes and complexity for no real need. KConfigDialogManager has apparently already two constructors; one with KConfigSkeleton argument type, and yet another with KCoreConfigSkeleton. It looks like a situation where the KCoreConfigSkeleton version was added later. KConfigDialog does not have a constructor yet with KCoreConfigSkeleton argument type yet; it has probably somehow been missed so far. Changing the current constructor to KCoreConfigSkeleton usage is not possible in the 4.X major version because of the consequences (ABI breakage). Thereby, the freshly replacated constructor. The proper fix can be filed against frameworks where there is only one, and properly working constructor. Diffs - kdeui/dialogs/kconfigdialog.h 2ac0eda kdeui/dialogs/kconfigdialog.cpp e815e54 Diff: http://git.reviewboard.kde.org/r/103716/diff/diff Testing --- On Archlinux (build test only) Thanks, Laszlo Papp
Review Request: Use KCoreConfigSkeleton argument type where possible inside the KConfigDialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103719/ --- Review request for kdelibs and Jeremy Paul Whiting. Description --- Use case: there are applications, like kanagram, which would be nice to have running on several platforms, as in handsets; for instance Harmattan on N9. It would be nice to use the same settings code generation in certain cases for all the platforms. The additions of KConfigSkeleton on the top of KCoreConfigSkeleton are the font and color settings which are currently not used in couple of KDE applications. Hence, it should not be mandatory. The kdeui module is unlikely welcome on mobile platforms, especially in appstores with its sizes and complexity for no real need. KConfigDialogManager has apparently already two constructors (ie.: the need already arised previously for such an approach); one with KConfigSkeleton argument type, and yet another with KCoreConfigSkeleton. It looks like a situation where the KCoreConfigSkeleton version was added for good. The KConfigDialog constructor does not handle KCoreConfigSkeleton argument type yet; it has probably somehow been missed so far. Changing the current constructor to KCoreConfigSkeleton usage is a good way because it does not cause any API break; a simple recompilation is enough in client applications. Diffs - kdeui/dialogs/kconfigdialog.h 2ac0eda kdeui/dialogs/kconfigdialog.cpp e815e54 Diff: http://git.reviewboard.kde.org/r/103719/diff/diff Testing --- Build test on Linux Thanks, Laszlo Papp
Re: Review Request: Replicate the existing KConfigDialog constructor and change one argument type
> On Jan. 17, 2012, 10:28 p.m., David Faure wrote: > > > "The kdeui module is unlikely welcome on mobile platforms" > > > > Why is this review about adding stuff to kdeui, then? I don't get it. > > Either you're using it or you're not using it -- or the real reason is > > core/gui split in your libs/apps, which would be a valid point. The desktop application uses kdeui. KConfigDialog (QWidget *parent, const QString &name, KConfigSkeleton *config) -> It is now impossible to generate only one settings class inheriting KCoreConfigSkeleton, and use that in each frontend. I would not like to generate distinct settings classes without no real reasons. Also, I discarded this patch because it is possible to make this API addition to 4.X. See my patch in frameworks. - Laszlo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103716/#review9903 ------- On Jan. 17, 2012, 3:54 p.m., Laszlo Papp wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103716/ > --- > > (Updated Jan. 17, 2012, 3:54 p.m.) > > > Review request for kdelibs and Jeremy Paul Whiting. > > > Description > --- > > Use case: there are applications like kanagram which would be nice to have > running on several platforms, like handsets; for instance Harmattan on N9. It > would be nice to use the same settings code generation in certain cases for > all > the platforms since the additions of KConfigSkeleton on the top of > KCoreConfigSkeleton are the font and color settings. These are currently not > used in many KDE applications. Hence, it should not be mandatory. The kdeui > module is unlikely welcome on mobile platforms, especially in appstores with > its sizes and complexity for no real need. > > KConfigDialogManager has apparently already two constructors; one with > KConfigSkeleton argument type, and yet another with KCoreConfigSkeleton. It > looks like a situation where the KCoreConfigSkeleton version was added later. > > KConfigDialog does not have a constructor yet with KCoreConfigSkeleton > argument > type yet; it has probably somehow been missed so far. Changing the current > constructor to KCoreConfigSkeleton usage is not possible in the 4.X major > version because of the consequences (ABI breakage). Thereby, the freshly > replacated constructor. The proper fix can be filed against frameworks where > there is only one, and properly working constructor. > > > Diffs > - > > kdeui/dialogs/kconfigdialog.h 2ac0eda > kdeui/dialogs/kconfigdialog.cpp e815e54 > > Diff: http://git.reviewboard.kde.org/r/103716/diff/diff > > > Testing > --- > > On Archlinux (build test only) > > > Thanks, > > Laszlo Papp > >
Re: Review Request: Replicate the existing KConfigDialog constructor and change one argument type
> On Jan. 17, 2012, 10:28 p.m., David Faure wrote: > > > "The kdeui module is unlikely welcome on mobile platforms" > > > > Why is this review about adding stuff to kdeui, then? I don't get it. > > Either you're using it or you're not using it -- or the real reason is > > core/gui split in your libs/apps, which would be a valid point. > > Laszlo Papp wrote: > The desktop application uses kdeui. > > KConfigDialog (QWidget *parent, const QString &name, KConfigSkeleton > *config) -> It is now impossible to generate only one settings class > inheriting KCoreConfigSkeleton, and use that in each frontend. I would not > like to generate distinct settings classes without no real reasons. > > Also, I discarded this patch because it is possible to make this API > addition to 4.X. See my patch in frameworks. It is impossible to make this API addition to 4.X* - Laszlo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103716/#review9903 --- On Jan. 17, 2012, 3:54 p.m., Laszlo Papp wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103716/ > --- > > (Updated Jan. 17, 2012, 3:54 p.m.) > > > Review request for kdelibs and Jeremy Paul Whiting. > > > Description > --- > > Use case: there are applications like kanagram which would be nice to have > running on several platforms, like handsets; for instance Harmattan on N9. It > would be nice to use the same settings code generation in certain cases for > all > the platforms since the additions of KConfigSkeleton on the top of > KCoreConfigSkeleton are the font and color settings. These are currently not > used in many KDE applications. Hence, it should not be mandatory. The kdeui > module is unlikely welcome on mobile platforms, especially in appstores with > its sizes and complexity for no real need. > > KConfigDialogManager has apparently already two constructors; one with > KConfigSkeleton argument type, and yet another with KCoreConfigSkeleton. It > looks like a situation where the KCoreConfigSkeleton version was added later. > > KConfigDialog does not have a constructor yet with KCoreConfigSkeleton > argument > type yet; it has probably somehow been missed so far. Changing the current > constructor to KCoreConfigSkeleton usage is not possible in the 4.X major > version because of the consequences (ABI breakage). Thereby, the freshly > replacated constructor. The proper fix can be filed against frameworks where > there is only one, and properly working constructor. > > > Diffs > - > > kdeui/dialogs/kconfigdialog.h 2ac0eda > kdeui/dialogs/kconfigdialog.cpp e815e54 > > Diff: http://git.reviewboard.kde.org/r/103716/diff/diff > > > Testing > --- > > On Archlinux (build test only) > > > Thanks, > > Laszlo Papp > >
Re: hard-dep for Qt 4.8
> To contribute to the actual question in this thread: I'd say let's support > both for now. And the responsibility is shared: developers should check for > "since 4.8" tags when looking at Qt api docs, and people using 4.7 to compile > kde must accept that they'll sometimes hit a breakage due to 4.8-only api > being used (and then either fix it or report it). To be re-evaluated when 4.8 > is more commonly used. +1. My additional note is that: Qt 4.8 is most likely not going to be available for Harmattan (unlike qt5) because of several reasons; whereas it would be nice to get new KDE versions for our N9/N950 devices (kdelibs, plasma-components and so forth). I would personally be a bit disappointed, if I cannot experiment with hot features, like plasma components, on my Harmattan, if the hard dependency is agreed upon. It is just my two cents though. :) Best Regards, Laszlo Papp
Review Request: Add yet another code generation option for having invokable methods
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103815/ --- Review request for kdelibs and David Faure. Description --- The patch addresses the current issue, for instance with QML-based KDE UIs. There is no clean way currently for having, for example a Settings page for a KDE Mobile application, and interact with the backend (generated code) directly from the QML bits. The current workaround is to have proxy methods in a helper class that are properly exposed to QML. There are no visible drawbacks for this extension as far as a programmer might wanna expose it on wish. :) The patch has a minor "drawback" because it puts the "static" keyword in line with the rest of the method declaration, so resides the Q_INVOKABLE macro. It is not any source or binary incompatible change though, just generated code-style internals. The patch is simpler and cleaner this way, and I personally prefer the not split declaration as well. Although this is behind the main point of the addition, thus can be altered, if needed. Diffs - kdecore/kconfig_compiler/README.dox b9606f1 kdecore/kconfig_compiler/kconfig_compiler.cpp 4203d30 Diff: http://git.reviewboard.kde.org/r/103815/diff/diff Testing --- Tested and works properly on Archlinux (build- and runtime). The Q_INVOKABLE accessor and mutator methods are properly generated. That said, it is being planned against the "frameworks" branch since no new features involved in the KDE4.X series anymore. Thanks, Laszlo Papp
Re: Review Request: Add yet another code generation option for having invokable methods
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103815/#review10218 --- An option for using Q_PROPERTY macros with NOTIFY signals might make a bit more sense since that is even handier to use than Q_INVOKABLE methods for settings (read/write) in QML. We would also have an "onFoobarChanged" signal handler then in QML for these properties. I am eager to implement that, but it is going to be a bit more intrusive patch, and work from me. - Laszlo Papp On Jan. 28, 2012, 8:39 p.m., Laszlo Papp wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103815/ > --- > > (Updated Jan. 28, 2012, 8:39 p.m.) > > > Review request for kdelibs and David Faure. > > > Description > --- > > The patch addresses the current issue, for instance with QML-based KDE UIs. > There is no clean way currently for having, for example a Settings page for a > KDE Mobile application, and interact with the backend (generated code) > directly from the QML bits. > > The current workaround is to have proxy methods in a helper class that are > properly exposed to QML. There are no visible drawbacks for this extension as > far as a programmer might wanna expose it on wish. :) > > The patch has a minor "drawback" because it puts the "static" keyword in line > with the rest of the method declaration, so resides the Q_INVOKABLE macro. It > is not any source or binary incompatible change though, just generated > code-style > internals. The patch is simpler and cleaner this way, and I personally prefer > the not split declaration as well. Although this is behind the main point of > the addition, thus can be altered, if needed. > > > Diffs > - > > kdecore/kconfig_compiler/README.dox b9606f1 > kdecore/kconfig_compiler/kconfig_compiler.cpp 4203d30 > > Diff: http://git.reviewboard.kde.org/r/103815/diff/diff > > > Testing > --- > > Tested and works properly on Archlinux (build- and runtime). The Q_INVOKABLE > accessor and mutator methods are properly generated. That said, it is being > planned against the "frameworks" branch since no new features involved in the > KDE4.X series anymore. > > > Thanks, > > Laszlo Papp > >
Review Request: Make the writeConfig() method a public slot
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103829/ --- Review request for kdelibs and David Faure. Description --- According to the kconfig-xt example [1], it seems to me we need to call this method for settings changing. Therefore, it is not enough to just set the certain properties separately. I currently need to wrap this writeConfig() method in a helper class in order to get an invokable or slot version. There are at least two ways of addressing the issue in question: 1) Make the current method Q_INVOKABLE 2) Make the method actually a slot I personally chose the second alternative since the method already returns void, thus a potential candidate for being a slot. According to the Qt documentation, it is not a problem for having a virtual (public) slot: "You can also define slots to be virtual, which we have found quite useful in practice." [1] http://techbase.kde.org/Development/Tutorials/Using_KConfig_XT#Example Diffs - kdecore/config/kcoreconfigskeleton.h b42ff22 Diff: http://git.reviewboard.kde.org/r/103829/diff/diff Testing --- Tested on Archlinux for building only. Thanks, Laszlo Papp
Re: Review Request: New KPart extension for manupilating a browser engine's settings
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103973/#review10609 --- Is it acceptable to send new features/extensions against KDE4.x ? I had the impression only bugfixes, and I tried to push my changes against the frameworks branch instead. I may have been wrong with that though. - Laszlo Papp On Feb. 13, 2012, 7 p.m., Dawit Alemayehu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103973/ > --- > > (Updated Feb. 13, 2012, 7 p.m.) > > > Review request for kdelibs and David Faure. > > > Description > --- > > This patch adds a new KPart extension, BrowserSettingsExtension, for setting > as well as accessing a browser engine's properties in a generic fashion from > KPart plugins. This is yet another step towards making Konqueror's plugins > and settings module independent of the default browser engine in use. IOW, > they do not have to directly link to a specific browser engine. > > > Diffs > - > > kparts/CMakeLists.txt 96fa31f > kparts/browsersettingsextension.h PRE-CREATION > kparts/browsersettingsextension.cpp PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/103973/diff/ > > > Testing > --- > > > Thanks, > > Dawit Alemayehu > >
Re: Please avoid noisy merge commits in frameworks
Hi, > There's some ideas for such hooks on the Internet already: Yes, there are things flowing around, whereas it would be nice to have a "Getting started" frameworks contribution page, where the advices (requirements) could be mentioned, like this. Is there already something like that ? Best Regards, Laszlo Papp
Re: Please avoid noisy merge commits in frameworks
> Is there already something like that ? There is already something here: http://community.kde.org/Frameworks/Git_Workflow#Local_branches_are_always_rebased.2C_remote_branches_never Might be a good idea to extend it with "git config branch.autosetuprebase always" and the gitk advice. -- Laszlo
Re: Review Request: Replicate the existing KConfigDialog constructor and change one argument type
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103716/ --- (Updated Feb. 21, 2012, 3:56 p.m.) Review request for kdelibs and David Faure. Description --- Use case: there are applications like kanagram which would be nice to have running on several platforms, like handsets; for instance Harmattan on N9. It would be nice to use the same settings code generation in certain cases for all the platforms since the additions of KConfigSkeleton on the top of KCoreConfigSkeleton are the font and color settings. These are currently not used in many KDE applications. Hence, it should not be mandatory. The kdeui module is unlikely welcome on mobile platforms, especially in appstores with its sizes and complexity for no real need. KConfigDialogManager has apparently already two constructors; one with KConfigSkeleton argument type, and yet another with KCoreConfigSkeleton. It looks like a situation where the KCoreConfigSkeleton version was added later. KConfigDialog does not have a constructor yet with KCoreConfigSkeleton argument type yet; it has probably somehow been missed so far. Changing the current constructor to KCoreConfigSkeleton usage is not possible in the 4.X major version because of the consequences (ABI breakage). Thereby, the freshly replacated constructor. The proper fix can be filed against frameworks where there is only one, and properly working constructor. Diffs (updated) - kdeui/dialogs/kconfigdialog.h 2ac0eda kdeui/dialogs/kconfigdialog.cpp e815e54 Diff: http://git.reviewboard.kde.org/r/103716/diff/ Testing --- On Archlinux (build test only) Thanks, Laszlo Papp
Re: Preparing MWC
Excellent plans, Alex ! Please add the available applications on Harmattan in here, if the list is not complete, outdated and so forth: http://community.kde.org/KDE_Mobile/Harmattan#Ported_Application Off topic: Keep an eye on Nokia ;) http://www.youtube.com/watch?v=iZlE4uWnFqI Best Regards, Laszlo Papp On Wed, Feb 22, 2012 at 12:19 PM, Alex Fiestas wrote: > Mext week the biggest mobile congress will start in Barcelona from 27 February > to 1 March. I got an invitation for the developing area and I'm planning to do > some networking KDE related and I want to go well prepared :) > > So far this is what I got: > -I will download all our Harmattan apps > -I will setup Calligra on my Android tablet > -I will setup active in my exoPC (this should include PIM) > > Is there anything more I should have with me? what I'm missing? maybe > something from ownCloud? > > Also, if somebody else is comming we can organize a dinner or something :)
Re: bugzilla situation
> The suggestion remains: to allow everyone to edit and close bugs, as is > apparently the case in some other bug trackers. +1. Worked fine on the MeeGo bugzilla for instance, I previously used. Best Regards, Laszlo Papp
Re: Review Request: Port shutdown dialog to QML
> On Feb. 6, 2012, 9:38 p.m., Alexander Neundorf wrote: > > Good from my POV (cmake stuff). > > Christoph Feck wrote: > UI-wise looks also fine. Was there anything else we needed to do? If not, > merge to master. Thanks, you rock! Alex, we need this FindKdeclarative.cmake in kdelibs, and not in this repository since it is used by almost every single KDE Mobile Applications in theory (one common use case is the localization)... Are you fine with this "quick" solution, if I push it against KDE/4.8 ? I do not personally have time for learning this *Config.cmake, and we would not like to hard code "kdeclarative" into the target_link_libraries either. If someone felt like volunteering with a proper config file, I would be happy. :-) - Laszlo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103621/#review10379 --- On Feb. 4, 2012, 2:04 p.m., Lamarque Vieira Souza wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103621/ > --- > > (Updated Feb. 4, 2012, 2:04 p.m.) > > > Review request for KDE Base Apps and KDE Runtime. > > > Description > --- > > Port shutdown dialog to QML. Two QML themes are included: default, which > mimics the current shutdown dialog look & feel, and contour, which is used in > Plasma Active. > > > This addresses bugs 216853 and 216853. > http://bugs.kde.org/show_bug.cgi?id=216853 > http://bugs.kde.org/show_bug.cgi?id=216853 > > > Diffs > - > > ksmserver/CMakeLists.txt 295b96e > ksmserver/Copyright.txt PRE-CREATION > ksmserver/FindKDeclarative.cmake PRE-CREATION > ksmserver/Messages.sh 0aa8bab > ksmserver/shutdown.cpp 7fd1e11 > ksmserver/shutdowndlg.h e5f0942 > ksmserver/shutdowndlg.cpp a09a1a7 > ksmserver/themes/contour/ContourButton.qml PRE-CREATION > ksmserver/themes/contour/main.qml PRE-CREATION > ksmserver/themes/contour/metadata.desktop PRE-CREATION > ksmserver/themes/contour/screenshot.png PRE-CREATION > ksmserver/themes/default/ContextMenu.qml PRE-CREATION > ksmserver/themes/default/KSMButton.qml PRE-CREATION > ksmserver/themes/default/MenuItem.qml PRE-CREATION > ksmserver/themes/default/helper.js PRE-CREATION > ksmserver/themes/default/main.qml PRE-CREATION > ksmserver/themes/default/metadata.desktop PRE-CREATION > ksmserver/themes/default/screenshot.png PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/103621/diff/ > > > Testing > --- > > Works in Plasma Active Two using MeeGo image and KDE SC 4.8. It does not work > in 4.7.x because the default theme requires kde-runtime 4.8's declarative > imports. > > TODO: > > . test right to left language support. > > > Screenshots > --- > > > http://git.reviewboard.kde.org/r/103621/s/400/ > New version with label accelerator working > http://git.reviewboard.kde.org/r/103621/s/407/ > > > Thanks, > > Lamarque Vieira Souza > >
Re: Review Request: Add cmake config for kdeclarative library.
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104140/#review11090
---
I am a bit of layman in here (thus pardon me), but I would personally prefer a
separated location for these config files. Something like either cmake/modules
or in the experimental subfolder itself right next to the "CTestConfig.cmake"
(I do not personally know what is the best practice here). You can see an
example for cmake/modules from Stephen in grantlee, but the cmake example,
about it, puts it into the $projectroot. Admittedly, it would be nice to hear
some kde-buildsystem guy(s) to comment on this, like Alex, Stephen, etc. :)
Thank you for your effort about it really, by the way!
- Laszlo Papp
On March 2, 2012, 6:01 p.m., Lamarque Vieira Souza wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104140/
> ---
>
> (Updated March 2, 2012, 6:01 p.m.)
>
>
> Review request for kdelibs.
>
>
> Description
> ---
>
> Currently kdeclarative library does not install the KDeclarativeConfig.cmake
> and KDeclarativeConfigVersion.cmake to ${LIB_INSTALL_DIR}/cmake/KDeclarative
> and so other KDE programs cannot find the library using cmake's find_package
> macro.
>
> kde-workspace, kde-runtime and plasma-mobile currently hardcode the
> "kdeclarative" library name in their CMakeLists.txt, which is not ideal. Once
> this patch is submitted we need to fix their CMakeLists.txt to use
> "find_package(KDeclarative REQUIRED)".
>
>
> Diffs
> -
>
> experimental/libkdeclarative/CMakeLists.txt 0db647c
> experimental/libkdeclarative/KDeclarativeConfig.cmake.in PRE-CREATION
> experimental/libkdeclarative/KDeclarativeConfigVersion.cmake.in
> PRE-CREATION
>
> Diff: http://git.reviewboard.kde.org/r/104140/diff/
>
>
> Testing
> ---
>
> I can now compile kde-workspace/ksmserver without using the custom made
> FindKDeclarative.cmake.
>
>
> Thanks,
>
> Lamarque Vieira Souza
>
>
Re: Setting up a Quality Team within KDE
> Well, I'd say jenkins has a lot more to offer than cdash. Its also a lot > simpler to use, setup and understand for newcomers in my opinion. With > jenkins I can have a shell-script job which runs cmake && make && make > test and be done. Setting up a build for submission to cdash takes a lot > more effort - at least it did when I tried to do this maybe things got > easier meanwhile. It has been simpler than I thought when I have set the functionality up with a little bit of guidance last summer. I think we could probably even make the setup easier with some automated script or so by solving the boilerplate part of the relevant cmake files. As far as I see the admin setting this up needs to know some parameters if I am not too mistaken. I do not have any opinions about the web interface differences because I do not visit that. I have been getting the warnings, errors and unit test failures via email, if any. I will also try out this Jenkins in the future once I find the time for that, but I have been a happy CDash user for about ten months by now. :-) Best Regards, Laszlo Papp
Re: Setting up a Quality Team within KDE
> Hmm, that may work if your project has usually no warnings, but I find > this for warnings to be too much noise. We have also had many warnings back then. :-) > The CI mails should immediately > tell me if CI is considered broken (and warnings are often not > considered that) or not and if its broken show me the error so I don't > need to go to the website to fix it - ideally. That can be done as far as I know. It also shows the warnings, but it might be that you need to click on the link you receive in the email, if you have many warnings. It redirects you to the list so that you can go through your codebase to fix those. I have never found the web interface for this goal disadvantageous yet. >> I will also try out this Jenkins in the future once I find the time >> for that, but I have been a happy CDash user for about ten months by >> now. :-) > > build.kde.org can give you a pretty good idea of how jenkins "looks" and > can be used to do CI. I do not personally find the page aforementioned having that professional layout as the CDash site, but that might be just me. Also, I personally find the CDash site simpler to use. My personal worry is that, I would not like to refactor the setup already existing and working just fine for a while unless there is a compelling reason and the switch is simple. Also, I do not see Playground projects on the build.kde.org site. In addition, if it is just for KDE, it would result me using different services for Qt Playground and KDE projects. That would be a bit unhandy. I could use CDash for both. That having said, CDash was designed with CMake in mind. We already depend on CMake and CTest. Those three projects are maintained by the same company, if I am not mistaken, called "Kitware" (and probably also by community volunteers). Therefore, we can be sure about the integrity and so forth. On the contrary I can somewhat understand the need for a community driven site even if it is quite unlike Kitware just goes away. They have not been doing that with cmake either for many years. They respect KDE, and Alex has always been very helpful with those topics. :-) The current setup is comfortable and good enough to me, but I am open, thus I will check out Jenkins. Best Regards, Laszlo Papp
Re: Setting up a Quality Team within KDE
> Also IIRC there was a blog-post inviting people to submit requests for the > addition of their > projects. I believe, I missed that. > I also don't see any KDE playground apps on my.cdash.org :) http://my.cdash.org/index.php?project=Gluon http://my.cdash.org/index.php?project=QtOpenAL (You do not find it in playground since it was deleted 1-2 days ago after migrating to Qt Playground, but it has been hosted there). Unfortunately, I had some server issues recently though that I did not have time to deal with. At any rate, playground projects should be able to have quality services on wish as well IMO. > If one is involved with different projects outside of Qt/KDE then its > quite normal to have to deal with various types of web-services. So > personally I don't think thats a good enough reason to ignore the > benefits that jenkins does provide. That is not so simple. Once you get used to the feeling and you settle down you can use the same service for multiple projects, it is a bit difficult to persuade yourself it is worth changing in order to have more services to get familiar with. Like I said, as for me, it needs to have a compelling reason with smooth transition and simple usage in the future as well. As for my case, I would not just personally like to get involved in two different services, if I am fine with one. > In addition as was said elsewhere in the thread, the jenkins job could > submit their data to cdash too if the projects are set up for that. :-) Meanwhile, I trust you it is possible to do that, I prefer to avoid the multilayering, if possible. >> That having said, CDash was designed with CMake in mind. We already >> depend on CMake and CTest. > > We actually do not depend on CTest, that is an optional tool, one can > run the tests without ctest (in fact I've never used CTest on my > machines). I stand corrected, you are right about that. You can use "make test" without getting involved with CTest. [...] > all I care about is that its easy to get a project set up to > be build continously (and the unit-tests executed) and wether it > provides more than just build errors/warnings and test-results. Since > some of these things are handy - especially when working on libraries. Could you please precisely enumerate the technical pros and cons so that we can all understand ? Thank you in advance! Best Regards, Laszlo Papp
Re: Setting up a Quality Team within KDE
>> I also don't see any KDE playground apps on my.cdash.org :) > > http://my.cdash.org/index.php?project=Gluon > http://my.cdash.org/index.php?project=QtOpenAL (You do not find it in > playground since it was deleted 1-2 days ago after migrating to Qt > Playground, but it has been hosted there). Ah yes, and also my playground dictionary I worked on: http://my.cdash.org/index.php?project=Mula Best Regards, Laszlo Papp
Re: kdelibs/Qt 4.8
On Tue, Apr 10, 2012 at 1:22 PM, Marco Martin wrote: > Hi all, > just to signal a small issue, > at the moment kdelibs from the 4.8 branch seems to require Qt 4.8: > http://pastebin.com/zqPGYRqa > as Qssl::TlsV1SslV3 esists only in Qt 4.8 > > wasn't decided to keep that branch on Qt 4.7? I had that impression. Unfortunately Harmattan does not still have Qt 4.8 and it does not seem to be the direction to upgrade to that version. I would personally like to have updated kdelibs in there, if possible. We have already put a lot of effort to have the KDE stack in there up and running. It would be a pity, if we cannot update to new versions (with bug fixes and so forth). Best Regards, Laszlo Papp
Re: Setting up a Quality Team within KDE
Okay, back to this list then from kde-testing. I have at least tried. :) > Actually, make test invokes CTest behind the scenes[1]. Actually, yes. :-) > That being said, if > we aren't uploading results anywhere, CTest only runs the test executables and > offers nothing else (in this case). If tomorrow we drop CMake/CTest, the > tests would still run fine as is. Yes, they can be run separately. I believe that is also my workflow when a test fails. I run the desired binary in question to see which test methods pass and fail to localize the issue further on. I think "make test", and hence ctest, is a good and handy service after all in my opinion. I am not worried about that, and it comes with cmake (at least on the distributions I use). Best Regards, Laszlo Papp PS.: Plus what Alex said about other ctest usages.
Re: Re: Setting up a Quality Team within KDE
> Afterwards it runs cppcheck on the source code... That is a really nice advantage, if it can be integrated with handy tools. Although, I would personally like to use much more advanced and useful tools than cppcheck. [...] > But overall these are two very useful solutions which do not compete with each > other and we should make use of them in a useful combined way, e.g. by > submitting build results from build.kde.org to CDash. Fair enough, thanks. One additional comment on my side is that, if I read these lines on the jenkins website, I have the impression Jenkins can cover the use case of CDash in the sense of running the build from cron jobs: "Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even those that are run on a remote machine. For example, with cron, all you receive is regular e-mails that capture the output, and it is up to you to look at them diligently and notice when it broke. Jenkins keeps those outputs and makes it easy for you to notice when something is wrong." As far as I have been told, there are no limitations in the future for involving (certain?) playground projects. Although, since it is still just an experiment, even though the outcome looks quite impressive from what I can say, it is probably better to involve kde sc and extragear projects first because of the limited resources. Best Regards, Laszlo Papp
Re: Fwd: import kde-thumbnail-po into kdesdk
> what about through kde reviewboard, like kio-recentdocuments plugin[1] > I don't think it is necessary for a plugin to follow application lifecycle > policy to get into kde main modules or extragear ones. > but I couldn't find the reviewboard group for kdesdk, so I may have to put > this plugin in kdereview and wait reviewing for weeks. I think the important question is where the project should reside in the end. If the project should go into an already existing repository (subproject, like kdesdk/foobar), reviewboard is probably better, but if this plugin should live on its own (for instance in kdesdk directly with separate repository establishment, as you have asked for), then probably application lifecycle as Albert mentioned. Although, kdesdk is still under the svn umbrella [1]. I have been told previously there are plans for the git migration by 4.9, but I am not sure about the current situation with regards to that. My impression is that the "submodules" in kdesdk should be separated in the end (after the git migration, the latest), so I do not need to clone "okteta" for instance, if I would just like to work on "lokalize". Best Regards, Laszlo Papp [1] http://websvn.kde.org/trunk/KDE/kdesdk/
Re: Review Request: Add cmake config for kdeclarative library.
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104140/#review13003
---
Ship it!
Ship It!
- Laszlo Papp
On March 5, 2012, 9:55 p.m., Lamarque Vieira Souza wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104140/
> ---
>
> (Updated March 5, 2012, 9:55 p.m.)
>
>
> Review request for kdelibs.
>
>
> Description
> ---
>
> Currently kdeclarative library does not install the KDeclarativeConfig.cmake
> and KDeclarativeConfigVersion.cmake to ${LIB_INSTALL_DIR}/cmake/KDeclarative
> and so other KDE programs cannot find the library using cmake's find_package
> macro.
>
> kde-workspace, kde-runtime and plasma-mobile currently hardcode the
> "kdeclarative" library name in their CMakeLists.txt, which is not ideal. Once
> this patch is submitted we need to fix their CMakeLists.txt to use
> "find_package(KDeclarative REQUIRED)".
>
>
> Diffs
> -
>
> experimental/libkdeclarative/CMakeLists.txt 0db647c
> experimental/libkdeclarative/KDeclarativeConfig.cmake.in PRE-CREATION
> experimental/libkdeclarative/KDeclarativeConfigVersion.cmake.in
> PRE-CREATION
>
> Diff: http://git.reviewboard.kde.org/r/104140/diff/
>
>
> Testing
> ---
>
> I can now compile kde-workspace/ksmserver without using the custom made
> FindKDeclarative.cmake.
>
>
> Thanks,
>
> Lamarque Vieira Souza
>
>
Re: Review Request: Plasma Components buttons: first focus, than emit clicked() signal
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104893/#review13616 --- I am unsure whether Plasma Components related patches are relevant to k-c-d. I would rather include the plasma devel team for reviews. Other Aaron, Marco or other plasma developers might miss this. :-) - Laszlo Papp On May 9, 2012, 4:41 p.m., Sebastian Gottfried wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104893/ > --- > > (Updated May 9, 2012, 4:41 p.m.) > > > Review request for KDE Runtime. > > > Description > --- > > Otherwise a client wanting to give another QML component the focus in > reaction to a clicked button has no chance doing so because the button > will steal the focus again right after the event hander has finished > executing. > > > Diffs > - > > plasma/declarativeimports/plasmacomponents/qml/Button.qml 6aab1b2 > plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 00ffa4c > > Diff: http://git.reviewboard.kde.org/r/104893/diff/ > > > Testing > --- > > Tested the behaviour in ktouch/next, works fine. > > > Thanks, > > Sebastian Gottfried > >
Re: Review Request: Plasma Components: TextField and TextArea: Show placeholders even if item has the focus
> On May 9, 2012, 6:30 p.m., Mark Gaiser wrote: > > Ehh optional perhaps? > > I've seen forms behave like this before and back then when i first saw it i > > tried to delete the text.. Which obviously didn't happen. The text just > > disappears as soon as i start typing. I kinda dislike that behavior. I > > mean, there is a big fat blue focus border that has the purpose of telling > > the user that the one with the blue border (style dependent) is the one > > that currently has focus. The blinking cursor is yet another indication > > that the field has focus. I think that is enough. > > > > Perhaps optional, but please not by default. This is just my opinion and i > > don't maintain plasma components (nor anything in KDE for that matter). > > You'd have to wait for a reply from some of the plasma component > > maintainers to get a final word on this. > > Sebastian Kügler wrote: > This just fixes a race condition, I don't quite understand your > reservation, Mark? > > David Edmundson wrote: > No it doesn't. Currently if you give an item focus you hide the > placeholder text. In this patch it only hides placeholder text after you > start typing. > > David Edmundson wrote: > ^ That reply was at Sebastian where he says it's a fix, where it's > actually a large visual change. (reviewboard doesn't really show that very > well) > > Sebastian Kügler wrote: > Funny, because I ran into this exact behaviour last night, and to make it > work well, I had to resort to using a Timer which calls forceActiveFocus() on > the TextArea, not quite intuitive either. > > Does anyone have a suggestion which satisfies both usecase without hacks? > > Sebastian Gottfried wrote: > Using a timer to give a text field the focus sounds really strange in my > ears. > > We could obviously extend the API of the text fields with a boolean > property "showPlaceholderWhileFocused" and give the responsibility to decide > on the wanted behaviour to the application developer. But at least me would > prefer a consistent behaviour for all text fields. > > Mark Gaiser wrote: > The behavior is consistent right now. The defacto "standard" on the > internet right now for forms seems to be to have a placeholder text and > remove the placeholder as soon as the field gets focus. However, lately there > have been more sites that do keep the placeholder even while focused and only > moves away if you start typing. Like for example the twitter login page > (though that does make the placeholder text a bit more transparent when you > have the focus). > > I think both options should be provided, but the default should be to > remove the placeholder as soon as it gets focus. > > Yet again just my opinion. > > Mathias Kraus wrote: > How about the following: > - pre-focused text field shows the placeholder > - if the user press any key (e.g. Esc, arrow keys, backspace) or starts > typing, the placeholder disappears and does't appear again, even if the text > field is empty > - it the user clicks into a text field, the placeholder also disappears > immediatelly I do not have too strong opinions about either way; just some additional data fwiw: 1) QLineEdit - clear for focus http://qt-project.org/doc/qt-4.8/qlineedit.html#placeholderText-prop 2) KLineEdit - most likely the same since there is no such an addition for KLineEdit, but inherits this from QLineEdit 3) Harmattan components: clear for typing 4) Symbian components: http://doc.qt.nokia.com/qt-components-symbian/qml-textfield.html#placeholderText-prop 5) Interesting that the following html practice shares the opinions as well: http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_input_placeholder On Linux with firefox, rekonq and so forth, it produces the behavior that the placeholder is gone for focus. On the contrary, the form keeps the placeholder until typing on Windows. - Laszlo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104895/#review13617 --- On May 9, 2012, 4:53 p.m., Sebastian Gottfried wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104895/ > --- > > (Updated May 9, 2012, 4:53 p.m.) > > > Review request for KDE Runtime. > > > Description > --- > > Rationale: This allows the application to pre-focus a text field with a > placeholder text for the user. In the version before this would have > hidden the placeholder text and it may not have been obvious for user > what he was expected to enter in the text field. > > > Diffs > - > > plasma/declarativeimports/plasmacomponents/qml/TextArea.qml 2d9e89f > plasma
Re: Review Request: Plasma Components: TextField and TextArea: Show placeholders even if item has the focus
> On May 9, 2012, 6:30 p.m., Mark Gaiser wrote:
> > Ehh optional perhaps?
> > I've seen forms behave like this before and back then when i first saw it i
> > tried to delete the text.. Which obviously didn't happen. The text just
> > disappears as soon as i start typing. I kinda dislike that behavior. I
> > mean, there is a big fat blue focus border that has the purpose of telling
> > the user that the one with the blue border (style dependent) is the one
> > that currently has focus. The blinking cursor is yet another indication
> > that the field has focus. I think that is enough.
> >
> > Perhaps optional, but please not by default. This is just my opinion and i
> > don't maintain plasma components (nor anything in KDE for that matter).
> > You'd have to wait for a reply from some of the plasma component
> > maintainers to get a final word on this.
>
> Sebastian Kügler wrote:
> This just fixes a race condition, I don't quite understand your
> reservation, Mark?
>
> David Edmundson wrote:
> No it doesn't. Currently if you give an item focus you hide the
> placeholder text. In this patch it only hides placeholder text after you
> start typing.
>
> David Edmundson wrote:
> ^ That reply was at Sebastian where he says it's a fix, where it's
> actually a large visual change. (reviewboard doesn't really show that very
> well)
>
> Sebastian Kügler wrote:
> Funny, because I ran into this exact behaviour last night, and to make it
> work well, I had to resort to using a Timer which calls forceActiveFocus() on
> the TextArea, not quite intuitive either.
>
> Does anyone have a suggestion which satisfies both usecase without hacks?
>
> Sebastian Gottfried wrote:
> Using a timer to give a text field the focus sounds really strange in my
> ears.
>
> We could obviously extend the API of the text fields with a boolean
> property "showPlaceholderWhileFocused" and give the responsibility to decide
> on the wanted behaviour to the application developer. But at least me would
> prefer a consistent behaviour for all text fields.
>
> Mark Gaiser wrote:
> The behavior is consistent right now. The defacto "standard" on the
> internet right now for forms seems to be to have a placeholder text and
> remove the placeholder as soon as the field gets focus. However, lately there
> have been more sites that do keep the placeholder even while focused and only
> moves away if you start typing. Like for example the twitter login page
> (though that does make the placeholder text a bit more transparent when you
> have the focus).
>
> I think both options should be provided, but the default should be to
> remove the placeholder as soon as it gets focus.
>
> Yet again just my opinion.
>
> Mathias Kraus wrote:
> How about the following:
> - pre-focused text field shows the placeholder
> - if the user press any key (e.g. Esc, arrow keys, backspace) or starts
> typing, the placeholder disappears and does't appear again, even if the text
> field is empty
> - it the user clicks into a text field, the placeholder also disappears
> immediatelly
>
> Laszlo Papp wrote:
> I do not have too strong opinions about either way; just some additional
> data fwiw:
>
> 1) QLineEdit - clear for focus
> http://qt-project.org/doc/qt-4.8/qlineedit.html#placeholderText-prop
>
> 2) KLineEdit - most likely the same since there is no such an addition
> for KLineEdit, but inherits this from QLineEdit
>
> 3) Harmattan components: clear for typing
>
> 4) Symbian components:
> http://doc.qt.nokia.com/qt-components-symbian/qml-textfield.html#placeholderText-prop
>
> 5) Interesting that the following html practice shares the opinions as
> well:
>
> http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_input_placeholder
>
> On Linux with firefox, rekonq and so forth, it produces the behavior that
> the placeholder is gone for focus. On the contrary, the form keeps the
> placeholder until typing on Windows.
>
> Thomas Lübking wrote:
> The reason for the "clear on focus" behavior is to not confuse the user
> about the content as soon as the entry is focused ("about to be used")
>
> The "legacy" way in this regard (pre-focused & hinting lineedits) was to
> also prefill the lineedit with the hint and pre-select the entire text
> (especially if you really just want some input here or assume a "Cancel"
> otherwise)
>
Re: Review Request: Apper on kdereview
> Right now the code is at (I've asked kde sysadmin to move to > kdereview, but afaik it will only reflect the projects url): > https://projects.kde.org/projects/playground/sysadmin/apper/repository Yes, the repository can be found here while reviewing: https://projects.kde.org/projects/kdereview/apper/repository Best Regards, Laszlo Papp
Re: Review request: moving libkgoogle to extragear
> Hmm, can really just the word "google" be considered a TM? I would personally ask this question differently: in order to feel safe, can you please prove that it is safe to use ? I recall I had a wrapper library for OpenAL, and I even had to rename that to Audio3D instead of QtOpenAL (I know it is case by case situation). I do not feel safe until a lawyer tells that. Therefore, probably better not to go for "google" usage unless the safetyness is coming from a trustworthy lawyer. Best Regards, Laszlo Papp
Re: Review request: moving libkgoogle to extragear
> I'm sorry, but unless there's an objective objection, I'll rename the library > and everything inside to LibKGAPI. I personally like this the best so far amongst the discussed. Best Regards, Laszlo Papp
Re: kdelibs and Qt version dependency
> To re-iterate, it is policy that any dependency changes are discussed > and approved on k-c-d first. It was discussed and disapproved as far as I understood. Best Regards, Laszlo Papp
Re: kdelibs and Qt version dependency
> Do you have a link for that discussion? http://lists.kde.org/?l=kde-core-devel&m=132630064116231&w=2 Best Regards, Laszlo Papp
Re: Extra KDE Telepathy modules moving to Extragear
> Are there any further objections to moving these forward into extragear? No objections, just a question: How much of this works on Windows ? Unsure about the call UI, but I presume the logger could at least ? Best Regards, Laszlo Papp
Re: Extra KDE Telepathy modules moving to Extragear
On Thu, Jun 7, 2012 at 4:42 PM, Laszlo Papp wrote:
>> Are there any further objections to moving these forward into extragear?
This is probably not the best way:
https://projects.kde.org/projects/kdereview/ktp-call-ui/repository/revisions/master/entry/libktpcall/CMakeLists.txt#L25
https://projects.kde.org/projects/kdereview/ktp-call-ui/repository/revisions/master/entry/src/CMakeLists.txt#L21
Also, FoobarConfig{Version}.cmake is in favor of FindFoobar.cmake in this case:
https://projects.kde.org/projects/kdereview/ktp-call-ui/repository/revisions/master/entry/cmake/modules/FindKTp.cmake
I do not find a shipped FoobarConfig{Version}.cmake for the other one.
Best Regards,
Laszlo Papp
Re: Extra KDE Telepathy modules moving to Extragear
> No objections, just a question: How much of this works on Windows ? > Unsure about the call UI, but I presume the logger could at least ? Last time I tried, I had issues with python3 that the KDE Windows project had been using. I have mentioned that to George. It would be nice in the future (so not now instantly) to get that resolved. I presume this would mean a python3 porting or some other way around. Best Regards, Laszlo Papp
Re: kdelibs and Qt version dependency
> Just checked the Qt docs for 4.8 and this new method is not marked as > new in 4.8, bad Qt coder! Forgot to mention, but should be fixed in the future versions: https://codereview.qt-project.org/#change,28087 Best Regards, Laszlo Papp
Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
>> Thank you for pushing a bunch of untested huge changes in the "minor" >> point >> release. Really appreciated. >> > what are those untested changes please? +1. Bit of nitpick about wording, but 4.8.4 is a new patch level release, not minor. Best Regards, Laszlo Papp
Re: Qt Contributors Summit
> I've created a new page at http://community.kde.org/KDE_at_QCS/QCS_2012 I would suggest using "QtCS" on these wiki pages for consistency. From the event page: "The Qt Contributors Summit (aka QtCS) is the main event of the Qt Project." Perhaps, it is just me, but the QtCS 2011 url is broken in here: http://community.kde.org/KDE_at_QCS I thought to take a look at the notes last year before writing up new ones this time. Best Regards, Laszlo Papp
Re: Patch to add kdoctools/customization/xsl/hu.xml
Hi, Usually, we use reviewboard for patches. For instance, I cannot unfortunately open up this attachment on my phone (N9) for reviewing. I can do that in few hours. Perhaps, you also meant against the frameworks branch (saying this without even seeing the patch). BR, Laszlo On 6/22/12, Kristóf Kiszel wrote: > Hello, > > the attached patch adds the kdoctools/customization/xsl/hu.xml to > kdelibs. Please commit it to KDE/4.8 and to master. > > Kristóf Kiszel >
Re: Patch to add kdoctools/customization/xsl/hu.xml
> Was added already by Yuri yesterday. Sure. I did not want to commit because I am unsure what is the committing policy to the various branches. At any rate, I think the content of the patch is fine, so thanks for the contribution. :) Best Regards, Laszlo Papp
Re: Review request: moving libkgoogle to extragear
> I'm reopening this thread again as I think (and ask you to correct me if not) > the library now meets all the requirements to be moved to extragear. IMO, just go ahead, move to extragear! You had fixed the issues requested more than one month ago (very swiftly) without any further complains. Best Regards, Laszlo Papp
Scope of kde-frameworks-devel and k-c-d mailing lists
Hi, I am having this question: where should the frameworks review requests go? There was a long discussion back then. Some people preferred the establishment of kde-frameworks-devel, some did not. It was created in the end. Now, Albert's patches keep coming in, but it can happen with everybody else as well for sure. If there is a such a list established for frameworks development, I would prefer not to get this mixed up again, and review requests could be sent there. I have been told, it is not possible to have different mailing list default values for different branches with reviewboard, so the contributor should select the relevant for the frameworks branches in my book unless there is a good reason not to do so. In addition, I wanted to read again the scope of the "kde-frameworks-devel" mailing list, but there is no description for that in here: https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Recap: the mailing list was created in the past for separation, so I would like to see k-c-d for KDE4 and kde-frameworks-devel for frameworks personally. I would have personally preferred, if we do not have an additional mailing list for that, but the decision was made, so I need to accept it anyway. :) Still, I would like to avoid the mixing then, or the previous decision needs to be reconsidered in my opinion. Best Regards, Laszlo Papp
Re: playground/games/picmi moved to KDE Review
> With the latest push to master, all of these points should be addressed > (except the icon, I'm still looking). Does the game work on Windows? Best Regards, Laszlo Papp
Re: playground/games/picmi moved to KDE Review
> Does the game work on Windows?
I have just put some effort into testing this, but it is quite broken.
I would like to see improvements in this front since Windows is an
important platform for Qt and KDE. I am here for helping with that, if
needed.
The issues so far (until I found enough to not bother with finding
more as of now) in kdegames (dependency):
1) FindSndFile.cmake is broken. It does not find the installed sndfile
on my system which it should. I would suggest using the one we used in
alure, gluon, QtOpenAL back then and so forth.
2)
http://websvn.kde.org/trunk/KDE/kdegames/libkdegames/CMakeLists.txt?view=markup
-> file(RELATIVE_PATH CONF_REL_INCLUDE_DIR
"${DATA_INSTALL_DIR}/cmake/modules"
"${INCLUDE_INSTALL_DIR}")
This is not going to work since you need to use absolute paths, if I
am not mistaken. ${CMAKE_INSTALL_PREFIX} will help you out about that.
3)
http://websvn.kde.org/trunk/KDE/kdegames/libkdegames/audio/kgsound-openal.cpp?view=markup:
#include //TODO: use Phonon instead of libsndfile for
decoding -> You should use "sndfile.h"
4) You use "class Private" here:
http://websvn.kde.org/trunk/KDE/kdegames/libkdegames/audio/kgsound.h?view=markup
and then "struct Foobar::Private" here:
http://websvn.kde.org/trunk/KDE/kdegames/libkdegames/audio/kgsound-openal.cpp?view=markup
... after this point I gave up for now. Please fix the issues in
kdegames along with the responsible person(s), and I will make check
further checks. The game, and libkdegames has not clearly been tested
properly with openal and sndfile. That may also be due to the fact,
the FindSndFile.cmake is broken.
Unfortunately, phonon master also had issues, so we just recommend
using the last phonon stable release in certain cases.
Let me know, if you need help with all these. I can also commit the
fixes myself, if it is accepted by whoever the maintainer is.
Best Regards,
Laszlo Papp
Re: playground/games/picmi moved to KDE Review
> I'd like to clarify that all of the points mentioned in this mail > concern libkdegames (and compilation thereof on Windows) and not picmi > in particular, therefore I'm forwarding this to kde-games-devel. Just to clarify this: the kdegames stack is broken on Windows, and I have not continued the investigation about picmi until that is fixed. I would not like to see something integrated where the whole stack is broken on Windows from the ground up (sorry for sounding blunt but Windows should not really be considered as something unimportnat for KDE in my opinion). It is not just a runtime issue, but does not even compile ... I have pushed the fixes to trunk as I mentioned on the kde-games-devel mailing list. Feel free to back port the build fixes to 4.9 for instance. I do not have time for going through the policies for that to do myself. About picmi: 1) The makefile is a non-crossplatform specific file in the project root. I do not see much value in that file to be honest since it is practically a file to avoid a simple alias? I would like to get that either removed (my preference) or make cross-platform. NMake or preferrably Jom is used on Windows, but you would need to sort out the Mac compiler there and the like. I do not think it is worth it in comparison with the additional maintainance. 2) find_package(LibKDEGames REQUIRED) -> Broken on Windows. I have made a local alering to KDEGames, but I am unsure if that is the real fix. My arch box seems to install LibKDEGames.cmake, so probably not. Please unbreak this. 3) Do not use gcc specific compilation options, like /extra please. I do not see the real need for that, but if you desperately need that, use conditions... 4) C:\Projects\picmi\src/settings.h(30) : fatal error C1083: Cannot open include file: 'kgamedifficulty.h': No such file or directory -> Something is wrong around the private libkdegames topic. This is the point where I have given up the further investigation for now. I will continue the help once you fix these essential build issues. :-) Best Regards, Laszlo Papp
Re: playground/games/picmi moved to KDE Review
> There was never a requirement for software that wants to be part of KDE to > work on Windows, and I'd like to keep this as it is. Perhaps, but I can still raise my personal opinion, just as you can. Although, it is a bit more here than "does not work". It does even compile. :-) I do think a minimal effort could be taken, especially when people are keen on helping with testing and even fixing like in this case. Perhaps, if some people do not have Windows access (due to the fact, it costs money, etc), they could have an option for remote usage, and run at least a build check. Other option is a build server perhaps with Jenkins? It just makes the KDE Windows' team life hard to get all the application running. Unfortunately, there is a decent manpower lack over there, and if each developer can help a little bit, even just about their applications, the situation looks much better. Best Regards, Laszlo Papp
Re: playground/games/picmi moved to KDE Review
> Perhaps, but I can still raise my personal opinion, just as you can. > Although, it is a bit more here than "does not work". It does even > compile. :-) Err... silly typo: it does /not/ even compile. Best Regards, Laszlo Papp
Re: playground/games/picmi moved to KDE Review
>> Although, it is a bit more here than "does not work". It does even >> compile. :-) > > The usual reason is that the developer doesn't even have a MS compiler or > Windows. And nobody can be forced to have one. ;) You could theoritically say the same for Linux (or certain softwares, versions etc). I have just read my mail again, and I have written "I would not like to ..." and "I am here for helping with the issues". Sure, it can be integrated, but if it is integrated now without the fixes, it is likely there will not be much attention later, and now I am here for help. Unsure about later. :) > It is not a problem you bring up the issues, but that shouldn't block the app > being moved from kdereview to another module (if it is accepted by the module > maintainer, there are not other problems with it). Sure. I am suggesting as of now. :) Jakob can take my suggestions to make this up and running on Windows with not so much effort. > Yes, that would help, but somebody has to do the work, do the setup, buy the > MS tools, etc. Sincerely, I don't see th I believe, the last part of the sentence is missing, but there are already windows servers. Unsure what you mean by ms tools, but in an ideal world, even mingw should work. In fact, even when you cross-compile from Linux. :-) A build server, like Jenkins, with Windows target could be a lot of help. I am sure some of us could also provide remote access for build checks. I do not see this a big problem, but yes the flow needs to proceed. However, as for this special case, I am here for helping and patching, if I can create one with my skills. > I keep telling to Patrick to just use Linux, but he is hard headed, so he has > to leave with the pain and fix our mess. ;) I said small team, but it is not that small. There are others you need to "brainwash". ;) I can just speak up about the Download numbers Patrick and Patrick mentioned during the aKademy talk, and it is not an insignificant number. Meaning, many people use KDE on Windows, already. Best Regards, Laszlo Papp
Re: playground/games/picmi moved to KDE Review
> Sure, but you have to admit, that there is a subtle difference between Linux > different versions and Linux vs. Windows. I am just saying that, it can happen someone is unable to have an access to Linux for some reasons. This is for instance the situation at my company without finding workarounds. :-) > The problem is that if the developer doesn't have access to the tools, all > fixes will be done blindly. Doable, but not that easy and more error-prone. Like I said, I can help with this special case, so it is not going to be blind. :-) > Mingw doesn't catch compiler msvc errors, the two compilers are different > enough that having access to one doesn't guarntee the second will work. Sure. I would personally be happy, if a person investigate about one of them, already, according to the person's liking or not liking, but I can understand the unwillingness as well at times. > Re. tools I was thinking about the server itself (MS license), compiler tools > (if you want anything more then the free compiler) and the rest. I believe, most of us using msvc, use the free express edition. I have not needed more so far while working on Qt or/and KDE Windows. Best Regards, Laszlo Papp
Re: playground/games/picmi moved to KDE Review
Some of the content may be familiar from irc, but just for the record. > This is basically a convenience makefile and is not part of the actual > cmake build system (= it can be ignored). Following SaroEngels' > suggestion, it has been renamed to GNUmakefile - this way it should only > be executed by GNU make. Yes. It is a bit inconsistent with the rest, but I do not mind, if you need this to aid your work. You are the maintainer after all, so it must be convenient for you. :) > I mentioned this in my initial mail. find_package(LibKDEGames) does not > work for trunk (find_package(KDEGames) does). > > Does everyone here use trunk? If yes, I will change this in the > repository - let me know. 1) The current double check is in wrong order unless you have fixed this after my mentioning. I think the fallback should be the old, and the first citizen should be changed "cmake API". 2) I would suggest meaningful warning messages, if the old version is found for some reasons. That might be unintentional from the person trying to build. >> 3) Do not use gcc specific compilation options, like /extra please. I >> do not see the real need for that, but if you desperately need that, >> use conditions... > > Thanks, these are now conditionally added (if (CMAKE_COMPILER_IS_GNUCXX)). It is fine as well as the fix for the first point. Even if the majority in KDE does not use this too much, you are the maintainer, you decide about such details. :-) > So it seems like cmake is unable to find kgdifficulty.h in your > installation? As discussed in #kde-windows, I will be around later > tonight to follow up on this. Unsure, why this issue disappeared right now when I have tried to run, but I cannot reproduce this issue anymore after the fresh git clone and pull operations for kdegames and picmi. I have just tried to run the binary from the command line, but a crash happened for some reasons. Perhaps, the resource is not found. KERNELBASE.dll!RaiseException() [[unknown] @ -1] at 0x75f7b727 MSVCR100.dll!CxxThrowException() [[unknown] @ -1] at 0x64617819 picmi.exe!Renderer::loadResources() [c:\projects\picmi\src\gui\renderer.cpp @ 73] at 0xec028f picmi.exe!GetCommandLineW() [[unknown] @ -1] at 0xed233d picmi.exe!Renderer::Renderer() [c:\projects\picmi\src\gui\renderer.cpp @ 46] at 0xec0566 picmi.exe!Renderer::instance() [c:\projects\picmi\src\gui\renderer.cpp @ 161] at 0xec0865 picmi.exe!Scene::init() [c:\projects\picmi\src\gui\scene.cpp @ 130] at 0xebb7fe picmi.exe!Scene::Scene() [c:\projects\picmi\src\gui\scene.cpp @ 27] at 0xebbbd6 picmi.exe!View::createScene() [c:\projects\picmi\src\gui\view.cpp @ 47] at 0xeb6bca picmi.exe!MainWindow::startGame() [c:\projects\picmi\src\gui\mainwindow.cpp @ 228] at 0xeb564d picmi.exe!MainWindow::startRandomGame() [c:\projects\picmi\src\gui\mainwindow.cpp @ 199] at 0xeb59f8 picmi.exe!MainWindow::MainWindow() [c:\projects\picmi\src\gui\mainwindow.cpp @ 58] at 0xeb64da picmi.exe!main() [c:\projects\picmi\src\main.cpp @ 43] at 0xeb1a65 picmi.exe!WinMain() [c:\kderoot\git\qt-4.8.2\src\winmain\qtmain_win.cpp @ 135] at 0xeb1125 picmi.exe!__tmainCRTStartup() [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 547] at 0xecfc90 kernel32.dll!BaseThreadInitThunk() [[unknown] @ -1] at 0x75fd3677 ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77649d72 ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77649d45 Thank you for your collaboration, again! Best Regards, Laszlo Papp
Re: playground/games/picmi moved to KDE Review
> KERNELBASE.dll!RaiseException() [[unknown] @ -1] at 0x75f7b727 > MSVCR100.dll!CxxThrowException() [[unknown] @ -1] at 0x64617819 > picmi.exe!Renderer::loadResources() > [c:\projects\picmi\src\gui\renderer.cpp @ 73] at 0xec028f > picmi.exe!GetCommandLineW() [[unknown] @ -1] at 0xed233d > picmi.exe!Renderer::Renderer() [c:\projects\picmi\src\gui\renderer.cpp > @ 46] at 0xec0566 > picmi.exe!Renderer::instance() [c:\projects\picmi\src\gui\renderer.cpp [snip] OK, this can be fixed by a proper cmake run, like "cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_ PREFIX=%KDEROOT% -DCMAKE_PREFIX_PATH=%KDEROOT% ../". Best Regards, Laszlo Papp
Re: playground/games/picmi moved to KDE Review
> Are there any objections or requested changes before Picmi can proceed > to kdegames? Yes, you have ignored my comments for more than a week with a cross-platform issue, and not just on Windows. Here is what I wrote earlier: 1) The current double check is in wrong order unless you have fixed this after my mentioning. I think the fallback should be the old, and the first citizen should be changed "cmake API". 2) I would suggest meaningful warning messages, if the old version is found for some reasons. That might be unintentional from the person trying to build. Best Regards, Laszlo Papp
Re: playground/games/picmi moved to KDE Review
> Could somebody please point out the next steps to take? As for information about the procedure, you can find all the necessary information here: http://techbase.kde.org/Policies/Application_Lifecycle#Stage_2:_Stable Best Regards, Laszlo Papp
Re: playground/games/picmi moved to KDE Review
> Support for the old libkdegames will be removed soon, making both of the > points below nonissues. I already stated as much in both my original > mail and on 07/25. It *should* work logically and correctly until a new refactor, thus I cannot buy this argument, I am afraid. This is a few-liner change to make this operation right... Best Regards, Laszlo Papp
Re: playground/games/picmi moved to KDE Review
> It *should* work logically and correctly until a new refactor, thus I > cannot buy this argument, I am afraid. This is a few-liner change to > make this operation right... Just to clarify, this statement means that you either support the old kde games library properly, or you do not support at all. Best Regards, Laszlo Papp
Re: QtScript considered dangerous
> > Yeah, I think something along the lines of "the following weeks". Like in > 2-4 > weeks or so as far as I heard. > Indeed, here is the proof: http://lists.qt-project.org/pipermail/development/2012-August/005571.html Laszlo
Re: Review Request: Remove redundant SSL certificate hostname mismatch check in KIO::TCPSlaveBase
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105976/#review18258 --- Where can I see the diff? - Laszlo Papp On Aug. 28, 2012, 11:35 p.m., Dawit Alemayehu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105976/ > --- > > (Updated Aug. 28, 2012, 11:35 p.m.) > > > Review request for kdelibs. > > > Description > --- > > The attached patch removes the code that performs SSL certificate host name > mismatch check in TCPSlaveBase. Since we do not connect to servers using IP > address anymore, it is simply redundant to perform checks that are already > done in Qt's SSL classes. > > > Diffs > - > > > Diff: http://git.reviewboard.kde.org/r/105976/diff/ > > > Testing > --- > > > Thanks, > > Dawit Alemayehu > >
Review Request: Unbreak the build on Windows as there is no "uint" type recognized
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106539/ --- Review request for kdelibs and David Faure. Description --- There may be another approaches for fixing this build issue I have not yet discovered, hence putting for review. Diffs - kjs/jsonstringify.cpp f816e98 Diff: http://git.reviewboard.kde.org/r/106539/diff/ Testing --- Build test Thanks, Laszlo Papp
Re: Review Request: Unbreak the build on Windows as there is no "uint" type recognized
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106539/#review19349 --- kjs/jsonstringify.cpp <http://git.reviewboard.kde.org/r/106539/#comment15300> We could also include "WinDef.h", but that would need ifdef'ing or finding a separate place where there is already a windows branching and alos appropriate for this. Since it only affects one line here as it seems so far, probably it is just better not to spare few characters here, but I do not mind either way. :-) - Laszlo Papp On Sept. 23, 2012, 8 a.m., Laszlo Papp wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106539/ > --- > > (Updated Sept. 23, 2012, 8 a.m.) > > > Review request for kdelibs and David Faure. > > > Description > --- > > There may be another approaches for fixing this build issue I have not yet > discovered, hence putting for review. > > > Diffs > - > > kjs/jsonstringify.cpp f816e98 > > Diff: http://git.reviewboard.kde.org/r/106539/diff/ > > > Testing > --- > > Build test > > > Thanks, > > Laszlo Papp > >
Re: Requiring cmake 2.8.9 for kdelibs 4.10 ?
> Objections ? None from Harmattan side either. I have already updated [1] the cmake version to 2.8.9 previously due to the frameworks experiment. :-) Thank you for bringing this topic up. Laszlo http://lpapp.blogspot.ie/2012/09/randa-kde-frameworks-build-experiment.html
Re: RFC: Enabling -DKDE4_BUILD_TESTS=ON by default
> +1 for always building unit tests! > Actually I've always been unsure why packagers don't run unit tests... > Maybe this would help. Because the tests are broken in certain environments (just like last time on Harmattan with the frameworks branch) and due to the lack of time on the packagers' side to fix upstream bugs, they choose the simpler way as a temporary workaround. Therefore, they can proceed with the project, and do other things further on. +1 from me as well for sure! :-) Laszlo
Re: RFC: Enabling -DKDE4_BUILD_TESTS=ON by default
> Because the tests are broken in certain environments (just like last > time on Harmattan with the frameworks branch) and due to the lack of > time on the packagers' side to fix upstream bugs, they choose the > simpler way as a temporary workaround. Therefore, they can proceed > with the project, and do other things further on. I have just checked few packagings, and perhaps if they do not have issues with the tests, the communication was not good enough between the developers and packagers. This change may help with that, but it should also be communicated with the packagers to get them aware about the change. Laszlo
Re: kde-runtime module master and KDE/4.9 branches
I think David took the responsibility for the merge: http://lists.kde.org/?l=kde-release-team&m=134510779413123&w=4 Laszlo On Tue, Oct 9, 2012 at 3:36 PM, Aleix Pol wrote: > Hi, > I'm sending this e-mail because I was experiencing some bug with the > ScrollBar and I thought about fixing it. Then I decided to commit it > in KDE/4.9 because it's a bugfix and I realised it's already in 4.9, > it's just not in master. > > My natural reaction was to see if we could merge KDE/4.9 to master, > that was the git output [1]. Besides the normal .desktop files > conflicts there were a lot of .cpp and .qml changes that conflicted > (mostly Plasma Components and some Nepomuk). > > So, should I look into merging those? Maybe there are more things > fixed in 4.9 that aren't in master... > Should we make sure this won't happen again? If so, how? > > Aleix > > [1] http://paste.kde.org/565196/
Re: kde-runtime module master and KDE/4.9 branches
On Tue, Oct 9, 2012 at 7:54 PM, Laszlo Papp wrote: > I think David took the responsibility for the merge: > http://lists.kde.org/?l=kde-release-team&m=134510779413123&w=4 Oh, that was mentioned for kdelibs, and not kde-runtime. Can someone do that for kde-runtime as well? Laszlo
Re: kde-runtime module master and KDE/4.9 branches
> Hm, as kde-runtime is not frozen in master, whoever does fixes in 4.9 should > merge them to master. Unfortunately, there may always be changes missing. Unsure how much it can be automated, but I have the impression we do not exactly know until a person is responsible for making sure. Laszlo
Re: kde-runtime module master and KDE/4.9 branches
> If you merge stable into master you cannot miss changes. Sure, but what I was referring to, is more than that. People should do that for their changes, but you cannot expect there will be no mistakes at all in the procedure. Someone making sure about this on top of the utilities that can just be introduced, would be a great addition as well. Currently David is similar contribution in kdelibs, and I am happy about that. I do not think it is only tightened to freeze. Perhaps if a few people get involved into this for separate subcomponents, then it is not that a big job for each. There were also people trying to make sure relevant changes ended up in Qt 4.8 and Qt5 as well. These were mostly maintainers and approvers I found, but basically anybody could have said. Although that is somewhat a simpler situation because each patch is reviewed, so more eyes have to miss this procedure not to happen. That said, I support any mechanism that helps with missing those for the authors as well. Laszlo
Re: kde-runtime module master and KDE/4.9 branches
> I think the problem is we don't know the commit policy for kde-runtime. Is it: > > fix-master-and-backport: fix in master, cherry-pick to KDE/4.x > > -- or -- > > fix-stable-and-merge: fix in KDE/4.x, merge KDE/4.x in master I personally prefer the former as in contributors should make sure if it is fixed in master, and if not, fix there, otherwise cherry-pick. That way the preference would be to focus on having the bug fixes in the upcoming releases rather than in stable releases. Having those fixes in stable releases may mean that they are not available for a (sometimes long) while in the upcoming releases in case of missed merges. > - modify the commit-hook for KDE/4.x branches to show a message recommending > merging changes to master (optionally pointing to instructions on the wiki for > more info) > - set up a nag system to send an email/post on irc if there are unmerged > commits and last merge-to-master is older than 2 or 3 days. I recall we had nagging emails previously about license issues and so forth. To be consistent with the handling of those, I would prefer the latter personally. Laszlo
Re: kde-runtime module master and KDE/4.9 branches
> Problem with this approach is the code you backport is usually a lot less > tested as you made all your developments on master. In the svn days I even > remember people telling me they were blind-backporting to stable because it > was "too much work to test the backported code". One could say the opposite as well for the upcoming versions from master, so it depends on the point of view what you focus for. :-) > It also makes it difficult to know if a fix has already been backported > because > it has different commit-ids depending on the branch it has been committed to. The commit id is not the only one to match. You can also match commits this way: " Backport bugfixes If you commit bugfixes, consider porting the fixes to other branches. Use the same comment for both the original fix and the backport, that way it is easy to see which fixes have been backported already. " from: http://techbase.kde.org/Policies/SVN_Commit_Policy So as for cherry-pick, this would be a clear identifier as far as I can tell. The problem I see with that approach is if a bugfix is forgotten to be cherry-picked, it may be hard later to recognize which commits need to be cherry-picked from master if someone would like to volunteer with that if there are no clear identifiers for that in the commit message. For instance a bugfix which is not made for a bugzilla entry. > I lke this rule from gitworklows (man gitworklows or [1]): > > "Always commit your fixes to the oldest supported branch that require them. > Then (periodically) merge the integration branches upwards into each other." Okay for me if it is demanded by our policy it has to happen, and someone volunteers for making sure it does happen. Otherwise, the upcoming releases from master may lack the bugfixes potentially. > If we have an agreement to use fix-stable-and-merge, I'd be happy to get > started on writing a script to check for missing merges. Great. :-) > Actually something > like that: > > git log --pretty="%an <%ae>" origin/master..origin/KDE/4.9 \ >| grep -v scri...@kde.org | sort | uniq > > Could be a good start. It lists all authors of commits which are in KDE/4.9 > but not in master (and, there is my name in there :/). Of course it cannot > tell if a commit is actually a cherry-picked version of another commit in > master, so there are a few false positives. Why not? I think even if the commit message is poor like "build fix" and it is the same for more commits, you still have the chance to make sure they are the same in master and the given release branch according to further information like the diff for instance. In case of no ambiguous commit messages, it is less problematic. Laszlo
Re: Dependency Freeze for 4.10 in two weeks
Ok from Harmattan side as I do not work on it anymore. I am not aware of anybody doing so either. L. On 10/21/12, David Faure wrote: > On Thursday 18 October 2012 22:32:12 Albert Astals Cid wrote: >> Dependency freeze for 4.10 releases is in two weeks (November 1st), >> please >> be sure you update all the needed dependencies before that date. >> >> Notorious dependencies we might want to discuss: >> * kdelibs depends on Qt 4.7 > > Is anyone still testing kdelibs -- or the rest of KDE SC master -- with > Qt-4.7? > > Qt-4.8 was released quite a long time ago, I would think we could raise the > > dependency. > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE, in particular KDE Frameworks 5 > >
Re: Cleaning house: KDE Review
> I think libs would be a much better place then. +1 Laszlo
Re: KDE Continuous Integration (build.kde.org) outage
https://codereview.qt-project.org/#change,39912 On Sun, Nov 25, 2012 at 11:54 AM, Ben Cooksley wrote: > Hi all, > > Just a quick notice that due to Qt breaking their ABI it is now > necessary for build.kde.org (Jenkins) to initiate a rebuild of all > binaries. > This will take a long time to complete unfortunately, I suspect ~24 - 48 > hours. > > An excerpt of the failure log is below, prior to the rebuild. > /srv/jenkins/install/kde/kdelibs/KDE/4.10/lib64/libkio.so.5: undefined > reference to `QFutureInterfaceBase::refT() const' > /srv/jenkins/install/kde/kdelibs/KDE/4.10/lib64/libkio.so.5: undefined > reference to `QFutureInterfaceBase::derefT() const' > > I consider this extremely irritating. Should the Qt developers wish to > correct this transgression in their ABI, I would appreciate it if both > this list and myself were informed a minimum of 48 hours in advance of > the commit entering any form of Qt integration system. > > Regards, > Ben Cooksley > KDE Sysadmin >
Re: KDE Continuous Integration (build.kde.org) outage
> > As it turns out, the correction in this case was the cause of this > breakage. Somehow the original breakage (which was built and deployed > by build.kde.org 3 builds ago) did not have any impact upon the > system, yet the revert of the breakage caused this. > Because as the Gerrit text wrote: it removed the symbols added which is not allowed in a patch release. There should be no problem for people using released Qt as 4.8.3 was okay, and will the 4.8.4 release be. Laszlo
Re: Review of kdev-python for move to extragear
On Thu, Dec 6, 2012 at 8:25 PM, Sven Brauch wrote: > Hi! > > For quite exactly two years I have been working on integrating the > Python scripting language into KDevelop. Recently this project, called > kdev-python, has seen its first stable release (called 1.4 in order to > match kdevplatform version numbers). The release seems to be > successful so far, no crashes or grave bugs have surfaced yet. Of > course there is a lot of nice-to-have functionality missing, but > especially for developing PyQt / PyKDE applications, kdev-python > provides a very usable development tool already. I intend to further > maintain and improve the program in the future. > + PySide, I guess. :-) Out of the curiosity: how much python3 is available? Thank you for your work. Laszlo
Re: Review of kdev-python for move to extragear
> > Out of the curiosity: how much python3 is available? Thank you for your > work. > python3 _support_
Re: Review of kdev-python for move to extragear
On Fri, Dec 7, 2012 at 12:09 PM, Milian Wolff wrote: > On Friday 07 December 2012 06:01:19 Laszlo Papp wrote: > > > Out of the curiosity: how much python3 is available? Thank you for your > > > work. > > > > python3 _support_ > > please read http://scummos.blogspot.de/2012/11/kdev-python-14-stable- > released.html > > 1.5 will get python3 support Thank you. Laszlo
Re: Review Request: Keep clickmessage text visible when empty and focused
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107678/#review23366 --- It did not get a ship it back then for the plasma components, but I would not like to block the rediscussion, just saying what happened earlier. :-) https://git.reviewboard.kde.org/r/104895/ - Laszlo Papp On Dec. 12, 2012, 5:10 p.m., Aurélien Gâteau wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107678/ > --- > > (Updated Dec. 12, 2012, 5:10 p.m.) > > > Review request for kdelibs. > > > Description > --- > > This patch changes the way KLineEdit and KTextEdit handle the clickMessage > property. The message remains visible when the widget is focused, as long as > no text has been typed in. This is useful when the widget is focused by > default, and also gives another opportunity to the user to read the message > before typing, removing the need for workarounds like clicking in another > text entry to bring back the clickMessage. > > I filed a similar review-request for Plasma components: > https://git.reviewboard.kde.org/r/107600/ > > > Diffs > - > > kdeui/widgets/klineedit.cpp d96c1c4 > kdeui/widgets/ktextedit.cpp dfaf5b8 > > Diff: http://git.reviewboard.kde.org/r/107678/diff/ > > > Testing > --- > > Tested KLineEdit in Dolphin "add place" dialog and KDevelop. Tested KTextEdit > with Gwenview "description" image field. > > > Thanks, > > Aurélien Gâteau > >
Re: FOSDEM
Pau reminds me: Anyone a KDE Mobile talk for the embedded room? I already have a different proposal idea, but it would be nice to see the KDE presence there, too! On Wed, Dec 12, 2012 at 12:06 PM, Pau Garcia i Quiles wrote: > Guys, > > No frameworks talk at FOSDEM CrossDesktop DevRoom? Really? > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) >
Re: Review Request: Keep clickmessage text visible when empty and focused
> On Dec. 12, 2012, 6:43 p.m., Laszlo Papp wrote: > > It did not get a ship it back then for the plasma components, but I would > > not like to block the rediscussion, just saying what happened earlier. :-) > > > > https://git.reviewboard.kde.org/r/104895/ > > David Edmundson wrote: > One of the key arguments people had then was because it would have led to > seriously inconsistent behaviour between plasma components and the desktop. > > Aurelien is fixing that by also proposing to patch KDE libs, which turns > my personal opinion from a definite "no" to something I'm happy with. > At least, I do not see such a key argument personally in the previous review comments. As for me, it seems that certain people would prefer one way, and certain people would prefer the other way. So, it is a hard decision to take in my opinion. Certain projects do this way, and certain do not. It will stay inconsistent with the QLineEdit based applications for instance (I know one could bring different examples, too). I am not envy for the decision maker. :-) - Laszlo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107678/#review23366 --- On Dec. 12, 2012, 5:10 p.m., Aurélien Gâteau wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107678/ > --- > > (Updated Dec. 12, 2012, 5:10 p.m.) > > > Review request for kdelibs. > > > Description > --- > > This patch changes the way KLineEdit and KTextEdit handle the clickMessage > property. The message remains visible when the widget is focused, as long as > no text has been typed in. This is useful when the widget is focused by > default, and also gives another opportunity to the user to read the message > before typing, removing the need for workarounds like clicking in another > text entry to bring back the clickMessage. > > I filed a similar review-request for Plasma components: > https://git.reviewboard.kde.org/r/107600/ > > > Diffs > - > > kdeui/widgets/klineedit.cpp d96c1c4 > kdeui/widgets/ktextedit.cpp dfaf5b8 > > Diff: http://git.reviewboard.kde.org/r/107678/diff/ > > > Testing > --- > > Tested KLineEdit in Dolphin "add place" dialog and KDevelop. Tested KTextEdit > with Gwenview "description" image field. > > > Thanks, > > Aurélien Gâteau > >
Re: FOSDEM
On Wed, Dec 12, 2012 at 7:53 PM, Pau Garcia i Quiles wrote: > Laszlo, > > Aaron submitted a proposal for a Plasma Active talk: > > > https://lists.fosdem.org/pipermail/crossdesktop-devroom/2012-November/30.html > Aaron everywhere, great. ;-) I personally think that it would fit better into the embedded room because of the audience type, but that is just my personal opinion. > If the topic is different, more proposals cannot hurt. Specially if backed > with devices to show during the talk :-) > Perhaps a Qt/QNX (+ KDE plans) talk would also make sense even if we cannot back the presentation with KDE applications on the playbook, or devalpha phone as of now. Laszlo
Re: Review Request: Keep clickmessage text visible when empty and focused
> On Dec. 12, 2012, 6:43 p.m., Laszlo Papp wrote: > > It did not get a ship it back then for the plasma components, but I would > > not like to block the rediscussion, just saying what happened earlier. :-) > > > > https://git.reviewboard.kde.org/r/104895/ > > David Edmundson wrote: > One of the key arguments people had then was because it would have led to > seriously inconsistent behaviour between plasma components and the desktop. > > Aurelien is fixing that by also proposing to patch KDE libs, which turns > my personal opinion from a definite "no" to something I'm happy with. > > > Laszlo Papp wrote: > At least, I do not see such a key argument personally in the previous > review comments. As for me, it seems that certain people would prefer one > way, and certain people would prefer the other way. So, it is a hard decision > to take in my opinion. Certain projects do this way, and certain do not. > > It will stay inconsistent with the QLineEdit based applications for > instance (I know one could bring different examples, too). I am not envy for > the decision maker. :-) > > Aurélien Gâteau wrote: > I see more and more interfaces switching to keeping the placeholder when > the widget is focused. This behavior can now be found in: > - Firefox awesome bar > - Android input fields > - Facebook search and input fields > - Twitter login form (with a nice twist: opacity of placeholder reduces > when focused) > - Deezer search field > - Google+ input field > - Wikipedia search field > - forum.kde.org search field > > For the record, I also plan to file a patch against Qt to change the > behavior of QLineEdit. I would personally suggest you to propose this against Qt first, and see the reaction from Marc, Gunnar et al, anyone relevant. We are not in a hurry after all with this as we have been using the state of affair for a long time. ;-) - Laszlo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107678/#review23366 --- On Dec. 12, 2012, 5:10 p.m., Aurélien Gâteau wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107678/ > --- > > (Updated Dec. 12, 2012, 5:10 p.m.) > > > Review request for kdelibs. > > > Description > --- > > This patch changes the way KLineEdit and KTextEdit handle the clickMessage > property. The message remains visible when the widget is focused, as long as > no text has been typed in. This is useful when the widget is focused by > default, and also gives another opportunity to the user to read the message > before typing, removing the need for workarounds like clicking in another > text entry to bring back the clickMessage. > > I filed a similar review-request for Plasma components: > https://git.reviewboard.kde.org/r/107600/ > > > Diffs > - > > kdeui/widgets/klineedit.cpp d96c1c4 > kdeui/widgets/ktextedit.cpp dfaf5b8 > > Diff: http://git.reviewboard.kde.org/r/107678/diff/ > > > Testing > --- > > Tested KLineEdit in Dolphin "add place" dialog and KDevelop. Tested KTextEdit > with Gwenview "description" image field. > > > Thanks, > > Aurélien Gâteau > >
Re: Review Request: Fix generating kconfig skeletons with UrlList fields that have a default value
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107716/#review23516 --- Ship it! Ship It! - Laszlo Papp On Dec. 14, 2012, 1:17 p.m., Aleix Pol Gonzalez wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107716/ > --- > > (Updated Dec. 14, 2012, 1:17 p.m.) > > > Review request for kdelibs. > > > Description > --- > > This patch changes the generated code so that if a property is "UrlList" in > the kcfg file, the variable that will receive it when generating the skeleton > is a KUrl::List instead a QStringList. This solves the following compiling > error: > > aleix@kubuntu:~/projects/muon/build$ make > [ 0%] Built target muonprivate_automoc > [ 0%] Building CXX object > libmuon/CMakeFiles/muonprivate.dir/MuonDataSources.o > In file included from /usr/include/kcoreconfigskeleton.h:28:0, > from /usr/include/kconfigskeleton.h:28, > from > /home/aleix/projects/muon/build/libmuon/MuonDataSources.h:8, > from > /home/aleix/projects/muon/build/libmuon/MuonDataSources.cpp:4: > /usr/include/kurl.h: In constructor ‘MuonDataSources::MuonDataSources()’: > /usr/include/kurl.h:1146:3: error: ‘KUrl::operator QString() const’ is private > /home/aleix/projects/muon/build/libmuon/MuonDataSources.cpp:38:105: error: > within this context > > > Diffs > - > > kdecore/kconfig_compiler/kconfig_compiler.cpp 4203d30 > > Diff: http://git.reviewboard.kde.org/r/107716/diff/ > > > Testing > --- > > > Thanks, > > Aleix Pol Gonzalez > >
Re: Review Request: Fix icon generation and installation on OS X
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107752/#review23532 --- cmake/modules/KDE4Macros.cmake <http://git.reviewboard.kde.org/r/107752/#comment18079> Wouldn't it be nicer to write a loop for this with the icon resolutions? - Laszlo Papp On Dec. 16, 2012, 7:26 a.m., Yue Liu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107752/ > --- > > (Updated Dec. 16, 2012, 7:26 a.m.) > > > Review request for kdelibs. > > > Description > --- > > There are two issues when using kde4_add_app_icon on mac. a) apps using > kdeinit won't install icon files to thier app bundles, b) mac app icon > generating method is outdated and does not support retina resolution. > > The patch changed kde4_add_kdeinit_executable and kde4_add_app_icon to solve > these issues. > > > Diffs > - > > cmake/modules/KDE4Macros.cmake 0753879 > > Diff: http://git.reviewboard.kde.org/r/107752/diff/ > > > Testing > --- > > Works well on 4.9 branch. > Not sure if some changes breaks other platforms. > > > Thanks, > > Yue Liu > >
Re: Review Request: Fix icon generation and installation on OS X
> On Dec. 16, 2012, 1:47 p.m., Laszlo Papp wrote: > > cmake/modules/KDE4Macros.cmake, line 1293 > > <http://git.reviewboard.kde.org/r/107752/diff/1/?file=99544#file99544line1293> > > > > Wouldn't it be nicer to write a loop for this with the icon resolutions? > > Yue Liu wrote: > osx icon only uses some specific resolution, 22x22 and 48x48 are not used. > > Yue Liu wrote: > and for some resolutions one icon is needed, for some two icons are > needed (like 16x16@2x and 32x32, both are 32x32) Yes, so? You have 2-3 factors, but most of the code is the same for all. In other words, that is what functions exist for with parameters. - Laszlo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107752/#review23532 --- On Dec. 16, 2012, 7:26 a.m., Yue Liu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107752/ > --- > > (Updated Dec. 16, 2012, 7:26 a.m.) > > > Review request for kdelibs. > > > Description > --- > > There are two issues when using kde4_add_app_icon on mac. a) apps using > kdeinit won't install icon files to thier app bundles, b) mac app icon > generating method is outdated and does not support retina resolution. > > The patch changed kde4_add_kdeinit_executable and kde4_add_app_icon to solve > these issues. > > > Diffs > - > > cmake/modules/KDE4Macros.cmake 0753879 > > Diff: http://git.reviewboard.kde.org/r/107752/diff/ > > > Testing > --- > > Works well on 4.9 branch. > Not sure if some changes breaks other platforms. > > > Thanks, > > Yue Liu > >
Re: [Kde-pim] Boost vs cmake 2.8.8 vs kdepimlibs master
On Sun, Dec 16, 2012 at 11:07 PM, Albert Astals Cid wrote: > El Dilluns, 17 de desembre de 2012, a les 00:03:38, Luigi Toscano va > escriure: > > Albert Astals Cid wrote: > > > El Diumenge, 16 de desembre de 2012, a les 23:53:23, Antonis > Tsiapaliokas > > > va> > > > escriure: > > >> Hello, > > >> > > >>> Attached, can somebody give it a try ? > > >>> > > >>> Alex > > >> > > >> I have test the attached patch with 2.8.8 cmake and it doesn't work. > > >> With the 2.8.9 cmake, the issues is solved, without the attached patch > > >> needed. > > > > > > So let's go for the cmake increase? > > > > > > Anyone against it? (I will need an answer before RC1 tag on tuesday > night) > I am all for it. On a side note, I have never understood the objection against 2.8.9 before as that is what was also required for framework. Hence, it would somewhat lower the barrier for the framework contribution, too. IIRC, one of the main issues was the debian way, but it does not seem the case anymore: http://packages.debian.org/search?searchon=names&keywords=cmake Laszlo
Re: [Kde-pim] Boost vs cmake 2.8.8 vs kdepimlibs master
On Mon, Dec 17, 2012 at 4:42 PM, Alexander Neundorf wrote: > Not really. For the frameworks branch the most current cmake is required, > which is 2.8.10.1 currently. > We will stay there with the most current until we get somewhat stable. > I see. My post seems to date back then when it was discussed. Apparently, I have not contributed to frameworks to even notice it, at least not the way through that branch. My understanding got outdated. Thank you for the information. :) Laszlo PS.: If only the entry barrier was not so high for even a basic tool like cmake. It is certainly not a problem for me as an arch user, but I can understand this a -1 for many. This is of course off-topic here.
Re: Review Request: Fix icon generation and installation on OS X
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107752/#review23767 --- Great, thank you for your care! One suggestion to this, and I think then it is fine from that point of view: you could write a foreach on top of the "copy_icons" macro, and avoid the same function name in each line. - Laszlo Papp On Dec. 20, 2012, 6:10 p.m., Yue Liu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107752/ > --- > > (Updated Dec. 20, 2012, 6:10 p.m.) > > > Review request for kdelibs. > > > Description > --- > > There are two issues when using kde4_add_app_icon on mac. a) apps using > kdeinit won't install icon files to thier app bundles, b) mac app icon > generating method is outdated and does not support retina resolution. > > The patch changed kde4_add_kdeinit_executable and kde4_add_app_icon to solve > these issues. > > > Diffs > - > > cmake/modules/KDE4Macros.cmake 0753879 > > Diff: http://git.reviewboard.kde.org/r/107752/diff/ > > > Testing > --- > > Works well on 4.9 branch. > Not sure if some changes breaks other platforms. > > > Thanks, > > Yue Liu > >
Re: Review Request: Fix icon generation and installation on OS X
> On Dec. 20, 2012, 6:58 p.m., Laszlo Papp wrote: > > Great, thank you for your care! One suggestion to this, and I think then it > > is fine from that point of view: you could write a foreach on top of the > > "copy_icons" macro, and avoid the same function name in each line. > > Yue Liu wrote: > that doesn't save many characters but increased complexity since you have > to emulate a 2d array. You follow the 2D logic either way, but now it is done manually by copy/paste as many times as you need it which is currently ten times the same call. - Laszlo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107752/#review23767 --- On Dec. 20, 2012, 6:10 p.m., Yue Liu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107752/ > --- > > (Updated Dec. 20, 2012, 6:10 p.m.) > > > Review request for kdelibs. > > > Description > --- > > There are two issues when using kde4_add_app_icon on mac. a) apps using > kdeinit won't install icon files to thier app bundles, b) mac app icon > generating method is outdated and does not support retina resolution. > > The patch changed kde4_add_kdeinit_executable and kde4_add_app_icon to solve > these issues. > > > Diffs > - > > cmake/modules/KDE4Macros.cmake 0753879 > > Diff: http://git.reviewboard.kde.org/r/107752/diff/ > > > Testing > --- > > Works well on 4.9 branch. > Not sure if some changes breaks other platforms. > > > Thanks, > > Yue Liu > >
Re: Review Request: Fix icon generation and installation on OS X
> On Dec. 20, 2012, 6:58 p.m., Laszlo Papp wrote: > > Great, thank you for your care! One suggestion to this, and I think then it > > is fine from that point of view: you could write a foreach on top of the > > "copy_icons" macro, and avoid the same function name in each line. > > Yue Liu wrote: > that doesn't save many characters but increased complexity since you have > to emulate a 2d array. > > Laszlo Papp wrote: > You follow the 2D logic either way, but now it is done manually by > copy/paste as many times as you need it which is currently ten times the same > call. Also, the raw data is not separated from the code this way as much as it could be. - Laszlo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107752/#review23767 --- On Dec. 20, 2012, 6:10 p.m., Yue Liu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107752/ > --- > > (Updated Dec. 20, 2012, 6:10 p.m.) > > > Review request for kdelibs. > > > Description > --- > > There are two issues when using kde4_add_app_icon on mac. a) apps using > kdeinit won't install icon files to thier app bundles, b) mac app icon > generating method is outdated and does not support retina resolution. > > The patch changed kde4_add_kdeinit_executable and kde4_add_app_icon to solve > these issues. > > > Diffs > - > > cmake/modules/KDE4Macros.cmake 0753879 > > Diff: http://git.reviewboard.kde.org/r/107752/diff/ > > > Testing > --- > > Works well on 4.9 branch. > Not sure if some changes breaks other platforms. > > > Thanks, > > Yue Liu > >
Re: Review Request: Fix icon generation and installation on OS X
> On Dec. 20, 2012, 6:58 p.m., Laszlo Papp wrote: > > Great, thank you for your care! One suggestion to this, and I think then it > > is fine from that point of view: you could write a foreach on top of the > > "copy_icons" macro, and avoid the same function name in each line. > > Yue Liu wrote: > that doesn't save many characters but increased complexity since you have > to emulate a 2d array. > > Laszlo Papp wrote: > You follow the 2D logic either way, but now it is done manually by > copy/paste as many times as you need it which is currently ten times the same > call. > > Laszlo Papp wrote: > Also, the raw data is not separated from the code this way as much as it > could be. > > Yue Liu wrote: > sorry i don't get it what's the difference between call that ten times > directly and use a foreach loop to call that ten times. And those patterns > has to be in the code some where, what's the difference between put them in > an array and put them in several adjacent lines. You wanna separate data and code usually as much as possible while programming so that non-programmers can change raw data, and the code works just out of the box. This is a fairly essential principle, and surely, if you have a raw data storage variable, it is not mixed right in the middle. Don't you feel that 10 or potentially more later function calls are just plain wrong? - Laszlo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107752/#review23767 --- On Dec. 20, 2012, 6:10 p.m., Yue Liu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107752/ > --- > > (Updated Dec. 20, 2012, 6:10 p.m.) > > > Review request for kdelibs. > > > Description > --- > > There are two issues when using kde4_add_app_icon on mac. a) apps using > kdeinit won't install icon files to thier app bundles, b) mac app icon > generating method is outdated and does not support retina resolution. > > The patch changed kde4_add_kdeinit_executable and kde4_add_app_icon to solve > these issues. > > > Diffs > - > > cmake/modules/KDE4Macros.cmake 0753879 > > Diff: http://git.reviewboard.kde.org/r/107752/diff/ > > > Testing > --- > > Works well on 4.9 branch. > Not sure if some changes breaks other platforms. > > > Thanks, > > Yue Liu > >
