date:20160225

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

2016-02-25 Thread Martin Gräßlin



> On Feb. 25, 2016, 8:26 a.m., Martin Gräßlin wrote:
> > I don't like the introduction of the SCRAPBOOK. The repository is not the 
> > place for dead and old code. That's what git already supports with keeping 
> > the whole history.
> > 
> > We have some autotests for kwindowsystem. Could you try whether the tests 
> > work also on OSX?
> 
> René J.V. Bertin wrote:
> I agree to a certain extent. Git's history feature isn't exactly 
> comparable to a history book in which you can go look around to see if at 
> some point maybe someone contributed some code that was never finished. At 
> the very least you'd need to leave comments in the code that "here used to be 
> some junk DNA that maybe could have led to a whole better world" (and in that 
> case, why not just leave in the code #ifdeffed-out ...)
> 
> As to the autotests: they're built only when `X11_FOUND`. Are you in fact 
> asking me to port them?

> At the very least you'd need to leave comments in the code that "here used to 
> be some junk DNA that maybe could have led to a whole better world" (and in 
> that case, why not just leave in the code #ifdeffed-out ...)

eh no, we are not StarOffice. We have a version control system. No need to 
reference old code.

> they're built only when X11_FOUND. Are you in fact asking me to port them?

No, of course not. There are some which might not be X11 specific. E.g. 
kwindowsystem_threadtest.cpp. It would be good to know which ones can work on 
OSX


- Martin


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


