Re: Cannot connect on first launch

[tormento]

Sent a private with log.

Tell me if you need other.

Alberto

Il giorno lun 2 lug 2018 alle ore 17:41 Dirk Hohndel  ha
scritto:

>
> > On Jul 2, 2018, at 12:33 AM, tormento  wrote:
> >
> > I have one minor bugs on Windows:
> >
> > I use nightly builds. After every manual update, i.e. unpacking the .exe
> and replacing older files, on the first launch I get the "automatic check
> for updates" windows. I can accept or decline but the following effect is
> that the first connection to cloud goes timeout and I get lower window red
> message "Cannot connect to cloud server, working with local copy". I have
> to close Subsurface and on the next use everything goes ok.
>
> That's strange. Can you run this with '-v -v' and share the log from an
> unsuccessful attempt?
>
> Thanks
>
> /D
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Video thumbnails

[Berthold Stoeger]

Hi Robert,

On Friday, 6 July 2018 15:38:33 CEST Robert Helling wrote:

> > On 6. Jul 2018, at 15:32, Berthold Stoeger 
> > wrote:
> > Can't ffmpeg write the image to stdout? Then we could just read it in a
> > thread and send it via signal/slot to the thumbnailing system. I always
> > prefer "push" over "pull" interfaces.
> 
> I don’t know about writing to stdout, maybe. But still those would be
> several, wouldn’t it? What do you think is a good rate, one image per
> minute?
> 
> Let me modify my proposal: Trigger the generation upon opening the dive (and
> not having thumbnails) in a background task. Store the images in a
> temporary directory. Upon completion of the ffmpeg process add those images
> to the Subsurface thumbnails. Does that sound better (that would be a
> signal based push if you like).

I pushed a very rudimentary PR to github, which shows how this could be 
married with the current thumbnailing system. In a first test on Linux, I was 
amazed how nicely this works!

But it is of course still very rough. ffmpeg muse be in the current path. The 
difficult case will be what to do if no ffmpeg is installs or it fails. I 
think we shouldn't show a "broken" icon in order not to penalize users without 
ffmpeg. But should we add an entry into the thumbnail cache, etc?

I can dig up the my old code that added a watermark to the thumbnails to 
signal "video file".

Hope that is useful,

Berthold


___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cannot connect on first launch

[Dirk Hohndel]

Thanks for sending the log. The error is really weird. We get the correct 
response back from the server; we use a personalized silly variation of the 
"I'm a teapot" protocol to recognize our cloud server - and we get the right 
response back, yet the code seems to think it's an error.
I need to stare at that code a bit longer, but this makes no sense, TBH.

Would you mind creating a GitHub issue and attaching that Log there - this way 
others can take a look and maybe help me see what we are doing wrong.

Thanks

/D

> On Jul 10, 2018, at 12:52 AM, tormento  wrote:
> 
> Sent a private with log.
> 
> Tell me if you need other.
> 
> Alberto
> 
> Il giorno lun 2 lug 2018 alle ore 17:41 Dirk Hohndel  > ha scritto:
> 
> > On Jul 2, 2018, at 12:33 AM, tormento  > > wrote:
> > 
> > I have one minor bugs on Windows:
> > 
> > I use nightly builds. After every manual update, i.e. unpacking the .exe 
> > and replacing older files, on the first launch I get the "automatic check 
> > for updates" windows. I can accept or decline but the following effect is 
> > that the first connection to cloud goes timeout and I get lower window red 
> > message "Cannot connect to cloud server, working with local copy". I have 
> > to close Subsurface and on the next use everything goes ok.
> 
> That's strange. Can you run this with '-v -v' and share the log from an 
> unsuccessful attempt?
> 
> Thanks
> 
> /D
> 
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cannot connect on first launch

[tormento]

Couldn’t be simply a timeout or handshake error caused by the update check?
It happens only on that event.

Anyway I need to study a bit GitHub as I have never contributed directly.
Could you please give me also an idea on how to anonymoize log? Personal
data there :)

Il giorno mar 10 lug 2018 alle 17:32 Dirk Hohndel  ha
scritto:

