Re: kdelibs and Qt version dependency
On Wednesday, June 6, 2012 20:32:49 Albert Astals Cid wrote: Someone from plasma? summary: no hard requirement to jump to Qt 4.8 from plasma at this time ... Qt 4.8 brings a number of speed improvements and general goodness which certainly helps the various Plasma workspaces, but i do not believe we have any hard requirements on it at this time ... so i'd love to see people using Qt 4.8, but we can keep a minimum 4.8 requirement for the time being. my only concern is that our team works with Qt 4.8 right now, most of our users will likely get Qt 4.8 with SC 4.9 packages and so our code will be well tested with Qt 4.8 and Qt 4.7 will not be as well tested. i don't think there is much we can do about that though, unless a magic QA fairy passes by dropping testers. :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: Extra KDE Telepathy modules moving to Extragear
Are there any further objections to moving these forward into extragear? No objections, just a question: How much of this works on Windows ? Unsure about the call UI, but I presume the logger could at least ? Best Regards, Laszlo Papp
Re: Extra KDE Telepathy modules moving to Extragear
On Thu, Jun 7, 2012 at 4:42 PM, Laszlo Papp lp...@kde.org wrote:
Are there any further objections to moving these forward into extragear?
This is probably not the best way:
https://projects.kde.org/projects/kdereview/ktp-call-ui/repository/revisions/master/entry/libktpcall/CMakeLists.txt#L25
https://projects.kde.org/projects/kdereview/ktp-call-ui/repository/revisions/master/entry/src/CMakeLists.txt#L21
Also, FoobarConfig{Version}.cmake is in favor of FindFoobar.cmake in this case:
https://projects.kde.org/projects/kdereview/ktp-call-ui/repository/revisions/master/entry/cmake/modules/FindKTp.cmake
I do not find a shipped FoobarConfig{Version}.cmake for the other one.
Best Regards,
Laszlo Papp
Re: Extra KDE Telepathy modules moving to Extragear
No objections, just a question: How much of this works on Windows ? Unsure about the call UI, but I presume the logger could at least ? Last time I tried, I had issues with python3 that the KDE Windows project had been using. I have mentioned that to George. It would be nice in the future (so not now instantly) to get that resolved. I presume this would mean a python3 porting or some other way around. Best Regards, Laszlo Papp
Re: Review Request: update the outdated documention and sample code of kde_terminal_interface
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105155/ --- (Updated June 7, 2012, 2:44 p.m.) Review request for kdelibs and Konsole. Changes --- Add kdelibs into groups Description (updated) --- main change: 1. update the outdated inline document for kde_terminal_interface(which contained some signals that does not exist ever since KDE 4.0) 2. update the example code to make it really work and avoid using hardcoded library name 'libkonsolepart'. 3. update test/CMakeList.txt to make it stand-alone. I don't think that 'test' subfolder is ever used for building test case. Maybe it is more accurate to rename that folder to 'example'. But I could be wrong. This addresses bug 257350. http://bugs.kde.org/show_bug.cgi?id=257350 Diffs - interfaces/terminal/kde_terminal_interface.h 649d674 interfaces/terminal/test/CMakeLists.txt a0fa93a interfaces/terminal/test/main.h 8a3197a interfaces/terminal/test/main.cc 132cee1 Diff: http://git.reviewboard.kde.org/r/105155/diff/ Testing --- The sample code works fine with kdelibs/4.8 and konsole built from master. Thanks, Jekyll Wu
Re: kdelibs and Qt version dependency
El Dijous, 7 de juny de 2012, a les 09:27:22, Aaron J. Seigo va escriure: On Wednesday, June 6, 2012 20:32:49 Albert Astals Cid wrote: Someone from plasma? summary: no hard requirement to jump to Qt 4.8 from plasma at this time ... Qt 4.8 brings a number of speed improvements and general goodness which certainly helps the various Plasma workspaces, but i do not believe we have any hard requirements on it at this time ... so i'd love to see people using Qt 4.8, but we can keep a minimum 4.8 requirement for the time being. You meant but we can keep a minimum 4.7 requirement for the time being.? Asking because otherwise i don't understand the but in the sentence Albert my only concern is that our team works with Qt 4.8 right now, most of our users will likely get Qt 4.8 with SC 4.9 packages and so our code will be well tested with Qt 4.8 and Qt 4.7 will not be as well tested. i don't think there is much we can do about that though, unless a magic QA fairy passes by dropping testers. :)