On Feb. 23, 2016, 10:54 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126291/
> ---
> 
> (Updated Feb. 23, 2016, 10:54 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> KWindowSystem has been lacking a platform plugin for OS X. This RR presents a 
> "backport" of the modified KDE4 KWindowSystem implementation that has been 
> used in the MacPorts kdelibs4 port for the last 2 or 3 (or more) years.
> 
> I have made some initial steps to remove deprecated Carbon API calls, but 
> this is clearly a work in progress.
> 
> Open questions include
> - is there any justification to run an event handler (or Cocoa observer) to 
> keep track of running applications, possibly even listing all their open 
> windows?
> - is there any use for the Qt event listener framework (cf. the 
> NETEventFilter in the X11 plugin)? I haven't yet had time to try to figure 
> out what this "could be good for", and am very open to suggestions in this 
> departments.
> - one application for such an event filter would be a listener that catches 
> the opening and closing of all windows by the running process, and keeps 
> track of their `WId`s. A new method could then be added (to `KWindowInfo`?) 
> to distinguish `WId`s created by the running application from "foreign" ones 
> (useful also on Wayland and MS Windows).
> 
> `KWindowSystem::setMainWindow` should become a front for payload provided by 
> the plugins. I'll leave that to the regular/official maintainer(s) of this 
> framework.
> 
> This code could probably do with *lots* of comments; I'll try to add them as 
> questions about this or that bit of code arise.
> 
> 
> Diffs
> -
> 
>   src/debug_p.h 5ef8996 
>   src/debug_p.cpp 72abfb7 
>   src/kwindowsystem.cpp 407a67d 
>   src/platforms/osx/CMakeLists.txt 4fc3347 
>   src/platforms/osx/SCRAPBOOK PRE-CREATION 
>   src/platforms/osx/cocoa.json PRE-CREATION 
>   src/platforms/osx/kkeyserver.cpp 3ddb921 
>   src/platforms/osx/kwindowinfo.cpp e8555bb 
>   src/platforms/osx/kwindowinfo.mm PRE-CREATION 
>   src/platforms/osx/kwindowinfo_mac_p.h c8f307e 
>   src/platforms/osx/kwindowinfo_p_cocoa.h PRE-CREATION 
>   src/platforms/osx/kwindowsystem.cpp 1758829 
>   src/platforms/osx/kwindowsystem_mac_p.h PRE-CREATION 
>   src/platforms/osx/kwindowsystem_macobjc.mm PRE-CREATION 
>   src/platforms/osx/kwindowsystem_p_cocoa.h PRE-CREATION 
>   src/platforms/osx/plugin.h PRE-CREATION 
>   src/platforms/osx/plugin.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126291/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and frameworks 5.16.0 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

2016-02-25 Thread Nicolás Alvarez

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

Ship it!

Looks like I totally misunderstood this change. It only changes the default if 
the project's `CMAKE_INSTALL_PREFIX` is the same as the prefix where Qt is 
installed, and in that case it does make sense to change the subpaths, since it 
won't put anything outside the given prefix. If Qt is in a different location 
(eg. self-built project in `~/local`, system Qt in `/usr`), nothing changes.

I was concerned because I have seen other projects always try to install stuff 
in eg. `/etc`, even if `CMAKE_INSTALL_PREFIX` is somewhere in `$HOME`, because 
some system daemon expects its config there. But that's not the case here :)

- Nicolás Alvarez

On Feb. 24, 2016, 2:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated Feb. 24, 2016, 2:09 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
> might be controlled but usually won't.
> 
> In the end, otherwise, people need to keep adapting their systems with 
> environment variables anyway. All distros end up setting always this setting 
> as ON, as well as brave developers who don't have separate prefixes for Qt 
> and KDE.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake ebd48fa 
> 
> Diff: https://git.reviewboard.kde.org/r/127169/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

2016-02-25 Thread Stephen Kelly



> On Feb. 24, 2016, 7:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> > 
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would 
> > expect the libs go in the same place, but maybe the plugins are affected by 
> > this? Can you be more specific?
> > 
> > Thanks,
> 
> Aleix Pol Gonzalez wrote:
> Well, Qt might be installing things in `$prefix/lib` and cmake in 
> `$prefix/lib64`. In fact, Qt by default installs plugins in `$prefix/plugins` 
> (which looks really odd, I agree).
> In any case, if it's meant to go to the same place, let's just ask Qt 
> where to go.
> 
> As you can see, all of the distros are already specifying this: (and they 
> don't need to in fact, because it's the same prefix)
> 
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kcoreaddons
> 
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkg-kde-tools/wily/view/head:/datalib/kf5_flags
> https://pkgs.fedoraproject.org/cgit/rpms/kf5.git/tree/macros.kf5
> 
> Nicolás Alvarez wrote:
> I don't think "all distros set it" is a valid argument for changing a 
> default, otherwise we would be setting `CMAKE_INSTALL_PREFIX=/usr` by default 
> too.
> 
> Stephen Kelly wrote:
> I agree with Nicolás that this seems wierd. Are packagers complaining 
> about having to set this?
> 
> Also, I don't think I've seen enough specifics about the impact this has. 
> What moves where etc.
> 
> Aleix Pol Gonzalez wrote:
> 99% of our users use a setting that we don't enable by default? It's 
> definitely something to take into account.
> 
> In fact, if the creator of a system decided that Qt plugins go to 
> /usr/heaven/plugins, I don't really see why we should override the decision 
> and ask the user to configure each project specifically. I understand this 
> wouldn't make sense if they weren't sharing a prefix, as it's a complete 
> different thing.
> 
> An example is my installation. Qt decided to put the plugins in 
> `$prefix/lib/plugins`, cmake/ecm decides to put them in 
> `$prefix/lib64/plugins`. I get 2 Qt plugin directories for no reason.
> 
> Stephen Kelly wrote:
> Sorry, just so I understand - The '99%' is referring to packagers 
> creating distro packages? 
> 
> Do we want to make 'create a distro package' the primary/default case in 
> kde buildsystems? Genuine question. Otherwise I don't understand your point 
> here I'm afraid. That would indeed mean we should set 
> CMAKE_INSTALL_PREFIX=/usr. Perhaps there are other things we should set too. 
> If you're suggesting we should do that, then maybe we really should. Is that 
> the suggestion?
> 
> I'd still like to see a list of what changes. What moves where etc, as a 
> result of this. You mentioned $prefix/lib/plugins to $prefix/lib64/plugins . 
> Is that everything? It's only plugins that are affected?
> 
> Aleix Pol Gonzalez wrote:
> `CMAKE_INSTALL_PREFIX=/usr` would be a whole different story, because 
> we'd be deciding on where the project is installed. The important thing is 
> that if the user decides that his project and Qt share the same prefix, those 
> should get plugins (and FWIW, anything that will be looked-up afterwards by 
> Qt) in the same place, by default.
> 
> Namely, that is that we're making sure is the same:
> 
> * KDE_INSTALL_QTPLUGINDIR: `qmake -query QT_INSTALL_PLUGINS`
> * KDE_INSTALL_QMLDIR: `qmake -query QT_INSTALL_QML`
> * KDE_INSTALL_QTQUICKIMPORTSDIR: `qmake -query IMPORTS_INSTALL_DIR`
> 
> Nicolás Alvarez wrote:
> Oh, what if the user *doesn't* have his project and Qt in the same 
> prefix? Eg. Qt in /usr (system-provided) and his project in ~/local?

> Namely, that is that we're making sure is the same:
>KDE_INSTALL_QTPLUGINDIR: qmake -query QT_INSTALL_PLUGINS
>KDE_INSTALL_QMLDIR: qmake -query QT_INSTALL_QML
>KDE_INSTALL_QTQUICKIMPORTSDIR: qmake -query IMPORTS_INSTALL_DIR

Thanks. This is specific and we can have a discussion about them. Too late in 
this evening for me now though.


- Stephen


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


On Feb. 24, 2016, 5:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated Feb. 24, 2016, 5:09 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
>

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

2016-02-25 Thread Nicolás Alvarez



> On Feb. 24, 2016, 4:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> > 
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would 
> > expect the libs go in the same place, but maybe the plugins are affected by 
> > this? Can you be more specific?
> > 
> > Thanks,
> 
> Aleix Pol Gonzalez wrote:
> Well, Qt might be installing things in `$prefix/lib` and cmake in 
> `$prefix/lib64`. In fact, Qt by default installs plugins in `$prefix/plugins` 
> (which looks really odd, I agree).
> In any case, if it's meant to go to the same place, let's just ask Qt 
> where to go.
> 
> As you can see, all of the distros are already specifying this: (and they 
> don't need to in fact, because it's the same prefix)
> 
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kcoreaddons
> 
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkg-kde-tools/wily/view/head:/datalib/kf5_flags
> https://pkgs.fedoraproject.org/cgit/rpms/kf5.git/tree/macros.kf5
> 
> Nicolás Alvarez wrote:
> I don't think "all distros set it" is a valid argument for changing a 
> default, otherwise we would be setting `CMAKE_INSTALL_PREFIX=/usr` by default 
> too.
> 
> Stephen Kelly wrote:
> I agree with Nicolás that this seems wierd. Are packagers complaining 
> about having to set this?
> 
> Also, I don't think I've seen enough specifics about the impact this has. 
> What moves where etc.
> 
> Aleix Pol Gonzalez wrote:
> 99% of our users use a setting that we don't enable by default? It's 
> definitely something to take into account.
> 
> In fact, if the creator of a system decided that Qt plugins go to 
> /usr/heaven/plugins, I don't really see why we should override the decision 
> and ask the user to configure each project specifically. I understand this 
> wouldn't make sense if they weren't sharing a prefix, as it's a complete 
> different thing.
> 
> An example is my installation. Qt decided to put the plugins in 
> `$prefix/lib/plugins`, cmake/ecm decides to put them in 
> `$prefix/lib64/plugins`. I get 2 Qt plugin directories for no reason.
> 
> Stephen Kelly wrote:
> Sorry, just so I understand - The '99%' is referring to packagers 
> creating distro packages? 
> 
> Do we want to make 'create a distro package' the primary/default case in 
> kde buildsystems? Genuine question. Otherwise I don't understand your point 
> here I'm afraid. That would indeed mean we should set 
> CMAKE_INSTALL_PREFIX=/usr. Perhaps there are other things we should set too. 
> If you're suggesting we should do that, then maybe we really should. Is that 
> the suggestion?
> 
> I'd still like to see a list of what changes. What moves where etc, as a 
> result of this. You mentioned $prefix/lib/plugins to $prefix/lib64/plugins . 
> Is that everything? It's only plugins that are affected?
> 
> Aleix Pol Gonzalez wrote:
> `CMAKE_INSTALL_PREFIX=/usr` would be a whole different story, because 
> we'd be deciding on where the project is installed. The important thing is 
> that if the user decides that his project and Qt share the same prefix, those 
> should get plugins (and FWIW, anything that will be looked-up afterwards by 
> Qt) in the same place, by default.
> 
> Namely, that is that we're making sure is the same:
> 
> * KDE_INSTALL_QTPLUGINDIR: `qmake -query QT_INSTALL_PLUGINS`
> * KDE_INSTALL_QMLDIR: `qmake -query QT_INSTALL_QML`
> * KDE_INSTALL_QTQUICKIMPORTSDIR: `qmake -query IMPORTS_INSTALL_DIR`

Oh, what if the user *doesn't* have his project and Qt in the same prefix? Eg. 
Qt in /usr (system-provided) and his project in ~/local?


- Nicolás


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


On Feb. 24, 2016, 2:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated Feb. 24, 2016, 2:09 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
> might be controlled but usually won't.
> 
> In the end, otherwise, people need to keep adapting their systems with 
> environment variables anyway. All distros end up setting always this setting 
> as ON, as well as brave developers who don't have separate prefixes for Qt 
> and KDE.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake ebd48fa 
> 
> Diff:

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

2016-02-25 Thread Aleix Pol Gonzalez



> On Feb. 24, 2016, 8:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> > 
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would 
> > expect the libs go in the same place, but maybe the plugins are affected by 
> > this? Can you be more specific?
> > 
> > Thanks,
> 
> Aleix Pol Gonzalez wrote:
> Well, Qt might be installing things in `$prefix/lib` and cmake in 
> `$prefix/lib64`. In fact, Qt by default installs plugins in `$prefix/plugins` 
> (which looks really odd, I agree).
> In any case, if it's meant to go to the same place, let's just ask Qt 
> where to go.
> 
> As you can see, all of the distros are already specifying this: (and they 
> don't need to in fact, because it's the same prefix)
> 
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kcoreaddons
> 
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkg-kde-tools/wily/view/head:/datalib/kf5_flags
> https://pkgs.fedoraproject.org/cgit/rpms/kf5.git/tree/macros.kf5
> 
> Nicolás Alvarez wrote:
> I don't think "all distros set it" is a valid argument for changing a 
> default, otherwise we would be setting `CMAKE_INSTALL_PREFIX=/usr` by default 
> too.
> 
> Stephen Kelly wrote:
> I agree with Nicolás that this seems wierd. Are packagers complaining 
> about having to set this?
> 
> Also, I don't think I've seen enough specifics about the impact this has. 
> What moves where etc.
> 
> Aleix Pol Gonzalez wrote:
> 99% of our users use a setting that we don't enable by default? It's 
> definitely something to take into account.
> 
> In fact, if the creator of a system decided that Qt plugins go to 
> /usr/heaven/plugins, I don't really see why we should override the decision 
> and ask the user to configure each project specifically. I understand this 
> wouldn't make sense if they weren't sharing a prefix, as it's a complete 
> different thing.
> 
> An example is my installation. Qt decided to put the plugins in 
> `$prefix/lib/plugins`, cmake/ecm decides to put them in 
> `$prefix/lib64/plugins`. I get 2 Qt plugin directories for no reason.
> 
> Stephen Kelly wrote:
> Sorry, just so I understand - The '99%' is referring to packagers 
> creating distro packages? 
> 
> Do we want to make 'create a distro package' the primary/default case in 
> kde buildsystems? Genuine question. Otherwise I don't understand your point 
> here I'm afraid. That would indeed mean we should set 
> CMAKE_INSTALL_PREFIX=/usr. Perhaps there are other things we should set too. 
> If you're suggesting we should do that, then maybe we really should. Is that 
> the suggestion?
> 
> I'd still like to see a list of what changes. What moves where etc, as a 
> result of this. You mentioned $prefix/lib/plugins to $prefix/lib64/plugins . 
> Is that everything? It's only plugins that are affected?

`CMAKE_INSTALL_PREFIX=/usr` would be a whole different story, because we'd be 
deciding on where the project is installed. The important thing is that if the 
user decides that his project and Qt share the same prefix, those should get 
plugins (and FWIW, anything that will be looked-up afterwards by Qt) in the 
same place, by default.

Namely, that is that we're making sure is the same:

* KDE_INSTALL_QTPLUGINDIR: `qmake -query QT_INSTALL_PLUGINS`
* KDE_INSTALL_QMLDIR: `qmake -query QT_INSTALL_QML`
* KDE_INSTALL_QTQUICKIMPORTSDIR: `qmake -query IMPORTS_INSTALL_DIR`


- Aleix


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


On Feb. 24, 2016, 6:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated Feb. 24, 2016, 6:09 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
> might be controlled but usually won't.
> 
> In the end, otherwise, people need to keep adapting their systems with 
> environment variables anyway. All distros end up setting always this setting 
> as ON, as well as brave developers who don't have separate prefixes for Qt 
> and KDE.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake ebd48fa 
> 
> Diff: https://git.reviewboard.kde.org/r/127169/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

2016-02-25 Thread Stephen Kelly



> On Feb. 24, 2016, 7:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> > 
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would 
> > expect the libs go in the same place, but maybe the plugins are affected by 
> > this? Can you be more specific?
> > 
> > Thanks,
> 
> Aleix Pol Gonzalez wrote:
> Well, Qt might be installing things in `$prefix/lib` and cmake in 
> `$prefix/lib64`. In fact, Qt by default installs plugins in `$prefix/plugins` 
> (which looks really odd, I agree).
> In any case, if it's meant to go to the same place, let's just ask Qt 
> where to go.
> 
> As you can see, all of the distros are already specifying this: (and they 
> don't need to in fact, because it's the same prefix)
> 
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kcoreaddons
> 
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkg-kde-tools/wily/view/head:/datalib/kf5_flags
> https://pkgs.fedoraproject.org/cgit/rpms/kf5.git/tree/macros.kf5
> 
> Nicolás Alvarez wrote:
> I don't think "all distros set it" is a valid argument for changing a 
> default, otherwise we would be setting `CMAKE_INSTALL_PREFIX=/usr` by default 
> too.
> 
> Stephen Kelly wrote:
> I agree with Nicolás that this seems wierd. Are packagers complaining 
> about having to set this?
> 
> Also, I don't think I've seen enough specifics about the impact this has. 
> What moves where etc.
> 
> Aleix Pol Gonzalez wrote:
> 99% of our users use a setting that we don't enable by default? It's 
> definitely something to take into account.
> 
> In fact, if the creator of a system decided that Qt plugins go to 
> /usr/heaven/plugins, I don't really see why we should override the decision 
> and ask the user to configure each project specifically. I understand this 
> wouldn't make sense if they weren't sharing a prefix, as it's a complete 
> different thing.
> 
> An example is my installation. Qt decided to put the plugins in 
> `$prefix/lib/plugins`, cmake/ecm decides to put them in 
> `$prefix/lib64/plugins`. I get 2 Qt plugin directories for no reason.

Sorry, just so I understand - The '99%' is referring to packagers creating 
distro packages? 

Do we want to make 'create a distro package' the primary/default case in kde 
buildsystems? Genuine question. Otherwise I don't understand your point here 
I'm afraid. That would indeed mean we should set CMAKE_INSTALL_PREFIX=/usr. 
Perhaps there are other things we should set too. If you're suggesting we 
should do that, then maybe we really should. Is that the suggestion?

I'd still like to see a list of what changes. What moves where etc, as a result 
of this. You mentioned $prefix/lib/plugins to $prefix/lib64/plugins . Is that 
everything? It's only plugins that are affected?


- Stephen


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


On Feb. 24, 2016, 5:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated Feb. 24, 2016, 5:09 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
> might be controlled but usually won't.
> 
> In the end, otherwise, people need to keep adapting their systems with 
> environment variables anyway. All distros end up setting always this setting 
> as ON, as well as brave developers who don't have separate prefixes for Qt 
> and KDE.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake ebd48fa 
> 
> Diff: https://git.reviewboard.kde.org/r/127169/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127090: Clean KWalletQuery cmake file

2016-02-25 Thread Aleix Pol Gonzalez



> On Feb. 25, 2016, 7:39 p.m., Hrvoje Senjan wrote:
> > This is not 100% correct. KF5DocTools is searched nowhere, so doc subdir is 
> > now never added.

Good catch! Fixed: 
http://commits.kde.org/kwallet-framework/3ea2c94aa2ab7e01962ad4fb64e1232f9f8e7a55


- Aleix


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


On Feb. 25, 2016, 1:34 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127090/
> ---
> 
> (Updated Feb. 25, 2016, 1:34 a.m.)
> 
> 
> Review request for KDE Frameworks and Valentin Rusu.
> 
> 
> Repository: kwallet
> 
> 
> Description
> ---
> 
> I saw it didn't build because I needed a build with KDocTools, ended up 
> cleaning a bit more.
> 
> 
> Diffs
> -
> 
>   src/runtime/kwallet-query/CMakeLists.txt 42b4687 
>   src/runtime/kwallet-query/src/main.cpp c19cb29 
> 
> Diff: https://git.reviewboard.kde.org/r/127090/diff/
> 
> 
> Testing
> ---
> 
> Built with and without KDocTools.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

2016-02-25 Thread Aleix Pol Gonzalez



> On Feb. 24, 2016, 8:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> > 
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would 
> > expect the libs go in the same place, but maybe the plugins are affected by 
> > this? Can you be more specific?
> > 
> > Thanks,
> 
> Aleix Pol Gonzalez wrote:
> Well, Qt might be installing things in `$prefix/lib` and cmake in 
> `$prefix/lib64`. In fact, Qt by default installs plugins in `$prefix/plugins` 
> (which looks really odd, I agree).
> In any case, if it's meant to go to the same place, let's just ask Qt 
> where to go.
> 
> As you can see, all of the distros are already specifying this: (and they 
> don't need to in fact, because it's the same prefix)
> 
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kcoreaddons
> 
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkg-kde-tools/wily/view/head:/datalib/kf5_flags
> https://pkgs.fedoraproject.org/cgit/rpms/kf5.git/tree/macros.kf5
> 
> Nicolás Alvarez wrote:
> I don't think "all distros set it" is a valid argument for changing a 
> default, otherwise we would be setting `CMAKE_INSTALL_PREFIX=/usr` by default 
> too.
> 
> Stephen Kelly wrote:
> I agree with Nicolás that this seems wierd. Are packagers complaining 
> about having to set this?
> 
> Also, I don't think I've seen enough specifics about the impact this has. 
> What moves where etc.

99% of our users use a setting that we don't enable by default? It's definitely 
something to take into account.

In fact, if the creator of a system decided that Qt plugins go to 
/usr/heaven/plugins, I don't really see why we should override the decision and 
ask the user to configure each project specifically. I understand this wouldn't 
make sense if they weren't sharing a prefix, as it's a complete different thing.

An example is my installation. Qt decided to put the plugins in 
`$prefix/lib/plugins`, cmake/ecm decides to put them in 
`$prefix/lib64/plugins`. I get 2 Qt plugin directories for no reason.


- Aleix


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


On Feb. 24, 2016, 6:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated Feb. 24, 2016, 6:09 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
> might be controlled but usually won't.
> 
> In the end, otherwise, people need to keep adapting their systems with 
> environment variables anyway. All distros end up setting always this setting 
> as ON, as well as brave developers who don't have separate prefixes for Qt 
> and KDE.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake ebd48fa 
> 
> Diff: https://git.reviewboard.kde.org/r/127169/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

2016-02-25 Thread René J . V . Bertin



> On Feb. 25, 2016, 8:26 a.m., Martin Gräßlin wrote:
> > I don't like the introduction of the SCRAPBOOK. The repository is not the 
> > place for dead and old code. That's what git already supports with keeping 
> > the whole history.
> > 
> > We have some autotests for kwindowsystem. Could you try whether the tests 
> > work also on OSX?

I agree to a certain extent. Git's history feature isn't exactly comparable to 
a history book in which you can go look around to see if at some point maybe 
someone contributed some code that was never finished. At the very least you'd 
need to leave comments in the code that "here used to be some junk DNA that 
maybe could have led to a whole better world" (and in that case, why not just 
leave in the code #ifdeffed-out ...)

As to the autotests: they're built only when `X11_FOUND`. Are you in fact 
asking me to port them?


> On Feb. 25, 2016, 8:26 a.m., Martin Gräßlin wrote:
> > src/kwindowsystem.cpp, lines 465-467
> > 
> >
> > I would prefer to not introduce new platform specific code in the 
> > shared part.
> > 
> > The idea you have here is right, but it's not OSX specific, the same 
> > applies for e.g. Wayland

I agree. This function should probably be moved to the plugin. That's just not 
a responsability I'd love to take for X11 and Wayland, otherwise I'd have 
implemented this in my patch.

Can you or one of the other KWindowSystem devs take care of this on the current 
supported platforms, so that I can adapt this patch?


> On Feb. 25, 2016, 8:26 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/plugin.h, line 2
> > 
> >
> > I'm not the author of this file

Actually, you apparently are the author of the template I used to create this 
file :)

