Review Request: Respect PYTHONDONTWRITEBYTECODE environmental variable
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107248/ --- Review request for kdelibs and Luca Beltrame. Description --- PythonMacros.cmake should not create/install byte-compiled Python modules (*.pyc) when PYTHONDONTWRITEBYTECODE environmental variable is set. See also: http://docs.python.org/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE Patch by Arfrever Frehtes Taifersar Arahesis. (This is like review #107228, but for KDE/4.10) This addresses bug 276151. http://bugs.kde.org/show_bug.cgi?id=276151 Diffs - cmake/modules/PythonMacros.cmake 785093e44b88a9be7d5d601fdd95f559af80e164 Diff: http://git.reviewboard.kde.org/r/107248/diff/ Testing --- Thanks, Michael Palimaka
Re: kdelibs git mess
On Thursday 08 November 2012 04:12:09 AM Christoph Feck wrote: Hi, my git foo is limited, but if I interpret http://ompldr.org/vZzZxaw correctly, then somehow master got merged into KDE/4.9 branch, meaning, for example, that Alex's commits to depend on cmake 2.8.8 are now in KDE/4.9 branch. I suggest to not to commit to kdelibs, until this is resolved. What about pulling from kdelibs KDE/4.10? is that ok?
Re: KDE-GTK-Config to KDEReview
Hi, thanks for the work you are putting in it, so far. Alle lunedì 5 novembre 2012, Aleix Pol ha scritto: Some months ago I pushed this project quite intensively so that right now we have a stable KCM for editing the GTK settings. This is being used already in some distributions, so I think it should be moved to extragear/base. So here I open the process for kde:kde-gtk-config to move in extragear. Any thoughts? Looking at the installed files, I see: - stuff in $prefix/bin: - reload_gtk_apps - gtk_preview - gtk3_preview those names are too generic for a global bin dir, what about giving them a kgc_ (kde gtk config) prefix and install them in libexec dir? KStandardDirs::findExe will find them anyway, and this way the global bin dir is not polluted - the icon $prefix/share/icons/hicolor/48x48/apps/gtkconfig.png had a too generic name for hicolor, I renamed it to kde-gtk-config.png -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Nepomuk Metadata Extractor moved to KDE Review
Hi Sebastian, 2012/11/8 Sebastian Kügler se...@kde.org: * As far as I can see, QWidget-related bits and service-related bits are split, so we're able to drop another ui on top of it for Plasma Active without much effort. (Even if the UI is a single knob =)) (Correct me if I missed a few points.) Yes this was the idea behind all of it. Each program that want's ti use this can decide to either reuse the available ui or just the the easy to use single parts. It is possible to use the plugin based structure for searching/ metadata fetching and than doe whatever someone wants with the data (a big QVariantMap) and also reuse the actual Nepomuk abstraction, that understands such a QVariantMap structure and allows to easily throw such data into Nepomuk. Conquirere actually uses this to integrate the search/select/save frontend better into the application. The same can easily be done by plasma or other apps that want to use Web Metadata search and/or Nepomuk integration based on key=value pairs * The browser integration is a very cool feature. It's nice that it supports Konqueror, Chrome and Mozilla/NPAPI on multiple platforms. I suppose it works with both Rekonq and Konqueror? The browser part is is bit experimental and should all of this go into KDE SC i will leave the browser part in extragear. The problem here is that in order to build the NPAPI part the kinda complicated firebreath development enviroment is necessary. reKonq support is currently not possible, because it does not have a plugin api available at the moment. * Is there any support for images planned? I think especially additional geolocation information could be really useful (also for other resource types, by the way. In Plasma Active the user can set a location, it would be cool if we could retrieve additional info through Nepomuk about the location, and thereby being able to relate it to other data, think Photos taken at current location =) Extraction geo information from images/files is the responsibility of the fileindexer Also all fotos from location lat/long isn't part of this. What could be added is a way to extend the fetcher to allow ot get information about a specific geo lat/long. Like lat/long is the City London or something like it. In order to save such additional information, we might need to add a new ontology. * One UI issue I see is that it installs a toplevel systemsettings module, while it should be under Desktop Search, so part of the Nepomuk KCM (which is also not great at all, UI-wise :/). I could imagine the primary knobs integration the service into the system a bit like this: [...] If we want to add it to our default install by 4.11 (which I support!), those should be fixed. I know the current solution is more temporary, but integration into the Nepomuk KCM isn't so easy either. Nonetheless Vishesh wanted to change this part anyway and some mails ago in this discussion there was the idea to combine the MetaData Extractor and Nepomuk. In this step we will come up with a better looking configuration KCM and this would also allow me to reuse the nepomuk System Tray parts to give information about the current progress. So unless this is a stopper to go extragear I would like to wait for this change for the possible 4.11 integration. * the binary name for metadataextractor should probably be nepomuk- metadataexractor or somesuch (matching other related binaries, easier to find if uses on the commandline). I think I will rename everything to Nepomuk WebFetcher and than also adapt the commandline program with it. * Is the scripting API documented or is it planned? Yes it is documented in the doxygen output. I will put the same information to techbase later on too. * You're shipping pre-generated Nepomuk headers it seems,[...] This is fixed, now all these files will be generated from cmake. And have a build switch, so this can be avoided after the first generation. * Coding Style spacing after if statements:if(bla) becomes if (bla spacing between arguments: foo(firstArg,secondArg) becomes foo(firstArg, secondArg) Whupps, I thought I've already changed QtCreator to respect kdelibs coding style. Seems I've missed these parts. I'll fix that. * Licensing Please consider using the KDE e.V. clause in your licenses, it makes the legal side a bit more future proof (it's clearer about the (L)GPL successor). You can find those on http://techbase.kde.org/Policies/Licensing_Policy From what I can see, licensing overall pretty much complies otherwise, so that's just a suggestion. I'll change this too. Cheers and thanks for the long input, Joerg
Re: kdelibs git mess
Christoph Feck wrote: Hi, my git foo is limited, but if I interpret http://ompldr.org/vZzZxaw correctly, then somehow master got merged into KDE/4.9 branch, meaning, for example, that Alex's commits to depend on cmake 2.8.8 are now in KDE/4.9 branch. I suggest to not to commit to kdelibs, until this is resolved. There is indeed breakage there. One way it could have happened is if Marco made a commit on his KDE/4.9 branch, and then accidentally did a 'git rebase origin/master' or similar and pushed the result. As far as I can see, this could happen for any branch at any time. There may be a way to add a server-side hook for it, which I've emailed sysadmin about. The fix should be for dfaure to reset the 4.9 branch to the v4.9.3 tag, cherry-pick the commits made after that and force push the result. He's going to do that now I think. Thanks, Steve.
Re: Review Request: Respect PYTHONDONTWRITEBYTECODE env variable
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107228/#review21641 --- This review has been submitted with commit 5a3cedacdb6485f7551090467cffb2cdf150b05a by Arfrever Frehtes Taifersar Arahesis to branch KDE/4.9. - Commit Hook On Nov. 6, 2012, 10:50 a.m., Andrea Scarpino wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107228/ --- (Updated Nov. 6, 2012, 10:50 a.m.) Review request for kdelibs. Description --- cmake/modules/PythonMacros.cmake defines PYTHON_INSTALL macro. This macro should not create/install byte-compiled Python modules (*.pyc) when PYTHONDONTWRITEBYTECODE environmental variable is set. See also: http://docs.python.org/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE patch by Arfrever Frehtes Taifersar Arahesis, I just updated it to be applied to master/KDE4.9 This addresses bug 276151. http://bugs.kde.org/show_bug.cgi?id=276151 Diffs - cmake/modules/PythonMacros.cmake 661e32d Diff: http://git.reviewboard.kde.org/r/107228/diff/ Testing --- Works. kdelibs Arch Linux package uses it since 4.8.4 Thanks, Andrea Scarpino
Re: KDE-GTK-Config to KDEReview
On Wed, Nov 7, 2012 at 9:45 PM, Pino Toscano p...@kde.org wrote:
Hi,
Alle mercoledì 7 novembre 2012, Aleix Pol ha scritto:
On Wed, Nov 7, 2012 at 12:49 AM, Pino Toscano p...@kde.org wrote:
Alle lunedì 5 novembre 2012, Aleix Pol ha scritto:
Some months ago I pushed this project quite intensively so that
right now we have a stable KCM for editing the GTK settings. This
is being used already in some distributions, so I think it should
be moved to extragear/base.
So here I open the process for kde:kde-gtk-config to move in
extragear. Any thoughts?
Sure, here are mine:
- please convert the two QDialog in .ui files to QWidget and put
them in KDialog, so they have a simplier layout and they don't
have to relayout (and retranslate) buttons
Is that really a big problem? I don't really like the jumping from
and to Q/K classes.
Where would be this jumping from and to?
Using KDialog for dialogs makes them follow the KDE style and settings,
and avoid retranslating standard texts.
Ok, not using QDialog anymore...
- I've just simplified some ui strings, but there are still few
more which use the qt rich text format, forcing a font face and
size; please apply the font enlarging at runtime on the font
active at that time
Yep..
Meaning it is going to be fixed? :)
Yes, it should be fixed. I left one in gui.ui which is in a tooltip and I
think it's ok like that.
It's only like this because we wanted to have links in it, if it's wrong,
we can change that of course.and I'll
- QMessageBox - KMessageBox
done
Still there...?
Not anymore.
- related to the above, there's the job of ThreadAnalisysTheme::run
and ThreadAnalisysThemeIcon::run, which currently spawn `tar` to
extract the archive... what about porting them to KArchive (so you
can potentially rely on all the formats supported by that)?
`tar` usage still there.
not anymore!
- AppearanceGTK2::installedThemes and
AppearanceGTK3::installedThemes need to be ported to
KStandardDirs, yes
done
foreach(const QString themesDir, KGlobal::dirs()-findDirs \
(xdgdata-apps, ../themes)) {
This is a bit ich-y, but at the moment I'm not sure how to do it
properly.
I have no idea either, if anybody has an idea, please don't hesitate to
suggest it :).
- port AppearanceGTK3::defaultConfigFile to
KStandardDirs::localxdgconfdir
done
I don't think localxdgconfdir returns an empty directory.
- IconThemesModel really needs to use KStandardDirs instead of
looking for XDG envvars and looking for paths on its own... or,
even, just use KIconLoader/KIconTheme...
true, changed
Why not just use KIconLoader/KIconTheme to simplify even more?
Because the code we have now just works and I don't have much experience
with KIcon* classes.
I know it's a lousy explanation, but I think that it could become a waste
of time...
- the differences between gtkproxies/preview.c and
gtk3proxies/preview3.c seem minimal; is there really no way to have
just one source with at most 1-2 «#if GTK_IS_VERSION(...)» blocks?
also, doesn't glib/gtk offer some kind of functions to parse
command line arguments (similar to getopt, KCmdLineArgs, etc)?
Probably, on the other hand, it just works now and I don't think it
would add much value to spend time improving that, as it's only for
[...]? :)
If nobody has a big problem with having the preview codes duplicated, I'd
prefer to leave it like that.
- there are icons in .ui files which are badly set, see:
$ grep 'pixmap' src/ui/*
so better remove them from .ui files and set them via code.
removed. It was already being set from the code.
- instead of have ThreadErase::run execute a KIO job synchronously, why
not just rely on the async result of the job?
Well it's a thread and the thread needs to wait for the job to finish for
finishing the thread itself, so it would end up being synchronous anyway.
I ported the EraseThread to KJob anyway, because it made sense there.
- AbstractAppearance::hasProperty should be const, and just check
QString::isEmpty?
True, fixed
--
Pino Toscano
Re: KDE-GTK-Config to KDEReview
On Thu, Nov 8, 2012 at 3:47 PM, Pino Toscano p...@kde.org wrote: Hi, thanks for the work you are putting in it, so far. Thanks for your effort for having the best project in extragear as well. :) Alle lunedì 5 novembre 2012, Aleix Pol ha scritto: Some months ago I pushed this project quite intensively so that right now we have a stable KCM for editing the GTK settings. This is being used already in some distributions, so I think it should be moved to extragear/base. So here I open the process for kde:kde-gtk-config to move in extragear. Any thoughts? Looking at the installed files, I see: - stuff in $prefix/bin: - reload_gtk_apps - gtk_preview - gtk3_preview those names are too generic for a global bin dir, what about giving them a kgc_ (kde gtk config) prefix and install them in libexec dir? KStandardDirs::findExe will find them anyway, and this way the global bin dir is not polluted Done. I wanted to do that but I always forgot - the icon $prefix/share/icons/hicolor/48x48/apps/gtkconfig.png had a too generic name for hicolor, I renamed it to kde-gtk-config.png Ok, thanks! -- Pino Toscano
Re: KDEREVIEW: share like connect and plasmate
- PasswordAsker sounds like could be implemented on top of KPasswordDialog gpgme is using pinetry-qt4 for password prompt, i don't think that we should use the KPasswordDialog.
Property id of Plasma::Applet
Hello! I'm trying to use property id of Plasma::Applet in QML, but it isn't notifyable. Do you know can id of applet be changed in run-time? Maybe is it possible to add CONSTANT to declaration of property before KDE 4.10 is released? Thank you.
Re: KDEREVIEW: share like connect and plasmate
Alle giovedì 8 novembre 2012, Antonis Tsiapaliokas ha scritto: - PasswordAsker sounds like could be implemented on top of KPasswordDialog gpgme is using pinetry-qt4 for password prompt, i don't think that we should use the KPasswordDialog. Did you actually understand what I'm referring to? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: KDEREVIEW: share like connect and plasmate
On Thursday, November 8, 2012 20:06:10 Antonis Tsiapaliokas wrote: - PasswordAsker sounds like could be implemented on top of KPasswordDialog gpgme is using pinetry-qt4 for password prompt, i don't think that we should use the KPasswordDialog. gpgme does this because pinentry-qt4 is integrated with the (needs to be secure) gpg passphrase infrastructure. that is not the case here, so it can easily use KPasswordDialog. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: Property id of Plasma::Applet
On Thursday, November 8, 2012 23:12:55 Dmitry A. Ashkadov wrote: Hello! I'm trying to use property id of Plasma::Applet in QML, but it isn't notifyable. Do you know can id of applet be changed in run-time? Maybe is it possible to add CONSTANT to declaration of property before KDE 4.10 is released? Yes, it is constant. I'll note that in the property now. Note that none of Plasma::Applet's properties are notifiable as they were put in place before the QML world decended upon us making that important. In libplasma2, this will not matter though :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: KStringHandler: stateless/reentrant/thread-safe?
On Sunday 28. October 2012 09.22.39 Thiago Macieira wrote: That's a static const non-POD created by a non-constexpr. That means it's initialised on the first run. It's thread-safe on GCC and C++11, but not on other conditions. It should be safe according to the spec (section 6.7 I think), but I guess we can't rely on all compilers to follow the spec? -- Martin Sandsmark KDE
Re: KDEREVIEW: share like connect and plasmate
Did you actually understand what I'm referring to? I guess that we all agree that we should replace the QDialog with the KPasswordDialog (right?). If so, how can we do that? Even if someone doesn't have the pinentry-qt4, then the pinentry (CL) is opening. And i wasn't able to remove the pinentry. (Pinentry is being required by the gpg2). Right now, plasmate doesn't use the QDialog. (For example if your try to remove some of the UI widgets, then the UI doesn't change...) So how can i make the gpgme to use the QDialog/KPasswordDialog instead of the pinentry-qt4?
