Writing and deploying a small Firefox OS application

By Chris Lord

For the last week I’ve been using a Geeksphone Keon as my only phone. There’s been no cheating here, I don’t have a backup Android phone and I’ve not taken to carrying around a tablet everywhere I go (though its use has increased at home slightly…) On the whole, the experience has been positive. Considering how entrenched I was in Android applications and Google services, it’s been surprisingly easy to make the switch. I would recommend anyone getting the Geeksphones to build their own OS images though, the shipped images are pretty poor.

Among the many things I missed (Spotify is number 1 in that list btw), I could have done with a countdown timer. Contrary to what the interfaces of most Android timer apps would have you believe, it’s not rocket-science to write a usable timer, so I figured this would be a decent entry-point into writing mobile web applications. For the most part, this would just be your average web-page, but I did want it to feel ‘native’, so I started looking at the new building blocks site that documents the FirefoxOS shared resources. I had elaborate plans for tabs and headers and such, but turns out, all I really needed was the button style. The site doesn’t make hugely clear that you’ll actually need to check out the shared resources yourself, which can be found on GitHub.

Writing the app was easy, except perhaps for getting things to align vertically (for which I used the nested div/”display: table-cell; vertical-alignment: middle;” trick), but it was a bit harder when I wanted to use some of the new APIs. In particular, I wanted the timer to continue to work when the app is closed, and I wanted it to alert you only when you aren’t looking at it. This required use of the Alarm API, the Notifications API and the Page Visibility API.

The page visibility API was pretty self-explanatory, and I had no issues using it. I use this to know when the app is put into the background (which, handily, always happens before closing it. I think). When the page gets hidden, I use the Alarm API to set an alarm for when the current timer is due to elapse to wake up the application. I found this particularly hard to use as the documentation is very poor (though it turns out the code you need is quite short). Finally, I use the Notifications API to spawn a notification if the app isn’t visible when the timer elapses. Notifications were reasonably easy to use, but I’ve yet to figure out how to map clicking on a notification to raising my application – I don’t really know what I’m doing wrong here, any help is appreciated! Update: Thanks to Thanos Lefteris in the comments below, this now works – activating the notification will bring you back to the app.

The last hurdle was deploying to an actual device, as opposed to the simulator. Apparently the simulator has a deploy-to-device feature, but this wasn’t appearing for me and it would mean having to fire up my Linux VM (I have my reasons) anyway, as there are currently no Windows drivers for the Geeksphone devices available. I obviously don’t want to submit this to the Firefox marketplace yet, as I’ve barely tested it. I have my own VPS, so ideally I could just upload the app to a directory, add a meta tag in the header and try it out on the device, but unfortunately it isn’t as easy as that.

Getting it to work well as a web-page is a good first step, and to do that you’ll want to add a meta viewport tag. Getting the app to install itself from that page was easy to do, but difficult to find out about. I think the process for this is harder than it needs to be and quite poorly documented, but basically, you want this in your app:

if (navigator.mozApps) {
  var request = navigator.mozApps.getSelf();
  request.onsuccess = function() {
    if (!this.result) {
      request = navigator.mozApps.install(location.protocol + "//" + location.host + location.pathname + "manifest.webapp");
      request.onerror = function() {
        console.log("Install failed: " + this.error.name);
      };
    }
  };
}

And you want all paths in your manifest and appcache manifest to be absolute (you can assume the host, but you can’t have paths relative to the directory the files are in). This last part makes deployment very awkward, assuming you don’t want to have all of your app assets in the root directory of your server and you don’t want to setup vhosts for every app. You also need to make sure your server has the webapp mimetype setup. Mozilla has a great online app validation tool that can help you debug problems in this process.

And we’re done! (Ctrl+Shift+M to toggle responsive design mode in Firefox)

Visiting the page will offer to install the app for you on a device that supports app installation (i.e. a Firefox OS device). Not bad for a night’s work! Feel free to laugh at my n00b source and tell me how terrible it is in the comments

Interested in MIPS/UCLIBC/DirectFB becoming a Tier1 platform?

By Holger "zecke" Freyther

http-streams 0.5.0 released

By Andrew Cowie

I’ve done some internal work on my http-streams package. Quite a number of bug fixes, which I’m pleased about, but two significant qualitative improvements as well.

First we have rewritten the “chunked” transfer encoding logic. The existing code would accept chunks from the server, and feed them as received up to the user. The problem with this is the server is the one deciding the chunk size, and that means you can end up being handed multi-megabyte ByteStrings. Not exactly streaming I/O. So I’ve hacked that logic so that it yield‘s bites of maximum 32 kB until it has iterated through the supplied chunk, then moves on to the next. Slight increase in code complexity internally, but much smoother streaming behaviour for people using the library.

Secondly I’ve brought in the highly tuned HTTP header parsing code from Gregory Collins’s new snap-server. Our parser was already pretty fast, but this gave us a 13% performance improvement. Nice.

We changed the types in the openConnection functions; Hostname and Port are ByteString and Word16 now, so there’s an API version bump to 0.5.0. Literals will continue to work so most people shouldn’t be affected.

AfC

Migrating *.osmocom.org trac installations to a new host

By Holger "zecke" Freyther

http-streams 0.4.0 released

By Andrew Cowie

Quick update to http-streams, making a requested API change to the signature of the buildRequest function as well as pushing out some bug fixes and performance improvements.

You no longer need to pass the Connection object when composing a Request, meaning you can prepare it before opening the connection to the target web server. The required HTTP 1.1 Host: header is added when sendRequest is called, when the request is written to the server. If you need to see the value of the Host: field that will be sent (ie when debugging) you can call the getHostname function.

I’ve added an “API Change Log” to the README file on GitHub, and the blog post introducing http-streams has been updated reflect the signature change.

Thanks to Jeffrey Chu for his contributions and to Gregory Collins for his advice on performance improvement; this second release is about 9% faster than the original.

AfC

Cookies blabla…

By Marcin "hrw" Juszkiewicz

This site is using cookies. Some of them are to track you as I use Google Analytics. Other may keep your name/email/website when you write comments on my blog.

We have new law here in European Union that visitors should get notification when website is using cookies. You know — privacy stuff etc. Lot of people does not even have any idea what this whole noise is about. There are websites for them with all that not even needed information — your search engine will point you there (and use few cookies in meantime).

I do not plan to add any of those annoying popups which will tell that there are cookies in use. Once you see such one you get cookie — cause website needs a way to remember that you clicked “yes, I know, get off my screen” button. You will not see such one here.

