* This is a very useful control, and 3rd-party apps should be able to
use it.
* But, there are planned improvements (making a better model/view
interface) which prevents making it part of the stable API yet.
* Store the username in the app settings. The password was already stored
in the keyring. Restore the username upon next launch.
* Display the logged in user in the main window.
* Added "Log out" menu entry.
* When the password could not be retrieved from the keyring (also because
the user rejects the keyring dialog), unset the username.
* Allow unsetting the username by passing an empty name.
For the time being, there is a limited amount of supported languages
when creating accounts, reflect this in the UI and use a BMenuField.
Creating accounts with other languages fails, the error reporting was
not ideal and could be improved. The server responded with "object not found",
which was reported in the alert, but the response actually contains the
object which was not found (NaturalLanguageCode).
* Added TODO to retrieve the list from the web-app, there is already an
API for it. For now, the hard-coded list matches the web-app's and the
next change in this regard will be to support any known language.
* Make the list accessible.
* There is a little code duplication. This will be moved to BFormat once
the time and datetime formatting is also moved out of BLocale
* The way to create a BDateFormat from a BLocale is still open for
discussion. I'm undecided between making BDateFormat a member of
BLocale, or adding a BDateFormat(const BLocale&) constructor.
* Adjust all users of the API.
We get several users on IRC asking for help on how to disable it. It
doesn't even look good, uses a lot of CPU, and we have better (useful)
ways to demonstrate replicants on the desktop. So this demo has no use
anymore.
* We install the headers for many things that are currently in libshared
(BColumnListView, BCalendarView, etc). So it makes sense to also provide
the lib in an "use at your own risk" way. Only the static library is
included, so apps linking against it should continue running on newer
Haiku versions even if the content of the lib changes.
* 3rd party application developers can now make use of those
experimental features without having to copypaste and fork the sources.
* Fontconfig and freetype are now building fine, so let's add correct
packages.
* Our pixman was way too old and cairo didn't want to use it
* itstool is used by gtk_doc, which will come in another commit.
Source or destination buffers passed to pagecache functions may belong
to kernel memory (e.g. when the caller is packagefs). Because of that
we should tell vm_memcpy_{from, to}_physical() truth, not assume that all
buffers are in user memory. That's important because user memory page fault
handlers cannot be nested and these functions may be used while handling
a page fault.
With high probability fixes#11246.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
At the moment, the web-app has a defined, limited set of supported languages
for translations. JSON requests fail when asking for an unsupported language
code. For the time being, force the language code to be in the supported set.
... completely untested and premature. The idea is that after a successful
login with the web-app, the password used is stored in the keyring. Then
HaikuDepot will restore just last the used username on next launch and retrieve
the password from the keyring. One could also register multiple accounts in
HaikuDepot and switch between them.
* It seems openbmap is using a variation of the API that's not
compatible with what other providers use.
* Fix a ";" instead of "," in the JSON request. We should get a
BJsonBuilder to avoid such silly errors
* Improve indenting of the request to ease readability.
* Parse the latitude and longitude as doubles, not strings.
This was tested against Mozilla Location Services and I get accurate
results (withing a few hundred meters). However I'm not sure how to
share the MLS API key safely so it is used only in Haiku, I will discuss
this with the MLS team.
A BGeolocation object can query an online service to get geolocation
and geotagging data:
* LocateSelf() tries to locate the machine it is running on, by using an
online database of wifi access points
* Locate() (not yet implemented) searches a BString and converts it to
lat/lon coordinates (reverse geotagging)
* Name() (not yet implemented) finds a suitable name for the given
coordinates (address, building name, or anything fitting).
The default service used is openbmap.org, which is freely available but
not very accurate. A request has been sent to Mozilla to use MLS
(Mozilla Location Services), which is a bit more accurate but needs an
API key. MLS is used for geolocation on FirefoxOS, for mobile phones
which don't have a GPS, and the data can be contributed by Firefox for
Android or the dedicated MozStumbler app.
Alternatively, Google Maps also provide the service, but wants
people to pay for it. Google Maps data is more accurate as all Android
devices contribute data to it.
All 3 services use the same JSON-based API: we send a list of reachable
Wifi APs (mac address and signal strength), and we get lattitude and
longitude information, and possibly extra data which will currently be
unused.
This can be used to implement HTML5 geolocation with reasonably accurate
results, but it can also be used in other places. For example
FirstBootPrompt could try to guess a list of most likely languages and
keyboard layouts from it (if wifi is working at install time, that is).
