Adding further modules to api.kde.org

Hi all, back in KDE4 days the workspace libraries were listed on api.kde.org [1]. But for the current version we don't have any API docs available. The section "Other KDE Software" [2] lists KDE Support, KDE Extragear and Playground but apparently nothing from what used to be KDE SC. Does

Re: Moving KDE Connect out of playground

+1 here too. On Thu, Sep 10, 2015 at 3:39 AM, Albert Vaca wrote: > +kde-core-devel > > Hi, > > With the latest changes we are making to KDE Connect as part of the sprint > in Randa, I think that the project is becoming mature enough to be moved out > of playground. Not only

Re: Adding further modules to api.kde.org

Martin, I took a look at this as part of the gardening documentation websites, but I didn't get very far. The code that runs this and ebn is in kde:websites/quality-kde-org and is pretty outdated unfortunately. Actually now that Allen Winter is back maybe he could add it (Added him to cc)? What I

Re: Moving KDE Connect out of playground

On Thursday 10 of September 2015 02:33:55 Albert Vaca wrote: > +kde-core-devel > > Hi, > > With the latest changes we are making to KDE Connect as part of the sprint > in Randa, I think that the project is becoming mature enough to be moved > out of playground. Not only that, but Kubuntu and

Re: Adding further modules to api.kde.org

On Thursday 10 September 2015 06:07:40 Jeremy Whiting wrote: > It would be awesome to have what used to be in KDE SC on api.kde.org > again. We have many libraries that aren't frameworks that are Qt5/KF5 > based which would be good to show on there imo. Perhaps half of this is figuring out what

Re: Adding further modules to api.kde.org

Well, it's not even just about workspace, we had in kde4 times kdeedu, kdegames, etc. etc. all on api.kde.org. Not all of it was api per se (I don't know anyone that would want to read the apidocs for kanagram for example, except to know how it's internals work or used to work when hacking on it).

Re: Moving KDE Connect out of playground

+kde-core-devel Hi, With the latest changes we are making to KDE Connect as part of the sprint in Randa, I think that the project is becoming mature enough to be moved out of playground. Not only that, but Kubuntu and other distros are already installing KDE Connect by default, regardless of it

Re: Review Request 125097: Icons for hiding/unhiding files

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125097/#review85127 --- Please add andreask as reviewer, so that we get these icons

Re: Review Request 125097: Icons for hiding/unhiding files

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125097/#review85144 --- hi, we have hint

folder icons where should they be set

salut mes amis so this popped up https://bugs.kde.org/show_bug.cgi?id=352498 and GTK/Gnome rather seems to set the folder icon as part of their folder-display-component sort of thing (e.g. file open as well as file browsers and what not). it does so however *without* creating a .directory file

Re: RFC: Enabling -DECM_ENABLE_SANITIZERS='address' in jenkins

El Dijous, 10 de setembre de 2015, a les 18:20:19, Lamarque Souza va escriure: > I agree but there is a problem: it can catch a lot of errors in our > dependency libraries (upstream bugs). No, it can not, asan works only on code you have compiled with asan enabled (which for most of our

Re: Review Request 125097: Icons for hiding/unhiding files

> On Sept. 10, 2015, 9:29 p.m., andreas kainz wrote: > > hi, we have > > hint https://dl.dropboxusercontent.com/u/1642456/VDG/KF5/hint.svg and > > visibility > > https://dl.dropboxusercontent.com/u/1642456/VDG/KF5/visibility.svg > > in the kde:breeze Plasma/5.4 brunch and on 13.09. in master.

Re: Review Request 125097: Icons for hiding/unhiding files

> On Sept. 10, 2015, 11:29 p.m., andreas kainz wrote: > > hi, we have > > hint https://dl.dropboxusercontent.com/u/1642456/VDG/KF5/hint.svg and > > visibility > > https://dl.dropboxusercontent.com/u/1642456/VDG/KF5/visibility.svg > > in the kde:breeze Plasma/5.4 brunch and on 13.09. in master.

Re: Adding further modules to api.kde.org

On Thursday, September 10, 2015 01:55:21 PM Jeremy Whiting wrote: > Allen, > > Those are both KDE4 versions of workspace stuff. I don't see any place > where kf5 versions are. > oh. sorry I misunderstood the problem. > > On Thu, Sep 10, 2015 at 1:50 PM, Allen Winter wrote: >

Re: Adding further modules to api.kde.org

On Thursday, September 10, 2015 10:57:10 AM Martin Graesslin wrote: > Hi all, > > back in KDE4 days the workspace libraries were listed on api.kde.org [1]. But > for the current version we don't have any API docs available. The section > "Other KDE Software" [2] lists KDE Support, KDE Extragear

Re: Adding further modules to api.kde.org

Allen, Those are both KDE4 versions of workspace stuff. I don't see any place where kf5 versions are. BR, Jeremy On Thu, Sep 10, 2015 at 1:50 PM, Allen Winter wrote: > On Thursday, September 10, 2015 10:57:10 AM Martin Graesslin wrote: >> Hi all, >> >> back in KDE4 days the

Re: Moving KDE Connect out of playground

On Thu, Sep 10, 2015 at 2:20 PM, Luigi Toscano wrote: > On Thursday 10 of September 2015 02:33:55 Albert Vaca wrote: >> +kde-core-devel >> >> Hi, >> >> With the latest changes we are making to KDE Connect as part of the sprint >> in Randa, I think that the project is

RFC: Enabling -DECM_ENABLE_SANITIZERS='address' in jenkins

We have this nice ECM module that gives us the option to compile with ASAN. I'd like to propose that we enable it by default in jenkins. This way we get all the autotests run with ASAN and potentially catch more bugs/regressions. Comments? Cheers, Albert

Re: Porting to frameworks 3: Krfb

If anyone using kde-telepathy is interested I just reenabled the ktp support in krfb frameworks branch (but I haven't set up ktp locally yet to test). BR, Jeremy On Sun, Sep 6, 2015 at 3:39 PM, Jeremy Whiting wrote: > Ah, another note. Sysadmin kindly created a phabricator

Re: RFC: Enabling -DECM_ENABLE_SANITIZERS='address' in jenkins

I agree but there is a problem: it can catch a lot of errors in our dependency libraries (upstream bugs). I had this problem when I used it with a program I develop at my work. Enabling it for all programs at once and fixing all those upstream bugs can be overwhelming. Maybe we should do it for a