Re: QTMoko website
On Tuesday, October 02, 2012 10:08:02 AM matthsch...@arcor.de wrote: Hi Radek, OK, i installed it with apt-get install qtmoko-navit. Now I'm about to assign maps, onscreen buttons and so on, I will figure it out. Whta I didd not find until now is how navit turns the GPS on. Neither I found how Nerongps turns it on - here it works, but I dont know how. Navit currently does not support QtMoko's GPS framework. You will have to edit navit configuration file and give it /dev/ttyO1 as serial NMEA port and you will also need to do rfkill unblock gps to power on GPS antenna. Or on Freerunner the port will be something like /dev/ttySAC1. It's one of things i have in plan to add QtMoko's GPS framework support to navit. No idea when i have time to do it, but it's quite big priority for me. BTW, http://qtmoko.sourceforge.net/apps/qtmoko-qtopiagps.html gives an error message about the package not present. Yup, the app needs someone to adapt it make it working. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Status of camera support
Hi, What is the actual state of camera support in Qtmoko for GTA04...? -- Regards Sebastian Reinhardt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Status of camera support
On Tuesday, October 02, 2012 01:57:08 PM Sebastian Reinhardt wrote: What is the actual state of camera support in Qtmoko for GTA04...? IIRC the kernel driver is not completely working yet, so we are waiting for kernel now... Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QTMoko website
On Tuesday, October 2, 2012 12:25:31, Radek Polak wrote: On Tuesday, October 02, 2012 10:08:02 AM matthsch...@arcor.de wrote: Hi Radek, OK, i installed it with apt-get install qtmoko-navit. Now I'm about to assign maps, onscreen buttons and so on, I will figure it out. Whta I didd not find until now is how navit turns the GPS on. Neither I found how Nerongps turns it on - here it works, but I dont know how. Navit currently does not support QtMoko's GPS framework. You will have to edit navit configuration file and give it /dev/ttyO1 as serial NMEA port and you will also need to do rfkill unblock gps to power on GPS antenna. Or on Freerunner the port will be something like /dev/ttySAC1. It's one of things i have in plan to add QtMoko's GPS framework support to navit. No idea when i have time to do it, but it's quite big priority for me. BTW, http://qtmoko.sourceforge.net/apps/qtmoko-qtopiagps.html gives an error message about the package not present. Yup, the app needs someone to adapt it make it working. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I'm not sure if it's relevant for Navit but I've integrated gpsd usage in QtMoko. I'll write more about that this evening. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QTMoko website
Neil Jerram n...@ossau.homelinux.net writes:
On Tuesday, October 2, 2012 12:25:31, Radek Polak wrote:
Navit currently does not support QtMoko's GPS framework. You will have to
edit
navit configuration file and give it /dev/ttyO1 as serial NMEA port and you
will
also need to do rfkill unblock gps to power on GPS antenna. Or on
Freerunner
the port will be something like /dev/ttySAC1.
It's one of things i have in plan to add QtMoko's GPS framework support to
navit. No idea when i have time to do it, but it's quite big priority for me.
Alternatively, one could install gpsd and gpsd-clients and run Navit
using gpsd (which I think is its default). You'd still have to do the
rfkill unblock gps somehow, because the gpsd in Debian Squeeze doesn't
have a hook for doing that. (The gpsd in Wheezy does.)
The only problem then is that QtMoko apps wouldn't be able to access the
GPS at the same time, but for that...
I'm not sure if it's relevant for Navit but I've integrated gpsd usage
in QtMoko. I'll write more about that this evening.
Attached is a patch to make QtMoko's GPS framework (Q*Whereabouts) use
gpsd instead of reading directly from /dev/ttyO1. The benefit of that
is that multiple clients, both Qt and non-Qt, can all use GPS at the
same time.
From edb97c45be3e36b91fbd4bc8836d4cab56046ac3 Mon Sep 17 00:00:00 2001
From: Neil Jerram n...@ossau.homelinux.net
Date: Sun, 30 Sep 2012 23:35:15 +0100
Subject: [PATCH] NeoGpsPlugin - use gpspipe -r instead of cat /dev/ttyO1.
This allows us to have multiple GPS clients at the same time.
Specifically, to have NeronGPS running on the GTA04, and also using
gpspipe to export the GPS NMEA stream over Bluetooth.
(An alternative approach is to use QGpsdWhereabouts instead of
NeoGpsPlugin, but this doesn't work because the QGpsdWhereabouts code
assumes the old GPSD protocol which has now been replaced by JSON. To
use QGpsdWhereabouts successfully, that code would need updating for
the new protocol, probably by using libgps.
Using gpspipe -r at the bottom of NeoGpsPlugin should be equally
effective, and doesn't require such a complex code change.)
---
.../src/plugins/whereabouts/neo/neogpsplugin.cpp | 21
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/devices/gta04/src/plugins/whereabouts/neo/neogpsplugin.cpp b/devices/gta04/src/plugins/whereabouts/neo/neogpsplugin.cpp
index 7737c17..f6e55fc 100644
--- a/devices/gta04/src/plugins/whereabouts/neo/neogpsplugin.cpp
+++ b/devices/gta04/src/plugins/whereabouts/neo/neogpsplugin.cpp
@@ -31,7 +31,20 @@
#include qtopialog.h
/*
- This plugin only works for Goldelico's GTA04
+ This plugin uses gpspipe -r to get NMEA sentences out of GPSD,
+ then feeds those to QNmeaWhereabouts. It should work on any
+ distribution where GPSD is running and successfully accessing the
+ GPS device.
+
+ The benefit of using GPSD, instead of reading the GPS device
+ directly, is that multiple clients can access GPS information at the
+ same time. For example, GPS can be simultaneously used by a local
+ application such as NeronGPS, and exported over Bluetooth to another
+ device.
+
+ An alternative GPSD-based solution would be to use QGpsdWhereabouts
+ instead of QNmeaWhereabouts, but that would require updating
+ QGpsdWhereabouts for GPSD's new JSON-based protocol.
*/
NeoGpsPlugin::NeoGpsPlugin(QObject * parent)
: QWhereaboutsPlugin(parent)
@@ -56,12 +69,12 @@ QWhereabouts *NeoGpsPlugin::create(const QString )
qLog(Hardware) __PRETTY_FUNCTION__;
reader = new QProcess(this);
-reader-start(cat, QStringList() /dev/ttyO1, QIODevice::ReadWrite);
+reader-start(gpspipe, QStringList() -r, QIODevice::ReadWrite);
if (!reader-waitForStarted()) {
-qWarning() couldnt start cat /dev/ttyO1: + reader-errorString();
+qWarning() Couldn't start gpspipe -r: + reader-errorString();
QMessageBox::warning(0, tr(GPS),
- tr(Cannot open GPS device at /dev/ttyO1),
+ tr(Couldn't start gpspipe -r),
QMessageBox::Ok, QMessageBox::Ok);
delete reader;
reader = 0;
--
1.7.10.4
I don't think this patch is ready for inclusion yet, because it would be
better if it handled both gpsd usage and direct access gracefully -
i.e. try using gpspipe, and fall back to opening /dev/ttyO1 if that
fails. But it would be interesting to hear if people think this is the
right longterm approach.
Regards,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
[QtMoko] Hyperlink viewing and factory reset
Hi there,
Below is a QtMoko patch (for the Arora submodule) for hyperlink viewing
- i.e. so that touching on a hyperlink in, say, an email causes Arora to
pop up and show the corresponding web page.
I imagine a very similar patch could be applied to Yberbrowser, but I
still mostly use Arora, so haven't looked at that in detail. Also I
don't know what happens if there are two installed apps that both
provide the WebAccess service.
Slightly related is this story about tel: URLs in web pages with
telephone numbers that are actually dangerous USSD requests, and some
Android phones automatically executing those requests:
http://nakedsecurity.sophos.com/2012/09/26/are-android-phones-facing-a-remote-wipe-hacking-pandemic
On the GTA04, with QtMoko:
- USSD requests in general are implemented; e.g. typing *#06# into the
dialer will cause your IMEI to pop up. This happens immediately after
the second #, without any call button press.
- The Arora browser doesn't seem to understand tel: URLs at all, so the
patch below isn't exposing any new danger (unless/until Arora might be
enhanced to support tel: URLs).
- I don't know if the dialer would execute a USSD request without
confirmation if the request came from another application, instead of
being typed into the dialer.
- I don't know if the GTA04 has any dangerous USSD codes!
Does anyone know about the last two points?
Regards,
Neil
From a3784d5e4107cbc460139bc3ded8fe0cde76b9ec Mon Sep 17 00:00:00 2001
From: Neil Jerram n...@ossau.homelinux.net
Date: Sun, 16 Sep 2012 23:42:19 +0100
Subject: [PATCH] arora - Provide the Qtopia WebAccess service
This makes clicking on links in email work - both when Arora is
already running, and when there isn't already any web browser
running (in which case Arora is started automatically).
---
.gitignore |2 +-
src/browserapplication.cpp | 29 +
src/qbuild.pro |6 ++
src/services/WebAccess/arora |2 ++
src/webservice.h | 37 +
5 files changed, 75 insertions(+), 1 deletion(-)
create mode 100644 src/services/WebAccess/arora
create mode 100644 src/webservice.h
diff --git a/.gitignore b/.gitignore
index b101154..a8bea3c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,4 @@
-arora
+/arora
Arora.app
Makefile
.DS_Store
diff --git a/src/browserapplication.cpp b/src/browserapplication.cpp
index cc8bd1f..5585971 100644
--- a/src/browserapplication.cpp
+++ b/src/browserapplication.cpp
@@ -83,9 +83,23 @@
#include qwebsettings.h
#include QtopiaApplication
+#include QtopiaAbstractService
#include qdebug.h
+#include webservice.h
+
+void WebAccessService::openURL(QString url)
+{
+emit openUrl(url);
+}
+
+void WebAccessService::openSecureURL(QString url)
+{
+// XXX make sure this is a secure url
+emit openUrl(url);
+}
+
DownloadManager *BrowserApplication::s_downloadManager = 0;
HistoryManager *BrowserApplication::s_historyManager = 0;
NetworkAccessManager *BrowserApplication::s_networkAccessManager = 0;
@@ -152,6 +166,10 @@ BrowserApplication::BrowserApplication(int argc, char **argv)
this, SLOT(lastWindowClosed()));
#endif
+QObject *service = new WebAccessService(this);
+connect(service, SIGNAL(openUrl(const QString )),
+ this, SLOT(messageRecieved(const QString )));
+
#ifndef AUTOTESTS
QTimer::singleShot(0, this, SLOT(postLaunch()));
#endif
@@ -455,6 +473,17 @@ BrowserMainWindow *BrowserApplication::newMainWindow()
m_mainWindows.prepend(browser);
setMainWidget(browser); //
showMainWidget();
+
+// Calling showMainWidget() a second time is the magic sauce that
+// is needed for Qtopia not to kill Arora after it has processed a
+// request for the WebAccess service. When servicing a
+// QtopiaServiceRequest requires _launching_ a new application -
+// i.e. because a suitable application isn't already running -
+// Qtopia's default behaviour is to close the launched application
+// again as soon as it appears to have processed that request.
+// For a web browser, we clearly don't want that.
+showMainWidget();
+
//browser-show();
return browser;
}
diff --git a/src/qbuild.pro b/src/qbuild.pro
index 4db82b6..7e39289 100644
--- a/src/qbuild.pro
+++ b/src/qbuild.pro
@@ -93,6 +93,7 @@ HEADERS += \
tabwidget.h \
toolbarsearch.h \
webactionmapper.h \
+webservice.h \
webview.h \
webviewsearch.h \
xbel.h
@@ -151,3 +152,8 @@ SOURCES += \
utils/rotate.cpp
#---
+
+# Install service registration
+service.files=services/WebAccess/arora
+service.path=/services/WebAccess
+INSTALLS+=service
diff --git a/src/services/WebAccess/arora b/src/services/WebAccess/arora
new file mode 100644
index 000..f99c0fd
--- /dev/null
+++ b/src/services/WebAccess/arora
@@ -0,0 +1,2 @@
+[Standard]
+Version=100
diff
Re: QtMoko v48 neofreerunner
dmatthews.org m...@dmatthews.org writes: Here's some more smtp debugging - I'm now using the mail.inbox.lv server which supports unencrypted and TLS access Trying port 587 with TLS:- Sep 24 20:01:37 neo Qtopia: 250-STARTTLS^M Sep 24 20:01:37 neo Qtopia: 250-AUTH LOGIN PLAIN^M Sep 24 20:01:37 neo Qtopia: 250-ENHANCEDSTATUSCODES^M Sep 24 20:01:37 neo Qtopia: 250-8BITMIME^M Sep 24 20:01:37 neo Qtopia: 250 DSN Sep 24 20:01:37 neo Qtopia: SMTP : StartTLS: sent: STARTTLS Sep 24 20:01:37 neo Qtopia: SMTP : response: 220 2.0.0 Ready to start TLS Sep 24 20:01:38 neo Qtopia: Encrypted connect warnings: 'The root certificate of the certificate chain is self-signed, and untrusted' Sep 24 20:01:38 neo Qtopia: SMTP : Closed connection Sep 24 20:01:38 neo Qtopia: socketError: 13 : The root certificate of the certificate chain is self-signed, and untrusted Hi David, I was just looking again at your reports about SMTP. I think there are several different factors for the different cases, and I haven't understood most of them yet. But I wonder if one relevant factor, for some of the untrusted cases, is that the QtMoko v48 rootfs doesn't include any CA certificates. I suddenly remembered that I also get lots of SSL error popups when using Arora. But after doing an apt-get install ca-certificates, I don't see those anymore, so presumably they were caused by the lack of any CA certificates. Also an odd thing about about those popups is that they don't indicate the actual problem, i.e. that the root certificate is untrusted. Instead they typically just say No Error No Error No Error :-) That could just be an Arora-specific problem, but it could be a more general problem with how certificate-related errors are propagated up through Qt. Anyway, you may like to: - try apt-get install ca-certificates, restart QtMoko, and see if any of your SMTP cases succeed after that - see if your working v35 rootfs has CA certificates in it (at /etc/ssl/certs). Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
