I've applied the following changes:
* Remove @brief
* DailyWeatherForecast and HourlyWeatherForecast constructor now
take one QDate/QDateTime arguement. The previous "one for all" constructor has
been removed
* various setters now take const reference
* other naming, misc changes
Regards,
Han
Hi Han,
let's have this discussion public on kde-core-devel and kde-framworks,
so other can contribute.
On Sat, Jan 2, 2021 at 1:29 PM hanyoung wrote:
>
> Hi Dominik,
>
> Thank you for your time. This is my first time writing a library, I tried my
> best by looking
> at existing KDE frameworks
On Samstag, 2. Januar 2021 12:44:31 CET Dominik Haumann wrote:
> This is just by looking at the first two header files.
>
> Looking at WeatherForecast.cpp:
>
> double maxTemp = std::numeric_limits::min();
> double minTemp = std::numeric_limits::max();
>
> Initializing the temperature to
Hi Han,
just having a quick glance at the code, and I feel like there is a lot of
polishing
missing. I'll give some examples, but this is by no means a complete review,
and I'll not comment on technical aspects at all, since this is not the
domain
of my expertise.
- #pragma once: It's used in
I've made some changes to KWeatherCore according to the feedback. Namely:
* More Private Classes
* Removed inline functions
* Lowered coordinates resolution
* Listed API services in use on README
* Switched to LGPL
Regards,
Han
On lundi 21 décembre 2020 07:16:09 CET hanyoung wrote:
> KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for
> querying weather forecast data. During the development of KWeather, we
> found the need to have a weather library. KWeatherCore is the result of
> extracting
El dilluns, 21 de desembre de 2020, a les 7:16:09 CET, hanyoung va escriure:
> KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for
> querying weather forecast data.
> During the development of KWeather, we found the need to have a weather
> library.
> KWeatherCore is the
Am Montag, 21. Dezember 2020, 15:45:22 CET schrieb Nicolas Fella:
> On 12/21/20 3:19 PM, Friedrich W. H. Kossebau wrote:
> > My idea/proposal there is that the library internally makes use of that
> > demon. So code which uses KWeatherCore does not need to know that
> > implementation-wise there
On 12/21/20 3:19 PM, Friedrich W. H. Kossebau wrote:
Am Montag, 21. Dezember 2020, 07:16:09 CET schrieb hanyoung:
KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for
querying weather forecast data. During the development of KWeather, we
found the need to have a
Would it be possible for KweatherCore to lean on location services like
Geoclue? (And/if should we be working on a KDE GUI for Geoclue to help with
this? That way Kweather could only be dealing with resolving weather info)
On Sunday, December 20, 2020 10:16:09 PM PST hanyoung wrote:
>
Am Montag, 21. Dezember 2020, 07:16:09 CET schrieb hanyoung:
> KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for
> querying weather forecast data. During the development of KWeather, we
> found the need to have a weather library. KWeatherCore is the result of
>
Having implemented the weather support for Itinerary, rebasing that onto a
more comprehensive framework would indeed be welcome :)
I haven't looked too deeply at the implementation or the API yet, most of the
feedback below is based on things learned when implementing this for
Itinerary.
##
KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for
querying weather forecast data.
During the development of KWeather, we found the need to have a weather library.
KWeatherCore is the result of extracting weather data fetching code from
KWeather.
I think having a
13 matches
Mail list logo
