Re: Review Request 119849: Improve CMAKE error message when XRender or XFixes are missing

[Martin Gräßlin]

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

Ship it!


best would of course be to migrate away from those XLib libraries...

- Martin Gräßlin


On Aug. 20, 2014, 12:55 a.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119849/
> ---
> 
> (Updated Aug. 20, 2014, 12:55 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> This is what would be printed previously:
> 
> CMake Error: The following variables are used in this project, but they are 
> set to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the CMake 
> files:
> X11_Xrender_LIB (ADVANCED)
> linked by target "KF5WindowSystem" in directory /foo/bar
> 
> Now we print:
> 
> The XRender library could not be found. Please install the development 
> package for it.
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt 2794ed1e6f56ed521d845bc20ba1c027493e14e7 
> 
> Diff: https://git.reviewboard.kde.org/r/119849/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: How to promote less mature Frameworks?

[Kevin Ottens]

On Tuesday 19 August 2014 22:39:32 Cornelius Schumacher wrote:
> On Tuesday 19 August 2014 09:33:07 Kevin Ottens wrote:
> > On Tuesday 19 August 2014 08:44:10 David Faure wrote:
> > > IMHO the solution is just to publicize the upcoming frameworks
> > > somewhere.
> > 
> > Which shouldn't be that hard, it's "only" about processing the yaml file
> > and creating a page listing them. I think that's what makes most sense
> > indeed.
> We already have a list on Inqlude with libraries under development (i.e.
> where there is a release, but which is not considered stable quality yet):
> http://inqlude.org/development.html, and a list with unreleased libraries
> (i.e. where there is no release yet, just a repository to grab the code
> from): http://inqlude.org/unreleased.html.

Ah-ah! Sounds about perfect.
 
> Adding some frameworks there based on information from the yaml file would
> be easy. At the moment all framework in the frameworks project are
> considered stable by Inqlude.

Okidoki, so just need to be adjusted to take the release key into account. If 
that's true it can be considered stable, otherwise it should go in the 
unreleased list.

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

Unsolicited email delivered to the mailing list

[Ben Cooksley]

Hi all,

Just to let you know, the delivery of unsolicited email to these
mailing lists recently is in the process of being dealt with. This was
not the result of a fault in Mailman - the identity of a mailing list
member has been impersonated to abuse our lists.

The ultimate originating sender (Nextdoor.com) has been indefinitely
blacklisted from all KDE Sysadmin handled domains as a result (for
both personal and mailing list traffic).

In addition, a complaint has been filed with the whitelisting provider
(ReturnPath) for their email service provider (Mailgun.com) requesting
that the offending behaviour be dealt with appropriately. If
Mailgun.com refuses to implement impersonation prevention, they will
also be subject to being indefinitely blacklisted.

Apologies for any inconvenience this may have caused.

Thanks,
Ben Cooksley
KDE Sysadmin
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

I think you should join 101 Pines/Horseshoe Lake's private website

[Valorie Zimmerman]

Hello,

Valorie Zimmerman invites you to join your 101 Pines/Horseshoe Lake
neighbors on Nextdoor. Nextdoor is a free and private social network
that your neighbors are using.

Valorie wrote:

"Our neighborhood is using a private online network called Nextdoor 101
Pines/Horseshoe Lake. On our Nextdoor site, neighbors share community
events, recommendations, items for sale/free, crime/safety concerns,
ideas about how to make our neighborhood better, and more. I think
you'd also benefit from joining Nextdoor. Please join us to build
better neighborhoods!"

Accept Valorie's invitation:
https://nextdoor.com/choose_address/?i=hkczsx&stage=0&te=1

It's free and only takes a minute.



WHAT IS NEXTDOOR?
Nextdoor is a free, private social network for your
neighborhood.

* Build a stronger neighborhood
Connect with your neighbors to stay
informed and share useful local information.

* Keep the neighborhood safe
Look out for each other and send updates
to keep the neighborhood safe.

* Share goods and recommendations
Find a great babysitter or trusty
dentist. Borrow a ladder or sell that old bookcase.

See your neighborhood in action:
https://nextdoor.com/choose_address/?i=hkczsx&stage=0&te=1



To stop receiving email reminders about this invitation, please follow
the unsubscribe link below:
https://101pineshorseshoelake.nextdoor.com/inv_unsub/?e=kde-frameworks-devel%40kde.org&k=6092244d28ea565

This message was sent by Nextdoor, 760 Market Street, Suite 300, San
Francisco, CA 94102, and intended for kde-frameworks-devel@kde.org.___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 119849: Improve CMAKE error message when XRender or XFixes are missing

[Alexander Richardson]

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

(Updated Aug. 20, 2014, 12:55 vorm.)


Review request for KDE Frameworks.


Repository: kwindowsystem


Description
---

This is what would be printed previously:

CMake Error: The following variables are used in this project, but they are set 
to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake 
files:
X11_Xrender_LIB (ADVANCED)
linked by target "KF5WindowSystem" in directory /foo/bar

Now we print:

The XRender library could not be found. Please install the development package 
for it.


Diffs (updated)
-

  src/CMakeLists.txt 2794ed1e6f56ed521d845bc20ba1c027493e14e7 

Diff: https://git.reviewboard.kde.org/r/119849/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: Proposal to improving KDE Software Repository Organization

[Ben Cooksley]

On Wed, Aug 20, 2014 at 9:39 AM, Michael Pyne  wrote:
> On Tue, August 19, 2014 10:18:17 David Faure wrote:
>> On Tuesday 19 August 2014 19:10:14 Ben Cooksley wrote:
>> > The old kf5-qt5 / latest-qt4 names are being mapped to division /
>> > track combinations. They are otherwise not used.
>>
>> Ah!
>>
>> > Just a clarification though: there would only be two divisions for the
>> > above scenario: Plasma5 and KF5.
>> > Plasma5 would then have two tracks: stable and devel. KF5 would have
>> > it's single track.
>>
>> Ah!
>>
>> OK it's a lot clearer to me now.
>>
>> I thought a division was an overall selection of everything
>> (like kf5-qt5 was).
>> Now I see, it's a group of modules, e.g. just KF5, or just Plasma5.
>> This makes a lot more sense, and leads to understandable naming, I like it
>> :)
>>
>> I assume a future kdesrc-buildrc will look like a selection of *one or many*
>> divisions, with a track for each one, then.
>
> Yes, and branch groups simply become a "pre-tested" set of divisions (I would
> imagine it simply defines the various combinations CI would test in the
> future, though that concept is still up to Ben).
>
> In the kdesrc-build world you'd still be able to pick divisions (and tracks),
> individual modules, etc.
>
> There's two feasible ways to go with the "branch-group" option though: It is
> used to pick the right branch or track if not specified, or it is used as CI
> would use it, to pull in an entire set of divisions in one fell swoop. I'm
> open to other ideas, but that's a topic for a separate thread in any event.

