(Added Han Young as BCC: based on code email address, as the task is not public, and not sure you are subscribed to the mailinglists)
Am Sonntag, 20. Dezember 2020, 12:05:46 CET schrieb David Edmundson: > Please see https://community.kde.org/Policies/Application_Lifecycle about > the process of adding things to frameworks. > > As for plasma, we have a weather library there, so the comment about it > being easier for new plasmoids doesn't hold directly. Maybe you can expand > on what's different? David, any chance you misremembered there being a weather library? If you refer to the stuff in plasma-workspace (which then e.g. drives the kde- plasmaaddons weather applet), that is just a DataEngine. As former contributor to the Weather DataEngine in plasma-workspace, and with the DataEngine concept being deprecated, also having seen at least the code copy used in a Marble plugin for overlaying weather reports on the map, having a library instead makes a lot sense. I would have written that myself, just had other things more attractive eating any resources :) I guess Itinerary, KOrganizer and other date/location centric applications might also fancy access to weather forecast info optionally (Itinerary does already with custom code, no?) But I would also recommend first going to "Extragear" (i.e. stand-alone releases) before entering KDE Framewprks, as that means not having to stick to the initial ABI/API from the first release on. Being a new library it's API is candidate for seeing some evolvement based on feedback by API consumers, and not having to bend over to keep compatibility to the initial API can make life easier. It might not be needed, but the option to be agile here allows for a better product. BTW, I would also propose to consider doing a demon instead, so different programs/processes all interested in weather forecast data could share the data, would be also more nice to the weather data providing services to have a single process do optimized calls & caching of the data. Cheers Friedrich
