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

[Ben Cooksley]

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

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


- Ben


---
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: Review Request 119942: give the applet alternatives QML file an entry

[Aaron J. Seigo]

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

(Updated Aug. 26, 2014, 7:44 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

Give the applet alternatives QML file an entry; this adds to the 
self-documenting nature of the package and prevents paths from creeping into 
usage points. This is a starting point in the package, so it should have a well 
known name.


Diffs
-

  src/plasma/private/packages.cpp 585ab1f272d48f9b998c64968beeccf0f6dd979f 

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


Testing
---

Loaded plasmashell and the alternatives UI.


Thanks,

Aaron J. Seigo

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

Re: Review Request 119942: give the applet alternatives QML file an entry

[Aaron J. Seigo]

> On Aug. 26, 2014, 5:40 p.m., Marco Martin wrote:
> > src/plasma/private/packages.cpp, line 278
> > 
> >
> > maybe going even more explicit and giving its own subdicrectory too? 
> > (i'm fine with either)

A subdirectory for one item is probably overkill, and it does make sense there 
imho as it is with the other applet explorer bits. The name "explorer" is 
perhaps a bit unfortunate, but it is not so bad as to warrant changing it. This 
does all need documenting, however.


- Aaron J.


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


On Aug. 26, 2014, 5:25 p.m., Aaron J. Seigo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119942/
> ---
> 
> (Updated Aug. 26, 2014, 5:25 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Give the applet alternatives QML file an entry; this adds to the 
> self-documenting nature of the package and prevents paths from creeping into 
> usage points. This is a starting point in the package, so it should have a 
> well known name.
> 
> 
> Diffs
> -
> 
>   src/plasma/private/packages.cpp 585ab1f272d48f9b998c64968beeccf0f6dd979f 
> 
> Diff: https://git.reviewboard.kde.org/r/119942/diff/
> 
> 
> Testing
> ---
> 
> Loaded plasmashell and the alternatives UI.
> 
> 
> Thanks,
> 
> Aaron J. Seigo
> 
>

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

Re: Review Request 119947: Re-enable build of SVG thumbnailer

[Hrvoje Senjan]

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

(Updated Aug. 26, 2014, 7:20 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Repository: kio-extras


Description
---

turns out just uncommenting and adjusting link target is enough...


Diffs
-

  CMakeLists.txt 542d566 
  thumbnail/CMakeLists.txt c508be2 

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


Testing
---

builds, thumbnails for svg's shown in Dolphin


Thanks,

Hrvoje Senjan

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

Re: split kdepimlibs

[Kevin Ottens]

Hello,

On Tuesday 26 August 2014 18:25:01 Daniel Vratil wrote:
> I definitely want to have the Server and the client libraries in one repo,
> shipped as a complete solution for PIM storage with the server being just
> part of the solution, not a standalone one.

Excellent. Definitely what I'd like to see happen.

> My original idea was that we would just merge the client libs into the
> existing akonadi.git repo, but setting up new akonadi-framework.git works
> just fine with me (and akonadi.git end up like kdelibs.git)

If we could keep the akonadi repository that would be nice. I'm not too fond 
of the "-framework" suffix in the repository name.

> About the type-specific (-abc, -calendar, ...) frameworks: maybe there could
> be something like Akonadi Framework Extras, and Akonadi Framework would
> really only be the server and the base client libs? What do you think?

Makes sense. An akonadi-extras is a possibility.
 
Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

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


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

Re: Review Request 119947: Re-enable build of SVG thumbnailer

[David Edmundson]

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

Ship it!


Ship It!

- David Edmundson


On Aug. 26, 2014, 6:40 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119947/
> ---
> 
> (Updated Aug. 26, 2014, 6:40 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> turns out just uncommenting and adjusting link target is enough...
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 542d566 
>   thumbnail/CMakeLists.txt c508be2 
> 
> Diff: https://git.reviewboard.kde.org/r/119947/diff/
> 
> 
> Testing
> ---
> 
> builds, thumbnails for svg's shown in Dolphin
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

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

Review Request 119947: Re-enable build of SVG thumbnailer

[Hrvoje Senjan]

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

Review request for KDE Frameworks and Plasma.


Repository: kio-extras


Description
---

turns out just uncommenting and adjusting link target is enough...


Diffs
-

  CMakeLists.txt 542d566 
  thumbnail/CMakeLists.txt c508be2 

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


Testing
---

builds, thumbnails for svg's shown in Dolphin


Thanks,

Hrvoje Senjan

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

Re: split kdepimlibs

[Daniel Vratil]

On Tuesday 26 of August 2014 19:02:49 laurent Montel wrote:
> Le mardi 26 août 2014 18:25:01 Daniel Vratil a écrit :
> > On Tuesday 26 of August 2014 12:32:48 laurent Montel wrote:
> > > Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit :
> > > > On Tuesday 26 August 2014 11:20:25 laurent Montel wrote:
> > > > > Hi,
> > > > > I will split kdepimlibs as it
> > > > > 
> > > > > akonadi (need to find another name because it's still used)
> > > > > akonadi-abc
> > > > > akonadi-calendar
> > > > > akonadi-contact
> > > > > akonadi-mime
> > > > > akonadi-notes
> > > > > akonadi-socialutils
> > > > 
> > > > To me it sounds like some of those things could be regrouped now. What
> > > > about also bringing the akonadi server on board? Having a bigger
> > > > akonadi
> > > > framework containing server (right now in kdesupport), some access
> > > > libs
> > > > and a few default plugins would make sense (it looks like a KIO like
> > > > framework).
> > > 
> > > Regroup as a framework as :
> > > akonadi-framework (better name)
> > > 
> > >  -> src
> > >  
> > >  -> akonadi-abc
> > >  -> akonadi-calendar
> > >  -> akonadi-contact
> > >  -> akonadi-mime
> > >  -> akonadi-notes
> > >  -> akonadi-socialutils
> > >  -> server (Dan must speak about it if he wants to move here)
> > >  -> plugins serializer (moved from kdepim-runtime)
> > 
> > Hi,
> > 
> > I definitely want to have the Server and the client libraries in one repo,
> > shipped as a complete solution for PIM storage with the server being just
> > part of the solution, not a standalone one. My original idea was that we
> > would just merge the client libs into the existing akonadi.git repo, but
> > setting up new akonadi-framework.git works just fine with me (and
> > akonadi.git end up like kdelibs.git)
> 
> seems good for me
> 
> And we move serialize plugin from kdepim-runtime to this framework no ?

The plugins usually depend on the type-specific classes, so they would have to 
go to the "Extras" too.

> > About the type-specific (-abc, -calendar, ...) frameworks: maybe there
> > could be something like Akonadi Framework Extras, and Akonadi Framework
> > would really only be the server and the base client libs? What do you
> > think?
> I like it
> 
> > Dan

-- 
Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

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

Re: Review Request 119942: give the applet alternatives QML file an entry

[Marco Martin]

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

Ship it!



src/plasma/private/packages.cpp


maybe going even more explicit and giving its own subdicrectory too? (i'm 
fine with either)


- Marco Martin


On Aug. 26, 2014, 5:25 p.m., Aaron J. Seigo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119942/
> ---
> 
> (Updated Aug. 26, 2014, 5:25 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Give the applet alternatives QML file an entry; this adds to the 
> self-documenting nature of the package and prevents paths from creeping into 
> usage points. This is a starting point in the package, so it should have a 
> well known name.
> 
> 
> Diffs
> -
> 
>   src/plasma/private/packages.cpp 585ab1f272d48f9b998c64968beeccf0f6dd979f 
> 
> Diff: https://git.reviewboard.kde.org/r/119942/diff/
> 
> 
> Testing
> ---
> 
> Loaded plasmashell and the alternatives UI.
> 
> 
> Thanks,
> 
> Aaron J. Seigo
> 
>

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

Re: circular dependencies?

[Michael Pyne]

On Mon, August 25, 2014 22:26:50 Marko Käning wrote:
> Hi,
> 
> I just see (on the OSX/CI system) using e.g.
> 
> ---
> $ cd ~/scripts/dependencies/tools
> $ list_dependencies frameworks/kauth
> desupport/extra-cmake-modules
> Qt5[stable]
> frameworks/kcoreaddons
> frameworks/kauth
> ---
> 
> that all frameworks depend on themselves.
> 
> Is that intended, just an artifact or a bug?

Artifact, it's listing modules in a proper build order (not simply a "list of 
deps"), but you're right: it should not list the last module since this is 
supposed to be a dependency listing.

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

Review Request 119942: give the applet alternatives QML file an entry

[Aaron J. Seigo]

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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

Give the applet alternatives QML file an entry; this adds to the 
self-documenting nature of the package and prevents paths from creeping into 
usage points. This is a starting point in the package, so it should have a well 
known name.


Diffs
-

  src/plasma/private/packages.cpp 585ab1f272d48f9b998c64968beeccf0f6dd979f 

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


Testing
---

Loaded plasmashell and the alternatives UI.


Thanks,

Aaron J. Seigo

___
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 18:25:01 Daniel Vratil a écrit :
> On Tuesday 26 of August 2014 12:32:48 laurent Montel wrote:
> > Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit :
> > > On Tuesday 26 August 2014 11:20:25 laurent Montel wrote:
> > > > Hi,
> > > > I will split kdepimlibs as it
> > > > 
> > > > akonadi (need to find another name because it's still used)
> > > > akonadi-abc
> > > > akonadi-calendar
> > > > akonadi-contact
> > > > akonadi-mime
> > > > akonadi-notes
> > > > akonadi-socialutils
> > > 
> > > To me it sounds like some of those things could be regrouped now. What
> > > about also bringing the akonadi server on board? Having a bigger akonadi
> > > framework containing server (right now in kdesupport), some access libs
> > > and a few default plugins would make sense (it looks like a KIO like
> > > framework).
> > 
> > Regroup as a framework as :
> > akonadi-framework (better name)
> > 
> >  -> src
> >  
> >  -> akonadi-abc
> >  -> akonadi-calendar
> >  -> akonadi-contact
> >  -> akonadi-mime
> >  -> akonadi-notes
> >  -> akonadi-socialutils
> >  -> server (Dan must speak about it if he wants to move here)
> >  -> plugins serializer (moved from kdepim-runtime)
> 
> Hi,
> 
> I definitely want to have the Server and the client libraries in one repo,
> shipped as a complete solution for PIM storage with the server being just
> part of the solution, not a standalone one. My original idea was that we
> would just merge the client libs into the existing akonadi.git repo, but
> setting up new akonadi-framework.git works just fine with me (and
> akonadi.git end up like kdelibs.git)

seems good for me 

And we move serialize plugin from kdepim-runtime to this framework no ?

> 
> About the type-specific (-abc, -calendar, ...) frameworks: maybe there could
> be something like Akonadi Framework Extras, and Akonadi Framework would
> really only be the server and the base client libs? What do you think?

I like it



> 
> Dan

___
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 17:24:24 Kevin Krammer a écrit :
> Looks like you forgot to add the KDE PIM list :-)
> 
> On Tuesday, 2014-08-26, 11:20:25, laurent Montel wrote:
> > Hi,
> > I will split kdepimlibs as it
> > 
> > akonadi (need to find another name because it's still used)
> > akonadi-abc
> 
> Is that akonadi/kabc?

yes it's akonadi-kabc.


> 
> > akonadi-calendar
> > akonadi-contact
> > akonadi-mime
> > akonadi-notes
> > akonadi-socialutils
> > gpgme++
> > kabc
> > kalarmcal
> > kblog
> > kcalcore
> > kcalutils
> > kholidays
> > kimap
> > kioslave
> > kldap
> > kmbox
> > kmime
> > kontactinterface
> > kpimidentities
> > kpimtextedit
> > kpimutils
> > ktnef
> > kxmlrpcclient
> > mailtransport
> > microblog
> > qgpgme
> > syndication
> 
> Cheers,
> Kevin

-- 
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: split kdepimlibs

[laurent Montel]

Le mardi 26 août 2014 17:29:46 Kevin Krammer a écrit :

> > kioslave indeed not a framework. I think that just pop3 is used by kdepim
> > 
> > yes others can move to kio-extra
> 
> Is the Akonadi IO slave in there as well?

Akonadi io slave is from kdepim-runtime but can be moved to kio-extra too not 
a problem fo me.

> Cheers,
> Kevin

-- 
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: split kdepimlibs

[Daniel Vratil]

On Tuesday 26 of August 2014 17:24:24 Kevin Krammer wrote:
> Looks like you forgot to add the KDE PIM list :-)
> 
> On Tuesday, 2014-08-26, 11:20:25, laurent Montel wrote:
> > Hi,
> > I will split kdepimlibs as it
> > 
> > akonadi (need to find another name because it's still used)
> > akonadi-abc
> 
> Is that akonadi/kabc?

Yep - the massive framework with two files that contain two strings in total! 
I think this "framework" should die and the files moved to akonadi-contact.

Or even better, we could just drop it - the only use in entire PIM stack I 
found is in the contactgroup serializer plugin - and it's only including the 
header file and not even actually using the strings defined there - seems 
kinda useless to me :-)

Dan

> 
> > akonadi-calendar
> > akonadi-contact
> > akonadi-mime
> > akonadi-notes
> > akonadi-socialutils
> > gpgme++
> > kabc
> > kalarmcal
> > kblog
> > kcalcore
> > kcalutils
> > kholidays
> > kimap
> > kioslave
> > kldap
> > kmbox
> > kmime
> > kontactinterface
> > kpimidentities
> > kpimtextedit
> > kpimutils
> > ktnef
> > kxmlrpcclient
> > mailtransport
> > microblog
> > qgpgme
> > syndication
> 
> Cheers,
> Kevin

-- 
Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

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

Re: split kdepimlibs

[Daniel Vratil]

On Tuesday 26 of August 2014 17:29:46 Kevin Krammer wrote:
> On Tuesday, 2014-08-26, 12:32:48, laurent Montel wrote:
> > Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit :
> > > On Tuesday 26 August 2014 11:20:25 laurent Montel wrote:
> > > > Hi,
> > > > I will split kdepimlibs as it
> > > > 
> > > > akonadi (need to find another name because it's still used)
> > > > akonadi-abc
> > > > akonadi-calendar
> > > > akonadi-contact
> > > > akonadi-mime
> > > > akonadi-notes
> > > > akonadi-socialutils
> > > 
> > > To me it sounds like some of those things could be regrouped now. What
> > > about also bringing the akonadi server on board? Having a bigger akonadi
> > > framework containing server (right now in kdesupport), some access libs
> > > and a few default plugins would make sense (it looks like a KIO like
> > > framework).
> > 
> > Regroup as a framework as :
> > akonadi-framework (better name)
> > 
> >  -> src
> >  
> >  -> akonadi-abc
> >  -> akonadi-calendar
> >  -> akonadi-contact
> >  -> akonadi-mime
> >  -> akonadi-notes
> >  -> akonadi-socialutils
> >  -> server (Dan must speak about it if he wants to move here)
> >  -> plugins serializer (moved from kdepim-runtime)
> 
> We have to assume that frameworks will end up in single package
> dependencies, so it would be nice to have Akonadi server separate so it
> remains installable on its own.

Ee, the server goes in :-) It will still be installable standalone of course, 
the only difference is that what is now libakonadiprotocolinternals.so would 
be libKF5AkonadiPrivate.so.

> 
> One thing that should probably be considered is that the current libs mix
> non- UI and UI stuff, so some separation in between these lines might still
> be something to strive for.

The Akonadi framework itself is already split into multiple libraries:

libKF5AkonadiCore - non-gui stuff
libKF5AkonadiAgentBase - agents/resources-related stuff (non-gui)
libKF5AkonadiWidgets - gui
(and some more, not important)

I think all the type-specific libraries (-abc, -calendar, ...) would all 
depend on the Widgets library anyway and the amount of non-gui stuff is rather 
limited *


* I haven't actually checked, sorry ;)

> 
> > > > gpgme++
> > > > kabc
> > > > kalarmcal
> > > > kblog
> > > > kcalcore
> > > > kcalutils
> > > 
> > > This one looks like a dumping ground of random things. Maybe some of it
> > > should move in other frameworks?
> > 
> > Sergio can speak about it
> > 
> > > > kholidays
> > > > kimap
> > > > kioslave
> > > 
> > > Definitely not a framework. Are all the ioslaves in there still used? I
> > > think at least some of them can be let go. The others could go in
> > > kio-extras I guess.
> > 
> > kioslave indeed not a framework. I think that just pop3 is used by kdepim
> > 
> > yes others can move to kio-extra
> 
> Is the Akonadi IO slave in there as well?
> 
> Cheers,
> Kevin

-- 
Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

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

Re: split kdepimlibs

[Daniel Vratil]

On Tuesday 26 of August 2014 12:32:48 laurent Montel wrote:
> Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit :
> > On Tuesday 26 August 2014 11:20:25 laurent Montel wrote:
> > > Hi,
> > > I will split kdepimlibs as it
> > > 
> > > akonadi (need to find another name because it's still used)
> > > akonadi-abc
> > > akonadi-calendar
> > > akonadi-contact
> > > akonadi-mime
> > > akonadi-notes
> > > akonadi-socialutils
> > 
> > To me it sounds like some of those things could be regrouped now. What
> > about also bringing the akonadi server on board? Having a bigger akonadi
> > framework containing server (right now in kdesupport), some access libs
> > and a few default plugins would make sense (it looks like a KIO like
> > framework).
> 
> Regroup as a framework as :
> akonadi-framework (better name)
>  -> src
>  -> akonadi-abc
>  -> akonadi-calendar
>  -> akonadi-contact
>  -> akonadi-mime
>  -> akonadi-notes
>  -> akonadi-socialutils
>  -> server (Dan must speak about it if he wants to move here)
>  -> plugins serializer (moved from kdepim-runtime)

Hi,

I definitely want to have the Server and the client libraries in one repo, 
shipped as a complete solution for PIM storage with the server being just part 
of the solution, not a standalone one. My original idea was that we would just 
merge the client libs into the existing akonadi.git repo, but setting up new 
akonadi-framework.git works just fine with me (and akonadi.git end up like 
kdelibs.git)

About the type-specific (-abc, -calendar, ...) frameworks: maybe there could 
be something like Akonadi Framework Extras, and Akonadi Framework would really 
only be the server and the base client libs? What do you think?


Dan


> 
> > > gpgme++
> > > kabc
> > > kalarmcal
> > > kblog
> > > kcalcore
> > > kcalutils
> > 
> > This one looks like a dumping ground of random things. Maybe some of it
> > should move in other frameworks?
> 
> Sergio can speak about it
> 
> > > kholidays
> > > kimap
> > > kioslave
> > 
> > Definitely not a framework. Are all the ioslaves in there still used? I
> > think at least some of them can be let go. The others could go in
> > kio-extras I guess.
> 
> kioslave indeed not a framework. I think that just pop3 is used by kdepim
> 
> yes others can move to kio-extra
> 
> > > kldap
> > > kmbox
> > > kmime
> > > kontactinterface
> > 
> > Probably should go in kdepim or kontact itself. Similarly the content of
> > the kdelibs/interfaces folder moved out of KF5.
> 
> We extracted it in 4.x to allow to create kontact plugins for other
> application.
> If we merge in kdepim we will not able to do it.
> 
> > > kpimidentities
> > 
> > Maybe deserves a better name? kidentitymanagement?
> 
> Ok seems better. I will work to rename it.
> 
> > > 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.
> 
> For me it's kdepim specific.
> 
> > > kpimutils
> > 
> > Looks like another dumping ground of random classes. Each class should
> > likely find a new home.
> 
> Ok I will try to move them.
> 
> > > ktnef
> > > kxmlrpcclient
> > > mailtransport
> > > microblog
> > > qgpgme
> > 
> > Couldn't that be merged with gpgme++? This one already builds several
> > variants depending what it finds on the platform, why not treat the Qt
> > integration in the same way?
> 
> Really I never study this lib, there is not unittest, I don't know how it
> works and I don't know why there is several build.
> I will not work on.
> 
> > > syndication
> > > 
> > > is it ok for you ?
> > 
> > I tried to point out things which would be harder to address after the
> > split. So I think we should have discussions and decisions about the
> > points
> > above before being able to proceed.
> > 
> > Regards.

-- 
Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

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

Re: split kdepimlibs

[Kevin Krammer]

On Tuesday, 2014-08-26, 12:32:48, laurent Montel wrote:
> Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit :
> > On Tuesday 26 August 2014 11:20:25 laurent Montel wrote:
> > > Hi,
> > > I will split kdepimlibs as it
> > > 
> > > akonadi (need to find another name because it's still used)
> > > akonadi-abc
> > > akonadi-calendar
> > > akonadi-contact
> > > akonadi-mime
> > > akonadi-notes
> > > akonadi-socialutils
> > 
> > To me it sounds like some of those things could be regrouped now. What
> > about also bringing the akonadi server on board? Having a bigger akonadi
> > framework containing server (right now in kdesupport), some access libs
> > and a few default plugins would make sense (it looks like a KIO like
> > framework).
> 
> Regroup as a framework as :
> akonadi-framework (better name)
>  -> src
>  -> akonadi-abc
>  -> akonadi-calendar
>  -> akonadi-contact
>  -> akonadi-mime
>  -> akonadi-notes
>  -> akonadi-socialutils
>  -> server (Dan must speak about it if he wants to move here)
>  -> plugins serializer (moved from kdepim-runtime)

We have to assume that frameworks will end up in single package dependencies, 
so it would be nice to have Akonadi server separate so it remains installable 
on its own.

One thing that should probably be considered is that the current libs mix non-
UI and UI stuff, so some separation in between these lines might still be 
something to strive for.

> > > gpgme++
> > > kabc
> > > kalarmcal
> > > kblog
> > > kcalcore
> > > kcalutils
> > 
> > This one looks like a dumping ground of random things. Maybe some of it
> > should move in other frameworks?
> 
> Sergio can speak about it
> 
> > > kholidays
> > > kimap
> > > kioslave
> > 
> > Definitely not a framework. Are all the ioslaves in there still used? I
> > think at least some of them can be let go. The others could go in
> > kio-extras I guess.
> 
> kioslave indeed not a framework. I think that just pop3 is used by kdepim
> 
> yes others can move to kio-extra

Is the Akonadi IO slave in there as well?

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


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

Re: split kdepimlibs

[Kevin Krammer]

Looks like you forgot to add the KDE PIM list :-)

On Tuesday, 2014-08-26, 11:20:25, laurent Montel wrote:
> Hi,
> I will split kdepimlibs as it
> 
> akonadi (need to find another name because it's still used)
> akonadi-abc

Is that akonadi/kabc?

> akonadi-calendar
> akonadi-contact
> akonadi-mime
> akonadi-notes
> akonadi-socialutils
> gpgme++
> kabc
> kalarmcal
> kblog
> kcalcore
> kcalutils
> kholidays
> kimap
> kioslave
> kldap
> kmbox
> kmime
> kontactinterface
> kpimidentities
> kpimtextedit
> kpimutils
> ktnef
> kxmlrpcclient
> mailtransport
> microblog
> qgpgme
> syndication

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


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

Re: split kdepimlibs

[Kevin Ottens]

On Tuesday 26 August 2014 15:51:33 David Gil Oliva wrote:
> El 26/08/2014 15:49, "Vishesh Handa"  escribió:
> > On Tuesday, August 26, 2014 11:50:50 AM Kevin Ottens wrote:
> > > > gpgme++
> > > > kabc
> > > > kalarmcal
> > > > kblog
> > > > kcalcore
> > > > kcalutils
> > > 
> > > This one looks like a dumping ground of random things. Maybe some of it
> > > should  move in other frameworks?
> > 
> > KAbc definitely doesn't seem like a dumping ground. It's a valuable
> > library that is also used by kpeople. It seems like a good candidate for
> > an individual framework

Really ;-)

> I would say he refers to kcalutils. Am I wrong?

You're completely right. I didn't add any comments for the ones which looked 
fine.

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

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



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

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

[Hugo Pereira Da Costa]

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


Status
--

This change has been marked as submitted.


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: Review Request 119940: Use style primitive to render custom tooltip rather than custom code

[Hugo Pereira Da Costa]

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

(Updated Aug. 26, 2014, 2:38 p.m.)


Review request for KDE Frameworks.


Changes
---

added screenshots


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 (updated)


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

SIC in KIO master

[Harald Sitter]

alohas,

it would appear to me that a recent change in kio [1] was rather,
very, entirely source incompatible (one could argue binary but let's
not go there).

Say I had the following in my application using kio 5.0/1:

connect(copyjob, &CopyJob::aboutToCreate, this, &MyThing::onABoutToCreate);

my application would no longer compile with 5.2 :'(

Can we please revert and deprecate instead?

[1] 
https://projects.kde.org/projects/frameworks/kio/repository/revisions/5f79e84f41ffdacbfe63277ed4f0422549bdfa89

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

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.

sorry. Will add
(being lazy)


- Hugo


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


On Aug. 26, 2014, 2:14 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:14 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
> 
> 
> 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: Review Request 119940: Use style primitive to render custom tooltip rather than custom code

[Aleix Pol Gonzalez]

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

Ship it!


+1 looks good to me.

Maybe a before/after screenshot would help in these reviews.

- Aleix Pol Gonzalez


On Aug. 26, 2014, 2:14 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:14 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
> 
> 
> Thanks,
> 
> Hugo Pereira Da Costa
> 
>

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

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

[Hugo Pereira Da Costa]

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

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


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: split kdepimlibs

[Vishesh Handa]

On Tuesday, August 26, 2014 11:50:50 AM Kevin Ottens wrote:
> > gpgme++
> > kabc
> > kalarmcal
> > kblog
> > kcalcore
> > kcalutils
> 
> This one looks like a dumping ground of random things. Maybe some of it
> should  move in other frameworks?

KAbc definitely doesn't seem like a dumping ground. It's a valuable library 
that is also used by kpeople. It seems like a good candidate for an individual 
framework.

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

Re: split kdepimlibs

[David Gil Oliva]

El 26/08/2014 15:49, "Vishesh Handa"  escribió:
>
> On Tuesday, August 26, 2014 11:50:50 AM Kevin Ottens wrote:
> > > gpgme++
> > > kabc
> > > kalarmcal
> > > kblog
> > > kcalcore
> > > kcalutils
> >
> > This one looks like a dumping ground of random things. Maybe some of it
> > should  move in other frameworks?
>
> KAbc definitely doesn't seem like a dumping ground. It's a valuable
library
> that is also used by kpeople. It seems like a good candidate for an
individual
> framework

I would say he refers to kcalutils. Am I wrong?

Cheers

David Gil

>
> --
> Vishesh Handa
> ___
> 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]

On 26 Aug 2014, at 12:18 , Aleix Pol  wrote:
> Maybe it hasn't been ported yet?

I was jumping the gun again. :)
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 119798: Generating PkgConfig files from ECM

[Aleix Pol Gonzalez]

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

(Updated Aug. 26, 2014, 11:51 a.m.)


Review request for Build System, KDE Frameworks and Harald Sitter.


Changes
---

Added documentation and a unit test.


Repository: extra-cmake-modules


Description
---

So we decided we wanted those .pc files, so I created a small script that 
generates one, I haven't used pc in the past, so feedback is welcome.


Diffs (updated)
-

  modules/ECMGeneratePkgConfigFile.cmake PRE-CREATION 
  tests/CMakeLists.txt 65de038 
  tests/ECMGeneratePkgConfigFile/CMakeLists.txt PRE-CREATION 
  tests/ECMGeneratePkgConfigFile/KF5CoreAddons.pc PRE-CREATION 
  tests/ECMGeneratePkgConfigFile/run_test.cmake.config PRE-CREATION 

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


Testing
---

I added it in KCoreAddons, this is the patch:
diff --git src/lib/CMakeLists.txt src/lib/CMakeLists.txt
index 26eb5a1..3a07d1c 100644
--- src/lib/CMakeLists.txt
+++ src/lib/CMakeLists.txt
@@ -188,4 +188,6 @@ install(FILES
 
 include(ECMGeneratePriFile)
 ecm_generate_pri_file(BASE_NAME KCoreAddons LIB_NAME KF5CoreAddons DEPS "core" 
FILENAME_VAR PRI_FILENAME INCLUDE_INSTALL_DIR 
${KF5_INCLUDE_INSTALL_DIR}/KCoreAddons)
+ecm_generate_pkgconfig_file(BASE_NAME KCoreAddons LIB_NAME KF5CoreAddons DEPS 
Qt5Core INCLUDE_INSTALL_DIR ${KF5_INCLUDE_INSTALL_DIR}/KCoreAddons INSTALL)
 install(FILES ${PRI_FILENAME} DESTINATION ${ECM_MKSPECS_INSTALL_DIR})

This is the result, on my system:

Name: KF5CoreAddons
Version: 5.1.0
Libs: -L/home/kde-devel/kde5/lib64 -l/home/kde-devel/kde5/lib64
Cflags: -I/home/kde-devel/kde5/include/KF5/KCoreAddons 
Requires: Qt5Core


Thanks,

Aleix Pol Gonzalez

___
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 12:37:40 Aleix Pol a écrit :
> On Tue, Aug 26, 2014 at 11:20 AM, laurent Montel  wrote:
> > Hi,
> > I will split kdepimlibs as it
> > 
> > akonadi (need to find another name because it's still used)
> > akonadi-abc
> > akonadi-calendar
> > akonadi-contact
> > akonadi-mime
> > akonadi-notes
> > akonadi-socialutils
> > gpgme++
> > kabc
> > kalarmcal
> > kblog
> > kcalcore
> > kcalutils
> > kholidays
> > kimap
> > kioslave
> > kldap
> > kmbox
> > kmime
> > kontactinterface
> > kpimidentities
> > kpimtextedit
> > kpimutils
> > ktnef
> > kxmlrpcclient
> > mailtransport
> > microblog
> > qgpgme
> > syndication
> > 
> > is it ok for you ?
> > Regards
> 
> I'm sorry if I'm insisting too much. Will these become KDE Frameworks? Some
> of them?
> 
> For example KXMLRPC is used by drkonqi, it would be good if it could become
> a KDE Framework.

it's the focus.
We start to split and after we move as KF5 each module when they are ready.

> 
> Aleix

-- 
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: split kdepimlibs

[Jonathan Riddell]

I'd like to suggest taking the opportunity to remove uses of the quite ugly 
term PIM in favour of the friendlier Kontact.

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

Re: split kdepimlibs

[Aleix Pol]

On Tue, Aug 26, 2014 at 11:20 AM, laurent Montel  wrote:

> Hi,
> I will split kdepimlibs as it
>
> akonadi (need to find another name because it's still used)
> akonadi-abc
> akonadi-calendar
> akonadi-contact
> akonadi-mime
> akonadi-notes
> akonadi-socialutils
> gpgme++
> kabc
> kalarmcal
> kblog
> kcalcore
> kcalutils
> kholidays
> kimap
> kioslave
> kldap
> kmbox
> kmime
> kontactinterface
> kpimidentities
> kpimtextedit
> kpimutils
> ktnef
> kxmlrpcclient
> mailtransport
> microblog
> qgpgme
> syndication
>
> is it ok for you ?
> Regards
>

I'm sorry if I'm insisting too much. Will these become KDE Frameworks? Some
of them?

For example KXMLRPC is used by drkonqi, it would be good if it could become
a KDE Framework.

Aleix
___
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 :
> On Tuesday 26 August 2014 11:20:25 laurent Montel wrote:
> > Hi,
> > I will split kdepimlibs as it
> > 
> > akonadi (need to find another name because it's still used)
> > akonadi-abc
> > akonadi-calendar
> > akonadi-contact
> > akonadi-mime
> > akonadi-notes
> > akonadi-socialutils
> 
> To me it sounds like some of those things could be regrouped now. What about
> also bringing the akonadi server on board? Having a bigger akonadi
> framework containing server (right now in kdesupport), some access libs and
> a few default plugins would make sense (it looks like a KIO like
> framework).

Regroup as a framework as :
akonadi-framework (better name)
 -> src
 -> akonadi-abc
 -> akonadi-calendar
 -> akonadi-contact
 -> akonadi-mime
 -> akonadi-notes
 -> akonadi-socialutils
 -> server (Dan must speak about it if he wants to move here)
 -> plugins serializer (moved from kdepim-runtime)



> > gpgme++
> > kabc
> > kalarmcal
> > kblog
> > kcalcore
> > kcalutils
> 
> This one looks like a dumping ground of random things. Maybe some of it
> should move in other frameworks?

Sergio can speak about it

> 
> > kholidays
> > kimap
> > kioslave
> 
> Definitely not a framework. Are all the ioslaves in there still used? I
> think at least some of them can be let go. The others could go in
> kio-extras I guess.

kioslave indeed not a framework. I think that just pop3 is used by kdepim

yes others can move to kio-extra

> 
> > kldap
> > kmbox
> > kmime
> > kontactinterface
> 
> Probably should go in kdepim or kontact itself. Similarly the content of the
> kdelibs/interfaces folder moved out of KF5.

We extracted it in 4.x to allow to create kontact plugins for other 
application.
If we merge in kdepim we will not able to do it.

> 
> > kpimidentities
> 
> Maybe deserves a better name? kidentitymanagement?

Ok seems better. I will work to rename it.

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

For me it's kdepim specific. 

> > kpimutils
> 
> Looks like another dumping ground of random classes. Each class should
> likely find a new home.

Ok I will try to move them.

> > ktnef
> > kxmlrpcclient
> > mailtransport
> > microblog
> > qgpgme
> 
> Couldn't that be merged with gpgme++? This one already builds several
> variants depending what it finds on the platform, why not treat the Qt
> integration in the same way?

Really I never study this lib, there is not unittest, I don't know how it 
works and I don't know why there is several build.
I will not work on.

> 
> > syndication
> > 
> > is it ok for you ?
> 
> I tried to point out things which would be harder to address after the
> split. So I think we should have discussions and decisions about the points
> above before being able to proceed.
> 
> Regards.



-- 
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: OSX/CI: libkdxraw fails to build on branch frameworks

[Aleix Pol]

On Tue, Aug 26, 2014 at 8:28 AM, Marko Käning  wrote:

> There are actually two problems here:
>
> ---
>
> Building CXX object src/CMakeFiles/LibKDcraw.dir/squeezedcombobox.cpp.o
> In file included from
> /Users/marko/WC/KDECI-builds/libkdcraw/src/squeezedcombobox.cpp:31:
> /Users/marko/WC/KDECI-builds/libkdcraw/src/squeezedcombobox.h:36:10: fatal
> error: 'QtGui/QComboBox' file not found
> #include 
>  ^
> 5 warnings generated.
> In file included from
> /Users/marko/WC/KDECI-builds/libkdcraw/src/ractionthreadbase_p.cpp:28:
> /Users/marko/WC/KDECI-builds/libkdcraw/src/ractionthreadbase_p.h:40:10:
> fatal error: 'threadweaver/WeaverObserver.h' file not found
> #include 
>  ^
> In file included from
> /Users/marko/WC/KDECI-builds/libkdcraw/src/ractionthreadbase.cpp:47:
> /Users/marko/WC/KDECI-builds/libkdcraw/src/ractionthreadbase_p.h:40:10:
> fatal error: 'threadweaver/WeaverObserver.h' file not found
> #include 
>  ^
> 1 error generated.
> make[2]: *** [src/CMakeFiles/LibKDcraw.dir/ractionthreadbase.cpp.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> 1 error generated.
> make[2]: *** [src/CMakeFiles/LibKDcraw.dir/ractionthreadbase_p.cpp.o]
> Error 1
>
>
Maybe it hasn't been ported yet?

libkdcraw is not a KDE Framework anyway, you probably want to tell the
Digikam mailing lists.

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

Re: split kdepimlibs

[Kevin Ottens]

On Tuesday 26 August 2014 11:20:25 laurent Montel wrote:
> Hi,
> I will split kdepimlibs as it
> 
> akonadi (need to find another name because it's still used)
> akonadi-abc
> akonadi-calendar
> akonadi-contact
> akonadi-mime
> akonadi-notes
> akonadi-socialutils

To me it sounds like some of those things could be regrouped now. What about 
also bringing the akonadi server on board? Having a bigger akonadi framework 
containing server (right now in kdesupport), some access libs and a few 
default plugins would make sense (it looks like a KIO like framework).

> gpgme++
> kabc
> kalarmcal
> kblog
> kcalcore
> kcalutils

This one looks like a dumping ground of random things. Maybe some of it should 
move in other frameworks?

> kholidays
> kimap
> kioslave

Definitely not a framework. Are all the ioslaves in there still used? I think 
at least some of them can be let go. The others could go in kio-extras I 
guess.

> kldap
> kmbox
> kmime
> kontactinterface

Probably should go in kdepim or kontact itself. Similarly the content of the 
kdelibs/interfaces folder moved out of KF5.

> kpimidentities

Maybe deserves a better name? kidentitymanagement?

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

> ktnef
> kxmlrpcclient
> mailtransport
> microblog
> qgpgme

Couldn't that be merged with gpgme++? This one already builds several variants 
depending what it finds on the platform, why not treat the Qt integration in 
the same way?

> syndication
> 
> is it ok for you ?

I tried to point out things which would be harder to address after the split. 
So I think we should have discussions and decisions about the points above 
before being able to proceed.

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

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



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

split kdepimlibs

[laurent Montel]

Hi,
I will split kdepimlibs as it

akonadi (need to find another name because it's still used)
akonadi-abc
akonadi-calendar
akonadi-contact
akonadi-mime
akonadi-notes
akonadi-socialutils
gpgme++
kabc
kalarmcal
kblog
kcalcore
kcalutils
kholidays
kimap
kioslave
kldap
kmbox
kmime
kontactinterface
kpimidentities
kpimtextedit
kpimutils
ktnef
kxmlrpcclient
mailtransport
microblog
qgpgme
syndication

is it ok for you ?
Regards

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

Jenkins build is back to normal : kcmutils_master_qt5 #76

[KDE CI System]

See 

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

Re: Attention KDE Frameworks 5 Cookbook authors

[Marko Käning]

Thanks Valorie,

for the hint.

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

Re: Attention KDE Frameworks 5 Cookbook authors

[Valorie Zimmerman]

On Tue, Aug 26, 2014 at 12:00 AM, Marko Käning  wrote:
> Hi Valorie,
>
> is there already a PDF somewhere accessible, or does one need to build it 
> locally still?
>
> Greets,
> Marko

Hi Marko,

Please read Mirko's recent blog:
http://creative-destruction.me/2014/08/25/how-to-contribute-to-the-kde-frameworks-cookbook/

When we release we'll have a PDF & ePub available, as well as Techbase
pages. Until then, it must be built locally.

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

Re: Attention KDE Frameworks 5 Cookbook authors

[Marko Käning]

Hi Valorie,

is there already a PDF somewhere accessible, or does one need to build it 
locally still?

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