> Thanks for sending the log. The error is really weird. We get the correct
> response back from the server; we use a personalized silly variation of the
> "I'm a teapot" protocol to recognize our cloud server - and we get the
> right response back, yet the code seems to think it's an error.
> I need to stare at that code a bit longer, but this makes no sense, TBH.
>
> Would you mind creating a GitHub issue and attaching that Log there - this
> way others can take a look and maybe help me see what we are doing wrong.
>
> Thanks
>
> /D
>
> On Jul 10, 2018, at 12:52 AM, tormento  wrote:
>
> Sent a private with log.
>
> Tell me if you need other.
>
> Alberto
>
> Il giorno lun 2 lug 2018 alle ore 17:41 Dirk Hohndel 
> ha scritto:
>
>>
>> > On Jul 2, 2018, at 12:33 AM, tormento  wrote:
>> >
>> > I have one minor bugs on Windows:
>> >
>> > I use nightly builds. After every manual update, i.e. unpacking the
>> .exe and replacing older files, on the first launch I get the "automatic
>> check for updates" windows. I can accept or decline but the following
>> effect is that the first connection to cloud goes timeout and I get lower
>> window red message "Cannot connect to cloud server, working with local
>> copy". I have to close Subsurface and on the next use everything goes ok.
>>
>> That's strange. Can you run this with '-v -v' and share the log from an
>> unsuccessful attempt?
>>
>> Thanks
>>
>> /D
>>
>> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: MXE with Qt5.11.1 and missing map

[Thiago Macieira]

On Monday, 9 July 2018 23:31:22 PDT Dirk Hohndel wrote:
> And the same thing is preventing the Qt 5.11 based Android app from working.
> There is some other component or library that we need to select in cmake -
> but I can't figure out what the right keyword might be. On Android it's lib
> declarative_positioning.so that isn't packaged and that one isn't packaged
> because its dependency libQt5PositioningQuick.so is missing.
> 
> That sound awfully familiar, doesn't it?

Yeah.

My guess is that the deploy applications actually all share the same history 
and have the same bug. They work like this (my theory):
 1) check which libraries the application links to
 2) adds regular (non-QML) plugins associated with that library
 3) check what QML imports (including plugins) are needed

But they don't recheck after #3 if any plugins require libraries the 
application doesn't link to. This could be worked around by explicitly linking 
to the new library -- except that library has no public symbols to require, so 
many linkers will just drop it as unnecessary.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: MXE with Qt5.11.1 and missing map

[Dirk Hohndel]

> On Jul 10, 2018, at 3:15 PM, Thiago Macieira  wrote:
> 
> On Monday, 9 July 2018 23:31:22 PDT Dirk Hohndel wrote:
>> And the same thing is preventing the Qt 5.11 based Android app from working.
>> There is some other component or library that we need to select in cmake -
>> but I can't figure out what the right keyword might be. On Android it's lib
>> declarative_positioning.so that isn't packaged and that one isn't packaged
>> because its dependency libQt5PositioningQuick.so is missing.
>> 
>> That sound awfully familiar, doesn't it?
> 
> Yeah.
> 
> My guess is that the deploy applications actually all share the same history 
> and have the same bug. They work like this (my theory):
> 1) check which libraries the application links to
> 2) adds regular (non-QML) plugins associated with that library
> 3) check what QML imports (including plugins) are needed
> 
> But they don't recheck after #3 if any plugins require libraries the 
> application doesn't link to. This could be worked around by explicitly 
> linking 
> to the new library -- except that library has no public symbols to require, 
> so 
> many linkers will just drop it as unnecessary.

So the problem becomes... how do we work around that. Just force the library 
to be part of the package... is that the way to go? It's what I did for macOS 
and
I think I know how to do that win Windows (but haven't tried, yet). With 
Android 
I still haven't figured out how to do that... :-( 

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: MXE with Qt5.11.1 and missing map

[Thiago Macieira]

On Tuesday, 10 July 2018 15:28:43 PDT Dirk Hohndel wrote:
> > But they don't recheck after #3 if any plugins require libraries the
> > application doesn't link to. This could be worked around by explicitly
> > linking to the new library -- except that library has no public symbols
> > to require, so many linkers will just drop it as unnecessary.
> 
> So the problem becomes... how do we work around that. Just force the library
> to be part of the package... is that the way to go? It's what I did for
> macOS and I think I know how to do that win Windows (but haven't tried,
> yet). With Android I still haven't figured out how to do that... 

That sounds like a decent workaround, until the deploy tools get fixed.

I haven't looked at he macdeployqt tool in a few years, but it shouldn't be 
too difficult to fix it. Assuming the other two have copy/pasted code, the fix 
should be ported easily too.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: MXE with Qt5.11.1 and missing map

[Thiago Macieira]

On Tuesday, 10 July 2018 18:08:08 PDT Thiago Macieira wrote:
> I haven't looked at he macdeployqt tool in a few years, but it shouldn't be
> too difficult to fix it. Assuming the other two have copy/pasted code, the
> fix should be ported easily too.

Quick inspection of the source code shows that it *meant* to deploy the 
plugins' dependencies. I'm going to try and create a simple testcase to see 
what happens.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface