Re: KF5 Update Meeting Minutes 2014-w28
On Thursday 10 July 2014 07:41:31 Marko Käning wrote:
> Most support I need re QStandardPaths and I would be stealing some Unix code
> from QStandardPaths::writableLocation() to be found in
> qstandardpaths_unix.cpp where XDG is being used to determine the
> environment of the system the Qt5 program runs on, using qgetenv() like
> e.g. this:
> ---
> QString xdgCacheHome = QFile::decodeName(qgetenv("XDG_CACHE_HOME"));
> ---
> Since the CI system - of course - makes use of these XDG environment
> variables during the test of every framework and application installed, it
> would be great if all these environment vars would be given to the CI
> system by a patched qt5 as well. I am working on it and will post a RR once
> I’ve got something working.
Wrong approach. XDG is a freedesktop thing which doesn't apply to Mac.
This should be fixed the other way around:
1) finding out how Mac OS lets people configure the location for their files,
or if this isn't configurable, coming up with QT_* environment variables.
2) patching QStandardPaths to use these
3) setting these vars in the CT scripts
--
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: KF5 Update Meeting Minutes 2014-w28
Hi Kevin,
On 10 Jul 2014, at 07:12 , Kevin Ottens wrote:
> See, I was unsure if you were painfully doing that by hand or if you had some
> machine you delegated the work to. :-)
well, all manually done up to now. ;)
> But that definitely confirm we should do something to help you there so that
> you can focus on others tasks than running build and sending failures by hand.
Yes, that would be a big step forward and I do appreciate all the help I got
so far already.
Most support I need re QStandardPaths and I would be stealing some Unix code
from QStandardPaths::writableLocation() to be found in qstandardpaths_unix.cpp
where XDG is being used to determine the environment of the system the Qt5
program runs on, using qgetenv() like e.g. this:
---
QString xdgCacheHome = QFile::decodeName(qgetenv("XDG_CACHE_HOME"));
---
Since the CI system - of course - makes use of these XDG environment variables
during the test of every framework and application installed, it would be great
if all these environment vars would be given to the CI system by a patched qt5
as well. I am working on it and will post a RR once I’ve got something working.
> And your work is very appreciated. Helped catch a really bad issue already.
> Keep it coming! ;-)
Thanks for the flowers. :)
(Well, that was close, just moments before the release.)
> I would agree with Albert here, you get a higher chance of growth by trying
> to
> attract current OSX users, there's not many of them in KDE. There was a few,
> but they moved on with their lives.
Some have moved back to Linux. ;)
Greets,
Marko
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
On Wednesday 09 July 2014 22:24:20 Marko Käning wrote: > Hi, > > On 09 Jul 2014, at 07:14 , Kevin Ottens wrote: > > On Wednesday 09 July 2014 09:57:27 Ben Cooksley wrote: > >>> * finally he thinks we need to strengthen our CI system and tests to > >>> raise the bar on quality. > >> > >> Expand on strengthen please? > > > > Sure, for the CI side what I have in mind is mostly about supporting more > > platforms (at least windows, mac and android as mentioned earlier) with > > all > > the results in the same dashboard (currently the mac results come from > > "somewhere"). > > this “somewhere” is currently only me, personally, not ‘a’ OSX/CI system. :) See, I was unsure if you were painfully doing that by hand or if you had some machine you delegated the work to. :-) But that definitely confirm we should do something to help you there so that you can focus on others tasks than running build and sending failures by hand. > I am very thankful for all the help I get from you guys on this list! And your work is very appreciated. Helped catch a really bad issue already. Keep it coming! ;-) > Still hoping that some day someone will join the rather small OSX CI team… > ;) I would agree with Albert here, you get a higher chance of growth by trying to attract current OSX users, there's not many of them in KDE. There was a few, but they moved on with their lives. 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: KF5 Update Meeting Minutes 2014-w28
Hi Albert, On 09 Jul 2014, at 22:33 , Albert Astals Cid wrote: > I think not much of us use/has OSX, so it may be easier if you look in the > OSX > side of the world to get them closer to us than in the KDE side of the world > to get them closer to OSX. I know and we do advertise on KDE-MAC and MACPORTS-DEVEL! :) > Keep up the good work :) Thanks, Marko 8-) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
El Dimecres, 9 de juliol de 2014, a les 22:24:20, Marko Käning va escriure: > Hi, > > On 09 Jul 2014, at 07:14 , Kevin Ottens wrote: > > On Wednesday 09 July 2014 09:57:27 Ben Cooksley wrote: > >>> * finally he thinks we need to strengthen our CI system and tests to > >>> raise the bar on quality. > >> > >> Expand on strengthen please? > > > > Sure, for the CI side what I have in mind is mostly about supporting more > > platforms (at least windows, mac and android as mentioned earlier) with > > all > > the results in the same dashboard (currently the mac results come from > > "somewhere"). > > this “somewhere” is currently only me, personally, not ‘a’ OSX/CI system. :) > > I am very thankful for all the help I get from you guys on this list! > > Still hoping that some day someone will join the rather small OSX CI team… > ;) I think not much of us use/has OSX, so it may be easier if you look in the OSX side of the world to get them closer to us than in the KDE side of the world to get them closer to OSX. Keep up the good work :) Cheers, Albert > > Greets, > Marko ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
Hi, On 09 Jul 2014, at 07:14 , Kevin Ottens wrote: > On Wednesday 09 July 2014 09:57:27 Ben Cooksley wrote: >>> * finally he thinks we need to strengthen our CI system and tests to >>> raise the bar on quality. >> >> Expand on strengthen please? > > Sure, for the CI side what I have in mind is mostly about supporting more > platforms (at least windows, mac and android as mentioned earlier) with all > the results in the same dashboard (currently the mac results come from > "somewhere"). this “somewhere” is currently only me, personally, not ‘a’ OSX/CI system. :) I am very thankful for all the help I get from you guys on this list! Still hoping that some day someone will join the rather small OSX CI team… ;) Greets, Marko signature.asc Description: Message signed with OpenPGP using GPGMail ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
On 9 July 2014 06:14, Kevin Ottens wrote: > Hello, > > On Wednesday 09 July 2014 09:57:27 Ben Cooksley wrote: >> On 9 July 2014 03:30, Kevin Ottens wrote: >> > * ervin hopes to see kdepimlibs bits getting in sooner rather than later; >> >> Hmm? Sysadmin has already received a request to get the frameworks >> branch of kdepimlibs building on the CI system to allow for KMyMoney's >> frameworks branch to be built. I thought this was already underway? > > There's work underway of course. Laurent is very instrumental there. But > there's still a long way to go AFAIK. Having a branch that builds is a first > step, but then splitting the repository will be necessary, figuring out which > parts of kdepim-runtime will go with which part of kdepimlibs, organizing the > splitted repositories so that they follow the existing policies, etc. > > It's pretty much the kdelibs/kde-runtime work again, it shouldn't be > underestimated. I've had clarification from Montel, and indeed the schedule has been moved up due to there being no 4.15, so now after 4.14 in say September/October time frame. We have a PIM Sprint planned for November in Munich when I guess the Frameworks planning will be the main focus. The Frameworks branch does build, has many build fixes applied to it for KF5 and gets regular merges from master. However we're still doing new features and bug fixes in kdepimlibs as needed for improvements to the apps, hence the reluctance to split it off before necessary. I think many of the libs are already fairly standalone, but others will need considerable restructuring. A few like KHolidays could be split off and released almost immediately, others will take much longer. The really big hurdle for pimlibs will be removing KDateTime/KTimeZone/KLocale usage which is substantial work. There's some initial work towards the split at [1]. Cheers! John. [1] https://community.kde.org/Frameworks/Epics/kdepimlibs ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
On 9 July 2014 17:14, Kevin Ottens wrote: > Hello, Hi Kevin, > > On Wednesday 09 July 2014 09:57:27 Ben Cooksley wrote: >> On 9 July 2014 03:30, Kevin Ottens wrote: >> > * ervin hopes to see kdepimlibs bits getting in sooner rather than later; >> >> Hmm? Sysadmin has already received a request to get the frameworks >> branch of kdepimlibs building on the CI system to allow for KMyMoney's >> frameworks branch to be built. I thought this was already underway? > > There's work underway of course. Laurent is very instrumental there. But > there's still a long way to go AFAIK. Having a branch that builds is a first > step, but then splitting the repository will be necessary, figuring out which > parts of kdepim-runtime will go with which part of kdepimlibs, organizing the > splitted repositories so that they follow the existing policies, etc. > > It's pretty much the kdelibs/kde-runtime work again, it shouldn't be > underestimated. Ah, oki. I thought you meant it hadn't been started yet, which is why I was confused. > >> > * also he would like our developer story to be clearer, tooling needs to >> > be improved for our different targets (especially third parties); >> > >> > * finally he thinks we need to strengthen our CI system and tests to >> > raise the bar on quality. >> >> Expand on strengthen please? > > Sure, for the CI side what I have in mind is mostly about supporting more > platforms (at least windows, mac and android as mentioned earlier) with all > the results in the same dashboard (currently the mac results come from > "somewhere"). For the tests side, it is about getting way more tests > introduced, we might also want to start looking at the coverage data (although > the CI might be the bottleneck there). Coverage data shouldn't be too much of a problem - at least for Linux. I've no idea what happens on other platforms though. The primary constraints here are the size of the repository, and the latency to the build master (currently hosted on one of our Hetzner servers). Presenting it in the same dashboard is basically blocked only by getting our configuration made declarative for Jenkins. Once that is done we can begin adding build nodes for the respective platforms without too much problem, at least on the Jenkins side. I expect the CI scripts will also need adapting. Some parts of the configuration are already duplicative, and other parts have proved problematic for both early experiments on Windows and OS X. I'm also aware that Windows has path length restrictions which we'll need to keep in mind and may necessitate changes in how we currently store builds. One major stumbling block at the moment is QStandardPaths - which doesn't support environment variables of any description on Windows or OSX. This needs to be fixed, or a different approach taken to how the CI system handles builds. Help with the three above items would be appreciated. I'd like more details on how an Android setup would work - would this be a x86 or ARM based? For ARM we'd need to either emulate and virtualise or have physical hardware... > > Hope that clarifies. It certainly does. > > Regards. > -- > Kévin Ottens, http://ervin.ipsquad.net > > KDAB - proud supporter of KDE, http://www.kdab.com > Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
Hello, On Wednesday 09 July 2014 09:57:27 Ben Cooksley wrote: > On 9 July 2014 03:30, Kevin Ottens wrote: > > * ervin hopes to see kdepimlibs bits getting in sooner rather than later; > > Hmm? Sysadmin has already received a request to get the frameworks > branch of kdepimlibs building on the CI system to allow for KMyMoney's > frameworks branch to be built. I thought this was already underway? There's work underway of course. Laurent is very instrumental there. But there's still a long way to go AFAIK. Having a branch that builds is a first step, but then splitting the repository will be necessary, figuring out which parts of kdepim-runtime will go with which part of kdepimlibs, organizing the splitted repositories so that they follow the existing policies, etc. It's pretty much the kdelibs/kde-runtime work again, it shouldn't be underestimated. > > * also he would like our developer story to be clearer, tooling needs to > > be improved for our different targets (especially third parties); > > > > * finally he thinks we need to strengthen our CI system and tests to > > raise the bar on quality. > > Expand on strengthen please? Sure, for the CI side what I have in mind is mostly about supporting more platforms (at least windows, mac and android as mentioned earlier) with all the results in the same dashboard (currently the mac results come from "somewhere"). For the tests side, it is about getting way more tests introduced, we might also want to start looking at the coverage data (although the CI might be the bottleneck there). Hope that clarifies. 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: KF5 Update Meeting Minutes 2014-w28
On 9 July 2014 03:30, Kevin Ottens wrote: > Hello everyone, Hi Kevin, > > This is the minutes of the Week 28 KF5 meeting. As usual it has been held on > #kde-devel at 4pm Paris time. > > Were present: agateau, apol, d_ed, dfaure, fregl, mgraesslin, notmart, > PovAddict, Riddell, sandsmark, tosky, unormal, vHanda and myself. > > Announcements: > * KF 5.0 got officially released yesterday! > * As announced this meeting is more forward looking than reporting, > especially useful would be: features you want to see appear, and areas for > improvements you see; > * It will be our last regular meeting for the time being, we can move to flow > base without trying to set a strict deadline now (as release and development > is mostly decoupled); > > * agateau would like to see the ColumnResizer class get out of review limbo > (probably didn't have enough energy to get it in Qt, would happily push it to > kwidgetsaddons); > > * apol would like us to figure out how we expect people to develop on apps > with KF5; > * we need to ensure the tooling is there and that it's easy to get started; > * he's also like to see the android port progress, in particular he got no > answer about getting a file in ECM to that effect; > > * d_ed has two models he wants to get into kf5 at some point (one similar to > KCategoryModel, allowing a row in two categories, the other one merges two > list models together); > * also he'd like the framework integration to be cleaned up and to sync > itself with breeze's settings; > > * dfaure plans to complete the startup notification in kdbusservice; > * he also plans to replace sycoca; > * he also wants to figure out what to do with libkonq; > > * fregl wants to see more focus on a11y; > * he notes it will require being able to operate plasma based code with the > keyboard; > > * mgraesslin would like windows and macos support effective in KWindowSystem; > * he plans wayland support in kwindowsystem too; > * he'd also like the runtime component of kglobalaccel back in the framework > itself; > > * notmart would welcome a git hook to make sure all commits are reviewed; > * he's not sold on the no branches policy, actually plasma-framework seeing > heavy work he pushed feature branches already (said policy isn't written > anywhere BTW); > * for the upcoming versions he wants the runtime part of plasma-framework to > converge as much as possible the plasma components and the qt controls; > * there's interest to move Package out of plasma-framework, a solution should > be devised; > > * PovAddict is working on a single-app installer for windows: >http://i.imgur.com/zokLHVe.png ; > * he'd like our documentation to improve, we're really behind alternatives in > that regard; > > * Riddell would like kauth/polkit fixed; > * he'd like the kwallet migrator done ASAP; > * he'd also like kdesudo next to kdesu; > * finally, he pointed out that the schedule was missing the string freezes; > > * sandsmark wants to get to grammar checking in sonnet; > * he's also like to get auto-correct in sonnet; > > * tosky would like to see more tests; > * he'd also want more work on some of the i18n components; > > * unormal is looking forward to more mac CI results; > * the windows CI is a bit stuck; > * he'd like to see progress on the android CI; > * he'd like to see a donation button in KDE apps based on KF5 (developers > could opt-out); > * he's thinking we should ask third party developers if they want to send us > some information when they use a framework to create an app; > > * vHanda would like kfilemetadata to make it into a framework; > * he'd also like to turn baloo into a framework; > * finally he'd like gestures in kglobalaccel; > > * ervin hopes to see kdepimlibs bits getting in sooner rather than later; Hmm? Sysadmin has already received a request to get the frameworks branch of kdepimlibs building on the CI system to allow for KMyMoney's frameworks branch to be built. I thought this was already underway? > * also he would like our developer story to be clearer, tooling needs to be > improved for our different targets (especially third parties); > * finally he thinks we need to strengthen our CI system and tests to raise > the bar on quality. Expand on strengthen please? > > If you got questions, feel free to ask. > > Regards. Thanks, Ben > -- > Kévin Ottens, http://ervin.ipsquad.net > > KDAB - proud supporter of KDE, http://www.kdab.com > > > ___ > 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: KF5 Update Meeting Minutes 2014-w28
On 9 July 2014 04:05, Mario Fux wrote: > Am Dienstag, 08. Juli 2014, 17.30:19 schrieb Kevin Ottens: >> Hello everyone, > > Morning Hi Mario, > >> This is the minutes of the Week 28 KF5 meeting. As usual it has been held >> on #kde-devel at 4pm Paris time. > > [snip] > >> * unormal is looking forward to more mac CI results; >> * the windows CI is a bit stuck; >> * he'd like to see progress on the android CI; How exactly has the Windows CI gotten stuck? I'm aware that while our scripts are portable the environment they rely upon does tend to be quite hostile - especially due to weaknesses in the non-X11 parts of Qt. It also seems that we may need to shift to some form of declarative configuration rather than the current INI based setup we have at the moment. (To be able to accommodate the various other differences in platforms I did not anticipate) As a note to all those interested in having various types of builds being run, we're going to need to shift towards a different method of configuring Jenkins. The current method isn't sustainable i'm afraid. We're essentially copying jobs to configure the system at the moment. Adding other platforms will require using Multi-Configuration jobs, which means we have to reconfigure from scratch. Two solutions i've found are http://ci.openstack.org/jenkins-job-builder/builders.html#builders and https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin Help moving the system configuration towards a setup such as one of the two above would be appreciated. >> * he'd like to see a donation button in KDE apps based on KF5 (developers >> could opt-out); >> * he's thinking we should ask third party developers if they want to send >> us some information when they use a framework to create an app; > > There was a small misunderstanding (probably based on my fatigue brain atm). > Of course this interpretation would be nice as well I meant apps based on KF5 > and to get a channel to our users. Two way: > - Get to them if we need (financial) support or want to tell them about new > version or other stuff > - They send us automatically and agreed upon data about their use of our apps. > > [snip] > > griits > Mario Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
Am Dienstag, 08. Juli 2014, 19.27:52 schrieb John Layt: Morning John [snip] > > * he'd like to see a donation button in KDE apps based on KF5 > > (developers > > > > could opt-out); > > We already have a link to the donations page buried deep in the "About > KDE" dialog under the "Support KDE" tab where no-one ever sees it. A Indeed there is something ;-). > Help menu item for "Donate to KDE..." that pops up a dialog explaining > why would be far more visible, but easily disabled by distros who So what? It's still free software so everybody can patch it away. But we can present it prominently and try and see if it helps. And I mainly think about KDE apps on Windows, Mac and Android when I want to see this donate button as we're the distributors there ourselves. But it's exactly what I meant: A "Donate to KDE..." menu item under the Help menu. > object. We could also include a "Donate to KDE" tip in every > KTipDatabase and ensure it's the first tip shown by default on an apps > first run. As an admin note, whenever we do add a donate link > anywhere we should make it unique so that we can track how successful > each channel is. +1 > > * ervin hopes to see kdepimlibs bits getting in sooner rather than > > later; > > I asked on the PIM list the other day, Montel says the plan is not to > start on frameworks until after 4.15, so maybe March/April next year? There won't be a 4.15 and I talked with Montel about this. > I think he meant porting the PIM applications though, so I'm not sure > what that means for starting on pimlibs. I'll follow up. > > > My plans: > * Write proper docs for KUnitConversion > * Make KUnitConversion Tier 1 by switching to Qt translations > * In advanced planning for replacements for ISO codes and flag images, > even have some code, see > https://community.kde.org/KDE_Core/KDE_Open_Data > ** OpenCodes: repo of json files of ISO data auto-extracted from > Wikidata, CC-0, can be used by anyone > ** KCodes: Qt library which loads OpenCodes files > ** OpenFlags: repo of SVG flag images auto-extracted from Wikidata, > with icon set auto-generated from SVGs Very interesting stuff! > Here's a bit of bike-shedding for you: when creating completely new > Frameworks in Tier 1, do we name them with a Q or with a K or with > something completely neutral? > > Cheers! > > John. Thx Mario ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
On Tue, 8 Jul 2014, John Layt wrote: We already have a link to the donations page buried deep in the "About KDE" dialog under the "Support KDE" tab where no-one ever sees it. A Help menu item for "Donate to KDE..." that pops up a dialog explaining why would be far more visible, but easily disabled by distros who object. We could also include a "Donate to KDE" tip in every KTipDatabase and ensure it's the first tip shown by default on an apps first run. As an admin note, whenever we do add a donate link anywhere we should make it unique so that we can track how successful each channel is. As a datapoint, and not something most apps will want to do... Adding a splash screen with a donation link to the development build of Krita meant getting three out-of-the-blue donations a week more than the zero I had before. No huge numbers, but then, Krita still is small compared to other apps. Boud ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
On Tuesday 08 July 2014 18:27:52 John Layt wrote: > Here's a bit of bike-shedding for you: when creating completely new > Frameworks in Tier 1, do we name them with a Q or with a K or with > something completely neutral? Not really a bike-shedding topic hopefully... We had the case already and we used K. 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: KF5 Update Meeting Minutes 2014-w28
On Tuesday 08 July 2014 17:30:19 Kevin Ottens wrote: > * he's also like to see the android port progress, in particular he got no > answer about getting a file in ECM to that effect; Sorry, life's a bit crazy at the mo. Will try to look at soon. Although I'd appreciate the input of anyone else with android development experience. My plans: * more tests for ECM * work on rewriting/cleaning up image format handlers * get the remaining KImageIO methods into QImageReader/Writer I also second the "better docs" call. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
On 8 July 2014 16:30, Kevin Ottens wrote: > * he'd like our documentation to improve, we're really behind alternatives in > that regard; Seconded, especially from the point-of-view of external devs. For example, someone today was asking about KArchive and whether it was fully standalone or depended on external libs that they needed to ship on non-Linux platforms, but the apidocs don't mention the dependencies anywhere. We need to document every single library from the point of view of someone completely new to KDE who just wants one single library in their Qt app. Do we have a single home page or landing point that we want all potential users to start from? Do we have general docs to point to about build chain, licences, getting help, etc? We have the community wiki but it is not meant to be for that purpose, and the apidox main page may be too static to keep up with FAQs, so we probably need to create some TechBase pages. Actually, TechBase is really going to need a big review. > * he'd like to see a donation button in KDE apps based on KF5 (developers > could opt-out); We already have a link to the donations page buried deep in the "About KDE" dialog under the "Support KDE" tab where no-one ever sees it. A Help menu item for "Donate to KDE..." that pops up a dialog explaining why would be far more visible, but easily disabled by distros who object. We could also include a "Donate to KDE" tip in every KTipDatabase and ensure it's the first tip shown by default on an apps first run. As an admin note, whenever we do add a donate link anywhere we should make it unique so that we can track how successful each channel is. > * ervin hopes to see kdepimlibs bits getting in sooner rather than later; I asked on the PIM list the other day, Montel says the plan is not to start on frameworks until after 4.15, so maybe March/April next year? I think he meant porting the PIM applications though, so I'm not sure what that means for starting on pimlibs. I'll follow up. My plans: * Write proper docs for KUnitConversion * Make KUnitConversion Tier 1 by switching to Qt translations * In advanced planning for replacements for ISO codes and flag images, even have some code, see https://community.kde.org/KDE_Core/KDE_Open_Data ** OpenCodes: repo of json files of ISO data auto-extracted from Wikidata, CC-0, can be used by anyone ** KCodes: Qt library which loads OpenCodes files ** OpenFlags: repo of SVG flag images auto-extracted from Wikidata, with icon set auto-generated from SVGs Here's a bit of bike-shedding for you: when creating completely new Frameworks in Tier 1, do we name them with a Q or with a K or with something completely neutral? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
> * he's not sold on the no branches policy, actually plasma-framework seeing > heavy work he pushed feature branches already (said policy isn't written > anywhere BTW); I've quite confused on this. Whyever would you not want feature branches? Jonathan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w28
Am Dienstag, 08. Juli 2014, 17.30:19 schrieb Kevin Ottens: > Hello everyone, Morning > This is the minutes of the Week 28 KF5 meeting. As usual it has been held > on #kde-devel at 4pm Paris time. [snip] > * unormal is looking forward to more mac CI results; > * the windows CI is a bit stuck; > * he'd like to see progress on the android CI; > * he'd like to see a donation button in KDE apps based on KF5 (developers > could opt-out); > * he's thinking we should ask third party developers if they want to send > us some information when they use a framework to create an app; There was a small misunderstanding (probably based on my fatigue brain atm). Of course this interpretation would be nice as well I meant apps based on KF5 and to get a channel to our users. Two way: - Get to them if we need (financial) support or want to tell them about new version or other stuff - They send us automatically and agreed upon data about their use of our apps. [snip] griits Mario ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
