Re: New repo in kdereview: KWeather

[Jeremy Whiting]

Looks like it's got a runtime dependency on kirigami (Maybe that's expected
for plasma-mobile, not sure)

Built it on laptop and got this from cmake:

cmake ..
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Python3: /usr/bin/python3.10 (found version "3.10.8") found
components: Interpreter
-- Could NOT find ReuseTool (missing: REUSETOOL_EXECUTABLE)
CMake Warning at /usr/share/ECM/modules/ECMCheckOutboundLicense.cmake:86
(message):
 Reuse tool not found, skipping test generation
Call Stack (most recent call first):
 CMakeLists.txt:30 (include)


-- Skipping execution of outbound license tests.
-- Installing in the same prefix as Qt, adopting their path scheme.
-- Setting build type to 'Debug' as none was specified.
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Performing Test HAVE_DATE_TIME
-- Performing Test HAVE_DATE_TIME - Success
-- Found KF5Config: /usr/lib64/cmake/KF5Config/KF5ConfigConfig.cmake (found
version "5.99.0")
-- Found KF5Kirigami2:
/usr/lib64/cmake/KF5Kirigami2/KF5Kirigami2Config.cmake (found version
"5.99.0")
-- Found Gettext: /usr/bin/msgmerge (found version "0.21.1")
-- Found KF5I18n: /usr/lib64/cmake/KF5I18n/KF5I18nConfig.cmake (found
version "5.99.0")
-- Found KF5CoreAddons:
/usr/lib64/cmake/KF5CoreAddons/KF5CoreAddonsConfig.cmake (found version
"5.99.0")
-- Found KF5Notifications:
/usr/lib64/cmake/KF5Notifications/KF5NotificationsConfig.cmake (found
version "5.99.0")
-- Found KF5: success (found suitable version "5.99.0", minimum required is
"5.90.0") found components: Config Kirigami2 I18n CoreAddons Notifications
-- Found X11: /usr/include
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so -
found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found KF5Plasma: /usr/lib64/cmake/KF5Plasma/KF5PlasmaConfig.cmake (found
version "5.99.0")
-- Found KF5: success (found suitable version "5.99.0", minimum required is
"5.90.0") found components: Plasma
-- Found org.kde.kholidays-QMLModule: TRUE (found version "")
-- The following RUNTIME packages have been found:

* org.kde.kholidays-QMLModule, QML module 'org.kde.kholidays' is a runtime
dependency.

-- The following OPTIONAL packages have been found:

* Python3
  Required to run tests of module ECMCheckOutboundLicense
* Qt5QuickCompiler
* KF5Package (required version >= 5.99.0)
* KF5Service (required version >= 5.99.0)
* Freetype
* PkgConfig
* Fontconfig

-- The following REQUIRED packages have been found:

* ECM (required version >= 5.90.0)
* Qt5Network (required version >= 5.15.7)
* Qt5QmlModels (required version >= 5.15.7)
* Qt5Quick
* Qt5Test
* Qt5Svg
* Qt5QuickControls2
* Qt5Charts
* KF5Kirigami2 (required version >= 5.90.0)
* Gettext
* KF5I18n (required version >= 5.90.0)
* KF5Notifications (required version >= 5.90.0)
* KF5KWeatherCore (required version >= 0.6.0)
* KF5CoreAddons (required version >= 5.99.0)
* Qt5Gui (required version >= 5.15.2)
* Qt5Widgets (required version >= 5.15.2)
* KF5Plasma (required version >= 5.90.0)
* KF5 (required version >= 5.90.0)
* Qt5Qml
* Qt5Core
* Qt5

-- The following features have been disabled:

* SPDX_LICENSE_TESTING, Automatic license testing based on SPDX definitions
(requires reuse tool)

-- The following OPTIONAL packages have not been found:

* ReuseTool
  Required to run tests of module ECMCheckOutboundLicense

-- Configuring done
-- Generating done
-- Build files have been written to:
/home/jeremy/data/devel/kde/src/kde/plasma-mobile/kweather/build

then it built and installed fine, but trying to run failed with this:

kweather
QQmlApplicationEngine failed to load component
qrc:/qml/main.qml:163:26: Type SettingsDialog unavailable
qrc:/qml/settings/SettingsDialog.qml:33:22: Type SettingsComponent
unavailable
qrc:/qml/settings/SettingsComponent.qml:13:1: module
"org.kde.kirigamiaddons.labs.mobileform" is not installed

maybe cmake should have said it depends on kirigami?

On Wed, Nov 9, 2022 at 3:00 PM Devin  wrote:

> Hi everyone,
>
> I would like to put kweather through kdereview:
>
> https://invent.kde.org/plasma-mobile/kweather
>
> KWeather is an application that can give simple weather 

Re: New repo in kdereview: KWeather

[Jeremy Whiting]

After installing kirigami-addons it runs fine, adding my location went
smooth, etc. Only nitpick I found as a user was that it's a bit weird that
Settings -> About changes the main window instead of showing about data in
the little settings window. I would suggest making About be one of the
buttons on the main window, or showing the about data in the settings
window.

On Wed, Nov 9, 2022 at 3:31 PM Jeremy Whiting 
wrote:

> Looks like it's got a runtime dependency on kirigami (Maybe that's
> expected for plasma-mobile, not sure)
>
> Built it on laptop and got this from cmake:
>
> cmake ..
> -- The C compiler identification is GNU 12.2.0
> -- The CXX compiler identification is GNU 12.2.0
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Found Python3: /usr/bin/python3.10 (found version "3.10.8") found
> components: Interpreter
> -- Could NOT find ReuseTool (missing: REUSETOOL_EXECUTABLE)
> CMake Warning at /usr/share/ECM/modules/ECMCheckOutboundLicense.cmake:86
> (message):
>  Reuse tool not found, skipping test generation
> Call Stack (most recent call first):
>  CMakeLists.txt:30 (include)
>
>
> -- Skipping execution of outbound license tests.
> -- Installing in the same prefix as Qt, adopting their path scheme.
> -- Setting build type to 'Debug' as none was specified.
> -- Looking for __GLIBC__
> -- Looking for __GLIBC__ - found
> -- Performing Test _OFFT_IS_64BIT
> -- Performing Test _OFFT_IS_64BIT - Success
> -- Performing Test HAVE_DATE_TIME
> -- Performing Test HAVE_DATE_TIME - Success
> -- Found KF5Config: /usr/lib64/cmake/KF5Config/KF5ConfigConfig.cmake
> (found version "5.99.0")
> -- Found KF5Kirigami2:
> /usr/lib64/cmake/KF5Kirigami2/KF5Kirigami2Config.cmake (found version
> "5.99.0")
> -- Found Gettext: /usr/bin/msgmerge (found version "0.21.1")
> -- Found KF5I18n: /usr/lib64/cmake/KF5I18n/KF5I18nConfig.cmake (found
> version "5.99.0")
> -- Found KF5CoreAddons:
> /usr/lib64/cmake/KF5CoreAddons/KF5CoreAddonsConfig.cmake (found version
> "5.99.0")
> -- Found KF5Notifications:
> /usr/lib64/cmake/KF5Notifications/KF5NotificationsConfig.cmake (found
> version "5.99.0")
> -- Found KF5: success (found suitable version "5.99.0", minimum required
> is "5.90.0") found components: Config Kirigami2 I18n CoreAddons
> Notifications
> -- Found X11: /usr/include
> -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so
> -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so -
> found
> -- Looking for gethostbyname
> -- Looking for gethostbyname - found
> -- Looking for connect
> -- Looking for connect - found
> -- Looking for remove
> -- Looking for remove - found
> -- Looking for shmat
> -- Looking for shmat - found
> -- Looking for IceConnectionNumber in ICE
> -- Looking for IceConnectionNumber in ICE - found
> -- Found KF5Plasma: /usr/lib64/cmake/KF5Plasma/KF5PlasmaConfig.cmake
> (found version "5.99.0")
> -- Found KF5: success (found suitable version "5.99.0", minimum required
> is "5.90.0") found components: Plasma
> -- Found org.kde.kholidays-QMLModule: TRUE (found version "")
> -- The following RUNTIME packages have been found:
>
> * org.kde.kholidays-QMLModule, QML module 'org.kde.kholidays' is a runtime
> dependency.
>
> -- The following OPTIONAL packages have been found:
>
> * Python3
>   Required to run tests of module ECMCheckOutboundLicense
> * Qt5QuickCompiler
> * KF5Package (required version >= 5.99.0)
> * KF5Service (required version >= 5.99.0)
> * Freetype
> * PkgConfig
> * Fontconfig
>
> -- The following REQUIRED packages have been found:
>
> * ECM (required version >= 5.90.0)
> * Qt5Network (required version >= 5.15.7)
> * Qt5QmlModels (required version >= 5.15.7)
> * Qt5Quick
> * Qt5Test
> * Qt5Svg
> * Qt5QuickControls2
> * Qt5Charts
> * KF5Kirigami2 (required version >= 5.90.0)
> * Gettext
> * KF5I18n (required version >= 5.90.0)
> * KF5Notifications (required version >= 5.90.0)
> * KF5KWeatherCore (required version >= 0.6.0)
> * KF5CoreAddons (required version >= 5.99.0)
> * Qt5Gui (required version >= 5.15.2)
> * Qt5Widgets (required version >= 5.15.2)
> * KF5Plasma (required version >= 5.90.

Re: MacOS signing issue.

[Jeremy Whiting]

Notarizing and signing are actually separate things on MacOS, signing the
app or checking the signature of the dmg are orthogonal to the issue
described and the popup in that report. Notarization is sending the app
(zipped) to apple's notarization service so they can check it doesn't use
any apis that it shouldn't or something, then the .app needs to be
"stapled" with the notarization before putting it into the dmg. That said
iirc signing the app is a requirement before submitting the app to apple's
notarization service in the first place.

On Thu, Oct 22, 2020 at 11:12 AM Ben Cooksley  wrote:

> On Fri, Oct 23, 2020 at 6:08 AM Michael Reeves 
> wrote:
>
>> Could someone familiar with the CI and OS X signing machinism look at
>> this.
>>
>> https://bugs.kde.org/show_bug.cgi?id=428062
>>
>> I have no way to test or fix this issue. Which as far as I know is an
>> issue with the CI on binary factory.
>>
>
> This is because Craft to my knowledge at this time does not support
> notarization of MacOS binaries.
>
> Once that has been added, the issue should disappear.
>
> Regards,
> Ben
>

Re: Review Request 121584: Make the webapp manager run again.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121584/
---

(Updated Feb. 8, 2017, 1:25 p.m.)


Status
--

This change has been discarded.


Review request for Bodega, kdelibs, Aaron J. Seigo, and Marco Martin.


Repository: bodega-webapp-manager


Description
---

Make the webapp manager run again.


Diffs
-

  app.js ceede62c192451f2ac2bba8848a97f9bcc4a2f4a 
  package.json 715d01c3fa9e9f3a890ee9e047093fdfb528095f 
  public/favicon.ico PRE-CREATION 
  routes.js 891660f7fb3d036b5907114c58bd17f1128b1efe 
  views/layout.jade 423a37493acac482369693168cce32886a71f0bb 

Diff: https://git.reviewboard.kde.org/r/121584/diff/


Testing
---

It runs now, and gives 200 or 304 responses, though the browser currently shows 
"Page Not Found"


Thanks,

Jeremy Whiting

Re: [kde-community] Sunsetting of Infrastructure and the Phabricator migration

[Jeremy Whiting]

Just a note so everyone doesn't need to go google/search this
themselves. To see your scratch repositories look at quickgit.kde.org
and filter by your identity name. To delete old repos, do this:

ssh g...@git.kde.org D unlock scratch//reponame <--
notice no .git on the end, if you put .git it will just say "You are
not authorized"
ssh g...@git.kde.org D rm scratch//reponame

Hope that helps,
Jeremy

On Fri, Mar 18, 2016 at 12:46 AM, Ben Cooksley  wrote:
> == This mail is considered mandatory reading for all KDE Developers.
> Please read this email in whole. ==
>
> Hi all,
>
> As you'll all be aware we are currently in the process of overhauling
> our Git infrastructure, and replacing numerous elements of it.
>
> The first part of this will take place this weekend - with
> projects.kde.org being shutdown. All Git repository browsing from that
> point on should take place through quickgit.kde.org. commits.kde.org
> will also be reconfigured to redirect you exclusively to
> quickgit.kde.org.
>
> As a result the tree structure will only be available from the XML
> file from this point onward. There are no plans to replicate the tree
> structure within Phabricator (although some of the grouping it
> facilitates may be provided through a different mechanism)
>
> The XML file upon which numerous utilities (including kdesrc-build)
> depend will continue to be made available. It will instead be
> generated by a Python script periodically, based on the contents of a
> Git repository.
>
> In terms of Reviewboard, there are no plans to import it's contents
> into Phabricator, as the level of effort required is too high. Once we
> are migrated to Phabricator for reviews, i'm proposing that everyone
> has 4 weeks to finish any final reviews up within Reviewboard before
> it is set to read only by disabling login for everyone. Reviews still
> open at that point would be discarded.
>
> The contents of Kanboard will be migrated into Phabricator, more
> details will come on that over the next few weeks, including details
> of any action people needs to take. As an immediate measure it would
> be appreciated if people could conduct a general cleanup and remove
> tasks and boards they have no intention of using or revisiting in the
> future. Following this migration Kanboard will be shutdown.
>
> In terms of repositories, now would be a good time to look into the
> scratch and clone repositories you have on git.kde.org and perform a
> cleanup of any repositories which are unused, not useful or are
> otherwise no longer needed.
>
> We will be looking into how to import our repositories into
> Phabricator which will include all scratch and clone repositories.
> This means the entire content of these repositories will be indexed,
> and reducing the number of repositories will reduce the amount of
> indexing work which Phabricator needs to complete.
>
> I should also note that as a side affect of the Phabricator
> transition, scratch/clone repositories will to a certain extent cease
> to exist - everything will now be a mainline repository. As a
> consequence force pushes will be disabled for all repositories as part
> of the migration (including scratch repositories). We will be creating
> a mechanism which will allow repositories following certain naming
> conventions to be easily created by developers (although this will
> have to be done through the web interface).
>
> As part of the capabilities of Phabricator, sysadmin will also be
> extending the power to create general purpose mainline repositories
> (and certain other actions within Phabricator) to a number of
> community members. They will be contacted individually over the next
> month or two regarding this.
>
> Comments on the above are welcome (little is in concrete yet), please
> start them in appropriate sub-threads on kde-core-devel (to minimize
> cross-posting, etc).
>
> Thanks,
> Ben Cooksley
> KDE Sysadmin
> ___
> kde-community mailing list
> kde-commun...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community

Re: remove khelpcenter from next Plasma release?

[Jeremy Whiting]

As an application developer I agree it makes sense to have khelpcenter
released with KDE Applications. I also agree with Albert's point that
having online documentation isn't the best since it could be newer
than what's actually running. People using LTS distributions or
"stable" variants of less often released distributions will have very
old (to those of us that run from git) versions of stuff. Having
online documentation for plasma 5.7 to look at while you're running
plasma 4 would just confuse.

Also, thanks Luigi for stepping up to maintain it.

BR,
Jeremy

On Tue, Mar 15, 2016 at 4:11 PM, Luigi Toscano  wrote:
> Luigi Toscano ha scritto:
>> On Wednesday 09 of March 2016 16:50:39 Sebastian Kügler wrote:
>>> On Wednesday, March 09, 2016 17:30:01 Luigi Toscano wrote:
> Let me cut right to the chase, do you want to maintain it? Does it need
> to
> be in Plasma?

 Yes, I can maintain it. In fact many features come from components I
 already  control.

> You're right that Plasma devs don't seem to want it, I thought my
> initial
> email made that pretty clear. We do think that disconnected systems are
> rather a fringe case, and that our time and effort is better spent on
> other
> things.

 Then the question still holds: with a maintainer, does it have a place in
 Plasma? I'm not talking about an hypothetical time and effort for
 maintaining  this offline use case (which will continue to be 0) but in
 the
 light of the statement above. In other words, if the question mark in the
 subject is real or rhetorical.
 I'm ready for both possible outcomes.
>>>
>>> Ah OK, sorry for misunderstanding it.
>>>
>>> I think there are the following options:
>>>
>>> 1) keeping it in Plasma with maintainer
>>> 2) keeping it outside of Plasma with maintainer
>>> 3) moving it to unmaintained (that's basically killing it)
>>> 4) keeping the status quo (not wanted)
>>>
>>> My personal preference would be an optional component (hence Extragear),
>>> since I think that the vast majority of users has web access, so
>>> khelpcenter isn't necessary and only adds to our maintainance burden
>>> without much gain in those cases.
>>
>> My offer stands and we can rule out 4) and 3).
>> Note that 2) could also mean a move to Applications (from your point of view
>> it does not matter too much).
>> The case 1) shouldn't add maintenance anyway as the maintainer is identified.
>>
>>>
>>> If we can move from 4) to 1) (so status quo but with maintainer), that would
>>> already be an improvement of course.
>>>
>>> The question mark was honest, we haven't made a decision on it, but
>>> different people do have expressed a preference for not shipping it (as or
>>> by default in Plasma releases). We may have missed important points, and we
>>> don't want to just kick things out unilaterally.
>>
>> I think we can leave some time for other people to comment. The shortest
>> deadline of all possibilities is the one for moving into Applications, and
>> there are still 8 days before the dependency freeze and two weeks before the
>> branch.
>
> Any other comment from anyone else?
>
> Ciao
> --
> Luigi
> ___
> Plasma-devel mailing list
> plasma-de...@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Minuet (music education software) moved to kdereview

[Jeremy Whiting]

Sandro,

We have a mixture of both in kde-edu. I know kanagram and khangman use
their own versioning numbers. If no changes happen between releases we
don't bump the version number. If they do we do. I think at some point
when it's pretty solid you may want to consider using the KDE
Applications version numbering, but to start off, using 0.1, 0.2 etc.
to indicate that it's a new project makes sense.

BR,
Jeremy

On Mon, Feb 8, 2016 at 12:21 PM, Sandro Andrade  wrote:
> On Mon, Feb 8, 2016 at 2:44 PM, Sandro Andrade  wrote:
>> On Sun, Jan 31, 2016 at 8:42 PM, Aleix Pol  wrote:
>>> On Mon, Feb 1, 2016 at 12:30 AM, Albert Astals Cid  wrote:
 El Tuesday 26 January 2016, a les 10:15:47, Andreas Cord-Landwehr va 
 escriure:
