Re: Review Request 123229: Ensure we don't crash when using KIO from non-QApplication process

[David Faure]

> On April 7, 2015, 3:38 p.m., Aleix Pol Gonzalez wrote:
> > src/widgets/jobuidelegate.cpp, line 391
> > 
> >
> > This is not correct, it's too early to figure out if it's going to have 
> > a QApplication or not. Breaks some test.

Which test? Can you be more specific?


- David


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


On Dec. 7, 2015, 1:29 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123229/
> ---
> 
> (Updated Dec. 7, 2015, 1:29 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Prevents the UiDelegate and UiTracker to get initialized, because they'll try 
> to create windows and dialogs when some things happen and these will 
> immediately end in a crash.
> 
> 
> Diffs
> -
> 
>   src/widgets/kdynamicjobtracker.cpp 14924d5 
> 
> Diff: https://git.reviewboard.kde.org/r/123229/diff/
> 
> 
> Testing
> ---
> 
> Ran the tests, my unit test doesn't crash anymore.
> 
> 
> 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 123229: Ensure we don't crash when using KIO from non-QApplication process

[David Faure]

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


I don't understand why the move to Q_COREAPP_STARTUP_FUNCTION. That startup 
function is only about creating some singleton, not about registering a KJob 
(which is where the qApp type check happens).

If the startup function needs to see a fully constructed app (why?) - then 
Q_COREAPP_STARTUP_FUNCTION is too early, it's called by the QCoreApplication 
constructor.
But I don't understand what was the problem with the function being called even 
earlier. Do we have a case where a kio job is created before the app is 
constructed? (that sounds wrong).

- David Faure


On Dec. 7, 2015, 1:29 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123229/
> ---
> 
> (Updated Dec. 7, 2015, 1:29 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Prevents the UiDelegate and UiTracker to get initialized, because they'll try 
> to create windows and dialogs when some things happen and these will 
> immediately end in a crash.
> 
> 
> Diffs
> -
> 
>   src/widgets/kdynamicjobtracker.cpp 14924d5 
> 
> Diff: https://git.reviewboard.kde.org/r/123229/diff/
> 
> 
> Testing
> ---
> 
> Ran the tests, my unit test doesn't crash anymore.
> 
> 
> 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 126185: Make the KAppTemplate CMake module global

[Alex Merry]

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



kde-modules/KDETemplateMacro.cmake (line 1)


Use function instead of macro: this prevents variables leaking 
accidentally. That will also allow removing the leading underscores on the 
variable names.



kde-modules/KDETemplateMacro.cmake (line 2)


You might want to consider using keyword arguments (ie: 
cmake_parse_arguments). This makes the function more extensible in the future.



kde-modules/KDETemplateMacro.cmake (lines 32 - 42)


Have a look at CMake's tar mode - run `cmake -E` and look at the tar 
command. This will mean the command won't depend on external utilities like 
7-zip.



kde-modules/KDETemplateMacro.cmake (line 45)


To make this slightly more general, consider passing in the install 
destination as an argument, or at least allowing that as a possibility. The 
actual directory could (should?) be put into KDEInstallDirs.cmake as an extra 
variable.


- Alex Merry


On Dec. 3, 2015, 12:34 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 3, 2015, 12:34 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDETemplateMacro.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 126185: Make the KAppTemplate CMake module global

[Alex Merry]

> On Dec. 3, 2015, 11:49 p.m., Aleix Pol Gonzalez wrote:
> > kde-modules/KDETemplateMacro.cmake, line 1
> > 
> >
> > You might want to add documentation.
> > 
> > You can get inspired with 
> > `kde-modules/KDEFrameworkCompilerSettings.cmake` or 
> > `modules/ECMInstallIcons.cmake`. Note it's also lacking the copyright 
> > header.

And you'll need to add a reference to the module to get Sphinx to find it - 
look at the files in docs/kde-module


- Alex


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


On Dec. 3, 2015, 12:34 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 3, 2015, 12:34 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDETemplateMacro.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

kdelibs4support forces "icons in buttons"?

[René J . V . Bertin]

Hi,

I have the strong impression that applications using the kdelibs4support fw are 
forced to show icons in buttons, regardless of the corresponding setting (which 
is respected elsewhere).
For some reason it does not happen when I use the native platform plugin on OS 
X, but if the frameworkintegration platform plugin were responsible I'd expect 
icons to appear on buttons in all applications, including those not using 
kdelibs4support.

What's going on here? As far as I can see kdelibs4support does indeed support 
the key from kdeglobals; maybe the return value from the functions reading the 
key value is not used?

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

Re: RFC: split platformtheme plugin from frameworkintegration and move to kde/workspace

[Mark Gaiser]

On Tue, Dec 8, 2015 at 7:49 AM, Martin Graesslin  wrote:

> On Monday, December 7, 2015 3:54:31 PM CET Mark Gaiser wrote:
> > While at it. Why does frameworkintegration force [1] specific fonts upon
> > the user?
> >
> > It's fine that apparently some folks prefer Oxygen fonts over all else,
> but
> > i thoroughly dislike it.
> > I always end up blacklisting it in my pacman manager (pacman, archlinux)
> > since 99% of the time when i have font issues, it's because of that
> package
> > being installed.
>
> We cannot find a font which makes everybody happy. This is impossible, so
> please let's not derail the discussion.
>

Ok.

> >
> > Regarding your proposal. When running KDE apps on something other then
> > Plasma, you would also want to have the frameworksintegration plugin to
> be
> > loaded, right?
>
> No. As I outlined, it would not get loaded as the required env variables
> are
> set by startkde. I doubt that GNOME is announcing the KDE_SESSION_VERSION
> env
> variable.
>

I did not mention gnome. I don't mean any particular desktop environment,
just others in general.

>
> > Specially the platformtheme folder with the vastly improved dialogs over
> > stock Qt. Remember, those improved dialogs have the power of KIO behind
> it
> > instead of the default Qt support (only the local filesystem)
>
> On other desktop environments it should pick the platform's native dialog.
> E.g. on GNOME we want to give users the GNOME's file dialog to have an
> integrated experience. Please don't start about GNOME's dialog being not
> that
> good as ours. That's not the point. We want GTK applications to pick our
> file
> dialog in Plasma and we want our application's to pick GNOME's file dialog
> in
> GNOME. Our subjective feeling of superior user experience is pointless if
> the
> user is used to the platform's file dialog.
>

You're right and wrong.
In a Plasma VS GNOME world where either one will be used as the users
desktop environment, you're right.

It's not that black and white though. There are much more desktop
environments out there. Specifically (but not only) those that are also
using the Qt framework, but not plasma. They would feel the change you're
proposing, in a negative way.
Take for instance LXQt, that would really benefit from this in their
dialogs without dragging in plasma dependencies.
Other examples are openbox where a user wants to use mostly Qt
applications, Or tilling environments, same story. You force them to drag
in plasma if this part moves to the workspace.

Right now we're in a - imho - perfectly fine situation where one can get
all the Qt + Framework integration goodness with just setting an
environment variable.
I'm in favor of keeping it that way.

Quote: "Please don't start about GNOME's dialog being not that good as
ours. That's not the point."
Really.. I did not say gnome. I said better then the stock Qt (file)
dialogs. Stop assuming that i mean GNOME with this mail, i just don't


>
> >
> > I really see value in having that usable in - say - openbox or any other
> > non plasma environment where people would want to open KDE applications
> > that make use of framework libraries (like KIO).
>
> which is still possible. They need to install the package and set the env
> variables. That's the same as right now: they need to install the package
> and
> set the env variables. It's not an automagically works anyway.
>

Yes, but they will drag in plasma, just for that. I would not consider that
good.

>
> >
> > Isn't the only plasma specific part the KStyle folder?
>
> No.
>
> Cheers
> Martin
>
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125869: Convert all io slave .protocol data to json and embed it.

[Andrew McCann]

> On Nov. 3, 2015, 9:47 p.m., Albert Astals Cid wrote:
> > How does this work without modifying 
> > KProtocolInfoPrivate::KProtocolInfoPrivate?
> 
> Christoph Cullmann wrote:
> You mean the JSON stuff? That was implemented in 
> https://git.reviewboard.kde.org/r/125830/
> For the http slave, that already works nicely, but we missed that 
> "ExtraNames" as used by other slaves need i18n care.
> 
> Albert Astals Cid wrote:
> i see, i did not see that there's two almost copied 
> KProtocolInfoPrivate::KProtocolInfoPrivate implementations
> 
> So the json magic stuff (you can see 
> ./src/ioslaves/http/kcookiejar/kcookiejar.json in kio) only works for 
> Description and Name inside KPlugin, someone would need to update 
> createjsoncontext.py and filljsonfrompo.py so they also take into account 
> ExtraNames inside childs of "KDE-KIO-Protocols" and then make that new code 
> from 125830 extract the correct translation from the json.
> 
> Alex Richardson wrote:
> Reading the translated string can be done using 
> `KPluginMetaData::readTranslatedString()`
> 
> Christoph Cullmann wrote:
> Hmm, Ok, can take a look at that scripts. Will it be a problem that the 
> ExtraNames are a stringlist or is that fine?
> 
> Albert Astals Cid wrote:
> You'll have to take care of serializing and unserializing the list, 
> ideally using a well known marker like ; or similar. The scripts are at 
> https://websvn.kde.org/trunk/l10n-kf5/scripts/
> 
> Christoph Cullmann wrote:
> Hi, ok, started to take a look at that again ;=) Is there actually any 
> way to get all entries out of KConfig for all locales in the .ini? Atm I 
> struggle a bit with the fact that the localized keys are hidden from any 
> keys() accessor I can get from the outside.

+1 on having an application for this diff to be applied.  I abandoned my own 
diff that did nearly the same thing. https://git.reviewboard.kde.org/r/126038/


- Andrew


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


On Nov. 1, 2015, 6:13 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125869/
> ---
> 
> (Updated Nov. 1, 2015, 6:13 p.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid, Alex Richardson, David 
> Faure, and Luigi Toscano.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Convert all io slave .protocol data to json and embed it.
> Allows easier deployment of the slaves.
> 
> 
> Diffs
> -
> 
>   src/ioslaves/http/CMakeLists.txt 76a8e28 
>   src/ioslaves/help/main_ghelp.cpp 59c8558 
>   src/ioslaves/help/main.cpp 9939196 
>   src/ioslaves/help/help.protocol 1deefe5 
>   src/ioslaves/help/help.json PRE-CREATION 
>   src/ioslaves/help/ghelp.protocol d2a642a 
>   src/ioslaves/help/ghelp.json PRE-CREATION 
>   src/ioslaves/help/CMakeLists.txt 867b59d 
>   src/ioslaves/ftp/ftp.protocol 4c5f80c 
>   src/ioslaves/ftp/ftp.json PRE-CREATION 
>   src/ioslaves/ftp/ftp.cpp 382723a 
>   src/ioslaves/ftp/CMakeLists.txt 04f5600 
>   src/ioslaves/file/file.protocol 523c0f5 
>   src/ioslaves/file/file.json PRE-CREATION 
>   src/ioslaves/file/file.cpp 5ef1587 
>   src/ioslaves/file/CMakeLists.txt cb85cfb 
>   autotests/kprotocolinfotest.cpp fa3ad38 
>   src/ioslaves/http/http.protocol 49e5dc5 
>   src/ioslaves/http/https.protocol c15d06f 
>   src/ioslaves/http/webdav.protocol 05c977a 
>   src/ioslaves/http/webdavs.protocol d5e4b2f 
>   src/ioslaves/trash/CMakeLists.txt 05161cd 
>   src/ioslaves/trash/kio_trash.cpp cb23169 
>   src/ioslaves/trash/trash.json PRE-CREATION 
>   src/ioslaves/trash/trash.protocol 7430575 
> 
> Diff: https://git.reviewboard.kde.org/r/125869/diff/
> 
> 
> Testing
> ---
> 
> Tests still work (one needed patching, as the exec line contains now the full 
> path).
> 
> Correction: Somehow the ./autotests/jobtest test is unstable for me here, 
> sometimes it works, sometimes not :/ but even without this change.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

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

Re: Review Request 126038: Add protocol info to KIO plugin metadata

[Andrew McCann]

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

(Updated Dec. 8, 2015, 6:31 p.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks and Christoph Cullmann.


Repository: kio


Description
---

Add protocol info to KIO plugin metadata.  This is necessary to get KDevelop to 
work on OSX in an app bundle.

This continues work done by Christoph Cullmann in 
https://git.reviewboard.kde.org/r/125830/

Followed the same pattern as the aforementioned diff.

protocol.json files were generated using the protocoltojson utility.


Diffs
-

  src/ioslaves/file/file.cpp 381e4885bf0e78ceb4b06f1f1657ad4068923a84 
  src/ioslaves/file/file.json PRE-CREATION 
  src/ioslaves/ftp/ftp.cpp 2179179e966d97ce24784292ef67812fa1d3361d 
  src/ioslaves/ftp/ftp.json PRE-CREATION 
  src/ioslaves/help/ghelp.json PRE-CREATION 
  src/ioslaves/help/help.json PRE-CREATION 
  src/ioslaves/help/main.cpp 9939196b4fc4aefd52c2c13717609181429fe891 
  src/ioslaves/help/main_ghelp.cpp 59c85587af5edf767261a6b3ca66e6f37efecd29 
  src/ioslaves/trash/kio_trash.cpp 81cc0361d22606f54d31e6ce743cd5fe818a4701 
  src/ioslaves/trash/kio_trash_win.cpp 9dd857f3dd9aebaef9e8d9e5adfc30adb0c1ae6b 
  src/ioslaves/trash/trash.json PRE-CREATION 

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


Testing
---

With this patch applied, my development version of kdevelop on OSX was able to 
find:
(logging statements were added by me, but not in this diff)

```
{ Found Plugin path  
"/Users/mccann/src/kde_playground/kdevelop_bundle_dest/Applications/kdevelop.app/Contents/PlugIns/kf5/kio/file.so"
   protocol contains  "file"
}
{ Found Plugin path  
"/Users/mccann/src/kde_playground/kdevelop_bundle_dest/Applications/kdevelop.app/Contents/PlugIns/kf5/kio/ftp.so"
   protocol contains  "ftp"
}
{ Found Plugin path  
"/Users/mccann/src/kde_playground/kdevelop_bundle_dest/Applications/kdevelop.app/Contents/PlugIns/kf5/kio/ghelp.so"
   protocol contains  "ghelp"
}
{ Found Plugin path  
"/Users/mccann/src/kde_playground/kdevelop_bundle_dest/Applications/kdevelop.app/Contents/PlugIns/kf5/kio/help.so"
   protocol contains  "help"
}
{ Found Plugin path  
"/Users/mccann/src/kde_playground/kdevelop_bundle_dest/Applications/kdevelop.app/Contents/PlugIns/kf5/kio/http.so"
   protocol contains  "http"
   protocol contains  "https"
   protocol contains  "webdav"
   protocol contains  "webdavs"
}
{ Found Plugin path  
"/Users/mccann/src/kde_playground/kdevelop_bundle_dest/Applications/kdevelop.app/Contents/PlugIns/kf5/kio/trash.so"
   protocol contains  "trash"
}
```


Thanks,

Andrew McCann

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

Re: Purpose as a KDE Framework

[Alex Merry]

On 2015-12-03 18:29, Aleix Pol wrote:

On Wed, Dec 2, 2015 at 11:56 PM, Mark Gaiser  wrote:

I'm trying to understand what Purpose is doing exactly.
I've read the readme file, but i still can't quite figure out what 
it's

doing or where i might be able to use it.

Could you give a short summary with a clear example where to use it? 
That

would help me :)


Well, the shortcut to explaining it is that it's quite similar to
Android intents.

The idea is that you identify some tasks you can group, for example:
- share, where you can get the different services to share
- getImage that would list your scanner, camera and also some web 
services.

- addContact that would let you add a contact on your address book or
gmail directly.

Then you receive the results in a nice and simple tuple. The input and
output arguments depend on the kind of task you are performing.


Could you integrate this into your README.md? I had the same issue as 
Mark, and the examples really help.


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

Re: Review Request 125800: OS X build and warning fix

[Samuel Gaist]

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

(Updated Dec. 8, 2015, 8:46 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Ivan Romanov.


Repository: qca


Description
---

The cmake find file was missing, but CoreFoundation being a system
framework, no need to search for it.

OS X: Update code to not use deprecated functions/data structure

CSSM_DATA and SecCertificateGetData have been deprecated since 10.7.
This patch uses SecCertificateCopyData which is the official
replacement.


Diffs
-

  CMakeLists.txt dbce08272deb284f3cb0fd09ccfec4ab93ce3e23 
  src/CMakeLists.txt a60bda0bf3d8bad7523ee7d50798c8cdb6c2eccb 
  src/qca_systemstore_mac.cpp 9349c90c8258d3d1f00a3796d93f94c09f5b1f2a 

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


Testing
---

Build on OS X 10.8

Check that qcatool-qt5 keystore list-stores returns the same results


Thanks,

Samuel Gaist

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

Re: Review Request 126285: OS X build and warning fix

[Samuel Gaist]

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

(Updated Dec. 8, 2015, 8:48 p.m.)


Review request for KDE Frameworks and Ivan Romanov.


Repository: qca


Description
---

Revert "Add missed file"

This reverts commit 4c9f27270e0a7c00c10cbc56ce5c6842b47e5ab2.

FindCoreFoundation.cmake is not needed since CoreFoundation
is a system framework. Its use has been removed by
commit f223ce03d4b94ffbb093fc8be5adf8d968f54434


Diffs
-

  CMakeLists.txt 051ae6d26111725d3a296a124e8c1772e37c9940 
  cmake/modules/FindCoreFoundation.cmake 
c08e529ceec337c085f2f650f180b4e7897246bb 
  src/CMakeLists.txt a60bda0bf3d8bad7523ee7d50798c8cdb6c2eccb 
  src/qca_systemstore_mac.cpp 9349c90c8258d3d1f00a3796d93f94c09f5b1f2a 

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


Testing
---


Thanks,

Samuel Gaist

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

Re: Review Request 126039: When configfile is loaded from resource, do not issue file not found error

[Milian Wolff]

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

Ship it!


Ship It!

- Milian Wolff


On Nov. 12, 2015, 11:15 p.m., Andrew McCann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126039/
> ---
> 
> (Updated Nov. 12, 2015, 11:15 p.m.)
> 
> 
> Review request for KDE Frameworks, Christoph Cullmann and Jeremy Whiting.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> When configfile is loaded from resource, do not issue file not found error.
> 
> Encountered this problem while attempting to make KDevelop work on OSX as an 
> app bundle.
> 
> Concretely, the logic error here is that the file actually is loaded and is 
> aborting early. 
> 
> If the file were actually not found, the following code block that tests for 
> validity will error anyway.
> 
> 
> Diffs
> -
> 
>   src/core/engine.cpp 56912ddfa8312ea6233aecffda296f041b180237 
> 
> Diff: https://git.reviewboard.kde.org/r/126039/diff/
> 
> 
> Testing
> ---
> 
> Verify that loading configfile from qt5's resource system ex 
> ":/kconfig/test.knsrc" now works and didn't before.
> 
> 
> Thanks,
> 
> Andrew McCann
> 
>

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

Re: Review Request 126039: When configfile is loaded from resource, do not issue file not found error

[Jeremy Whiting]

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

Ship it!


Works for me, sorry I missed this somehow.

- Jeremy Whiting


On Nov. 12, 2015, 4:15 p.m., Andrew McCann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126039/
> ---
> 
> (Updated Nov. 12, 2015, 4:15 p.m.)
> 
> 
> Review request for KDE Frameworks, Christoph Cullmann and Jeremy Whiting.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> When configfile is loaded from resource, do not issue file not found error.
> 
> Encountered this problem while attempting to make KDevelop work on OSX as an 
> app bundle.
> 
> Concretely, the logic error here is that the file actually is loaded and is 
> aborting early. 
> 
> If the file were actually not found, the following code block that tests for 
> validity will error anyway.
> 
> 
> Diffs
> -
> 
>   src/core/engine.cpp 56912ddfa8312ea6233aecffda296f041b180237 
> 
> Diff: https://git.reviewboard.kde.org/r/126039/diff/
> 
> 
> Testing
> ---
> 
> Verify that loading configfile from qt5's resource system ex 
> ":/kconfig/test.knsrc" now works and didn't before.
> 
> 
> Thanks,
> 
> Andrew McCann
> 
>

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

Re: RFC: split platformtheme plugin from frameworkintegration and move to kde/workspace

[Martin Graesslin]

On Tuesday, December 8, 2015 6:03:47 PM CET Mark Gaiser wrote:
> I thought the frameworkintegration plugin was exactly that and usable for
> any platform if they wish to use it.
> Or is my assumption wrong and is it really only for Plasma and should
> others stay away from it?

well obviously it's only for plasma as it's bound to env variables set by 
startkde. And in 4.x time the qpt plugin was in kde-workspace repo, see:
https://quickgit.kde.org/?p=kde-workspace.git=blob=4f67cc55104fe1081b05d381e9516e0215f8e24a=1b97d4427257120e305408404bff5ec6be0b65a9=qguiplatformplugin_kde
%2Fqguiplatformplugin_kde.cpp

> 
> My assumption can very well be wrong, but then i think we need to have a
> "base" frameworkintegration that every app dev can use with or without
> plasma. And a plasma specific version that integrates more in plasma i
> suppose.

I don't think it's anything an app developer should care about. It's 
integration, that's not something the app developer picks - otherwise the app 
breaks on integrating with other platforms.

> I don't care for that either. It's logical and to be expected.
> I do care when i want to use the KF5 filedialog and need to install plasma
> (which has absolutely nothing to do with the dialog) just to get it.
> With "use" i mean the file open dialog, not the ones you can just call from
> the C++ side of things.
> 
> And i definitely do not want to make a QPA just to have that working.

Well you have to. The file dialog is part of integration. If you want to have 
a specific integration you need to provide a QPT (not QPA) plugin. Application 
developers must keep away from that.

Please also read up on the topic of why KFileDialog got removed from our API.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel