Re: Review Request 119940: Use style primitive to render custom tooltip rather than custom code

[Hugo Pereira Da Costa]

> On Aug. 26, 2014, 2:21 p.m., Aleix Pol Gonzalez wrote:
> > +1 looks good to me.
> > 
> > Maybe a before/after screenshot would help in these reviews.
> 
> Hugo Pereira Da Costa wrote:
> sorry. Will add
> (being lazy)
> 
> Ben Cooksley wrote:
> You may wish to examine System Settings, it has very similar code as well 
> (If I recall correctly, the tooltip rendering code was copied between them - 
> and originally came from Dolphin).

Hi Ben, 
it appears systemsetting's tooltips painting was already fixed a while ago 
(just double checked)
no artifact, stylePainter is already used there (and so is the case for dolphin)
Btw: I wonder if this tooltip widget/manager would be a good candidate for 
kwidgetsaddons, so that applications would not have to duplicate the code
(what you actually put in the tooltips contents being still the responsibility 
of the application)


- Hugo


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


On Aug. 26, 2014, 2:43 p.m., Hugo Pereira Da Costa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119940/
> ---
> 
> (Updated Aug. 26, 2014, 2:43 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kinfocenter
> 
> 
> Description
> ---
> 
> as title says
> the current custom code was made to match oxygen, and does not fit breeze any 
> more.
> You end up with artifacts, incorrect rounding, wrong shadow etc.
> also the current code is much simpler and works with all other themes too
> 
> 
> Diffs
> -
> 
>   ToolTips/ktooltipwindow.cpp 0ef540c 
>   ToolTips/ktooltipwindow_p.h a9ac30f 
> 
> Diff: https://git.reviewboard.kde.org/r/119940/diff/
> 
> 
> Testing
> ---
> 
> with oxygen, fusion, breeze
> 
> 
> File Attachments
> 
> 
> kinfocenter-before.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/08/26/344a7dab-0dce-4a80-915b-8fccbd1b9f16__kinfocenter-before.png
> kinfocenter-after.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/08/26/dc2d618e-077f-4f49-ba02-11420927a068__kinfocenter-after.png
> 
> 
> Thanks,
> 
> Hugo Pereira Da Costa
> 
>

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

Re: OSX/CI: libkdxraw fails to build on branch frameworks

[Marko Käning]

Hi Aleix,

On 26 Aug 2014, at 12:18 , Aleix Pol  wrote:
> libkdcraw is not a KDE Framework anyway, you probably want to tell the 
> Digikam mailing lists.

hmmm, I just verified again that it has a frameworks branch.

OK, so a frameworks branch alone doesn't mean that a project is already 
frameworkified, I understand. :)

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

Re: OSX/CI: libkdxraw fails to build on branch frameworks

[Aleix Pol]

On Wed, Aug 27, 2014 at 10:48 AM, Marko Käning  wrote:

> Hi Aleix,
>
> On 26 Aug 2014, at 12:18 , Aleix Pol  wrote:
> > libkdcraw is not a KDE Framework anyway, you probably want to tell the
> Digikam mailing lists.
>
> hmmm, I just verified again that it has a frameworks branch.
>
> OK, so a frameworks branch alone doesn't mean that a project is already
> frameworkified, I understand. :)
>
> Greets,
> Marko
>

I insist, there's no harm in asking them:
https://mail.kde.org/mailman/listinfo/digikam-devel

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

Re: Review Request 119895: New class for 5.2 to help user to migrate config files and ui file to new standardpath

[Laurent Montel]

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


So what do I do ?

- Laurent Montel


On août 22, 2014, 10:55 matin, Laurent Montel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119895/
> ---
> 
> (Updated août 22, 2014, 10:55 matin)
> 
> 
> Review request for KDE Frameworks, David Faure and Kevin Krammer.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Class helps user to migrate config file and ui file to new location
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 75d1293 
>   autotests/data/appui1rc PRE-CREATION 
>   autotests/data/appuirc PRE-CREATION 
>   autotests/data/foo1rc PRE-CREATION 
>   autotests/data/foorc PRE-CREATION 
>   autotests/kdelibs4configmigratortest.cpp PRE-CREATION 
>   src/lib/CMakeLists.txt 26eb5a1 
>   src/lib/util/kdelibs4configmigrator.h PRE-CREATION 
>   src/lib/util/kdelibs4configmigrator.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119895/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Laurent Montel
> 
>

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

Re: OSX/CI: libkdxraw fails to build on branch frameworks

[David Edmundson]

It's known it's not finished being ported.

I started porting this, as I needed it for Gwenview.

I got stuck on the Threadweaver porting, so at the time just made it
an optional dependency in Gwenview instead.

It's on my TODO list, though feel free to help out.

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

Re: Review Request 119895: New class for 5.2 to help user to migrate config files and ui file to new standardpath

[Kevin Krammer]

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

Ship it!


Ship It!

- Kevin Krammer


On Aug. 22, 2014, 10:55 vorm., Laurent Montel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119895/
> ---
> 
> (Updated Aug. 22, 2014, 10:55 vorm.)
> 
> 
> Review request for KDE Frameworks, David Faure and Kevin Krammer.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Class helps user to migrate config file and ui file to new location
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 75d1293 
>   autotests/data/appui1rc PRE-CREATION 
>   autotests/data/appuirc PRE-CREATION 
>   autotests/data/foo1rc PRE-CREATION 
>   autotests/data/foorc PRE-CREATION 
>   autotests/kdelibs4configmigratortest.cpp PRE-CREATION 
>   src/lib/CMakeLists.txt 26eb5a1 
>   src/lib/util/kdelibs4configmigrator.h PRE-CREATION 
>   src/lib/util/kdelibs4configmigrator.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119895/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Laurent Montel
> 
>

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

Re: Review Request 119895: New class for 5.2 to help user to migrate config files and ui file to new standardpath

[Laurent Montel]

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

(Updated Aug. 27, 2014, 12:42 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, David Faure and Kevin Krammer.


Repository: kcoreaddons


Description
---

Class helps user to migrate config file and ui file to new location


Diffs
-

  autotests/CMakeLists.txt 75d1293 
  autotests/data/appui1rc PRE-CREATION 
  autotests/data/appuirc PRE-CREATION 
  autotests/data/foo1rc PRE-CREATION 
  autotests/data/foorc PRE-CREATION 
  autotests/kdelibs4configmigratortest.cpp PRE-CREATION 
  src/lib/CMakeLists.txt 26eb5a1 
  src/lib/util/kdelibs4configmigrator.h PRE-CREATION 
  src/lib/util/kdelibs4configmigrator.cpp PRE-CREATION 

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


Testing
---


Thanks,

Laurent Montel

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

Re: Review Request 119901: Fix ECM to use qmake instead of hardcoding plugin install dirs

[Rohan Garg]

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

(Updated Aug. 27, 2014, 6:41 p.m.)


Review request for Build System and KDE Frameworks.


Changes
---

I've changed the name to KDE_ECM_INSTALL_TO_QT_SYS_DIR , which is what makes 
sense to me. And incorporated the fixes Aleix mentioned.


Repository: extra-cmake-modules


Description
---

Use qmake to query dirs for plugins and imports instead of hardcoding them in 
ECM.


Diffs (updated)
-

  modules/ECMQueryQmake.cmake PRE-CREATION 
  kde-modules/KDEInstallDirs.cmake 880539b 
  modules/ECMGeneratePriFile.cmake 34001d6 

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


Testing
---

Seems to work on my system.


Thanks,

Rohan Garg

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

Re: OSX/CI: libkdxraw fails to build on branch frameworks

[Marko Käning]

Hi David,

On 27 Aug 2014, at 12:53 , David Edmundson  wrote:
> It's known it's not finished being ported.

Not to me.
Where would I find a place with information about the porting state of the 
various KDE libs?
I know there is one for kdeedu, which Aleix pointed out to me a while ago [1].
Something like that for all KDE libs would be nice to have...

> It's on my TODO list, though feel free to help out.

Sorry, I was just testing whether it would build and install on the OSX/CI 
system. :)

Greets,
Marko


[1] https://community.kde.org/KDEEdu/RouteToKF5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 119901: Fix ECM to use qmake instead of hardcoding plugin install dirs

[Alex Merry]

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


Nice! See my comments below, though.


kde-modules/KDEInstallDirs.cmake


Remove this TODO, since you've done it.



kde-modules/KDEInstallDirs.cmake


Move the include to inside the if(KDE_ECM_INSTALL_TO_QT_SYS_DIR), so that 
it doesn't try to find qmake if it's not set.



kde-modules/KDEInstallDirs.cmake


I don't think you need both KDE and ECM there. KDE alone is sufficient - 
that is the prefix of the module name, after all. It ends up a bit odd in the 
ECMGeneratePriFile module, but I don't like the fact we set an install variable 
in there anyway.

Actually, I would call it KDE_INSTALL_USE_QT_SYS_PATHS.



modules/ECMGeneratePriFile.cmake


Similarly, this should be inside the conditional.



modules/ECMQueryQmake.cmake


I think we need to be a bit more clever here. I'd go for a cache variable, 
and if (TARGET Qt5::qmake), set the default to that, otherwise set the default 
to just "qmake".



modules/ECMQueryQmake.cmake


CMake macros/functions that take a variable name usually take it first. 
Swapping the argument order would make it more consistent with other things.


- Alex Merry


On Aug. 27, 2014, 1:11 p.m., Rohan Garg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119901/
> ---
> 
> (Updated Aug. 27, 2014, 1:11 p.m.)
> 
> 
> Review request for Build System and KDE Frameworks.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Use qmake to query dirs for plugins and imports instead of hardcoding them in 
> ECM.
> 
> 
> Diffs
> -
> 
>   modules/ECMQueryQmake.cmake PRE-CREATION 
>   kde-modules/KDEInstallDirs.cmake 880539b 
>   modules/ECMGeneratePriFile.cmake 34001d6 
> 
> Diff: https://git.reviewboard.kde.org/r/119901/diff/
> 
> 
> Testing
> ---
> 
> Seems to work on my system.
> 
> 
> Thanks,
> 
> Rohan Garg
> 
>

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

Review Request 119958: Fix thumbnails for mimetype groups.

[Maarten De Meyer]

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

Review request for KDE Frameworks.


Repository: kio


Description
---

Fix a regression in PreviewJob. This one was hard to find :)