> On Monday 25 January 2016 21:48:27 Albert Astals Cid wrote:
> > El Sunday 24 January 2016, a les 16:50:18, Andreas Cord-Landwehr va
>
> escriure:
> > > * it looks strange to me that in minuet/cmake/ there are Config-files
> > > for
> > > the 3rd-party library drumstick. My understanding was that such Config
> > > files should only be shipped with the respective library (maybe 
> > > someone
> > > with a deeper CMake-knowledge can comment?)
> >
> > If upstream ships a cmake file awesome, but if not then we have to find 
> > it
> > having our own cmake file.
>
> Absolutely, but shouldn't that be find-files then instead of config-files?
> I always had the perception that those are quite different.

 Right, it most probably be a Find file not a Config file, as far as I
 understand it Config files are mostly for projects that ship the cmake 
 file as
 part of their install.

 Can someone with more cmake knowledge comment?
>>>
>>> Yes, the idea is that *Config.cmake files should be distributed by the
>>> framework itself, otherwise you need to find it. It probably works
>>> though, because such things are seldom checked within cmake though.
>>>
>>> I suggest turning it into a normal Find*.cmake file. Or get Drumstick
>>> to provide a cmake file, which is always more convenient.
>>
>> Hi,
>>
>> I've changed CMakeLists.txt to find out drumstick libs using 
>> pkg_check_modules,
>> which is the way other drumstick clients (like KMetronome, KMidimon)
>> actually do.
>> I confirm that works fine at least in Arch, KUbuntu, openSUSE, and Fedora 
>> (other
>> distros should package drumstick's pkg-config files similarly).
>>
>> The three weeks period (two weeks review + one week after completion
>> of requested changes)
>> ends tomorrow. I plan to move it to KDE edu by the end of this week,
>> so that further suggestions
>> are quite welcome :)
>>
>> Also, could someone clarify the questions I raised before? (copied below)
>>
>> * Regarding Minuet versioning itself: should I use the automatic version
>> numbering from release script or should I start from a 1.0.0 release?
>> * Also, where are those release scripts stored (some repository)?
>
> That seems to be the release-tools.git repository. Following the version
> numbering of KDE Applications would be nice for consistency but it may
> not reflect the fact Minuet is yet in its early days.
>
> Suggestions?
>
> Sandro
>
>>
>> Cheers,
>> Sandro
>>
>>>
>>> Aleix

Re: Maintenance of api.kde.org

[Jeremy Whiting]

Alex,

Last time I checked api.kde.org was generated by scripts in the
websites/quality-kde-org git repository. It includes instructions for
installing it locally, though the instructions are a bit outdated. I
think perl's setup scripts have changed since it was written since I
needed to tweak the install script to get it to install here (when I
was looking into it about 8 months ago or so). Poke me if you hit the
same issues and I can put a patch up on reviewboard if it's still
around my hard drive here somewhere...

thanks,
Jeremy

On Thu, Nov 5, 2015 at 4:58 PM, Alex Merry  wrote:
> On 2015-11-05 09:22, Ben Cooksley wrote:
>>
>> Hi all,
>>
>> For some time it has been apparent that api.kde.org is experiencing
>> some issues with maintenance. It doesn't really fall into sysadmin's
>> domain, but developers often lack the knowledge on how to get Doxygen
>> working as needed to build projects API documentation. This isn't
>> helped by the setup not being simple for easy local testing.
>>
>> Any volunteers to look into it, fix some issues and generally make it
>> easier to work with for the future?
>
>
> This is my domain really, as maintainer of kapidox - kapidox was intended to
> make this simpler and easier, but currently it's only run on frameworks. I
> don't really know much about the automation on api.kde.org itself, though,
> and we need to figure out how to choose whether to run kapidox, kdelibs4's
> apidox generation scripts, or no apidox generation at all for a given
> project.
>
> I'm willing to put some time into this, but I'd need to be able to at least
> mirror api.kde.org's setup locally to try tweaking and testing things -
> going through Allen Winter every time I want to test something out (and then
> waiting for the cron jobs or whatever to run) is just too slow of a feedback
> cycle.
>
> Alex

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Jeremy Whiting]

Ok, I just removed ksnapshot from the release-tools script. It won't
be included in Applications 15.12 releases.

On Sun, Oct 18, 2015 at 8:46 AM, Ivan Čukić  wrote:
>> Oh yes, I had completely forgotten about that. Thank you so much for
>> bringing this to notice, Ivan!
>
> No problem. I've noticed the issue when I wanted to submit a couple of
> bugs/wishlist things. :)
>
> Cheers,
> Ivan

Re: Cervisia?

[Jeremy Whiting]

Awesome! Keep it up. Porting to Qt5/KF5 can happen on a branch and be
done a small bit at a time if you like. There are also some scripts in
kdesdk/kde-dev-scripts/kf5 that can help with the trivial changes.
Most are executed like find -iname *.cpp | xargs scriptname, but if
not they will say in a comment at the top of the script how to execute
them.

On Thu, Oct 15, 2015 at 8:02 PM, Martin Koller <kol...@aon.at> wrote:
> On Thursday 15 October 2015 15:49:32 Jeremy Whiting wrote:
>> Michael, Martin,
>>
>> Any progress on the cervisia front? Is there anything I can do to help?
>
> yes, a lot of progress!
> We have already ported away from Qt3/KDE3 support classes.
> This is already in master and I'm testing it by using it on a daily basis.
>
> The next step would now be to start the port to KF5 - this has not been 
> started yet.
>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> ()  ascii ribbon campaign - against html e-mail
> /\- against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

Re: Cervisia?

[Jeremy Whiting]

Michael, Martin,

Any progress on the cervisia front? Is there anything I can do to help?

thanks,
Jeremy

On Sat, Sep 26, 2015 at 8:25 PM, Michael Reeves <reeves...@gmail.com> wrote:
>
> On Sep 26, 2015 9:22 PM, "Jeremy Whiting" <jpwhit...@kde.org> wrote:
>>
>> Martin,
>>
>> Michael Reeves reeves...@gmail.com mentioned he would be interested in
>> helping also, maybe the two of you can get it ported away from
>> Qt3Support, then ported to Qt5/Kf5 ?
>>
>> thanks,
>> Jeremy
>>
> Sounds like a plan. I don't have write access to the repo. I too have
> limited time.

Re: Review Request 125561: Sync FindGettext.cmake macros with upstream module from CMake

[Jeremy Whiting]

> On Oct. 9, 2015, 2:26 p.m., Albert Astals Cid wrote:
> > This doesn't look like "a bugfix" to me.
> 
> Jeremy Whiting wrote:
> Oh, but it is. Without this or cmake_policy(SET CMP0002 OLD) (see 
> https://bugs.kde.org/show_bug.cgi?id=316308) applications that have their own 
> translations in the tarball (everything we release from extragear) fails to 
> build with a newer cmake. With this change in the kdelibs cmake modules it 
> builds fine by setting a different target for each po folder.
> 
> Albert Astals Cid wrote:
> Ok, bad wording, it's probably a bugfix, but doesn't look like a minimal 
> bugfix, i mean it's rewriting the whole file, is there nothing better than 
> that we can do?

Ah, that I don't know. As I said before, following all this cmake macro stuff 
is somehow over my head (or I'm not trying hard enough, dunno). Hrvoje, is 
there a simpler way to do what you're proposing here?


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125561/#review86580
---


On Oct. 8, 2015, 11:50 a.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125561/
> ---
> 
> (Updated Oct. 8, 2015, 11:50 a.m.)
> 
> 
> Review request for Build System, kdelibs, Localization and Translation 
> (l10n), Albert Astals Cid, and Alexander Neundorf.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Otherwise some apps fail to build with kdelibs >= 4.14.11:
> ```
> CMake Error at /usr/share/kde4/apps/cmake/modules/FindGettext.cmake:232 
> (ADD_CUSTOM_TARGET):
>   add_custom_target cannot create target "pofiles" because another target
>   with the same name already exists.  The existing target is a custom target
>   created in source directory
>   "/home/hrvoje/rpmbuild/BUILD/skanlite-1.1/po/be".  See documentation for
>   policy CMP0002 for more details.
> Call Stack (most recent call first):
>   po/zh_CN/CMakeLists.txt:2 (GETTEXT_PROCESS_PO_FILES)
> ```
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindGettext.cmake 91e88f7 
> 
> Diff: https://git.reviewboard.kde.org/r/125561/diff/
> 
> 
> Testing
> ---
> 
> Skanlite now builds.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

Re: Review Request 125561: Sync FindGettext.cmake macros with upstream module from CMake

[Jeremy Whiting]

> On Oct. 9, 2015, 2:26 p.m., Albert Astals Cid wrote:
> > This doesn't look like "a bugfix" to me.

Oh, but it is. Without this or cmake_policy(SET CMP0002 OLD) (see 
https://bugs.kde.org/show_bug.cgi?id=316308) applications that have their own 
translations in the tarball (everything we release from extragear) fails to 
build with a newer cmake. With this change in the kdelibs cmake modules it 
builds fine by setting a different target for each po folder.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125561/#review86580
---


On Oct. 8, 2015, 11:50 a.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125561/
> ---
> 
> (Updated Oct. 8, 2015, 11:50 a.m.)
> 
> 
> Review request for Build System, kdelibs, Localization and Translation 
> (l10n), Albert Astals Cid, and Alexander Neundorf.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Otherwise some apps fail to build with kdelibs >= 4.14.11:
> ```
> CMake Error at /usr/share/kde4/apps/cmake/modules/FindGettext.cmake:232 
> (ADD_CUSTOM_TARGET):
>   add_custom_target cannot create target "pofiles" because another target
>   with the same name already exists.  The existing target is a custom target
>   created in source directory
>   "/home/hrvoje/rpmbuild/BUILD/skanlite-1.1/po/be".  See documentation for
>   policy CMP0002 for more details.
> Call Stack (most recent call first):
>   po/zh_CN/CMakeLists.txt:2 (GETTEXT_PROCESS_PO_FILES)
> ```
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindGettext.cmake 91e88f7 
> 
> Diff: https://git.reviewboard.kde.org/r/125561/diff/
> 
> 
> Testing
> ---
> 
> Skanlite now builds.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

Re: Review Request 125561: Sync FindGettext.cmake macros with upstream module from CMake

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125561/#review86518
---


Looks good to me, but I can't quite follow it all myself. Someone else should 
give the ship it. If it fixes it so setting the CMake policy 0002 to OLD isn't 
needed anymore that's good.

- Jeremy Whiting


On Oct. 8, 2015, 11:50 a.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125561/
> ---
> 
> (Updated Oct. 8, 2015, 11:50 a.m.)
> 
> 
> Review request for Build System, kdelibs, Localization and Translation 
> (l10n), Albert Astals Cid, and Alexander Neundorf.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Otherwise some apps fail to build with kdelibs >= 4.14.11:
> ```
> CMake Error at /usr/share/kde4/apps/cmake/modules/FindGettext.cmake:232 
> (ADD_CUSTOM_TARGET):
>   add_custom_target cannot create target "pofiles" because another target
>   with the same name already exists.  The existing target is a custom target
>   created in source directory
>   "/home/hrvoje/rpmbuild/BUILD/skanlite-1.1/po/be".  See documentation for
>   policy CMP0002 for more details.
> Call Stack (most recent call first):
>   po/zh_CN/CMakeLists.txt:2 (GETTEXT_PROCESS_PO_FILES)
> ```
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindGettext.cmake 91e88f7 
> 
> Diff: https://git.reviewboard.kde.org/r/125561/diff/
> 
> 
> Testing
> ---
> 
> Skanlite now builds.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

Filling Holes

[Jeremy Whiting]

Hello everyone.

I'm cross posting to a couple of lists on purpose to hit a bigger audience.

The release team wants you! 

Have you ever thought about what it takes to make KDE software
releases great? Now you can find out first hand. The release team is
in need of some module coordinators as seen here [1]. If you have a
moderate amount of experience with some software we develop step up
and help out. What qualifications are required to become a module
coordinator? Read them there on the techbase page, but mostly these
imo.

 - Don't mind poking stuff in your chosen area to make sure everything builds
 - Watch to make sure nobody breaks stuff in your module
 - Can fix stuff when needed for releases if it is broken for some reason
 - Help shape the future of your chosen module

As you can see it mostly comes down to having time. If you are
interested in any of the spots marked there as "Help Wanted" please
step up and help us continue to make releases awesome.

thanks,
Jeremy

1. https://techbase.kde.org/Projects/Release_Team#Coordinator_List

Re: State of Audio CD support in KDE

[Jeremy Whiting]

Boudhayan,

I think your plan looks good to me. Let me know if I can help in any way.

thanks,
Jeremy

On Tue, Sep 29, 2015 at 6:03 PM, Boudhayan Gupta  wrote:
> Hi Albert (and others),
>
> On 30 September 2015 at 04:09, Albert Astals Cid  wrote:
>>> In terms of support for Audio CDs in KDE,
>>>
>>> * K3B can write them.
>>> * Phonon the API can play them, with some minor but weird bugs.
>>>
>>> And that's it.
>>
>> Does solid offer some support?
>> I guess at least it can say how many drives are there
>> but maybe nothing related to Audio-CD itself?
>
> Solid is interesting. It can detect the number of drives in the
> system, and it can tell us if the CD inside is an Audio CD.
>
> We can also subscribe to signals from Solid that notify is the disc is
> ejected, but there's no signal in Solid::OpticalDrive to notify if a
> new disc was inserted. Maybe it's a small patch that can be worked on?
>
>>> I think we need to take a long hard look at the state of support for
>>> Red Book CDs in KDE and decide:
>>>
>>> a) Do we still want to support them, and
>>> b) If yes, to what degree do we support them?
>>
>> I'd say we totally want to support them. The question is if there's
>> something that can be shared in an library or should it be app specific.
>>
>> The things i can think of doing with an Audio-CD are:
>>
>>  * ripping it
>>  * playing it
>>  * copying it to another Audio-CD
>>
>> Ripping and playing have some "common" stuff that is:
>>  * Finding the CD drive that actually has a Audio-CD inside (if you have 
>> muliple drivers and others
>>are either empty or have data CDs)
>>  * Listing the number of tracks and their info (cddb, or whatever)
>>  * Extracting data to either feed it to the player or ripper
>>
>> So I think that having a library that those these 3 basic things is a good 
>> thing, once we have it we
>> can see how to make it used in kio-audiocd, kaudiocreator, kscd or whatever 
>> cd apps we decide to have.
>>
>> I can't think of a "common" stuff between copying and and ripping/playing.
>
> So here's the situation:
>
> Ripping and playing have some commonality in them, in that they both
> need access to raw PCM data from the disc. Phonon seems to have pretty
> good playback support (I'll file bug reports for the bugs I've been
> mentioning) - so if you have an app that uses Phonon you've got
> support for playing back CDs. Let's not reinvent that wheel, but round
> it out if there are flat spots.
>
> Now information and ripping. KCDDB seems to be in pretty good shape
> (kdelibs4 though) - for getting data about the CD from CDDB servers.
> Whatever work I've done for the libKCompactDisc nextgen branch, I can
> extract raw PCM data from the disc and also read CD-TEXT information
> to find whatever data is embedded in the disc.
>
> kaudiocreator seems to be using CDParanoia directly, as is
> audiocd-kio. I tried to start a basic port of audiocd-kio to kf5
> today, but audiocd-kio is also trying to do too much, because I've
> been looking through the code and it has converters for MP3, FLAC and
> OGG in it.
>
> What I would suggest is:
>
> 1: Let Phonon do the playing
> 2: Let k3b do the copying
> 3: Let Solid do all the disc detection
> 4: Consolidate libKCDDB and libKCompactDisc into an all-in-one
> disc-info and raw-data-from-CD library
> 5: Write a new, very small cdda kioslave that just exposes the audio
> files on the CD as a set of wav files. We can re-use code from the
> current audiocd-kio.
> 6: Once the new lib is up, port KAudioCreator to kf5.
>
> This plan of action will eventually end up removing a lot of lines of
> code and reducing our maintenance burden. Right now:
>
> * kaudiocreator and audiocd-kio both duplicate media conversion code.
> * both use cdparanoia, and do the same thing differently
> * all of them have their own disc detection code
>
> Inputs?
>
> Cheers,
> Boudhayan Gupta

Re: Cervisia?

[Jeremy Whiting]

Martin,

Michael Reeves reeves...@gmail.com mentioned he would be interested in
helping also, maybe the two of you can get it ported away from
Qt3Support, then ported to Qt5/Kf5 ?

thanks,
Jeremy

On Sat, Sep 26, 2015 at 3:55 PM, Martin Koller <kol...@aon.at> wrote:
> On Monday 14 September 2015 13:59:20 Jeremy Whiting wrote:
>> Well, it was released as part of Applications 15.08.0 (and will be in
>> the rest of the .x releases) I'm fine either way, but it seems like
>> continuing to release something that hasn't been looked at in quite
>> some time. I think to continue to release it we would need to have:
>>
>> 1) A port to Qt5/KF5 which could be difficult with Qt3Support stuff in
>> it, tricky but doable.
>> 2) A maintainer.
>>
>> Anyone want to try taking on one or both of those?
>
> As I still use cervisia daily, I can't let it go to /dev/null ...
> I started to port away from Q3 classes, so the next step to port to KF5 is 
> easier.
> No promises though, since my day job is demanding
>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> ()  ascii ribbon campaign - against html e-mail
> /\- against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Jeremy Whiting]

And to make sure you get concensus before releasing something that
uses or implements the interface.


On Fri, Sep 25, 2015 at 9:02 AM, Martin Klapetek
 wrote:
> On Fri, Sep 25, 2015 at 10:54 AM, Boudhayan Gupta  wrote:
>>
>>
>> In other *unrelated* news, I've woken up to certain disaster on the
>> dbus mailing list, so for now I'll move it to the org.kde namespace.
>
>
> It's not a disaster, people are just telling you "think the interface
> through
> and then propose it on a correct list (xdg), not on dbus list". Far from
> disaster :P
>
> Cheers
> --
> Martin Klapetek | KDE Developer

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Jeremy Whiting]

Hello,

On Thu, Sep 24, 2015 at 4:11 AM, Boudhayan Gupta  wrote:
> Hi all,
>
> Spectacle has been moved to KDE Graphics.
>
> There are a few things that need to be done for a smooth release with
> Applications 15.12. I'll list them below:
>
> 1. Inclusion into the list of applications released as part of KDE
> Applications. I believe I'll have to trouble Albert for that?

A mail to the release-team mailing list would be nice, but it's ok I
added spectacle to the list of modules for Applications 15.12.

> 2. Icon. I've filed a Breeze bug at
> https://bugs.kde.org/show_bug.cgi?id=353126 to symlink the ksnapshot
> icon to spectacle. Should I do the same for Oxygen?
>
> 3. KHotkeys. Once Spectacle is included into Applications 15.12, I'll
> patch KHotkeys to look for Spectacle rather than KSnapshot.
>
> Now, what'll come of KSnapshot? Spectacle clearly obsoletes KSnapshot
> on X11 (and Wayland as long as KWin is running - if a generic Wayland
> protocol isn't out by dependency freeze I'll add a generic KWin
> backend temporarily for this release). However, we have no Mac OS and
> Windows backends, so KSnapshot clearly still has use in those
> platforms.
>
> What about moving KSnapshot to Extragear?

If this is what we end up deciding it needs to be decided before Nov
11 which is the KDE Applications 15.12 dependency freeze date. Let us
know on the release team mailing list so we can remove it from the
list of modules if so.

thanks,
Jeremy

> Cheers,
> Boudhayan Gupta

KTabWidget vs QTabWidget

[Jeremy Whiting]

Hey all,

In looking into fixing the remaining issues in Okular's frameworks
branch I realized that in part of the effort to port it away from
KDELibs4Support it got some functionality removed. It was ported from
KTabWidget to QTabWidget but QTabWidget doesn't seem to support drag
and drop the way KTabWidget did. In looking at the KTabWidget
documentation on api.kde.org it still says that KTabWidget is
preferred over QTabWidget [1]. If that's the case why did it end up in
KDELibs4Support?

In reading Qt documentation about drag and drop [2] it seems that you
need to subclass widgets in order to specify any additional mime types
that should be handled by a drop event (which okular made use of so
you could drop documents on it's tab bar to open them). Without
KTabWidget we lose that feature completely unless we subclass
QTabWidget (which we have in KTabWidget... so why not just use it...).
Am I missing something? If not I suggest we reconsider and maybe
move/copy? KTabWidget into KF5::WidgetsAddons as it still provides
functionality we want/need in some cases. I'm not sure what would be
BC or SC in this case tbh (or maybe users of KTabWidget should just
keep using KDELibs4Support?)

BR,
Jeremy


1. 
http://api.kde.org/frameworks-api/frameworks5-apidocs/kdelibs4support/html/classKTabWidget.html
2. http://doc.qt.io/qt-5/dnd.html

Re: Review Request 125297: okular: Change Shell::openDocument parameter from QUrl to QString so it can be called via DBus

[Jeremy Whiting]

> On Sept. 17, 2015, 3:28 p.m., Thomas Lübking wrote:
> > a) fix the test?
> > b) the patch first limits to a Url subset and then guesses what it was ... 
> > if that is the "fix" it smell like okular or the test scenario cannot deal 
> > with remote files?

As I said in the description this isn't meant to fix the test, but to remove 
another warning. The warning states that openDocument is ignored because QUrl 
isn't a type registered with QtDBus. I agree and am not sure why this function 
was changed from taking a QString url over DBus to trying (and failing) to take 
a QUrl instead since QDBus doesn't know what QUrl even is.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125297/#review85590
---


On Sept. 17, 2015, 3:06 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125297/
> ---
> 
> (Updated Sept. 17, 2015, 3:06 p.m.)
> 
> 
> Review request for kdelibs and Albert Astals Cid.
> 
> 
> Repository: okular
> 
> 
> Description
> ---
> 
> When running the mainshelltest the tests that fail report being unable to 
> call openDocument because of it's QUrl parameter. With this it no longer 
> complains about that (but the tests still fail).
> 
> 
> Diffs
> -
> 
>   shell/okular_main.cpp 1c988d9 
>   shell/shell.h c16a0b2 
>   shell/shell.cpp d0204f9 
> 
> Diff: https://git.reviewboard.kde.org/r/125297/diff/
> 
> 
> Testing
> ---
> 
> Test no longer complains about being unable to call openDocument.
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

Re: Review Request 125297: okular: Change Shell::openDocument parameter from QUrl to QString so it can be called via DBus

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125297/
---

(Updated Sept. 17, 2015, 3:46 p.m.)


Review request for kdelibs and Albert Astals Cid.


Changes
---

Fixed issues pointed out by Thomas.


Repository: okular


Description
---

When running the mainshelltest the tests that fail report being unable to call 
openDocument because of it's QUrl parameter. With this it no longer complains 
about that (but the tests still fail).


Diffs (updated)
-

  shell/okular_main.cpp 1c988d9 
  shell/shell.h c16a0b2 
  shell/shell.cpp d0204f9 

Diff: https://git.reviewboard.kde.org/r/125297/diff/


Testing
---

Test no longer complains about being unable to call openDocument.


Thanks,

Jeremy Whiting

Re: Review Request 125297: okular: Change Shell::openDocument parameter from QUrl to QString so it can be called via DBus

[Jeremy Whiting]

> On Sept. 17, 2015, 4:17 p.m., Albert Astals Cid wrote:
> > shell/shell.cpp, line 99
> > <https://git.reviewboard.kde.org/r/125297/diff/3/?file=404615#file404615line99>
> >
> > I'd actually prefer if you fixed DnD as the fixme says instead of 
> > removing the feature.

Dragging and dropping of tabs is working fine with QTabBar as is.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125297/#review85593
---


On Sept. 17, 2015, 3:46 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125297/
> ---
> 
> (Updated Sept. 17, 2015, 3:46 p.m.)
> 
> 
> Review request for kdelibs and Albert Astals Cid.
> 
> 
> Repository: okular
> 
> 
> Description
> ---
> 
> When running the mainshelltest the tests that fail report being unable to 
> call openDocument because of it's QUrl parameter. With this it no longer 
> complains about that (but the tests still fail).
> 
> 
> Diffs
> -
> 
>   shell/okular_main.cpp 1c988d9 
>   shell/shell.h c16a0b2 
>   shell/shell.cpp d0204f9 
> 
> Diff: https://git.reviewboard.kde.org/r/125297/diff/
> 
> 
> Testing
> ---
> 
> Test no longer complains about being unable to call openDocument.
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

Review Request 125297: okular: Change Shell::openDocument parameter from QUrl to QString so it can be called via DBus

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125297/
---

Review request for kdelibs and Albert Astals Cid.


Repository: okular


Description
---

When running the mainshelltest the tests that fail report being unable to call 
openDocument because of it's QUrl parameter. With this it no longer complains 
about that (but the tests still fail).


Diffs
-

  shell/okular_main.cpp 1c988d9 
  shell/shell.h c16a0b2 
  shell/shell.cpp d0204f9 

Diff: https://git.reviewboard.kde.org/r/125297/diff/


Testing
---

Test no longer complains about being unable to call openDocument.


Thanks,

Jeremy Whiting

Re: Review Request 125297: okular: Change Shell::openDocument parameter from QUrl to QString so it can be called via DBus

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125297/
---

(Updated Sept. 17, 2015, 3:06 p.m.)


Review request for kdelibs and Albert Astals Cid.


Changes
---

Remove unused KTabWidget slots instead of commenting out the connect only.


Repository: okular


Description
---

When running the mainshelltest the tests that fail report being unable to call 
openDocument because of it's QUrl parameter. With this it no longer complains 
about that (but the tests still fail).


Diffs (updated)
-

  shell/okular_main.cpp 1c988d9 
  shell/shell.h c16a0b2 
  shell/shell.cpp d0204f9 

Diff: https://git.reviewboard.kde.org/r/125297/diff/


Testing
---

Test no longer complains about being unable to call openDocument.


Thanks,

Jeremy Whiting

Re: Review Request 125297: okular: Change Shell::openDocument parameter from QUrl to QString so it can be called via DBus

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125297/
---

(Updated Sept. 17, 2015, 4:58 p.m.)


Status
--

This change has been discarded.


Review request for kdelibs and Albert Astals Cid.


Repository: okular


Description
---

When running the mainshelltest the tests that fail report being unable to call 
openDocument because of it's QUrl parameter. With this it no longer complains 
about that (but the tests still fail).


Diffs
-

  shell/okular_main.cpp 1c988d9 
  shell/shell.h c16a0b2 
  shell/shell.cpp d0204f9 

Diff: https://git.reviewboard.kde.org/r/125297/diff/


Testing
---

Test no longer complains about being unable to call openDocument.


Thanks,

Jeremy Whiting

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

"I've let it there as a testimony of the dark side of wikis." <-- me
adds that to his quote book.

As a brand new user of KDE Connect if we had a user manual I would
look in it to see why for some reason the connection between KDE
Connect and my android phone who's name is "Jeremy's LG Phone" is for
some reason "Ige" or even better how to change it to something
meaningful.

BR,
Jeremy


On Tue, Sep 15, 2015 at 3:17 PM, Albert Astals Cid  wrote:
> El Dimarts, 15 de setembre de 2015, a les 08:01:44, Albert Vaca va escriure:
>> I don't think that having "descriptive documentation" (more about this
>> later) is that important nowadays, and IMO users will likely google for
>> help way before they use the help button when they find issues. Since most
>> people I talked to in Randa agreed with me on this, I'm a bit surprised to
>> find that you want to enforce this as a strong requirement.
>
> He doesn't want to enforce this as a strong requirement. It is just another of
> the requirement listed on our list of requirements.
>
>> IMO, the kind of documentation that users need is not a list of every
>> button in the KCM with a redundant description like the one we provide
>> (probably because most projects write it just to meet the requirement), but
>> instead answers to questions like "I see error X, what to do?". And this
>> kind of help is easier to find online, in wikis, forums, etc. than in the
>> static documentation we provide.
>
> People need both, documentation that drives them through the crucial/hard
> parts of the UI and support forums for when something goes wrong, they're not
> exclusive.
>
>> Leaving aside the utility of having docs, they are yet another moving piece
>> to maintain and likely to become outdated (eg: "Activity Settings" help
>> shows a screenshot from KDE 4), specially in a piece of software in change
>> like KDE Connect.
>
> What makes KDE Connect special?
>
>> To put an example of a similar case, Windows 10 completely removed the
>> "Help Center" and now it sends you online to the MS site if you need help.
>
> Meaning you're screwed if you don't have internet access \o/
>
>> Why don't we move our docs to the userbase wiki, and make it an open and
>> live thing that users can update (ala Arch Linux wiki)? If there are no
>> objections, I could start a page for KDE Connect there and make the help
>> button in the KCM link to it. Also, since right now we don't have any
>> numbers around how many poeple uses our help, moving it to the web would
>> give us some nice analytics around it for free.
>
> Because as well as the internet being awesome it also sucks, if you go to
> https://userbase.kde.org/Okular [1] we recommed removing ~/.cups/lpoptions if
> you have problems printing, sure it says "the file was corrupt", but how many
> of our users are able to diferentiate a corrupt lpoptions from a non corrupt
> one (i can't)?
>
> I've let it there as a testimony of the dark side of wikis.
>
> Cheers,
>   Albert
>
> [1] a page that has less content and is generally worse than
> https://okular.kde.org/ that i still don't understand why we need, but that's
> a discussion for a different day
>
>>
>> Albert
>

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

I see your points and actually agree. I'm completely ok with having
help go to some online documentation on userbase. I see the
requirement for offline/included help documentation to be going down
lately as you say and completely moot for kdeconnect since it
technically requires an internet connection anyway.

Thanks for explaining the reasoning.

BR,
Jeremy

On Tue, Sep 15, 2015 at 9:01 AM, Albert Vaca  wrote:
> I don't think that having "descriptive documentation" (more about this
> later) is that important nowadays, and IMO users will likely google for help
> way before they use the help button when they find issues. Since most people
> I talked to in Randa agreed with me on this, I'm a bit surprised to find
> that you want to enforce this as a strong requirement. I can of course write
> a few lines to meet this requirement, but I would like to start a discussion
> to re-think why we are doing this.
>
> IMO, the kind of documentation that users need is not a list of every button
> in the KCM with a redundant description like the one we provide (probably
> because most projects write it just to meet the requirement), but instead
> answers to questions like "I see error X, what to do?". And this kind of
> help is easier to find online, in wikis, forums, etc. than in the static
> documentation we provide.
>
> Leaving aside the utility of having docs, they are yet another moving piece
> to maintain and likely to become outdated (eg: "Activity Settings" help
> shows a screenshot from KDE 4), specially in a piece of software in change
> like KDE Connect.
>
> To put an example of a similar case, Windows 10 completely removed the "Help
> Center" and now it sends you online to the MS site if you need help.
>
> Why don't we move our docs to the userbase wiki, and make it an open and
> live thing that users can update (ala Arch Linux wiki)? If there are no
> objections, I could start a page for KDE Connect there and make the help
> button in the KCM link to it. Also, since right now we don't have any
> numbers around how many poeple uses our help, moving it to the web would
> give us some nice analytics around it for free.
>
> Albert

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

Aleix,

I disagree. I see the colors kcm has a manual, the icons kcm has a
manual, both accessible from the big "Help" button on the kcm in
systemsettings. kdeconnect's kcm has a Help button disabled because
there's no manual. While the ui is pretty intuitive, it would be good
to have something to show when users hit the "Help" button that says
what each option does at a minimum. It doesn't need to be much, but
something is better than nothing in my opinion.

BR,
Jeremy

On Mon, Sep 14, 2015 at 6:13 PM, Aleix Pol <aleix...@kde.org> wrote:
> On Mon, Sep 14, 2015 at 12:52 AM, Jeremy Whiting <jpwhit...@kde.org> wrote:
>> As shown here: http://developer.kde.org/~cfeck/portingstatus.html
>> (under Extragear base) It is missing a manual. Needs a Feature_summary
>> added to CMakeLists.txt and some .desktop files should be renamed to
>> org.kde.foo.desktop.
>>
>> I just tried it out and it seems to work here, though I'm not seeing
>> sms notifications in the desktop like I expected (I am able to control
>> cantata from my phone though, which is handy). Yes I installed the
>> beta on the play store.
>>
>> BR,
>> Jeremy
>>
>>
>> On Sat, Sep 12, 2015 at 6:29 AM, Albert Vaca <albertv...@gmail.com> wrote:
>>>> I moved the translations for both repositories. Please update the
>>>> translations
>>>> branches for kdeconnect-android so that trunk_kf5 is master and trunk is
>>>> none;
>>>> yes, it's android and it does not matter, but it's easier for us.
>>>
>>>
>>> Done.
>>>
>>>>
>>>> Translation branches for kdeconnect-kde are fine (translations moved few
>>>> months ago). In addition to master, we track also the 'kde4' branch. Do
>>>> you
>>>> plan to release additional versions from there, or can we drop that
>>>> branch?
>>>
>>>
>>> Removed kde4.
>>>
>
> Hi Jeremy,
> We just fixed the desktop naming issue and added the feature summary.
>
> Regarding the documentation, we discussed it briefly during the sprint
> and we have the feeling that the documentation for such a project
> would look more like a simple placeholder or something easily outdated
> than anything. Furthermore, since there isn't a clear main window of
> the application, it would be unintuitive to get there. We're convinced
> nobody would ever end up there.
>
> Aleix

Re: Cervisia?

[Jeremy Whiting]

Well, it was released as part of Applications 15.08.0 (and will be in
the rest of the .x releases) I'm fine either way, but it seems like
continuing to release something that hasn't been looked at in quite
some time. I think to continue to release it we would need to have:

1) A port to Qt5/KF5 which could be difficult with Qt3Support stuff in
it, tricky but doable.
2) A maintainer.

Anyone want to try taking on one or both of those?

thanks,
Jeremy


On Mon, Sep 14, 2015 at 1:48 PM, André Wöbbeking <woebbek...@kde.org> wrote:
> Hi,
>
> On Sunday 13 September 2015 16:31:55 Jeremy Whiting wrote:
>> Hey all,
>>
>> I think I may have found another cruft to move to unmaintained.
>> Cervisia is a gui for cvs. The last non trivial change to it was
>> around 2011 everything since has been preparing it for git migration,
>> bumping version, scripty, fix docbook issues, etc. It hasn't been
>> ported to Qt5/KF5 obviously. Should we kill it? If anyone objects let
>> me know this week sometime, otherwise it will join unmaintained.
>
> I'm, well was a developer of Cervisia and when Christian stepped down as
> maintainer I tried to take care of bugs. But for some years now I've less time
> due to real life.
>
> Of course I thought about porting to Qt5 but Cervisia still uses Qt3 classes
> (well, even Qt2 :-) and nowadays cvs isn't used that much any more. So it's
> probably time to let it rest in 4.14 or to move it to unmaintained.
>
>
> Cheers,
> André

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

As shown here: http://developer.kde.org/~cfeck/portingstatus.html
(under Extragear base) It is missing a manual. Needs a Feature_summary
added to CMakeLists.txt and some .desktop files should be renamed to
org.kde.foo.desktop.

I just tried it out and it seems to work here, though I'm not seeing
sms notifications in the desktop like I expected (I am able to control
cantata from my phone though, which is handy). Yes I installed the
beta on the play store.

BR,
Jeremy


On Sat, Sep 12, 2015 at 6:29 AM, Albert Vaca  wrote:
>> I moved the translations for both repositories. Please update the
>> translations
>> branches for kdeconnect-android so that trunk_kf5 is master and trunk is
>> none;
>> yes, it's android and it does not matter, but it's easier for us.
>
>
> Done.
>
>>
>> Translation branches for kdeconnect-kde are fine (translations moved few
>> months ago). In addition to master, we track also the 'kde4' branch. Do
>> you
>> plan to release additional versions from there, or can we drop that
>> branch?
>
>
> Removed kde4.
>

Cervisia?

[Jeremy Whiting]

Hey all,

I think I may have found another cruft to move to unmaintained.
Cervisia is a gui for cvs. The last non trivial change to it was
around 2011 everything since has been preparing it for git migration,
bumping version, scripty, fix docbook issues, etc. It hasn't been
ported to Qt5/KF5 obviously. Should we kill it? If anyone objects let
me know this week sometime, otherwise it will join unmaintained.

thanks,
Jeremy

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

+1 here too.

On Thu, Sep 10, 2015 at 3:39 AM, Albert Vaca  wrote:
> +kde-core-devel
>
> Hi,
>
> With the latest changes we are making to KDE Connect as part of the sprint
> in Randa, I think that the project is becoming mature enough to be moved out
> of playground. Not only that, but Kubuntu and other distros are already
> installing KDE Connect by default, regardless of it being in playground.
>
> I think that extragear/network is the best place for KDE Connect to be in,
> as we don't want to be tied to external release schedules for now.
>
> Any thoughts?
>
> Albert
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

Re: Adding further modules to api.kde.org

[Jeremy Whiting]

Martin,

I took a look at this as part of the gardening documentation websites,
but I didn't get very far. The code that runs this and ebn is in
kde:websites/quality-kde-org and is pretty outdated unfortunately.
Actually now that Allen Winter is back maybe he could add it (Added
him to cc)? What I tried here during gardening which I couldn't get to
work locally was:

1. Install it (I had some trouble with the perl based installer
putting files in different places than expected, maybe perl itself
changed over the years?)
2. Once I manually copied some files to places where they were
expected I couldn't figure out how to manually run the doc generator,
the --help documentation mentioned what arguments to use, but it
wasn't obvious what I should put for my Qt documentation paths and
such somehow, so I didn't try anything further.

It would be awesome to have what used to be in KDE SC on api.kde.org
again. We have many libraries that aren't frameworks that are Qt5/KF5
based which would be good to show on there imo.

BR,
Jeremy

On Thu, Sep 10, 2015 at 2:57 AM, Martin Graesslin  wrote:
> Hi all,
>
> back in KDE4 days the workspace libraries were listed on api.kde.org [1]. But
> for the current version we don't have any API docs available. The section
> "Other KDE Software" [2] lists KDE Support, KDE Extragear and Playground but
> apparently nothing from what used to be KDE SC.
>
> Does anybody know how I can get our KDE Workspaces listed there again? I'm in
> particular interested in getting KWayland API documentation published.
>
> If nobody knows: does anyone know who needs to be poked.
>
> Cheers
> Martin
>
> [1] http://api.kde.org/4.x-api/kde-workspace-apidocs/
> [2] http://api.kde.org/other.php

Re: Adding further modules to api.kde.org

[Jeremy Whiting]

Well, it's not even just about workspace, we had in kde4 times kdeedu,
kdegames, etc. etc. all on api.kde.org. Not all of it was api per se
(I don't know anyone that would want to read the apidocs for kanagram
for example, except to know how it's internals work or used to work
when hacking on it). Currently we only show frameworks and other. This
misses a lot of useful documentation, nothing is there about
libkomparediff2, libkeduvocdocument, libkdegames, etc. since those
aren't generated anymore for some reason.

A good idea that Ben suggested when the gardening project started was
having the apidocs generate on commit, rather than regenerating
everything every night at a specified time. A lot of the sources don't
actually change very often, so rebuilding part of the apidocs when the
code or it's doxygen comments change would make a lot of sense.

BR,
Jeremy

On Thu, Sep 10, 2015 at 11:05 AM, Adriaan de Groot <gr...@kde.org> wrote:
> On Thursday 10 September 2015 06:07:40 Jeremy Whiting wrote:
>> It would be awesome to have what used to be in KDE SC on api.kde.org
>> again. We have many libraries that aren't frameworks that are Qt5/KF5
>> based which would be good to show on there imo.
>
> Perhaps half of this is figuring out what actually constitutes the "Workspace
> API" that would be interesting here and how to subsequently pull information
> out of the metadata-services that we have (src-build? projects.kde.org? I
> don't know, I haven't followed very closely what lives where now).
>
>
>
> [ade] (who is now reminded that the original ebn domain is expiring and needs
> renewal, yeah)

Re: Adding further modules to api.kde.org

[Jeremy Whiting]

Allen,

Those are both KDE4 versions of workspace stuff. I don't see any place
where kf5 versions are.

BR,
Jeremy

On Thu, Sep 10, 2015 at 1:50 PM, Allen Winter  wrote:
> On Thursday, September 10, 2015 10:57:10 AM Martin Graesslin wrote:
>> Hi all,
>>
>> back in KDE4 days the workspace libraries were listed on api.kde.org [1]. But
>> for the current version we don't have any API docs available. The section
>> "Other KDE Software" [2] lists KDE Support, KDE Extragear and Playground but
>> apparently nothing from what used to be KDE SC.
>>
>> Does anybody know how I can get our KDE Workspaces listed there again? I'm in
>> particular interested in getting KWayland API documentation published.
>>
>> If nobody knows: does anyone know who needs to be poked.
>>
>
> http://api.kde.org/4.x-api/workspace-apidocs/ exists
> The KDE SC stuff is shown under "KDE4 Versions" 
> http://api.kde.org/history4.php
>
> I do notice that under the various KDE 4.foo tables we don't have a workspace 
> entry
> we have kde-workspace, but not workspace.  seems like kde-workspace and 
> workspace are similar.
>
> I'm not sure there's anything to fix.
>
> -Allen
>
>

Re: Porting to frameworks 3: Krfb

[Jeremy Whiting]

If anyone using kde-telepathy is interested I just reenabled the ktp
support in krfb frameworks branch (but I haven't set up ktp locally
yet to test).

BR,
Jeremy

On Sun, Sep 6, 2015 at 3:39 PM, Jeremy Whiting <jpwhit...@kde.org> wrote:
> Ah, another note. Sysadmin kindly created a phabricator board for this
> effort. [1] I've added some tasks to it already, but if you know of
> other tasks that need doing, please add them or take them and fix the
> issues from the tasks.
>
> thanks,
> Jeremy
>
> 1. https://phabricator.kde.org/tag/qt_5_porting/
>
> On Sun, Sep 6, 2015 at 3:37 PM, Jeremy Whiting <jpwhit...@kde.org> wrote:
>> Hey all,
>>
>> Third project I took what I thought would be a a quick stab at but
>> turned out to take a few hours over a couple of days. Krfb has a
>> frameworks branch that is using Qt5/KF5 libraries. It builds and runs
>> and I was able to vnc view my linux machine from another machine, but
>> probably could use some more love. Its desktop files probably need to
>> be changed to org.kde.krfb.desktop, it probably could use some help
>> porting away from KIcon and the rest of KDELibs4Support etc. Play with
>> it, build it, use it, report bugs, fix bugs, etc. etc. :)
>>
>> BR,
>> Jeremy

Re: Review Request 125010: konq-plugins: port kttsd plugin to QtSpeech

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125010/
---

(Updated Sept. 9, 2015, 2:19 p.m.)


Status
--

This change has been marked as submitted.


Review request for kdelibs and David Faure.


Changes
---

Submitted with commit 53a983ac73a001511ad4242e9e420d64e8551120 by Jeremy 
Whiting to branch frameworks.


Repository: kde-baseapps


Description
---

Ported kttsd plugin to QtSpeech.


Diffs
-

  konq-plugins/CMakeLists.txt 1d74e91 
  konq-plugins/kttsplugin/CMakeLists.txt 2faa7e6 
  konq-plugins/kttsplugin/Messages.sh 3c21b1c 
  konq-plugins/kttsplugin/khtmlkttsd.cpp c361321 
  konq-plugins/kttsplugin/khtmlkttsd.desktop cb0a4bd 
  konq-plugins/kttsplugin/khtmlkttsd.h 99bc848 
  konq-plugins/kttsplugin/khtmlkttsd.rc 75a2c49 
  konq-plugins/ttsplugin/CMakeLists.txt PRE-CREATION 
  konq-plugins/ttsplugin/Messages.sh PRE-CREATION 
  konq-plugins/ttsplugin/khtmltts.cpp PRE-CREATION 
  konq-plugins/ttsplugin/khtmltts.desktop PRE-CREATION 
  konq-plugins/ttsplugin/khtmltts.h PRE-CREATION 
  konq-plugins/ttsplugin/khtmltts.rc PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/125010/diff/


Testing
---

