wwWidgets in 2019

21 views
Skip to first unread message

Malcolm Schongalla

unread,
Aug 4, 2019, 6:47:08 PM8/4/19
to FlySight Developers
I wiped my laptop and updated to Mint 19.1, and then wanted to rebuild FlySightViewer from source.  The wwWidgets download link seems to be gone now.  No idea where to get it from again.  Fortunately I think I saved the library I'd previously compiled, but otherwise it basically seems like a broken dependency at this point.  Hopefully I am mistaken.  Anybody know what happened to wwWidgets?

Michael Cooper

unread,
Aug 5, 2019, 4:25:01 PM8/5/19
to flysig...@googlegroups.com
Hi Malcolm--

I noticed this recently myself. I will be removing the dependency from FlySight Viewer in the next release--the only reason it's needed is for a colour picker widget used in the Preferences dialog box. I'm pretty busy with other work this week, but will try to get a pull request into the main repository within a week or so.

In the meantime, you may be able to build wwWidgets from source here: https://github.com/TheDZhon/wwwidgets. I haven't tried it myself, but it looks like this is the same library maintained by someone other than the original author.

Michael

On Sun, Aug 4, 2019 at 4:47 PM Malcolm Schongalla <malcolm.s...@gmail.com> wrote:
I wiped my laptop and updated to Mint 19.1, and then wanted to rebuild FlySightViewer from source.  The wwWidgets download link seems to be gone now.  No idea where to get it from again.  Fortunately I think I saved the library I'd previously compiled, but otherwise it basically seems like a broken dependency at this point.  Hopefully I am mistaken.  Anybody know what happened to wwWidgets?

--
You received this message because you are subscribed to the Google Groups "FlySight Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flysight-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flysight-devs/58014f6b-1b13-47ea-8bf2-c7930565ea4a%40googlegroups.com.

Malcolm Schongalla

unread,
Aug 5, 2019, 5:11:23 PM8/5/19
to flysig...@googlegroups.com
Thanks, I'll check out that repository. Meanwhile I'm still trying to
get Qt 5.5 to compile too!
> To view this discussion on the web visit https://groups.google.com/d/msgid/flysight-devs/CAGVxNqkzxhQvb0v7Vo4xLUnVaCtrcmgquF_ys_gv-4k42sLxQQ%40mail.gmail.com.

Michael Cooper

unread,
Aug 6, 2019, 12:01:44 AM8/6/19
to flysig...@googlegroups.com
:-) Ah, the fun of Linux. What problems are you running into?

Michael

Malcolm Schongalla

unread,
Aug 6, 2019, 2:20:31 PM8/6/19
to flysig...@googlegroups.com
1. Compiler throws some type incompatibility errors compiling Qt
5.5.1. I suspect it's because I need to enforce the -std=c++98 option
(instead of default c+11 standard). The README file says
specifically to do this. But I don't have a lot of experience with
the makefile system so I'm not sure how to send this flag to the
compiler to test this theory.

2. After that, I need to figure out how to make VLC-Qt compile with
5.5.1 installed in, say, /home/user/qt5.5, instead of Qt 5.9.5 in
/usr/include/x86_64-linux-gnu/qt5 which it seeks by default somehow.

Any suggestions? Otherwise I'm just searching through stackexchange
and trialing-and-error-ing. I figured it out back in 2017, somehow...
> To view this discussion on the web visit https://groups.google.com/d/msgid/flysight-devs/CAGVxNq%3Dfi59LwdEB7L%3DNBYwvuKbdmCz3bx7-299f-xtuBAr_vg%40mail.gmail.com.

Malcolm Schongalla

unread,
Aug 6, 2019, 7:24:28 PM8/6/19
to flysig...@googlegroups.com
If I try running make with CXXFLAGS="-std=c++98", it throws the error: "You must build your code with position independent code if Qt was built with -reduce-relocations."  "Compile your code with -fPIC (-fPIE is not enough)."

If I try running make with CXXFLAGS="-std=c++98 -fPIC" , it can't locate numerous header files in the source tree (i.e. jpeglib.h), so that didn't help.

Compiling Qt 5.5.1 by the c++11 standard: make has been failing with error in the qtwebkit module: "invalid conversion from ‘const JSChar* {aka const short unsigned int*}’ to ‘const UChar* {aka const char16_t*}’ [-fpermissive]"

There are a lot of people asking for help on this same problem on help forums, across platforms, with no useful answers.  The problem is also mentioned for Qt 5.9.  Some are claiming it is related to the release of ICU 59, some are posting about this in late 2017, or thereabouts (as in, International Components for Unicode for those like me who didn't know that).  There are supposedly some bugfixes out there but the various links I found were all broken.

I found this from http://site.icu-project.org/download/59:
"With the move to C++11, ICU4C has also moved to char16_t as the type for UTF-16 code units and string pointers.
This is a breaking change.
Why are we breaking your code?
With C++11 finally supported by all ICU platforms, this is the first time that a C++ standard type is available for UTF-16, together with u"syntax for string literals" which have type const char16_t *.
ICU's mission is to be the premier Unicode and i18n library, and we want ICU to “play nice” with the new standard C++ UTF-16 type and strings."

So basically Qt 5.5 uses 'const UChar*' declarations, which was compatible with ICU when it was released in 2015.  But since ICU has changed to 'const char16_t*' declarations, breaking Qt 5.5.  As far as I can tell.  Maybe a real programmer out there can shine some light on this...

Maybe I can just do a massive "find and replace" from JChar* to UChar* on the entire source, but that's a lot of work :)

Michael Cooper

unread,
Aug 7, 2019, 1:39:45 PM8/7/19
to flysig...@googlegroups.com
Hi Malcolm--

I'm afraid I won't be able to dig into this for a few weeks--at the moment, I'm a bit swamped between regular business and supporting competitions.

One of the main reasons we still use Qt 5.5 is because we use QWebView for the map view. I'd like to port this to QWebEngineView, but the latter doesn't seem to support a synchronous interface--so I'd need to convert our synchronous interface into callbacks. Otherwise, I think we could probably move forward to later versions of Qt, which might eliminate some compatibility issues.

Michael

Malcolm Schongalla

unread,
Aug 7, 2019, 3:19:10 PM8/7/19
to flysig...@googlegroups.com
Oh no problem at all, I'm not trying to urge anyone to act on anything.  I have compiled Qt libraries from my old backup HD so I can use those-- I just wanted to build it again to keep myself fluent with the process.

I still have your email from 2017 describing the blocked vs. concurrent code.  In theory I would be very interested to take this on as an educational project, but I'm closing on a house this week, moving cross country, and have a newborn baby so those are my priorities for now :)
Malcolm

Michael Cooper

unread,
Sep 11, 2019, 2:52:06 PM9/11/19
to flysig...@googlegroups.com
Hi Malcolm--

Just wanted to let you know, in case you're not following on Facebook, that I've merged a change into GitHub that removes the dependency on wwWidgets. Hopefully this will help a little with your compilation issues!

Michael

Malcolm Schongalla

unread,
Sep 11, 2019, 3:04:21 PM9/11/19
to flysig...@googlegroups.com
I appreciate the heads up. I'm not a facebook guy, so I didn't know.  I'm excited to check out the change!
Malcolm

Reply all
Reply to author
Forward
0 new messages