(It's an oversight I didn't add myself though)


- René J.V.


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


On Feb. 23, 2016, 10:54 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126291/
> ---
> 
> (Updated Feb. 23, 2016, 10:54 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> KWindowSystem has been lacking a platform plugin for OS X. This RR presents a 
> "backport" of the modified KDE4 KWindowSystem implementation that has been 
> used in the MacPorts kdelibs4 port for the last 2 or 3 (or more) years.
> 
> I have made some initial steps to remove deprecated Carbon API calls, but 
> this is clearly a work in progress.
> 
> Open questions include
> - is there any justification to run an event handler (or Cocoa observer) to 
> keep track of running applications, possibly even listing all their open 
> windows?
> - is there any use for the Qt event listener framework (cf. the 
> NETEventFilter in the X11 plugin)? I haven't yet had time to try to figure 
> out what this "could be good for", and am very open to suggestions in this 
> departments.
> - one application for such an event filter would be a listener that catches 
> the opening and closing of all windows by the running process, and keeps 
> track of their `WId`s. A new method could then be added (to `KWindowInfo`?) 
> to distinguish `WId`s created by the running application from "foreign" ones 
> (useful also on Wayland and MS Windows).
> 
> `KWindowSystem::setMainWindow` should become a front for payload provided by 
> the plugins. I'll leave that to the regular/official maintainer(s) of this 
> framework.
> 
> This code could probably do with *lots* of comments; I'll try to add them as 
> questions about this or that bit of code arise.
> 
> 
> Diffs
> -
> 
>   src/debug_p.h 5ef8996 
>   src/debug_p.cpp 72abfb7 
>   src/kwindowsystem.cpp 407a67d 
>   src/platforms/osx/CMakeLists.txt 4fc3347 
>   src/platforms/osx/SCRAPBOOK PRE-CREATION 
>   src/platforms/osx/cocoa.json PRE-CREATION 
>   src/platforms/osx/kkeyserver.cpp 3ddb921 
>   src/platforms/osx/kwindowinfo.cpp e8555bb 
>   src/platforms/osx/kwindowinfo.mm PRE-CREATION 
>   src/platforms/osx/kwindowinfo_mac_p.h c8f307e 
>   src/platforms/osx/kwindowinfo_p_cocoa.h PRE-CREATION 
>   src/platforms/osx/kwindowsystem.cpp 1758829 
>   src/platforms/osx/kwindowsystem_mac_p.h PRE-CREATION 
>   src/platforms/osx/kwindowsystem_macobjc.mm PRE-CREATION 
>   src/platforms/osx/kwindowsystem_p_cocoa.h PRE-CREATION 
>   src/platforms/osx/plugin.h PRE-CREATION 
>   src/platforms/osx/plugin.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126291/diff/

Re: Review Request 127179: Add external extractor plugin support

2016-02-25 Thread Pinak Ahuja


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




src/externalextractor.cpp (line 104)


You should use the asynchronous api instead of blocking the event loop by 
calling waitForFinished()

Connect a slot to the QProcess::finished signal and let it handle the 
output of the QProcess.


- Pinak Ahuja


On Feb. 25, 2016, 6:32 p.m., Varun Joshi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127179/
> ---
> 
> (Updated Feb. 25, 2016, 6:32 p.m.)
> 
> 
> Review request for Baloo, KDE Frameworks, Boudhayan Gupta, and Vishesh Handa.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> 1. Add the ExternalExtractor class that wrap the external extractor process 
> into the standard Extractor interface
> 2. Modify ExtractorCollection to enable it to support ExternalExtractors
> 3. Added an example PyPDF2 extractor plugin
> 
> 
> Diffs
> -
> 
>   README.md 19b1a26a241e6a35c636aaf8162afe762018f073 
>   src/CMakeLists.txt a5490856a51aa2f59389ee963f3430c1ce5c60d5 
>   src/config-kfilemetadata.h.in PRE-CREATION 
>   src/externalextractor.h PRE-CREATION 
>   src/externalextractor.cpp PRE-CREATION 
>   src/extractorcollection.h 8542aed576102be2b0c86bbdf3d65d756d468c6e 
>   src/extractorcollection.cpp a1bde65bf57e493918cd3e85ccdb23c4cd623401 
>   src/extractorplugin.h 65abad3b2397628ba42a40d9ef2970e02114e250 
>   src/extractors/CMakeLists.txt 5dd223e1cf6864a943e848664ad5fae0d0603e77 
>   src/extractors/externalextractors/CMakeLists.txt PRE-CREATION 
>   src/extractors/externalextractors/pdfextractor/main.py PRE-CREATION 
>   src/extractors/externalextractors/pdfextractor/manifest.json PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127179/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Varun Joshi
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

2016-02-25 Thread Stephen Kelly



> On Feb. 24, 2016, 7:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> > 
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would 
> > expect the libs go in the same place, but maybe the plugins are affected by 
> > this? Can you be more specific?
> > 
> > Thanks,
> 
> Aleix Pol Gonzalez wrote:
> Well, Qt might be installing things in `$prefix/lib` and cmake in 
> `$prefix/lib64`. In fact, Qt by default installs plugins in `$prefix/plugins` 
> (which looks really odd, I agree).
> In any case, if it's meant to go to the same place, let's just ask Qt 
> where to go.
> 
> As you can see, all of the distros are already specifying this: (and they 
> don't need to in fact, because it's the same prefix)
> 
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kcoreaddons
> 
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkg-kde-tools/wily/view/head:/datalib/kf5_flags
> https://pkgs.fedoraproject.org/cgit/rpms/kf5.git/tree/macros.kf5
> 
> Nicolás Alvarez wrote:
> I don't think "all distros set it" is a valid argument for changing a 
> default, otherwise we would be setting `CMAKE_INSTALL_PREFIX=/usr` by default 
> too.

I agree with Nicolás that this seems wierd. Are packagers complaining about 
having to set this?

Also, I don't think I've seen enough specifics about the impact this has. What 
moves where etc.


- Stephen


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


On Feb. 24, 2016, 5:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated Feb. 24, 2016, 5:09 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
> might be controlled but usually won't.
> 
> In the end, otherwise, people need to keep adapting their systems with 
> environment variables anyway. All distros end up setting always this setting 
> as ON, as well as brave developers who don't have separate prefixes for Qt 
> and KDE.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake ebd48fa 
> 
> Diff: https://git.reviewboard.kde.org/r/127169/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

2016-02-25 Thread Albert Vaca Cintora


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


Ship it!




I don't see a reason not to change it.

It makes a lot of sense to install things in the same places as Qt, especially 
when Qt has to find the stuff we install.

- Albert Vaca Cintora


On feb. 24, 2016, 9:09 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated feb. 24, 2016, 9:09 a.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
> might be controlled but usually won't.
> 
> In the end, otherwise, people need to keep adapting their systems with 
> environment variables anyway. All distros end up setting always this setting 
> as ON, as well as brave developers who don't have separate prefixes for Qt 
> and KDE.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake ebd48fa 
> 
> Diff: https://git.reviewboard.kde.org/r/127169/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127179: Add external extractor plugin support

2016-02-25 Thread Boudhayan Gupta

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

The logic is more or less sound. You'll have to solve these issues.

I think you should try to get this patch merged first, before the writers. The 
code looks fine enough - I don't think when you apply the patch it'll depend on 
the writers RR.

Just edit the RR and remove the depends-on RR number.

src/externalextractor.h (line 40)

This isn't the proper way to do private classes.

Private classes are done like this:

1) In the header:
```
private:
struct ExternalExtractorPrivate;
ExternalExtractorPrivate *d_ptr;
Q_DECLARE_PRIVATE(ExternalExtractor);
```

