Re: C++11 policy in frameworks?

[Jeremy Whiting]

https://trac.macports.org/browser/trunk/dports/lang/llvm-3.7/Portfile I
thought this was clang 3.7 maybe I'm confused though
On Feb 8, 2015 1:39 PM, Albert Astals Cid aa...@kde.org wrote:

 El Diumenge, 8 de febrer de 2015, a les 09:55:05, Jeremy Whiting va
 escriure:
  Hey all,
 
  In trying to get kf5 built on an older machine with clang 3.7 I've hit an
  isuse with kdeclarative.

 clang 2.7 or 3.7?

 3.7 is still unreleased, no?

 Cheers,
   Albert

  A few days ago some code was checked into it that
  uses std::lround which isn't available on clang's stdlib implementation
  yet. Should this change to floor or ciel, or is there an #ifdef we can
 put
  around it depending if C++11 support is available when building? Or is
  C++11 not allowed in frameworks yet (just applications) so it should be
  changed to use some other method to round the values (floor(value + 0.5)
 or
  something similar)?
 
  thanks,
  Jeremy

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

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

Review Request 122493: Use math.h round rather than C++11 std::lround.

[Jeremy Whiting]

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

Review request for KDE Frameworks and Marco Martin.


Repository: kdeclarative


Description
---

Use math.h round rather than C++11 std::lround.

Removes dependency on C++11.


Diffs
-

  src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 
67ce63a943234b167165b0f3986f974bba5ff0cf 

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


Testing
---

kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and 
standard library.


Thanks,

Jeremy Whiting

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

Re: Review Request 122481: Fix use of environ for OS X

[Jeremy Whiting]

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

(Updated Feb. 8, 2015, 8:24 p.m.)


Review request for KDE Frameworks, David Faure, Marko Käning, and René J.V. 
Bertin.


Changes
---

Thanks for the idea, changed to use QProcessEnvironment.


Repository: kio


Description
---

On OS X 10.7 environ needs to be #defined as _NSGetEnviron() from 
crt_externs.h according to man environ. This is also required for kio to 
build on OS X 10.7


Diffs (updated)
-

  src/widgets/kurlcompletion.cpp 1871c49a936e2ca322286e23ad6fe976ae2c7044 

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


Testing
---

kio builds with this patch on OS X 10.7 and 10.10


Thanks,

Jeremy Whiting

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

Re: Framework Categories

[Jeremy Whiting]

Ok, I've changed knewstuff to a solution type. Should all frameworks that
depend on kio be also changed to solution type ?

On Tue, Feb 3, 2015 at 11:54 PM, Kevin Ottens er...@kde.org wrote:

 On Tuesday 03 February 2015 12:53:08 Jeremy Whiting wrote:
  Hey frameworks developers,
 
  Albert wrote a couple weeks ago:
   As far as i remember, functional means you can use it standalone,
 solution
   means it needs a daemon and integraion means it needs more stuff (more
   daemons?
 
  Is this categorization correct? Has it been checked with a dependency
  analysis to see that each functional framework is usable standalone? I
  understood the tiers concept but never did get my head around the
  functional/integration/solution concept yet, but would like to.


 https://community.kde.org/Frameworks/Policies#Frameworks_have_a_Tier_and_a_Type

  At any
  rate, I think KNewStuff which I'm very familiar with doesn't seem to be
  usable standalone as the functional status it has implies. It depends on
  and uses KIO for all network downloads and uploads, which requires a
 daemon
  as far as I can tell (and is a solution) so should KNewStuff be changed
 to
  a solution also probably?

 Sounds like it yes.

 Regards.
 --
 Kévin Ottens, http://ervin.ipsquad.net

 KDAB - proud supporter of KDE, http://www.kdab.com


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


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

Framework Categories

[Jeremy Whiting]

Hey frameworks developers,

Albert wrote a couple weeks ago:
 As far as i remember, functional means you can use it standalone, solution
 means it needs a daemon and integraion means it needs more stuff (more
 daemons?

Is this categorization correct? Has it been checked with a dependency
analysis to see that each functional framework is usable standalone? I
understood the tiers concept but never did get my head around the
functional/integration/solution concept yet, but would like to. At any
rate, I think KNewStuff which I'm very familiar with doesn't seem to be
usable standalone as the functional status it has implies. It depends on
and uses KIO for all network downloads and uploads, which requires a daemon
as far as I can tell (and is a solution) so should KNewStuff be changed to
a solution also probably?

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

Re: [Kde-games-devel] Freeze in 6 weeks

[Jeremy Whiting]

Albert, Frameworks developers/maintainers,

On Thu, Jan 29, 2015 at 12:43 PM, Albert Astals Cid aa...@kde.org wrote:

 El Dijous, 29 de gener de 2015, a les 10:05:01, Inge Wallin va escriure:
  On Wednesday, January 28, 2015 20:47:44 Albert Astals Cid wrote:
   El Dimecres, 28 de gener de 2015, a les 14:04:14, Inge Wallin va
 escriure:
On Wednesday, January 28, 2015 07:38:23 laurent Montel wrote:
 I am agree with Albert if there is a problem with
 network-transparency
 on
 MacOsX it's better to fix it that remove it.
   
That is not the issue. The issue is that it was promised that if you
developed your program with KDE Frameworks 5 instead of KDElibs, you
would
get a more lightweight program that did not need any daemons to run.
   
Now this turns out to be not true.   *That* is what we want, not to
remove
network transparency per se. But if the promise from frameworks 5 is
 not
kept, what is there to be done?
  
   Really? Who promised you that? That's never been the promise, the
 promise
   of KF5 is that it's more modular, and yes there's some libs that don't
   need extra daemons and some that do need them.
 
  I actually tried to do some research to find this promise in writing but
  except for pointing it out as a problem in an article on the dot I
 couldn't
  find any written promise.

 The list on http://api.kde.org/frameworks-api/frameworks5-apidocs/ has
 three
 items, functional, solution, integration.

 As far as i remember, functional means you can use it standalone, solution
 means it needs a daemon and integraion means it needs more stuff (more
 daemons?


Is this categorization correct? Has it been checked with a dependency
analysis to see that each functional framework is usable standalone? I
understood the tiers concept but never did get my head around the
functional/integration/solution concept yet, but would like to. At any
rate, I think KNewStuff which I'm very familiar with doesn't seem to be
usable standalone as the functional status it has implies. It depends on
and uses KIO for all network downloads and uploads, which requires a daemon
as far as I can tell (and is a solution) so should KNewStuff be changed to
a solution also probably?


  But I do remember bringing up this problem in a
  number of conversations with frameworks developers early in the
 development
  cycle.  One of those times was in a frameworks meeting at Akademy in
  Tampere.
 
  And the developers did say that bringing down the amount of
 infrastructure
  that the first KDE application on an alien platform started was one of
 the
  motivations for frameworks. Not the only one, of course, but still an
  important one.
 
 And this problem will be in other application.
 It's not just a problem with kdegames so fix it for kdegames will
 fix
 for
 all application.

 We can't remove feature each time we need to fix on a specific
 platform
 no
 ?
   
Yes, it will be in other applications.  But that is the price you
 have
to
pay for platform portability sometimes.
   
I never thought it was reasonable to have to start the full KDE
 desktop
infrastructure just to run an application from the KDE on, say,
 Gnome.
But
that's what we had to do back in the kdelibs days. Frameworks 5 was
supposed to get rid of that but now it turns out that it doesn't.
 The
question is: is this just not yet implemented or was this design goal
abandoned?
  
   What is the full KDE desktop infraestructure for you?
 
  Let's skip the word full, since I don't really know every nook and
 crannie
  of the kde infrastructure.  But to start several daemons to be able to
  access a file on another server seems like overkill.  Even one, in fact.

 Why starting a program to do something is an overkill? If i want to
 convert a
 pdf to a ps, running pdftops seems totally legit to me.

 Cheers,
   Albert

 
  I understand (or at least I think I do) that kded is an optimisation that
  loads all the shared libraries once so that all the subsequent kde
  applications don't have to do it. Instead they are forked off from kded
 with
  the libraries already loaded.  This is a good idea if you know for sure
  that you will be running a whole slew of such applications. But this is
 not
  a very strong guess on non-KDE platforms and even less so on non-linux
  platforms.
 
-Inge
 
   Cheers,
  
 Albert
  
This is what we need to focus on. Network transparency is *not* the
issue.
   
  Cheers,
 
Albert
 
   Cheers, Ian W.
  
   ___
   kde-games-devel mailing list
   kde-games-de...@kde.org
   https://mail.kde.org/mailman/listinfo/kde-games-devel
 
  ___
  kde-games-devel mailing list
  kde-games-de...@kde.org
  https://mail.kde.org/mailman/listinfo/kde-games-devel
   

Re: Review Request 122210: KCmdLineArgs: Fix -version handling

[Jeremy Whiting]

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

Ship it!


Ship It!

- Jeremy Whiting


On Jan. 22, 2015, 1:43 p.m., Albert Astals Cid wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122210/
 ---
 
 (Updated Jan. 22, 2015, 1:43 p.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: kdelibs4support
 
 
 Description
 ---
 
 Remove the TODO and fix the i18n usage
 
 
 Diffs
 -
 
   src/kdecore/kcmdlineargs.cpp de2f829 
 
 Diff: https://git.reviewboard.kde.org/r/122210/diff/
 
 
 Testing
 ---
 
 konsole -v is no longer ugly as hell
 
 
 Thanks,
 
 Albert Astals Cid
 


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

Re: Review Request 122105: Fix KgDifficulty saving on app close

[Jeremy Whiting]

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

Ship it!


Ship It!

- Jeremy Whiting


On Jan. 17, 2015, 4:53 a.m., Albert Astals Cid wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122105/
 ---
 
 (Updated Jan. 17, 2015, 4:53 a.m.)
 
 
 Review request for KDE Frameworks and KDE Games.
 
 
 Repository: libkdegames
 
 
 Description
 ---
 
 Since you can't use KSharedConfig::openConfig from a static destructor 
 anymore (the QCoreApplication is gone and thus can't find the name of the 
 thing) use a post routine to save the level before the QCoreApplication is 
 gone.
 
 KF5 people: Is this something worth mentioning on the porting notes or using 
 KSharedConfig::openConfig from a static destructor is a bit of a corner case 
 anyway?
 
 
 Diffs
 -
 
   kgdifficulty.cpp 94489c7 
 
 Diff: https://git.reviewboard.kde.org/r/122105/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Albert Astals Cid
 


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

Re: Review Request 121448: Introduce ECMAddAppIcon.

[Jeremy Whiting]

 On Dec. 12, 2014, 7:08 a.m., Alex Merry wrote:
  modules/ECMAddAppIcon.cmake, line 15
  https://git.reviewboard.kde.org/r/121448/diff/1/?file=332663#file332663line15
 
  Would this actually work? The code looks to me like pattern_rx would 
  just be the filename again, so fn would be empty, and the icon would never 
  be appended to _list.
 
 Ralf Habacker wrote:
 The doc in the origin cmake macro file seems to be out of sync with the 
 official doc located in FindKDE4Internals.cmake, which is: 
 
 ---
 #  adds an application icon to target source list.
 #  Make sure you have a 128x128 icon, or the icon won't display on Mac OS 
 X.
 #  Mac OSX notes : the application icon is added to a Mac OS X bundle so 
 that Finder and friends show the right thing.
 #  Win32 notes: the application icon(s) are compiled into the application
 #  There is some workaround in kde4_add_kdeinit_executable to make it 
 possible for those applications as well.
 # Parameters:
 #  SRCS_VAR  - specifies the list of source files
 #  pattern   - regular expression for searching application icons
 #  Example: KDE4_ADD_APP_ICON( myapp_SOURCES pics/cr*-myapp.png)
 #  Example: KDE4_ADD_APP_ICON( myapp_KDEINIT_SRCS 
 icons/oxygen/*/apps/myapp.png)
 ---
 
 normal file mode is not documentated and does not work
 
 Alex Merry wrote:
 I would still much prefer an API to match ecm_add_icons, as I noted at 
 the start of this review. Would you be willing to do that? If not, I can 
 probably find some time over Christmas to look at it.
 
 Ralf Habacker wrote:
 Just one question: As it turns out that the macro used in KDE4 only 
 supports a simple pattern style and no single files, what is different or 
 has been extended with KDE5 to require this now ?
 
 Alex Merry wrote:
 Best CMake practices include listing all source files in the 
 CMakeLists.txt file, rather than globbing them. That way, CMake knows when a 
 file has been added (or removed), because the CMakeLists.txt file will 
 change, and so it will automatically reconfigure when you run `make`. The 
 icon installation function (`ecm_add_icons`) was changed to support and 
 encourage that approach, and I think this function should also change to 
 match it.
 
 Additionally, I would like consistency between interfaces. Having 
 ecm_add_app_icon behave completely differently to ecm_add_icons just makes 
 things that much harder for users of e-c-m. They should use the same file 
 naming scheme (or compatible schemes, at least), and similar arguments, in so 
 far as they need similar information.
 
 I'll admit it makes porting a little harder, but it should be possible to 
 create a porting script without too much difficulty.
 
 Jeremy Whiting wrote:
 Ralf any updates on this patch?
 
 Ralf Habacker wrote:
 @Alex, you wrote
  The icon installation function (ecm_add_icons) 
 
 you are refering to ecm_install_icons ? 
 
 was changed to support and encourage that approach, and I think this 
 function should also change to match it.
 
 What could be matched ? As far as I can see only the ICONS parameter, all 
 other parameter do not match by design. :-(
 
 Merging the ICONS parameter with recent ecm_add_app_icon parameter list 
 will have the following syntax: 
   
 1.  ecm_add_app_icon(source_var ICONS icon [icon [...]])
 
 the additional mentioned syntax forms are not supported by 
 ecm_install_icons so we are free to choose what we like. 
 
 According to http://www.cmake.org/cmake/help/v3.0/command/install.html 
 the mentioned term 'PATTERN' only supports '*' at the end of files and 
 therefore does not fit into the recent implementation. 
 
 So the term 'GLOB' which is defined in the cmake file command 
 http://www.cmake.org/cmake/help/v3.0/command/file.html remains and fit into 
 what is implemented in the patch
 
 2.   ecm_add_app_icons(source_var GLOB icon-glob-expression) [1]
 
 and
 
 3.ecm_add_app_icon(source_var icon-glob-expression) [1]
 
 because ecm_install_icons also have a compatibility mode to support old 
 style parameter list: 
 
  From 
 https://projects.kde.org/projects/kdesupport/extra-cmake-modules/repository/revisions/master/entry/modules/ECMInstallIcons.cmake
 An old form of arguments will also be accepted::
 #   ecm_install_icons(icon_install_dir [l10n_code])
 
 
 syntax 3 is what is already implemented by the recent patch. 
 
 Can we agree ? 
 
 @Jeremey:
 1. Syntax 3 is already implemented and need only a few spelling fixed 
 before commit. 
 2. Currently I do not have any access to a Mac/OSX development machine, 
 so I can only cover the windows part. Is there anyone having access to a Mac 
 OSX development machine

Re: Review Request 121448: Introduce ECMAddAppIcon.

[Jeremy Whiting]

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


Ralf,  Can you update the diff rather than uploading the file? It's much easier 
to apply a diff than to figure out where to put this file and if any other 
changes are needed to use it, etc.

- Jeremy Whiting


On Dec. 15, 2014, 1:01 a.m., Ralf Habacker wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121448/
 ---
 
 (Updated Dec. 15, 2014, 1:01 a.m.)
 
 
 Review request for Extra Cmake Modules, KDE Frameworks and Laurent Navet.
 
 
 Repository: extra-cmake-modules
 
 
 Description
 ---
 
 This module, which has been migrated from the related KDE4 macto 
 kde4_app_app_icon,
 supports platform specific application icon for Windows and Mac OSX.
 
 On Windows this function depends on the external tool png2ico, which is
 provided by the kdewin-tools binary package. Sources are available at
 https://projects.kde.org/projects/kdesupport/kdewin.
 
 
 Diffs
 -
 
   modules/ECMAddAppIcon.cmake PRE-CREATION 
 
 Diff: https://git.reviewboard.kde.org/r/121448/diff/
 
 
 Testing
 ---
 
 
 File Attachments
 
 
 ECMAddAppIcon.cmake
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/12/12/a05ee2b5-64e3-4e44-ae34-4e1b7110e5f1__ECMAddAppIcon.cmake
 ECMAddAppIcon.cmake
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/12/15/8b3e226f-a70b-4998-983a-813730a436bf__ECMAddAppIcon.cmake
 ECMAddAppIcon.cmake
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/12/15/8433995f-b88f-426d-af54-46aba635ae1e__ECMAddAppIcon.cmake
 
 
 Thanks,
 
 Ralf Habacker
 


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

Re: Review Request 121448: Introduce ECMAddAppIcon.

[Jeremy Whiting]

 On Dec. 12, 2014, 7:08 a.m., Alex Merry wrote:
  modules/ECMAddAppIcon.cmake, line 15
  https://git.reviewboard.kde.org/r/121448/diff/1/?file=332663#file332663line15
 
  Would this actually work? The code looks to me like pattern_rx would 
  just be the filename again, so fn would be empty, and the icon would never 
  be appended to _list.
 
 Ralf Habacker wrote:
 The doc in the origin cmake macro file seems to be out of sync with the 
 official doc located in FindKDE4Internals.cmake, which is: 
 
 ---
 #  adds an application icon to target source list.
 #  Make sure you have a 128x128 icon, or the icon won't display on Mac OS 
 X.
 #  Mac OSX notes : the application icon is added to a Mac OS X bundle so 
 that Finder and friends show the right thing.
 #  Win32 notes: the application icon(s) are compiled into the application
 #  There is some workaround in kde4_add_kdeinit_executable to make it 
 possible for those applications as well.
 # Parameters:
 #  SRCS_VAR  - specifies the list of source files
 #  pattern   - regular expression for searching application icons
 #  Example: KDE4_ADD_APP_ICON( myapp_SOURCES pics/cr*-myapp.png)
 #  Example: KDE4_ADD_APP_ICON( myapp_KDEINIT_SRCS 
 icons/oxygen/*/apps/myapp.png)
 ---
 
 normal file mode is not documentated and does not work
 
 Alex Merry wrote:
 I would still much prefer an API to match ecm_add_icons, as I noted at 
 the start of this review. Would you be willing to do that? If not, I can 
 probably find some time over Christmas to look at it.
 
 Ralf Habacker wrote:
 Just one question: As it turns out that the macro used in KDE4 only 
 supports a simple pattern style and no single files, what is different or 
 has been extended with KDE5 to require this now ?
 
 Alex Merry wrote:
 Best CMake practices include listing all source files in the 
 CMakeLists.txt file, rather than globbing them. That way, CMake knows when a 
 file has been added (or removed), because the CMakeLists.txt file will 
 change, and so it will automatically reconfigure when you run `make`. The 
 icon installation function (`ecm_add_icons`) was changed to support and 
 encourage that approach, and I think this function should also change to 
 match it.
 
 Additionally, I would like consistency between interfaces. Having 
 ecm_add_app_icon behave completely differently to ecm_add_icons just makes 
 things that much harder for users of e-c-m. They should use the same file 
 naming scheme (or compatible schemes, at least), and similar arguments, in so 
 far as they need similar information.
 
 I'll admit it makes porting a little harder, but it should be possible to 
 create a porting script without too much difficulty.

Ralf any updates on this patch?


- Jeremy


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


On Dec. 15, 2014, 1:01 a.m., Ralf Habacker wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121448/
 ---
 
 (Updated Dec. 15, 2014, 1:01 a.m.)
 
 
 Review request for Extra Cmake Modules, KDE Frameworks and Laurent Navet.
 
 
 Repository: extra-cmake-modules
 
 
 Description
 ---
 
 This module, which has been migrated from the related KDE4 macto 
 kde4_app_app_icon,
 supports platform specific application icon for Windows and Mac OSX.
 
 On Windows this function depends on the external tool png2ico, which is
 provided by the kdewin-tools binary package. Sources are available at
 https://projects.kde.org/projects/kdesupport/kdewin.
 
 
 Diffs
 -
 
   modules/ECMAddAppIcon.cmake PRE-CREATION 
 
 Diff: https://git.reviewboard.kde.org/r/121448/diff/
 
 
 Testing
 ---
 
 
 File Attachments
 
 
 ECMAddAppIcon.cmake
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/12/12/a05ee2b5-64e3-4e44-ae34-4e1b7110e5f1__ECMAddAppIcon.cmake
 ECMAddAppIcon.cmake
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/12/15/8b3e226f-a70b-4998-983a-813730a436bf__ECMAddAppIcon.cmake
 ECMAddAppIcon.cmake
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/12/15/8433995f-b88f-426d-af54-46aba635ae1e__ECMAddAppIcon.cmake
 
 
 Thanks,
 
 Ralf Habacker
 


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

Re: Review Request 121895: Fix local issues in KIO build

[Jeremy Whiting]

 On Jan. 7, 2015, 5:35 a.m., Jeremy Whiting wrote:
  Ship It!

Fixes it here.


- Jeremy


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


On Jan. 7, 2015, 4:52 a.m., Aleix Pol Gonzalez wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121895/
 ---
 
 (Updated Jan. 7, 2015, 4:52 a.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: kio
 
 
 Description
 ---
 
 Fix KIO build, otherwise I get the following error:
 ``` /home/kde-devel/frameworks/kio/src/kioexec/main.cpp:47:24: fatal error: 
 KStartupInfo: No such file or directory```
 ``` #include KStartupInfo```
 
 
 Diffs
 -
 
   src/kioexec/CMakeLists.txt 1f08845 
 
 Diff: https://git.reviewboard.kde.org/r/121895/diff/
 
 
 Testing
 ---
 
 Now it builds.
 
 
 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 121895: Fix local issues in KIO build

[Jeremy Whiting]

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

Ship it!


Ship It!

- Jeremy Whiting


On Jan. 7, 2015, 4:52 a.m., Aleix Pol Gonzalez wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121895/
 ---
 
 (Updated Jan. 7, 2015, 4:52 a.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: kio
 
 
 Description
 ---
 
 Fix KIO build, otherwise I get the following error:
 ``` /home/kde-devel/frameworks/kio/src/kioexec/main.cpp:47:24: fatal error: 
 KStartupInfo: No such file or directory```
 ``` #include KStartupInfo```
 
 
 Diffs
 -
 
   src/kioexec/CMakeLists.txt 1f08845 
 
 Diff: https://git.reviewboard.kde.org/r/121895/diff/
 
 
 Testing
 ---
 
 Now it builds.
 
 
 Thanks,
 
 Aleix Pol Gonzalez
 


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

Re: Some more projects in need of respecting KF5_INSTALL_TARGETS_DEFAULT_ARGS

[Jeremy Whiting]

I hit the same issues reported by Marko here on OS X also, and have no
KDE_INSTALL_DIRS_NO_DEPRECATED set either. Maybe the logic in ecm is broken
somehow?

On Wed, Jan 7, 2015 at 11:48 AM, Alex Merry alex.me...@kde.org wrote:

 On Tuesday 06 January 2015 23:55:48 Marko Käning wrote:
  P.P.S.: I realised by now that there are no changes on the production
  branch, which probably means that there was some change in ECM or
 wherever
  provoking these issues...

 I'm somewhat puzzled, as INSTALL_TARGET_DEFAULT_ARGS should still be set
 (to
 the same value as KDE_INSTALL_TARGET_DEFAULT_ARGS) unless you have set
 KDE_INSTALL_DIRS_NO_DEPRECATED to some TRUE-ish value. If not, that's a
 bug.

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

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

Re: OSX/CI: kio-extras fails to build on branch master

[Jeremy Whiting]

Well, I just attempted to try building kio-extras (I guess it's in
kde/workspace in projects.kde.org right? And my qt build doesn't have dbus
somehow, what do you use when you configure Qt to build in the CI system ?
I've been talking to thiago in #qt and he said some of his changes just hit
the 5.4 branch to make it default but I tried with configure with -dbus
which said it would build dbus runtime but I have no QtDBusConfig.cmake
for kio-extras to find and build with still.

thanks,
Jeremy

On Tue, Jan 6, 2015 at 2:41 PM, Marko Käning mk-li...@email.de wrote:

 Hi Jeremy,

 On 06 Jan 2015, at 22:39 , Jeremy Whiting jpwhit...@kde.org wrote:

  I think this is the same problem that kconfig had last week. i.e. we
 need to change INSTALL_TARGET_ARGS to KDE_INSTALL_TARGET_ARGS. I'll take a
 look.

 yes, see the discussion with Milian and Christopher in thread “OSX/CI:
 konsole fails to build on branch master”.

 Thanks for taking care of this,
 Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Some more projects in need of respecting KF5_INSTALL_TARGETS_DEFAULT_ARGS

[Jeremy Whiting]

Yes, ecm changed recently.

On Tue, Jan 6, 2015 at 3:55 PM, Marko Käning mk-li...@email.de wrote:

 Hi Christoph,

 I’ve found that these projects do not make use of
 KF5_INSTALL_TARGETS_DEFAULT_ARGS
 at the moment:

  - systemsettings
  - muon
  - rocs
  - libkdegames
  - kiten
  - cantor
  - kolourpaint
  - libkmahjongg

 See for details below in order of appearance.

 I figure this is only the beginning of it and more projects might turn up
 in the future.

 Thanks for taking care of these.

 Regards,
 Marko




 P.S.: I’ve tested locally to prepend KF5_” to INSTALL_TARGETS_DEFAULT_ARGS
   for project systemsettings only, which worked fine and made the
 project
   install successfully again here on my OSX/CI system.




 P.P.S.: I realised by now that there are no changes on the production
 branch,
 which probably means that there was some change in ECM or wherever
 provoking these issues...




 ---

 systemsettings:

 CMake Error at core/CMakeLists.txt:37 (install):
   install TARGETS given no LIBRARY DESTINATION for shared library target
   systemsettingsview”.
 ---

 muon:

 CMake Error at libmuon/notifiers/CMakeLists.txt:7 (install):
   install TARGETS given no LIBRARY DESTINATION for shared library target
   MuonNotifiers.

 CMake Error at libmuon/CMakeLists.txt:63 (install):
   install TARGETS given no LIBRARY DESTINATION for shared library target
   muonprivate”.
 ---

 rocs:

 CMake Error at libgraphtheory/CMakeLists.txt:106 (install):
   install TARGETS given no LIBRARY DESTINATION for shared library target
   rocsgraphtheory”.
 ---

 libkdegames:

 CMake Error at CMakeLists.txt:163 (install):
   install TARGETS given no LIBRARY DESTINATION for shared library target
   KF5KDEGames.

 CMake Error at CMakeLists.txt:222 (install):
   install TARGETS given no LIBRARY DESTINATION for shared library target
   KF5KDEGamesPrivate”.
 ---

 kiten:

 CMake Error at lib/CMakeLists.txt:37 (install):
   install TARGETS given no LIBRARY DESTINATION for shared library target
   kiten.
 ---

 cantor:

 CMake Error at src/lib/CMakeLists.txt:75 (install):
   install TARGETS given no LIBRARY DESTINATION for shared library target
   cantorlibs”.

 CMake Error at src/CMakeLists.txt:25 (install):
   install TARGETS given no LIBRARY DESTINATION for shared library target
   cantor_config.
 ---

 kolourpaint:

 CMake Error at CMakeLists.txt:579 (install):
   install TARGETS given no LIBRARY DESTINATION for shared library target
   kolourpaint_lgpl.
 ---

 libkmahjongg:

 CMake Error at CMakeLists.txt:64 (install):
   install TARGETS given no LIBRARY DESTINATION for shared library target
   KF5KMahjongglib.

 CMake Error at CMakeLists.txt:67 (install):
   install TARGETS given no LIBRARY DESTINATION for shared library target
   KF5KMahjongglib.
 ---

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

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

Re: Review Request 121833: add reviewboardrc, targets kdeframeworks and plasma groups

[Jeremy Whiting]

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

Ship it!


Ship It!

- Jeremy Whiting


On Jan. 4, 2015, 8:19 a.m., Harald Sitter wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121833/
 ---
 
 (Updated Jan. 4, 2015, 8:19 a.m.)
 
 
 Review request for KDE Frameworks and Plasma.
 
 
 Repository: kpackage
 
 
 Description
 ---
 
 add reviewbaordrc, targets kdeframeworks and plasma groups
 
 
 Diffs
 -
 
   .reviewboardrc PRE-CREATION 
 
 Diff: https://git.reviewboard.kde.org/r/121833/diff/
 
 
 Testing
 ---
 
 made this here review request
 
 
 Thanks,
 
 Harald Sitter
 


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

Re: Review Request 121792: Make KAboutData::setupCommandLine call addHelpOption and addVersionOption

[Jeremy Whiting]

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

Ship it!


Looks good to me, except you removed the r on the end of parser in the comment 
:)

- Jeremy Whiting


On Jan. 3, 2015, 2:36 p.m., Albert Astals Cid wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121792/
 ---
 
 (Updated Jan. 3, 2015, 2:36 p.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: kcoreaddons
 
 
 Description
 ---
 
 It's something we used to do somewhere in kdelibs4 so people don't expect 
 them to have to call this stuff manually. Also gives us some consistency.
 
 
 Diffs
 -
 
   src/lib/kaboutdata.h 5564dab 
   src/lib/kaboutdata.cpp f8d5e30 
 
 Diff: https://git.reviewboard.kde.org/r/121792/diff/
 
 
 Testing
 ---
 
 Ran one of my apps, now i have help and version.
 
 
 Thanks,
 
 Albert Astals Cid
 


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

Re: Review Request 121773: Fix build without X.

[Jeremy Whiting]

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



src/kdesud/kdesud.cpp
https://git.reviewboard.kde.org/r/121773/#comment50720

Why not use if HAVE_X11  !defined(Q_OS_MAC) to keep that fix in place?


- Jeremy Whiting


On Dec. 31, 2014, 3:23 a.m., Michael Palimaka wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121773/
 ---
 
 (Updated Dec. 31, 2014, 3:23 a.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: kdesu
 
 
 Description
 ---
 
 This fixes breakage introduced by 5de62b90fdaece965876af8f991d48640f21
 since HAVE_X11 is always defined (0 or 1), and reverts 
 163d9f1598596cfe8090f21c2562e25e64ad151b
 since it's just a workaround for OSX for the aforementioned breakage.
 
 
 Diffs
 -
 
   src/kdesud/kdesud.cpp 337e37a50b9d10ae8c0839f6d26e67de6a9418d9 
 
 Diff: https://git.reviewboard.kde.org/r/121773/diff/
 
 
 Testing
 ---
 
 Build passes again, both with and without X.
 
 
 Thanks,
 
 Michael Palimaka
 


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

Re: Review Request 121773: Fix build without X.

[Jeremy Whiting]

 On Dec. 31, 2014, 5:52 a.m., Jeremy Whiting wrote:
  src/kdesud/kdesud.cpp, line 76
  https://git.reviewboard.kde.org/r/121773/diff/1/?file=337535#file337535line76
 
  Why not use if HAVE_X11  !defined(Q_OS_MAC) to keep that fix in place?
 
 Michael Palimaka wrote:
 !defined(Q_OS_MAC) was only added after the incorrect logic 
 defined(HAVE_X11) was introduced (because defined(HAVE_X11) is always true). 
 HAVE_X11 will always be false on OSX since find_package(X11) always fails. 
 This is consistent with the rest of kdesu, as well as other frameworks with 
 optional X.

Ah, makes sense to me, thanks.


- Jeremy


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


On Dec. 31, 2014, 3:23 a.m., Michael Palimaka wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121773/
 ---
 
 (Updated Dec. 31, 2014, 3:23 a.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: kdesu
 
 
 Description
 ---
 
 This fixes breakage introduced by 5de62b90fdaece965876af8f991d48640f21
 since HAVE_X11 is always defined (0 or 1), and reverts 
 163d9f1598596cfe8090f21c2562e25e64ad151b
 since it's just a workaround for OSX for the aforementioned breakage.
 
 
 Diffs
 -
 
   src/kdesud/kdesud.cpp 337e37a50b9d10ae8c0839f6d26e67de6a9418d9 
 
 Diff: https://git.reviewboard.kde.org/r/121773/diff/
 
 
 Testing
 ---
 
 Build passes again, both with and without X.
 
 
 Thanks,
 
 Michael Palimaka
 


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

Re: Review Request 121496: Fix build if the X11 headers are not located in /usr/include

[Jeremy Whiting]

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

Ship it!


Ship It!

- Jeremy Whiting


On Dec. 13, 2014, 8:02 p.m., Alexander Richardson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121496/
 ---
 
 (Updated Dec. 13, 2014, 8:02 p.m.)
 
 
 Review request for KDE Frameworks and Martin Gräßlin.
 
 
 Repository: kcrash
 
 
 Description
 ---
 
 Fix build if the X11 headers are not located in /usr/include
 
 
 Diffs
 -
 
   src/CMakeLists.txt 9038adc2d5c61cf03132751fba9333f75ac4a561 
 
 Diff: https://git.reviewboard.kde.org/r/121496/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Alexander Richardson
 


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

Re: Review Request 121401: Add Windows VERSIONINFO to KF5CoreAddons.dll

[Jeremy Whiting]

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


This probably shouldn't go in until ecm has a release with that other change in 
it, right ? Otherwise anyone building on windows will need ecm from git (do 
they already?)

- Jeremy Whiting


On Dec. 8, 2014, 10:01 p.m., Nicolás Alvarez wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121401/
 ---
 
 (Updated Dec. 8, 2014, 10:01 p.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: kcoreaddons
 
 
 Description
 ---
 
 Add a Windows VERSIONINFO resource to KF5CoreAddons.dll, using the new macro 
 in ECM (see /r/121400).
 
 
 Diffs
 -
 
   src/lib/CMakeLists.txt b2b46b1 
 
 Diff: https://git.reviewboard.kde.org/r/121401/diff/
 
 
 Testing
 ---
 
 Tested with CMake 3.0.2, MSVC2013, Windows 7. Explorer tooltip shows 
 description and version. File properties shows all the new information.
 
 
 Thanks,
 
 Nicolás Alvarez
 


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

Re: KF 5.5.0 changelog

[Jeremy Whiting]

Looks good to me on the attica/knewstuff entries.

On Sat, Dec 6, 2014 at 7:59 AM, David Faure fa...@kde.org wrote:

 Here's the changelog I wrote for 5.5.0.

 Please everyone remember to use CHANGELOG in your commits, with
 a standalone description of the issue (i.e. which doesn't use the modified
 filenames as implicit context).

 I tried to grab what I could from the commit logs, but I don't always
 understand everything in e.g. plasma-framework.

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

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


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

Re: Review Request 121356: Do not change the volume when playing a notification

[Jeremy Whiting]

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

Ship it!


Ship It!

- Jeremy Whiting


On Dec. 4, 2014, 2:12 p.m., Albert Astals Cid wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121356/
 ---
 
 (Updated Dec. 4, 2014, 2:12 p.m.)
 
 
 Review request for KDE Frameworks and David Edmundson.
 
 
 Repository: knotifications
 
 
 Description
 ---
 
 Playing a notification should be that, playing a notification.
 
 Inspired by David's comment on https://git.reviewboard.kde.org/r/121278/
 
 
 Diffs
 -
 
   src/notifybysound.cpp 09a80dd 
 
 Diff: https://git.reviewboard.kde.org/r/121356/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Albert Astals Cid
 


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

Re: Review Request 121265: Make modified flag work for KMainWindow::setCaption(QString, bool)

[Jeremy Whiting]

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



src/kmainwindow.cpp
https://git.reviewboard.kde.org/r/121265/#comment49591

what if caption already contains [*] ? Shouldn't we check for that and only 
append the  [*] if it's not there already ?


- Jeremy Whiting


On Nov. 26, 2014, 8:10 p.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121265/
 ---
 
 (Updated Nov. 26, 2014, 8:10 p.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: kxmlgui
 
 
 Description
 ---
 
 The API dox of KMainWindow::setCaption(const QString caption, bool modified) 
 claims that the flag modified specifies whether the document is modified. 
 This displays an additional sign in the title bar, usually *.
 See 
 http://api.kde.org/frameworks-api/frameworks5-apidocs/kxmlgui/html/classKMainWindow.html#aa78364d5eeb1c1f5bd333c733378741d
 
 Currently that is not true. Instead a warning is shown on the console:
 QWidgetPrivate::setWindowModified_helper: QWidget::setWindowModified: The 
 window title does not contain a '[*]' placeholder
 
 When 'KDialog::setCaption(QString, bool)' was moved to 
 'KMainWindow::setCaption(QString, bool)' for kf5, it was dumped that the old 
 code also called ' makeStandardCaption(...)' which would add a custom 
 [modified] string if the 'modified' flag was set. See 
 http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/kdialog_8cpp_source.html#l00475
 
 Now KMainWindow uses the 'windowModified' property of 'QWidget', and if doing 
 so, the windowtitle needs a placeholder where to put the modified marker, by 
 the form of [*]. See 
 https://qt-project.org/doc/qt-5/qwidget.html#windowTitle-prop
 
 This patch proposes to comply to the API and to add that placeholder, so the 
 method behaves as expected. It does not use [modified] flag like the 
 kde4libs variant of the code did, but by using the Qt placeholder perhaps can 
 even integrate better into the platform (not sure if there is a hook yet).
 
 
 Diffs
 -
 
   src/kmainwindow.cpp 9562318 
 
 Diff: https://git.reviewboard.kde.org/r/121265/diff/
 
 
 Testing
 ---
 
 Modified is now properly marked to Off or On in the window title, when 
 'KMainWindow::setCaption(QString,bool)' is used. Tested with Okteta.
 
 
 Thanks,
 
 Friedrich W. H. Kossebau
 


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

Re: Review Request 121153: Restore filedialog show() functionality for modal dialogs

[Jeremy Whiting]

 On Nov. 17, 2014, 4:33 p.m., Jeremy Whiting wrote:
  I tested this here and FileDialog qml still hangs the ui with this patch. 
  (though at least the dialog appears)
 
 Martin Klapetek wrote:
 Yes, QML still hangs, not sure why though. Looking into it.
 
 Martin Klapetek wrote:
 So I've spent a considerable amount of time on this but to no avail. I've 
 even rewritten significant portion of our file dialog to match the gtk2 
 platform theme plugin one, but it still wouldn't work.
 
 I'm at a loss here, sorry...
 
 Albert Astals Cid wrote:
 Then maybe use https://git.reviewboard.kde.org/r/121098/diff/# since 
 Jeremy says qml dialogs work there?

No I discarded that patch, that makes qml dialogs work, but also makes the 
dialog show up twice when used from QFileDialog::anystaticmethod as seen from 
the standarddialogs qt example app.


- Jeremy


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


On Nov. 17, 2014, 10:46 a.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121153/
 ---
 
 (Updated Nov. 17, 2014, 10:46 a.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 Based on https://git.reviewboard.kde.org/r/121098/ and on the GTK2 platform 
 theme, which does the modal show() like this.
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformfiledialoghelper.cpp 44eca19 
 
 Diff: https://git.reviewboard.kde.org/r/121153/diff/
 
 
 Testing
 ---
 
 All kinds of file dialogs from tests/qfiledialogtest work as expected
 
 
 Thanks,
 
 Martin Klapetek
 


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

Re: Review Request 121098: Restore filedialog functionality for modal dialogs.

[Jeremy Whiting]

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

(Updated Nov. 17, 2014, 9:39 a.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks and Eike Hein.


Repository: frameworkintegration


Description
---

Before David's astyle commit, the show method used to call m_dialog-exec
if the window flags weren't nonmodal (i.e. modal dialogs). This got removed 
somehow.
BUG:334963


Diffs
-

  src/platformtheme/kdeplatformfiledialoghelper.cpp 
44eca192946f0da2b357b33e93a57ef0de05135b 

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


Testing
---

fifteen puzzle config with patch from https://git.reviewboard.kde.org/r/121097/ 
now shows the dialog and lets you choose a file.


Thanks,

Jeremy Whiting

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

Review Request 121163: Also allow absolute filepaths for configfile parameter.

[Jeremy Whiting]

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

Review request for KDE Frameworks and Jeremy Whiting.


Repository: knewstuff


Description
---

Also allow absolute filepaths for configfile parameter.


Diffs
-

  src/core/engine.cpp 7fae48a09aa88565ab1bfafcbff23494fabf75b1 

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


Testing
---


Thanks,

Jeremy Whiting

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

Re: Review Request 121163: Also allow absolute filepaths for configfile parameter.

[Jeremy Whiting]

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

(Updated Nov. 17, 2014, 11:28 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Jeremy Whiting.


Repository: knewstuff


Description
---

Also allow absolute filepaths for configfile parameter.


Diffs
-

  src/core/engine.cpp 7fae48a09aa88565ab1bfafcbff23494fabf75b1 

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


Testing
---


Thanks,

Jeremy Whiting

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

Re: Review Request 121153: Restore filedialog show() functionality for modal dialogs

[Jeremy Whiting]

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


I tested this here and FileDialog qml still hangs the ui with this patch. 
(though at least the dialog appears)

- Jeremy Whiting


On Nov. 17, 2014, 10:46 a.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121153/
 ---
 
 (Updated Nov. 17, 2014, 10:46 a.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 Based on https://git.reviewboard.kde.org/r/121098/ and on the GTK2 platform 
 theme, which does the modal show() like this.
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformfiledialoghelper.cpp 44eca19 
 
 Diff: https://git.reviewboard.kde.org/r/121153/diff/
 
 
 Testing
 ---
 
 All kinds of file dialogs from tests/qfiledialogtest work as expected
 
 
 Thanks,
 
 Martin Klapetek
 


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

Re: Review Request 121098: Restore filedialog functionality for modal dialogs.

[Jeremy Whiting]

 On Nov. 14, 2014, 4:16 p.m., Martin Klapetek wrote:
  src/platformtheme/kdeplatformfiledialoghelper.cpp, lines 301-303
  https://git.reviewboard.kde.org/r/121098/diff/1/?file=327582#file327582line301
 
  Looking at QDialog docs, it says
  
  modal : bool
  This property holds whether show() should pop up the dialog as modal or 
  modeless.
  
  So as the modal is being set here, shouldn't the if (windowModality == 
  Qt::NonModal) { just be removed instead and always call show()?

Yep, I've tried just removing the if, that makes it appear when the static 
QFileDialog methods are called, but you can't interact with it. Clicking 
anywhere in the dialog itself does nothing. As reported here: 
https://bugs.kde.org/show_bug.cgi?id=334963


- Jeremy


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


On Nov. 10, 2014, 11:17 a.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121098/
 ---
 
 (Updated Nov. 10, 2014, 11:17 a.m.)
 
 
 Review request for KDE Frameworks and Eike Hein.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 Before David's astyle commit, the show method used to call m_dialog-exec
 if the window flags weren't nonmodal (i.e. modal dialogs). This got removed 
 somehow.
 BUG:334963
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformfiledialoghelper.cpp 
 44eca192946f0da2b357b33e93a57ef0de05135b 
 
 Diff: https://git.reviewboard.kde.org/r/121098/diff/
 
 
 Testing
 ---
 
 fifteen puzzle config with patch from 
 https://git.reviewboard.kde.org/r/121097/ now shows the dialog and lets you 
 choose a file.
 
 
 Thanks,
 
 Jeremy Whiting
 


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

Re: Review Request 121098: Restore filedialog functionality for modal dialogs.

[Jeremy Whiting]

 On Nov. 14, 2014, 4:16 p.m., Martin Klapetek wrote:
  src/platformtheme/kdeplatformfiledialoghelper.cpp, lines 301-303
  https://git.reviewboard.kde.org/r/121098/diff/1/?file=327582#file327582line301
 
  Looking at QDialog docs, it says
  
  modal : bool
  This property holds whether show() should pop up the dialog as modal or 
  modeless.
  
  So as the modal is being set here, shouldn't the if (windowModality == 
  Qt::NonModal) { just be removed instead and always call show()?
 
 Jeremy Whiting wrote:
 Yep, I've tried just removing the if, that makes it appear when the 
 static QFileDialog methods are called, but you can't interact with it. 
 Clicking anywhere in the dialog itself does nothing. As reported here: 
 https://bugs.kde.org/show_bug.cgi?id=334963
 
 Martin Klapetek wrote:
 The main issue I see here is that show() is always expected to not block; 
 if the QML dialogs wanted to use the blocking version, it would internally 
 just call exec() rather than show(). So putting blocking exec() into show() 
 is imho not right.
 
 Have you tried investigating why the dialog cannot be interacted with? I 
 can have a look if you want

I think removing the if is the right solution, but I've no idea where to start 
looking to figure out why it's not interactive. If you've got some ideas I can 
do the digging, otherwise you can look into it. I'm fine either way, just want 
to get the underlying issue solved.


- Jeremy


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


On Nov. 10, 2014, 11:17 a.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121098/
 ---
 
 (Updated Nov. 10, 2014, 11:17 a.m.)
 
 
 Review request for KDE Frameworks and Eike Hein.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 Before David's astyle commit, the show method used to call m_dialog-exec
 if the window flags weren't nonmodal (i.e. modal dialogs). This got removed 
 somehow.
 BUG:334963
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformfiledialoghelper.cpp 
 44eca192946f0da2b357b33e93a57ef0de05135b 
 
 Diff: https://git.reviewboard.kde.org/r/121098/diff/
 
 
 Testing
 ---
 
 fifteen puzzle config with patch from 
 https://git.reviewboard.kde.org/r/121097/ now shows the dialog and lets you 
 choose a file.
 
 
 Thanks,
 
 Jeremy Whiting
 


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

Review Request 121115: Use all of QT_PLUGIN_PATH paths rather than just QLibraryInfo path to look for plugins.

[Jeremy Whiting]

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

Review request for KDE Frameworks and Frederik Gladhorn.


Repository: attica


Description
---

Use all of QT_PLUGIN_PATH paths rather than just QLibraryInfo path to look for 
plugins.


Diffs
-

  src/providermanager.cpp ce04fc9df122c4284fe046801547b5b67d8b72e8 

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


Testing
---

Without this change, the attica_kde.so plugin isn't found even if it's 
installed to a path that is in QT_PLUGIN_PATH. With this change it loads 
correctly.


Thanks,

Jeremy Whiting

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

Re: Review Request 121115: Use all of QT_PLUGIN_PATH paths rather than just QLibraryInfo path to look for plugins.

[Jeremy Whiting]

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

(Updated Nov. 14, 2014, 1:02 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Frederik Gladhorn.


Repository: attica


Description
---

Use all of QT_PLUGIN_PATH paths rather than just QLibraryInfo path to look for 
plugins.


Diffs
-

  src/providermanager.cpp ce04fc9df122c4284fe046801547b5b67d8b72e8 

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


Testing
---

Without this change, the attica_kde.so plugin isn't found even if it's 
installed to a path that is in QT_PLUGIN_PATH. With this change it loads 
correctly.


Thanks,

Jeremy Whiting

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

Re: Review Request 121100: Add qCDebug statements back into knewstuff sources.

[Jeremy Whiting]

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

(Updated Nov. 12, 2014, 2:01 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: knewstuff


Description
---

Add qCDebug statements back into knewstuff sources.


Diffs
-

  tests/knewstuff2_standard.cpp e44628b549ea5ad3b002c3a11eac298b92b5a6ae 
  tests/khotnewstuff.cpp 1aba7de48a8b7cf7f8886957fc473bf0cc631a13 
  tests/knewstuff2_cache.cpp e7e8a48666237f468d986e99a8c472fe37fd7a77 
  tests/knewstuff2_download.cpp 39d756e30f5b4f56f9254ae1e08c0d8310daf4d1 
  src/staticxml/staticxmlprovider.cpp 434ecef0b71543bf4504c9781d1d3a21b9cf6e34 
  src/ui/entrydetailsdialog.cpp 8a36d33f9a390a211313b11fba65030261a54446 
  src/ui/itemsgridviewdelegate.cpp 19ddc59eb4acbb2b7a591119453be407d01d9a9f 
  src/ui/itemsmodel.cpp 0254e88a5c16a2f8c5818a45bb7ec28eef4973e8 
  src/ui/itemsviewbasedelegate.cpp 5137beb93ee8cccd15b28b9a9f47eff60fc17fc8 
  src/ui/itemsviewdelegate.cpp 5e9b985cc155d141664a944b3d2bd1e751d96136 
  src/uploaddialog.cpp 1a087b30a7fc6198062f0f7a012ae37ed6f396af 
  src/core/engine.cpp 017154323cfd3f48fc61c0c705d4842f3c2f94a4 
  src/core/entryinternal.cpp d3af619e9908b2f9e6176c7c87eda44897e93f0a 
  src/core/installation.cpp d8de905bd2d19d098fb08a64897f5617f04e996d 
  src/core/upload.cpp 166e69417b687fef6e89ef7fb5c383ec478c5c2d 
  src/core/xmlloader.cpp 2cee02b66f8ec2a0f1fc407aaadd0ea397b89939 
  src/downloadmanager.cpp 60d0d37ef0bd35efdcfe5e6ac58fefb3a2ce9954 
  src/downloadwidget.cpp 358bb8b5222ac596dd3f0025778cd2721c1f3120 
  src/entry.h df3095e3f75d2f6ca15daf9e87172990214d6352 
  src/entry.cpp 48a92a7db04eec9b7b1b824841c95c280f31fab7 
  autotests/knewstuffentrytest.cpp bf55f063dc8cb0b0984fdc73501a13107241a75a 
  src/attica/atticaprovider.cpp 7103b59d62de468ba0c21a6b6260e5befc8575a2 
  src/core/cache.cpp 3ba6cb4f4d344781d7b95c966d0a0643777e1e6a 
  tests/knewstuff2_test.cpp ee2ead451be06854ea65ee9128231d37b118355c 

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


Testing
---

Builds and works still, more debug output filterable with the kanagram logging 
category.


Thanks,

Jeremy Whiting

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

Review Request 121098: Restore filedialog functionality for modal dialogs.

[Jeremy Whiting]

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

Review request for KDE Frameworks and Eike Hein.


Repository: frameworkintegration


Description
---

Before David's astyle commit, the show method used to call m_dialog-exec
if the window flags weren't nonmodal (i.e. modal dialogs). This got removed 
somehow.
BUG:334963


Diffs
-

  src/platformtheme/kdeplatformfiledialoghelper.cpp 
44eca192946f0da2b357b33e93a57ef0de05135b 

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


Testing
---

fifteen puzzle config with patch from https://git.reviewboard.kde.org/r/121097/ 
now shows the dialog and lets you choose a file.


Thanks,

Jeremy Whiting

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

Review Request 121099: Fix kautosave doesn't work with more than 1 file per application.

[Jeremy Whiting]

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

Review request for KDE Frameworks and David Faure.


Repository: kcoreaddons


Description
---

kautosave doesn't work when any app tries to use a second filename, because it 
doesn't filter on filename.  The unit tests can be droppped into master to show 
the problem, if you remove the include on line 21.

This patch:
1. Adds unit tests to test more behavior mentioned in the header.
2. Fixes kautosave working with multple files per application.
3. Fixes filenaming brittleness, which would cause kautosave to randomly fail 
when the last 3 randomly generated characters in the filename matched any 3 
consequtive chracters in the managed filename.

Original patch by Andreas Xavier (https://git.reviewboard.kde.org/r/119530)

Items from original review have been fixed.


Diffs
-

  src/lib/io/kautosavefile_p.cpp PRE-CREATION 
  autotests/kautosavefiletest.h cf70f4c6a4e1f093c431eff6ff25e6f510e84a53 
  autotests/kautosavefiletest.cpp ec0309e5fda95e01bbed31bd2fe91f9b7a48bec0 
  src/lib/CMakeLists.txt 1dc56270ab5157af706b7745cfa88ae11e16184a 
  src/lib/io/kautosavefile.h 05cc3aedc248665c8727ade3b86b524275c013ca 
  src/lib/io/kautosavefile.cpp 13a13d7cfb26194be3edf7cbdcd1d39309b79465 
  src/lib/io/kautosavefile_p.h PRE-CREATION 

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


Testing
---

It builds and the test passes.


Thanks,

Jeremy Whiting

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

Review Request 121100: Add qCDebug statements back into knewstuff sources.

[Jeremy Whiting]

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

Review request for KDE Frameworks.


Repository: knewstuff


Description
---

Add qCDebug statements back into knewstuff sources.


Diffs
-

  tests/knewstuff2_standard.cpp e44628b549ea5ad3b002c3a11eac298b92b5a6ae 
  tests/khotnewstuff.cpp 1aba7de48a8b7cf7f8886957fc473bf0cc631a13 
  tests/knewstuff2_cache.cpp e7e8a48666237f468d986e99a8c472fe37fd7a77 
  tests/knewstuff2_download.cpp 39d756e30f5b4f56f9254ae1e08c0d8310daf4d1 
  src/staticxml/staticxmlprovider.cpp 434ecef0b71543bf4504c9781d1d3a21b9cf6e34 
  src/ui/entrydetailsdialog.cpp 8a36d33f9a390a211313b11fba65030261a54446 
  src/ui/itemsgridviewdelegate.cpp 19ddc59eb4acbb2b7a591119453be407d01d9a9f 
  src/ui/itemsmodel.cpp 0254e88a5c16a2f8c5818a45bb7ec28eef4973e8 
  src/ui/itemsviewbasedelegate.cpp 5137beb93ee8cccd15b28b9a9f47eff60fc17fc8 
  src/ui/itemsviewdelegate.cpp 5e9b985cc155d141664a944b3d2bd1e751d96136 
  src/uploaddialog.cpp 1a087b30a7fc6198062f0f7a012ae37ed6f396af 
  src/core/engine.cpp 017154323cfd3f48fc61c0c705d4842f3c2f94a4 
  src/core/entryinternal.cpp d3af619e9908b2f9e6176c7c87eda44897e93f0a 
  src/core/installation.cpp d8de905bd2d19d098fb08a64897f5617f04e996d 
  src/core/upload.cpp 166e69417b687fef6e89ef7fb5c383ec478c5c2d 
  src/core/xmlloader.cpp 2cee02b66f8ec2a0f1fc407aaadd0ea397b89939 
  src/downloadmanager.cpp 60d0d37ef0bd35efdcfe5e6ac58fefb3a2ce9954 
  src/downloadwidget.cpp 358bb8b5222ac596dd3f0025778cd2721c1f3120 
  src/entry.h df3095e3f75d2f6ca15daf9e87172990214d6352 
  src/entry.cpp 48a92a7db04eec9b7b1b824841c95c280f31fab7 
  autotests/knewstuffentrytest.cpp bf55f063dc8cb0b0984fdc73501a13107241a75a 
  src/attica/atticaprovider.cpp 7103b59d62de468ba0c21a6b6260e5befc8575a2 
  src/core/cache.cpp 3ba6cb4f4d344781d7b95c966d0a0643777e1e6a 
  tests/knewstuff2_test.cpp ee2ead451be06854ea65ee9128231d37b118355c 

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


Testing
---

Builds and works still, more debug output filterable with the kanagram logging 
category.


Thanks,

Jeremy Whiting

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

Re: Ksshaskpass ?

[Jeremy Whiting]

Laurent,

Thanks for fixing those.

On Sun, Nov 2, 2014 at 11:20 PM, laurent Montel mon...@kde.org wrote:
 Hi,
 I fixed some problem:
 - translate program
 - fix command line parser
 - Fix version
 - Use astyle-kdelibs to reform code
 - etc.

 I think it will ok now :)

 Regards.


 Le Sunday 02 November 2014 16:21:32 Jeremy Whiting a écrit :
 Ok, pushed to kde:ksshaskpass now. I'll request it move to kdereview
 tomorrow. I would like at least one other person to try it before
 that, as I'm the only one that has built and run the kf5 port that I
 know of.

 thanks,
 Jeremy

 On Sat, Nov 1, 2014 at 3:14 PM, Jeremy Whiting jpwhit...@kde.org wrote:
  Ok, pushed to scratch/whiting/ksshaskpass the original sources from
  0.5.3 on first commit, and a commit to port to kf5 which seems to work
  ok here. I removed the RPATH exception since that made the binary not
  able to find KF5CoreAddons.so here. If it should be left in and some
  other method works to help it find the libraries it needs that's ok by
  me (if you can tell me how to make it work here too).
 
  If anyone interested can look at my commit porting to kf5 I'd
  appreciate it. After a few days I'll request a real git repo for it
  and put it in kdereview for the required 2 weeks, then move it to
  kde/workspace unless someone has a better idea for it. It only needs
  CoreAddons, WidgetsAddons, I18n, and Wallet frameworks.
 
  thanks,
  Jeremy
 
  On Sat, Nov 1, 2014 at 2:40 PM, Jeremy Whiting jpwhit...@kde.org wrote:
  Ok, I'll push it to git somewhere today and let the list know where so
  it can get reviewed. One question I have is where should it end up
  ultimately? In frameworks with/inside kwallet? in
  kde/workspace/plasma-desktop ?
 
  thanks,
  Jeremy
 
  On Sat, Nov 1, 2014 at 11:34 AM, laurent Montel mon...@kde.org wrote:
  Le Saturday 01 November 2014 10:29:13 Jeremy Whiting a écrit :
  I was wondering about that myself last night. I have a mostly finished
  port to kf5 here on my disk if we want it.
 
  Ah you did it ?:)
  So it's in your hand so :)
 
  By the way I didn't find
  any git or svn repo for the old code, did it have one?
 
  No it's for this reason that I asked to Armin Berres to move it in kde
  project
  :)
  :
  All the distros
  were grabbing it from kde-apps.org from what I saw.
 
  Indeed.
 
 
  Regards
 
  BR,
  Jeremy

 --
 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


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

Re: Ksshaskpass ?

[Jeremy Whiting]

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.

thanks,
Jeremy

P.S. We may get some patches from lxqt guys to make the kwallet
dependency optional at some point in the near future with an #ifdef or
whatnot. Just keep that in mind when considering where this tiny
useful application belongs.

On Mon, Nov 3, 2014 at 1:23 PM, Marko Käning mk-li...@email.de wrote:
 Hi Laurent,

 I’ve added a Jenkins job for ksshaskpass. I haven’t started the 1st build 
 yet, as I intend
 to wait for an hour until the dependencies have migrated onto Jenkins master 
 [2].

 Greets,
 Marko


 [1] http://build.kde.org/view/FAILED/job/ksshaskpass_master_qt5/
 [2] 
 http://commits.kde.org/kde-build-metadata/532bfac9f3d3bf8f1d80ccd5c668a596b4daefb3
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Ksshaskpass ?

[Jeremy Whiting]

Ok, pushed to kde:ksshaskpass now. I'll request it move to kdereview
tomorrow. I would like at least one other person to try it before
that, as I'm the only one that has built and run the kf5 port that I
know of.

thanks,
Jeremy

On Sat, Nov 1, 2014 at 3:14 PM, Jeremy Whiting jpwhit...@kde.org wrote:
 Ok, pushed to scratch/whiting/ksshaskpass the original sources from
 0.5.3 on first commit, and a commit to port to kf5 which seems to work
 ok here. I removed the RPATH exception since that made the binary not
 able to find KF5CoreAddons.so here. If it should be left in and some
 other method works to help it find the libraries it needs that's ok by
 me (if you can tell me how to make it work here too).

 If anyone interested can look at my commit porting to kf5 I'd
 appreciate it. After a few days I'll request a real git repo for it
 and put it in kdereview for the required 2 weeks, then move it to
 kde/workspace unless someone has a better idea for it. It only needs
 CoreAddons, WidgetsAddons, I18n, and Wallet frameworks.

 thanks,
 Jeremy

 On Sat, Nov 1, 2014 at 2:40 PM, Jeremy Whiting jpwhit...@kde.org wrote:
 Ok, I'll push it to git somewhere today and let the list know where so
 it can get reviewed. One question I have is where should it end up
 ultimately? In frameworks with/inside kwallet? in
 kde/workspace/plasma-desktop ?

 thanks,
 Jeremy

 On Sat, Nov 1, 2014 at 11:34 AM, laurent Montel mon...@kde.org wrote:
 Le Saturday 01 November 2014 10:29:13 Jeremy Whiting a écrit :
 I was wondering about that myself last night. I have a mostly finished
 port to kf5 here on my disk if we want it.

 Ah you did it ?:)
 So it's in your hand so :)

 By the way I didn't find
 any git or svn repo for the old code, did it have one?

 No it's for this reason that I asked to Armin Berres to move it in kde 
 project
 :)


 All the distros
 were grabbing it from kde-apps.org from what I saw.

 Indeed.


 Regards


 BR,
 Jeremy

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

Re: Ksshaskpass ?

[Jeremy Whiting]

Ok, pushed to scratch/whiting/ksshaskpass the original sources from
0.5.3 on first commit, and a commit to port to kf5 which seems to work
ok here. I removed the RPATH exception since that made the binary not
able to find KF5CoreAddons.so here. If it should be left in and some
other method works to help it find the libraries it needs that's ok by
me (if you can tell me how to make it work here too).

If anyone interested can look at my commit porting to kf5 I'd
appreciate it. After a few days I'll request a real git repo for it
and put it in kdereview for the required 2 weeks, then move it to
kde/workspace unless someone has a better idea for it. It only needs
CoreAddons, WidgetsAddons, I18n, and Wallet frameworks.

thanks,
Jeremy

On Sat, Nov 1, 2014 at 2:40 PM, Jeremy Whiting jpwhit...@kde.org wrote:
 Ok, I'll push it to git somewhere today and let the list know where so
 it can get reviewed. One question I have is where should it end up
 ultimately? In frameworks with/inside kwallet? in
 kde/workspace/plasma-desktop ?

 thanks,
 Jeremy

 On Sat, Nov 1, 2014 at 11:34 AM, laurent Montel mon...@kde.org wrote:
 Le Saturday 01 November 2014 10:29:13 Jeremy Whiting a écrit :
 I was wondering about that myself last night. I have a mostly finished
 port to kf5 here on my disk if we want it.

 Ah you did it ?:)
 So it's in your hand so :)

 By the way I didn't find
 any git or svn repo for the old code, did it have one?

 No it's for this reason that I asked to Armin Berres to move it in kde 
 project
 :)


 All the distros
 were grabbing it from kde-apps.org from what I saw.

 Indeed.


 Regards


 BR,
 Jeremy

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

Re: Review Request 120903: Fix typo in documentation.

[Jeremy Whiting]

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

(Updated Oct. 30, 2014, 1:30 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kconfigwidgets


Description
---

Fix typo in documentation.


Diffs
-

  src/kconfigdialog.h 436aa05e7e206ccb8a814bb590d9c1af28c1fb98 

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


Testing
---

It's a comment, no code to test.


Thanks,

Jeremy Whiting

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

Review Request 120903: Fix typo in documentation.

[Jeremy Whiting]

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

Review request for KDE Frameworks.


Repository: kconfigwidgets


Description
---

Fix typo in documentation.


Diffs
-

  src/kconfigdialog.h 436aa05e7e206ccb8a814bb590d9c1af28c1fb98 

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


Testing
---

It's a comment, no code to test.


Thanks,

Jeremy Whiting

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

Re: Review Request 120589: Remove #ifndefs for WIN CE, we don't support CE anymore.

[Jeremy Whiting]

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

(Updated Oct. 22, 2014, 8:51 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Nicolás Alvarez and Jeremy Whiting.


Repository: knewstuff


Description
---

Remove #ifndefs for WIN CE, we don't support CE anymore.


Diffs
-

  src/core/installation.cpp b69837db5b9ec05bce0a9c7bdc854fa0c9391f0e 

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


Testing
---

It still builds on linux, though I didn't modify any linux code. Someone to 
test on windows would be awesome.


Thanks,

Jeremy Whiting

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

Re: Review Request 120574: Add explicit to ctors with one parameter

[Jeremy Whiting]

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

(Updated Oct. 14, 2014, 10:11 a.m.)


Review request for KDE Frameworks, David Faure, Vavelin Kevin, and Jeremy 
Whiting.


Changes
---

Added Kevin and David to weigh in.


Repository: knewstuff


Description
---

Add explicit to ctors with one parameter


Diffs
-

  src/attica/atticaprovider_p.h 8638aff0e6548705a22f125a7adc25ff6b1db165 
  src/button.h 155b6dc5f4b032970bcd0e5400cf5dba12f76e81 
  src/core/engine_p.h f7a6884d9a22c56f1feff8b6c97fa242f46533da 
  src/core/installation_p.h 9d855a26590dcee2259fe657fc7c3293669e3f81 
  src/core/xmlloader_p.h 7167417c1fcfbeafea1ceb9c7cb5eb56b9d8ac29 
  src/downloadwidget_p.h 37c7f0872fe0ff6fe65ab7bc63e1239f1b0d8e36 
  src/ui/itemsview_p.h df65d0b47abaddd404a171890e47af1b93c4203f 
  src/ui/progressindicator_p.h 3d18bff8eac6b8a21f94da39b21b51ee334ec3de 

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


Testing
---

It builds and khotnewstuff test app still works.

My only question is if this source incompatible change is allowed in frameworks 
or not.


Thanks,

Jeremy Whiting

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

Re: Review Request 120574: Add explicit to ctors with one parameter

[Jeremy Whiting]

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

(Updated Oct. 14, 2014, 7:47 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, David Faure, Vavelin Kevin, and Jeremy 
Whiting.


Repository: knewstuff


Description
---

Add explicit to ctors with one parameter


Diffs
-

  src/attica/atticaprovider_p.h 8638aff0e6548705a22f125a7adc25ff6b1db165 
  src/button.h 155b6dc5f4b032970bcd0e5400cf5dba12f76e81 
  src/core/engine_p.h f7a6884d9a22c56f1feff8b6c97fa242f46533da 
  src/core/installation_p.h 9d855a26590dcee2259fe657fc7c3293669e3f81 
  src/core/xmlloader_p.h 7167417c1fcfbeafea1ceb9c7cb5eb56b9d8ac29 
  src/downloadwidget_p.h 37c7f0872fe0ff6fe65ab7bc63e1239f1b0d8e36 
  src/ui/itemsview_p.h df65d0b47abaddd404a171890e47af1b93c4203f 
  src/ui/progressindicator_p.h 3d18bff8eac6b8a21f94da39b21b51ee334ec3de 

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


Testing
---

It builds and khotnewstuff test app still works.

My only question is if this source incompatible change is allowed in frameworks 
or not.


Thanks,

Jeremy Whiting

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

Review Request 120589: Remove #ifndefs for WIN CE, we don't support CE anymore.

[Jeremy Whiting]

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

Review request for KDE Frameworks, Nicolás Alvarez and Jeremy Whiting.


Repository: knewstuff


Description
---

Remove #ifndefs for WIN CE, we don't support CE anymore.


Diffs
-

  src/core/installation.cpp b69837db5b9ec05bce0a9c7bdc854fa0c9391f0e 

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


Testing
---

It still builds on linux, though I didn't modify any linux code. Someone to 
test on windows would be awesome.


Thanks,

Jeremy Whiting

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

private export

[Jeremy Whiting]

Hello,

In KNewStuff autotests there are two disabled tests that build and
work if I export the Author and EntryInternal classes, but these two
classes are private (declared in _p.h files) so I'd rather not export
them, since they aren't public api. Is there a way to have them
exported when BUILD_TESTING is set only? I didn't see anything obvious
in the knewstuff_export.h generated header. I guess I could have the
class declarations wrapped in #ifdef BUILD_TESTING but that seems like
a hack. Is there a proper way to only export private classes when
building and running tests?

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

Review Request 120592: Remove #ifndefs for WIN CE, we don't support CE anymore.

[Jeremy Whiting]

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

Review request for KDE Frameworks and Jeremy Whiting.


Repository: knewstuff


Description
---

Enable autotests.

Make autotests build in the sources they need to test to avoid exporting.
Patch by Albert Astals Cid aa...@kde.org


Diffs
-

  autotests/CMakeLists.txt c210f70c493fc7febb9157f212e23c92042315c7 
  autotests/knewstuffentrytest.cpp fbf2e0d7478def609a2cb9912139a6bbc20197fc 

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


Testing
---

The tests build and pass here.


Thanks,

Jeremy Whiting

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

Re: Review Request 120592: enable autotests for knewstuff

[Jeremy Whiting]

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

(Updated Oct. 14, 2014, 5:19 p.m.)


Review request for KDE Frameworks and Jeremy Whiting.


Changes
---

Fix summary


Summary (updated)
-

enable autotests for knewstuff


Repository: knewstuff


Description
---

Enable autotests.

Make autotests build in the sources they need to test to avoid exporting.
Patch by Albert Astals Cid aa...@kde.org


Diffs
-

  autotests/CMakeLists.txt c210f70c493fc7febb9157f212e23c92042315c7 
  autotests/knewstuffentrytest.cpp fbf2e0d7478def609a2cb9912139a6bbc20197fc 

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


Testing
---

The tests build and pass here.


Thanks,

Jeremy Whiting

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

Re: private export

[Jeremy Whiting]

Meh, Albert found a decent enough way to do it. Posted to rb to look at.

On Tue, Oct 14, 2014 at 5:03 PM, Aleix Pol aleix...@kde.org wrote:
 On Tue, Oct 14, 2014 at 10:37 PM, Jeremy Whiting jpwhit...@kde.org wrote:

 Hello,

 In KNewStuff autotests there are two disabled tests that build and
 work if I export the Author and EntryInternal classes, but these two
 classes are private (declared in _p.h files) so I'd rather not export
 them, since they aren't public api. Is there a way to have them
 exported when BUILD_TESTING is set only? I didn't see anything obvious
 in the knewstuff_export.h generated header. I guess I could have the
 class declarations wrapped in #ifdef BUILD_TESTING but that seems like
 a hack. Is there a proper way to only export private classes when
 building and running tests?

 thanks,
 Jeremy


 You can do things like that with cmake library objects. See documentation
 for add_library(... OBJECT ...).

 It will make it possible for you to have objects in different targets so
 they are compiled once but in different places. I used it here as a test
 [1]. It's not magic, but it saves some compilation time and possible
 complexity.

 Cheers!
 Aleix

 [1] kde:scratch/apol/kanboardclient

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

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

Re: Review Request 120592: enable autotests for knewstuff

[Jeremy Whiting]

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

(Updated Oct. 15, 2014, 1:41 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Jeremy Whiting.


Repository: knewstuff


Description
---

Enable autotests.

Make autotests build in the sources they need to test to avoid exporting.
Patch by Albert Astals Cid aa...@kde.org


Diffs
-

  autotests/CMakeLists.txt c210f70c493fc7febb9157f212e23c92042315c7 
  autotests/knewstuffentrytest.cpp fbf2e0d7478def609a2cb9912139a6bbc20197fc 

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


Testing
---

The tests build and pass here.


Thanks,

Jeremy Whiting

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

Review Request 120574: Add explicit to ctors with one parameter

[Jeremy Whiting]

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

Review request for KDE Frameworks and Jeremy Whiting.


Repository: knewstuff


Description
---

Add explicit to ctors with one parameter


Diffs
-

  src/attica/atticaprovider_p.h 8638aff0e6548705a22f125a7adc25ff6b1db165 
  src/button.h 155b6dc5f4b032970bcd0e5400cf5dba12f76e81 
  src/core/engine_p.h f7a6884d9a22c56f1feff8b6c97fa242f46533da 
  src/core/installation_p.h 9d855a26590dcee2259fe657fc7c3293669e3f81 
  src/core/xmlloader_p.h 7167417c1fcfbeafea1ceb9c7cb5eb56b9d8ac29 
  src/downloadwidget_p.h 37c7f0872fe0ff6fe65ab7bc63e1239f1b0d8e36 
  src/ui/itemsview_p.h df65d0b47abaddd404a171890e47af1b93c4203f 
  src/ui/progressindicator_p.h 3d18bff8eac6b8a21f94da39b21b51ee334ec3de 

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


Testing
---

It builds and khotnewstuff test app still works.

My only question is if this source incompatible change is allowed in frameworks 
or not.


Thanks,

Jeremy Whiting

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

platforms

[Jeremy Whiting]

Do we support building and using frameworks on Windows CE anymore? I
don't see it on
http://qt-project.org/doc/qt-4.8/supported-platforms.html so I guess
not, is that correct? If not I can clean up some old ifdefs in
knewstuff sources.

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

Re: Review Request 120535: attica: Add const to getter methods.

[Jeremy Whiting]

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

(Updated Oct. 9, 2014, 12:02 p.m.)


Review request for KDE Frameworks and Frederik Gladhorn.


Changes
---

Duplicated methods to be const rather than changing existing methods.

Can someone confirm this is a binary compatible change?


Repository: attica


Description
---

Add const to getter methods.


Diffs (updated)
-

  src/downloaddescription.h 08796c9283d1412386f6e096b981c3afa2b1f55e 
  src/downloaddescription.cpp f76a1601a53e66b836623f4ac7a67ceeb543c1f0 

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


Testing
---

This builds and an improved knewstuff (with const AtticaDescription foo, bar) 
in foreach lines builds.

My only question about committing this is if it's allowed since it's a binary 
incompatible change. If it's not allowed I will add duplicates of these methods 
that are const and deprecate these non-const ones instead.


Thanks,

Jeremy Whiting

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

Re: Review Request 120535: attica: Add const to getter methods.

[Jeremy Whiting]

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

(Updated Oct. 9, 2014, 7:54 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Frederik Gladhorn.


Repository: attica


Description
---

Add const to getter methods.


Diffs
-

  src/downloaddescription.h 08796c9283d1412386f6e096b981c3afa2b1f55e 
  src/downloaddescription.cpp f76a1601a53e66b836623f4ac7a67ceeb543c1f0 

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


Testing
---

This builds and an improved knewstuff (with const AtticaDescription foo, bar) 
in foreach lines builds.

My only question about committing this is if it's allowed since it's a binary 
incompatible change. If it's not allowed I will add duplicates of these methods 
that are const and deprecate these non-const ones instead.


Thanks,

Jeremy Whiting

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

Review Request 120535: attica: Add const to getter methods.

[Jeremy Whiting]

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

Review request for KDE Frameworks and Frederik Gladhorn.


Repository: attica


Description
---

Add const to getter methods.


Diffs
-

  src/downloaddescription.h 08796c9283d1412386f6e096b981c3afa2b1f55e 
  src/downloaddescription.cpp f76a1601a53e66b836623f4ac7a67ceeb543c1f0 

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


Testing
---

This builds and an improved knewstuff (with const AtticaDescription foo, bar) 
in foreach lines builds.

My only question about committing this is if it's allowed since it's a binary 
incompatible change. If it's not allowed I will add duplicates of these methods 
that are const and deprecate these non-const ones instead.


Thanks,

Jeremy Whiting

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

Re: Review Request 120535: attica: Add const to getter methods.

[Jeremy Whiting]

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

(Updated Oct. 8, 2014, 3:20 p.m.)


Review request for KDE Frameworks, kdelibs and Frederik Gladhorn.


Repository: attica


Description
---

Add const to getter methods.


Diffs
-

  src/downloaddescription.h 08796c9283d1412386f6e096b981c3afa2b1f55e 
  src/downloaddescription.cpp f76a1601a53e66b836623f4ac7a67ceeb543c1f0 

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


Testing
---

This builds and an improved knewstuff (with const AtticaDescription foo, bar) 
in foreach lines builds.

My only question about committing this is if it's allowed since it's a binary 
incompatible change. If it's not allowed I will add duplicates of these methods 
that are const and deprecate these non-const ones instead.


Thanks,

Jeremy Whiting

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

Re: Review Request 120535: attica: Add const to getter methods.

[Jeremy Whiting]

 On Oct. 8, 2014, 3:22 p.m., Albert Astals Cid wrote:
  According to 
  https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ 
  changing the const/volatile qualifiers of the function is BIC
  
  Now the thing is if we allow BIC changes in frameworks like attica or not 
  is for someone else to answer.

Yes, I saw that, the real question is if we allow BIC changes or not. Also I 
guess if we don't allow BIC changes in frameworks anymore we should change that 
page to not say BIC changes should all happen on Monday's anymore :)


- Jeremy


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


On Oct. 8, 2014, 3:20 p.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120535/
 ---
 
 (Updated Oct. 8, 2014, 3:20 p.m.)
 
 
 Review request for KDE Frameworks, kdelibs and Frederik Gladhorn.
 
 
 Repository: attica
 
 
 Description
 ---
 
 Add const to getter methods.
 
 
 Diffs
 -
 
   src/downloaddescription.h 08796c9283d1412386f6e096b981c3afa2b1f55e 
   src/downloaddescription.cpp f76a1601a53e66b836623f4ac7a67ceeb543c1f0 
 
 Diff: https://git.reviewboard.kde.org/r/120535/diff/
 
 
 Testing
 ---
 
 This builds and an improved knewstuff (with const AtticaDescription foo, 
 bar) in foreach lines builds.
 
 My only question about committing this is if it's allowed since it's a binary 
 incompatible change. If it's not allowed I will add duplicates of these 
 methods that are const and deprecate these non-const ones instead.
 
 
 Thanks,
 
 Jeremy Whiting
 


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

Re: Review Request 120535: attica: Add const to getter methods.

[Jeremy Whiting]

 On Oct. 8, 2014, 3:22 p.m., Albert Astals Cid wrote:
  According to 
  https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ 
  changing the const/volatile qualifiers of the function is BIC
  
  Now the thing is if we allow BIC changes in frameworks like attica or not 
  is for someone else to answer.
 
 Jeremy Whiting wrote:
 Yes, I saw that, the real question is if we allow BIC changes or not. 
 Also I guess if we don't allow BIC changes in frameworks anymore we should 
 change that page to not say BIC changes should all happen on Monday's anymore 
 :)
 
 Aleix Pol Gonzalez wrote:
 Also you can add a TODO KF5 comment. And yes, fix the wiki... :/

Do you mean TODO KF6 ?


- Jeremy


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


On Oct. 8, 2014, 3:20 p.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120535/
 ---
 
 (Updated Oct. 8, 2014, 3:20 p.m.)
 
 
 Review request for KDE Frameworks, kdelibs and Frederik Gladhorn.
 
 
 Repository: attica
 
 
 Description
 ---
 
 Add const to getter methods.
 
 
 Diffs
 -
 
   src/downloaddescription.h 08796c9283d1412386f6e096b981c3afa2b1f55e 
   src/downloaddescription.cpp f76a1601a53e66b836623f4ac7a67ceeb543c1f0 
 
 Diff: https://git.reviewboard.kde.org/r/120535/diff/
 
 
 Testing
 ---
 
 This builds and an improved knewstuff (with const AtticaDescription foo, 
 bar) in foreach lines builds.
 
 My only question about committing this is if it's allowed since it's a binary 
 incompatible change. If it's not allowed I will add duplicates of these 
 methods that are const and deprecate these non-const ones instead.
 
 
 Thanks,
 
 Jeremy Whiting
 


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

Re: Qt DevDays is coming; do we want to print up some Frameworks Cookbooks to give to attendees?

[Jeremy Whiting]

Valorie,

I'm a bit confused. books.kde.org says the book is hosted at
flossmanuals, but that url takes me to the oldish KDE Dev Guide is
thi Frameworks Cookbook a different thing than that old book, right?
Is the current wip book available somewhere ? I guess if so we should
point that link at it (and also turn the epub, pdf etc. text below the
cover there into links) If not what's needed to make it from the git
repo? I saw one or so tasks on the kanboard about generating a book,
is that to generate the epub/pdf/html from the git repo? or to print
the actual hard copy once we have the epub/pdf/html ?

thanks,
Jeremy

On Wed, Oct 1, 2014 at 11:43 PM, Valorie Zimmerman
valorie.zimmer...@gmail.com wrote:
 https://www.qtdeveloperdays.com/europe says that Qt DevDays happens
 October 6 – 8, at the Berlin Congress Centre in Berlin.

 If we want to print up some books to give away, we need some more chapters.

 See https://books.kde.org for more details.

 Valorie

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

Re: KAnagram QML WebView crash

[Jeremy Whiting]

::TextureMapperPaintOptions
const) ()
at platform/graphics/texmap/TextureMapper.h:90
#26 0xb56e6a94 in
WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions
const) () at platform/graphics/texmap/TextureMapper.h:90
#27 0xb56e6b83 in WebCore::TextureMapperLayer::paint() ()
at platform/graphics/texmap/TextureMapper.h:90
#28 0xb58a407a in
WebCore::CoordinatedGraphicsScene::paintToCurrentGLContext(WebCore::TransformationMatrix
const, float, WebCore::FloatRect const, unsigned int) () at
../WTF/wtf/HashTable.h:690
#29 0xb52e438d in
WebKit::ContentsSGNode::render(QSGRenderNode::RenderState const) ()
at /usr/include/i386-linux-gnu/qt5/QtCore/qvector.h:508
#30 0xb7cb55bf in
QSGBatchRenderer::Renderer::renderRenderNode(QSGBatchRenderer::Batch*)
() from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
#31 0xb7cb5b8a in QSGBatchRenderer::Renderer::renderBatches() ()
   from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
#32 0xb7cb6249 in QSGBatchRenderer::Renderer::render() ()
   from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
#33 0xb7cc2a5b in QSGRenderer::renderScene(QSGBindable const) ()
   from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
---Type return to continue, or q return to quit---
#34 0xb7cc30c7 in QSGRenderer::renderScene() ()
   from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
#35 0xb7cd32ec in QSGRenderContext::renderNextFrame(QSGRenderer*, unsigned int)
() from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
#36 0xb7d133b7 in QQuickWindowPrivate::renderSceneGraph(QSize const) ()
   from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
#37 0xb7cef4bb in ?? () from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
#38 0xb7cf0628 in ?? () from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
#39 0xb365d86a in QApplicationPrivate::notify_helper (this=0x808e380, receiver=
0x80d4848, e=0xbfffef40) at kernel/qapplication.cpp:3522
#40 0xb3662e1c in QApplication::notify (this=0xb1ec, receiver=0x80d4848,
e=0xbfffef40) at kernel/qapplication.cpp:3487
#41 0xb7946da7 in QCoreApplication::notifyInternal (this=0xb1ec,
receiver=0x80d4848, event=0xbfffef40) at kernel/qcoreapplication.cpp:935
#42 0xb799dcb8 in sendEvent (event=0xbfffef40, receiver=optimized out)
at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:237
#43 QTimerInfoList::activateTimers (this=0x80ad04c)
at kernel/qtimerinfo_unix.cpp:643
#44 0xb799e149 in timerSourceDispatch (source=0x80ad018)
at kernel/qeventdispatcher_glib.cpp:185
#45 0xb2289f64 in g_main_context_dispatch ()
   from /lib/i386-linux-gnu/libglib-2.0.so.0
#46 0xb228a279 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
---Type return to continue, or q return to quit---
#47 0xb228a346 in g_main_context_iteration ()
   from /lib/i386-linux-gnu/libglib-2.0.so.0
#48 0xb799edc4 in QEventDispatcherGlib::processEvents (this=0x80ad238,
flags=...) at kernel/qeventdispatcher_glib.cpp:426
#49 0xaf8fe7e1 in QPAEventDispatcherGlib::processEvents (this=0x80ad238,
flags=...) at eventdispatchers/qeventdispatcher_glib.cpp:123
#50 0xb7944183 in QEventLoop::processEvents (this=0xb17c, flags=...)
at kernel/qeventloop.cpp:136
#51 0xb794459a in QEventLoop::exec (this=0xb17c, flags=...)
at kernel/qeventloop.cpp:212
#52 0xb794c26a in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1188
#53 0xb3077f21 in QGuiApplication::exec () at kernel/qguiapplication.cpp:1450
#54 0xb365be04 in QApplication::exec () at kernel/qapplication.cpp:2767
#55 0x08066d79 in main (argc=1, argv=0xb3d4)
at /home/jeremy/devel/kde/frameworks/kde/kdeedu/kanagram/src/main.cpp:60

The only thing I'm doing in the qml is making the WebView visible and
after about one or two seconds I get this segfault. Anyone with
QtWebKit experience know what's going on here? do I need to change
some qml property to make it not crash ?

BR,
Jeremy

On Fri, Aug 22, 2014 at 4:11 PM, Jeremy Whiting jpwhit...@kde.org wrote:
 Sorry all, seems this is something wrong with my local setup. Though
 I've no clue what would cause these issues. If anyone has any ideas
 for me to try I'll try anything to get back to where I can work on
 fixing real issues rather than strange crashes that are only on my
 system :) I'll keep digging I guess.

 thanks,
 Jeremy


 On Fri, Aug 22, 2014 at 3:57 PM, Albert Astals Cid aa...@kde.org wrote:
 El Divendres, 22 d'agost de 2014, a les 15:45:12, Jeremy Whiting va escriure:
 Hello all,

 I'm reaching out because I can't seem to find a solution myself.

 TLDR If you can get a backtrace from building and running
 scratch/whiting/testqmlapp which uses QtWebKit's QML WebView I'd very
 much appreciate it.

 works for me http://i.imgur.com/OVgSImV.png

 Cheers,
   Albert




 KAnagram qt4 version from master (before frameworks branch was merged)
 has a qml WebView to show wikipedia data for the current word as a
 hint (obvious hint, but nevertheless). Now that master branch is kf5
 based I've disabled this feature temporarily because on my machine at
 least every time

Re: KAnagram QML WebView crash

[Jeremy Whiting]

Hmm, could I be hitting the crash on
TSymbolTableLevel::~TSymbolTableLevel() mentioned here:
http://download.opensuse.org/ports/armv7hl/factory/repo/oss/ChangeLog



On Sat, Aug 23, 2014 at 6:45 PM, Jeremy Whiting jpwhit...@kde.org wrote:
 Ok, I rebuilt frameworks and such on a fresh debian jessie vm with
 frameworks build from git and kanagram crashes here with this
 backtrace I got from gdb:

 Set qml file location
 [New Thread 0xa6e99b40 (LWP 10760)]

 Program received signal SIGSEGV, Segmentation fault.
 0x in ?? ()
 (gdb) bt
 #0  0x in ?? ()
 #1  0xb657b980 in TSymbolTableLevel::~TSymbolTableLevel() ()
 at src/compiler/SymbolTable.cpp:174
 #2  0xb653d0a1 in TCompiler::compile (this=0x9094f88, shaderStrings=0x0,
 numStrings=unknown type, compileOptions=-1218551960)
 at src/compiler/SymbolTable.h:270
 #3  0xb657ad64 in ShCompile (
 handle=error reading variable: Unknown argument list address for
 `handle'.,
 shaderStrings=error reading variable: Unknown argument list
 address for `shaderStrings'.,
 numStrings=error reading variable: Unknown argument list address
 for `numStrings'.,
 compileOptions=error reading variable: Unknown argument list
 address for `compileOptions'.) at src/compiler/ShaderLang.cpp:200
 #4  0xb587e4c2 in WebCore::ANGLEWebKitBridge::compileShaderSource(char
 const*, WebCore::ANGLEShaderType, WTF::String, WTF::String,
 WTF::VectorWebCore::ANGLEShaderSymbol, 0u, WTF::CrashOnOverflow,
 int) () at ../WTF/wtf/HashTable.h:690
 #5  0xb588bc57 in
 WebCore::Extensions3DOpenGLCommon::getTranslatedShaderSourceANGLE(unsigned
 int) () at ../WTF/wtf/HashTable.h:690
 #6  0xb58881d0 in WebCore::GraphicsContext3D::compileShader(unsigned int) ()
 at ../WTF/wtf/HashTable.h:690
 #7  0xb5895b42 in
 WebCore::TextureMapperShaderProgram::TextureMapperShaderProgra---Type
 return to continue, or q return to quit---
 m(WTF::PassRefPtrWebCore::GraphicsContext3D, WTF::String const,
 WTF::String const) () at ../WTF/wtf/HashTable.h:690
 #8  0xb5895fff in
 WebCore::TextureMapperShaderProgram::create(WTF::PassRefPtrWebCore::GraphicsContext3D,
 unsigned int) () at ../WTF/wtf/HashTable.h:690
 #9  0xb58938b1 in WebCore::TextureMapperGL::drawTexture(unsigned int,
 int, WebCore::IntSize const, WebCore::FloatRect const,
 WebCore::TransformationMatrix const, float, unsigned int) () at
 ../WTF/wtf/HashTable.h:690
 #10 0xb588f45a in
 WebCore::TextureMapperGL::drawTexture(WebCore::BitmapTexture const,
 WebCore::FloatRect const, WebCore::TransformationMatrix const,
 float, unsigned int) () at ../WTF/wtf/HashTable.h:690
 #11 0xb56e7ab7 in
 WebCore::TextureMapperTile::paint(WebCore::TextureMapper*,
 WebCore::TransformationMatrix const, float, unsigned int) ()
 at ../WTF/wtf/Vector.h:1053
 #12 0xb589b8d5 in
 WebCore::CoordinatedBackingStore::paintTilesToTextureMapper(WTF::VectorWebCore::TextureMapperTile*,
 0u, WTF::CrashOnOverflow, WebCore::TextureMapper*,
 WebCore::TransformationMatrix const, float, WebCore::FloatRect
 const) () at ../WTF/wtf/HashTable.h:690
 #13 0xb589c150 in
 WebCore::CoordinatedBackingStore::paintToTextureMapper(WebCore::TextureMapper*,
 WebCore::FloatRect const, WebCore::TransformationMatrix const,
 float) [clone .part.62] () at ../WTF/wtf/HashTable.h:690
 #14 0xb56e3994 in
 WebCore::TextureMapperLayer::paintSelf(WebCore::TextureMapperPaintOptions
 const) () at platform/graphics/texmap/TextureMapper.h:90
 #15 0xb56e6d94 in
 WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::Tex---Type
 return to continue, or q return to quit---
 tureMapperPaintOptions const) ()
 at platform/graphics/texmap/TextureMapper.h:90
 #16 0xb56e6efb in
 WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions
 const) ()
 at platform/graphics/texmap/TextureMapper.h:90
 #17 0xb56e6a94 in
 WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions
 const) () at platform/graphics/texmap/TextureMapper.h:90
 #18 0xb56e6d1a in
 WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions
 const) [clone .part.99] ()
 at platform/graphics/texmap/TextureMapper.h:90
 #19 0xb56e6efb in
 WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions
 const) ()
 at platform/graphics/texmap/TextureMapper.h:90
 #20 0xb56e6a94 in
 WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions
 const) () at platform/graphics/texmap/TextureMapper.h:90
 #21 0xb56e6d1a in
 WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions
 const) [clone .part.99] ()
 at platform/graphics/texmap/TextureMapper.h:90
 #22 0xb56e6efb in
 WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions
 const) ()
 at platform/graphics/texmap/TextureMapper.h:90
 #23 0xb56e6a94 in
 WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions
 const) () at platform/graphics/texmap

