Restoring weather applet in kdeplasma-addons

[Marco Martin]

On Monday 08 February 2016, Friedrich W. H. Kossebau wrote:
> Am Freitag, 5. Februar 2016, 19:15:29 CET schrieb Marco Martin:
> > On Friday 05 February 2016 18:39:00 Friedrich W. H. Kossebau wrote:
> > > I see. And found it now, plasma-workspace/dataengines/weather. Seems
> 
> it
> 
> > > was started in 2014, but then lost focus of developers. Some "ions"
> > > library is installed, but the dataengine plugin itself is not even
> 
> build.
> 
> > > Will look some more around and see where the loose ends to pick up
> 
> are.
> 
> > i'm finishing the port right now, seems easier then expected :)
> 
> Oh, good, always best to have the expert do things. ;)
> 
> Can confirm the code in master works here as well.
> 
> > so yeah, you would have to take the qml1 weather applet, port to qml2
> > (wouldn't do anything at that point) then hook it up to the dataengine
> 
> and
> 
> > give it a configuration dialog.
> > I can walk you trough the steps
> 
> Being new to both Plasma5 (applet) technologies (only did minor C++
> plasmoids for Plasma4) as well as the weather applet(s) code and logic, I
> tried to learn a little for now by looking into porting the current code
> and its structure.
> 
> So QQ1->QQ2, kdelibs4->KF5 and Plasma->Plasma5, the latter learning-by-
> doing and not all changes yet understood.
> 
> And I did to some first rough success, the weather applet shows up when
> testing with plasmawindowed, and using a hardcoded data source string
> (using Turin :) ) I get correct weather data shown in the applet.

great \o/

> No config support yet, are QWidget-based config dialogs that even still
> supported API-wise?

eh, unfortunately no,because mixing qwidgets and qml in the same application 
is extremely painful :/
so also the cofig dialog has to be qml now...

take a look at other applets, like userswitcher on that repo too.
you need a config/config.xml that says what config keys are "legit", 
a config/config.qml that says what pages there are in the dialog, like 

import org.kde.plasma.configuration 2.0

ConfigModel {
    ConfigCategory {
        name: i18n("General")
        icon: "weather-clear"
        source: "configGeneral.qml"
    }
}

that you'll have ui/configGeneral.qml that is the page you specified there.

every config value you specified in the config.xml will be available for read 
and write as properties in the root item of configGeneral.qml as
cfg_configKEy like cfg_location

and the applet will read them as plasmoid.config.location or whatever the 
config key


> For a start I would not mind first recreating the the QWidget-based
> config, so there is a stable working intermediate state, and I have a
> clear picture about the data flows and logic, before going the
> 
> IIRC the ideal Plasma5 applet is qml-only, right? Not sure yet if all
> current logic would best or could be moved to qml/js.
> That libplasmaweather, as shared between the applets weather and
> weatherstation (no idea about this, never used), has functionality like
> at least:
> * WeatherValidator, for correct input of weather data provider and
> correct input of weather locations supported by the provider

yeah, i've seen that, it may be useful, if you need that 

> * integration with KNewStuff for weather data providers
>  (though currently bound to private and no longer existing
> http://www.sh0n.net/spstarr/khotnewstuff/plasmaweather-providers.xml)

yeah, i think this has to be skipped for now, it needed stuff that i don't 
want to expose as public symbol again.
I'll probably add some simpler js binding to replace that in the future

> * KUnitConversion data handling config & widgets, no idea yet how to port
> that to QQ2

isn't that stuff in kde4support?

> * further data processing of the raw data delivered by the weather data
> engines and feeding of view models
> 

you can do an Appplet subclass like that (like the confics applet) buut i 
think from it you can throw away most of the code of the current weatherapplet
then from qml it's accessible as plasmoid.nativeInterface all properties and 
methods you expose in the usual way  

> Perhaps some things should be moved to QmlExtension rather?
> Would not mind completing the recreation of the weather applet to a
> perfect implementation of how things should be done. So happy to be
> walked through the steps. But at the same time I need after every step a
> milestone where things work completely :)
> 
> Pushed as branch kossebau/weatherapplet to kdeplasma-addons, so you can
> have a look, feedback welcome.
> 
> Not sure if there is an issue with PlasmaComponents.TabGroup:
> in main.qml I currently need to disable setting the "model" property of
> the "DetailsView" item:
> //             model: plasmoid.nativeInterface.detailsModel
> otherwise the tab bar is not shown.
> Any idea why that can happen?

will take a look

-- 
Marco Martin