The CI system will probably end up relying on divisions directly in
the long run from what I can see at this point.
As an interim measure though, it is likely the branch group concept
will continue to be used though.

I have some other questions for those working on Windows/OS X/Android
CI, but that is a topic for another thread :)

>
> Regards,
>  - Michael Pyne

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

Re: Proposal to improving KDE Software Repository Organization

[Michael Pyne]

On Tue, August 19, 2014 10:18:17 David Faure wrote:
> On Tuesday 19 August 2014 19:10:14 Ben Cooksley wrote:
> > The old kf5-qt5 / latest-qt4 names are being mapped to division /
> > track combinations. They are otherwise not used.
> 
> Ah!
> 
> > Just a clarification though: there would only be two divisions for the
> > above scenario: Plasma5 and KF5.
> > Plasma5 would then have two tracks: stable and devel. KF5 would have
> > it's single track.
> 
> Ah!
> 
> OK it's a lot clearer to me now.
> 
> I thought a division was an overall selection of everything
> (like kf5-qt5 was).
> Now I see, it's a group of modules, e.g. just KF5, or just Plasma5.
> This makes a lot more sense, and leads to understandable naming, I like it
> :)
> 
> I assume a future kdesrc-buildrc will look like a selection of *one or many*
> divisions, with a track for each one, then.

Yes, and branch groups simply become a "pre-tested" set of divisions (I would 
imagine it simply defines the various combinations CI would test in the 
future, though that concept is still up to Ben).

In the kdesrc-build world you'd still be able to pick divisions (and tracks), 
individual modules, etc.

There's two feasible ways to go with the "branch-group" option though: It is 
used to pick the right branch or track if not specified, or it is used as CI 
would use it, to pull in an entire set of divisions in one fell swoop. I'm 
open to other ideas, but that's a topic for a separate thread in any event.

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

Review Request 119849: Improve CMAKE error message when XRender or XFixes are missing

[Alexander Richardson]

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

Review request for KDE Frameworks.


Repository: kwindowsystem


Description
---

This is what would be printed previously:

CMake Error: The following variables are used in this project, but they are set 
to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake 
files:
X11_Xrender_LIB (ADVANCED)
linked by target "KF5WindowSystem" in directory /foo/bar

Now we print:

The XRender library could not be found. Please install the development package 
for it.


Diffs
-

  src/CMakeLists.txt 2794ed1e6f56ed521d845bc20ba1c027493e14e7 

Diff: https://git.reviewboard.kde.org/r/119849/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: Replacement for kde4_add_app_icon ?

[Marko Käning]

On 12 Aug 2014, at 12:52 , Albert Astals Cid  wrote:

> Hi, i've been porting some of my apps to KF5 work and I'm noticing there 
> doesn't seem to be (or i can't find) a replacement for kde4_add_app_icon.
> 
> This seems like a problem for the support in windows/macosX. Is there any 
> plan 
> to work on an ecm version? Or it already exists and i failed to find it? Or 
> it 
> was decided on purpose not to support it?

Any news on this one?
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: How to promote less mature Frameworks?

[Albert Astals Cid]

El Dimarts, 19 d'agost de 2014, a les 08:44:10, David Faure va escriure:
> On Friday 15 August 2014 12:51:58 Kevin Ottens wrote:
> > On Friday 15 August 2014 09:34:04 Alex Merry wrote:
> > > On Friday 15 August 2014 10:21:57 Mark Gaiser wrote:
> > > > On Fri, Aug 15, 2014 at 12:12 AM, Àlex Fiestas  
wrote:
> > > > > Hi there
> > > > > 
> > > > > At the Randa sprint we have discussed a little bit what to do with
> > > > > those
> > > > > frameworks that are still not mature (for example they can't commit
> > > > > on
> > > > > ABI/API stability) but they are ready for feedback from third party
> > > > > developers.
> > > > > 
> > > > > Even though there was not consensus in the discussion this is an
> > > > > idea
> > > > > that
> > > > > came out during the discussion:
> > > > > 
> > > > > -We introduce a Maturity level that we can use to manage
> > > > > expectations
> > > > > about
> > > > > the Framework (for example whether API/ABI will be kept)
> > > > > -We release Frameworks that are not ready together with the rest,
> > > > > but
> > > > > we
> > > > > have to make damn sure we manage expectations.
> > > > > 
> > > > > With this we can get early feedback for new frameworks, and since we
> > > > > have
> > > > > a
> > > > > rapid release cycle we can improve them fast.
> > > > > 
> > > > > What do you think?
> > > > 
> > > > It depends on how you define maturity.
> > > > 
> > > > For instance, if a maturity is simply a value set in each project'
> > > > metainfo.yaml and set by those that maintain it then the maturity
> > > > level quite frankly doesn't tell you anything.
> > > > 
> > > > But if you decide maturity dynamically based on git activity, api/abi
> > > > stability, number of people contributing and where the project itself
> > > > is used in other projects (just some conditions that i can think of
> > > > now, there is probably more). With this a project maturity actually
> > > > has a meaning. When going for this approach it would also be nice to
> > > > show a list of projects using "Framework X". Also, i do not consider a
> > > > project being healthy when it has only one developer [1] even if the
> > > > project is used by dozens of other projects and has much activity. For
> > > > us - kde devs - we probably don't care much if a framework is being
> > > > developed/maintained by one person, but for external potential
> > > > framework users that will be a concern. Specially companies.
> > > 
> > > I think you're talking less about "maturity" and more about "vitality",
> > > or
> > > something. Anyway, naming aside, I think Àlex was talking specifically
> > > about API/ABI guarantees - we offer pretty strong guarantees, and fresh
> > > projects may not want to commit to that until they've had some
> > > real-world
> > > usage and feedback. This would allow the equivalent to kdelibs' old
> > > "experimental" tagging, which was used for a couple of libraries while
> > > they settled on an API.
> > > 
> > > I think it could be useful, but would definitely require very careful
> > > communication.
> > 
> > And that's the problem if we release them. If it's released "with the
> > rest"
> > expect people to have wrong expectations about them.
> > 
> > A possibility would be perhaps to produce nightly tarballs for those
> > frameworks which don't have the "release: true" flag. This way they keep
> > not being part of a release, and early adopters have something easy to
> > grab.
> Wouldn't early adopters just checkout and build from git ?
> 
> I don't know about you, but I almost never download a source tarball,
> because a git checkout is just so much easier to update later.
> We mostly make tarballs for packagers, and the non-mature frameworks we're
> talking about should definitely NOT be packaged.
> 
> IMHO the solution is just to publicize the upcoming frameworks somewhere.