KAnagram QML WebView crash

[Jeremy Whiting]

Hello all,

I'm reaching out because I can't seem to find a solution myself.

TLDR If you can get a backtrace from building and running
scratch/whiting/testqmlapp which uses QtWebKit's QML WebView I'd very
much appreciate it.


KAnagram qt4 version from master (before frameworks branch was merged)
has a qml WebView to show wikipedia data for the current word as a
hint (obvious hint, but nevertheless). Now that master branch is kf5
based I've disabled this feature temporarily because on my machine at
least every time the WebView becomes visible KAnagram crashes. KCrash
shows two lines of ?? so isn't helpful. gdb kanagram shows no ui
strangely enough. At any rate I've simplified kanagram's code to a
base/small set of sources that also crashes when the WebView is shown
here, and I'd like to see if anyone knows why or can get me a
backtrace that could help. Note I've built Qt5 myself twice to try to
get a backtrace, but for some reason when building qt5 from git
QtWebKit is built as a QtQuick 1 library (placed into qtbase/imports)
rather than a QtQuick 2 library (placed into qtbase/qml) (If anyone
can explain why this is the case I'd like to know that also...) so if
you've built qt5 yourself you probably also wont be able to run this
test app. If I can't solve this crash I'll simply disable this feature
for the 14.12 release and look at it again once Qt 5.4 is released,
which will have a Blink based WebEngine or something to try it with
I'm told.

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

Re: KAnagram QML WebView crash

[Jeremy Whiting]

Sorry all, seems this is something wrong with my local setup. Though
I've no clue what would cause these issues. If anyone has any ideas
for me to try I'll try anything to get back to where I can work on
fixing real issues rather than strange crashes that are only on my
system :) I'll keep digging I guess.

