What version of the Google Maps API is used if you don't specify a version number? The latest release version perhaps? The documentation about versioning doesn't say.
The documentation does recommend that production apps specify a minor version number. But it also says "all API changes will be backwards-compatible," so is there any reason I should specify a version number if I'm not using any experimental features?
English is not my first language, so I might be reading this part wrong (from the versioning doc you linked)
You can indicate which version of the API to load within your application by specifying it using the v parameter ... The nightly (development) version, specified with v=3 or by omitting the v parameter.
Further down, there's a mention of 3.9 being nightly.
Documentation of Versions
Version 3.9 Reference (Nightly)
So, sounds like leaving out the v (which I do) will load the nightly, version 3.9.
<script type="text/javascript" src="http://maps.googleapis.com/maps/api/js?sensor=false"></script>
About part two of your question: I can think of a very good reason to specify a version:
Consistency, predictability, reliability
You might want to keep the same look-and-feel while working on a update for the latest release of the Maps API. For example, the labels or map controls may move around.
On the other hand, it's good to keep track of the latest versions, too. By lagging too far behind your application might stop working when it becomes unsupported.
I'm sure there are better reasons. I'm not a professional Maps developer.
I've been building extensive Google Maps based applications and according to my experience it's better to specify API version for a long term projects. For example an issue I was facing recently:
The system was built and tested along with v3.6 but Google released an experimental version
Which is loaded by default but from the other hand not recommended for business or professional development.
Therefore to avoid some malfunction that appeared suddenly I had to specify API version:
<script src="http://maps.google.com/maps/api/js?sensor=false&v=3.16" type="text/javascript"></script>
Then after that everything came back to normal. You may quickly consult API version by typing in the browser console google.maps.version.
I hope someone may find it useful.
Related
I need to know when inFullscreen of monitor object is set to true, I wanna make sure it's not set to true when window is maximized. I can't find any docs for imports.ui.main nor any imports.ui.*. That's simple (but still annoying) I can hold alt and press F2 and type lg then enter to try it in the repl. But what if I need some info about queueDeferredWork?
Or what if I wanna know if there's a signal like switch-workspace but when the switch is finished (when switch-workspace is triggered it SEEMS that the switch animation just began and at least inFullscreen doesn't return true when I switch to a fullscreen workspace, it just SEEMS so, I can't make sure as I can't find docs for it.)
Is gnome-shell api (except imports.gi.*) not documented? or am I missing something?
There was very similar question asked here: How do I get the monitor of an active window in GNOME?
Sorry I didn't see your question earlier; you should use the tags [gnome-shell-extensions] and [gjs] to ellicit help for more programming related questions.
Updated September 2021
As of, well awhile ago, GJS has its own portal for tutorials, documentation and so on.
https://gjs.guide
Everything below is linked to from this portal, so it's a good bookmark.
There are guides covering all the basics, much of the advanced usage, introductions to core libraries like GLib and GTK, including some specialized tutorials like spawning subprocesses. There is also a dedicated section for extensions, covering creation, translations, preferences and porting guides to get your extension working on the latest release.
Please - do request any documentation you find lacking. It may not always be feasible or quick, but we'll do our best.
https://gjs-docs.gnome.org
This is GJS's official API documentation for the GNOME platform, including all core libraries and all the other libraries like GStreamer and WebKit you expect. If a library is missing, you can request it by opening an issue.
For GNOME Shell extensions, these will be of particular interest (see the Architecture page for more details):
Clutter: The compositor-side toolkit, part of Mutter
Meta: The window manager and/or compositor (aka Mutter)
St: Builds on Clutter to add more complex widgets and CSS
Shell: The internal library of GNOME Shell, providing several classes and functions
Gvc: High-level bindings for PulseAudio. Not strictly a part of GNOME Shell, but used by it and worth noting.
This documentation is still correct, however it is probably best for those familiar with the GNOME platform that just need some hints for GJS.
Modules built into GJS: https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Modules.md
General API usage in GJS: https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Mapping.md
As JavaScript is (now) evolving fairly quickly, it is highly advised you familiarize yourself with GNOME Shell's JavaScript source. Aside from being crucial to writing extensions, this is the best way to keep up with new features in JavaScript and GJS, including patterns for using them.
HELP!
discourse.gnome.org using the extensions tag
Matrix: https://matrix.to/#/#extensions:gnome.org
IRC: irc://irc.gnome.org/shell-extensions
I updated my pods today and got the latest 6.0.0 version of the SDK. However this seems to be missing the "track" function that was used to interact with the whispers setup on the dashboard. What is the alternative for this?
Whispers support, including the track API, was removed from all three Smooch SDKs in the latest major version releases, since the Whispers feature is currently deprecated and set to be removed from the platform on October 1st. The deprecation was communicated to all Whispers users at the beginning of July 2017.
If you send an email to help#smooch.io describing your use case, there may be the possibility of a workaround, but the newest SDKs were not designed to support Whispers or Whispers-style use cases, so workarounds won't be possible in every case.
Two days ago the released version of the google maps API was updated to 3.19
Version 3.18 broke some things in our application so we had been explicitly asking for 3.17 until it was deprecated. We updated the application to work with 3.19 and ask for the latest release version, instead of explicitly specifying the version.
Yesterday it went back to 3.18.20, which again broke our application.
We have since updated to explicitly request 3.19, but I'm wondering why the default version is now returning 3.18 instead of the current release version?
Thanks
If you don't specify the version number the version you get will vary according to the documentation on versioning:
You can indicate which version of the API to load within your application by specifying it using the v parameter of the Maps Javascript API bootstrap request. Three options are supported:
The experimental version, specified with v=3.exp.
The release version, specified with v=3
The frozen version, specified with v=3.0
If you do not explicitly specify a version, you will receive the experimental version by default. Google Maps API for Work customers who specify a client ID will receive the release version by default.
If you specify a specific version (i.e. v=3.18), you will get that version while it is available. Once it is retired, you will get the frozen version.
I experienced this same issue, and submitted a bug to Google. See their answer here:
https://code.google.com/p/gmaps-api-issues/issues/detail?id=7694
To reiterate their answer, there were apparently some issues with 3.19, so they reverted their experimental/release/frozen versions. I've chosen to directly use 3.19, as it doesn't seem to introduce any issues for my purposes.
My intention is to create a chrome plugin for the windows users. Is that possible to call windows api from Native Client /PPAPI. If possible how?
I am answering my question, as after some study, I found the answer from West a bit not right. I tried calling windows APIs in Pepper(PPAPI) Plugin and it works fine with a command line switch "--register-pepper-plugins" (not the --no-sandbox as specified by West). It seems safer to use this command line attribute as it is only registering a plugin in to the Chrome browser and not removing any sandbox. I thought of adding an answer after finding an actual pepper plugin existing in use, which uses the switch (the NetFlix pepper plugin for chromeos ).
Got more information to add. Chrome API is available which provides the multi-monitor information : chrome.systemInfo.display object provides all the necessary information. The chrome documentation is not updated. Important thing to note is that, the permission "systemInfo.display" is to be added in the manifest to use this object. Two bugs are reported in the functionality of this object.
1. The monitor name is same for all monitors "Generic PnP Monitor", the documentation claims to provide the user friendly name of monitors.
2. There is an event which should get invoked on resolution change of monitors, but the event is never getting invoked.
Currently the implementation is only for Windows OS. Support for other OS are on the way. Documentation says that the API is only available for Chrome App, but I haves tested that and the API is available on Chrome Extensions as well.
Unfortunately, the short answer is 'no'. Native Client is designed to be OS-independent and as safe as JavaScript. Think of Native Client as native code that has the same capabilities and restrictions as JavaScript. A Native Client module that made Windows API calls would break both of those design principles: it wouldn't run on, e.g., a Mac, and it would be a major security risk (imagine browsing to a web page that decides to erase files from your harddrive).
Since you mention Chrome, it may be interesting to you to know that web apps - whether they use JavaScript or Native Client - can request additional permissions as packaged apps in Chrome Web Store. However, native OS calls are still not possible for the reasons listed above.
NPAPI plugins do not have these restrictions, but the future of NPAPI, at least in Chrome, is uncertain (see the last paragraph of http://blog.chromium.org/2012/07/npapi-plug-ins-in-windows-8-metro-mode.html).
For development purposes, it is possible to turn Chrome's outer sandbox off with the command-line flag --no-sandbox and then run PPAPI plugins that make direct OS calls. This is meant for developers and is not a suitable option to be used by end-users.
If you could say a bit more about what you're trying to achieve, there may be ways to do this with Native Client/Pepper.
So i am working in a chrome extension which won't be hosted on the google webstore, thus i will need to add the auto-update functionality to it, however i need it to be a little more dynamic, i will try to illustrate what i am trying to accomplish by a little scenario so it won't seem pointless.
Scenario
I need to have an extension that's kinda have different editions for each version, i.e. each version have a free edition and a paid (feature rich) edition, and whenever a new version is released the extension will be updated according to it's edition.
In other words, the server should be able detect the user's edition and provide the crx file according to it "i.e. dynamic".
What i tried / think of
1.I tried to set a cookie with the extension edition, so when the auto-update occurs the server can check it and generate the xml file, unfortunately i found that cookies don't get sent in the auto-update headers sent by chrome.
2.I can make the extension talk to the serve when chrome start-up, so it will send it's edition, so the server will store it along with the ip and when the auto-update occurs the server will check the request ip and match it with the edition to provide the xml, i think this could work but it's kinda lame method.
3.I can use native apps to modify the manifest file to point to a different xml file according to the edition, i guess this will work too but i am not in favor of using native apps.
4.I tried to find a way to modify the get-request parameters (i.e. to add custom parameters like the edition), but it seems that there is no way to do so.
5.I can separate different editions to be different extensions (i.e. free edition will be a in different package than the paid one), however i am interested to make it all in one, so the user can upgrade/downgrade their subscription without installing/removing the extension they already have.
I guess that's it and i hope some one would have a better idea on how i can accomplish what i am trying to do.
P.S. I know the title is kinda vague but i couldn't find a better one, so if you came up with better title please let me know.
Why not make the free edition version 1.* and the paid edition version 2.*? Then make your update page generated dynamically by a simple PHP page, that gets the app id and version (see the autoupdate docs).
Put "update":"http://www.mysite.com/update_app.php in your manifest. In your PHP script, read $_GET['version'], and serve an XML update document to match the major version number (1.* free version, 2.* paid version). Basically, keep two XML update files on your server (and two CRX files) and have the script decide which one to serve.
It doesn't have to be PHP, of course; any server-side language will do.