Basically, the private class should be named ParentClassPrivate, the next 
line should create a ParentClassPrivate pointer called d_ptr (the variable name 
is important), and then you use the Q_DECLARE_PRIVATE(ParentClass) macro call 
(not ParentClassPrivate) to set up the accessor.

I've used the struct keyword instead of class because everything inside the 
public class is typically public - and in C++ structs are just classes where 
everything is public by default.

Doing it this way is better because the macros take care of casting the 
pointer correctly - suppose someone subclasses ParentClass to ChildClass, raw 
pointers won't work because it's still a pointer to ParentClass::Private, not 
ChildClass::Private.

2) When you use the d-pointer inside a function, do this:
```
someFunc()
{
Q_D(ParentClass) // not ParentClassPrivate
d->whatever = whatever;
}
```

Note that you're using d-> and not d_ptr->. The Q_D() macro automatically 
static_casts() the d_ptr into the appropriate type and makes a variable d 
(local to your function) that you can use to access the private class.

For more information, refer to:
https://wiki.qt.io/D-Pointer

src/externalextractor.cpp (line 46)

You'll need to create an object for the private class here too.

src/externalextractor.cpp (line 61)

All text needs to be translatable.

1) ```#include ```
2) Replace all ```string``` by ```i18n(string)```

src/externalextractor.cpp (line 83)