Builds, and works (wow I haven't ran konqueror in ages...)


Thanks,

Jeremy Whiting

Let's kill Jovie/KSpeech

[Jeremy Whiting]

Hey all,

As the subject says, I think it's time to retire/kill Jovie. It served
its purpose and has been replaced by QtSpeech (as optional
dependencies all over the place). As seen here [1] only one more place
that we release from for Applications 15.12 is left and I pushed a
change to konq-plugins today that ports it from KSpeech to QtSpeech,
so nothing is using KSpeech any longer except for the caveats listed
below.

A. Okular master branch is using KSpeech still, frameworks branch
isn't so Jovie can't die until okular's frameworks branch is merged to
master branch for release.
B. KDE-baseapps frameworks branch is using QtSpeech, but master branch
is still kdelibs4/KSpeech based. What is the timeframe for merging
kde-baseapps frameworks branch to master branch?

thanks,
Jeremy

1. http://lxr.kde.org/ident?_i=KSpeech&_remember=1

Re: Review Request 125010: konq-plugins: port kttsd plugin to QtSpeech

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125010/
---

(Updated Sept. 8, 2015, 9:42 a.m.)


Review request for kdelibs and David Faure.


Repository: kde-baseapps


Description
---

Ported kttsd plugin to QtSpeech.


Diffs (updated)
-

  konq-plugins/CMakeLists.txt 1d74e91 
  konq-plugins/kttsplugin/CMakeLists.txt 2faa7e6 
  konq-plugins/kttsplugin/Messages.sh 3c21b1c 
  konq-plugins/kttsplugin/khtmlkttsd.cpp c361321 
  konq-plugins/kttsplugin/khtmlkttsd.desktop cb0a4bd 
  konq-plugins/kttsplugin/khtmlkttsd.h 99bc848 
  konq-plugins/kttsplugin/khtmlkttsd.rc 75a2c49 
  konq-plugins/ttsplugin/CMakeLists.txt PRE-CREATION 
  konq-plugins/ttsplugin/Messages.sh PRE-CREATION 
  konq-plugins/ttsplugin/khtmltts.cpp PRE-CREATION 
  konq-plugins/ttsplugin/khtmltts.desktop PRE-CREATION 
  konq-plugins/ttsplugin/khtmltts.h PRE-CREATION 
  konq-plugins/ttsplugin/khtmltts.rc PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/125010/diff/


Testing
---

Builds, and works (wow I haven't ran konqueror in ages...)


Thanks,

Jeremy Whiting

Re: Review Request 125010: konq-plugins: port kttsd plugin to QtSpeech

[Jeremy Whiting]

> On Sept. 7, 2015, 1:37 a.m., David Faure wrote:
> > konq-plugins/CMakeLists.txt, line 21
> > <https://git.reviewboard.kde.org/r/125010/diff/1/?file=399825#file399825line21>
> >
> > using macro_log_feature would be better

Hmm, did macro_log_feature get replaced by something else? I can't seem to find 
it actually used in any kf5 based framework or application here somehow.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125010/#review84941
---


On Aug. 31, 2015, 8:23 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125010/
> ---
> 
> (Updated Aug. 31, 2015, 8:23 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> Ported kttsd plugin to QtSpeech.
> 
> 
> Diffs
> -
> 
>   konq-plugins/CMakeLists.txt 1d74e91 
>   konq-plugins/kttsplugin/CMakeLists.txt 2faa7e6 
>   konq-plugins/kttsplugin/Messages.sh 3c21b1c 
>   konq-plugins/kttsplugin/khtmlkttsd.cpp c361321 
>   konq-plugins/kttsplugin/khtmlkttsd.desktop cb0a4bd 
>   konq-plugins/kttsplugin/khtmlkttsd.h 99bc848 
>   konq-plugins/kttsplugin/khtmlkttsd.rc 75a2c49 
>   konq-plugins/ttsplugin/CMakeLists.txt PRE-CREATION 
>   konq-plugins/ttsplugin/Messages.sh PRE-CREATION 
>   konq-plugins/ttsplugin/khtmltts.cpp PRE-CREATION 
>   konq-plugins/ttsplugin/khtmltts.desktop PRE-CREATION 
>   konq-plugins/ttsplugin/khtmltts.h PRE-CREATION 
>   konq-plugins/ttsplugin/khtmltts.rc PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125010/diff/
> 
> 
> Testing
> ---
> 
> Builds, and works (wow I haven't ran konqueror in ages...)
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

Porting to frameworks 3: Krfb

[Jeremy Whiting]

Hey all,

Third project I took what I thought would be a a quick stab at but
turned out to take a few hours over a couple of days. Krfb has a
frameworks branch that is using Qt5/KF5 libraries. It builds and runs
and I was able to vnc view my linux machine from another machine, but
probably could use some more love. Its desktop files probably need to
be changed to org.kde.krfb.desktop, it probably could use some help
porting away from KIcon and the rest of KDELibs4Support etc. Play with
it, build it, use it, report bugs, fix bugs, etc. etc. :)

BR,
Jeremy

Re: Porting to frameworks 3: Krfb

[Jeremy Whiting]

Ah, another note. Sysadmin kindly created a phabricator board for this
effort. [1] I've added some tasks to it already, but if you know of
other tasks that need doing, please add them or take them and fix the
issues from the tasks.

thanks,
Jeremy

1. https://phabricator.kde.org/tag/qt_5_porting/

On Sun, Sep 6, 2015 at 3:37 PM, Jeremy Whiting <jpwhit...@kde.org> wrote:
> Hey all,
>
> Third project I took what I thought would be a a quick stab at but
> turned out to take a few hours over a couple of days. Krfb has a
> frameworks branch that is using Qt5/KF5 libraries. It builds and runs
> and I was able to vnc view my linux machine from another machine, but
> probably could use some more love. Its desktop files probably need to
> be changed to org.kde.krfb.desktop, it probably could use some help
> porting away from KIcon and the rest of KDELibs4Support etc. Play with
> it, build it, use it, report bugs, fix bugs, etc. etc. :)
>
> BR,
> Jeremy

Re: Review Request 125010: konq-plugins: port kttsd plugin to QtSpeech

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125010/#review84918
---


Ping? David, I see you're answering e-mail, so thought I'd bring this one back 
into your attention. It works well here, but a second opinion would be nice.

- Jeremy Whiting


On Aug. 31, 2015, 8:23 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125010/
> ---
> 
> (Updated Aug. 31, 2015, 8:23 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> Ported kttsd plugin to QtSpeech.
> 
> 
> Diffs
> -
> 
>   konq-plugins/CMakeLists.txt 1d74e91 
>   konq-plugins/kttsplugin/CMakeLists.txt 2faa7e6 
>   konq-plugins/kttsplugin/Messages.sh 3c21b1c 
>   konq-plugins/kttsplugin/khtmlkttsd.cpp c361321 
>   konq-plugins/kttsplugin/khtmlkttsd.desktop cb0a4bd 
>   konq-plugins/kttsplugin/khtmlkttsd.h 99bc848 
>   konq-plugins/kttsplugin/khtmlkttsd.rc 75a2c49 
>   konq-plugins/ttsplugin/CMakeLists.txt PRE-CREATION 
>   konq-plugins/ttsplugin/Messages.sh PRE-CREATION 
>   konq-plugins/ttsplugin/khtmltts.cpp PRE-CREATION 
>   konq-plugins/ttsplugin/khtmltts.desktop PRE-CREATION 
>   konq-plugins/ttsplugin/khtmltts.h PRE-CREATION 
>   konq-plugins/ttsplugin/khtmltts.rc PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125010/diff/
> 
> 
> Testing
> ---
> 
> Builds, and works (wow I haven't ran konqueror in ages...)
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

Re: Review Request 125043: expose the WheelMouseZooms global setting through the input ("mouse") KCM

[Jeremy Whiting]

> On Sept. 4, 2015, 7:38 a.m., Martin Gräßlin wrote:
> > You are aware that this is a dead repo and that this is a new feature for a 
> > repository that has been feature frozen for years?
> > 
> > Given that I think this should not and never be merged. If you want to keep 
> > the repo going for OSX I suggest to create a branch for your patches.
> 
> René J.V. Bertin wrote:
> As I wrote in the summary, I don't consider this so much a new feature as 
> a fix to an omission because the parameter is used in kdelibs (and possible 
> elsewhere I don't know about). Besides, this concerns a KCM that I think 
> should have been part of kde-runtime (but that's probably a moot point).
> 
> Also, this is not only about OS X. There are several distribution 
> releases that ship KDE4 as the default desktop officially supported LTS 
> version, and I'd hope they too would be interested in upstream fixes. As such 
> I don't see the point in creating another branch, or in maintaining a freeze 
> on a branch that isn't going to see any more releases
> A separate repository with only fixes, organised by project and possibly 
> target platform could make sense though.
> 
> Luigi Toscano wrote:
> I disagree: a separate branch makes definitely more sense than a separate 
> repository (which would lead more confusion and divide the code).
> 
> René J.V. Bertin wrote:
> In case it wasn't clear: I meant a separate repository containing only 
> patchfiles. The patch under consideration here is not specific to OS X so 
> wouldn't justify the creation of an OS X branch (I just haven't gotten around 
> to including it in my Kubuntu PPA yet).

I think what Martin and Luigi are suggesting is a branch maybe called LTS or 
something for feature improvements since master is frozen and has been for 
quite a long time.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125043/#review84821
---


On Sept. 4, 2015, 8:22 a.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125043/
> ---
> 
> (Updated Sept. 4, 2015, 8:22 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, kde-workspace and kdelibs.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> KDE4 has been providing a setting that (would have) allowed to avoid unwanted 
> text zooming during simulated inertial scrolling (scroll coasting). KDE PIM 
> applications were immune to that issue because certain KDELibs classes use 
> the parameter, which made it all the more annoying that other (e.g. 
> Kate-based) applications weren't. Sadly this setting wasn't published via a 
> GUI.
> 
> This patch adds a checkbox to the input ("mouse") KCM which seemed like the 
> most appropriate place if not only because it also makes sense to provide 
> this KCM on non-X11 platforms like OS X and MS Windows (where settings like 
> "double or single click" are relevant).
> 
> I consider this a fix of an omission bug, but I realise that it could also be 
> considered a new feature, so this RR is also intended to give some public 
> exposure to my patch rather than keeping it to myself.
> 
> 
> Diffs
> -
> 
>   kcontrol/input/kmousedlg.ui b48a606 
>   kcontrol/input/mouse.h d926a99 
>   kcontrol/input/mouse.cpp cebb174 
> 
> Diff: https://git.reviewboard.kde.org/r/125043/diff/
> 
> 
> Testing
> ---
> 
> For now only on OS X with kdelibs 4.14.11 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Porting to frameworks 2: libkcompactdisc

[Jeremy Whiting]

Hey all,

Second project I took a quick stab at libkcompactdisc which
audiocd-kio will need (which amarok will need for playing audio cds
once it's ported to qt5/kf5 too). I pushed to a frameworks branch and
it builds, but the resulting library is called
libkcompactdisc.so.SOVERSION. I guess we need to set a specific
version for this library, probably bumped from what the old
qt4/kdelibs4 version was?

This seems to be a pretty small library that would be a good fit for
anyone that wants to get started maintaining something useful but not
very complex. Any takers?

BR,
Jeremy

Re: Porting to frameworks 2: libkcompactdisc

[Jeremy Whiting]

Boudhayan,

Welcome.

On Thu, Sep 3, 2015 at 4:43 PM, Boudhayan Gupta <bgu...@kde.org> wrote:
> Hi Jeremy,
>
> On 4 September 2015 at 03:19, Jeremy Whiting <jpwhit...@kde.org> wrote:
>> This seems to be a pretty small library that would be a good fit for
>> anyone that wants to get started maintaining something useful but not
>> very complex. Any takers?
>
> I'd like to get my feet wet in maintaining a project that I did not
> code from scratch. I'd like to volunteer for this, but only if it's
> fine if I make minor booboos along the way (of course I'll fix them
> once someone gives me a heads up where I've gone wrong :-))

Yep, KDE is a community. If something gets broken you'll find out
about it one way or another :)
>
> I did take a look at the code, it's not too overwhelming for me to get
> up to speed with. I don't have any imaginative ideas for this library
> though, so if anyone has grand plans for this, they should take up
> maintainership instead, not me.

Please do. If someone else has big plans for it they can come along
and help too.

BR,
Jeremy

>
> Cheers,
> Boudhayan

Review Request 125010: konq-plugins: port kttsd plugin to QtSpeech

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125010/
---

Review request for kdelibs and David Faure.


Repository: kde-baseapps


Description
---

Ported kttsd plugin to QtSpeech.


Diffs
-

  konq-plugins/CMakeLists.txt 1d74e91 
  konq-plugins/kttsplugin/CMakeLists.txt 2faa7e6 
  konq-plugins/kttsplugin/Messages.sh 3c21b1c 
  konq-plugins/kttsplugin/khtmlkttsd.cpp c361321 
  konq-plugins/kttsplugin/khtmlkttsd.desktop cb0a4bd 
  konq-plugins/kttsplugin/khtmlkttsd.h 99bc848 
  konq-plugins/kttsplugin/khtmlkttsd.rc 75a2c49 
  konq-plugins/ttsplugin/CMakeLists.txt PRE-CREATION 
  konq-plugins/ttsplugin/Messages.sh PRE-CREATION 
  konq-plugins/ttsplugin/khtmltts.cpp PRE-CREATION 
  konq-plugins/ttsplugin/khtmltts.desktop PRE-CREATION 
  konq-plugins/ttsplugin/khtmltts.h PRE-CREATION 
  konq-plugins/ttsplugin/khtmltts.rc PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/125010/diff/


Testing
---

Builds, and works (wow I haven't ran konqueror in ages...)


Thanks,

Jeremy Whiting

Re: Best-practise currently for testing internal parts of libs? *_TEST_EXPORT macro?

[Jeremy Whiting]

The way the knewstuff tests work is by linking the source files being
tested directly. For example the Entry test also links entry.cpp and
entry.h directly. This way it doesn't need to have Entry private
methods exported at all. This may or may not be the best way to do it
though, but has worked ok there and was the suggestion when I had the
same question when reenabling KNewStuff unit tests a year or so ago.

On Mon, Aug 31, 2015 at 6:41 AM, Friedrich W. H. Kossebau
 wrote:
> Hi,
>
> what approach is best-practise currently for testing internal parts of libs?
> E.g. by symbols (classes) are not exported by default?
>
> In Calligra we have code that uses XYZ_TEST_EXPORT macros for those symbols
> which should be only exported in test-enabled builds, e.g. by defining
> COMPILING_TESTS to true and having code in the export header like
>
> #ifdef COMPILING_TESTS
> #if defined _WIN32 || defined _WIN64
> # if defined(calligrasheetsodf_EXPORTS)
> #   define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_EXPORT
> #   else
> #   define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_IMPORT
> #   endif
> # else /* not windows */
> #   define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_EXPORT
> # endif
> #else /* not compiling tests */
> #   define CALLIGRA_SHEETS_ODF_TEST_EXPORT
> #endif
>
> But when switching to generated export headers, using cmake's
> generate_export_header macro, this seems no longer an option.
>
> Grepping for TEST_EXPORT on lxr.kde.org points that this seems an older
> approach which only might have survived in the island of Calligra :) when the
> rest of KDE world evolved to something else?
> So what are others doing?
>
> The only place lxr.kde.org pointed out to use the *TEST_EXPORT approach was
> grantlee, which simply creates a separate file with the define that then is
> appended to the file generated with generate_export_header:
> http://lxr.kde.org/source/grantlee/templates/lib/CMakeLists.txt
>
> Seems a working hack which we could copy. But not sure if this is the best way
> and if this should not be done more generically?
>
> Cheers
> Friedrich

Re: Bringing back rsibreak from unmaintained

[Jeremy Whiting]

Just rebuilt it. It seems to run ok. The config dialog does look a lot
cleaner. nice work. I'll report back if I hit any issues as it runs
and such.

On Sun, Aug 30, 2015 at 4:10 PM, Albert Astals Cid aa...@kde.org wrote:
 El Dimecres, 19 d'agost de 2015, a les 01:01:35, Jan Kundrát va escriure:
 On Wednesday, 19 August 2015 00:30:01 CEST, Albert Astals Cid wrote:
  These messages are not new, IMHO does not apply to this request of
  bringing
  back from unmaintiained ;)

 I agree that it's not a blocker of course, but you asked for feedback :).

  However, the worst thing is that the passive popup for tiny breaks
  doesn't
  appear to notice that I'm still moving my mouse. This is with KF5 and
  Plasma5 from git from very late July, on X11.
 
  Are you sure about that? You mean the countdown goes down even
  if you move the mouse?

 Yes, that's what I'm seeing. It's interesting that the idle tracking
 appears to work when nothing is displayed, i.e., during the normal mode,
 the app detects that I'm actively using my computer and starts tracking my
 activity and the taskbar icon (the violet pie) goes from 100% to 75% when I
 start typing something, and back to 100% violet after a short while of
 inactivity. It's just the attention grabber hey, stop working now which
 ignores my activity and continues the countdown as if I were idle.

 The countdown please relax for %1 second(s) just doesn't notice my mouse
 or keyboard activity. In addition, it's always shown as a passive pop-up
 even when I pick Simple Gray Effect as a notification effect during
 breaks.

 The configuration dialog itself was a bit weirdly worded, i've pushed some
 text changed and also removed some settings that where too much flexibility,
 that hopefully would make it easier to understand.

 Can you check again?

 Cheers,
   Albert


 Cheers,
 Jan

Porting to frameworks 1: Sweeper

[Jeremy Whiting]

Hey all,

I took a quick stab at porting Sweeper to frameworks today. It only
took a few minutes with the handy scripts in kde-dev-scripts. I
changed the CMakeLists.txt and how the docbook is installed and
changed it to use QStandardPaths. Pushed to frameworks branch.

TODO:

1. It looks like it could use a bit more help and the manual should be
updated to not list kde4-config --path=cache as how to find what it
will delete.
2. It was also using an icon from the kde theme for it's application
icon, I'm not sure how that should work with no more KDEDIRS, but if
someone knows a way to do that please do so the application has an
icon on windows and OS X.

Hopefully we can get this small but useful utility ported in time for
Applications 15.12.

BR,
Jeremy

Re: Review Request 124824: [OS X] FindKDE4Internal.cmake : reintroduce a cmake_minimum_required statement

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124824/#review84061
---

Ship it!


Ship It!

- Jeremy Whiting


On Aug. 19, 2015, 11:41 a.m., René J.V. Bertin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/124824/
 ---
 
 (Updated Aug. 19, 2015, 11:41 a.m.)
 
 
 Review request for KDE Software on Mac OS X and kdelibs.
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 The recent removal of the code block from FindKDE4Internal.cmake starting 
 with the `cmake_minimum_required` statement breaks configuring on OS X:
 
 ```
 -- The C compiler identification is AppleClang 6.0.0.657
 -- The CXX compiler identification is AppleClang 6.0.0.657
 -- Check for working C compiler: 
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
 -- Check for working C compiler: 
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
  -- works
 -- Detecting C compiler ABI info
 -- Detecting C compiler ABI info - done
 -- Detecting C compile features
 -- Detecting C compile features - done
 -- Check for working CXX compiler: 
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
 -- Check for working CXX compiler: 
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
  -- works
 -- Detecting CXX compiler ABI info
 -- Detecting CXX compiler ABI info - done
 -- Detecting CXX compile features
 -- Detecting CXX compile features - done
 -- Looking for Q_WS_X11
 -- Looking for Q_WS_X11 - not found
 -- Looking for Q_WS_WIN
 -- Looking for Q_WS_WIN - not found
 -- Looking for Q_WS_QWS
 -- Looking for Q_WS_QWS - not found
 -- Looking for Q_WS_MAC
 -- Looking for Q_WS_MAC - found
 -- Looking for QT_MAC_USE_COCOA
 -- Looking for QT_MAC_USE_COCOA - found
 -- Found Qt-Version 4.8.7 (using /opt/local/libexec/qt4/bin/qmake)
 -- Looking for include file pthread.h
 -- Looking for include file pthread.h - found
 -- Looking for pthread_create
 -- Looking for pthread_create - found
 -- Found Threads: TRUE  
 CMake Error at /opt/local/share/cmake-3.2/Modules/FindPkgConfig.cmake:112 
 (elseif):
   given arguments:
 
 VERSION_LESS 3.1
 
   Unknown arguments specified
 Call Stack (most recent call first):
   /opt/local/share/cmake-3.2/Modules/FindPkgConfig.cmake:501 
 (_pkgconfig_parse_options)
   /opt/local/share/cmake-3.2/Modules/FindOpenSSL.cmake:43 (pkg_check_modules)
   /opt/local/share/apps/cmake/modules/Qt4ConfigDependentSettings.cmake:224 
 (FIND_PACKAGE)
   /opt/local/share/apps/cmake/modules/FindQt4.cmake:1207 (INCLUDE)
   /opt/local/share/apps/cmake/modules/FindKDE4Internal.cmake:425 
 (find_package)
   /opt/local/share/cmake-3.2/Modules/FindKDE4.cmake:108 (find_package)
   CMakeLists.txt:4 (find_package)
 
 
 -- Configuring incomplete, errors occurred!
 ```
 
 The attached patch is the minimum reintroduction of the removed code that 
 allows the cmake procedure to conclude successfully.
 
 CMake experts might be aware of other ways to address this issue more in line 
 with the reason the block was removed.
 
 
 Diffs
 -
 
   cmake/modules/FindKDE4Internal.cmake 7d54b9b 
 
 Diff: https://git.reviewboard.kde.org/r/124824/diff/
 
 
 Testing
 ---
 
 On OS X 10.9.5 with KDELibs 4.14.11 (v4.14.10-20-g150d983) and CMake 3.2.2 .
 
 The unmodified code from v4.14.10-20-g150d983 is fine on Linux with cmake 
 3.0.1 .
 
 
 Thanks,
 
 René J.V. Bertin
 

Re: Bringing back rsibreak from unmaintained

[Jeremy Whiting]

That surprises me. It worked fine here as I've been testing it with
everything else built on master.

On Tue, Aug 18, 2015 at 4:30 PM, Albert Astals Cid aa...@kde.org wrote:
 El Dimarts, 18 d'agost de 2015, a les 19:06:22, Jan Kundrát va escriure:
 On Monday, 17 August 2015 20:04:04 CEST, Albert Astals Cid wrote:
  Other comments?

 Nice, happy to see it -- it builds here, with a bunch of warnings:

 [2/29] Generating index.cache.bz2
 index.docbook:2: element para: validity error : ID gnu-fdl already defined
 element div: validity error : ID header already defined
 element div: validity error : ID header_content already defined
 element div: validity error : ID header_left already defined
 element div: validity error : ID header_right already defined
 element div: validity error : ID header already defined
 element div: validity error : ID header_content already defined
 element div: validity error : ID header_left already defined
 element div: validity error : ID header_right already defined
 element div: validity error : ID footer already defined
 element div: validity error : ID footer_text already defined
 element div: validity error : ID header already defined
 element div: validity error : ID header_content already defined
 element div: validity error : ID header_left already defined
 element div: validity error : ID header_right already defined
 element div: validity error : ID footer already defined
 element div: validity error : ID footer_text already defined
 element div: validity error : ID header already defined
 element div: validity error : ID header_content already defined
 element div: validity error : ID header_left already defined
 element div: validity error : ID header_right already defined
 element div: validity error : ID footer already defined
 element div: validity error : ID footer_text already defined
 element div: validity error : ID header already defined
 element div: validity error : ID header_content already defined
 element div: validity error : ID header_left already defined
 element div: validity error : ID header_right already defined
 element div: validity error : ID footer already defined
 element div: validity error : ID footer_text already defined
 element div: validity error : ID footer already defined
 element div: validity error : ID footer_text already defined

 Same warning every single KDE app gives you when building the docbook.


 The stderr is full of output which probably just wastes space. I don't
 think that these are good default settings:

 ** resetAfterTinyBreak !!
 ** resetAfterBigBreak !!
 ** resetAfterTinyBreak !!
 ** resetAfterTinyBreak !!

 These messages are not new, IMHO does not apply to this request of bringing
 back from unmaintiained ;)

 Besides this is supposed to be auto-run so it's not like you'll see that.

 However, the worst thing is that the passive popup for tiny breaks doesn't
 appear to notice that I'm still moving my mouse. This is with KF5 and
 Plasma5 from git from very late July, on X11.

 Are you sure about that? You mean the countdown goes down even if you move the
 mouse?

 Cheers,
   Albert


 Cheers,
 Jan

Re: Bringing back rsibreak from unmaintained

[Jeremy Whiting]

Builds and runs fine here. I say +1

On Mon, Aug 17, 2015 at 12:04 PM, Albert Astals Cid aa...@kde.org wrote:
 Hi guys, i just merged the frameworks port of rsibreak to master.

 rsibreak is in the unmaintained silo, i'd like to bring it back to extragear-
 utils (i guess kdeutils is too much for this niche app?).

 Anyone wants to review it?

 Other comments?

 Cheers,
   Albert

Re: Review Request 123881: Add KONSOLEPRIVATE_EXPORT to HistoryScroll since it's hasScroll method is needed.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123881/
---

(Updated Aug. 8, 2015, 1:50 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Base Apps and Konsole.


Changes
---

Submitted with commit 5f58169ba6fb18887b0e98aa390496df6fe8f242 by Kurt 
Hindenburg to branch master.


Repository: konsole


Description
---

Without this HistoryTest fails to link here.


Diffs
-

  src/History.h 6314ef993a329b3a7b52b5e43aeacafaf4d896de 

Diff: https://git.reviewboard.kde.org/r/123881/diff/


Testing
---


Thanks,

Jeremy Whiting

Re: Moving akonadi from kdesupport and akonadi-search from playground

[Jeremy Whiting]

+1 move it please.

On Fri, Jul 24, 2015 at 2:29 AM, laurent Montel mon...@kde.org wrote:
 Le Tuesday 21 July 2015, 13:52:01 Daniel Vrátil a écrit :
 On Monday, July 20, 2015 04:17:16 PM Daniel Vrátil wrote:
  Hi all,
 
  we (the KDE PIM team) kinda screwed up when we forgot to communicate our
  intentions about
  next KDE PIM release with the release team and we ended up in a
  situation that we have
  some repositories in modules from which they cannot be released as part
  of KDE Applications,
  so releasing KF5-based KDE PIM as part of KDE Applications is currently
  endangered.
 
  Normally I'd have to ask for the 2-week review period before moving the
  repos but since we are
  under a big time pressure and because the modules have both proven
  themselves (see below),
  I kindly ask for those repositories to be granted an exception to the
  review period and they
  can be moved right away.
 
  akonadi-search repository contains PIM-specific code that originally
  lived in Baloo repository
  and was split out when Baloo switched to KF5. We only ported the code to
  KF5 and removed all
  mentions of Baloo from code (it's now Akonadi::Search namespace).
  Technically this code
  already went through review when Baloo has been reviewed for move from
  playground, and also
  during Baloo development, and has been actively used with KDE PIM 4.x
  for several releases.
 
  akonadi I think has proven itself well enough in during the years :)
 
  I'd like to move both repositories to kde/pim module where other KDE PIM
  repos (mostly those
  split from kdepimlibs) currently live.
 
  If that's fine with everyone I'd request the move ASAP.

 Hi all,

 if there are no objections, I'll request the repos to be move later in the
 afternoon.

 I spoke with Dan. He told me that Ben waited more feedback from kde dev about
 it.

 He kde-code-dev guys could you give us more feedback please ?

 It urges because Albert waits this moving for creating 15.08.
 For the moment it's postponed.

 Thanks
 Regards

 Thanks,
 Dan

  Cheers,
  Daniel

 --
 Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer
 KDAB (France) S.A.S., a KDAB Group company
 Tel. France +33 (0)4 90 84 08 53,  http://www.kdab.fr

Re: Reviving Kaffeine

[Jeremy Whiting]

If it's unmaintained and previous maintainer isn't responding go for
it. If you can get others interested in it enough to do review of your
updates, even better.

On Mon, Jul 20, 2015 at 12:01 AM, Lasse Lindqvist
lasse.k.lindqv...@gmail.com wrote:
 I was thinking about reviving Kaffeine, but the previous developer hasn't
 responded to me. The projects irc channel and sites are dead, too.

 I was hoping someone here might be able to help me on this.

 Lasse Lindqvist

Re: Review Request 124163: Use KIO::Overwrite when saving a changed file otherwise it always fails.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124163/
---

(Updated July 10, 2015, 5 p.m.)


Status
--

This change has been marked as submitted.


Review request for kdelibs and Kevin Kofler.


Changes
---

Submitted with commit 3cffb9abc3d0c0fd3c861f65cc7738fbe7568b54 by Jeremy 
Whiting to branch master.


Bugs: 347760
http://bugs.kde.org/show_bug.cgi?id=347760


Repository: libkomparediff2


Description
---

As the summary says use KIO::Overwrite when saving files.
BUG:347760


Diffs
-

  komparemodellist.cpp 32242777411ddb8549154a6f2ef0fbc9fff7a239 

Diff: https://git.reviewboard.kde.org/r/124163/diff/


Testing
---

Kompare now correctly saves the destination file when comparing and making 
changes.


Thanks,

Jeremy Whiting

Review Request 124163: Use KIO::Overwrite when saving a changed file otherwise it always fails.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124163/
---

Review request for kdelibs and Kevin Kofler.


Bugs: 347760
http://bugs.kde.org/show_bug.cgi?id=347760


Repository: libkomparediff2


Description
---

As the summary says use KIO::Overwrite when saving files.
BUG:347760


Diffs
-

  komparemodellist.cpp 32242777411ddb8549154a6f2ef0fbc9fff7a239 

Diff: https://git.reviewboard.kde.org/r/124163/diff/


Testing
---

Kompare now correctly saves the destination file when comparing and making 
changes.


Thanks,

Jeremy Whiting

Re: building kio on Mac

[Jeremy Whiting]

Alex's memory is correct. We can solve this in one of two ways:

1) Patching Qt's QStandardPaths, we tried that and it didn't seem to
get anywhere.
2) Using Qt's QstandardPaths when we build and install KDE software.
This is the approach I've taken locally and seems to work. I think
this is what is being done on the CI system also. The idea is to put
data files in either /Library/Application Support/foo or
$HOME/Library/Application Support/foo. Locally I'm using
/Users/jeremy/Library/Application Support by adding
-DKDE_INSTALL_DATADIR=/Users/jeremy/Library/Application Support

in the cmake-options in my .kdesrc-buildrc file.

One of the reasons I'm not installing into /Library/Application
Support is to not require sudo. I believe macports itself has policies
of not installing to either of these paths though, so it's not a
proper solution for macports I guess.

BR,
Jeremy


On Sat, Jun 6, 2015 at 10:15 AM, Allen Winter win...@kde.org wrote:
 On Saturday, June 06, 2015 10:41:48 AM Alex Merry wrote:
 On Wednesday 27 May 2015 06:56:29 Allen Winter wrote:
  On Tuesday, May 26, 2015 09:12:13 AM Scarlett Clark wrote:
   On Tuesday, May 26, 2015 12:06:22 PM Allen Winter wrote:
% kdesrc-build kio
Could not locate file kf5/kdoctools/customization in
(/Users/allenwinter/Library/Application Support, 
/Library/Application
Support) Could not locate file kf5/kdoctools/customization in
(/Users/allenwinter/Library/Application Support, 
/Library/Application
Support) Error: Could not find kdoctools catalogs
   
kdesrc-build kdoctools succeeded though.
I recall this was a QStandardPaths thing. but I forgot the trick to
solving.
   
help.
  
   -DCMAKE_INSTALL_BUNDLEDIR={instPrefix}/Applications/KF5 -
   DDATA_INSTALL_DIR={instPrefix}/Library/Application Support
 
  Why can't we put these settings in the top-level buildsystem?

 IIRC, there was some disagreement over the correct approach to take, both on
 OSX and Windows (installing to the operating system's idea of where various
 files should go vs patching Qt to allow for environment variables to put them
 in other places). I think the outcome of that was that KDEers generally
 preferred the patching Qt route, but Qt didn't want to take that upstream.

 Too bad  Qt didn't want the upstream fix.
 And I suppose we aren't interesting in resurrecting KStandardDirs either.
 rock vs. hard-place. neither side will yield

 Now, KDEInstallDirs currently sets KDE_INSTALL_BUNDLEDIR (which is the same 
 as
 CMAKE_INSTALL_BUNDLEDIR) to /Applications/KDE, but sets KDE_INSTALL_DATADIR
 (which is the same as DATA_INSTALL_DIR) to ${CMAKE_INSTALL_PREFIX}/share. 
 We
 could adjust those on OSX, but I don't know what would be the most useful
 settings. does $prefix/Applications or $prefix/Library make sense if $prefix
 is not / or $HOME? How do we deal with developers who just want to put
 something locally in their home dir vs proper installations? I don't know a
 whole lot about OSX software installation, so I'm not best placed to make
 these decisions.

 I recall we decided a while back that $HOME was not the right approach on OSX.
 I don't recall if the same was decided for Windows.

 jpwhiting: you had this all figured out, didn't you?

Re: QIcon::fromTheme

[Jeremy Whiting]

Ok, that explains why it doesn't work on the kubuntu machine where
I've got breeze and such from packages. But why does it not work on
arch where all my icon themes are coming from kdesrc-build and are all
in /usr/local/share/icons ? I'm using breeze-dark or breeze, and both
are in /usr/local/share/icons here, so why doesn't it grab the hicolor
fallback theme icons from /usr/local/share/icons/hicolor when using
/usr/local/share/icons/breeze or breeze-dark ?

BR,
Jeremy


On Sat, May 23, 2015 at 9:38 PM, Albert Astals Cid aa...@kde.org wrote:
 El Dissabte, 23 de maig de 2015, a les 19:45:57, Jeremy Whiting va escriure:
 Hello all,

 I'm confused about how QIcon::fromTheme works (or maybe how it's
 supposed to work?) I've got Kmouth frameworks branch built and
 installed into /usr/local on two different machines. In both cases it
 installs phrase.png and phrasebook.png icons into
 /usr/local/share/icons/hicolor/XxY/actions and XDG_DATA_DIRS is set so
 QIcon::themeSearchPaths is giving /usr/local/share as one of the paths
 it is searching. Yet QIcon::fromTheme(QLatin1String(phrase)) gives
 no icon unless I copy the icon from
 /usr/local/share/icons/hicolor/32x32/actions/ to
 /usr/share/icons/hicolor/32x32/actions. I looked a bit in qicon.cpp
 itself to see how it's doing that. and it's using some QIconEngine. Is
 that creating an instance of our KIconEngine because the
 frameworkintegration platformtheme gives that for it's
 createIconEngine method? Is this a bug in KIconEngine itself that it's
  not searching the XDG paths specified by the icon spec? Any hints
 would be appreciated.

 Do you have a theme definition in /usr/local/share/icons/hicolor ? Probaby
 not, so when loading the icon from your theme (breeze, oxygen, whatever) that
 is most probably in /usr/share/icons/, why would the code fall back to a
 different hicolor theme?

 I understand what you want but i don't think icon themes work like that.

 Cheers,
   Albert


 thanks,
 Jeremy

Re: QIcon::fromTheme

[Jeremy Whiting]

Albert,

Strace was the key. It was looking for and not finding an index.theme
in the hicolor folder on both machines. After adding that (copied from
/usr/share/icons/hicolor) it works fine on both machines. Even the one
where my current icon theme is in a different prefix.

thanks,
Jeremy


On Sun, May 24, 2015 at 10:52 AM, Albert Astals Cid aa...@kde.org wrote:
 El Diumenge, 24 de maig de 2015, a les 05:24:10, Jeremy Whiting va escriure:
 Ok, that explains why it doesn't work on the kubuntu machine where
 I've got breeze and such from packages. But why does it not work on
 arch where all my icon themes are coming from kdesrc-build and are all
 in /usr/local/share/icons ? I'm using breeze-dark or breeze, and both
 are in /usr/local/share/icons here, so why doesn't it grab the hicolor
 fallback theme icons from /usr/local/share/icons/hicolor when using
 /usr/local/share/icons/breeze or breeze-dark ?

 I don't know, it is my understanding that it should work, have you straced it?

 Cheers,
   Albert


 BR,
 Jeremy

 On Sat, May 23, 2015 at 9:38 PM, Albert Astals Cid aa...@kde.org wrote:
  El Dissabte, 23 de maig de 2015, a les 19:45:57, Jeremy Whiting va
 escriure:
  Hello all,
 
  I'm confused about how QIcon::fromTheme works (or maybe how it's
  supposed to work?) I've got Kmouth frameworks branch built and
  installed into /usr/local on two different machines. In both cases it
  installs phrase.png and phrasebook.png icons into
  /usr/local/share/icons/hicolor/XxY/actions and XDG_DATA_DIRS is set so
  QIcon::themeSearchPaths is giving /usr/local/share as one of the paths
  it is searching. Yet QIcon::fromTheme(QLatin1String(phrase)) gives
  no icon unless I copy the icon from
  /usr/local/share/icons/hicolor/32x32/actions/ to
  /usr/share/icons/hicolor/32x32/actions. I looked a bit in qicon.cpp
  itself to see how it's doing that. and it's using some QIconEngine. Is
  that creating an instance of our KIconEngine because the
  frameworkintegration platformtheme gives that for it's
  createIconEngine method? Is this a bug in KIconEngine itself that it's
 
   not searching the XDG paths specified by the icon spec? Any hints
 
  would be appreciated.
 
  Do you have a theme definition in /usr/local/share/icons/hicolor ? Probaby
  not, so when loading the icon from your theme (breeze, oxygen, whatever)
  that is most probably in /usr/share/icons/, why would the code fall back
  to a different hicolor theme?
 
  I understand what you want but i don't think icon themes work like that.
 
  Cheers,
 
Albert
 
  thanks,
  Jeremy

Re: Review Request 123881: Add KONSOLEPRIVATE_EXPORT to HistoryScroll since it's hasScroll method is needed.

[Jeremy Whiting]

 On May 22, 2015, 6:23 p.m., Aleix Pol Gonzalez wrote:
  Hm..
  Builds here.
  Also builds in build.kde.org... 
  https://build.kde.org/job/konsole%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/2/
  
  :/

I'm not sure why, but I did test a few times before making this change. Could 
it be because I'm building with gcc 5.1 again?


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123881/#review80746
---


On May 22, 2015, 1:49 p.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123881/
 ---
 
 (Updated May 22, 2015, 1:49 p.m.)
 
 
 Review request for KDE Base Apps and Konsole.
 
 
 Repository: konsole
 
 
 Description
 ---
 
 Without this HistoryTest fails to link here.
 
 
 Diffs
 -
 
   src/History.h 6314ef993a329b3a7b52b5e43aeacafaf4d896de 
 
 Diff: https://git.reviewboard.kde.org/r/123881/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Jeremy Whiting
 

Review Request 123881: Add KONSOLEPRIVATE_EXPORT to HistoryScroll since it's hasScroll method is needed.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123881/
---

Review request for KDE Base Apps and Konsole.


Repository: konsole


Description
---

Without this HistoryTest fails to link here.


Diffs
-

  src/History.h 6314ef993a329b3a7b52b5e43aeacafaf4d896de 

Diff: https://git.reviewboard.kde.org/r/123881/diff/


Testing
---


Thanks,

Jeremy Whiting

Re: Distros and QtWebEngine

[Jeremy Whiting]

The thread subject is Deprecating modules with 5.5 on the qt development list.

On Tue, Apr 21, 2015 at 1:39 AM, Milian Wolff m...@milianw.de wrote:
 On Monday 20 April 2015 19:02:40 Lisandro Damián Nicanor Pérez Meyer wrote:
 Sorry Milian, i've sent it to your personal address by mistake.

 Resending to the list.

 On Monday 20 April 2015 23:02:35 you wrote:
 [snip]

  Have you notified the Qt WebEngine developers about this? I have not seen
  any email in that regard to the official upstream mailing list at
  qtwebengine@qt- project.org .

 Yes we have, but on the main devel mailing list, developm...@qt-project.org
 It has been troughly discussed, the thread is actually very long.

 When did this take place and what is the threads subject? I seem to have
 missed it, and also can't find it in my recent mails. Sorry for that.

 Thanks
 --
 Milian Wolff
 m...@milianw.de
 http://milianw.de

Re: Distros and QtWebEngine

[Jeremy Whiting]

Even simple applications may want to use a webview for stuff. Kanagram at
one point had a QtWebkit Web view just to show the wikipedia entry of the
current word. It was disabled because QtWebKit at the time was crashing.
I'd like to use something light and secure, but am not sure what options we
have going forward tbh.

On Mon, Apr 20, 2015 at 2:16 PM, Luigi Toscano luigi.tosc...@tiscali.it
wrote:

 Albert Astals Cid ha scritto:
  El Dilluns, 20 d'abril de 2015, a les 15:52:12, Lisandro Damián Nicanor
 Pérez
  Meyer va escriure:
 
  I could also say that Fedora+Debian+Debian derivatives (Ubuntu is
 mostly in
  the same position as us) is also a large userbase for KDE to loose.
 
  But *it's not really* about which distro or app is going to loose more
 user
  base, it's about keeping the current one. I don't want Debian nor KDE to
  loose users, in the same way I do not want to ship something that's
  unmaintainable.
 
  Maybe you guys should just trust the Qt project to maintain QtWebEngine
 and
  just run with what they provide instead of needing 3 people to
 maintain it
  yourselves?

 Qt project can maintain their bits, sure. Are they looking inside the big
 block, or do they import the core engine as it is? If the latter, well,
 it's
 not that simple as trusting them.


 
  What's wrong with that besides it going against your rules?

 The rules are there not because someone wants to have unhappy users; think
 about the rule about untangling tons of embedded libraries and patching
 issues.

 
  That you need to provide longer maintaince times than what Qt upstream
  provides?
 
  Just state that there's no such long maintaince time for that package or
 just
  install the newer version of Qt. And yes again that probably goes
 against your
  rules, but it's your rules, so you can just improve them for everyone's
  benefit :)

 Even Firefox ended up providing an yearly stable release for make it
 easier,
 and it's not an hard dependency (and they don't even provide a stable API).


 That said, let's talk for a moment on real use cases: how many applications
 can need an *hard* dependency on the beast, apart from mail apps?

 Ciao
 --
 Luigi