thanks,
Jeremy


On Fri, Aug 22, 2014 at 3:57 PM, Albert Astals Cid aa...@kde.org wrote:
 El Divendres, 22 d'agost de 2014, a les 15:45:12, Jeremy Whiting va escriure:
 Hello all,

 I'm reaching out because I can't seem to find a solution myself.

 TLDR If you can get a backtrace from building and running
 scratch/whiting/testqmlapp which uses QtWebKit's QML WebView I'd very
 much appreciate it.

 works for me http://i.imgur.com/OVgSImV.png

 Cheers,
   Albert




 KAnagram qt4 version from master (before frameworks branch was merged)
 has a qml WebView to show wikipedia data for the current word as a
 hint (obvious hint, but nevertheless). Now that master branch is kf5
 based I've disabled this feature temporarily because on my machine at
 least every time the WebView becomes visible KAnagram crashes. KCrash
 shows two lines of ?? so isn't helpful. gdb kanagram shows no ui
 strangely enough. At any rate I've simplified kanagram's code to a
 base/small set of sources that also crashes when the WebView is shown
 here, and I'd like to see if anyone knows why or can get me a
 backtrace that could help. Note I've built Qt5 myself twice to try to
 get a backtrace, but for some reason when building qt5 from git
 QtWebKit is built as a QtQuick 1 library (placed into qtbase/imports)
 rather than a QtQuick 2 library (placed into qtbase/qml) (If anyone
 can explain why this is the case I'd like to know that also...) so if
 you've built qt5 yourself you probably also wont be able to run this
 test app. If I can't solve this crash I'll simply disable this feature
 for the 14.12 release and look at it again once Qt 5.4 is released,
 which will have a Blink based WebEngine or something to try it with
 I'm told.

 thanks,
 Jeremy
 ___
 kde-edu mailing list
 kde-...@mail.kde.org
 https://mail.kde.org/mailman/listinfo/kde-edu

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

Re: Review Request 119345: Port away from deprecated QUrl API

[Jeremy Whiting]

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

Ship it!


Ship It!

- Jeremy Whiting


On July 17, 2014, 11:56 a.m., Alexander Richardson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119345/
 ---
 
 (Updated July 17, 2014, 11:56 a.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: attica
 
 
 Description
 ---
 
 This means we no longer need to set QT_DISABLE_DEPRECATED_BEFORE=0
 
 
 Diffs
 -
 
   src/CMakeLists.txt 8b8ecad61629ad5fdf23b1628587bf4a5d109e65 
   src/provider.cpp 40ee8876e7fc5f6eae322254f074110c321a33fc 
 
 Diff: https://git.reviewboard.kde.org/r/119345/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Alexander Richardson
 


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

Re: Review Request 118962: Add api for setting download widget and dialog title. Helps with bug 336737

[Jeremy Whiting]

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

(Updated June 27, 2014, 6:17 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Marco Martin and Jeremy Whiting.


Repository: knewstuff


Description
---

Add api for setting download widget and dialog title. Helps with bug 336737


Diffs
-

  src/downloaddialog.h 7d8f2b40ee46baf18af401631816e0623d797623 
  src/downloaddialog.cpp d29768bda622fd9324e34c66503a78e0729dfc8e 
  src/downloadwidget.h e4643aad853d76927be5d67714c5eff1c8c4e8d1 
  src/downloadwidget.cpp 186939bfbfeebfaacc9c25ebbe5aaaf5cb277c20 

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


Testing
---


Thanks,

Jeremy Whiting

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

Re: Review Request 118970: libkeduvocdocument: Remove KDELibs4Support dependency.

[Jeremy Whiting]

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

(Updated June 28, 2014, 12:57 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Edu, KDE Frameworks, Aleix Pol Gonzalez, and Inge Wallin.


Repository: libkdeedu


Description
---

Port tests away from KCmdLineArgs to QCommandLineParser.
Port from KDE_DEPRECATED to KEDUVOCDOCUMENT_DEPRECATED (Maybe we should remove 
these?)
Port from KLocale to klocalizedstring.h


Diffs
-

  CMakeLists.txt 4feb10b67f78530170aaae216b9347cf94c0e51a 
  keduvocdocument/CMakeLists.txt c242c46fa79f128d63ccdeb5c4f611ad7294c874 
  keduvocdocument/keduvocarticle.h b0b69c06d3d91ecc1680ecb18c9dd074beed1cb1 
  keduvocdocument/keduvoccsvreader.cpp e3d471c4ecbb1236bae73714f27e357a1681ec70 
  keduvocdocument/keduvoccsvwriter.cpp 32172e47d3617c082378969735dbd23d3178f06e 
  keduvocdocument/keduvocdocument.h 9da14c62c84a07ffc53ef46f4c48e35824210d2c 
  keduvocdocument/keduvocdocument.cpp 7026ccb9046968821b11ce6e07276d81e58e41c6 
  keduvocdocument/keduvockvtml2reader.cpp 
3884724422c318e34a5b8efc5e05481e27f7c6bc 
  keduvocdocument/keduvockvtmlcompability.cpp 
e486729054a9e69fd52c4e4f1031a0bdbb3433cf 
  keduvocdocument/keduvocpaukerreader.cpp 
4ded3e480222ea9401b8cbfddad2b99ba82036fb 
  keduvocdocument/keduvoctranslation.h c41d293755f0df7f87a41300569b093d020beb06 
  keduvocdocument/keduvocvokabelnreader.cpp 
ffbd64d3cd50e519af319d6d52a1491a7ed1588a 
  keduvocdocument/keduvocwqlreader.cpp 0841b1054ec41b93f4fffb1165c2c0d51806aeae 
  keduvocdocument/keduvocxdxfreader.cpp 
4317f6ff1fbc8a4a19c2bbcc72af2ace295743b6 
  keduvocdocument/sharedkvtmlfiles.cpp 9f74aa2af2f69f25fca8efa1585b8c8ea1127cd9 
  keduvocdocument/tests/CMakeLists.txt ac01a2b4a3e3b925517b2f004feb93bf365344a7 
  keduvocdocument/tests/converter.cpp 1916b2269a88e932beb46f165e6cebebcefecb3c 
  keduvocdocument/tests/sharedkvtmlfilestest.cpp 
489dad4fcafa0a97fe4e93905206fb0fc53e0cf5 

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


Testing
---

It still builds and the tests run.

Unrelated the sharedkvtmlfilestest exposes a bug in KEduVocDocument::open where 
the KFilterDev wont open, (bug from previous commit) not sure what to do here 
to fix it though.


Thanks,

Jeremy Whiting

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

Review Request 118970: Remove KDELibs4Support dependency.

[Jeremy Whiting]

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

Review request for KDE Edu, KDE Frameworks, Aleix Pol Gonzalez, and Inge Wallin.


Repository: libkdeedu


Description
---

Port tests away from KCmdLineArgs to QCommandLineParser.
Port from KDE_DEPRECATED to KEDUVOCDOCUMENT_DEPRECATED (Maybe we should remove 
these?)
Port from KLocale to klocalizedstring.h


Diffs
-

  CMakeLists.txt 4feb10b67f78530170aaae216b9347cf94c0e51a 
  keduvocdocument/CMakeLists.txt c242c46fa79f128d63ccdeb5c4f611ad7294c874 
  keduvocdocument/keduvocarticle.h b0b69c06d3d91ecc1680ecb18c9dd074beed1cb1 
  keduvocdocument/keduvoccsvreader.cpp e3d471c4ecbb1236bae73714f27e357a1681ec70 
  keduvocdocument/keduvoccsvwriter.cpp 32172e47d3617c082378969735dbd23d3178f06e 
  keduvocdocument/keduvocdocument.h 9da14c62c84a07ffc53ef46f4c48e35824210d2c 
  keduvocdocument/keduvocdocument.cpp 7026ccb9046968821b11ce6e07276d81e58e41c6 
  keduvocdocument/keduvockvtml2reader.cpp 
3884724422c318e34a5b8efc5e05481e27f7c6bc 
  keduvocdocument/keduvockvtmlcompability.cpp 
e486729054a9e69fd52c4e4f1031a0bdbb3433cf 
  keduvocdocument/keduvocpaukerreader.cpp 
4ded3e480222ea9401b8cbfddad2b99ba82036fb 
  keduvocdocument/keduvoctranslation.h c41d293755f0df7f87a41300569b093d020beb06 
  keduvocdocument/keduvocvokabelnreader.cpp 
ffbd64d3cd50e519af319d6d52a1491a7ed1588a 
  keduvocdocument/keduvocwqlreader.cpp 0841b1054ec41b93f4fffb1165c2c0d51806aeae 
  keduvocdocument/keduvocxdxfreader.cpp 
4317f6ff1fbc8a4a19c2bbcc72af2ace295743b6 
  keduvocdocument/sharedkvtmlfiles.cpp 9f74aa2af2f69f25fca8efa1585b8c8ea1127cd9 
  keduvocdocument/tests/CMakeLists.txt ac01a2b4a3e3b925517b2f004feb93bf365344a7 
  keduvocdocument/tests/converter.cpp 1916b2269a88e932beb46f165e6cebebcefecb3c 
  keduvocdocument/tests/sharedkvtmlfilestest.cpp 
489dad4fcafa0a97fe4e93905206fb0fc53e0cf5 

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


Testing
---

It still builds and the tests run.

Unrelated the sharedkvtmlfilestest exposes a bug in KEduVocDocument::open where 
the KFilterDev wont open, (bug from previous commit) not sure what to do here 
to fix it though.


Thanks,

Jeremy Whiting

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

Re: Review Request 118970: libkeduvocdocument: Remove KDELibs4Support dependency.

[Jeremy Whiting]

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

(Updated June 26, 2014, 7:57 p.m.)


Review request for KDE Edu, KDE Frameworks, Aleix Pol Gonzalez, and Inge Wallin.


Changes
---

Added library name to summary (Need to follow my own advice...)


Summary (updated)
-

libkeduvocdocument: Remove KDELibs4Support dependency.


Repository: libkdeedu


Description
---

Port tests away from KCmdLineArgs to QCommandLineParser.
Port from KDE_DEPRECATED to KEDUVOCDOCUMENT_DEPRECATED (Maybe we should remove 
these?)
Port from KLocale to klocalizedstring.h


Diffs
-

  CMakeLists.txt 4feb10b67f78530170aaae216b9347cf94c0e51a 
  keduvocdocument/CMakeLists.txt c242c46fa79f128d63ccdeb5c4f611ad7294c874 
  keduvocdocument/keduvocarticle.h b0b69c06d3d91ecc1680ecb18c9dd074beed1cb1 
  keduvocdocument/keduvoccsvreader.cpp e3d471c4ecbb1236bae73714f27e357a1681ec70 
  keduvocdocument/keduvoccsvwriter.cpp 32172e47d3617c082378969735dbd23d3178f06e 
  keduvocdocument/keduvocdocument.h 9da14c62c84a07ffc53ef46f4c48e35824210d2c 
  keduvocdocument/keduvocdocument.cpp 7026ccb9046968821b11ce6e07276d81e58e41c6 
  keduvocdocument/keduvockvtml2reader.cpp 
3884724422c318e34a5b8efc5e05481e27f7c6bc 
  keduvocdocument/keduvockvtmlcompability.cpp 
e486729054a9e69fd52c4e4f1031a0bdbb3433cf 
  keduvocdocument/keduvocpaukerreader.cpp 
4ded3e480222ea9401b8cbfddad2b99ba82036fb 
  keduvocdocument/keduvoctranslation.h c41d293755f0df7f87a41300569b093d020beb06 
  keduvocdocument/keduvocvokabelnreader.cpp 
ffbd64d3cd50e519af319d6d52a1491a7ed1588a 
  keduvocdocument/keduvocwqlreader.cpp 0841b1054ec41b93f4fffb1165c2c0d51806aeae 
  keduvocdocument/keduvocxdxfreader.cpp 
4317f6ff1fbc8a4a19c2bbcc72af2ace295743b6 
  keduvocdocument/sharedkvtmlfiles.cpp 9f74aa2af2f69f25fca8efa1585b8c8ea1127cd9 
  keduvocdocument/tests/CMakeLists.txt ac01a2b4a3e3b925517b2f004feb93bf365344a7 
  keduvocdocument/tests/converter.cpp 1916b2269a88e932beb46f165e6cebebcefecb3c 
  keduvocdocument/tests/sharedkvtmlfilestest.cpp 
489dad4fcafa0a97fe4e93905206fb0fc53e0cf5 

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


Testing
---

It still builds and the tests run.

Unrelated the sharedkvtmlfilestest exposes a bug in KEduVocDocument::open where 
the KFilterDev wont open, (bug from previous commit) not sure what to do here 
to fix it though.


Thanks,

Jeremy Whiting

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

Re: Review Request 118970: libkeduvocdocument: Remove KDELibs4Support dependency.

[Jeremy Whiting]

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

(Updated June 26, 2014, 10:55 p.m.)


Review request for KDE Edu, KDE Frameworks, Aleix Pol Gonzalez, and Inge Wallin.


Changes
---

Unrelated sharedkvtmlfilestest bug fixed.


Repository: libkdeedu


Description
---

Port tests away from KCmdLineArgs to QCommandLineParser.
Port from KDE_DEPRECATED to KEDUVOCDOCUMENT_DEPRECATED (Maybe we should remove 
these?)
Port from KLocale to klocalizedstring.h


Diffs (updated)
-

  CMakeLists.txt 4feb10b67f78530170aaae216b9347cf94c0e51a 
  keduvocdocument/CMakeLists.txt c242c46fa79f128d63ccdeb5c4f611ad7294c874 
  keduvocdocument/keduvocarticle.h b0b69c06d3d91ecc1680ecb18c9dd074beed1cb1 
  keduvocdocument/keduvoccsvreader.cpp e3d471c4ecbb1236bae73714f27e357a1681ec70 
  keduvocdocument/keduvoccsvwriter.cpp 32172e47d3617c082378969735dbd23d3178f06e 
  keduvocdocument/keduvocdocument.h 9da14c62c84a07ffc53ef46f4c48e35824210d2c 
  keduvocdocument/keduvocdocument.cpp 7026ccb9046968821b11ce6e07276d81e58e41c6 
  keduvocdocument/keduvockvtml2reader.cpp 
3884724422c318e34a5b8efc5e05481e27f7c6bc 
  keduvocdocument/keduvockvtmlcompability.cpp 
e486729054a9e69fd52c4e4f1031a0bdbb3433cf 
  keduvocdocument/keduvocpaukerreader.cpp 
4ded3e480222ea9401b8cbfddad2b99ba82036fb 
  keduvocdocument/keduvoctranslation.h c41d293755f0df7f87a41300569b093d020beb06 
  keduvocdocument/keduvocvokabelnreader.cpp 
ffbd64d3cd50e519af319d6d52a1491a7ed1588a 
  keduvocdocument/keduvocwqlreader.cpp 0841b1054ec41b93f4fffb1165c2c0d51806aeae 
  keduvocdocument/keduvocxdxfreader.cpp 
4317f6ff1fbc8a4a19c2bbcc72af2ace295743b6 
  keduvocdocument/sharedkvtmlfiles.cpp 9f74aa2af2f69f25fca8efa1585b8c8ea1127cd9 
  keduvocdocument/tests/CMakeLists.txt ac01a2b4a3e3b925517b2f004feb93bf365344a7 
  keduvocdocument/tests/converter.cpp 1916b2269a88e932beb46f165e6cebebcefecb3c 
  keduvocdocument/tests/sharedkvtmlfilestest.cpp 
489dad4fcafa0a97fe4e93905206fb0fc53e0cf5 

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


Testing
---

It still builds and the tests run.

Unrelated the sharedkvtmlfilestest exposes a bug in KEduVocDocument::open where 
the KFilterDev wont open, (bug from previous commit) not sure what to do here 
to fix it though.


Thanks,

Jeremy Whiting

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

git repo name in review request e-mail subject

[Jeremy Whiting]

Hey all,

In looking at frameworks e-mail each day I find it would be much
simpler if we would all add the git repo we are submitting the review
request for in the subject. e-mail with subjects like make
documentation match new values in code (not trying to single this one
out, many are not that descriptive when considering which framework
they are talking about) make sense once you open the e-mail but are
hard to distinguish when looking at the 50 (sometimes more) review
request mails that come to the list each day.  Imagine you maintain
one or two frameworks and if every rr e-mail contained the git repo it
is a request for in the subject (knewstuff: fix the bug blah
introduced by the lazy maintainer or whatnot) how quickly you could
go through the e-mail each day :)

just a suggestion,

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

Re: git repo name in review request e-mail subject

[Jeremy Whiting]

Ok, Added myself, good to know. That should help a bit.

On Wed, Apr 30, 2014 at 4:39 PM, Christoph Feck christ...@maxiom.de wrote:
 On Wednesday 30 April 2014 22:55:55 Jeremy Whiting wrote:
 In looking at frameworks e-mail each day I find it would be much
 simpler if we would all add the git repo we are submitting the
 review request for in the subject.

 If you have added yourself as a maintainer of a repository via
 TARGET_PEOPLE in its .reviewboardrc file, then you are mailed
 directly, while the other review request simply go to the list.
 Unfortunately, this doesn't always seem to work.

 Christoph Feck (kdepepo)
 ___
 Kde-frameworks-devel mailing list
 Kde-frameworks-devel@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: git repo name in review request e-mail subject

[Jeremy Whiting]

On Wed, Apr 30, 2014 at 6:08 PM, Michael Pyne mp...@kde.org wrote:
 On Wed, April 30, 2014 14:55:55 Jeremy Whiting wrote:
 Hey all,

 In looking at frameworks e-mail each day I find it would be much
 simpler if we would all add the git repo we are submitting the review
 request for in the subject. e-mail with subjects like make
 documentation match new values in code (not trying to single this one
 out, many are not that descriptive when considering which framework
 they are talking about) make sense once you open the e-mail but are
 hard to distinguish when looking at the 50 (sometimes more) review
 request mails that come to the list each day.  Imagine you maintain
 one or two frameworks and if every rr e-mail contained the git repo it
 is a request for in the subject (knewstuff: fix the bug blah
 introduced by the lazy maintainer or whatnot) how quickly you could
 go through the e-mail each day :)

 Sounds like you also get confused trying to figure out if a review request
 applies to a framework module you're maintaining or not. ;)

I'm not sure I understand what you mean. Isn't that just what I said? :)

Jeremy


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

libkomparediff2

[Jeremy Whiting]

Hello,

I've prepared a port of libkomparediff2 to KDE Frameworks and Qt 5.2
on the frameworks branch of it's git repo. If someone would take a
look and check if I did anything wrong that would be great.  It builds
here and the tests all pass, but a second (or more) set of eyes is
always welcome.

I guess another step to take with it would be to port it away from
KDELibs4Support and KIO::NetAccess ?

Any comments welcome, thanks,
Jeremy
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KSpeech

[Jeremy Whiting]

On Thu, Mar 6, 2014 at 6:43 AM, Frederik Gladhorn gladh...@kde.org wrote:
 Onsdag 5. mars 2014 23.04.12 skrev Jeremy Whiting:
 Took a quick read through that just now and it looks pretty promising
 from what I saw. I guess I don't know my way around gerrit very well
 because I couldn't see a place to comment on the code like
 reviewboard.
 Really the only difference between jovie and that class are the following:
 1. jovie has some old code and ui to control jobs at a fine grain that
 spd doesn't expose really well, so I left it out when I ported ktts to
 spd.

 I would like to expose voices and languages in a sensible fashion. This is
 tricky to get right cross-platform. I started with something on Linux but
 decided to implement other backends first before attempting to implement voice
 selection.
 For language/locale I think qtspeech should default to the system locale and
 let the user select a different one.

Using the system locale as default makes sense. What do you mean by
voices you mean something like spd's voice type (male1, male2,
female1, etc.)
Ktts had a complex system of specifying a voice with xml with
language, voice type, speed, pitch, etc. attributes and if an
attribute was empty it meant any voice with the other attributes was
acceptable. I think that's a bit too fine-grained for most cases
though, most uses I can think of just want to choose the voice type,
or even just the gender, and let the user/defaults choose the rest.
If more complex specification is wanted applications could always use
ssml to change the voice as part of the text they send to qtspeech.


 2. user defined filters with some sane/useful defaults (if we were to
 use QtSpeech for kde notifications, set konvi to speak all messages,
 there's not a way to let the user say change jpwhiting fregl: you
 rock into jpwhiting says fregl you rock)

 Maybe. I'd rather keep qtspeech very simple. My goals where to make it a tiny
 library that is lean, fast and async by using signals and slots.
 I want it to be good enough to be used in apps that use voice navigation, but
 also when writing a screen reader. Some level of configuration is required in
 any case. Let's come up with a good api that makes sense across platforms,
 then I'm in.

