Re: KDE Telepathy has an unreleased dependency
On Thu, Feb 26, 2015 at 4:22 PM, Vishesh Handa m...@vhanda.in wrote: On Wed, Feb 25, 2015 at 6:39 PM, Martin Klapetek martin.klape...@gmail.com wrote: As I said it's not even being used right now, so imho would be fine if it got removed/disabled altogether. Also, it will never work. Baloo KF5, has no knowledge about emails. That code also uses Akonadi APIs. There, I fixed it. https://git.reviewboard.kde.org/r/122729/ Cheers -- Martin Klapetek | KDE Developer
Re: KDE Telepathy has an unreleased dependency
On Wed, Feb 25, 2015 at 6:39 PM, Martin Klapetek martin.klape...@gmail.com wrote: As I said it's not even being used right now, so imho would be fine if it got removed/disabled altogether. Also, it will never work. Baloo KF5, has no knowledge about emails. That code also uses Akonadi APIs. -- Vishesh Handa
Re: Multiplatform frameworks
On Thu, Feb 26, 2015 at 3:10 AM, Jeremy Whiting jpwhit...@kde.org wrote:
Hello core developers,
In the past few months some effort has been made to get the frameworks (kf5)
to work on other platforms such as OS X and Windows. Together with Marko I
focused primarily on OS X since there was already a patch for QStandardPaths
there that worked pretty well. In discussion with the Qt developers I began
to think that we maybe should be installing our data files in the places
that QStandardPaths expect to find them, rather than get QStandardPaths to
find files in linuxy paths.
Yesterday I did a test to see if I could get our data files to install to
the places that QStandardPaths looks for them. All I had to do was pass
-DCMAKE_INSTALL_DATADIR=/Users/jeremy/Library/Application Support/ to
cmake (I added it in my .kdesrc-buildrc actually) and most of the frameworks
built just fine with vanilla Qt 5.4.1. Actually even kanagram and khangman
which required the QSP patch to run ran fine after I built kde with that one
change.
One issue I found however is that some frameworks (maybe all?) have a
KF5FooConfig.cmake.in with ${PACKAGE_PREFIX_PATH}/@KDE_INSTALL_DATADIR@ in
them to specify where to find the data files. On my OS X install that was
getting filled in as /usr/local/Users/jeremy/Library/Application Support
which is incorrect. It seems on linux KDE_INSTALL_DATADIR is a subpath of
the prefix, but that doesn't work if we are installing data files outside
the prefix. So how should/could this be solved? I can think of three ideas:
1. Add another .cmake.in specifically for platforms that install data files
outside the prefix such as KF5FooMacConfig.cmake.in which is used on OS X to
generate the KF5FooConfig.cmake and doesn't include ${PACKAGE_PREFIX_PATH}
2. Inside KF5FooConfig.cmake.in have platform detection to define whether to
use the prefix or not.
3. Use absolute paths for KDE_INSTALL_DATADIR everywhere and remove
${PACKAGE_PREFIX_PATH} completely.
I'm not sure which approach would be best, but any would be a step closer to
working better on other platforms.
BR,
Jeremy
Hi Jeremy,
Thanks a lot for looking into this, I think it's very interesting!
So what CMAKE_INSTALL_PREFIX are you setting on your applications?
That's /usr/local? Maybe that doesn't make sense in OS X?
I'd suggest you to play a bit with
modules/ECMPackageConfigHelpers.cmake so we can find what's exactly
the odd part...
Aleix
Re: [KDE/Mac] Multiplatform frameworks
On Wednesday February 25 2015 19:10:08 Jeremy Whiting wrote: QStandardPaths there that worked pretty well. In discussion with the Qt developers I began to think that we maybe should be installing our data files in the places that QStandardPaths expect to find them, rather than get QStandardPaths to find files in linuxy paths. Even if that were the easy way out, I don't think it's the proper solution if not only because OS X and MS Windows are multi-user machines and are maybe more often used like that than Linux desktop installs. Installing stuff in $HOME/Library/Application Support is thus not an option (besides, there's that obnoxious space in the filename that's bound to cause issues). If we can't find a best-of-both-worlds solution that we all agree on and can go into Qt, we'll just have to roll our own (which might be incorporated after all once it's proved its value ;)) Reminder to self: add my views to wherever we decided to continue the stalled discussion from gerrit. R
Re: kio-extras
El Dijous, 26 de febrer de 2015, a les 08:56:26, David Faure va escriure: On Thursday 26 February 2015 01:02:04 Albert Astals Cid wrote: Really it has to be either part of KIO or another framework, i mean, if you're using the desktop only (and no apps) you're also going to need it. Can you expand on why you are going to need it? I install workspace only. OK, I have a workspace. It works, but it has limited functionality obviously. No calculator - I install kcalc No text editor - I install kwrite No file manager - I install dolphin No support for sftp or thumbnails in dolphin - I install kio-extras. (of course this is written as a compiling-from-scratch type setup, in practice the binary package for dolphin would bring it in as a dependency) Ah. Is this about kio_desktop? That one should *definitely* be in workspace. But it doesn't have to be in kio-extras. Honestly I don't care, i fail to see why you want kio-extras in apps instead of frameworks while frameworksintegration is a framework and not an app or a desktop thing, but let's not discuss about technicalities. Anyway, If you want kio-extras in apps, someone needs to make sure it works, and if you want it in KDE Applications 15.04 someone needs to request an exception since Feature Freeze was yesterday. Cheers, Albert
Re: KDE Telepathy has an unreleased dependency
El Dijous, 26 de febrer de 2015, a les 16:55:17, Martin Klapetek va escriure: On Thu, Feb 26, 2015 at 4:22 PM, Vishesh Handa m...@vhanda.in wrote: On Wed, Feb 25, 2015 at 6:39 PM, Martin Klapetek martin.klape...@gmail.com wrote: As I said it's not even being used right now, so imho would be fine if it got removed/disabled altogether. Also, it will never work. Baloo KF5, has no knowledge about emails. That code also uses Akonadi APIs. There, I fixed it. https://git.reviewboard.kde.org/r/122729/ Cheers So we still need a KPeople release, which is still in playground so noone has properly reviewed it, and you want to speed-turn it into a frameworks in 1 day. Do you actually have anyone to review it in such notice? At least sanitize the headers? This feels like rush, rush and rush. KDE Applications schedule has been set for months, I've sent various reminders about the freeze dates, and yet, here we are, post freeze with unresolved issues, why are we doing this now and not last week? Albert
Re: [KDE/Mac] Multiplatform frameworks
On Thu, Feb 26, 2015 at 10:45 AM, René J.V. rjvber...@gmail.com wrote: On Wednesday February 25 2015 19:10:08 Jeremy Whiting wrote: QStandardPaths there that worked pretty well. In discussion with the Qt developers I began to think that we maybe should be installing our data files in the places that QStandardPaths expect to find them, rather than get QStandardPaths to find files in linuxy paths. Even if that were the easy way out, I don't think it's the proper solution if not only because OS X and MS Windows are multi-user machines and are maybe more often used like that than Linux desktop installs. Installing stuff in $HOME/Library/Application Support is thus not an option (besides, there's that obnoxious space in the filename that's bound to cause issues). If we can't find a best-of-both-worlds solution that we all agree on and can go into Qt, we'll just have to roll our own (which might be incorporated after all once it's proved its value ;)) Reminder to self: add my views to wherever we decided to continue the stalled discussion from gerrit. R IIRC, the solution is using /Library instead, although my OS X knowledge is rusty. Aleix
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated Feb. 27, 2015, 1:18 a.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. Changes --- Fix message box. What about having this message box as intermediate solution until the xkill generalization is done? Repository: libksysguard Description --- Current situation: The End Process... button has a tooltip which says To target a specific window to kill, press Ctrl+Alt+Esc at any time. The keyboard shortcut is hardcoded. RR: Add a drop down menu to the End Process... button with one action: i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut) Diffs (updated) - processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 tests/keyboardshortcututiltest.h PRE-CREATION tests/keyboardshortcututiltest.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122249/diff/ Testing --- File Attachments New End Process button with drop down arrow https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/16301e88-e21b-4358-9a63-a85dae5722bd__screenshot_default1.png Drop down shows Kill Window https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png Thanks, Gregor Mi
Re: [KDE/Mac] Multiplatform frameworks
Yeah, obviously to share with all users installing data files into /Library/Application Support/ is better, I just didn't do that in my test since my user doesn't own that folder and I didn't want to install with sudo for a test. On Thu, Feb 26, 2015 at 7:26 PM, Aleix Pol aleix...@kde.org wrote: On Thu, Feb 26, 2015 at 10:45 AM, René J.V. rjvber...@gmail.com wrote: On Wednesday February 25 2015 19:10:08 Jeremy Whiting wrote: QStandardPaths there that worked pretty well. In discussion with the Qt developers I began to think that we maybe should be installing our data files in the places that QStandardPaths expect to find them, rather than get QStandardPaths to find files in linuxy paths. Even if that were the easy way out, I don't think it's the proper solution if not only because OS X and MS Windows are multi-user machines and are maybe more often used like that than Linux desktop installs. Installing stuff in $HOME/Library/Application Support is thus not an option (besides, there's that obnoxious space in the filename that's bound to cause issues). If we can't find a best-of-both-worlds solution that we all agree on and can go into Qt, we'll just have to roll our own (which might be incorporated after all once it's proved its value ;)) Reminder to self: add my views to wherever we decided to continue the stalled discussion from gerrit. R IIRC, the solution is using /Library instead, although my OS X knowledge is rusty. Aleix