Re: Distros and QtWebEngine

[Jeremy Whiting]

Yeah, that's probably a better idea. is there a QML ui for QTextview? or
maybe some other QML component that renders html.

On Mon, Apr 20, 2015 at 2:54 PM, Thomas Lübking thomas.luebk...@gmail.com
wrote:

 On Montag, 20. April 2015 22:31:24 CEST, Jeremy Whiting wrote:

 Even simple applications may want to use a webview for stuff. Kanagram at
 one point had a QtWebkit Web view just to show the wikipedia entry of the
 current word.


 Ouch, sounds like giant overhead =)
 Shouldn't the basic html subset support in QTextView provide anything for
 this? (in doubt: fetch the xml and htmlify that locally?)

 Cheers,
 Thomas

Re: Jenkins CI help for compile failures!

[Jeremy Whiting]

kspeech is deprecated, we need to remove it's use in knights looks like.
It's interface file never got released with kf5.

On Thu, Apr 9, 2015 at 12:29 PM, Scarlett Clark sgcl...@kubuntu.org wrote:

 KF5 knights fails to compile with:
 23:47:49 make[2]: *** No rule to make target
 '/srv/jenkins/install/ubuntu/x86_64/g++/kf5-

 qt5/frameworks/kdelibs4support/inst/share/dbus-1/interfaces/org.kde.KSpeech.xml',
 needed by 'src/kspeechinterface.cpp'.  Stop.
 23:47:49 make[2]: *** Waiting for unfinished jobs
 23:47:49 [ 26%] [ 28%] [ 30%] [ 32%] Generating ui_popup.h
 23:47:49 Generating ui_enginesettings.h
 23:47:49 Generating ui_customdifficultydialog.h
 23:47:49 Generating settings.h, settings.cpp
 23:47:49 CMakeFiles/Makefile2:107: recipe for target
 'src/CMakeFiles/knights.dir/all' failed
 23:47:49 make[1]: *** [src/CMakeFiles/knights.dir/all] Error 2
 23:47:49 Makefile:126: recipe for target 'all' failed
 23:47:49 make: *** [all] Error 2

 Thoughts? ideas?
 Thanks for your help,
 Scarlett

Re: Review Request 122268: emerge: Update mysql and ruby dependencies

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122268/
---

(Updated April 3, 2015, 1:34 p.m.)


Status
--

This change has been discarded.


Review request for kdelibs, kdewin, Nicolás Alvarez, and Patrick Spendrin.


Repository: emerge


Description
---

A fresh install with emerge fails to build qt because mysql and ruby dependency 
urls and versions are no longer hosted at the previously default urls. This 
updates both so they work at least for a 32 bit build.


Diffs
-

  portage/binary/mysql-pkg/mysql-pkg.py f532351 
  portage/dev-util/ruby/ruby.py fd4f084 

Diff: https://git.reviewboard.kde.org/r/122268/diff/


Testing
---

emerge qt works after this change.


Thanks,

Jeremy Whiting

frameworkintegration QFileDialog bug

[Jeremy Whiting]

Hey all,

We have a strange bug in frameworkintegration
https://bugs.kde.org/show_bug.cgi?id=334963 which really ought to get a
solution sooner than later. People using the latest and greatest packages
are hitting the issue https://bugs.kde.org/show_bug.cgi?id=344586 and more
will if it doesn't get fixed. I've done a bit of testing and it boils down
to this.

In KDEFileDialogHelper show we need to call m_dialog-show() whether the
dialog is modal or not. Currently we are only calling it if the dialog is
not modal.
Doing the above makes QDialog static methods somehow not interactive, I'm
still not sure why. https://paste.kde.org/pdv7wlxpd -- here's a backtrace
of running the Qt 5 standarddialogs test and clicking on one of the file
dialog tests. Interestingly, a backtrace of standarddialogs working with
frameworkintegration as it is in git currently is exactly the same, and is
interactive. Somehow moving the m_dialog-show() out of the if makes the
exec() call not interactive anymore.

Anyone have any idea what's going on here?

thanks,
Jeremy

Re: Changing the licence of parley's editor model classes from GPL to LGPL

[Jeremy Whiting]

A good idea is to check the relicense.pl script in kde-dev-scripts. It
contains a list of anyone who has authorized license changes on their code.
It lists Albert, myself, frederik at least as being ok with relicensing
from GPL to LGPL. I didn't go through the list of committers, but you can
check that against the names in that script and if everyone is in there, go
ahead. If not, e-mail directly the one(s) who aren't already listed to get
their ok. identity.kde.org will help map names to kde account names.

BR,
Jeremy

