Cloud storage does not load at startup since b9b1f03

Jan Iversen jani at apache.org
Wed Jul 25 13:28:43 PDT 2018


Thanks to everybody for reporting issues, it is my top priority to solve these issues.

Stefan: can you please confirm that your problems is when using the desktop ? and before qCloudStorage it would load your local cache?

I just had a look at my jani.xml it has a lot of empty settings, can someone (stefan?) please send me  in private a filled xml working file, so I can adapt it to my xml file. THANKS IN ADVANCE.

It´s late here, but I will continue working tomorrow (after my training lessons).

Dirk: you write “a couple of scenarios” if that is more than the 2 I pursue now (cloud not loading automatically with cloud profile, and local profile tries to load from cloud) please be so kind and detail them so I can reproduce them.

Thanks to all for showing patience while I solve the problem I introduced.

rgds
jan I.



Enviado desde mi iPad

> El 25 jul 2018, a las 21:42, Dirk Hohndel <dirk at hohndel.org> escribió:
> 
> 
>> On Jul 25, 2018, at 12:12 PM, Stefan Fuchs <sfuchs at gmx.de> wrote:
>> I also have to report some unintended behavior coming from the "qPrefCloudStorage" change.
>> My setup is the following:
>> I by default start Subsurface with a local .xml file ("Stefan.xml") and rather seldom use the cloud storage.
>> 
>> After the change Subsurface starts with a title bar showing "[Cloud storage for] Stefan.xml" which is obviously not correct because I want to have the local file. Also the menu entry "File->Cloud storage online" is active which is also incorrect. I have the feeling that also the overall behavior regarding which data is used is rather strange but that's just a guess.
> 
> 
> My quick test here with a couple of scenarios seems to indicate that we misinterpret the setting for what to do at startup. Haven't had spent enough time staring at the code to understand why.
> 
> This is always the risk with rewrites like this (and why Tomaz was not excited to see another rewrite of the preferences subsystem, given that he had done this before and felt the existing system was good enough...) but now that we started, we should track down the little bugs but otherwise finish things.
> 
> /D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20180725/dcdb3f71/attachment-0001.html>


More information about the subsurface mailing list