Re: CHIP with subsurface

[Robert Helling]

Hi,

> Am 30.05.2016 um 16:41 schrieb Miika Turkia :
> 
> IIRC this should be very easy to do with dnsmasq.

I just had a look at the docs and indeed this seems to be exactly what I am 
looking for.

Thanks
Robert


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PLEASE VOTE] so what should we be working on

[Pedro Neves]

On 28-05-2016 22:37, Dirk Hohndel wrote:

So what should we be working on...? Should we...

(1) just shut this down and move on?
(2) move things to maintenance mode, abandon Subsurface-mobile, fix bugs in 
Subsurface whenever we find time but otherwise declare victory? It won't be too 
painful to track libdicecomputer and keep making 4.5.x releases for a while, I 
guess...
(3) focus on Subsurface-mobile, release the iOS version, update the Android 
version and see if there is a single person besides me who is willing to invest 
time into that?
(4) focus on Subsurface 4.6, fix the dive site management and create a list of 
prioritized features that we want to get in place?
(5) focus on Subsurface 5.0, write a completely new UI and abandon what we have 
in 4.5?



Hi Dirk et. al.

First, sorry for my late answer, but "better late than never", I guess...

Here goes my 2 cents:

- Regarding Subsurface-mobile, I must say I'm not a heavy user. I see 
it's potential, but (call me old fashioned), I always have my laptop 
around and I hate using apps. Nevertheless, from the responses we've got 
so far, there seems to be a fair number or people interested on our 
mobile version so its development must continue...


- As for the desktop version, I'd vote for (4). I'll continue to give my 
(small) contributions on the translation, manual and testing. Still on 
top of my todo list for Subsurface is my template for printing - I'd say 
that's the feature I'm still missing on our program. As soon as  have it 
ready, I'd be happy to place it on a public repository. Maybe that will 
help other users.


In short, I'm another one voting for  (3) and (4).

All the best:

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

[PLEASE VOTE] so what should we be working on

[Willem Ferguson]

On 30/05/2016 17:07, Benjamin wrote:



On 29 May 2016 at 00:37, Dirk Hohndel > wrote:


I have been focused on other things for a while (and the why and
the what will become public fairly soon) and decided to use that
chance to figure out what would happen if I just stopped paying
attention here for a while.

So what should we be working on...? Should we...

(1) just shut this down and move on?
(2) move things to maintenance mode, abandon Subsurface-mobile,
fix bugs in Subsurface whenever we find time but otherwise declare
victory? It won't be too painful to track libdicecomputer and keep
making 4.5.x releases for a while, I guess...
(3) focus on Subsurface-mobile, release the iOS version, update
the Android version and see if there is a single person besides me
who is willing to invest time into that?
(4) focus on Subsurface 4.6, fix the dive site management and
create a list of prioritized features that we want to get in place?
(5) focus on Subsurface 5.0, write a completely new UI and abandon
what we have in 4.5?

If your vote is for 3, 4, or 5 I assume that you are volunteering
to carry some of the work that is needed to get there.
If you don't vote, I will count that as a vote for 1.

Good afternoon all,
As one of the many lurkers, I suppose that my 2 cents is worth 
slightly less than that. To be honest, my life and work balance went 
to hell in the past few months for various reasons.


Having said that, I would vote for 4 and 3, in that order. 5 sounds 
like a fun challenge, but as both KDE and Gnome have shown, it is 
rather painful...


Given some time, I'm more than willing to help. I just need to a.) get 
through this mess that I'm currently stuck in (Let's hear it for work 
politics...), and b.) learn how the hell the QT interface code works 
(are there any good tutorials for C/assembly programmers?).


Benjamin

The decision for the future of Subsurface depends on how we see dive log 
software is likely to operate in future. Currently, by far the largest 
degree of innovation is on the different forms of mobile platforms. I 
would expect that this trend will continue for at least another decade. 
I would expect that smartphones will become more powerful, screen 
management and UI will develop significantly, and that the standard 
laptop and desktop will become less ubiquitous and used mostly by 
individuals with a serious IT function in some way. For subsurface this 
means that, in the longer term,  the mobile versions could likely become 
more important and more frequently used than the desktop version. If one 
has to guess at the future, I would think: chug away steadily at the 
desktop version (perhaps making location management more intuitive and 
more robust [works well for me because I (think) I understand it as is]. 
I am not convinced that a totally redesigned UI is the priority now. 
While updating the desktop version, keep an eye on what our own needs 
are, what new hardware turns up and what other dive computers and dive 
management software do that may be cool. Then, at the same time focus on 
the mobile versions. As we all know, this is the conundrum. Amongst us, 
the skills base for mobile development is pretty meagre. I see this as 
the major challenge going forward. Knowing nothing about mobile software 
design, the current KDS-Qt platform appears pretty sophisticated, mostly 
because it offers cross-platform functionality starting with C++ with 
which many are familiar. For me, personally, the open source aspect of 
this is also important. Therefore I am very uncomfortable with myself to 
ask the question: is the current Qt platform the one that will serve 
future development of Subsurface the best? I do not have the insight to 
be able to say anything coherently about this, but I really hope Qt is 
indeed the viable route. For Subsurface to advance, several 
diver-developers will have to either learn how to do mobile software 
development, or we need to find divers who have these mobile skills and 
who are prepared to contribute materially.


A hardware-based implementation of libdivecomputer appears very 
attractive, given that digital technology at the OS level appears to 
change much faster than the dive computers that are still being used (on 
occasion I still deal with a VR3). I suspect that IrDA will be used 
quite some time into the future for one reason: several of the dive 
computers that use IrDA have proved to be either workhorses for 
technical and other more demanding diving, or are still very popular in 
(at least in some circles, e.g. Poseidon). A hardware solution therefore 
offers opportunities for significantly extending the life of dive 
computers using older technology.


So my vote goes for a combination of 3 and 4.
Kind regards,
willem


___
subsurface mailing list

Re: [PATCH] WIP: use kirigami plugin instead of embedding in qrc

[Marco Martin]

On Monday 30 May 2016, Martin Gysel wrote:
> 
> I'm wondering if it would be possible to get Kirigami 'into' qpm [1].
> That way it would be much simpler to use it in any qmake base app.
> 
> I once played around with it and tried to create a .pri file but for
> some reasons I failed.

so, now if kirigami is compiled with cmake it generates and installs a global 
pri file (then in a qmake project one would do Qt +=Kirigami)
i also put a pri file in the root directory, that is identical to the full 
.pro.. 
in that case basically if you just check out kirigami as a subdirectory of 
your project and then do an include (kirigami/kirigami.pri) it should build 
and install kirigami directly from your project make step (this should work 
fine for android as well)

now , leaving it there to see if one of the approaches ends up working good 
enough in iOS

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

Re: [PLEASE VOTE] so what should we be working on

[Benjamin]

On 29 May 2016 at 00:37, Dirk Hohndel  wrote:

> I have been focused on other things for a while (and the why and the what
> will become public fairly soon) and decided to use that chance to figure
> out what would happen if I just stopped paying attention here for a while.
>
> So what should we be working on...? Should we...
>
> (1) just shut this down and move on?
> (2) move things to maintenance mode, abandon Subsurface-mobile, fix bugs
> in Subsurface whenever we find time but otherwise declare victory? It won't
> be too painful to track libdicecomputer and keep making 4.5.x releases for
> a while, I guess...
> (3) focus on Subsurface-mobile, release the iOS version, update the
> Android version and see if there is a single person besides me who is
> willing to invest time into that?
> (4) focus on Subsurface 4.6, fix the dive site management and create a
> list of prioritized features that we want to get in place?
> (5) focus on Subsurface 5.0, write a completely new UI and abandon what we
> have in 4.5?
>
> If your vote is for 3, 4, or 5 I assume that you are volunteering to carry
> some of the work that is needed to get there.
> If you don't vote, I will count that as a vote for 1.
>
> Good afternoon all,
As one of the many lurkers, I suppose that my 2 cents is worth slightly
less than that. To be honest, my life and work balance went to hell in the
past few months for various reasons.

Having said that, I would vote for 4  and 3, in that order. 5 sounds like a
fun challenge, but as both KDE and Gnome have shown, it is rather painful...

Given some time, I'm more than willing to help. I just need to a.) get
through this mess that I'm currently stuck in (Let's hear it for work
politics...), and b.) learn how the hell the QT interface code works (are
there any good tutorials for C/assembly programmers?).

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

Re: CHIP with subsurface

[Miika Turkia]

On Mon, May 30, 2016 at 4:50 PM, Robert Helling  wrote:
> Hi,
>
> my progress on the CHIP has unfortunately been slower than I though
> originally (mainly because there are a number of things do do and each takes
> longer than expected).
>
> Some things work, others not yet, but I see no fundamental obstacle, yet.
> All I have done so far works identically on CHIP and RaspberryPi. To be
> reproducible, I have logged all my steps here:
>
> http://trac.subsurface-divelog.org/wiki/Subsurface%20on%20RPi
>
> Currently, I could use help with three things:
>
> 1) Wifi Access point: i have the thing act like and access point. But
> iPhones, upon establishing a dhcp connection, phone home to apple and try to
> download http://www.apple.com/library/test/success.html to see if they are
> connected to the “real” internet rather than some hotel captive portal. As
> we do not provide that, we should respond to that request. I guess that
> means we have to run a DNS server and claim that we are www.apple.com and
> then serve that page.

IIRC this should be very easy to do with dnsmasq. Just one line in the
configuration stating that www.apple.com is our IP. Comment in config
file states that we can define a domain to be served as local, so we
might have to grab the whole apple.com but a simple test should reveal
the facts.

address=/apple.com/192.168.1.1

dnsmasq can act as a DHCP server as well, so it should cover quite
well what services we need.

I believe all vendors are more or less doing the same test, so we
might need to cover quite a bit of different connectivity tests.

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

Re: [PATCH] WIP: use kirigami plugin instead of embedding in qrc

[Martin Gysel]

Am 30.05.2016 um 14:55 schrieb Marco Martin:
> On Monday 30 May 2016, Martin Gysel wrote:
>> Am 30.05.2016 um 13:59 schrieb Marco Martin:
>>> On Sunday 29 May 2016, Dirk Hohndel wrote:
 To make matters worse, Tomaz no longer has access to a Mac so he can’t
 help, either. Which means that right now a Kirigami version that
 requires the plugin is a non-starter for Subsurface-mobile on iOS. I
 simply don’t understand how this is supposed to work and nothing that I
 find online seems to address this combination in a way that I can
 follow. Not sure what the solution here should be. A qmake file for the
 kirigami plugin maybe?
>>>
>>> If you want to give it a try, in the branch mart/runtimeTheme (that's the
>>> branch where i switch to requiring an actual c++ plugin)
>>> I added a minimal qmake file. I only tried it on my local system, but it
>>> seems to build it correctly here.
>>
>> I'm wondering if it would be possible to get Kirigami 'into' qpm [1].
> 
> I'll look into it
> 
>> That way it would be much simpler to use it in any qmake base app.
>>
>> I once played around with it and tried to create a .pri file but for
>> some reasons I failed.
> 
> I made it build in a branch with a cmake project already, i'll take a look at 
> doing a .pri as well
> 

sounds great, thx :)
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PLEASE VOTE] so what should we be working on

[Robert Helling]

Hi Dirk, hi others!

> On 28.05.2016, at 23:37, Dirk Hohndel  wrote:
> 
> I have been focused on other things for a while (and the why and the what 
> will become public fairly soon) and decided to use that chance to figure out 
> what would happen if I just stopped paying attention here for a while.

I can understand your frustration but I would not paint it as black as you seem 
to do. I agree that it’s sad that a large number of people that have 
contributed a lot in the past seem to have decoupled for a least the better 
part of a year and except for you (and the kirigami people) pushing the mobile 
version.

My personal excuse for doing so little recently (but as I tried to explain a 
while ago on IRC I would not say I do nothing but I have only very little to 
show) is that all my free time got soaked up by other things in particular job 
and family but I still hope that better times are still ahead. In no way I have 
given up contributing and strongly plan to do so again in the (hopefully near) 
future.

> 
> Here's what I think I learned (correct me if I'm wrong)
> 
> a) no one cares about Subsurface-mobile. No bug reports, no code, no 
> suggestions, nothing. So I guess we should call this a failed attempt and 
> abandon it - screw the 500 or so people who use it.
> 
> b) Miika continues to deal with any import bug that shows up. Awesome. Your 
> patches have been pushed
> 
> c) there continues to be a slow crawl of features, ideas, patches for the 
> planner. Those have also been pushed (someone poke me if I got something 
> wrong there)
> 
> d) no one cares about the dive site mess that we have. The current version in 
> Subsurface 4.5.x is pretty much unusable and makes no bleeping sense.  No 
> patches, some suggestions for improvement, no discussion, nothing.
> 
> 
> In summary, this project is pretty much dead. I guess it does everything the 
> formerly active developers wanted? Or everyone has moved on to more fun 
> things? Or had children, changed jobs, built a house, lost their job, or one 
> of a number of other life events?

My analysis would be: In the current version, subsurface desktop in its current 
incarnation does many things well (and often much better than other programs 
that I have seen). So there is very little pressure to fix things (and as  far 
as I can tell responses to bug reports on the mailing list are still quick and 
stuff that has a chance to be fixed usually is within 24h). The location thing 
might be a mess, but it works for me so I feel little itch there. But I should 
also say that I did not find much time for diving either (I haven’t been in the 
water in 2016, yet) so I did not have a lot of chances for real world use of 
subsurface.

The mobile version is a little different, but only a little: First of all, for 
what it is designed for (read access to your log book on the road) it already 
works very well. It might have some visual glitches but unfortunately, my 
experience of attacking those has been quite frustrating. I guess that this is 
mainly due to the fact, that I have long breaks between having goes at the 
mobile version which implies that just to get started an get the thing to 
compile and deploy on my device already takes significant time (before any line 
of code is added) and then (as you know) debugging QML is let’s put it like 
that, challenging.

Last time I tracked down one of the problems on my IPhone 4s (overlapping 
labels) I found a way to resolve that but that might have other implications so 
I asked on IRC (on May 9th) but never heard from anybody. I could probably 
still send a patch (but would have to remind myself what the actual issue was).

Another thing I tried was to address some of the many many warnings/error 
messages that I get on the command line when running subsurface-mobile. But I 
never got very far since I always ended up deep in kirigami code without proper 
understanding what was going on and what what was supposed to go on. Mainly the 
latter, my lack of understanding of “how things should work together” is what I 
blame on not being able to make any progress. But that on the other hand 
requires more investment into reading and understanding stuff which is only 
possible with larger chunks of time available (which was not the case in the 
past but is hopefully in the future). And of course, these things get much 
easier when there are other people around doing the same where one can get 
answers to questions or just steal ideas from code. I have not given up here, 
it’s just that progress is slow.

Still, I would see the mobile version to be quite close to a complete V 1.0. To 
me there is no obvious thing that is missing from the design goal. That is to 
say: Dirk (and others), you already did an amazing job! And I wish I had 
contributed more.

There is of course the issue with reading out dive computers using the mobile 
version. But (as I said in the past), I thing with the help of a 

Re: [PATCH] WIP: use kirigami plugin instead of embedding in qrc

[Marco Martin]

On Monday 30 May 2016, Martin Gysel wrote:
> Am 30.05.2016 um 13:59 schrieb Marco Martin:
> > On Sunday 29 May 2016, Dirk Hohndel wrote:
> >> To make matters worse, Tomaz no longer has access to a Mac so he can’t
> >> help, either. Which means that right now a Kirigami version that
> >> requires the plugin is a non-starter for Subsurface-mobile on iOS. I
> >> simply don’t understand how this is supposed to work and nothing that I
> >> find online seems to address this combination in a way that I can
> >> follow. Not sure what the solution here should be. A qmake file for the
> >> kirigami plugin maybe?
> > 
> > If you want to give it a try, in the branch mart/runtimeTheme (that's the
> > branch where i switch to requiring an actual c++ plugin)
> > I added a minimal qmake file. I only tried it on my local system, but it
> > seems to build it correctly here.
> 
> I'm wondering if it would be possible to get Kirigami 'into' qpm [1].

I'll look into it

> That way it would be much simpler to use it in any qmake base app.
> 
> I once played around with it and tried to create a .pri file but for
> some reasons I failed.

I made it build in a branch with a cmake project already, i'll take a look at 
doing a .pri as well

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

Re: [PATCH] WIP: use kirigami plugin instead of embedding in qrc

[Martin Gysel]

Am 30.05.2016 um 13:59 schrieb Marco Martin:
> On Sunday 29 May 2016, Dirk Hohndel wrote:
>> To make matters worse, Tomaz no longer has access to a Mac so he can’t
>> help, either. Which means that right now a Kirigami version that requires
>> the plugin is a non-starter for Subsurface-mobile on iOS. I simply don’t
>> understand how this is supposed to work and nothing that I find online
>> seems to address this combination in a way that I can follow. Not sure
>> what the solution here should be. A qmake file for the kirigami plugin
>> maybe?
> 
> If you want to give it a try, in the branch mart/runtimeTheme (that's the 
> branch where i switch to requiring an actual c++ plugin)
> I added a minimal qmake file. I only tried it on my local system, but it 
> seems 
> to build it correctly here.
> 

I'm wondering if it would be possible to get Kirigami 'into' qpm [1].
That way it would be much simpler to use it in any qmake base app.

I once played around with it and tried to create a .pri file but for
some reasons I failed.

I also tried to use Kirigami in a small toy project where I first
struggled. Now I can run the app locally but only by setting the QML
import path and autocompletion in qt creator still does not work.

As Kirigami is a KDE project it may make sense to use cmake but the way
Kirigami use cmake makes it definitely not easy to actually use Kirigami
as a framework for most projects.

/martin

[1] https://www.qpm.io/

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

Re: [PATCH] WIP: use kirigami plugin instead of embedding in qrc

[Marco Martin]

On Sunday 29 May 2016, Dirk Hohndel wrote:
> To make matters worse, Tomaz no longer has access to a Mac so he can’t
> help, either. Which means that right now a Kirigami version that requires
> the plugin is a non-starter for Subsurface-mobile on iOS. I simply don’t
> understand how this is supposed to work and nothing that I find online
> seems to address this combination in a way that I can follow. Not sure
> what the solution here should be. A qmake file for the kirigami plugin
> maybe?

If you want to give it a try, in the branch mart/runtimeTheme (that's the 
branch where i switch to requiring an actual c++ plugin)
I added a minimal qmake file. I only tried it on my local system, but it seems 
to build it correctly here.


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