On Sun, Mar 15, 2015 at 5:44 AM, Albert Astals Cid aa...@kde.org wrote:

 El Diumenge, 15 de març de 2015, a les 15:17:30, Rahul Chowdhury va
 escriure:
  Hi,
 
  I, and Inge Wallin ( CC'ed in this email ),
  have been working on a project on moving
  the editor of parley into libkeduvocdocument.
  For that we have moved the model classes of
  parley's editor into keduvoc, and used them in
  the entire codebase of parley instead of the
  old model classes.
 
  But on doing so we have encountered a problem.
  The old model classes of parley are GPL'ed ,
  but the rest of the keduvoc classes are LGPL.
  I think it would be better if the rest of the model classes
  are also changed accordingly.
  We would like to hear your suggestions on the same.
 
  The branches of libkeduvocdocument and parley
  where the task is implemented has been put up
  on reviewboard, please find the links to them below
  if you want to take a look :-
  [1] https://git.reviewboard.kde.org/r/122877/
  [2] https://git.reviewboard.kde.org/r/122878/
 
  I have tried to get a list of all the people who
  have worked on the old model classes,
  and here is what I have come up with-
 
* Frederik Gladhorn
* Amarvir Singh
* Avgoustinos Kadis* Javier Goday* Daniel Laidig
* Andreas Xavier
* David Capel
* Christian Muschick
* Albert Astals Cid

 You'll have to get agreement from all of them to relicense.

 Since I'm on the list, it's fine for me.

 Cheers,
   Albert

 
 
  Thanks and Regards,
 
  Rahul Chowdhury
  ( rahulch in IRC )


  Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
 unsubscribe 

Re: Review Request 122784: Fix 404 result for all api calls.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122784/
---

(Updated March 5, 2015, 1:42 p.m.)


Status
--

This change has been marked as submitted.


Review request for Bodega, kdelibs, Aaron J. Seigo, and Marco Martin.


Repository: bodega-server


Description
---

Thanks to Johnathan for this fix.


Diffs
-

  server/app.js 76c6f101a29a907a7af465d9f402770d84ab0e01 

Diff: https://git.reviewboard.kde.org/r/122784/diff/


Testing
---

Tests still fail but the api calls are returning json data now.


Thanks,

Jeremy Whiting

Review Request 122784: Fix 404 result for all api calls.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122784/
---

Review request for Bodega, kdelibs, Aaron J. Seigo, and Marco Martin.


Repository: bodega-server


Description
---

Thanks to Johnathan for this fix.


Diffs
-

  server/app.js 76c6f101a29a907a7af465d9f402770d84ab0e01 

Diff: https://git.reviewboard.kde.org/r/122784/diff/


Testing
---

Tests still fail but the api calls are returning json data now.


Thanks,

Jeremy Whiting

Re: [KDE/Mac] Multiplatform frameworks

[Jeremy Whiting]

Ian,

I read that KDEInstallDirs documentation, and it seems it's a bit outdated
or at least not complete. If I change just -DKDE_INSTALL_DATADIR but
nothing else here. kdesrc-build is installing data (stuff that went under
$prefix/share) in ~/Library/Application Support but nothing else so far.
For example .desktop files for applications are currently in
/usr/local/share/applications and kservice5 stuff is still in
/usr/local/share/kservices5. Now after rereading that page it seems I
changed the DATA_INSTALL_DIR but not the DATAROOTDIR, and since I set it to
an absolute path it's installing those files correctly. I guess ultimately
we would need/want to change all those paths on OS X. In my test here I've
simply added -DKDE_INSTALL_DATADIR=/Users/jeremy/Library/Application
Support to the cmake options in my ~/.kdesrc-buildrc If there's somewhere
where default cmake arguments are set per platform maybe that would be
better to use and we can figure out the best places for all of these
various paths one at a time.

BR,
Jeremy

On Sun, Mar 1, 2015 at 7:30 PM, Ian Wadham iandw...@gmail.com wrote:

 Hi Jeremy,

 My apologies for going back to basics.  Some things you said earlier made
 me
 think we are not on the same page, but I now see that we are.

 On 02/03/2015, at 3:15 AM, Jeremy Whiting wrote:
 
  The example code you've given does already use prefixes. I'll explain
 below.
 
  On Sat, Feb 28, 2015 at 7:56 PM, Ian Wadham iandw...@gmail.com wrote:
 /snip
   Note that the code could have said '(QStandardPaths::DataLocation,
 arenas, '.  So no
   way for a kf5 suffix to get in there.  Maybe it comes from
 $XDG_DATA_DIRS (?).
 
  Correct, DataLocation (newly clarified as AppDataLocation) is where the
 application stores it's own files, so it's Application Support/appname In
 this case granatier (or whatever QApplication::setApplicationName is given
 in main.cpp.
 
   Also, there would be several shared data folders in
 GenericDataLocation, alongside
   the DataLocation folders for the apps.  See [2] for details.  These
 would fit in quite well
   with standard paths on Apple OS X set to:
  
~/Library/Application Support/subdir, /Library/Application
 Support/subdir
  
   always supposing we really *want* to be good Apple citizens.  They
 would not look at
   all good if they were directly under Application Support/, because
 they are not apps.
 
  I'm not sure what you mean here, are you referring to kf5 frameworks,
 kdoctools uses kf5/kdoctools/ prefix beneath this to keep it's data
 separated from others, Other kf5 frameworks do the same. If they didn't we
 would have a ton of data in $prefix/share on linux which is also
 discouraged.

 I am talking about regular apps, not Frameworks, but I am glad that
 Frameworks'
 doctools is inserting the kf5/ subdir.

 If I were to build Granatier in KF5/Qt5, using standard QSP paths on OS X,
 I would
 expect to find /Library/Application Support/granatier/ containing all
 the data specific
 to Granatier (arenas, etc.).  But also I expect /Library/Application
 Support/kxmlgui5/,
 containing granatierui.rc (?), and /Library/Application
 Support/applications/ containing
 granatier.desktop (?).  Maybe there would be other subdirs, see [2],
 depending on
 whether Granatier shares other data with other apps or libraries or
 whether it uses shared
 resources such as /Library/Application Support/icons (?) (which I assume
 it does).

 If I have understood [2] correctly (BTW there seems to be a misprint under
 KXMLGUI5DIR),
 it seems to me that kxmlgui5/, applications/ and icons/, *whatever*
 they contain, would
 be out-of-place [3] in /Library/Application Support/ because they are
 not apps.  And even
 the application subdirs (granatier, etc.) run the risk of name-clashes
 with other software
 from sources other than KDE.  That is why I proposed a special subdir if
 we go the Apple
 and (unaltered) QStandardPaths 5.4 way.

 Cheers, Ian W.

  [1]
 https://projects.kde.org/projects/kde/kdegames/granatier/repository/revisions/master/entry/src/game.cpp
  [2] http://api.kde.org/ecm/kde-module/KDEInstallDirs.html

 [3] Out-of-place ... like feathers on a dog… :-)

Re: [KDE/Mac] Multiplatform frameworks

[Jeremy Whiting]

On Sat, Feb 28, 2015 at 4:51 AM, René J.V. rjvber...@gmail.com wrote:

 On Saturday February 28 2015 22:00:07 Ian Wadham wrote:

 Hi Ian,

  Esprit d'escalier.  We could change GenericDataDir in QStandardPaths to
 be:
 
   ~/Library/Application Support/Qt5, /Library/Application
 Support/Qt5
 
  That would work for ALL applications that use Qt5 and QSP, regardless of
 origin,
  and would be a more correct usage of Apple OS X by the Qt 5 libraries.

 And then you'd have to duplicate or migrate everything by the time Qt 6
 comes out ...
 I'd hope that Qt version-specific stuff is already installed by Qt itself
 in an appropriate place that's under configure control (${prefix}/share/qt5
 with my qt5-mac-devel port).


Then data will all be under ~/Library/Application Support/Qt5/appname ?
that's a bit cleaner, but why would Qt/KDE applications need to use a
namespace like that when apple's own applications don't? Here I see
~/Library/Application Support/kf5 for all frameworks as it is, I don't
think any frameworks or applications are using GenericDataLocation
directly, they all use a subfolder of it, otherwise we would see
application data files in /usr/share on linux which isn't recommended
either.



 The other issue is: how is the build system going to decide in which of
 the 2 locations above to install stuff?
 Has  KF5 done away with a ~/.kde/share equivalent that (partly) overrides
 things in ${prefix}/share?


kf5 based libraries and applications on linux are using
~/.local/applicationname mostly now. which overrides ${prefix}/share yes.


   Crowding out isn't the biggest issue, BTW  IMHO, it's the risk that
 we end up overwriting or
   otherwise interfering with stuff that's not ours but happens to be in
 the way.
 
  I was thinking the same.  I come from an environment where everything
 had to be uniquified:

 And as I said earlier, there's also the question of all the non-KDE/KF5
 applications that use freedesktop/xdg-style data paths that are conceived
 to be shared with KDE/KF5 (icons, themes, styles, the shared-mime database,
 .desktop/.service/dbus files, etc). There are loads of those in MacPorts
 (and Fink, and ...) and I think they're more widely used than KDE
 applications, so we have to factor in their existence. As well as MacPorts'
 policy to install everything in its own prefix (as well as the policies of
 the other major packaging efforts). There are just too many dependencies
 not to use MacPorts or similar, and OS X is different enough from Linux to
 make rolling our own standalone, do-as-the-romans-do distribution scheme
 a daunting task that I won't have anything to do with.


Which of those are using Qt or QStandardPaths though?



 R.
 ___
 kde-...@kde.org
 List Information: https://mail.kde.org/mailman/listinfo/kde-mac
 KDE/Mac Information: http://community.kde.org/Mac

Re: Multiplatform frameworks

[Jeremy Whiting]

Alex,

On Fri, Feb 27, 2015 at 4:05 AM, Alex Merry alex.me...@kde.org wrote:

 On Wednesday 25 February 2015 19:10:08 Jeremy Whiting wrote:
  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}

 I'd rather avoid this approach - too easy to let the files get out of sync.

I agree.


  2. Inside KF5FooConfig.cmake.in have platform detection to define
 whether
  to use the prefix or not.

 This is a lot of noise, and hard to check.

Agreed.


  3. Use absolute paths for KDE_INSTALL_DATADIR everywhere and remove
  ${PACKAGE_PREFIX_PATH} completely.

 There is KDE_INSTALL_FULL_DATADIR, which is absolute. However, that removes
 the relocatability of the package that ${PACKAGE_PREFIX_PATH} provides. I'm
 not sure just how much we care about that.

How is that set, just at the command line with -DKDE_INSTALL_FULL_DATADIR
or I also saw some IS_RELATIVE in the code that set FULL_* if the path is
absolute, though I couldn't get that to trigger here somehow.


 4. Use the PATH_VARS to ecm_configure_package_config_file().

 ecm_configure_package_config_file() behaves like
 configure_package_config_file from
 CMake 3.0, so see
 http://www.cmake.org/cmake/help/v3.1/module/CMakePackageConfigHelpers.html

 Basically, you add KDE_INSTALL_DATADIR to the PATH_VARS argument of
 ecm_configure_package_config_file(), and use @PACKAGE_KDE_INSTALL_DATADIR@
 in
 your Config.cmake.in file, and it should all work.


This sounds like the best option, could you throw together a patch to
kdoctools KF5KDocTools.ConfigCmake.cmake.in showing how that works? My
cmake foo is ok, but it would probably take me longer to do this than
someone that works with CMake every day.


 Alex

Re: [KDE/Mac] Multiplatform frameworks

[Jeremy Whiting]

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

Multiplatform frameworks

[Jeremy Whiting]

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

Re: Review Request 122552: warnings--

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122552/
---

(Updated Feb. 13, 2015, 1:17 p.m.)


Status
--

This change has been marked as submitted.


Review request for Bodega, kdelibs, Aaron J. Seigo, and Marco Martin.


Repository: bodega-server


Description
---

warnings--


Diffs
-

  server/app.js 4217a67735218e6bf1ccb04696a4e650319bb5d0 

Diff: https://git.reviewboard.kde.org/r/122552/diff/


Testing
---

This fixes a  few more warnings seen at runtime, with this fix browsing to 
localhost:3000/contact (or any other url in the api) shows the 404 page.
Without this fix it shows nothing and never responds.


Thanks,

Jeremy Whiting

Re: Review Request 122563: [OS X] emulate native window settings restore (size and position)

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122563/#review76003
---

Ship it!


Ship It!

- Jeremy Whiting


On Feb. 13, 2015, 12:19 p.m., René J.V. Bertin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122563/
 ---
 
 (Updated Feb. 13, 2015, 12:19 p.m.)
 
 
 Review request for KDE Software on Mac OS X and kdelibs.
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 OS X applications usually remember the last used screen, size and screen 
 position across restarts, and do not save screen-resolution dependent 
 settings. 
 
 The patch proposed here emulates that behaviour by following the example 
 given in the documentation for `QWidget::saveGeometry`: the current geometry 
 is saved in a key called `geometry`, and position is kept up to date by 
 letting `QEvent::Move` dirty the size setting, as under MS Windows.
 
 I think it's good practice to support previously stored settings when 
 changing a config store, so the code attempts to restore legacy settings 
 when the new key is unavailable.
 
 
 Diffs
 -
 
   kdeui/widgets/kmainwindow.cpp 85beacc 
 
 Diff: https://git.reviewboard.kde.org/r/122563/diff/
 
 
 Testing
 ---
 
 On OS X 10.9.5 with Qt 4.8.6 and kdelibs 4.14.5 (head of the 4.14 branch); 
 tested with systemsettings, kate and kontact.
 
 
 Thanks,
 
 René J.V. Bertin
 

Review Request 122552: warnings--

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122552/
---

Review request for Bodega, kdelibs, Aaron J. Seigo, and Marco Martin.


Repository: bodega-server


Description
---

warnings--


Diffs
-

  server/app.js 4217a67735218e6bf1ccb04696a4e650319bb5d0 

Diff: https://git.reviewboard.kde.org/r/122552/diff/


Testing
---

This fixes a  few more warnings seen at runtime, with this fix browsing to 
localhost:3000/contact (or any other url in the api) shows the 404 page.
Without this fix it shows nothing and never responds.


Thanks,

Jeremy Whiting

dolphin Qt requirement

[Jeremy Whiting]

Arjun,

http://mail.kde.org/pipermail/kde-frameworks-devel/2015-February/022157.html
-- it seems your recent commit changed Dolphin to require Qt 5.4 since
AssumeLocalFile is new in Qt 5.4. If you want to depend on Qt 5.4 please
bump the requirement in the kde-baseapps/CMakeLists.txt. If we/you want it
to build with Qt 5.3 some other workaround is needed.

thanks,
Jeremy

Re: Review Request 122394: Fix OSX library names in kdeinit5.app

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122394/
---