There is a text box in right column about cookies — go, read, decide would you read my blog or not. It is your choice and always was.

PS. I added tags into post just to get this post shown on each RSS aggregator I am/was listed.

UPDATE: added small header.

All rights reserved © Marcin Juszkiewicz
Cookies blabla… was originally posted on Marcin Juszkiewicz website

QtMoko v54 pour le Neo FreeRunner (GTA02)

By openmoko-fr

• Passage à Qt 4.8.3
• Support de l'html5 dans les navigateurs
• Réglage du problème de l'application wifi qui changer à chaque fois l'ordre d'apparition des SSID avant même qu'on aie le temps d'en sélectionner un pour se connecter
• Les clés du répertoires QtMoko sont installées par défaut
• phonon est crée et peut être utilisé
• Le gps utilise gpsd et gpspipe
• Mise à jour du thème Mokofaen

Et voici deux notes de Radek à propos de la mise à jour :

• Elle n'a pas beaucoup été testée, mais semble marcher. Mise à part que l'audio s'arrête dans le "media player" après quelques secondes et il faudrait donc utiliser qmplayer pour l'instant (peut-être que c'est résolvable en installant un autre plugin gstreamer pour le mp3 à la place de fluendo)
• Si vous voulez mettre à jour au lieu de réinstaller, sachez que ça n'a pas été testé, mais qu'il faudra configurer gpsd pour que ça fonctionne : il faut éditer le fichier "/etc/default/gpsd" et y mettre DEVICES="/dev/ttySAC1"

Amusez vous bien!

PS : le lien pour télécharger : http://sourceforge.net/projects/qtmoko/files/GTA02/

An HTTP client in Haskell using io-streams

By Andrew Cowie

An HTTP client

I’m pleased to announce http-streams, an HTTP client library for Haskell, using the Snap Framework’s new io-streams library to handle the streaming I/O.

Back and there again

I’ve been doing a lot of work lately using Haskell to do reprocessing of data from various back-end web services and then presenting fragments of that information in the specific form needed to drive client-side visualizations. Nothing unusual about that; on one edge of your program you have a web server and on the other you’re making make onward calls to further servers. Another project includes meshes of agents talking to other agents; again, nothing extreme; just a server daemon responding to requests and in turn making its own requests of others. Fairly common in any environment build on (and in turn offering) RESTful APIs.

I’m doing my HTTP server work with the fantastic Snap Framework; it’s a lightweight and decently performing web server library with a nice API. To go with that I needed an web client library, but there the choices are less inspiring.

Those working in Yesod have the powerful http-conduit package, but I didn’t find it all that easy to work with. I soon found myself writing a wrapper around it just so I could use types and an API that made more sense to me.

Because I was happily writing web apps using Snap, I thought it would be cool to write a client library that would use the same types. After much discussion with Gregory Collins and others, it became clear that trying to reuse the Request and Response types from snap-core wasn’t going to be possible. But there was a significant amount of code in Snap’s test suite, notably almost an entire HTTP client implementation. Having used Snap.Test to build test code for some of my own web service APIs, I knew there was some useful material there, and that gave me a useful starting point.

Streaming I/O

One of the exciting things about Haskell is the collaborative way that boundaries are pushed. From the beginnings in iteratee and enumerator, the development of streaming I/O libraries such as conduit and pipes has been phenomenal.

The Snap web server made heavy use of the original iteratee/enumerator paradigm; when I talked to some of the contributors in #snapframework about whether they were planning to upgrade to one of the newer streaming I/O libraries, I discovered from Greg that he and Gabriel were quietly working on a re-write of the internals of the server, based on their experiences doing heavy I/O in production.

This new library is io-streams, aimed at being a pragmatic implementation of some of the impressive theoretical work from the other streaming libraries. io-streams‘s design makes the assumption that you’re working in … IO, which seems to have allowed them to make some significant optimizations. The API is really clean, and my early benchmarks were promising indeed.

That was when I realized that being compatible with Snap was less about the Request and Response types and far more about being able to smoothly pass through request and response bodies — in other words, tightly integrating with the streaming I/O library used to power the web server.

http-streams, then, is an HTTP client library built to leverage and in turn expose an API based on the capabilities of io-streams.

A simple example

We’ll make a GET request of http://kernel.operationaldynamics.com:58080/time (which is just a tinsy web app which returns the current UTC time). The basic http-streams API is pretty straight forward:

10 
11 {-# LANGUAGE OverloadedStrings #-}
23 
24 import System.IO.Streams (InputStream, OutputStream, stdout)
25 import qualified System.IO.Streams as Streams
26 import Network.Http.Client
27 
28 main :: IO ()
29 main = do
30     c <- openConnection "kernel.operationaldynamics.com" 58080
31 
32     q <- buildRequest $ do
33         http GET "/time"
34         setAccept "text/plain"
35 
36     sendRequest c q emptyBody
37 
38     receiveResponse c (\p i -> do
39         Streams.connect i stdout)
40 
41     closeConnection c
42 

which results in

Sun 24 Feb 13, 11:57:10.765Z

Open connection

Going through that in a bit more detail, given that single import and some code running in IO, we start by opening a connection to the appropriate host and port:

30     c <- openConnection "kernel.operationaldynamics.com" 58080

Create Request object

Then you can build up the request you need:

32     q <- buildRequest $ do
33         http GET "/time"
34         setAccept "text/plain"

that happens in a nice little state monad called RequestBuilder with a number of simple functions to set various headers.

Having built the Request object we can have a look at what the outbound request would look like over the wire, if you’re interested. Doing:

35     putStr $ show q

would have printed out:

GET /time HTTP/1.1
Host: kernel.operationaldynamics.com:58080
User-Agent: http-streams/0.3.0
Accept-Encoding: gzip
Accept: text/plain

Send request

Making the request is a simple call to sendRequest. It takes the Connection, a Request object, and function of type

   (OutputStream Builder -> IO α)

which is where we start seeing the System.IO.Streams types from io-streams. If you’re doing a PUT or POST you write a function where you are handed the OutputStream and can write whatever content you want to it. Here, however, we’re just doing a normal GET request which by definition has no request body so we can use emptyBody, a predefined function of that type which simply returns without sending any body content. So:

36     sendRequest c q emptyBody

gets us what we want. If we were doing a PUT or POST with a request body, we’d write to the OutputStream in our body function. It’s an OutputStream of Builders as a fairly significant optimization; the library will end up chunking and sending over an underlying OutputStream ByteString which is wrapped around the socket, but building up the ByteString(s) first in a Builder reduces allocation overhead when smacking together all the small strings that the request headers are composed of; taken together it often means requests will be done in a single sendto(2) system call.

Read response

To read the reply from the server you make a call to receiveResponse. Like sendRequest, you pass the Connection and a function to handle the entity body, this time one which will read the response bytes. It’s type is

   (Response -> InputStream ByteString -> IO β)

This is where things get interesting. We can use the Response object to find out the status code of the response, read various headers, and deal with the reply accordingly. Perhaps all we care about is the status code:

42 statusHandler :: Response -> InputStream ByteString -> IO ()
43 statusHandler p i = do
44     case getStatusCode p of
45         200 -> return ()
46         _   -> error "Bad server!"

The response body it available through the InputStream, which is where we take advantage of the streaming I/O coming down from the server. For instance, if you didn’t trust the server’s Content-Length header and wanted to count the length of the response yourself:

42 countHandler :: Response -> InputStream ByteString -> IO Int
43 countHandler p i1 = do
44     go 0 i1
45   where
46     go !acc i = do
47         xm <- Streams.read i
48         case xm of
49             Just x  -> go (acc + S.length x) i
50             Nothing -> return acc

Ok, that’s pretty contrived, but it shows the basic idea: when you read from an InputStream a it’s a sequence of Maybe a; when you get Nothing the input is finished. Realistic usage of io-streams is a bit more idiomatic; the library offers a large range of functions for manipulating streams, many of which are wrappers to build up more refined streams from lower-level raw ones. In this case, we could do the counting trick using countInput which gives you an action to tell you how many bytes it saw:

42 countHandler2 p i1 = do
43     (i2, getCount) <- Streams.countInput i1
44 
45     Streams.skipToEof i2
46 
47     len <- getCount
48     return len

For our example, however, we don’t need anything nearly so fancy; you can of course use the lambda function in-line we showed originally. If you also wanted to spit the response headers out to stdout, Response also has a useful Show instance.

38     receiveResponse c (\p i -> do
39         putStr $ show p
40         Streams.connect i stdout)

which is, incidentally, exactly what the predefined debugHandler function does:

38     receiveResponse c debugHandler

either way, when we run this code, it will print out:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Sun, 24 Feb 2013 11:57:10 GMT
Server: Snap/0.9.2.4
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Type: text/plain

Sun 24 Feb 13, 11:57:10.765Z

Obviously you don’t normally need to print the headers like that, but they can certainly be useful for testing.

Close connection

Finally we close the connection to the server:

41     closeConnection c

And that’s it!

More advanced modes of operation are supported. You can reuse the same connection, of course, and you can also pipeline requests [sending a series of requests followed by reading the corresponding responses in order]. And meanwhile the library goes to some trouble to make sure you don’t violate the invariants of HTTP; you can’t read more bytes than the response contains, but if you read less than the length of the response, the remainder of the response will be consumed for you.

Don’t forget to use the conveniences before you go

The above is simple, and if you need to refine anything about the request then you’re encouraged to use the underlying API directly. However, as often as not you just need to make a request of a URL and grab the response. Ok:

61 main :: IO ()
62 main = do
63     x <- get "http://www.haskell.org/" concatHandler
64     S.putStrLn x

The get function is just a wrapper around composing a GET request using the basic API, and concatHandler is a utility handler that takes the entire response body and returns it as a single ByteString — which somewhat defeats the purpose of “streaming” I/O, but often that’s all you want.

There are put and post convenience functions as well. They take a function for specifying the request body and a handler function for the response. For example:

66     put "http://s3.example.com/" (fileBody "fozzie.jpg") handler

this time using fileBody, another of the pre-defined entity body functions.

Finally, for the ever-present not-going-to-die-anytime-soon application/x-www-form-urlencoded POST request — everyone’s favourite — we have postForm:

67     postForm "https://jobs.example.com/" [("name","Kermit"),("role","Stagehand")] handler

Secure connections

I’ve also completely neglected to mention until now SSL support and error handling. Secure connections are supported using openssl; if you’re working in the convenience API you can just request an https:// URL as shown above; in the underlying API you call openConnectionSSL instead of openConnection. As for error handling, a major feature of io-streams is that you leverage the existing Control.Exception mechanisms from base; the short version is you can just wrap bracket around the whole thing for any exception handling you might need — that’s what the convenience functions do, and there’s a withConnection function which automates this for you if you want.

Status

I’m pretty happy with the http-streams API at this point and it’s pretty much feature complete. A fair bit of profiling has been done, and the code is pretty sound at this point. Benchmarks against other HTTP clients are favourable.

After a few years working in Haskell this is my first go at implementing a library as opposed to just writing applications. There’s a lot I’ve had learn about writing good library code, and I’ve really appreciated working with Gregory Collins as we’ve fleshed out this API together. Thanks also to Erik de Castro Lopo, Joey Hess, Johan Tibell, and Herbert Valerio Riedel for their review and comments.

You can find the API documentation for Network.Http.Client here (until Hackage generates the docs) and the source code at GitHub.

AfC

Updates

1. Code snippets updated to reflect API change made to buildRequest as of v0.4.0. You no longer need to pass the Connection object when building a Request.

Railway Signalling

By Andrew Cowie

I’ve long been interested in railways. Not because I’m a “foamer” (UK parlance — apparently some people foam at the mouth when they get the chance to watch passenger trains move, or so the railway employees would have it) or a “railfan” (the US term — Is that supposed to be like “sportsfan”? I mean, just because I want to take a photo that has a train in it doesn’t make me a weirdo, does it? Apparently), but for the same reason that engineers tend to interested in almost everything: how does it all work?

Not bad for a model railroad!

One part of real-world railways that is fascinating is the signalling necessary to make operations safe and efficient. It’s beguiling to an engineer in no small part because, by design, you can’t infer the behaviour of the entire system just watching the signals that go by as you’re on a train: automated signalling isn’t just about local conditions, but about the relationships between track conditions and the locations of trains across vast distances. The relevant Wikipedia pages have never been much help, either. As an unrequited model railroader, I’ve seen plenty of articles about modelling signals, and even descriptions of CTC machines and Train Orders, but still precious little about how signalling systems, as a whole, work. So I’ve long been curious.

A few days ago I came across a fantastic reference by one Carsten Lundsten about how signalling is done in North America. I’ve been engrossed. It appears the site was written somewhat for a European audience, but as far as I can tell it’s pretty informative for a Canadian and American one, too.

Rather than blathering on about which rule number a signal represents or what speed limits are, these documents concentrate on how signalling systems protect trains and how they have improved over time to provide greater automation and flexibility. If you’re interested, definitely start with Basics of North American Signaling and Safety principles.

Want to know what this means?

Be sure to make your way through to the page about Absolute Permissive Block signalling — by far and away the best explanation for APB and how APB is different than ABS I’ve ever seen, and I’ve been casually researching this for years.

Enjoy, all ye “train geeks”.

AfC

Model photos from Richard Stallard’s site about his Marbelup Valley railway.
Signal plant diagrams from Carsten Lundsten’s site, as above.

Defining OS specific code in Haskell

By Andrew Cowie

I’ve got an ugly piece of Haskell code:

pre { font-family: monospace; color: #000000; background-color: #ffffff; } .lnr { color: #eeeeec; } .hsBlockComment { color: #c4a000; } .Constant { color: #73d216; } .Statement { color: #8f5902; font-weight: bold; } .String { color: #204a87; font-weight: bold; } .PreProc { color: #f57900; } .hsImport { color: #000000; font-weight: bold; } .hsImportLabel { color: #73d216; font-weight: bold; } .Identifier { color: #729fcf; } .hsType { color: #000000; font-weight: bold; } .hsModuleName { color: #000000; font-weight: bold; } .Type { color: #73d216; font-weight: bold; } .Special { color: #ad7fa8; } .hsLineComment { color: #888a85; }

code.filename { font-style: italic; color: green; }

213 baselineContextSSL :: IO SSLContext
214 baselineContextSSL = do
215     ctx <- SSL.context    -- a completely blank context
216     contextSetDefaultCiphers ctx
217 #if defined __MACOSX__
218     contextSetVerificationMode ctx VerifyNone
219 #elif defined __WIN32__
220     contextSetVerificationMode ctx VerifyNone
221 #else
222     contextSetCADirectory ctx "/etc/ssl/certs"
223     contextSetVerificationMode ctx $
224         VerifyPeer True True Nothing
225 #endif
226     return ctx

this being necessary because the non-free operating systems don’t store their X.509 certificates in a place that openssl can reliably discover them. This sounds eminently solvable at lower levels, but that’s not really my immediate problem; after all, this sort of thing is what #ifdefs are for. The problem is needing to get an appropriate symbol based on what OS you’re using defined.

I naively assumed there would be __LINUX__ and __MACOSX__ and __WIN32__ macros already defined by GHC because, well, that’s just the sort of wishful thinking that powers the universe.

When I asked the haskell-cafe mailing list for suggestions, Krzysztof Skrzętnicki said that I could use in my project’s .cabal file. Nice, but problematic because you’re not always building using Cabal; you might be working in ghci, you might be using a proper Makefile to build your code, etc. Then Henk-Jan van Tuyl pointed out that you can get at the Cabal logic care of Distribution.System. Hey, that’s cool! But that would imply depending on and linking the Cabal library into your production binary. That’s bad enough, but the even bigger objection is that binaries aren’t portable, so what’s the point of having a binary that — at runtime! — asks what operating system it’s on? No; I’d rather find that out at build time and then let the C pre-processor include only the relevant code.

This feels simple and an appropriate use of CPP; even the symbol names look just about like what I would have expected (stackoverflow said so, must be true). Just need to get the right symbol defined at build time. But how?

Build Types

Running cabal install one sees all kinds of packages building and I’d definitely noticed some interesting things happen; some packages fire off what is obviously an autoconf generated ./configure script; others seem to use ghci or runghc to dynamically interpret a small Haskell program. So it’s obviously do-able, but as is often the case with Haskell it’s not immediately apparent where to get started.

Lots of libraries available on Hackage come with a top-level Setup.hs. Whenever I’d looked in one all I’d seen is:

  1 import Distribution.Simple
  2 main = defaultMain

which rather rapidly gave me the impression that this was a legacy of older modules, since running:

$ cabal configure
$ cabal build
$ cabal install

on a project without a Setup.hs apparently just Does The Right Thing™.

It turns out there’s a reason for this. In a project’s .cabal file, there’s a field build-type that everyone seems to define, and of course we’re told to just set this to “Simple”:

 27 build-type:          Simple

what else would it be? Well, the answer to that is that “Simple” is not the default; “Custom” is (really? weird). And a custom build is one where Cabal will compile and invoke Setup.hs when cabal configure is called.

Ahh.

When you look in the documentation of the Cabal library (note, this is different from the cabal-install package which makes the cabal executable we end up running) Distribution.Simple indeed has defaultMain but it has friends. The interesting one is defaultMainWithHooks which takes this monster as its argument; sure enough, there are pre-conf, post-conf, pre-build, post-build, and so on; each one is a function which you can easily override.

 20 main :: IO ()
 21 main = defaultMainWithHooks $ simpleUserHooks {
 22        postConf = configure
 23     }
 24 
 25 configure :: Args -> ConfigFlags -> PackageDescription -> LocalBuildInfo -> IO ()
 26 configure _ _ _ _ = do
 27     ...

yeay for functions as first class objects. From there it was a simple matter to write some code in my configure function to call Distribution.Simple’s buildOS and write out a config.h file with the necessary #define I wanted:

  1 #define __LINUX__

Include Paths

We’re not quite done yet. As soon as you want to #include something, you have to start caring about include paths. It would appear the compiler, by default, looks in the same directory as the file it is compiling. Fair enough, but I don’t really want to put config.h somewhere deep in the src/Network/Http/ tree; I want to put it in the project’s top level directory, commonly known as ., also known as “where I’m editing and running everything from”. So you have to add a -I"." option to ghc invocations in your Makefiles, your .cabal file needs to be told in its way:

 61 library
 62   include-dirs:      .

and as for ghci, it turns out you can put a .ghci in your sources:

  1 :set -XOverloadedStrings
  2 :set +m
  3 :set -isrc:tests
  4 :set -I.

and if you put that in your project root directory, running ghci there will work without having to specify all that tedious nonsense on the command line.

The final catch is that you have to be very specific about where you put the #include directive in your source file. Put it at the top? Won’t work. After the pragmas? You’d think. Following the module statement? Nope. It would appear that it strictly has to go after the imports and before any real code. Line 65:

 47 import Data.Monoid (Monoid (..), (<>))
 48 import qualified Data.Text as T
 49 import qualified Data.Text.Encoding as T
 50 import Data.Typeable (Typeable)
 51 import GHC.Exts
 52 import GHC.Word (Word8 (..))
 53 import Network.URI (URI (..), URIAuth (..), parseURI)
 64 
 65 #include "config.h"
 66 
 67 type URL = ByteString
 68 
 69 --
 70 -- | Given a URL, work out whether it is normal or secure, and then
 71 -- open the connection to the webserver including setting the
 72 -- appropriate default port if one was not specified in the URL. This
 73 -- is what powers the convenience API, but you may find it useful in
 74 -- composing your own similar functions.
 75 --
 76 establishConnection :: URL -> IO (Connection)
 77 establishConnection r' = do
 78     ...

You get the idea.

Choices

Several people wrote to discourage this practice, arguing that conditional code is the wrong approach to portability. I disagree, but you may well have a simple piece of code being run dynamically that would do well enough just making the choice at runtime; I’d be more comfortable with that if the OS algebraic data type was in base somewhere; linking Cabal in seems rather heavy. Others tried to say that needing to do this at all is openssl’s fault and that I should be using something else. Perhaps, and I don’t doubt that we’ll give tls a try at some point. But for now, openssl is battle-tested crypto and the hsopenssl package is a nice language binding and heavily used in production.

Meanwhile I think I’ve come up with a nice technique for defining things to drive conditional compilation. You can see the complete Setup.hs I wrote here; it figures out which platform you’re on and writes the .h file accordingly. If you have need to do simple portability conditionals, you might give it a try.

AfC

A quick test on WordPress Open ClipArt Library plugin

By Xiangfu Liu

• Click the ClipArt icon
• Download clipart first
• Select the clipart from Library
• Insert to Post it will be looks like:

Tips for smooth scrolling web pages (EdgeConf follow-up)

By Chris Lord

I’m starting to type this up as EdgeConf draws to a close. I spoke on the performance panel, with Shane O’Sullivan, Rowan Beentje and Pavel Feldman, moderated by Matt Delaney, and tried to bring a platform perspective to the affair. I found the panel very interesting, and it reminded me how little I know about the high-level of web development. Similarly, I think it also highlighted how little consideration there usually is for the platform when developing for the web. On the whole, I think that’s a good thing (platform details shouldn’t be important, and they have a habit of changing), but a little platform knowledge can help in structuring things in a way that will be fast today, and as long as it isn’t too much of a departure from your design, it doesn’t hurt to think about it. At one point in the panel, I listed a few things that are particularly slow from a platform perspective today. While none of these were intractable problems, they may not be fixed in the near future and feedback indicated that they aren’t all common knowledge. So what follows are a few things to avoid, and a few things to do that will help make your pages scroll smoothly on both desktop and mobile. I’m going to try not to write lies, but I hope if I get anything slightly or totally wrong, that people will correct me in the comments and I can update the post accordingly

Avoid reflow

When I mentioned this at the conference, I prefaced it with a quick explanation of how rendering a web page works. It’s probably worth reiterating this. After network and such have happened and the DOM tree has been created, this tree gets translated into what we call the frame tree. This tree is similar to the DOM tree, but it’s structured in a way that better represents how the page will be drawn. This tree is then iterated over and the size and position of these frames are calculated. The act of calculating these positions and sizes is referred to as reflow. Once reflow is done, we translate the frame tree into a display list (other engines may skip this step, but it’s unimportant), then we draw the display list into layers. Where possible, we keep layers around and only redraw parts that have changed/newly become visible.

Really, reflow is actually quite fast, or at least it can be, but it often forces things to be redrawn (and drawing is often slow). Reflow happens when the size or position of things changes in such a way that dependent positions and sizes of elements need to be recalculated. Reflow usually isn’t something that will happen to the entire page at once, but incautious structuring of the page can result in this. There are quite a few things you can do to help avoid large reflows; set widths and heights to absolute values where possible, don’t reposition or resize things, don’t unnecessarily change the style of things. Obviously these things can’t always be avoided, but it’s worth thinking if there are other ways to achieve the result you want that don’t force reflow. If positions of things must be changed, consider using a CSS translate transform, for example – transforms don’t usually cause reflow.

If you absolutely have to do something that will trigger reflow, it’s important to be careful how you access properties in JavaScript. Reflow will be delayed as long as possible, so that if multiple things happen in quick succession that would cause reflow, only a single reflow actually needs to happen. If you access a property that relies on the frame tree being up to date though, this will force reflow. Practically, it’s worth trying to batch DOM changes and style changes, and to make sure that any property reads happen outside of these blocks. Interleaving reads and writes can end up forcing multiple reflows per page-draw, and the cost of reflow can add up quickly.

Avoid drawing

This sounds silly, but you should really only make the browser do as little drawing as is absolutely necessary. Most of the time, drawing will happen on reflow, when new content appears on the screen and when style changes. Some practical advice to avoid this would be to avoid making DOM changes near the root of the tree, avoid changing the size of things and avoid changing text (text drawing is especially slow). While repositioning doesn’t always force redrawing, you can ensure this by repositioning using CSS translate transforms instead of top/left/bottom/right style properties. Especially avoid causing redraws to happen while the user is scrolling. Browsers try their hardest to keep up the refresh rate while scrolling, but there are limits on memory bandwidth (especially on mobile), so every little helps.

Thinking of things that are slow to draw, radial gradients are very slow. This is really just a bug that we should fix, but if you must use CSS radial gradients, try not to change them, or put them in the background of elements that frequently change.

Avoid unnecessary layers

One of the reasons scrolling can be fast at all on mobile is that we reduce the page to a series of layers, and we keep redrawing on these layers down to a minimum. When we need to redraw the page, we just paste these layers that have already been drawn. While the GPU is pretty great at this, there are limits. Specifically, there is a limit to the amount of pixels that can be drawn on the screen in a certain time (fill-rate) – when you draw to the same pixel multiple times, this is called overdraw, and counts towards the fill-rate. Having lots of overlapping layers often causes lots of overdraw, and can cause a frame’s maximum fill-rate to be exceeded.

This is all well and good, but how does one avoid layers at a high level? It’s worth being vaguely aware of what causes stacking contexts to be created. While layers usually don’t exactly correspond to stacking contexts, trying to reduce stacking contexts will often end up reducing the number of resulting layers, and is a reasonable exercise. Even simpler, anything with position: fixed, background-attachment: fixed or any kind of CSS transformed element will likely end up with its own layer, and anything with its own layer will likely force a layer for anything below it and anything above it. So if it’s not necessary, avoid those if possible.

What can we do at the platform level to mitigate this? Firefox already culls areas of a layer that are made inaccessible by occluding layers (at least to some extent), but this won’t work if any of the layers end up with transforms, or aren’t opaque. We could be smarter with culling for opaque, transformed layers, and we could likely do a better job of determining when a layer is opaque. I’m pretty sure we could be smarter about the culling we already do too.

Avoid blending

Another thing that slows down drawing is blending. This is when the visual result of an operation relies on what’s already there. This requires the GPU (or CPU) to read what’s already there and perform a calculation on the result, which is of course slower than just writing directly to the buffer. Blending also doesn’t interact well with deferred rendering GPUs, which are popular on mobile.

This alone isn’t so bad, but combining it with text rendering is not so great. If you have text that isn’t on a static, opaque background, that text will be rendered twice (on desktop at least). First we render it on white, then on black, and we use those two buffers to maintain sub-pixel anti-aliasing as the background varies. This is much slower than normal, and also uses up more memory. On mobile, we store opaque layers in 16-bit colour, but translucent layers are stored in 32-bit colour, doubling the memory requirement of a non-opaque layer.

We could be smarter about this. At the very least, we could use multi-texturing and store non-opaque layers as a 16-bit colour + 8-bit alpha, cutting the memory requirement by a quarter and likely making it faster to draw. Even then, this will still be more expensive than just drawing an opaque layer, so when possible, make sure any text is on top of a static, opaque background when possible.

Avoid overflow scrolling

The way we make scrolling fast on mobile, and I believe the way it’s fast in other browsers too, is that we render a much larger area than is visible on the screen and we do that asynchronously to the user scrolling. This works as the relationship between time and size of drawing is not linear (on the whole, the more you draw, the cheaper it is per pixel). We only do this for the content document, however (not strictly true, I think there are situations where whole-page scrollable elements that aren’t the body can take advantage of this, but it’s best not to rely on that). This means that any element that isn’t the body that is scrollable can’t take advantage of this, and will redraw synchronously with scrolling. For small, simple elements, this doesn’t tend to be a problem, but if your entire page is in an iframe that covers most or all of the viewport, scrolling performance will likely suffer.

On desktop, currently, drawing is synchronous and we don’t buffer area around the page like on mobile, so this advice doesn’t apply there. But on mobile, do your best to avoid using iframes or having elements that have overflow that aren’t the body. If you’re using overflow to achieve a two-panel layout, or something like this, consider using position:fixed and margins instead. If both panels must scroll, consider making the largest panel the body and using overflow scrolling in the smaller one.

I hope we’ll do something clever to fix this sometime, it’s been at the back of my mind for quite a while, but I don’t think scrolling on sub-elements of the page can ever really be as good as the body without considerable memory cost.

Take advantage of the platform

This post sounds all doom and gloom, but I’m purposefully highlighting what we aren’t yet good at. There are a lot of things we are good at (or reasonable, at least), and having a fast page need not necessarily be viewed as lots of things to avoid, so much as lots of things to do.

Although computing power continues to increase, the trend now is to bolt on more cores and more hardware threads, and the speed increase of individual cores tends to be more modest. This affects how we improve performance at the application level. Performance increases, more often than not, are about being smarter about when we do work, and to do things concurrently, more than just finding faster algorithms and micro-optimisation.

This relates to the asynchronous scrolling mentioned above, where we do the same amount of work, but at a more opportune time, and in a way that better takes advantage of the resources available. There are other optimisations that are similar with regards to video decoding/drawing, CSS animations/transitions and WebGL buffer swapping. A frequently occurring question at EdgeConf was whether it would be sensible to add ‘hints’, or expose more internals to web developers so that they can instrument pages to provide the best performance. On the whole, hints are a bad idea, as they expose platform details that are liable to change or be obsoleted, but I think a lot of control is already given by current standards.

On a practical level, take advantage of CSS animations and transitions instead of doing JavaScript property animation, take advantage of requestAnimationFrame instead of setTimeout, and if you find you need even more control, why not drop down to raw GL via WebGL, or use Canvas?

I hope some of this is useful to someone. I’ll try to write similar posts if I find out more, or there are significant platform changes in the future. I deliberately haven’t mentioned profiling tools, as there are people far more qualified to write about them than I am. That said, there’s a wiki page about the built-in Firefox profiler, some nice documentation on Opera’s debugging tools and Chrome’s tools look really great too.

OpenPhoenux FOSDEM Impressions

By SlyBlog

FOSDEM 2013 is over and I had a really nice time again at Brussels, together with the OpenPhoenux/GTA04 team. It was especially nice to meet some people from our community in person and discuss interesting ideas with them.

Furthermore, it was great to meet people, who didn’t know about neither OpenPhoenux nor Openmoko, having cool ideas, which the OpenPhoenux GTA04 open hardware plattform would enable them to do.

We even got interviewed by Sam – a moviemaker, ceating a movie called “Year of Open Source” about living in a free software/hardware world for (at least) one year.

As stated, I had a nice time and I’m looking forward to meeting with the OpenPhoenux community soon again. Now, as a picture says more than 1000 words, here are some photographs from our FOSDEM booth:

Update: Now there is a video available as well.

Firefox for Android in 2013

By Chris Lord

Lucas Rocha and I gave a talk at FOSDEM over the weekend on Firefox for Android. It went ok, I think we could have rehearsed it a bit better, but it was generally well-received and surprisingly well-attended! I’m sure Lucas will have the slides up soon too. If you were unfortunate enough not to have attended FOSDEM, and doubly unfortunate that you missed our talk (guffaw), we’ll be reiterating it with a bit more detail in the London Mozilla space on February 22nd. We’ll do our best to answer any questions you have about Firefox for Android, but also anything Mozilla-related. If you’re interested in FirefoxOS, there may be a couple of phones knocking about too. Do come along, we’re looking forward to seeing you

p.s. I’ll be talking on a performance panel at EdgeConf this Saturday. Though it’s fully booked, I think tickets occasionally become available again, so might be worth keeping an eye on. They’ll be much cleverer people than me knocking about, but I’ll be doing my best to answer your platform performance related questions.

OpenPhoenux at FOSDEM 2013

By SlyBlog

The team of OpenPhoenux presented the development process of the open hardware and free software powered mobile plattform “GTA04″ at FOSDEM 2011 and 2012, including working prototypes and preview-boards for developers.


Now, that the OpenPhoenux has taken off to reach a broader audience, we’ll show off all the open hardware (prototypes of new products and finished devices) at FOSDEM 2013. We hope you’re already eager to have your hands on the latest and greatest open mobile handhelds, which will be presented at our booth!

• Letux 2804 smartphone
• Letux 7004 tablet
• Letux 3704 professional PDA

All of those are based on the GTA04 open mobile plattform, whose latest revision GTA04-A5 is ready and waiting for pre-orders to finance the next production run.

In addition, there are still a few complete GTA04 (revision A4) smartphone units on stock at the Openmoko reseller Pulster.eu. Contact him for further information.

Those are all great hardware projects for Linux/FOSS enthusiasts and freedom lovers! But the World of OpenPhoenux is not limited to hardware gadgets, but is connected to several other open mobile and communication projects, as well:

• free PowerVR SGX 3D driver, reverse engineering initiative
• Limesco, open mobile telephony provider
• SHR/FSO, QtMoko and Replicant mobile Linux distributions

   

So, if you’re visiting FOSDEM this year and are interested in open mobile communications it is a must to drop by the “World of OpenPhoenux”-booth (No. 3) in building AW, right next to Jolla/Sailfish, Hackable Devices/MakerBot, Enlightenment and more!

We’re looking forward to meet you there, answer your questions and demo the devices to you!

[GTA04] Une nouvelle production en voie !

By openmoko-fr

GoldenDelicious a annoncé la production de nouvelles cartes mères "grand publique" (c'est la deuxième version grand publique) et tout se passe sur le magasin en ligne. Comme l'année passée, le prix est élevé, c'est le problème des petites productions, mais il y a possibilité d'avoir des rabais si vous faites des achats groupés.

Bonjour tout le monde !

Ben Nanonote: UBB + 软件串口

By Xiangfu Liu

Werner create a libubb for ben nanonote memcard slot, click here for more info.

Towards the end of 2012

By Michael "mickeyl" Lauer

Hi folks!

Obviously I don’t manage to update this blog more than a few times a year. I must confess that – for smaller status messages – I find Facebook and Twitter working quite well. So if you want to stay in touch a bit more, hop over to my page @ Michael Lauer or follow my Tweets @ DrMickeyLauer.

The biggest tasks this year was getting Lara Marie to sleep well and buying a house, both which we finished successfully. Right now we have a hole in the ground, but it’s supposed to be finished by October 2013. I’m going to report about the progress now and then.

FOSS-wise I didn’t manage to do anything meaningful more than visiting FOSDEM and the OHSW this year. I tried to catch up with what’s happening in FSO, Vala, and OpenEmbedded though. Since I do no longer use OE on a frequent basis, I decided to not run for re-election as OE board member, thus also resigning from being OE e.V. president. I’m quite happy to hand the paperwork over to someone else

With Lara Marie growing older (she’s now 18 months), I enjoy being a father more and more. While mommy was #1 in the first year, it becomes apparent that I’m #1 in the 2nd year, helping the little one to form her individuality and her will.

Company-wise 2012 was a bit of a ride as due to the economy some of our biggest clients postponed their app updates and we struggled a bit getting enough contracts to keep the four of us busy. Then again, we worked on our own apps in the free time and I’m happy to announce the next major version of Volksradio / Just Radio, which is going to ship soon.

I wish all of you a merry 2013!

Yours, Mickey!

Openmoko/OpenPhoenux GTA04 jumps off

By SlyBlog

Table of Contents

The Story

All started off after Openmoko Inc. began to ship the Openmoko Neo 1973 (GTA01) and Neo Freerunner (GTA02) in 2007, which are fully open source smartphones. A dream became true for many open source lovers and technology enthusiasts at that time.

Sadly, Openmoko Inc. canceled their efforts for an open smartphone in 2009. But due to their openness (schematics, hardware specifications, software) it was possible for enthusiasts from the Openmoko community, with great support from Golden Delicious Computers (one of the german Openmoko distributors), to develop a new and modern open smartphone – the OpenPhoenux GTA04.

Technical Specifications

• 1GHz ARM Cortex-A8 processor (DM3730)
• PowerVR integrated graphics (SGX530)
• 2.8” resistive VGA touchscreen
• HSDPA 3G modem (Option GTM601)
• 512MB RAM
• 1GB internal memory & SDHC card slot (up to 32GB)
• WLAN, Bluetooth, GPS, FM Transceiver
• Accelerometer, Compass, Gyroscope, Barometric Altimeter
• USB 2.0 OTG port, 2.5mm headset port, GPS antenna port, video out

Prototypes & First production run (2012)

Golden Delicious Computers and the enthusiasts from the Openmoko community started off with the idea of stuffing a BeagleBoard into a Neo Freerunner case and connecting an USB UMTS dongle to it – this was the first prototype GTA04A1, announced in late 2010 and presented at OHSW 2010 and FOSDEM 2011.


Next, they started to integrate all of this onto a single PCB of the same size as the Neo 1973/Freerunner boards, so it could fit into their cases, use their batterys, antennas, speakers, buttons and touchscreens. This board was then called GTA04A2 – the second prototype, which had quite some problems. A redesign of that prototype resulted to the GTA04A3 “Early-Adpoter” boards, which were shipped to about 20 develpoers, enabling them to start with software development for the platform.

The next step was to reach out to the people by presenting the project on other conventions like the FOSDEM 2012, Openmobility 2012, Linuxwochen 2012 and the LinuxTag 2012, to produce bigger batches of GTA04s. To finance the first production run of the GTA04A4 (which includes some more fixes over the GTA04A3) Goldelico collected pre-orders from interested people from the Openmoko community. They were able to collect about 250 pre-orders and were thus able to start the first big OpenPhoenux production run.

GTA04 Boards in vapour phase soldering machine

“Now as we have finally learned everything about mass production [...], it is time to kick-start the next [production run].” (Dr. Schaller, Golden Delicious Computers)

Next production run (2013) – Out now!

To finance the 2nd production run of about 200 more GTA04 boards Goldelico started to collect pre-orders just recently. The production should run smoothly that time, as there were no big changes and the process is known. Production will start in march 2013 and the boards should ship shortly after that.

If you’re interested in pre-ordering one of those new A5 boards, check out the Handheld-Linux store. If you’re interested in getting a complete “Letux 2804″ unit (GTA04 board build into an Openmoko Freerunner case) now you can get it from the first OpenPhoenux reseller Pulster.eu (stock is limited!).

• Pre-order your GTA04 (revision A5) now.
• Buy an Letux 2804 (revision A4) from stock.

OpenPhoenux ecosystem

While preparing the next revision of the GTA04 and solving production problems, the guys at Goldelico started to experiment with other GTA04 powered devices. So it is no secret, that there is already an open GTA04 tablet prototype (Letux 7004) and the ready to use GTA04 professional PDA (Letux 3704), which can be used e.g. in logistics (RFID), measurement (GPS) or guiding tasks (big sunlight readable screen & long lasting battery).
The software for the GTA04 is already in a good shape as well. Besides the Debian (squeeze) hardware-validation image, there is the Debian based QtMoko distribution and the FSO based SHR distribution, which makes the GTA04 useable as a daily phone. Furthermore, a port of Replicant (fully open source Android) is in the works. All in all the GTA04 owners in the OpenPhoenux community seem to be satisfied with their devices, so is Nikolaus Schaller from Goldelico:

“[...] I enjoy every day to be member of this OpenPhoenux community. Let’s make the OpenPhoenux fly to new levels next year!” (Dr. Schaller, Golden Delicious Computers)

I really appreciate to see our community grow again and can just second Nikolaus’ sentence. I wish the community a successful year 2013, in which we can satisfy a lot of free software enthusiasts and freedom lovers needs. OpenPhoenux – Free your phone!

Some more Goodies

There are still some more goodies in the pipeline… So stay tuned!

Make PCB at home

By Xiangfu Liu

The document is here: http://en.qi-hardware.com/wiki/Mini-slx9.

Inside a cavity duplexer

By Harald "LaF0rge" Welte

In many cellular systems (GSM or otherwise) there is a frequency duplex between the uplink and downlink frequency band. If you use a single antenna to serve a BTS, then somehow you need to split the frequency band between the Rx and Tx side by means of a Duplexer.

The most common technology for this is the so-called Cavity Duplexer. I've used those devices (and seen them in use) for a long time, but never really opened one so far. The problem is that they are finely tuned, and each mechanical change can severely impact performance. As I had to repair a broken SMA socket on one of them recently, I took the chance to take a picture

In the first picture you can see the bottom side. This consists of a milled aluminum block, with a series of circular cavities. The Tx output of the BTS is connected to the SMA socket on the bottom right, the antenna to the SMA socket on the top side, and the Rx port to the SMA socket on the bottom left of the picture:

The small cylindrical objects in the center of the cavities are not milled from the same part, but they are separate pieces mounted by screws from the bottom of the unit.

The second picture shows the top section of the duplexer:

You can see a ~ 4mm aluminum plate with lots of (now empty) holes which are for the ~ 117 screws with which the top plate is screwed against the bottom part shown in the first picture.

The important part, however, are the screws that you can see sticking out of the top part. Those are used for tuning and present "obstacles" in the path of the waves as they pass through the cavities.

The big miracle for me is not that there are some resonances which build up a filter, but that you can actually transfer as much as 100W of RF power from the Tx input through to the antenna output.

Integrating Vim and GPG

By Andrew Cowie

Quite frequently, I need to take a quick textual note but when the content is sensitive, even just transiently, well, some things shouldn’t be left around on disk in plain text. Now before you pipe up with “but I encrypt my home directory” keep in mind that that only pretects data against it being read in the event your machine is stolen; if something gets onto your system while it’s powered up and you’re logged in, the file is there to read.

So for a while my workflow there has been the following rather tedious sequence:

$ vi document.txt
$ gpg --encrypt --armour 
    -r andrew@operationaldynamics.com 
    -o document.asc document.txt
$ rm document.txt
$

and later on, to view or edit the file,

$ gpg --decrypt -o document.txt document.asc 
$ view document.txt
$ rm document.txt

(yes yes, I could use default behaviour for a few things there, but GPG has a bad habit of doing things that you’re not expecting; applying the principle of least surprise seems a reasonable defensive measure, but fine, ok

$ gpg < document.asc

indeed works. Pedants, the lot of you).

Obviously this is tedious, and worse, error prone; don’t be overwriting the wrong file, now. Far more serious, you have the plain text file sitting around while you’re working on it, which from an operational security standpoint is completely unacceptable.

vim plugin

I began to wonder if there was better way of doing this, and sure enough, via the volumous Vim website I eventually found my way to this delightful gem: https://github.com/jamessan/vim-gnupg by James McCoy.

Since it might not be obvious, to install it you can do the following: grab a copy of the code,

$ cd ~/src/
$ mkdir vim-gnupg
$ cd vim-gnupg/
$ git clone git://github.com/jamessan/vim-gnupg.git github
$ cd github/
$ cd plugin/
$ ls

Where you will see one gnupg.vim. To make Vim use it, you need to put in somewhere vim will see it, so symlink it into your home directory:

$ mkdir ~/.vim
$ mkdir ~/.vim/plugin
$ cd ~/.vim/plugin/
$ ln -s ~/src/vim-gnupg/github/plugin/gnupg.vim .
$

Of course have a look at what’s in that file; this is crypto and it’s important to have confidence that the implementation is sane. Turns out that the gnupg.vim plugin is “just” Vim configuration commands, though there are some pretty amazing contortions. People give Emacs a bad rap for complexity, but whoa. :). The fact you can do all that in Vim is, er, staggering.

Anyway, after all that, it Just Works™. I give my filename a .asc suffix, and ta-da:

$ vi document.asc

the plugin decrypts, lets me edit clear text in memory, and then re-encrypts before writing back to disk. Nice! For a new file, it prompts for the target address (which is one’s own email for personal use) and then on it’s way. [If you’re instead using symmetrical encryption, I see no way around creating an empty file with gpg first, but other than that, it works as you’d expect]. Doing all of this on a GNOME 3 system, you already have a gpg-agent running, so you get all the sexy entry dialogs and proper passphrase caching.

I’m hoping a few people in-the-know will have a look at this and vet that this plugin doing the right thing, but all in all this seems a rather promising solution for quickly editing encrypted files.

Now if we can just convince Gedit to do the same.

AfC

Open Hard- and Software Workshop 2012

By SlyBlog

Soon this years Open Hard- and Software Workshop (OHSW) will take place in Garching (near Munich) at the TUM Campus Garching. There will be a lot of intetresting topics to discuss and people to meet. Make sure to drop by if you find some time!

The agenda and further details are now available online:

• OHSW Homepage
• Agenda OHSW 2012
• Further details about OHSW 2012