I see a small problem with git-only repos, and it's called 
release+distributions.

I have heard that the plam is to frameworks-ize kdepimlibs, ideally one would 
like to do a release of kdepimlibs so that the kf5-based kdepim can use them 
but without guaranteeing ABI/API compatibility.

But if we want distros to package that kdepim we're going to need packages.

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

OSX/CI: kactivities can't be build due to failing to locate framework kdeclarative

[Marko Käning]

When trying to build kactivities an error occurs on OSX due to inability to 
locate kdeclarative:

---

CMake Warning (dev) at 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/kdesupport/extra-cmake-modules/inst/share/ECM/find-modules/FindKF5.cmake:52
 (message):
  Your project should require at least CMake 2.8.12 to use FindKF5.cmake
Call Stack (most recent call first):
  src/workspace/kio/CMakeLists.txt:13 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found KF5I18n: 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/frameworks/ki18n/inst/lib/cmake/KF5I18n/KF5I18nConfig.cmake
 (found version "5.1.0")
-- Found KF5: success (found version "5.1.0") found components:  KIO I18n
CMake Warning at src/workspace/CMakeLists.txt:6 (find_package):
  By not providing "FindKF5Declarative.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "KF5Declarative", but CMake did not find one.

  Could not find a package configuration file provided by "KF5Declarative"
  with any of the following names:

KF5DeclarativeConfig.cmake
kf5declarative-config.cmake

---


But KFDeclarative IS indeed installed on the CI system:

---

$ tree 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/frameworks/kdeclarative/inst/lib/cmake
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/frameworks/kdeclarative/inst/lib/cmake
└── KF5Declarative
├── KF5DeclarativeConfig.cmake
├── KF5DeclarativeConfigVersion.cmake
├── KF5DeclarativeTargets-debug.cmake
└── KF5DeclarativeTargets.cmake

1 directory, 4 files

---





kactivities.log.gz
Description: GNU Zip compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kcoreaddons fails to build properly on OSX/CI (was OSX/CI: kauth fails to build )

[Marko Käning]

Hi Aleix & Ben,

On 13 Aug 2014, at 10:51 , Aleix Pol  wrote:
> I'm unsure, try cleaning the build directory and trying again?
> There certainly hasn't been a change on the kf5 side, that I know of at least.

following you guys’ advice, I could verify that there was nothing new, neither 
in
ECM nor in kcoreaddons.

Although I had *UN*successfully tried to build tier 2 from scratch a week ago, I
tried again today and see, now it worked! :-|
So, this must have been caused by the build directory itself for some reason.
(But I haven’t tried to figure out why this had happened, due to lack of insight
into these builds…)

For now I am happy that the CI scripts should be able to build most KF5 
frameworks
once again now, at least as long as I keep using my old Qt5!!
I haven’t tried to build project qt5 since [1], which is an issue into which 
also
Thibaut ran at Randa and which we could only fix by reverting back to an older 
qt5
install going back to June 10th.

Greets,
Marko



[1] http://mail.kde.org/pipermail/kde-frameworks-devel/2014-August/018268.html
[2] qt5 - a83826dad0f62d7a96f5a6093240e4c8f7f2e06e
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: How to promote less mature Frameworks?

[Cornelius Schumacher]

On Tuesday 19 August 2014 09:33:07 Kevin Ottens wrote:
> On Tuesday 19 August 2014 08:44:10 David Faure wrote:
> 
> > IMHO the solution is just to publicize the upcoming frameworks somewhere.
> 
> Which shouldn't be that hard, it's "only" about processing the yaml file and
> creating a page listing them. I think that's what makes most sense indeed.

We already have a list on Inqlude with libraries under development (i.e. where 
there is a release, but which is not considered stable quality yet): 
http://inqlude.org/development.html, and a list with unreleased libraries 
(i.e. where there is no release yet, just a repository to grab the code from): 
http://inqlude.org/unreleased.html.

Adding some frameworks there based on information from the yaml file would be 
easy. At the moment all framework in the frameworks project are considered 
stable by Inqlude.

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

Re: Review Request 119809: KIO: New job RestoreJob, public API KIO::restoreFromTrash().

[David Faure]

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