You're leaking memory. Have a destructor delete the private class object.

src/externalextractor.cpp (line 104)

You may want to wait for more than 5 seconds for large files. 30 seconds is 
a good idea.

src/externalextractor.cpp (line 108)

Clean this up. Vomit out the error output only if there's an error. There's 
no need to dump the extractor output in case there's no error.

src/extractorcollection.cpp (line 4)

Copyright who?

src/extractorcollection.cpp (line 81)

Cat-on-keyboard? ;-)

src/extractors/externalextractors/pdfextractor/main.py (line 40)

Remove empty space from this line.

- Boudhayan Gupta

On Feb. 26, 2016, 12:02 a.m., Varun Joshi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127179/
> ---
> 
> (Updated Feb. 26, 2016, 12:02 a.m.)
> 
> 
> Review request for Baloo, KDE Frameworks, Boudhayan Gupta, and Vishesh Handa.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> 1. Add the ExternalExtractor class that wrap the external extractor process 
> into the standard Extractor interface
> 2. Modify ExtractorCollection to enable it to support ExternalExtractors
> 3. Added an example PyPDF2 extractor plugin
> 
> 
> Diffs
> -
> 
>   README.md 19b1a26a241e6a35c636aaf8162afe762018f073 
>   src/CMakeLists.txt a5490856a51aa2f59389ee963f3430c1ce5c60d5 
>   src/config-kfilemetadata.h.in PRE-CREATION 
>   src/externalextractor.h PRE-CREATION 
>   src/externalextractor.cpp PRE-CREATION 
>   src/extractorcollection.h 8542aed576102be2b0c86bbdf3d65d756d468c6e 
>   src/extractorcollection.cpp a1bde65bf57e493918cd3e85ccdb23c4cd623401 
>   src/extractorplugin.h 65abad3b2397628ba42a40d9ef2970e02114e250 
>   src/extractors/CMakeLists.txt 5dd223e1cf6864a943e848664ad5fae0d0603e77 
>   src/extractors/externalextractors/CMakeLists.txt PRE-CREATION 
>   src/extractors/externalextractors/pdfextractor/main.py