(Updated Feb. 3, 2015, 12:21 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Software on Mac OS X, kdelibs, David Faure, and Ian 
Wadham.


Bugs: 343707
https://bugs.kde.org/show_bug.cgi?id=343707


Repository: kinit


Description
---

OSX Doesn't have .so libraries, so use OSX names in kdeinit5.app to load the 
correct libraries needed.


Diffs
-

  src/kdeinit/kinit.cpp 3c3c913 

Diff: https://git.reviewboard.kde.org/r/122394/diff/


Testing
---

kdeinit5.app no longer complains about the missing .so libraries.


Thanks,

Jeremy Whiting

Re: Review Request 122394: Fix OSX library names in kdeinit5.app

[Jeremy Whiting]

 On Feb. 2, 2015, 2:56 p.m., René J.V. Bertin wrote:
  src/kdeinit/kinit.cpp, lines 90-92
  https://git.reviewboard.kde.org/r/122394/diff/1/?file=346478#file346478line90
 
  These are true shared libraries that are also used for -l style 
  linking with ld?

I'm not sure I understand the question, is there some other type of library on 
OSX besides true shared libraries that are also used for -l style linking with 
ld? file says they are Mach-O 64-bit dynamically linked shared library x86_64 
if that helps answer your question.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122394/#review75242
---


On Feb. 2, 2015, 1:51 p.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122394/
 ---
 
 (Updated Feb. 2, 2015, 1:51 p.m.)
 
 
 Review request for KDE Software on Mac OS X, kdelibs, David Faure, and Ian 
 Wadham.
 
 
 Bugs: 343707
 https://bugs.kde.org/show_bug.cgi?id=343707
 
 
 Repository: kinit
 
 
 Description
 ---
 
 OSX Doesn't have .so libraries, so use OSX names in kdeinit5.app to load the 
 correct libraries needed.
 
 
 Diffs
 -
 
   src/kdeinit/kinit.cpp 3c3c913 
 
 Diff: https://git.reviewboard.kde.org/r/122394/diff/
 
 
 Testing
 ---
 
 kdeinit5.app no longer complains about the missing .so libraries.
 
 
 Thanks,
 
 Jeremy Whiting
 

Review Request 122394: Fix OSX library names in kdeinit5.app

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122394/
---

Review request for kdelibs, David Faure and Ian Wadham.


Bugs: 343707
https://bugs.kde.org/show_bug.cgi?id=343707


Repository: kinit


Description
---

OSX Doesn't have .so libraries, so use OSX names in kdeinit5.app to load the 
correct libraries needed.


Diffs
-

  src/kdeinit/kinit.cpp 3c3c913 

Diff: https://git.reviewboard.kde.org/r/122394/diff/


Testing
---

kdeinit5.app no longer complains about the missing .so libraries.


Thanks,

Jeremy Whiting

Re: Review Request 122394: Fix OSX library names in kdeinit5.app

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122394/
---

(Updated Feb. 2, 2015, 1:51 p.m.)


Review request for KDE Software on Mac OS X, kdelibs, David Faure, and Ian 
Wadham.


Changes
---

added kde-mac group.


Bugs: 343707
https://bugs.kde.org/show_bug.cgi?id=343707


Repository: kinit


Description
---

OSX Doesn't have .so libraries, so use OSX names in kdeinit5.app to load the 
correct libraries needed.


Diffs
-

  src/kdeinit/kinit.cpp 3c3c913 

Diff: https://git.reviewboard.kde.org/r/122394/diff/


Testing
---

kdeinit5.app no longer complains about the missing .so libraries.


Thanks,

Jeremy Whiting

Re: Review Request 122267: ki18n: Make it build with msvc compilers again

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122267/
---

(Updated Jan. 27, 2015, 2:15 p.m.)


Status
--

This change has been marked as submitted.


Review request for kdelibs, kdewin and Nicolás Alvarez.


Repository: ki18n


Description
---

QStringLiteral documentation says: 

Concatenated string literals cannot be used with QStringLiteral.
QString s = QStringLiteral(a b);

which causes ki18n to not build on msvc 2013 here. This patch makes it build 
again.


Diffs
-

  src/kuitmarkup.cpp e2dda98 

Diff: https://git.reviewboard.kde.org/r/122267/diff/


Testing
---

Now ki18n builds with msvc2013


Thanks,

Jeremy Whiting

Re: Apps 14.12 release aftermath / Running KF5 apps in KDE 4

[Jeremy Whiting]

Eike,

Thanks for looking into this and notifying us also. I heard some vague
reports but nothing concrete like this.

On Mon, Jan 26, 2015 at 8:58 AM, Eike Hein h...@kde.org wrote:


 Hi,

 it's becoming increasingly clear from feedback that we didn't
 think the decision to ship KF5 apps in 14.12 through very well.

 Distros are currently rolling it out as an upgrade to KDE 4
 systems over the last 4.x apps, and users are running into the
 following problems:

 * KF5-based apps don't pick up visual settings from KDE 4 and
   can't be configured because System Settings 5 is usually not
   co-installable.

   I believe this needs to be addressed in the QPA plugin we
   ship with Frameworks and have added a new BKO product for
   the plugin as well as opened a ticket:

   https://bugs.kde.org/show_bug.cgi?id=343336

 * Some apps apparently don't use the support class to migrate
   the app config file to the fd.o location, which means from
   the user POV they lose all settings for the app.


I know kns3 isn't using this support class to migrate it's registry of
what's been installed to the new locations it uses. Just curious, what
support class are you referring to here?
I know kanagram/khangman also don't use this, but that's probably not as
important, since they don't have many settings anyway.


   Here we need to go through every app and check and fix it,
   and make sure we don't ship anything without that QA check
   again on future ports.

 I cross-posted this to k-c-d and r-t for visibility - I suggest
 we discuss the Frameworks side on k-c-d and the release QA side
 on r-t.


 Cheers,
 Eike
 ___
 release-team mailing list
 release-t...@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

Review Request 122267: ki18n: Make it build with msvc compilers again

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122267/
---

Review request for kdelibs and Nicolás Alvarez.


Repository: ki18n


Description
---

QStringLiteral documentation says: 

Concatenated string literals cannot be used with QStringLiteral.
QString s = QStringLiteral(a b);

which causes ki18n to not build on msvc 2013 here. This patch makes it build 
again.


Diffs
-

  src/kuitmarkup.cpp e2dda98 

Diff: https://git.reviewboard.kde.org/r/122267/diff/


Testing
---

Now ki18n builds with msvc2013


Thanks,

Jeremy Whiting

Re: Review Request 122267: ki18n: Make it build with msvc compilers again

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122267/
---

(Updated Jan. 26, 2015, 5:55 p.m.)


Review request for kdelibs, kdewin and Nicolás Alvarez.


Changes
---

Added kdewin group


Repository: ki18n


Description
---

QStringLiteral documentation says: 

Concatenated string literals cannot be used with QStringLiteral.
QString s = QStringLiteral(a b);

which causes ki18n to not build on msvc 2013 here. This patch makes it build 
again.


Diffs
-

  src/kuitmarkup.cpp e2dda98 

Diff: https://git.reviewboard.kde.org/r/122267/diff/


Testing
---

Now ki18n builds with msvc2013


Thanks,

Jeremy Whiting

Re: Review Request 122268: emerge: Update mysql and ruby dependencies

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122268/
---

(Updated Jan. 26, 2015, 5:54 p.m.)


Review request for kdelibs, kdewin, Nicolás Alvarez, and Patrick Spendrin.


Changes
---

added kdewin group


Repository: emerge


Description
---

A fresh install with emerge fails to build qt because mysql and ruby dependency 
urls and versions are no longer hosted at the previously default urls. This 
updates both so they work at least for a 32 bit build.


Diffs
-

  portage/binary/mysql-pkg/mysql-pkg.py f532351 
  portage/dev-util/ruby/ruby.py fd4f084 

Diff: https://git.reviewboard.kde.org/r/122268/diff/


Testing
---

emerge qt works after this change.


Thanks,

Jeremy Whiting

Re: Review Request 121805: kconfig: fix building when KDE_INSTALL_DIRS_NO_DEPRECATED is set

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121805/
---

(Updated Jan. 5, 2015, 9:57 a.m.)


Status
--

This change has been discarded.


Review request for kdelibs and Marko Käning.


Repository: kconfig


Description
---

Use KF5_INSTALL_TARGETS_DEFAULT_ARGS so kconfig will configure when 
KDE_INSTALL_DIRS_NO_DEPRECATED is set.


Diffs
-

  src/kreadconfig/CMakeLists.txt 3804e16 

Diff: https://git.reviewboard.kde.org/r/121805/diff/


Testing
---

It builds again on osx where it didn't previously.


Thanks,

Jeremy Whiting

Review Request 121584: Make the webapp manager run again.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121584/
---

Review request for Bodega, kdelibs, Aaron J. Seigo, and Marco Martin.


Repository: bodega-webapp-manager


Description
---

Make the webapp manager run again.


Diffs
-

  app.js ceede62c192451f2ac2bba8848a97f9bcc4a2f4a 
  package.json 715d01c3fa9e9f3a890ee9e047093fdfb528095f 
  public/favicon.ico PRE-CREATION 
  routes.js 891660f7fb3d036b5907114c58bd17f1128b1efe 
  views/layout.jade 423a37493acac482369693168cce32886a71f0bb 

Diff: https://git.reviewboard.kde.org/r/121584/diff/


Testing
---

It runs now, and gives 200 or 304 responses, though the browser currently shows 
Page Not Found


Thanks,

Jeremy Whiting

Re: Re: Ksshaskpass ?

[Jeremy Whiting]

Martin, Thomas,

Is the implementation of InputGuard at
https://github.com/luebking/qarma/commit/b568dd14d6e1f661791c4d67245c614f1dc1986f
with
https://github.com/luebking/qarma/commit/3199c0a9810ed8f792b415e890425be8f2e8034a
complete then? should we copy that into kwidgetsaddons and use it in
kpassworddialog? If so I'll do that and post a review request, I don't
quite follow all the discussion on this thread so wanted to be sure that
implementation is complete before doing so.

thanks,
Jeremy

On Fri, Dec 12, 2014 at 2:56 PM, Martin Gräßlin mgraess...@kde.org wrote:

 On Friday 12 December 2014 16:11:25 Thomas Lübking wrote:
  On Freitag, 12. Dezember 2014 08:00:45 CEST, Martin Gräßlin wrote:
   I'd suggest to do a platform check as on Wayland it cannot work
   (grab keyboard fails).
 
  You're certainly right in that the guarding is entirely superfluous on
  wayland, but grabbing still works. Despite the platform window
  ::setKeyboardGrabEnabled() returns false for wayland, QWidget simply
  ignores that and assigns the grabber.

 oh that's much better than I thought. I only knew that the QPA prints out
 warnings like not supported so I expected that code would just break.

 
  What's worse: looking up the Qt code, QWidget only maintains the grabber
 as
  static variable, the grabbing state is never re-tested.
 
  Eeeewww... this is gonna be more complex, I fear.

 Maybe one could say that misconfiguring the X-Server is out of scope. So if
 it's grabbed it's assumed to stay grabbed.

 
  I wonder whether the grabbing state can actually be tested except by
  approaching a grab from a sidearm process. In doubt, the only possible
  hardening would be to continuously - and the only test whether it worked
  would be to invoke QWindow::setMouseGrabEnabled(bool grab) as well.

 QWindow::setMouseGrabEnabled should be fine. The QXcbWindow implementation
 looks properly to me, like actually checking whether the grab succeeded.

 
  Stay tuned ;-)
 
  Cheers,
  Thomas

Re: Ksshaskpass ?

[Jeremy Whiting]

ksshaskspass has been in kdereview and has been improved since it got
there. Is it ready to be moved to kde/workspace ?

On Wed, Nov 5, 2014 at 12:50 PM, David Faure fa...@kde.org wrote:

 [cutting down on the massive cross-posting]

 On Monday 03 November 2014 14:13:50 Jeremy Whiting wrote:
  ksshaskpass has no more krazy issues and has been moved to kdereview.
  I think it's final resting place should be kde/workspace but I'm open
  to other ideas. It is usable on other platforms besides plasma, but it
  saves passwords in kwallet, so may make the most sense there.

 Yep, sounds like a workspace component to me. It doesn't make sense when
 using
 a single KDE app in e.g. gnome, which surely has another GUI for ssh-add.

 --
 David Faure, fa...@kde.org, http://www.davidfaure.fr
 Working on KDE Frameworks 5

Re: Re: Ksshaskpass ?

[Jeremy Whiting]

Martin,

Thanks for the review. I see what you mean, is there an example of doing
that on X11, also does that make it so ksshaskpass (or kpassworddialog)
won't work on wayland? At any rate if you can point me to another example
that does this I'll put a patch for KPasswordDialog on reviewboard (unless
someone else beats me to it).

thanks,
Jeremy

On Thu, Dec 11, 2014 at 8:43 AM, Martin Gräßlin mgraess...@kde.org wrote:

 On Thursday 11 December 2014 08:33:48 Jeremy Whiting wrote:
  ksshaskspass has been in kdereview and has been improved since it got
  there. Is it ready to be moved to kde/workspace ?

 Sorry for being late for the review. I just cloned the repo and did a quick
 look for a common problem on X11: the dialog doesn't grab keyboard input.

 When a window asks for a password it should make sure that no other X
 client
 intercepts the input. On X11 every other client is able to get to the key
 events. Thus the dialog should:
 * grab the keyboard when it gets keyboard focus (is active)
 * disable entering the password if it failed to grab keyboard and print a
 useful message
 * release the grab keyboard once it lost focus (e.g. user wants to switch
 to
 browser to check why that wants a password)

 While writing that I realized that this is not at all the fault of
 ksshaskspass but rather of KPasswordDialog which should implement those
 checks. So I wouldn't say it's a blocking issue for a move, though I would
 prefer to not get new applications into kde/workspace which aren't secure
 against the key logging attacks on X11.

 Cheers
 Martin

 
  On Wed, Nov 5, 2014 at 12:50 PM, David Faure fa...@kde.org wrote:
   [cutting down on the massive cross-posting]
  
   On Monday 03 November 2014 14:13:50 Jeremy Whiting wrote:
ksshaskpass has no more krazy issues and has been moved to kdereview.
I think it's final resting place should be kde/workspace but I'm open
to other ideas. It is usable on other platforms besides plasma, but
 it
saves passwords in kwallet, so may make the most sense there.
  
   Yep, sounds like a workspace component to me. It doesn't make sense
 when
   using
   a single KDE app in e.g. gnome, which surely has another GUI for
 ssh-add.
  
   --
   David Faure, fa...@kde.org, http://www.davidfaure.fr
   Working on KDE Frameworks 5

QIcon::fromTheme on non linux platforms

[Jeremy Whiting]

Hey all,

In looking into building some kde applications on windows and mac besides
linux I've come across a minor hiccup. In many applications and frameworks
possibly we use QIcon::fromTheme to get icons from a named icon. This is
even recommended in the kf5 porting notes, however on non linux platforms
we hit a couple of issues. QIcon::fromTheme's documentation says it's not
meant to work on non linux platforms or if we want it to work there we need
to install icons into some theme path, add the theme to the application's
themeSearchPaths and set the name with setThemeName.

For kde on windows this is ok since the qt built with the emerge tool is
patched to set the theme name to oxygen however it's not ideal and
doesn't act the same as on linux itself where oxygen is the icon theme but
hicolor is a fallback (and there could be others from what I gather besides
the oxygen theme itself). All the ecm_install_icons calls in kdeedu
applications that I saw install into hicolor theme, or don't set a theme
and end up in hicolor by default. So the question then becomes what's the
correct/best way to get this functionality on non linux platforms? Is
QIcon::fromTheme something that comes from the platform plugin or do we
need to use patched Qt on those platforms to support getting the icons our
applications need?

BR,
Jeremy

Re: Adventures in Bodega

[Jeremy Whiting]

Yes, I've done that. I have redis and postgresql both running. Yet main.sh
fails because this RedisStore.prototype is undefined. I've added a couple
of console.log statements and I see that session exists and is defined, but
they set the RedisStore.prototype.__proto__ to the session.Store.prototype
while session.Store is undefined. main.sh thus doesn't run with the error
message I pasted in the original mail.

On Mon, Nov 24, 2014 at 3:41 AM, Aaron J. Seigo ase...@kde.org wrote:

 On Saturday, November 22, 2014 07.56:39 Jeremy Whiting wrote:
  getting an error inside the node redis module as seen below. Is redis
  something that is no longer maintained or something?

 redis is a very popular key/value store (in-memory with on-disk
 persistence).
 you need to have it installed and running. it does not require any
 configuration: just install, start, profit.

 --
 Aaron J. Seigo

Adventures in Bodega

[Jeremy Whiting]

Hello list,

I realize this list will reach many more people than could probably answer,
but the -active list seems to be dead from what I hear, so I thought I'd
try here. In looking into bodega as a successor to opendesktop and ocs I've
tried to setup a local bodega instance on my machine. The documentation is
pretty thorough and I've followed the steps to get postgresql set up and
have the node.js dependencies, however when trying to run the server I'm
getting an error inside the node redis module as seen below. Is redis
something that is no longer maintained or something? npm install works
without any error but says a warning about Swipe which I expect since I
haven't set up those parts of the config.json file. npm update gives many
more warnings about dependencies, but no errors that I see. Has anyone else
gotten the bodega server to run? Any help is appreciated.

thanks,
Jeremy

I slightly modified the node_modules/connect-redis/lib/connect-redis.js to
see what session and session.Store are, but here's the output:

 [jeremy@chrom server]$ ./main.sh

/home/jeremy/devel/kde/src/extragear/network/bodega-server/server/node_modules/connect-redis/lib/connect-redis.js:121

 RedisStore.prototype.__proto__ = Store.prototype;
   ^
TypeError: Cannot read property 'prototype' of undefined
   at module.exports
(/home/jeremy/devel/kde/src/extragear/network/bodega-server/server/node_modules/connect-redis/lib/connect-redis.js:121:41)

   at Object.anonymous
(/home/jeremy/devel/kde/src/extragear/network/bodega-server/server/app.js:19:42)

   at Module._compile (module.js:456:26)
   at Object.Module._extensions..js (module.js:474:10)
   at Module.load (module.js:356:32)
   at Function.Module._load (module.js:312:12)
   at Function.Module.runMain (module.js:497:10)
   at startup (node.js:119:16)
   at node.js:906:3
[jeremy@chrom server]$ vi node_modules/connect-redis/lib/connect-redis.js
[jeremy@chrom server]$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
[jeremy@chrom server]$ ./main.sh

/home/jeremy/devel/kde/src/extragear/network/bodega-server/server/node_modules/connect-redis/lib/connect-redis.js:37

 console.log(Store is  + store);
   ^
ReferenceError: store is not defined
   at module.exports
(/home/jeremy/devel/kde/src/extragear/network/bodega-server/server/node_modules/connect-redis/lib/connect-redis.js:37:29)

   at Object.anonymous
(/home/jeremy/devel/kde/src/extragear/network/bodega-server/server/app.js:19:42)

   at Module._compile (module.js:456:26)
   at Object.Module._extensions..js (module.js:474:10)
   at Module.load (module.js:356:32)
   at Function.Module._load (module.js:312:12)
   at Function.Module.runMain (module.js:497:10)
   at startup (node.js:119:16)
   at node.js:906:3

[jeremy@chrom server]$ vi node_modules/connect-redis/lib/connect-redis.js

[jeremy@chrom server]$ ./main.sh
Store is undefined


/home/jeremy/devel/kde/src/extragear/network/bodega-server/server/node_modules/connect-redis/lib/connect-redis.js:122

 RedisStore.prototype.__proto__ = Store.prototype;

   ^

TypeError: Cannot read property 'prototype' of undefined
   at module.exports
(/home/jeremy/devel/kde/src/extragear/network/bodega-server/server/node_modules/connect-redis/lib/connect-redis.js:122:41)

   at Object.anonymous
(/home/jeremy/devel/kde/src/extragear/network/bodega-server/server/app.js:19:42)

   at Module._compile (module.js:456:26)
   at Object.Module._extensions..js (module.js:474:10)
   at Module.load (module.js:356:32)
   at Function.Module._load (module.js:312:12)
   at Function.Module.runMain (module.js:497:10)
   at startup (node.js:119:16)
   at node.js:906:3
[jeremy@chrom server]$ vi node_modules/connect-redis/lib/connect-redis.js
[jeremy@chrom server]$ ./main.sh
session is function createApplication() {
 var app = function(req, res, next) {
   app.handle(req, res, next);
 };

 mixin(app, proto);
 mixin(app, EventEmitter.prototype);

 app.request = { __proto__: req, app: app };
 app.response = { __proto__: res, app: app };
 app.init();
 return app;
}
Store is undefined

/home/jeremy/devel/kde/src/extragear/network/bodega-server/server/node_modules/connect-redis/lib/connect-redis.js:123

 RedisStore.prototype.__proto__ = Store.prototype;
   ^
TypeError: Cannot read property 'prototype' of undefined
   at module.exports
(/home/jeremy/devel/kde/src/extragear/network/bodega-server/server/node_modules/connect-redis/lib/connect-redis.js:123:41)

   at Object.anonymous
(/home/jeremy/devel/kde/src/extragear/network/bodega-server/server/app.js:19:42)

   at Module._compile (module.js:456:26)
   at Object.Module._extensions..js (module.js:474:10)
   at Module.load (module.js:356:32)
   at Function.Module._load (module.js:312:12)
   at Function.Module.runMain (module.js:497:10)
   at startup (node.js:119:16)
   at 

Re: Review Request 121161: Set KIO::Integration::AccessManager to null so we don't crash on close.

[Jeremy Whiting]

 On Nov. 17, 2014, 2:45 p.m., Thomas Lübking wrote:
  attica-kde/kdeplugin/kdeplatformdependent.cpp, line 56
  https://git.reviewboard.kde.org/r/121161/diff/2/?file=328928#file328928line56
 
  is
  
  KdePlatformDependent::~KdePlatformDependent()
  {
 if (QCoreApplication::closingDown())
m_accessManager-setParent(nullptr);
  }
  
  sufficient?
 
 Albert Astals Cid wrote:
 Isn't that a more complex way of doing the same?
 
 Thomas Lübking wrote:
 Depends on whether KdePlatformDependent is ever deleted in a running 
 application (where the leak would really matter)
 If not, then yes: superfluous complication.
 
 Jeremy Whiting wrote:
 Did I hear a Ship it! in there somewhere?
 
 Thomas Lübking wrote:
 Leaving aside that don't maintain the attica plugin, you have a +1 from 
 here, IF
 a) the conditional reparent on destruction is not sufficient (doesn't 
 work)
OR
 b) KdePlatformDependent object(s) are not supposed to be deleted during 
 the runtime of the application
 
 Ie. if the leak is inevitable or only theoretical.

Yep, I'm one of the attica and knewstuff maintainers and got the plugin to load 
recently, then hit this crash on close, so trying to fix it. The code in the 
plugin is only built with the plugin, so shouldn't be used besides as a plugin.

The conditional reparent probably works too, but as Albert said it's just a 
more complicated way of doing the same thing.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121161/#review70542
---


On Nov. 17, 2014, 2:11 p.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121161/
 ---
 
 (Updated Nov. 17, 2014, 2:11 p.m.)
 
 
 Review request for kdelibs and Plasma.
 
 
 Repository: plasma-desktop
 
 
 Description
 ---
 
 Plugin unload order was making the attica_kde plugin crash on close,
 this works around it by leaking one AccessManager.
 
 
 Diffs
 -
 
   attica-kde/kdeplugin/kdeplatformdependent.cpp 
 489c03b18b7bb940007ab51cb197105fbc25de9f 
 
 Diff: https://git.reviewboard.kde.org/r/121161/diff/
 
 
 Testing
 ---
 
 knewstuff tests no longer crash on close.
 
 
 Thanks,
 
 Jeremy Whiting