Re: KDE review for KWeatherCore

2021-01-06 Thread hanyoung
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



Re: KDE review for KWeatherCore

2020-12-31 Thread hanyoung
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


KDE review for KWeatherCore

2020-12-21 Thread 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 extracting weather data fetching code from 
KWeather.
I think having a dedicated weather library can serve the following propose:
- simplify the KWeather code
- easier to develop a weather daemon
- potentially less code duplication across KDE

Many of you may have already seen my previous email to kde-devel mailing list.
Thank you for your constructive suggestions. Here are something I want to 
clarify:

> I would also propose to consider doing a demon instead, so different
> programs/processes all interested in weather forecast data could share the
> data
  The end goal is a daemon indeed, but we want to build the daemon upon the 
library. This would give us flexibility
 in the future if we don't want a daemon. At least KWeather and other projects 
can still benefit from the code.

> but we want to make sure we don't end up with two things.
  I admit there are some overlapped functionalities. But KWeatherCore isn't 
designed as a weather data provider as Weather DataEngine.
  Instead, it's trying to be the building block of weather related 
applications. KWeatherCore saves you the hassle of
  dealing with APIs, getting locations and converting timezone. You can build a 
daemon with it, or you can
  use it in your applications. For example, KItinerary and KWeather use the 
same weather API, but don't share code.
  That means two code base to maintain. Regarding the dynamic nature of online 
APIs, it's better to have one library,
  so other applications don't need to be worried about their APIs being 
depraved, and they aren't able to update it in time.

  Though not currently implemented, KWeatherCore does intend to have weather 
alerts added. We hope it can be done in this Sok
  https://community.kde.org/SoK/Ideas/2021#KWeather
  With this bit added, then the work on weather daemon can be started.

Regards,
Han Young



Re: T13975: Move hanyoung/libkweather to frameworks/kweathercore

2020-12-20 Thread hanyoung
Sorry I thought I need to get it moved to frameworks first then KDE review. 
I'll request for KDE review then beta release first. Sorry for the disturbance.

Regards,
Han Young