Re: Review Request 127090: Clean KWalletQuery cmake file

2016-02-25 Thread Hrvoje Senjan


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



This is not 100% correct. KF5DocTools is searched nowhere, so doc subdir is now 
never added.

- Hrvoje Senjan


On Feb. 25, 2016, 1:34 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127090/
> ---
> 
> (Updated Feb. 25, 2016, 1:34 a.m.)
> 
> 
> Review request for KDE Frameworks and Valentin Rusu.
> 
> 
> Repository: kwallet
> 
> 
> Description
> ---
> 
> I saw it didn't build because I needed a build with KDocTools, ended up 
> cleaning a bit more.
> 
> 
> Diffs
> -
> 
>   src/runtime/kwallet-query/CMakeLists.txt 42b4687 
>   src/runtime/kwallet-query/src/main.cpp c19cb29 
> 
> Diff: https://git.reviewboard.kde.org/r/127090/diff/
> 
> 
> Testing
> ---
> 
> Built with and without KDocTools.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127179: Add external extractor plugin support

2016-02-25 Thread Varun Joshi


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

(Updated Feb. 25, 2016, 6:32 p.m.)


Review request for Baloo, KDE Frameworks, Boudhayan Gupta, and Vishesh Handa.


Repository: kfilemetadata


Description
---