(Updated Aug. 19, 2014, 8:36 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Eike Hein.


Repository: kio


Description
---

This was within libkonq as KonqMultiRestoreJob, public API 
KonqOperations::restoreTrashedItems().

REVIEW: 119809


Diffs
-

  src/core/restorejob.h PRE-CREATION 
  src/core/restorejob.cpp PRE-CREATION 
  autotests/fileundomanagertest.h 112657a1fcfea1e588e5fa53a1bbfccfe7a5de3d 
  autotests/fileundomanagertest.cpp c1f253b4e41bff6d96baa9017fe8d6c70386efb8 
  src/core/CMakeLists.txt 1e9ab98d2c0c27a696baab0bb8375c8cf81a3632 

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


Testing
---

Added unittest; passes.

It reminded me that this operation wasn't undoable yet, though.


Thanks,

David Faure

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

Re: Review Request 119846: qtcontrols port for checkbox and radiobutton

[Marco Martin]

> On Aug. 19, 2014, 7:43 p.m., David Edmundson wrote:
> > src/declarativeimports/plasmacomponents/qml/styles/CheckBoxStyle.qml, line 
> > 51
> > 
> >
> > checked isn't a boolean, it's an enum of the checked, partial, 
> > unchecked.

eew, the tristate stuff, right..


- Marco


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


On Aug. 19, 2014, 5:21 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119846/
> ---
> 
> (Updated Aug. 19, 2014, 5:21 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this ports checkbox and radiobuttons (and switch that at least on desktop 
> formfactor is just an alias for checkboxes) to qtcontrols and adds the 
> corresponding styles
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qml/CheckBox.qml 5e98d11 
>   src/declarativeimports/plasmacomponents/qml/RadioButton.qml 00a1bbf 
>   src/declarativeimports/plasmacomponents/qml/Switch.qml d0608f9 
>   src/declarativeimports/plasmacomponents/qml/styles/CheckBoxStyle.qml 
> PRE-CREATION 
>   src/declarativeimports/plasmacomponents/qml/styles/RadioButtonStyle.qml 
> PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119846/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Kioslave repos

[David Faure]

On Tuesday 01 July 2014 22:25:15 Jonathan Riddell wrote:
> On Tue, Jul 01, 2014 at 11:25:11PM +0200, David Faure wrote:
> > On Sunday 27 April 2014 19:35:37 I wrote:
> > > > * place that repo in kde/ or kde/ in the projects.kde.org
> > > > hierarchy, so that it gets released with the KDE Applications, NOT
> > > > with
> > > > the
> > > > workspace product. Support for kio_fish/kio_sftp on Windows or Gnome
> > > > desktops is one of the major selling points of Dolphin there, this is
> > > > "apps", not "workspace".
> > 
> > What happened to this? I see that kio-extras is in kde/workspace,
> > while I believe it doesn't belong there.
> > 
> > Does anyone disagree with my line of thought above?
> 
> plasma-devel list may also have an opinion on this, sending there.

Any news?

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

Re: What to do with autostart scripts? (kinit / ksmserver problem)

[David Faure]

On Wednesday 09 July 2014 14:24:37 Luca Beltrame wrote:
> Hello,
> 
> commit f913e251fe66e22606c380a8cc0ddc8c69e3c07d in plasma-workspace removed
> autostart support in ksmserver because it caused .desktop files to be
> autostarted twice (one for kinit, and one for ksmserver).
> 
> I just noticed that it causes a regression in behavior from 4.x times, as
> user scripts (like adding ssh-agents etc.) are no longer run (because kinit
> only runs .desktop files).
> 
> So, this needs to be either communicated to the users or handled differently
> (yes, I don't want to wade through possible complaints in the forums ;)
> 
> My high (uniformed) level opinion on the possible scenarios:
> 
> - Re-enable autostart for everything but desktop files in ksmserver;
> - Add support for scripts in kinit (does it even make sense?);
> - Drop autostart scripts, tell users to make .desktop files
> 
> What do the gurus say on this?

I'd pick option 1 - do it all in ksmserver.

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

Re: Review Request 119846: qtcontrols port for checkbox and radiobutton

[David Edmundson]

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



src/declarativeimports/plasmacomponents/qml/styles/CheckBoxStyle.qml


Good question.

I think it is needed to set background to something otherwise it will use 
the one in the Base style.



src/declarativeimports/plasmacomponents/qml/styles/CheckBoxStyle.qml


checked isn't a boolean, it's an enum of the checked, partial, unchecked.



src/declarativeimports/plasmacomponents/qml/styles/RadioButtonStyle.qml


Can/should this be fixed inside the SVGs?

Otherwise we're doing breeze hacks at a code level, a themer who creates 
both as rectangles will get one inexplicably larger


- David Edmundson


On Aug. 19, 2014, 5:21 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119846/
> ---
> 
> (Updated Aug. 19, 2014, 5:21 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this ports checkbox and radiobuttons (and switch that at least on desktop 
> formfactor is just an alias for checkboxes) to qtcontrols and adds the 
> corresponding styles
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qml/CheckBox.qml 5e98d11 
>   src/declarativeimports/plasmacomponents/qml/RadioButton.qml 00a1bbf 
>   src/declarativeimports/plasmacomponents/qml/Switch.qml d0608f9 
>   src/declarativeimports/plasmacomponents/qml/styles/CheckBoxStyle.qml 
> PRE-CREATION 
>   src/declarativeimports/plasmacomponents/qml/styles/RadioButtonStyle.qml 
> PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119846/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119808: Move module metadata to after class picker

[Alex Merry]

> On Aug. 19, 2014, 10:19 a.m., Aleix Pol Gonzalez wrote:
> > I think it's disputable that the developers will want to interact with the 
> > "File List" more often. I think this shows we want a new design after all.
> > 
> > For the moment, I won't +1 or -1.

I'm admittedly going off how I personally use apidocs, which is to extensively 
use the class list and/or class picker, both of which are shoved off the bottom 
of the window for me with the current layout (while this patch makes both those 
and at least part of the module info section visible without scrolling).


- Alex


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


On Aug. 18, 2014, 10:04 p.m., Alex Merry wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119808/
> ---
> 
> (Updated Aug. 18, 2014, 10:04 p.m.)
> 
> 
> Review request for KDE Frameworks, Denis Steckelmacher and Aurélien Gâteau.
> 
> 
> Repository: kapidox
> 
> 
> Description
> ---
> 
> This puts the things developers will want to access repeatedly at the
> top.
> 
> Move module description out of sidebar header
> 
> Multi-line headers look very odd, and this happens on multiple
> frameworks. The header instead has "About", and the description is a
> normal paragraph underneath.
> 
> 
> Diffs
> -
> 
>   src/kapidox/data/htmlresource/kde.css 
> e173dfe559d762b347815223c9e1e3ef3b0b7a4c 
>   src/kapidox/data/templates/doxygen.html 
> d00e14e4b16e8d8ac1176cf2e73dd8dca02976d9 
>   src/kapidox/data/templates/fwinfo.html 
> 8bba4b48b1a4937df6d5e809b9389d2c3ba123f3 
> 
> Diff: https://git.reviewboard.kde.org/r/119808/diff/
> 
> 
> Testing
> ---
> 
> Built apidox with the changes, visually inspected KApiDox (long description) 
> and KArchive (short description).
> 
> 
> File Attachments
> 
> 
> Screenshot
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/08/18/66921e40-9e30-4231-a01e-da2d3c26d979__about_below_class_picker.png
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

___
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

[Alex Merry]

> On Aug. 15, 2014, 8:20 a.m., Alex Merry wrote:
> > modules/ECMGeneratePkgConfigFile.cmake, line 47
> > 
> >
> > This belongs in KDEInstallDirs.cmake, not here (as 
> > CMAKE_INSTALL_PKGCONFIGDIR, ideally). Projects that don't use 
> > KDEInstallDirs can create their own variable.
> > 
> > Also, pkconfig -> pkgconfig.
> 
> Aleix Pol Gonzalez wrote:
> I'm unsure about that, first ECM_MKSPECS_INSTALL_DIR is declared the same 
> way (again, copy&paste) then I understand that we can override the variable 
> from KDEInstallDirs, but we do want that the module that uses the variable 
> actually declares it, right?
> 
> Alex Merry wrote:
> Yeah, I don't like that about the QMake module. The thing is, this module 
> *doesn't* use the variable - it sets it, and then expects the caller to use 
> it.
> 
> Aleix Pol Gonzalez wrote:
> Maybe what feels wrong is the fact that we need to explicitly install it. 
> When we use such a macro, we want to generate the file and get it done.

I'm generally not in favour of magic, especially magic where you actually have 
to do something apparently unrelated (in this case, define CMAKE_INSTALL_LIBDIR 
or equivalent, possibly by including KDEInstallDirs) for it to actually work. 
I'd rather have an explicit argument - that, at least, is greppable. Note that 
getting the correct value of CMAKE_INSTALL_LIBDIR/LIB_INSTALL_DIR is *hard* - 
both the GNUInstallDirs and KDEInstallDirs have a reasonably large chunk of 
logic to figure it out.


- Alex


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


On Aug. 19, 2014, 11:34 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119798/
> ---
> 
> (Updated Aug. 19, 2014, 11:34 a.m.)
> 
> 
> Review request for Build System, KDE Frameworks and Harald Sitter.
> 
> 
> 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
> -
> 
>   modules/ECMGeneratePkgConfigFile.cmake 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

Review Request 119846: qtcontrols port for checkbox and radiobutton

[Marco Martin]

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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

this ports checkbox and radiobuttons (and switch that at least on desktop 
formfactor is just an alias for checkboxes) to qtcontrols and adds the 
corresponding styles


Diffs
-

  src/declarativeimports/plasmacomponents/qml/CheckBox.qml 5e98d11 
  src/declarativeimports/plasmacomponents/qml/RadioButton.qml 00a1bbf 
  src/declarativeimports/plasmacomponents/qml/Switch.qml d0608f9 
  src/declarativeimports/plasmacomponents/qml/styles/CheckBoxStyle.qml 
PRE-CREATION 
  src/declarativeimports/plasmacomponents/qml/styles/RadioButtonStyle.qml 
PRE-CREATION 

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


Testing
---


Thanks,

Marco Martin

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

Re: How to promote less mature Frameworks?

[Kevin Ottens]

On Tuesday 19 August 2014 16:53:58 Sebastian Kügler wrote:
> On Tuesday, August 19, 2014 09:33:07 Kevin Ottens wrote:
> > > Wouldn't early adopters just checkout and build from git ?
> > 
> > Well, I guess some of them might just want to grab something and run with
> > it.  Maybe not the majority indeed...
> 
> I think in this case we want to encourage picking it from Git, just to make
> the inevitable update (it's immature, right) easier and more
> straightforward.

Yep, that's what I meant by producing a list. It can probably be scripted and 
generate a page pointing to the repositories, giving the git command for 
cloning, etc.

> Creating a tarball would perhaps lend it too much
> credibility?

That's exactly the concern.
 
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: How to promote less mature Frameworks?

[Sebastian Kügler]

On Tuesday, August 19, 2014 09:33:07 Kevin Ottens wrote:
> > Wouldn't early adopters just checkout and build from git ?
> 
> Well, I guess some of them might just want to grab something and run with
> it.  Maybe not the majority indeed...

I think in this case we want to encourage picking it from Git, just to make 
the inevitable update (it's immature, right) easier and more straightforward. 
Creating a tarball would perhaps lend it too much credibility?

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: How to promote less mature Frameworks?

[Kevin Ottens]

On Tuesday 19 August 2014 15:09:46 Aleix Pol wrote:
> On Tue, Aug 19, 2014 at 2:04 PM, Kevin Ottens  wrote:
> > I'd wait for the demand for that. api.kde.org is already very loaded in
> > information no need to add even more IMO.
> 
> Well, we did some information unloading work back in Randa. Maybe you want
> to take a look at it again.

Did that already. ;-)

Cheers.
-- 
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: How to promote less mature Frameworks?

[Aleix Pol]

On Tue, Aug 19, 2014 at 2:04 PM, Kevin Ottens  wrote:

> On Tuesday 19 August 2014 12:22:17 Aleix Pol wrote:
> > On Tue, Aug 19, 2014 at 9:33 AM, Kevin Ottens  wrote:
> > > On Tuesday 19 August 2014 08:44:10 David Faure wrote:
> > > > IMHO the solution is just to publicize the upcoming frameworks
> > > > somewhere.
> > >
> > > Which shouldn't be that hard, it's "only" about processing the yaml
> file
> > > and creating a page listing them. I think that's what makes most sense
> > > indeed.
> >
> > Maybe we can show their API documentation as well, in a different
> category.
> > [1]
>
> I'd wait for the demand for that. api.kde.org is already very loaded in
> information no need to add even more IMO.
>
> Cheers.
>

Well, we did some information unloading work back in Randa. Maybe you want
to take a look at it again.

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

Re: How to promote less mature Frameworks?

[Kevin Ottens]

On Tuesday 19 August 2014 12:22:17 Aleix Pol wrote:
> On Tue, Aug 19, 2014 at 9:33 AM, Kevin Ottens  wrote:
> > On Tuesday 19 August 2014 08:44:10 David Faure wrote:
> > > IMHO the solution is just to publicize the upcoming frameworks
> > > somewhere.
> > 
> > Which shouldn't be that hard, it's "only" about processing the yaml file
> > and creating a page listing them. I think that's what makes most sense
> > indeed.
> 
> Maybe we can show their API documentation as well, in a different category.
> [1]

I'd wait for the demand for that. api.kde.org is already very loaded in 
information no need to add even more IMO.

Cheers.
-- 
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 119798: Generating PkgConig files from ECM

[Aleix Pol Gonzalez]

> On Aug. 15, 2014, 8:20 a.m., Alex Merry wrote:
> > modules/ECMGeneratePkgConfigFile.cmake, line 47
> > 
> >
> > This belongs in KDEInstallDirs.cmake, not here (as 
> > CMAKE_INSTALL_PKGCONFIGDIR, ideally). Projects that don't use 
> > KDEInstallDirs can create their own variable.
> > 
> > Also, pkconfig -> pkgconfig.
> 
> Aleix Pol Gonzalez wrote:
> I'm unsure about that, first ECM_MKSPECS_INSTALL_DIR is declared the same 
> way (again, copy&paste) then I understand that we can override the variable 
> from KDEInstallDirs, but we do want that the module that uses the variable 
> actually declares it, right?
> 
> Alex Merry wrote:
> Yeah, I don't like that about the QMake module. The thing is, this module 
> *doesn't* use the variable - it sets it, and then expects the caller to use 
> it.

Maybe what feels wrong is the fact that we need to explicitly install it. When 
we use such a macro, we want to generate the file and get it done.


> On Aug. 15, 2014, 8:20 a.m., Alex Merry wrote:
> > modules/ECMGeneratePkgConfigFile.cmake, lines 12-18
> > 
> >
> > Please document the arguments.

Will do, when we've agreed on an API.


- Aleix


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


On Aug. 18, 2014, 1:59 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119798/
> ---
> 
> (Updated Aug. 18, 2014, 1:59 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks and Harald Sitter.
> 
> 
> 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
> -
> 
>   modules/ECMGeneratePkgConfigFile.cmake 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 FILENAME_VAR PC_FILENAME INCLUDE_INSTALL_DIR 
> ${KF5_INCLUDE_INSTALL_DIR}/KCoreAddons)
> +install(FILES ${PC_FILENAME} DESTINATION ${ECM_PKGCONFIG_INSTALL_DIR})
>  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: 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. 19, 2014, 11:34 a.m.)


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


Changes
---

Iteration.


Summary (updated)
-

Generating PkgConfig files from ECM


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 

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


Testing (updated)
---

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: Proposal to improving KDE Software Repository Organization

[Aleix Pol]

On Tue, Aug 19, 2014 at 3:54 AM, Michael Pyne  wrote:

> Hi all,
>
> Ben Cooksley and I would like to get some feedback on further evolutions to
> the organization structure we employ for the repositories at git.kde.org,
> to
> allow our current usage of CI even as we move farther into the KF5-based
> world.
>
> TL;DR: More indirection in our JSON in kde-build-metadata, not a lot of
> end-
> user visible change, new org. terms: "Division" and "Track" for multi-repo
> organization, tracking inter-repo dependencies would change too (sayonara
> dependency-data-$branch_group), less CI servers turned into melting piles
> of
> slag. +1?
>
> The proposal follows for those who like reading excessively wordy text.
>
> Regards,
>  - Michael Pyne
>
> Improving KDE Project Organization: A Proposal
> ==
>
> 18 Aug 2014
>
> Michael Pyne  and Ben Cooksley 
>
> This is a proposal to evolve the current method of organizing our mass of
> KDE
> source code repositories, and their dependencies, as contained in the
> `kde-build-metadata` repository and used by kdesrc-build and build.kde.org
> (referred to as "CI"). This is needed in order to correct some
> deficiencies in
> the [current
> specification](https://community.kde.org/Infrastructure/Project_Metadata),
> and
> to help better support changing trends in developer workflow.
>
> Current Situation
> =
>
> If you're familiar with the current organization of "KDE build metadata"
> you
> should skip to the next section.
>
> Currently, the git-based source code repositories that make up KDE.org's
> software releases are each given a "project path" that fully specifies the
> name
> of the module in a virtual hierarchy. For instance, kdesrc-build itself is
> really "extragear/utils/kdesrc-build", and KDE 4's kdelibs is
> "kde/kdelibs".
>
> Since many modules support KDE4 and Qt5/KF5 (or may in the future), some
> developers associated with KDE source code repositories introduced the
> "branch
> group" construct, that maps the git repository branch for the majority of
> repositories into a few broad groupings, such as "stable-qt4", "latest-qt4"
> and
> "kf5-qt5". Developers and users using kdesrc-build could then use these
> groups
> to easily build the appropriate git branch of the many repositories needed
> for
> current releases of KDE.org software. This also allowed the CI
> infrastructure
> to support testing the development branches of both software using both
> KDE4 and KF5, in addition to the libraries/Frameworks themselves.
>
> Current Issues
> ==
>
> Things have gone fairly well with branch groups, but there have been minor
> issues with the construct:
>
> 1. The existing metadata listing dependencies between git repositories
> could
>not support multiple branch groups, as the dependencies were not
> necessarily
>identical for a given repository, for every possible branch group it
>belonged to. We worked around this by forking the metadata such that
> each
>different branch group used a separate dependency file.
>
> 2. Compounding that issue, different branch groups would have different
> sets
>of repositories. For instance some repositories will never have a
> KF5-based
>release due to ongoing reorganization, and many repositories were born
> for
>KF5. By common agreement, software using `kde-build-metadata` now
> recognize
>empty git branch names to mean that a repository doesn't actually
> belong to
>the given branch group. This is still a workaround, however; if we
> forget
>to manually specify an empty branch, then CI and kdesrc-build will both
>try to build that repository as part of that branch group (using a
> default
>branch).
>
> Upcoming Problems
> =
>
> A larger concern (and what instigated this effort) is that the KF5 era will
> introduce multiple development models that are difficult for the CI
> infrastructure to efficiently support.
>
> For example, testing the KF5-based Plasma 5 Workspace will eventually need
> to
> test both the stable and development tracks for Plasma 5. Under the branch
> group concept, this would lead to branch groups "kf5-qt5" and
> "kf5-qt5-stable"
> (or similar names).
>
> However the KF5 repositories that Plasma 5 requires do not have a split
> between
> stable and devel: They use a review-required process by which there's only
> one
> development track. In other words, Plasma 5's two development tracks will
> only
> depend on 1 KF5 track.
>
> At this time, that means CI will have to build 56 KF5 modules to test
> Plasme
> 5-stable, and then re-build, re-install, etc. the exact same 56 modules to
> then
> test Plasma 5-devel. This re-build is required because experience has shown
> that built repositories cannot be assumed to be compatible between
> different
> branch groups (in fact many repositories are significantly different
> on-disk
> between branch groups). There's simply no data recorde

Re: How to promote less mature Frameworks?

[Aleix Pol]

On Tue, Aug 19, 2014 at 9:33 AM, Kevin Ottens  wrote:

> On Tuesday 19 August 2014 08:44:10 David Faure wrote:
> > On Friday 15 August 2014 12:51:58 Kevin Ottens wrote:
> > > And that's the problem if we release them. If it's released "with the
> > > rest" expect people to have wrong expectations about them.
> > >
> > > A possibility would be perhaps to produce nightly tarballs for those
> > > frameworks which don't have the "release: true" flag. This way they
> keep
> > > not being part of a release, and early adopters have something easy to
> > > grab.
> >
> > Wouldn't early adopters just checkout and build from git ?
>
> Well, I guess some of them might just want to grab something and run with
> it.
> Maybe not the majority indeed...
>
> > I don't know about you, but I almost never download a source tarball,
> > because a git checkout is just so much easier to update later.
> > We mostly make tarballs for packagers, and the non-mature frameworks
> we're
> > talking about should definitely NOT be packaged.
>
> Agreed.
>
> > IMHO the solution is just to publicize the upcoming frameworks somewhere.
>
> Which shouldn't be that hard, it's "only" about processing the yaml file
> and
> creating a page listing them. I think that's what makes most sense indeed.
>
> Regards.
>

Maybe we can show their API documentation as well, in a different category.
[1]

Aleix

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

Re: Review Request 119808: Move module metadata to after class picker

[Aleix Pol Gonzalez]

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


I think it's disputable that the developers will want to interact with the 
"File List" more often. I think this shows we want a new design after all.

For the moment, I won't +1 or -1.

- Aleix Pol Gonzalez


On Aug. 18, 2014, 10:04 p.m., Alex Merry wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119808/
> ---
> 
> (Updated Aug. 18, 2014, 10:04 p.m.)
> 
> 
> Review request for KDE Frameworks, Denis Steckelmacher and Aurélien Gâteau.
> 
> 
> Repository: kapidox
> 
> 
> Description
> ---
> 
> This puts the things developers will want to access repeatedly at the
> top.
> 
> Move module description out of sidebar header
> 
> Multi-line headers look very odd, and this happens on multiple
> frameworks. The header instead has "About", and the description is a
> normal paragraph underneath.
> 
> 
> Diffs
> -
> 
>   src/kapidox/data/htmlresource/kde.css 
> e173dfe559d762b347815223c9e1e3ef3b0b7a4c 
>   src/kapidox/data/templates/doxygen.html 
> d00e14e4b16e8d8ac1176cf2e73dd8dca02976d9 
>   src/kapidox/data/templates/fwinfo.html 
> 8bba4b48b1a4937df6d5e809b9389d2c3ba123f3 
> 
> Diff: https://git.reviewboard.kde.org/r/119808/diff/
> 
> 
> Testing
> ---
> 
> Built apidox with the changes, visually inspected KApiDox (long description) 
> and KArchive (short description).
> 
> 
> File Attachments
> 
> 
> Screenshot
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/08/18/66921e40-9e30-4231-a01e-da2d3c26d979__about_below_class_picker.png
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

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

Re: Proposal to improving KDE Software Repository Organization

[David Faure]

On Tuesday 19 August 2014 19:10:14 Ben Cooksley wrote:
> The old kf5-qt5 / latest-qt4 names are being mapped to division /
> track combinations. They are otherwise not used.

Ah!

> Just a clarification though: there would only be two divisions for the
> above scenario: Plasma5 and KF5.
> Plasma5 would then have two tracks: stable and devel. KF5 would have
> it's single track.

Ah!

OK it's a lot clearer to me now.

I thought a division was an overall selection of everything
(like kf5-qt5 was).
Now I see, it's a group of modules, e.g. just KF5, or just Plasma5.
This makes a lot more sense, and leads to understandable naming, I like it :)

I assume a future kdesrc-buildrc will look like a selection of *one or many*
divisions, with a track for each one, then.

All sounds very good, +1.

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

Re: Review Request 119773: Launch scripts in autostart-directories

[Martin Yrjölä]

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

(Updated Aug. 19, 2014, 7:45 a.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks.


Bugs: 335878 and 338242
https://bugs.kde.org/show_bug.cgi?id=335878
https://bugs.kde.org/show_bug.cgi?id=338242


Repository: kinit


Description
---

This fixes execution of scripts other than ".desktop"-files in the 
~/.config/autostart directory when starting a session. This functionality was 
removed in https://git.reviewboard.kde.org/r/118977/ because of 
https://bugs.kde.org/show_bug.cgi?id=335878.

Things that still have to be discussed:
* Is kinit the right place for this functionality? I think it makes sense 
because all other autostart functionality is there.
* Is kioclient5 the correct way to start the scripts?
* Which kind of files in autostart-directories gets executed?
 * I chose a simple *.sh regex for testing purposes.
 * In KSMServer and KDE4 only obvious backup files (*.bak, *~, %*% etc.) were 
excluded.


Diffs
-

  src/klauncher/autostart.cpp 0706c735c3caf1c010d9968337456bfc5a0805c1 

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


Testing
---

Works for scripts that exit and those that run the whole session. Now the only 
limitation is the *.sh wildcard.


Thanks,

Martin Yrjölä

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

Re: Review Request 119773: Launch scripts in autostart-directories

[Martin Yrjölä]

> On Aug. 19, 2014, 6:41 a.m., David Faure wrote:
> > In the KF5 world even more so than before, all the autostart code should be 
> > in workspace rather than in kinit. This is really a workspace feature, 
> > starting a single app based on KF5 doesn't and shouldn't start anything.
> > 
> > kioclient5 exec is an unnecessary indirection, given that we have proper 
> > APIs for doing this in KIO. kioclient5 exec is nothing else than
> > 
> > KRun * run = new KRun(QUrl::fromLocalFile(path), Q_NULLPTR);
> > run->setRunExecutables(true);
> > 
> > Which kind of file --> I'm not sure. I'm confused by the older commit you 
> > point to, I missed that discussion.
> > Anyway I thought the XDG autostart directory was specified to only contain 
> > .desktop files? 
> > http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html
> > 
> > This being said, I wouldn't mind being able to add scripts without having 
> > to write a .desktop file for them I can bring this up on the xdg list 
> > maybe?

I didn't realise only desktop-files are part of the autostart standard. This 
problem could also be solved by having the "Add script"-button in the Autostart 
KCM generate a desktop file for the added script. The downside would be that 
console users still have to write their own desktop-files. But I think you're 
right that kinit is probably not the best place for this functionality.

I can continue the discussion in plasma-devel, there's already a thread for 
this.

I'll close this review request.


- Martin


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


On Aug. 13, 2014, 7:50 p.m., Martin Yrjölä wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119773/
> ---
> 
> (Updated Aug. 13, 2014, 7:50 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 335878 and 338242
> https://bugs.kde.org/show_bug.cgi?id=335878
> https://bugs.kde.org/show_bug.cgi?id=338242
> 
> 
> Repository: kinit
> 
> 
> Description
> ---
> 
> This fixes execution of scripts other than ".desktop"-files in the 
> ~/.config/autostart directory when starting a session. This functionality was 
> removed in https://git.reviewboard.kde.org/r/118977/ because of 
> https://bugs.kde.org/show_bug.cgi?id=335878.
> 
> Things that still have to be discussed:
> * Is kinit the right place for this functionality? I think it makes sense 
> because all other autostart functionality is there.
> * Is kioclient5 the correct way to start the scripts?
> * Which kind of files in autostart-directories gets executed?
>  * I chose a simple *.sh regex for testing purposes.
>  * In KSMServer and KDE4 only obvious backup files (*.bak, *~, %*% etc.) were 
> excluded.
> 
> 
> Diffs
> -
> 
>   src/klauncher/autostart.cpp 0706c735c3caf1c010d9968337456bfc5a0805c1 
> 
> Diff: https://git.reviewboard.kde.org/r/119773/diff/
> 
> 
> Testing
> ---
> 
> Works for scripts that exit and those that run the whole session. Now the 
> only limitation is the *.sh wildcard.
> 
> 
> Thanks,
> 
> Martin Yrjölä
> 
>

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

Re: How to promote less mature Frameworks?

[Kevin Ottens]

On Tuesday 19 August 2014 08:44:10 David Faure wrote:
> On Friday 15 August 2014 12:51:58 Kevin Ottens wrote:
> > And that's the problem if we release them. If it's released "with the
> > rest" expect people to have wrong expectations about them.
> > 
> > A possibility would be perhaps to produce nightly tarballs for those
> > frameworks which don't have the "release: true" flag. This way they keep
> > not being part of a release, and early adopters have something easy to
> > grab.
>
> Wouldn't early adopters just checkout and build from git ?

Well, I guess some of them might just want to grab something and run with it. 
Maybe not the majority indeed...

> I don't know about you, but I almost never download a source tarball,
> because a git checkout is just so much easier to update later.
> We mostly make tarballs for packagers, and the non-mature frameworks we're
> talking about should definitely NOT be packaged.

Agreed.

> IMHO the solution is just to publicize the upcoming frameworks somewhere.

Which shouldn't be that hard, it's "only" about processing the yaml file and 
creating a page listing them. I think that's what makes most sense indeed.

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: Proposal to improving KDE Software Repository Organization

[Ben Cooksley]

On Tue, Aug 19, 2014 at 6:55 PM, David Faure  wrote:
> Nice work.

Thanks.

>
> Just one thing:
>
> On Monday 18 August 2014 21:54:40 Michael Pyne wrote:
>>   So "kf5-qt5" might mean "KF5/Devel, Plasma5/Devel, etc." while
>>   "kf5-qt5-stable" might mean "KF5/Devel, Plasma5/Stable, etc.".
>
> This looks like an attempt to keep the current branch-group naming for
> compatibility and ease of transition. But I fear it makes things harder to
> understand in the longer term.

It is for compatibility - yes.
The old kf5-qt5 / latest-qt4 names are being mapped to division /
track combinations. They are otherwise not used.

> Would who guess that kf5-qt5 means plasma devel, since the name says nothing
> about plasma?
>
> I think the concept works, but the actual naming of the divisions should be
> improved, even if it means we need to update our kdesrc-buildrc files (or some
> compat code maps from old names to new names).
>
> Plasma5Devel-KF5 and Plasma5Stable-KF5 would already be better names for the
> divisions  but then what happens with apps on top? :)

Each application grouping would have it's own division.

Just a clarification though: there would only be two divisions for the
above scenario: Plasma5 and KF5.
Plasma5 would then have two tracks: stable and devel. KF5 would have
it's single track.

> I guess the divisions will include apps in the same state as plasma?
> So this is really AppsAndPlasmaDevel-KF5 and AppsAndPlasmaStable-KF5,
> both quite unreadable :)
> (Just Devel-KF5 and Stable-KF5 would make one thing the adjective applies to
> KF5, so no go)
>
> Sorry for starting a naming bikeshed, but I fear that the divison concept
> won't work out well if we can't find proper names for the "divisions", because
> then people will keep getting confused about what's in them.

KF5 will have the frameworks in it.
Plasma5 will have those repositories which form part of the Plasma 5
workspace, and are released as "Plasma 5".
Everything else will go in other divisions.

KDevelop for instance would probably have it's own division. As would
Calligra, even though it is only one repository. I imagine PIM would
have it's own as well (covering kdepim and kdepim-runtime).

How the current generation modules group themselves as divisions would
be up to them ultimately.

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

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