Right, simple is definitely good. I'm just wondering if it could
accept plugins that implement some filtering method to filter the
text. Then filters could be as simple as a regex to convert
xml/html/etc. text into something that makes sense audibly like that
example from irc, or a complex filter plugin to change the voice could
inject ssml into the text. Maybe something like

QAbstractSpeechFilter {
  public:
virtual QString filterText(QString text)
};

Then a simple filtermanager (or even part of the existing class) loads
the plugins and when say() is called it passes the text through all
the plugins filterText() methods.

Is there some other Qt library or class that takes plugins for
specific functionality we could use as inspiration for making this
work and look clean also?


 3. user configurability (As a user I can't set up which voice I would
 like all speech-using applications to use)

 As with other Qt libs, this is more for the platform to set up. Currently
 qtspeech uses whatever voice is selected system wide (aka the default). I
 think that is the right approach - follow what we get from the platform.
 For KDE I'd thus suggest creating a configuration module which lets the user
 choose the platform defaults.

Yeah, each platform could have its own configuration of the defaults
sure, the only part missing is a real-time configuration change. For
example if Jovie is reduced to a kcm to configure speech-dispatcher's
default voice and I start listening to a pdf from okular or something
and decide I need the pitch to be lower, changing the default voice
wont change the voice that speech-dispatcher is already using to read
the pdf.  Maybe that could be fixed with a patch to speech-dispatcher
to accept immediate default changes though, I'll have to think about
that.

 4. dbus, though this isn't as important if each application that uses
 speech links to the library and speech-dispatcher or the system apis
 do the async for us already anyway as you said.
 I don't see a point in adding dbus into the mix indeed. One thing that is
 interesting though is what kind of effect you get when opening the speech
 backend from two apps at the same time.

 Items 1 and 4 will be irrelevant in a KF5 world but I'm wondering how
 2 and 3 could be added either to qtspeech itself or as a kspeech
 library that wraps qtspeech for kde applications to use.

 Any thoughts on that? I would be pretty interested in helping with
 qtspeech if it greatly simplifies or even deprecates jovie as it looks
 like it could do possibly.

 I'd be more than happy to get contributions of course. I cannot promise much
 from my side, of course I'd like to continue working on this project as time
 permits (so far it really

KSpeech

[Jeremy Whiting]

Hello all, I've realized a bit ago that kspeech was not included in
the kdelibs split (probably because it was in staging at the time and
didn't conform to the other framework policies yet). I've cleaned it
up a bit and put it in my scratch space, but have some architectural
questions about it before I make it a proper framework.

1. The KSpeech dbus interface is old and showing its age. Many of the
methods are no longer implemented in the application itself since it
was ported to speech-dispatcher. One thing I would definitely like to
do is clean up/remove methods that aren't implemented currently (and
possibly re add some later on if speech-dispatcher gets better/more
support for job control, etc.) So the question about this is is KF5
time a good time to drop/clean up the dbus interface?

2. The KSpeech interface that was in kdelibs/interfaces is just that a
dbus interface only. I would like to make it a proper
library/framework with a QObject based class for talking to Jovie (the
application that implements the KSpeech dbus interface) and wonder if
other things such as what's currently in jovie/libkttsd should be in
the kspeech library also. If I move code from jovie into libkspeech
(or merge kspeech interface into libkttsd and make libkttsd a
framework likely renamed to libkspeech since libkttsd isn't a public
library anyway and has the old ktts name) what's the best way to
preserve the history of both the kspeech interface and libkttsd
sources. Didn't the plasma or kde-workspaces split do something fancy
with git where old history pointed to the old git repo somehow?
Along with this, if libkspeech is defining the kspeech dbus interface
and has a class to talk to that interface, does the interface still
need to be in servicetypes like the dbustexttospeech.desktop file that
was installed in /usr/share/kde4/servicetypes in kde4 times?

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

Re: kf5 alpha 1 : attica?

[Jeremy Whiting]

I can do the changes if needed. It just needs the changes here:
http://community.kde.org/Frameworks/Porting_Notes under Build System
?
I believe attica currently builds with both qt4 or qt5 based on cmake
options (if QT4_BUILD is set it builds with qt4). Is the qt4 branch
supposed to not use ECM then?

BR,
Jeremy

On Wed, Feb 5, 2014 at 5:47 AM,  frede...@gladhorn.de wrote:
 On Tuesday 4. February 2014 23.40.22 David Faure wrote:
 On Monday 03 February 2014 11:34:44 Kevin Ottens wrote:
  On Monday 03 February 2014 10:17:49 David Faure wrote:
   Any new module that should be added to this release, compared to TP1?
  
   Should I include attica?
 
  Since this question keeps popping up, let's integrate it. It should also
  be
  added to the list: http://community.kde.org/Frameworks/List

 Yes, but see what I wrote in the Tier status of attica  kwallet thread:
 there's some buildsystem work to be done for attica to be a proper
 framework
 (making it use ECM, so it can integrate better with the other frameworks
 and be fully consistent with them, including installing camelcase
 forwarding headers etc.), which also means moving the qt4 support into a
 separate branch first.
 Which brings us to the next topic: who as maintainer should approve this.

  Also, since no one stepped up to say if it should be in or out, I'd
 say it
  should be with no declared maintainer until someone claims it.

 I was under the impression that it had a maintainer, although right now I
 can't remember if that was Jeremy Whiting or Frederik Gladhorn or someone
 else. Cc'ing them. Guys, any input?

 (Note that overall this would lower the future maintainance work on
 attica's
 buildsystem, since it will just be maintained together with the other
 frameworks, by anyone who makes changes to ECM or across all frameworks.)

 I won't realistically get around to make any improvements and I have no
 idea about ECM, so I'd be very happy if someone could take over these
 tasks.

 I had the impression that Laszlo worked with attica for a while, but I
 don't know if he's available for any of this porting work.
 From my point of view, please just go ahead and change it as you think is
 sensible.

 Greetings,
 Frederik


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

Re: Review Request 115416: Improve knewstuff dependencies

[Jeremy Whiting]

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

Ship it!


Ship It!

- Jeremy Whiting


On Jan. 31, 2014, 11:49 a.m., Michael Palimaka wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/115416/
 ---
 
 (Updated Jan. 31, 2014, 11:49 a.m.)
 
 
 Review request for KDE Frameworks and Jeremy Whiting.
 
 
 Repository: knewstuff
 
 
 Description
 ---
 
 - QtDBus and QtNetwork are not used
 - Remove transitive framework dependencies
 - Add missing framework dependencies
 
 
 Diffs
 -
 
   src/CMakeLists.txt 9df24837f3915c2554d6be9c6be76ebfaee8cdcd 
   CMakeLists.txt aeed4d455498cc3ef4a24242b4d2c9c3f69809e3 
 
 Diff: https://git.reviewboard.kde.org/r/115416/diff/
 
 
 Testing
 ---
 
 Builds. Inspected CPP and UI includes and runtime links.
 
 
 Thanks,
 
 Michael Palimaka
 


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

kjs framework build failure

[Jeremy Whiting]

Hello,

In trying to build frameworks on arch here I'm getting a build error
in kjs/src/kjs/operations.cpp I'm not sure what I may be missing here,
others report it builds fine on other distros. The offending _isnan
seems to be in the original commit also, but I haven't tried to build
since the frameworks got split into individual repos. If you know what
I may be missing/doing wrong please let me know.  I'm using
kdesrc-build to build and have cleaned out my build folder and install
folders.

Attaching my build log.

BR,
Jeremy
# kdesrc-build running: 'make' '-j8'
# from directory: /home/jeremy/devel/kde/frameworksbuild/frameworks/kjs
Scanning dependencies of target kjs_bin_automoc
Scanning dependencies of target KF5JS_automoc
Scanning dependencies of target KF5JSApi_automoc
Scanning dependencies of target icemaker_automoc
Scanning dependencies of target testkjs_static_automoc
Scanning dependencies of target testkjs_automoc
[  1%] Scanning dependencies of target kjsapitest_automoc
Scanning dependencies of target ecmatest_automoc
[  2%] [  3%] [  4%] [  5%] [  6%] Automatic moc for target kjs_bin
[  7%] [  8%] Automatic moc for target KF5JSApi
Automatic moc for target testkjs_static
Automatic moc for target testkjs
Automatic moc for target ecmatest
Automatic moc for target KF5JS
Automatic moc for target kjsapitest
Automatic moc for target icemaker
[  8%] Built target kjs_bin_automoc
[  8%] [  8%] [  8%] Built target testkjs_automoc
Built target testkjs_static_automoc
Built target icemaker_automoc
[  8%] Built target KF5JSApi_automoc
Scanning dependencies of target icemaker
[ 12%] [ 12%] [ 12%] [ 13%] [ 14%] Building CXX object src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/codeprinter.cpp.o
Building CXX object src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/tablebuilder.cpp.o
Building CXX object src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/types.cpp.o
Building CXX object src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/lexer.cpp.o
Building CXX object src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/driver.cpp.o
[ 14%] Built target KF5JS_automoc
[ 15%] Building CXX object src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/parser.cpp.o
Generating moc_ecmatest.cpp
[ 15%] Built target ecmatest_automoc
[ 16%] Building CXX object src/kjs/CMakeFiles/icemaker.dir/icemaker_automoc.cpp.o
Generating kjsapitest.moc
[ 16%] Built target kjsapitest_automoc
Linking CXX executable icemaker
[ 16%] Built target icemaker
[ 17%] [ 18%] [ 20%] [ 20%] [ 21%] [ 23%] [ 24%] [ 25%] Generating opcodes.h, opcodes.cpp, machine.cpp
Generating number_object.lut.h
Generating regexp_object.lut.h
Generating date_object.lut.h
Generating math_object.lut.h
Generating string_object.lut.h
Generating json_object.lut.h
Generating array_object.lut.h
icemaker -41.9 for KJS/FrostByte
Generating bytecode instruction selection tables and VM dispatcher...
[ 26%] Generating lexer.lut.h
Scanning dependencies of target KF5JS
[ 27%] [ 28%] [ 29%] [ 30%] [ 31%] [ 32%] [ 34%] [ 35%] Building CXX object src/kjs/CMakeFiles/KF5JS.dir/collector.cpp.o
Building CXX object src/kjs/CMakeFiles/KF5JS.dir/grammar.cpp.o
Building CXX object src/kjs/CMakeFiles/KF5JS.dir/ustring.cpp.o
Building CXX object src/kjs/CMakeFiles/KF5JS.dir/nodes.cpp.o
Building CXX object src/kjs/CMakeFiles/KF5JS.dir/date_object.cpp.o
Building CXX object src/kjs/CMakeFiles/KF5JS.dir/lexer.cpp.o
Building CXX object src/kjs/CMakeFiles/KF5JS.dir/lookup.cpp.o
Building CXX object src/kjs/CMakeFiles/KF5JS.dir/operations.cpp.o
/home/jeremy/devel/kde/frameworks/frameworks/kjs/src/kjs/operations.cpp: In function ‘bool KJS::isNaN(double)’:
/home/jeremy/devel/kde/frameworks/frameworks/kjs/src/kjs/operations.cpp:55:20: error: ‘_isnan’ was not declared in this scope
 return _isnan(d) != 0;
^
/home/jeremy/devel/kde/frameworks/frameworks/kjs/src/kjs/operations.cpp:59:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1plus: some warnings being treated as errors
src/kjs/CMakeFiles/KF5JS.dir/build.make:268: recipe for target 'src/kjs/CMakeFiles/KF5JS.dir/operations.cpp.o' failed
make[2]: *** [src/kjs/CMakeFiles/KF5JS.dir/operations.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs
/home/jeremy/devel/kde/frameworks/frameworks/kjs/src/kjs/date_object.cpp:87:12: warning: unused parameter ‘t’ [-Wunused-parameter]
 inline int gmtoffset(const tm t)
^
CMakeFiles/Makefile2:103: recipe for target 'src/kjs/CMakeFiles/KF5JS.dir/all' failed
make[1]: *** [src/kjs/CMakeFiles/KF5JS.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
# kdesrc-build running: 'cmake' '/home/jeremy/devel/kde/frameworks/frameworks/kjs' '-DKDE4_BUILD_TESTS=TRUE' '-DLIB_SUFFIX=64' '-DBUILD_TESTING=TRUE' '-DCMAKE_BUILD_TYPE:STRING=debug' '-G' 'CodeBlocks - Unix Makefiles' '-DCMAKE_CXX_FLAGS:STRING=-pipe -DQT_STRICT_ITERATORS -DQURL_NO_CAST_FROM_STRING -DQT_NO_HTTP -DQT_NO_FTP -Wformat -Werror=format-security 

Review Request 113867: Add knewstuff public dependencies to it's config.cmake file.

[Jeremy Whiting]

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

Review request for KDE Frameworks.


Repository: kdelibs


Description
---

KNewStuff's Config.cmake is missing it's public dependencies. This adds them.


Diffs
-

  tier3/knewstuff/KNewStuffConfig.cmake.in 
54bee483444919ee0a337d117ff5f48139d04359 

Diff: http://git.reviewboard.kde.org/r/113867/diff/


Testing
---


Thanks,

Jeremy Whiting

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

Re: Review Request 113867: Add knewstuff public dependencies to it's config.cmake file.

[Jeremy Whiting]

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

(Updated Nov. 14, 2013, 6:40 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kdelibs


Description
---

KNewStuff's Config.cmake is missing it's public dependencies. This adds them.


Diffs
-

  tier3/knewstuff/KNewStuffConfig.cmake.in 
54bee483444919ee0a337d117ff5f48139d04359 

Diff: http://git.reviewboard.kde.org/r/113867/diff/


Testing
---


Thanks,

Jeremy Whiting

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

Review Request 113844: Move kspeech interface to tier3

[Jeremy Whiting]

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

Review request for KDE Frameworks.


Repository: kdelibs


Description
---

It builds and installs. Will make it conform to framework structure with src/ 
and whatnot after this is shipped.


Diffs
-

  interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 
  interfaces/kspeech/CMakeLists.txt  
  interfaces/kspeech/Mainpage.dox  
  interfaces/kspeech/dbustexttospeech.desktop  
  interfaces/kspeech/kspeech.h  
  interfaces/kspeech/org.kde.KSpeech.xml  
  tier3/CMakeLists.txt c801fd299d95f64d28676f80e86e2c86f9b39024 

Diff: http://git.reviewboard.kde.org/r/113844/diff/


Testing
---


Thanks,

Jeremy Whiting

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

Re: Review Request 113844: Move kspeech interface to tier3

[Jeremy Whiting]

 On Nov. 13, 2013, 10:22 a.m., Aleix Pol Gonzalez wrote:
  Why is it tier3? It doesn't seem to depend on anything, no?

No it doesn't depend on anything, but is specific to kde platform. I put it 
into tier3 because that's what I was told in the meeting, maybe another tier 
makes more sense though.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113844/#review43616
---


On Nov. 13, 2013, 10:16 a.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/113844/
 ---
 
 (Updated Nov. 13, 2013, 10:16 a.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 It builds and installs. Will make it conform to framework structure with src/ 
 and whatnot after this is shipped.
 
 
 Diffs
 -
 
   interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 
   interfaces/kspeech/CMakeLists.txt  
   interfaces/kspeech/Mainpage.dox  
   interfaces/kspeech/dbustexttospeech.desktop  
   interfaces/kspeech/kspeech.h  
   interfaces/kspeech/org.kde.KSpeech.xml  
   tier3/CMakeLists.txt c801fd299d95f64d28676f80e86e2c86f9b39024 
 
 Diff: http://git.reviewboard.kde.org/r/113844/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Jeremy Whiting
 


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

Re: Review Request 113844: Move kspeech interface to tier3

[Jeremy Whiting]

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

(Updated Nov. 13, 2013, 11:01 a.m.)


Review request for KDE Frameworks.


Changes
---

Updated to move to staging since the final tier isn't decided yet.


Repository: kdelibs


Description
---

It builds and installs. Will make it conform to framework structure with src/ 
and whatnot after this is shipped.


Diffs (updated)
-

  interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 
  interfaces/kspeech/CMakeLists.txt  
  interfaces/kspeech/Mainpage.dox  
  interfaces/kspeech/dbustexttospeech.desktop  
  interfaces/kspeech/kspeech.h  
  interfaces/kspeech/org.kde.KSpeech.xml  
  staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 

Diff: http://git.reviewboard.kde.org/r/113844/diff/


Testing
---


Thanks,

Jeremy Whiting

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

Re: Review Request 113844: Move kspeech interface to tier3

[Jeremy Whiting]

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

(Updated Nov. 13, 2013, 6:57 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kdelibs


Description
---

It builds and installs. Will make it conform to framework structure with src/ 
and whatnot after this is shipped.


Diffs
-

  interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 
  interfaces/kspeech/CMakeLists.txt  
  interfaces/kspeech/Mainpage.dox  
  interfaces/kspeech/dbustexttospeech.desktop  
  interfaces/kspeech/kspeech.h  
  interfaces/kspeech/org.kde.KSpeech.xml  
  staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 

Diff: http://git.reviewboard.kde.org/r/113844/diff/


Testing
---


Thanks,

Jeremy Whiting

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

Re: Review Request 113696: Rename knewstuff private headers to _p.h

[Jeremy Whiting]

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

(Updated Nov. 11, 2013, 10:39 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kdelibs


Description
---

Renamed knewstuff private headers to _p.h and adjusted #include's accordingly.


Diffs
-

  tier3/knewstuff/src/attica/atticaprovider.h 
38aacfa377c91c54951eec9923f9b1712a0f4e32 
  tier3/knewstuff/src/attica/atticaprovider.cpp 
b077b23a3decb644b6ab5d15dc1283dfcd0e05b2 
  tier3/knewstuff/src/core/author.h  
  tier3/knewstuff/src/core/author.cpp 12cde54d806fdf674fb413d59a586db831de082d 
  tier3/knewstuff/src/core/cache.h 03373377cb91df9d5448e6231b008bd7949a8364 
  tier3/knewstuff/src/core/cache.cpp 66e3ed13c690437cbbb3a43a518e22b5d5240581 
  tier3/knewstuff/src/core/engine.h 7f0bc3021ef21b1621bff51fcb76e0579452f6e7 
  tier3/knewstuff/src/core/engine.cpp 941b1d0753320f57641c868f94959d9bf93148f7 
  tier3/knewstuff/src/core/entryinternal.h 
08f6dcf02e0a765a80a0df24375381e1d6fdf909 
  tier3/knewstuff/src/core/entryinternal.cpp 
2eb592d771dbc3f5ec1e38b7c7d0231b49736543 
  tier3/knewstuff/src/core/installation.h 
aec5e71d449a3e13108e636553a721b56a1af08f 
  tier3/knewstuff/src/core/installation.cpp 
7ec710ac80ae2011e9d975aa5d00763b04b084bd 
  tier3/knewstuff/src/core/provider.h 0e3f7bc6efd3d205442c70d79035984848a1b7c8 
  tier3/knewstuff/src/core/provider.cpp 
294d8665971e8547abfccd47785f655a85d8796b 
  tier3/knewstuff/src/core/security.h  
  tier3/knewstuff/src/core/security.cpp 
eec03c39d3f1b5296ddd81525f4868359b46497c 
  tier3/knewstuff/src/core/upload.h  
  tier3/knewstuff/src/core/upload.cpp ef62cf10ad1d580df8b894ac70044ad9a286b827 
  tier3/knewstuff/src/core/xmlloader.h  
  tier3/knewstuff/src/core/xmlloader.cpp 
65b6de95c4902adb1beb2761dec54d7526036b2b 
  tier3/knewstuff/src/downloadmanager.cpp 
df06786b0cf136c2f7f52e85cbeb7a61835acad6 
  tier3/knewstuff/src/downloadwidget.cpp 
1d56e1106fb3ce1aa3f4a7f3b07a68732101b3ce 
  tier3/knewstuff/src/downloadwidget.ui 
17f2944e81c0510eb7ae85128e79e815eab1bf54 
  tier3/knewstuff/src/downloadwidget_p.h 
080e1779e0d2ed110da28cc087218262fad1f333 
  tier3/knewstuff/src/entry_p.h 73c1ee8619b171f90706ba3ed323abbd00add455 
  tier3/knewstuff/src/staticxml/staticxmlprovider.h 
52caed08f53d125928d12f329c96800530d9fcaa 
  tier3/knewstuff/src/staticxml/staticxmlprovider.cpp 
e7dd0686f122c938cf87959478acc97a0a25723b 
  tier3/knewstuff/src/ui/entrydetailsdialog.h 
0add71dfecd4f0cb8653e9a90568bad5d9d2e008 
  tier3/knewstuff/src/ui/entrydetailsdialog.cpp 
5a451086531c53af720a2874f5c3b5ed51d07423 
  tier3/knewstuff/src/ui/imageloader.h 5e87a7b7890b6678c4b94aacc1b2f84d001b7dd0 
  tier3/knewstuff/src/ui/imageloader.cpp 
8e6ed061e421e985535228599ff9da17303bae46 
  tier3/knewstuff/src/ui/imagepreviewwidget.h  
  tier3/knewstuff/src/ui/imagepreviewwidget.cpp 
d9d20775a9686715176ead2f24f122d82b88987b 
  tier3/knewstuff/src/ui/itemsgridviewdelegate.h 
a5d793d8c859c25639921cc9a05233cb9879377e 
  tier3/knewstuff/src/ui/itemsgridviewdelegate.cpp 
3970287927e8c17acc9347adbae4c342c78d389a 
  tier3/knewstuff/src/ui/itemsmodel.h 7bc691483b3f0a27dc0d35a7fa6a4ad877294c1a 
  tier3/knewstuff/src/ui/itemsmodel.cpp 
d972c53f2963dba4ed55bfb484005b77b056c323 
  tier3/knewstuff/src/ui/itemsview.h  
  tier3/knewstuff/src/ui/itemsview.cpp b200b651bf1c57b37c7d8cb8163246488e6b17fb 
  tier3/knewstuff/src/ui/itemsviewbasedelegate.h 
bbb08dbc1755b9d9c5bde20c27e7bf368c149c29 
  tier3/knewstuff/src/ui/itemsviewbasedelegate.cpp 
89e91f9563f95985759388dcfca76d480a9dedba 
  tier3/knewstuff/src/ui/itemsviewdelegate.h 
1df97a36fc72d9eb3b2d07c5edff0170db459ea5 
  tier3/knewstuff/src/ui/itemsviewdelegate.cpp 
5289ee0093e7e4d02e6250bad8807f7c7e0d04c7 
  tier3/knewstuff/src/ui/progressindicator.h  
  tier3/knewstuff/src/ui/progressindicator.cpp 
ab06ff19c103c4d809d9ef4b14586bcd936e75c5 
  tier3/knewstuff/src/upload/atticahelper.h  
  tier3/knewstuff/src/upload/atticahelper.cpp 
c17b743c29943fbd25020dc9c8b7a0862cdc2458 
  tier3/knewstuff/src/uploaddialog_p.h 084d626c095465b5176aa928fed1d6d6342e6e2d 

Diff: http://git.reviewboard.kde.org/r/113696/diff/


Testing
---

It still builds.


Thanks,

Jeremy Whiting

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

Re: kdelibs/interfaces/khexedit

[Jeremy Whiting]

I see, and agree. So the way forward with kspeech would be to make it
it's own framework. then at some point turn the header/dbus interface
into a library that can hide the implementation details of using the
dbus interface directly, right?
Something like libkspeech.so that has a class/namespace to interact
with the speech dbus interface itself.

BR,
Jeremy

On Mon, Nov 11, 2013 at 4:33 AM, Kevin Ottens er...@kde.org wrote:
 On Monday 11 November 2013 11:13:37 David Faure wrote:
 On Sunday 10 November 2013 15:28:27 Kevin Ottens wrote:
  On Sunday 10 November 2013 11:15:58 Dominik Haumann wrote:
   On Sunday 10 November 2013 09:47:41 David Faure wrote:
On Sunday 10 November 2013 04:32:12 Friedrich W. H. Kossebau wrote:
 So from my point of view, especially given the idea of KF5, I see no
 more need for interfaces/khexedit. Rather do I see the Okteta libs
 themselves (the core ones for simple widget things) one day being
 added
 to KF5, now that things are modular :)
   
Yep, makes sense.
   
I'll just delete interfaces/khexedit then, thanks for the input.
  
   Btw, this is basically the same solution as we take with KTextEditor:
   The
   KTextEditor interfaces are not part of some other module anymore.
   Instead
   they are directly shipped with Kate Part for KF5. This makes sense for
   the
   simple reason that there is no other KTextEditor implementation than
   Kate
   Part (for 10 years now). From this perspective. The same basically holds
   for Okteta imo: If you need a hex editor component, just state that as
   dependency at compile time and all is fine.
  
   So as I see it, removing interfaces/khexedit is the right way to go :-)
 
  Actually that's probably the way to go for the other interfaces too...
  Like
  the kspeech one.

 Well, it's a bit different.

 okteta provides a library that people can link to directly.
 kspeech, on the other hand, is a daemon with a dbus interface.
 The files in interfaces/kspeech are the dbus interface and a simple header
 to define enum values. In a sense *that* is the library (but it doesn't
 even need a .so). What I mean is, *that* is the framework that needs to
 be found at compilation time.
 But OK, the idea of frameworks is to bundle the compile-time bits with the
 runtime bits, so what you're saying is, a kspeech framework should include
 both this stuff and the daemon.

 Yes, also it's kind of odd to not have a library hiding the implementation
 details of the actual access to the daemon... It's fragile.

 We could still start the framework with the compile-time bits for now, and
 add the daemon later on, much like we plan to do with a lot of kde-runtime
 after the kdelibs splitting.

 Yes, sounds good to me.

 Regards.
 --
 Kévin Ottens, http://ervin.ipsquad.net

 KDAB - proud supporter of KDE, http://www.kdab.com


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

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

Re: the kspeech interface

[Jeremy Whiting]

I was actually wondering that myself the other day as I added to it in
kdelibs master (that got branched into KDE/4.12) for a feature that
hit jovie in KDE SC 4.12.

It's used but really only needed to expose jovie's dbus interface for
applications to use. Interestingly, knotify uses jovie but doesn't
include kspeech.h somehow. Could we move the dbus interface into
kdeaccessibility/jovie and install it only when jovie is installed,
and use the dbus interface the same way it is used in knotify in the
places it's currently used directly?

Jeremy

On Fri, Nov 8, 2013 at 5:53 PM, David Faure fa...@kde.org wrote:
 Hi Jeremy,

 I'm looking at kdelibs-frameworks/interface/kspeech, and trying to find a home
 for it, in the KF5 reorganization.

 I see that it's actually used in a number of places
 (http://lxr.kde.org/ident?i=soPlainText for instance).
 and that it's basically just a header file that depends only on QtCore,
 plus some data files (dbus xml, desktop file).

 Are you still happy with that interface?
 Any idea where it would belong, in KF5?
 Maybe in kdbusaddons, since it's only usable with a dbus dependency?

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

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

Re: the kspeech interface

[Jeremy Whiting]

Oops, that link was just users of soPlainText.  It seems
http://lxr.kde.org/ident?i=KSpeech the class itself is used in quite a
few places, and is how any application uses speech capabilities. I
guess kdbusaddons is as good a place as any for it and it will need to
stay in kdelibs itself.

On Fri, Nov 8, 2013 at 10:40 PM, Jeremy Whiting jpwhit...@kde.org wrote:
 I was actually wondering that myself the other day as I added to it in
 kdelibs master (that got branched into KDE/4.12) for a feature that
 hit jovie in KDE SC 4.12.

 It's used but really only needed to expose jovie's dbus interface for
 applications to use. Interestingly, knotify uses jovie but doesn't
 include kspeech.h somehow. Could we move the dbus interface into
 kdeaccessibility/jovie and install it only when jovie is installed,
 and use the dbus interface the same way it is used in knotify in the
 places it's currently used directly?

 Jeremy

 On Fri, Nov 8, 2013 at 5:53 PM, David Faure fa...@kde.org wrote:
 Hi Jeremy,

 I'm looking at kdelibs-frameworks/interface/kspeech, and trying to find a 
 home
 for it, in the KF5 reorganization.

 I see that it's actually used in a number of places
 (http://lxr.kde.org/ident?i=soPlainText for instance).
 and that it's basically just a header file that depends only on QtCore,
 plus some data files (dbus xml, desktop file).

 Are you still happy with that interface?
 Any idea where it would belong, in KF5?
 Maybe in kdbusaddons, since it's only usable with a dbus dependency?

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

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

Review Request 113696: Rename knewstuff private headers to _p.h

[Jeremy Whiting]

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

Review request for KDE Frameworks.


Repository: kdelibs


Description
---

Renamed knewstuff private headers to _p.h and adjusted #include's accordingly.


Diffs
-

  tier3/knewstuff/src/attica/atticaprovider.h 
38aacfa377c91c54951eec9923f9b1712a0f4e32 
  tier3/knewstuff/src/attica/atticaprovider.cpp 
b077b23a3decb644b6ab5d15dc1283dfcd0e05b2 
  tier3/knewstuff/src/core/author.h  
  tier3/knewstuff/src/core/author.cpp 12cde54d806fdf674fb413d59a586db831de082d 
  tier3/knewstuff/src/core/cache.h 03373377cb91df9d5448e6231b008bd7949a8364 
  tier3/knewstuff/src/core/cache.cpp 66e3ed13c690437cbbb3a43a518e22b5d5240581 
  tier3/knewstuff/src/core/engine.h 7f0bc3021ef21b1621bff51fcb76e0579452f6e7 
  tier3/knewstuff/src/core/engine.cpp 941b1d0753320f57641c868f94959d9bf93148f7 
  tier3/knewstuff/src/core/entryinternal.h 
08f6dcf02e0a765a80a0df24375381e1d6fdf909 
  tier3/knewstuff/src/core/entryinternal.cpp 
2eb592d771dbc3f5ec1e38b7c7d0231b49736543 
  tier3/knewstuff/src/core/installation.h 
aec5e71d449a3e13108e636553a721b56a1af08f 
  tier3/knewstuff/src/core/installation.cpp 
7ec710ac80ae2011e9d975aa5d00763b04b084bd 
  tier3/knewstuff/src/core/provider.h 0e3f7bc6efd3d205442c70d79035984848a1b7c8 
  tier3/knewstuff/src/core/provider.cpp 
294d8665971e8547abfccd47785f655a85d8796b 
  tier3/knewstuff/src/core/security.h  
  tier3/knewstuff/src/core/security.cpp 
eec03c39d3f1b5296ddd81525f4868359b46497c 
  tier3/knewstuff/src/core/upload.h  
  tier3/knewstuff/src/core/upload.cpp ef62cf10ad1d580df8b894ac70044ad9a286b827 
  tier3/knewstuff/src/core/xmlloader.h  
  tier3/knewstuff/src/core/xmlloader.cpp 
65b6de95c4902adb1beb2761dec54d7526036b2b 
  tier3/knewstuff/src/downloadmanager.cpp 
df06786b0cf136c2f7f52e85cbeb7a61835acad6 
  tier3/knewstuff/src/downloadwidget.cpp 
1d56e1106fb3ce1aa3f4a7f3b07a68732101b3ce 
  tier3/knewstuff/src/downloadwidget.ui 
17f2944e81c0510eb7ae85128e79e815eab1bf54 
  tier3/knewstuff/src/downloadwidget_p.h 
080e1779e0d2ed110da28cc087218262fad1f333 
  tier3/knewstuff/src/entry_p.h 73c1ee8619b171f90706ba3ed323abbd00add455 
  tier3/knewstuff/src/staticxml/staticxmlprovider.h 
52caed08f53d125928d12f329c96800530d9fcaa 
  tier3/knewstuff/src/staticxml/staticxmlprovider.cpp 
e7dd0686f122c938cf87959478acc97a0a25723b 
  tier3/knewstuff/src/ui/entrydetailsdialog.h 
0add71dfecd4f0cb8653e9a90568bad5d9d2e008 
  tier3/knewstuff/src/ui/entrydetailsdialog.cpp 
5a451086531c53af720a2874f5c3b5ed51d07423 
  tier3/knewstuff/src/ui/imageloader.h 5e87a7b7890b6678c4b94aacc1b2f84d001b7dd0 
  tier3/knewstuff/src/ui/imageloader.cpp 
8e6ed061e421e985535228599ff9da17303bae46 
  tier3/knewstuff/src/ui/imagepreviewwidget.h  
  tier3/knewstuff/src/ui/imagepreviewwidget.cpp 
d9d20775a9686715176ead2f24f122d82b88987b 
  tier3/knewstuff/src/ui/itemsgridviewdelegate.h 
a5d793d8c859c25639921cc9a05233cb9879377e 
  tier3/knewstuff/src/ui/itemsgridviewdelegate.cpp 
3970287927e8c17acc9347adbae4c342c78d389a 
  tier3/knewstuff/src/ui/itemsmodel.h 7bc691483b3f0a27dc0d35a7fa6a4ad877294c1a 
  tier3/knewstuff/src/ui/itemsmodel.cpp 
d972c53f2963dba4ed55bfb484005b77b056c323 
  tier3/knewstuff/src/ui/itemsview.h  
  tier3/knewstuff/src/ui/itemsview.cpp b200b651bf1c57b37c7d8cb8163246488e6b17fb 
  tier3/knewstuff/src/ui/itemsviewbasedelegate.h 
bbb08dbc1755b9d9c5bde20c27e7bf368c149c29 
  tier3/knewstuff/src/ui/itemsviewbasedelegate.cpp 
89e91f9563f95985759388dcfca76d480a9dedba 
  tier3/knewstuff/src/ui/itemsviewdelegate.h 
1df97a36fc72d9eb3b2d07c5edff0170db459ea5 
  tier3/knewstuff/src/ui/itemsviewdelegate.cpp 
5289ee0093e7e4d02e6250bad8807f7c7e0d04c7 
  tier3/knewstuff/src/ui/progressindicator.h  
  tier3/knewstuff/src/ui/progressindicator.cpp 
ab06ff19c103c4d809d9ef4b14586bcd936e75c5 
  tier3/knewstuff/src/upload/atticahelper.h  
  tier3/knewstuff/src/upload/atticahelper.cpp 
c17b743c29943fbd25020dc9c8b7a0862cdc2458 
  tier3/knewstuff/src/uploaddialog_p.h 084d626c095465b5176aa928fed1d6d6342e6e2d 

Diff: http://git.reviewboard.kde.org/r/113696/diff/


Testing
---

It still builds.


Thanks,

Jeremy Whiting

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

Re: Review Request 113510: Deprecate methods in kimageio

[Jeremy Whiting]

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

(Updated Nov. 2, 2013, 7:04 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kdelibs


Description
---

KImageIO functions can be deprecated in favor of QImageReader and QImageWriter 
functionality.


Diffs
-

  kio/kio/kimageio.h cecadf1 

Diff: http://git.reviewboard.kde.org/r/113510/diff/


Testing
---

it still builds.


Thanks,

Jeremy Whiting

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

Re: Review Request 113500: make KNewStuff build on its own

[Jeremy Whiting]

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

(Updated Oct. 30, 2013, 9:41 a.m.)


Review request for KDE Frameworks.


Changes
---

Rebased on upstream frameworks branch.


Repository: kdelibs


Description
---

With these changes, KNewStuff can build on it's own and as part of kdelibs.


Diffs (updated)
-

  tier3/knewstuff/CMakeLists.txt 497ab8d92622f917b6f37e1a58f62645ed298b2c 
  tier3/knewstuff/src/CMakeLists.txt 0cdfe43608397b756aba80dcc9c47c7ddf398d66 

Diff: http://git.reviewboard.kde.org/r/113500/diff/


Testing
---

Builds by itself and as part of kdelibs.


Thanks,

Jeremy Whiting

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

Review Request 113510: Deprecate methods in kimageio

[Jeremy Whiting]

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

Review request for KDE Frameworks.


Repository: kdelibs


Description
---

KImageIO functions can be deprecated in favor of QImageReader and QImageWriter 
functionality.


Diffs
-

  kio/kio/kimageio.h cecadf1 

Diff: http://git.reviewboard.kde.org/r/113510/diff/


Testing
---

it still builds.


Thanks,

Jeremy Whiting

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

Review Request 113500: make KNewStuff build on its own

[Jeremy Whiting]

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

Review request for KDE Frameworks.


Repository: kdelibs


Description
---

With these changes, KNewStuff can build on it's own and as part of kdelibs.


Diffs
-

  tier3/knewstuff/CMakeLists.txt 0e2136d07261f992022ecff3fa5948c34202585d 
  tier3/knewstuff/src/CMakeLists.txt ec9a44a4c3535157d05375ab9a13b247702444dd 

Diff: http://git.reviewboard.kde.org/r/113500/diff/


Testing
---

Builds by itself and as part of kdelibs.


Thanks,

Jeremy Whiting

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

Review Request 113388: Port knewstuff from KImageIO to QImageReader

[Jeremy Whiting]

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

Review request for KDE Frameworks.


Repository: kdelibs


Description
---

Ported knewstuff from KImageIO to QImageReader to get the qimage supported file 
formats to put in a filter for QFileDialog.


Diffs
-

  knewstuff/src/CMakeLists.txt a42d35443c0d3596d8ef18e46a1ec905fd14a33a 
  knewstuff/src/uploaddialog.cpp 6e4630caf93fe7b589e3365c2459e3ae103f3b1b 
  knewstuff/src/uploaddialog_p.h dca105910890c618e16724fc1944afda508842c1 

Diff: http://git.reviewboard.kde.org/r/113388/diff/


Testing
---

Builds.


Thanks,

Jeremy Whiting

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

Re: Review Request 113388: Port knewstuff from KImageIO to QImageReader

[Jeremy Whiting]

 On Oct. 22, 2013, 10:46 a.m., Alex Merry wrote:
  knewstuff/src/uploaddialog.cpp, lines 823-833
  http://git.reviewboard.kde.org/r/113388/diff/1/?file=204524#file204524line823
 
  Does this actually produce a list of the right form?  It looks like it 
  will generate something like png;;jpg;;jpeg;;gif;;[etc], while the 
  QFileDialog docs 
  (http://doc-snapshot.qt-project.org/qt5-stable/qfiledialog.html#getOpenFileName)
   suggest you want something like PNG image (*.png);;JPG image 
  (*.jpg);;[etc].
  
  The KImageIO code, incidentally, produced a different format again.  It 
  also added an All images thing to the start.

Actually it probably doesn't generate the right string, and also after 
discussing with david on irc it's a better idea to use supportedMimeTypes() and 
give that to the QFileDialog instead, so I'll redo this patch that way.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113388/#review42163
---


On Oct. 22, 2013, 10:06 a.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/113388/
 ---
 
 (Updated Oct. 22, 2013, 10:06 a.m.)
 
 
 Review request for KDE Frameworks.
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 Ported knewstuff from KImageIO to QImageReader to get the qimage supported 
 file formats to put in a filter for QFileDialog.
 
 
 Diffs
 -
 
   knewstuff/src/CMakeLists.txt a42d35443c0d3596d8ef18e46a1ec905fd14a33a 
   knewstuff/src/uploaddialog.cpp 6e4630caf93fe7b589e3365c2459e3ae103f3b1b 
   knewstuff/src/uploaddialog_p.h dca105910890c618e16724fc1944afda508842c1 
 
 Diff: http://git.reviewboard.kde.org/r/113388/diff/
 
 
 Testing
 ---
 
 Builds.
 
 
 Thanks,
 
 Jeremy Whiting
 


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

Re: Review Request 112730: add CMake changes to knewstuff

[Jeremy Whiting]

 On Oct. 12, 2013, 10:43 a.m., David Faure wrote:
  knewstuff/KNewStuffConfig.cmake.in, line 4
  http://git.reviewboard.kde.org/r/112730/diff/3/?file=200166#file200166line4
 
  why is kjs listed as a dependency here but not in the cmakelists.txt?

Ah, the Config.cmake.in I copied from had KJS, so should I list the public 
dependencies in the Config.cmake or the private ones? or both?


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112730/#review41599
---


On Oct. 9, 2013, 2:24 p.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/112730/
 ---
 
 (Updated Oct. 9, 2013, 2:24 p.m.)
 
 
 Review request for KDE Frameworks, Albert Astals Cid, David Faure, and 
 Chusslove Illich.
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 This makes it so I can mkdir build; cd build; cmake ../; make install from 
 knewstuff sources.
 It's still using KDE4_KIO_LIBS and find_package(KIO) since not all of the kio 
 libraries have been split out apparently.
 I'm not sure why sources had to be changed, but I had to add includes of 
 klocalizedstring where we didn't need them before somehow.
 
 
 Diffs
 -
 
   knewstuff/CMakeLists.txt 8ee3653c92692d606a2ff6d1fa69d0d8deb5439a 
   knewstuff/KNewStuffConfig.cmake.in PRE-CREATION 
   knewstuff/src/CMakeLists.txt 5bdf0f6ee619751d66ec48dc7516a73cfe89a8c0 
   knewstuff/src/downloaddialog.cpp 3294c7c04c7879320fc0949db0310868bd6fa4fa 
   knewstuff/src/downloadwidget.cpp 64b7673d67b4e2f15007fc1a3f57d3da844d1dc0 
   knewstuff/src/ui/entrydetailsdialog.cpp 
 65b75d79941d9026f368f82c7b6df91d754e0925 
   knewstuff/src/uploaddialog.cpp dbde573e8c3a477755c8c866d0ca1fccd1a35729 
 
 Diff: http://git.reviewboard.kde.org/r/112730/diff/
 
 
 Testing
 ---
 
 It builds and installs.
 
 
 Thanks,
 
 Jeremy Whiting
 


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

Re: Review Request 112730: add CMake changes to knewstuff

[Jeremy Whiting]

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

(Updated Oct. 14, 2013, 10:56 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Albert Astals Cid, David Faure, and 
Chusslove Illich.


Repository: kdelibs


Description
---

This makes it so I can mkdir build; cd build; cmake ../; make install from 
knewstuff sources.
It's still using KDE4_KIO_LIBS and find_package(KIO) since not all of the kio 
libraries have been split out apparently.
I'm not sure why sources had to be changed, but I had to add includes of 
klocalizedstring where we didn't need them before somehow.


Diffs
-

  knewstuff/CMakeLists.txt 8ee3653c92692d606a2ff6d1fa69d0d8deb5439a 
  knewstuff/KNewStuffConfig.cmake.in PRE-CREATION 
  knewstuff/src/CMakeLists.txt 5bdf0f6ee619751d66ec48dc7516a73cfe89a8c0 
  knewstuff/src/downloaddialog.cpp 3294c7c04c7879320fc0949db0310868bd6fa4fa 
  knewstuff/src/downloadwidget.cpp 64b7673d67b4e2f15007fc1a3f57d3da844d1dc0 
  knewstuff/src/ui/entrydetailsdialog.cpp 
65b75d79941d9026f368f82c7b6df91d754e0925 
  knewstuff/src/uploaddialog.cpp dbde573e8c3a477755c8c866d0ca1fccd1a35729 

Diff: http://git.reviewboard.kde.org/r/112730/diff/


Testing
---

It builds and installs.


Thanks,

Jeremy Whiting

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