KService::mimeTypes cannot handle mimetype groups. ex: text/*
Use KService::serviceTypes instead and ignore the first item which is
always type 'ThumbCreator'

This is the quick and easy solution. I could also add support for mimetype 
groups to KService::mimeTypes. (so that it return all mimetypes in a group) Not 
sure what the best solution is. Are groups only used in thumbnailer files?


Diffs
-

  src/widgets/previewjob.cpp 55a3fb7 

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


Testing
---

I'm porting a thumbnailer to frameworks 5. Before nothing happend, now I see 
thumbnails.


Thanks,

Maarten De Meyer

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

Re: split kdepimlibs

[John Layt]

My general 2c: I'm with Kevin that we should do functional and api
reviews, move code around, and generally refactor stuff *before* we
split anything. It's just plain easier that way. I don't think we're
anywhere near close to knowing what to do with everything to be
splitting things yet.  Will we also end up with deprecated code in a
kdepimlibs4-support, for example?

We started a page at
https://community.kde.org/Frameworks/Epics/kdepimlibs to document this
sort of stuff, it would be good to bring it up-to-date and work
through it progressively.

We also have Akademy and the sprint scheduled for November (?) at
which we could sit down and methodically work through the list of
everything and figure out what to do.

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

Re: split kdepimlibs

[John Layt]

On 26 August 2014 11:41, Jonathan Riddell  wrote:
>
> I'd like to suggest taking the opportunity to remove uses of the quite ugly 
> term PIM in favour of the friendlier Kontact.

I would say no. PIM in library names makes sense, especially as we
want that others outside KDE-PIM / Kontact will use the PIM Frameworks
. It's ugly, but recognised in the techie community.  And just as with
the other Frameworks, any gui strings need to be neutral as well.

Now, KDE-PIM itself is another issue...

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

Re: OSX/CI: libkdxraw fails to build on branch frameworks

[Albert Astals Cid]

El Dimecres, 27 d'agost de 2014, a les 19:56:17, Marko Käning va escriure:
> Hi David,
> 
> On 27 Aug 2014, at 12:53 , David Edmundson  
wrote:
> > It's known it's not finished being ported.
> 
> Not to me.

As I already said, I don't think it's worth for you building things that don't 
have Linux CI [unless you can work on fixing them, but I think you said it was 
not part of your skills].

> Where would I find a place with information about the porting state of the
> various KDE libs? 

There's 
https://community.kde.org/Frameworks/Application-release-status-December-2014

Which is not complete but it's what we have.

Cheers,
  Albert


> I know there is one for kdeedu, which Aleix pointed out
> to me a while ago [1]. Something like that for all KDE libs would be nice
> to have...
> 
> > It's on my TODO list, though feel free to help out.
> 
> Sorry, I was just testing whether it would build and install on the OSX/CI
> system. :)
> 
> Greets,
> Marko
> 
> 
> [1] https://community.kde.org/KDEEdu/RouteToKF5
> ___
> 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: libkdxraw fails to build on branch frameworks

[Marko Käning]

Hi Albert, Ben and Aleix,

On 27 Aug 2014, at 22:19 , Albert Astals Cid  wrote:
> As I already said, I don't think it's worth for you building things that 
> don't 
> have Linux CI [unless you can work on fixing them, but I think you said it 
> was 
> not part of your skills].

hmmm, okay. Well, I’ll try do so from now on. ;)


But you see, some were actually worth at least trying, since it went fine lately
for e.g.

  - kig
  - kstars
  - kqtquickcharts

which have no *_frameworks_qt5 on Linux/CI either up to now, but could be built
fine on OSX/CI already (same was true for konversation, kanagram and parley a
while ago).


Ben, could you add the above 3 projects to Linux/CI?



> https://community.kde.org/Frameworks/Application-release-status-December-2014

OK, that’s a rather short list, indeed. :)

I think the kde-edu route [1] needs some updates as well, since the projects

 - libkdeedu
 - libkeduvocdocument
 - analitza
 - kalgebra
 - step
 - kgeography
 - kig
 - kanagram
 - parley
 - kstars
 - kqtquickcharts
 - marble

can be build successfully by now for qt5, even on OSX/CI!

Greets,
Marko




[1] https://community.kde.org/KDEEdu/RouteToKF5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kio_trash

[Kevin Funk]

On Sunday 17 August 2014 00:03:41 David Faure wrote:
> kio_trash is currently in kde-workspace/kio-extras, but KIO actually offers
> API that depends on kio_trash (KIO::trash(), JobUiDelegateExtension::Trash,
> support for trash in FileUndoManager, and I'm about to add a
> KIO::restoreFromTrash job).
> And KIO::trash is called from the file dialog (kdiroperator.cpp).
> So this is a missing runtime dependency if kde-workspace/kio-extras isn't
> installed.
> 
> How about we move kio_trash to the kio framework?
> 
> (If we agree, can someone do it? I still have no experience with doing this
> in a way that preserves the git history)

I guess that'd also fix my CI-related issue here [1], right:

QWARN  : GitInitTest::testRemoveEmptyFolder() couldn't create slave: "Unable 
to create io-slave:
klauncher said: Unknown protocol 'trash'.
"

(We're using KIO::trash, but the CI doesn't provide this particular slave 
because it's part of different module)

Greets

[1] 
http://build.kde.org/view/kdevelop/job/kdevplatform_frameworks_qt5/154/testReport/(root)/TestSuite/test_kdevgit/

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: split kdepimlibs

[laurent Montel]

Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit :
> > kpimidentities
> 
> Maybe deserves a better name? kidentitymanagement?

Done.

> > kpimtextedit
> 
> I suspect it could get a better name, but couldn't decide yet. :-)
> Also I wonder if some of it could/should go in ktexteditor? But I don't know
> the respective feature sets enough to be sure.
> 
> > kpimutils
> 
> Looks like another dumping ground of random classes. Each class should
> likely find a new home.

I started to remove some duplicate function and start to move in other modules

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