maemo.org - Talk - mbarcode

maemo.org - Talk (https://talk.maemo.org/index.php)

- Applications (https://talk.maemo.org/forumdisplay.php?f=41)

- - mbarcode (https://talk.maemo.org/showthread.php?t=34996)

And I'm going to try to get python plugins working on Sunday afternoon.

Quote:

barcode or QR code are both ok.

I was just curious as there are many different types of 1D code and the 2D codes can explicitly say which app/plugin they want to handle them depending on what text they contain.

What are the specifics of your application? Do the barcodes already exist on whatever you're scanning (in which case you should know exactly what they are, or can give us an example image) or are you doing some sort of proof of concept and therefore can choose whatever you want?

I'd like to write a plugin that can handle URLs to .deb packages that will download the .deb to a temporary location and then open the .deb with Application Manager (after a warning if the .deb comes from a non-repository location).

Also, the same plugin should be able to handle text/data that just describes a package name and downloads and installs it from the repository using the Application Manager (what's the best way to "encode" information like this and have it detected by mbarcode as a package name?).

Someone could then provide a web interface to generate such QR codes and publish them on the application web pages (maybe we can even get these "app codes" integrated into maemo.org/downloads).

This is a well-known technique for installing apps in the Android world, and I think it would be a nice way of quickly "discovering" apps on Maemo, too.

Indeed, glad someone else is interested in this. I saw the very same feature in Android and in the old GTK+ version of mbarcode, wrote the QR code plugin so that it could accept either an entire .install file encoded as a QR code barcode (but those were then pretty large) or just the url to a .deb/.install file which is (theoretically, and at least did work iirc) automatically handed over to the relevant program to be downloaded and handled.

Anyway I'm all for this, I guess that encoding a url or the name of a deb, rather than the entire .install file would be a better way of doing this, just as the QR code barcodes are then smaller.

I'm open to suggestions and opinions as to formats, etc.

Example format of Android QR code:

Quote:

market://search?q=pname:com.company.program

I think providing only the package name and repository (extras, extras-testing and extras-devel) in the code would be enaugh and won't need that accurate captures :)

If only the application manager wasn't that slow ...

Quote:

Originally Posted by lardman (Post 699985)

Anyway I'm all for this, I guess that encoding a url or the name of a deb, rather than the entire .install file would be a better way of doing this, just as the QR code barcodes are then smaller.

I'm open to suggestions and opinions as to formats, etc.

The URI schemes page on Wikipedia has an entry for "apt:", which is used at least by Ubuntu AFAIK. So, "apt:<packagename>" would be really short for packages that are in Extras. Maybe we could also special-case the situation where <packagename> is not in Extras (and check for Extras-Testing/-Devel and ask the user with a big, fat warning if (s)he wants to install unstable software?).

For "single deb" installation, we could either detect ".deb" at the end of an URL and assume it's a package (maybe asking the user first) or "invent" some pseudo-URI-scheme (e.g. "dpkg://", which will be used to "detect" an installation request, and "dpkg://" will be replaced by "http://" before trying to download the package - "dpkgs://" could be used for https:// URLs).

Or maybe we leave the single-.deb option completely out of this as an incentive to get apps into Extras and just go with "apt:" URIs?

We could (if we wanted) support repository information by adding the parameters at the end of the "apt:" URI, e.g.:

apt:feedingit?url=http://repository.maemo.org/extras-devel/&distribution=fremantle&components=free%20non-free

Actually, the first lines of most install files contain exactly the package name and the repository name. If we take Personal IP Address as an example:

The install file contains this:

Code:

[install]

catalogues = extras

package = personal-ip-address



[extras]

name = Maemo Extras

uri = http://repository.maemo.org/extras/

components = free non-free

We could make probably cut the install file down to this:

Code:

[install]

catalogues = extras

package = personal-ip-address

And make it so that when the catalogue is not defined, the application tries to fill in the missing info for a set of known catalogues (extras, extras-testing, extras-devel etc.) and then uses the install file as always.

This minimal install file format is almost the same size as the URL to the file.

The URL is encoded like this:
http://qrcode.kaywa.com/img.php?s=3&...et_installfile

While the "minimal" install file is like this:
http://qrcode.kaywa.com/img.php?s=3&...nal-ip-address

Doing it the "Android way" is by far the most efficient method. This is

Code:

install://extras;personal-ip-address

in QR Code:
http://qrcode.kaywa.com/img.php?s=3&...nal-ip-address
I'm not sure if we should bring in a new format just to make the size smaller? Or to create a special URI? Reusing the data from the install file is maybe easier to make it work with the downloads section.

Using the web interface from Kaywa is quite easy by the way, and is probably a good start until someone creates a tool specifically for Maemo.

@thp: If you want to do that, please feel free to have a look at the qr-plugin source code. I think the easiest way to do what you want is to implement (patch) it into the qr-plugin rather than making a new one :)

@thp: I had completely forgotten about apt! That's probably the best idea yet. It actually has kind of a spec for repositories as well, just check out the apt URI for flash on Ubuntu:

Code:

apt:adobe-flashplugin?channel=$distro-partner

I'm not sure where to find the full spec for apt URI's, but this format is for sure simple enough - and we're not reinventing the wheel :)

Quote:

Originally Posted by thp (Post 700073)

Or maybe we leave the single-.deb option completely out of this as an incentive to get apps into Extras and just go with "apt:" URIs?

I at least believe that we shouldn't create a new URI standard just for debs. It is clearly for the best to get as many packages into repositories in general (because of updates etc.), and into extras especially. Having a simple parser for deb-files could be a good idea, although not all deb-links contain ".deb" (because of redirection etc.).

Attached is a very basic patch that should get you started, some things are still missing and need to be filled in. Untested, probably full of bugs, it might not even compile and you could overwrite important files (no error checking, etc..). It also does not open the generated .install file yet. Can you fill in the missing pieces? :)

We need to check whether the Hildon mimehandler handles apt: uris, if it does then all's well and good and we don't even need to change the plugin (or at least not significantly, i.e. a one liner, iirc).