1. Add the ExternalExtractor class that wrap the external extractor process 
into the standard Extractor interface
2. Modify ExtractorCollection to enable it to support ExternalExtractors
3. Added an example PyPDF2 extractor plugin


Diffs
-

  README.md 19b1a26a241e6a35c636aaf8162afe762018f073 
  src/CMakeLists.txt a5490856a51aa2f59389ee963f3430c1ce5c60d5 
  src/config-kfilemetadata.h.in PRE-CREATION 
  src/externalextractor.h PRE-CREATION 
  src/externalextractor.cpp PRE-CREATION 
  src/extractorcollection.h 8542aed576102be2b0c86bbdf3d65d756d468c6e 
  src/extractorcollection.cpp a1bde65bf57e493918cd3e85ccdb23c4cd623401 
  src/extractorplugin.h 65abad3b2397628ba42a40d9ef2970e02114e250 
  src/extractors/CMakeLists.txt 5dd223e1cf6864a943e848664ad5fae0d0603e77 
  src/extractors/externalextractors/CMakeLists.txt PRE-CREATION 
  src/extractors/externalextractors/pdfextractor/main.py PRE-CREATION 
  src/extractors/externalextractors/pdfextractor/manifest.json PRE-CREATION 

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


Testing
---


Thanks,

Varun Joshi

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127180: kdeinit: Prefer loading libraries from RUNPATH

2016-02-25 Thread Milian Wolff


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



Ah so that's it! I think I'm hit by the same issue on my work machine. I'll +1 
once I get to test this patch there (probably next week).

- Milian Wolff


On Feb. 25, 2016, 5:49 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127180/
> ---
> 
> (Updated Feb. 25, 2016, 5:49 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kinit
> 
> 
> Description
> ---
> 
> Prefer loading libraries from RUNPATH instead of only as fallback.
> 
> 
> Diffs
> -
> 
>   src/kdeinit/kinit.cpp 8b5c926 
> 
> Diff: https://git.reviewboard.kde.org/r/127180/diff/
> 
> 
> Testing
> ---
> 
> I have installed KF5 in separate prefix, kdeinit now loads libs from the 
> prefix instead of system path.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127180: kdeinit: Prefer loading libraries from RUNPATH

2016-02-25 Thread David Rosca


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

Review request for KDE Frameworks.


Repository: kinit


Description
---

Prefer loading libraries from RUNPATH instead of only as fallback.


Diffs
-

  src/kdeinit/kinit.cpp 8b5c926 

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


Testing
---

I have installed KF5 in separate prefix, kdeinit now loads libs from the prefix 
instead of system path.


Thanks,

David Rosca

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127177: Compilation fixes for MSVC (2013)

2016-02-25 Thread Thomas Friedrichsmeier


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

Review request for KDE Frameworks and kdewin.


Repository: ki18n


Description
---

Fix compilation on Windows with MSVC.

a) MSVC accepts declspec at global scope, only.
b) QStringLiteral does not work with concatenated literals in MSVC (see 
http://blog.qt.io/blog/2014/06/13/qt-weekly-13-qstringliteral/). Since the 
occurences seem to be mostly for debugging, going through QString::fromLatin1() 
in these cases should not hurt much.


Diffs
-

  src/kcatalog.cpp 083443d 
  src/ktranscript.cpp 72c3755 

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


Testing
---

Now builds with MSVC 2013.

No other compilers and no other platforms tested for this patch.


Thanks,

Thomas Friedrichsmeier

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127178: Added writer plugin support

2016-02-25 Thread Varun Joshi


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

Review request for Baloo, KDE Frameworks, Boudhayan Gupta, and Vishesh Handa.


Repository: kfilemetadata


Description
---

1. Added the Writer class similar to the Extractor class
2. Added the WriteData class that works like an ExtractionResult
3. Added WriterPlugin and WriterCollection that work similar to ExtractorPlugin 
and ExtractorCollection


Diffs
-

  README.md 19b1a26a241e6a35c636aaf8162afe762018f073 
  src/CMakeLists.txt a5490856a51aa2f59389ee963f3430c1ce5c60d5 
  src/writedata.h PRE-CREATION 
  src/writedata.cpp PRE-CREATION 
  src/writer.h PRE-CREATION 
  src/writer.cpp PRE-CREATION 
  src/writer_p.h PRE-CREATION 
  src/writercollection.h PRE-CREATION 
  src/writercollection.cpp PRE-CREATION 
  src/writerplugin.h PRE-CREATION 
  src/writerplugin.cpp PRE-CREATION 
  src/writers/CMakeLists.txt PRE-CREATION 
  src/writers/taglibwriter.h PRE-CREATION 
  src/writers/taglibwriter.cpp PRE-CREATION 

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


Testing
---


Thanks,

Varun Joshi

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127121: KWallet::openWallet(Synchronous) : time out after 1 hour rather than 25 seconds.

2016-02-25 Thread David Faure


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

(Updated Feb. 25, 2016, 12:16 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Valentin Rusu.


Changes
---

Submitted with commit 40f1fd03fc6d86f206322a100c5e1ead0df33493 by David Faure 
to branch master.


Repository: kwallet


Description
---

The default DBus timeout is 25 seconds, which means that if the user went to
get a cup of tea during session startup, when they come back they get prompted
with all sorts of additional non-kwallet password requests due to all kwallet
requests having timed out.

I added setTimeout in QDBusAbstractInterface in Qt 4.8 for things like this.

Testcase:
 eval `dbus-launch`
 export SSH_ASKPASS=$KDEDIR/bin/ksshaskpass
 ssh-add < /dev/null
(but the same happens with the IMAP resource etc.)


Diffs
-

  src/api/KWallet/kwallet.cpp b72edad19840943f70755c8668668a1881f1fb39 

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


Testing
---

(see commit log)


Thanks,

David Faure

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

Re: Review Request 127090: Clean KWalletQuery cmake file

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

Re: Review Request 127179: Add external extractor plugin support

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

Re: Review Request 127179: Add external extractor plugin support

Re: Review Request 127090: Clean KWalletQuery cmake file

Re: Review Request 127179: Add external extractor plugin support

Re: Review Request 127180: kdeinit: Prefer loading libraries from RUNPATH

Review Request 127180: kdeinit: Prefer loading libraries from RUNPATH

Review Request 127177: Compilation fixes for MSVC (2013)

Review Request 127178: Added writer plugin support

Re: Review Request 127121: KWallet::openWallet(Synchronous) : time out after 1 hour rather than 25 seconds.

20 matches

Site Navigation

Mail list logo

Footer information