=== jussi01_ is now known as jussi === david is now known as Guest58753 === jussi01_ is now known as jussi === genupulas is now known as raju [15:59] Everyone ready for the last day or UADW? === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: App Developer Week - Current Session: Getting A Grip on Your Apps: Multitouch on GTK apps using Libgrip - Instructors: Satoris [16:00] the people on #ubuntu-classroom-chat say yes! :) [16:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/09/09/%23ubuntu-classroom.html following the conclusion of the session. [16:01] Hello everyone and welcome to this last edition of the Ubuntu App Developer Week === BuZ-T is now known as BuZZ-T [16:01] lots of sessions with great speakers today, [16:02] speaking of which, let's give a warm welcome to Satoris, who'll be talking about adding multitouch support to your GTK+ apps with libgrip! [16:03] Hi all. My name is Jussi Pakkanen, and I am a member of the uTouch team at Canonical. [16:03] Today I'll be talking about adding gesture support for existing apps using libgrip. [16:04] Libgrip is a simple, "GTK-flavored" library for gestures. [16:04] The uTouch stack has lots of other parts as well, but I won't talk about them. If there is demand and time at the end, I can give an overview. [16:05] The first thing you might want to do is to open the libgrip tutorial page, which is here: https://wiki.ubuntu.com/Multitouch/GripTutorial [16:06] I'm going to go through it so it pays to have it open. Get the code as well, it is attatched to the page. [16:06] A word of warning, I'm going to describe libgrip 0.3.1 and newer. [16:07] This is not available in Natty, and won't be. So if you are using Natty, you need to compile libgrip from source. [16:07] There is also a known bug in Oneiric's libgrip. We pushed a fix to that some 20 minutes ago. [16:08] So it should be available soon. [16:09] The main things to know about libgrip are device types and subscriptions. [16:09] There are three different kinds of devices: touchscreens, touchpads and independent devices (Apple Magic Mice). [16:10] Whenever you say you want certain types of gestures, you create a subscription. [16:11] So the basic structure of a libgrip application is to subscribe to gestures, such as "one finger drags on touchscreens" or "two finger rotates on any device". [16:11] When these gestures are performed, libgrip calls your callback functions. [16:11] It is very similar to how GTK sends "redraw" or "mouse motion" events. [16:12] I forgot to mention that libgrip 0.3 requires GTK 3.0. You can't use it on GTK+ 2 apps. [16:12] But who has those anymore. :) [16:13] The subscription is describe on the tutorial page under "subscription". [16:14] It is very straightforward. [16:14] In the tutorial all subscriptions have the same callback function. [16:15] You can have different ones, it does not really matter. [16:15] People seem to prefer having one and then demultiplexing stuff by themselves. [16:16] In the test app we have a viewport and we want to be able to move it around with finger drags. [16:17] So we subscribe two finger drags for all devices and also one finger drags for touchscreens. [16:18] Very simple. [16:18] The gesture callback function is also quite straightforward. [16:19] We check how much the user has dragged and update the viewport correspondingly. [16:19] However there is one thing to note. [16:20] When dragging on a touchpad, the scroll directions need to be changed. [16:20] This is because historically dragging down on a touchpad moves the "document" up. [16:21] This is something that may change in the future, newest OSX has the option to make drags on touchpad the same as on touchscreens. [16:22] Libgrip does not invert the axes for you, because it can't know whether you are dragging an object or scrolling a view. [16:23] This is the app developer's responsibility. [16:24] The rest of the code is pretty standard GTK. [16:24] So in this case adding gestures took a couple of dozen of lines of code. [16:25] For a more complicated example, I recommend you to look at the gesture patches for Evince and EOG. [16:25] They can be found in the respective oneiric source packages. [16:26] This means that the oneiric's EOG and Evince will be gesture enabled out of the box. [16:28] Those patches have drags, document rotations and pinch to zoom. [16:29] Subscribing to gestures is quite simple, but there are certain things that will most likely surprise you. [16:29] The main thing being that gestures that human beings make are rarely pure. [16:30] Simply dragging two fingers along most likely triggers pinches or rotations as well. [16:30] That is because the human beings are not robots, at least not yet. [16:31] Their fingers move involuntarily, even if they try to keep them steady. [16:32] Unfortunately it is impossible to differentiate between "drag only, but fingers get slightly rotated accidentally" and "drag with a touch of rotation" in the general case. [16:33] So again, the app developer has to do work here. [16:34] Usually it is best to design the UI so that spurious events do not matter. [16:35] The basic guideline is that the gesture recognition stack can not read the user's mind. That is the job of an app developer. [16:36] Another thing to note is that trackpads especially have very different sizes. [16:37] A basic mini-laptop's touchpad is only about one quarter (or less) of a MacBook Pro's touch pad. [16:38] So you really have to consider these things when dealing with, e.g. pinch sensitivity. [16:38] And on the other hand if you want your app to be used on a touch screen, those are even bigger. [16:40] And the last thing: you should probably never subscribe to single finger drags on touchpads. [16:40] That grabs the mouse pointer, because one finger drags are mapped to mouse motion. [16:42] That's roughly what I had prepared. I'm open for questions. [16:44] tomalan asked: The MacBook Pro touchpad can distinguish between "tap" and "click". Is libgrip also capable of this? [16:45] If by "click" you mean pushing the pad so that it produces a mouse click, then yes. [16:45] Pushing it so hard that it produces the clicking sound, that is. [16:46] I use a Macbook for development (and am using it at this very moment) and have set it up so that taps do not produce mouse clicks and you use two fingers for scrolling. [16:47] Rather than using the edge for scrolling. [16:48] You can get the taps by subscribing to the GRIP_GESTURE_TAP event. [16:49] I'm not sure what happens if you have set it up so that tapping the pad lightly causes a mouse click. [16:50] I find that behaviour hugely irritating and always disable it as the first thing I do. [16:50] tomalan asked: In OSX i also like the feature that i open the context menu by "clicking" with two fingers and if I keep clicked and move to the menu entry and then release the selected menu entry gets activated. Do you know if it's possible to configure Ubuntu to behave the same? [16:50] There are 10 minutes remaining in the current session. [16:51] You can set up Ubuntu so that clicking with two fingers creates a right-click. That brings up a context menu most of the time. [16:51] This behaviour might even be the default. Not sure though. [16:53] You have to release one finger to be able to select stuff on the menu. [16:53] tomalan asked: I meant that i keep the pad pressed with one finger, navigate to my target with the other one and the release the second finger to activate the entry, so i don't have to click twice [16:54] This needs some plumbing and code changes that are not present currently AFAIK. But we will work on these issues in the next cycle. [16:55] There are 5 minutes remaining in the current session. [16:58] Last chance for questions. === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: App Developer Week - Current Session: Creating a Google Docs Lens - Instructors: njpatel [17:00] thanks Satoris for a great session! [17:00] Logs for this session will be available at http://irclogs.ubuntu.com/2011/09/09/%23ubuntu-classroom.html following the conclusion of the session. [17:01] Hi! My name is Neil Patel, I'm the System Architect in the Canonical Desktop Experience (DX) Team and I am also the Technical Lead for the Unity project. I'd like to talk today about the massive changes we've done to the Lens infrastructure in Unity this cycle, with an introduction to writing a simple Google Docs Lens & Scope! [17:01] Although I have a rough outline for at least the first half of this session, feel free to ask questions in #ubuntu-classroom-chat as you have them, and I'll answer as soon as it makes sense :) [17:01] I should add, all the information here, and much more, will be available on https://wiki.ubuntu.com/Unity/Lenses later on today and across the weekend. [17:02] So, a quick history on Lenses: They started off being named "Places", and they were, in Natty, little daemons that would show up on your Launcher and allow you to search through Applications/Files/AskUbuntu/Gwibber etc. [17:02] Although Lenses in that form were pretty good, we wanted them to be more powerful (as did the Lens authors!) so for Oneiric we decided that we should swallow our pride and re-archtect them to provide more features, and make it easier to add new features later on i.e. make a base API that we can carry forward through 12.04 and beyond. [17:02] So, people who are currently re-writing their Places as Lenses, sorry :) We promise it won't be this bad again! [17:02] One of the largest changes we made to the Lenses was to split out the concept of what controls the renderering/filters of a Lens to what provides data. In essence, we wanted to be able to make a Lens be able to just define it's properties, but then let anything be able to provide data to the Lens. [17:03] So, the job of a Lens is to create an Lens instance, add some categories, add some filters and thats it, it no longer does any searching of it's own. So what does the searching? Scopes! [17:03] Scopes are the engine of the Dash. They plug into Lenses over D-Bus and then provide data to the Lens. [17:03] This is best described in an example: We now ship a Music Lens by default in Oneiric. It ships with a Banshee Scope which provides search results for Banshee. However, instead of being stuck with a usesless Lens because you use Amarok or Rhythmbox (or you having to create an alternative Lens for your favourite music player), you can just create the Amarok or Rhythmbox Scope for the Music Lens. [17:03] The Scope would plug right into the Lens, providing results from Amarock in the main Lens. [17:04] Also, a Lens is not confined to having only one Scope. The Music Lens could easily have a Banshee Scope, a GrooveShark Scope, a Spotify Scope etc. So you can search multiple data sources from one Lens, just install the ones you like :) [17:04] Due to not many people likely to want to ship a Lens by itself without a Scope (wouldn't be very useful!) we have made it easy for you to ship a default Scope with your Lens, without having to create an extra daemon, and you'll see this later on. [17:04] [17:05] The largest user-visible change we made for a Lens is it can now create Filters [17:05] Filters allow the user to easily, er, filter the search results [17:05] We ship with four filters by default: CheckOption, RadioOption, MultiRange and Ratings [17:06] You can create as many as you'd like, and show/hide them as needed [17:07] The filters API is meant to be easy to use and we hope to add more filters in the 12.04 cycle [17:07] (we'd love to hear ideas!) [17:08] woah, lag :) [17:09] Andy80 asked: how do we control how the data found by a scope is displayed? The Lens provide the filters, ok... but can I design the view and incorporate it into the dash? [17:09] The Lens controls how the results are displayed per-category [17:09] So, we ship with a vertical or horizontal orientation for the results, but we really would like to see more [17:10] The complexity comes in that the results are rendered by Unity, and so must be written with Nux [17:10] We'd happily accept new renderers and are planning to add some whizzbang ones for 12.04! [17:11] [17:11] On that point, the two most important things a Lens will do is add Filters and Categories to itself [17:12] We spoke about filters (and will come back to that in the example), so i should cover Categories [17:12] Categories are headings inside the dash when you search for something inside a Lens [17:13] e.g. the Apps lens has "Most Frequently Used", "Installed" and "Apps Available for Download" [17:14] When you want to add a result to the results model inside a Scope, you tell Unity which category to put the result in. If a Category has no results, Unity will not show it [17:14] We normally add three Categories, but there is no limit [17:14] three just seems to fit nicely in the way Unity renderers the Dash :D [17:15] Andy80 asked: how do we control how the data found by a scope is displayed? The Lens provide the filters, ok... but can I design the view and incorporate it into the dash? [17:15] woops [17:15] Andy80 asked: I suppose we will have to write two different Lens (one for Unity and one for Unity-2D) but since the Scope exposes data trough an API/d-bus ecc... is the same Scope usable on both versions of Unity? [17:16] Any Lens you write works fine with both Unity and Unity-2D, they share the same code for talking to Lenses [17:17] This is because a Lens does not contain any specific UI code (i.e. gtk or Qt or Nux), it just requests that a category should use the horizontal tile, for instance, and it's up to the Unitys to render it correctly [17:18] It's actually one of my favourite things about Lenses/Scopes, they are purely data with requests for renderering, the actual renderering is handled elsewhere and therefore can be changed to match it's environment (i.e. searching your lenses from a webpage ;) [17:18] njpatel: so they can be written in any language? C, C++, Python, Vala ecc...? [17:18] Yep [17:19] Due to this boundary between the renderering-side (Unity) and the data side(Lenses or Scopes), you can write them in any language [17:19] libunity (the library you use to write them in) is a GObject library with full GObject introspection support [17:20] it also means, C++ Unity can have a Vala Applications Lens which has a Python Freedesktop-menus Scope and a Javascript Web Apps Scope :) [17:20] we like that :D [17:21] [17:21] Okay, so the other important thing is for Unity to actually find the Lens [17:22] for this, you need to choose a "id" for your lens i.e. Music lens = "music", Google Docs Lens = gdocs [17:22] you use that id and install your .lens file in /usr/share/unity/lenses/$id/$id.lens [17:22] This is an example .lens file: http://paste.ubuntu.com/685980/ [17:23] We use DBus activation to start a lens, so you also need to install a .service file into /usr/share/dbus-1/services [17:24] with the .lens file, Unity can start up, have a look at what lenses are installed, be able to load their icon etc, and then, when the user does a search, activate the Lens daemon (which will in turn activate it's scopes) [17:25] if you are writing a Scope, you have a Scope file which only contains the DBusName and DBusPath attributes and you install it in the Lens's folder in /usr/share/unity/lenses [17:26] you'll also need a dbus .service file as Scopes are also started with dbus activation [17:26] [17:26] As I mentioned earlier, we recognise that there are not many Lenses that people would like to ship which don't have at least one Scope readily available to make it useful [17:27] What we didn't want was to have you jump through hoops to create .scope files, .service files and a new binary just for this, so we have a little function that allows you to ship a Lens daemon with an in-built Scope easily [17:28] this does't stop other Scopes from plugging into your Lens, but just lets you get up-and-running much more easily [17:28] [17:29] So, for this session I had originally wanted to write a Scope for the Music lens, but ran into some difficulty with getting an API key for an OSS project (urgh), so I decided to be a bit daring and started a Google Documents Lens + Scope using Python (a language which we did not have support for until this morning!) [17:30] The code is available at lp:unity-lens-gdocs [17:30] but I have some pastes of the a few stages of the code which I thought would be useful to go over [17:31] So, the first commit I did looked something like: http://paste.ubuntu.com/685979/ [17:31] I should say, excuse any bad python in there, I'm a C/C++ guy :) [17:32] [17:32] So, from line 27 [17:32] You can see we create the Lens object [17:33] hopefully the properties we set are obvious enough [17:33] but you have some top-level control here over your Lens, like whether you want it to show in the global search results [17:33] what the search hint is, etc etc [17:33] then the first two important things are done [17:34] populate_filters() does exactly what it says on the tin [17:34] As in the comments, I love the RadioOption filter as it's one of the easiest to use :) [17:35] CheckOption, RadioOption and MultiRange filters are all "OptionFilter" sub-classes in libunity. This type of filter is basically one which can have multiple options in it, and an option can be active or inactive [17:36] Andy80 asked: you defined both scope + lens in that single python code? [17:37] Yep, I'm using the lens.add_local_scope() method to have my Lens be automatically useful when installed without having to also ship a separate scope in the package [17:37] this does mean that my lens and scope are in the same process, and this might be okay for some lenses and not okay for others, you would need to judge that yourself [17:38] due to this Lens being very much tied to a single service, having the scope ship with the lens and in the same process is fine [17:38] My goal is to make gdocs lens also ship a scope for the files lens, if you'd just like to search all files in one lens [17:38] but this is a good enough example for now :) [17:38] [17:39] So, the filters you add here are synced with Unity (so it knows what to display) and also down to the Scopes (so they can query them during search) [17:39] I'll show you how the Scope uses the filters during a search later on [17:40] As mentioned, check, radio and multi-range work very similarly, the Ratings filter is the simplest, providing you with a rating of 0.0 to 1.0 depending on how many stars the user has clicked [17:41] Using the visible property on a filter, you should be able to show/hide filters depending on which other options are clicked [17:41] be a bit careful, though, i don't think either Unity has a nice transition for that change yet, so it might surprise the user a bit! [17:42] [17:42] so, in populate_categories() we add the categories we'd like to use [17:43] for each category, we can choose and icon, set it's name and choose how we'd like it rendered [17:44] The order in which you add these categories is the numbering you use in the Scope when adding a result. So, for the first category, the integer you'd use when adding the result would be 0 [17:44] usually an enum would be best to make your code readable for others and yourself down the line! [17:45] coming back up, if you ignore line 46 & 47, calling lens.export() would get you ready for Scopes that want to plug in and ready fro Unity to start showing/search your lens [17:45] if you plan on making a Lens and separate scopes, this is all you need to do [17:46] however, for our GDocs lens we want to also provide some results from GDocs (as we're not really expecting anything else to plug into such a specific Lens) [17:46] [17:47] so, looking at lines 46 & 47, we can see we create a class that internally creates a Scope, and then inform our Lens that a "local scope" exists i.e. tell it that there is a scope that doesn't have a .scope file and cannot be activated, but is actually in the same process as itself [17:48] [17:48] Okay, so looking at the UserScope class [17:48] My idea is to give this Lens the ability to handle multiple google accounts (say work + personal), so i've encapsulated the logic of talking to a single account into one class and one scope [17:49] therefore, when I do add support for multiple accounts, I'll be creating a UserScope for each, and calling lens.add_local_scope() for each too [17:49] the start of the __init__ of the class mostly deals with the gdata bits [17:50] line 129 onwards does the fun stuff, namely it creates the Scope by telling the Unity.Scope class where to export it's internal dbus object [17:50] There are 10 minutes remaining in the current session. [17:50] after that, it connects to two signals to know when the normal search and global search changes [17:52] we keep them different, including two different results models, as we fully expect the Lens to behave a bit differently with global search versus with normal search. A good example of this is that a normal search will take into account filters but the global one won't [17:52] moving on, you can see there are some methods to grab the search string and then just one method to actually update the results, either global or normal [17:53] in update_results_model(), we have a placeholder that just grabs all the documents and throws it in the results model, it doesn't deal with the search string yet [17:54] so, the next thing would be to get it to do that [17:54] http://paste.ubuntu.com/685988/ [17:54] that is the diff for making the Scope actually search [17:54] as you can see, we now take into account the global search (though as we are not doing any filtering we can still keep it simple when searching) [17:55] the rest of the diff is mostly just constructing a good gdata search URI [17:55] running out of time! [17:55] There are 5 minutes remaining in the current session. [17:55] moving on, this http://paste.ubuntu.com/686007/ shows us responding to filters [17:56] if you look at apply_filters() [17:57] You can see that, for each filter that we know/care about, we query the scope to get the Filter object, and then we query the filter to see what the current active option is [17:57] however, we only do this if we are not doing a global search [17:58] the "id" property of the filter is the same as what the Lens set when creating the filter. Through this mechanism, you can always be sure you are reacting to the correct filter [17:59] also you can see I changed the filters a bit so I could be a bit lazy with ids :) [17:59] so, we're at the end, it would have been good to have more time but I'll be updating the wiki page with lots more info [17:59] https://wiki.ubuntu.com/Unity/Lenses [18:00] also, I'll be continuing to develop this lens if you want to subscribe to the branch on Launchpad to keep up! [18:00] thanks a lot njpatel, that was awesome! === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: App Developer Week - Current Session: Practical Ubuntu One Files Integration - Instructors: mterry [18:00] Logs for this session will be available at http://irclogs.ubuntu.com/2011/09/09/%23ubuntu-classroom.html following the conclusion of the session. [18:01] talking of which, next up mterry will be talking about connecting your apps to the cloud with ubuntu one :) [18:01] Hello everybody! Thanks njpatel! [18:01] So I'm Michael Terry, an Ubuntu developer as well as the developer of Deja Dup, a backup program [18:02] I recently added support for Ubuntu One to my program, and I thought I'd share how that went, and some simple examples of how to connect to Ubuntu One Files [18:02] I have lots of notes for this session here: https://wiki.ubuntu.com/mterry/UbuntuOneFilesNotes11.10 [18:02] Which you may be interested in going through as I talk [18:02] Please ask questions any old time [18:03] So, for this session (and for my purposes with Deja Dup), I only needed simple file functionality [18:03] get, put, list, delete basically [18:03] So we'll go through each of those basic ideas to help anyone else that's interested in integrating do so easily [18:03] We'll use Python, since that's most convenient [18:04] So let's create together a simple python script that can do basic file operations with U1 [18:04] You'll need an updated ubuntuone-couch package from Ubuntu 11.10 [18:04] I've backported it in my PPA [18:04] For this sessoin [18:04] So if you want to play along at home, but are stuck on Ubuntu 11.04, please do the following: [18:05] sudo add-apt-repository ppa:mterry/ppa2 [18:05] sudo apt-get update [18:05] sudo apt-get upgrade [18:05] That will give you a new ubuntuone-couch [18:05] So to start, let's write a super simple Python script that can just accept an argument [18:05] === [18:05] #!/usr/bin/python [18:05] import sys [18:05] if len(sys.argv) <= 1: [18:05] print "Need more arguments" [18:05] sys.exit(1) [18:05] print sys.argv[1:] [18:05] === [18:05] Very basic. We'll augment this with more in a second [18:06] Save that as u1file.py [18:06] And open a terminal in that same directory [18:06] The first thing you have to do when interacting with U1 is make sure the user is logged in [18:06] There is a helper library for that in ubuntuone.platform.credentials [18:06] It's designed to work with Twisted and be asynchronous [18:07] But we just want simple synchronous behavior for now [18:07] So I'll show you a function that will fake synchronousity by opening an event loop and waiting for login to finish [18:07] === [18:07] #!/usr/bin/python [18:07] import sys [18:07] _login_success = False [18:07] def login(): [18:07] from gobject import MainLoop [18:07] from dbus.mainloop.glib import DBusGMainLoop [18:07] from ubuntuone.platform.credentials import CredentialsManagementTool [18:07] global _login_success [18:07] _login_success = False [18:07] DBusGMainLoop(set_as_default=True) [18:07] loop = MainLoop() [18:07] def quit(result): [18:07] global _login_success [18:08] loop.quit() [18:08] if result: [18:08] _login_success = True [18:08] cd = CredentialsManagementTool() [18:08] d = cd.login() [18:08] d.addCallbacks(quit) [18:08] loop.run() [18:08] if not _login_success: [18:08] sys.exit(1) [18:08] if len(sys.argv) <= 1: [18:08] print "Need more arguments" [18:08] sys.exit(1) [18:08] if sys.argv[1] == "login": [18:08] login() [18:08] === [18:08] This may be easier to see on the wiki page https://wiki.ubuntu.com/mterry/UbuntuOneFilesNotes11.10#Logging_In [18:08] The important bit is from ubuntuone.platform.credentials import CredentialsManagementTool [18:08] followed by [18:08] cd = CredentialsManagementTool() [18:08] d = cd.login() [18:08] The rest is just wrappers to support the event loop [18:08] And to support calling "python u1file.py login" [18:09] So try running that now, and you should see a neat little U1 login screen [18:09] Unless... You've already used U1, in which case, nothing happens (because login() doesn't do anything in that case) [18:09] So let's add a logout function for testing purposes [18:09] === [18:09] def logout(): [18:09] from gobject import MainLoop [18:09] from dbus.mainloop.glib import DBusGMainLoop [18:09] from ubuntuone.platform.credentials import CredentialsManagementTool [18:09] DBusGMainLoop(set_as_default=True) [18:09] loop = MainLoop() [18:09] def quit(result): [18:09] loop.quit() [18:09] cd = CredentialsManagementTool() [18:09] d = cd.clear_credentials() [18:09] d.addCallbacks(quit) [18:09] loop.run() [18:09] if sys.argv[1] == "logout": [18:10] logout() [18:10] === [18:10] Now add that to your script and you can call "python u1file.py logout" to go back to a clean slate [18:10] OK. So we have a skeleton script that can talk to U1, but it doesn't do anything yet! [18:10] Let's upload a file [18:10] Oh, whoops [18:10] First, we have to make sure we create a volume [18:10] In U1-speak, a volume is a folder that can be synchronized between the user's computers [18:11] By default, new volumes are not synchronized anywhere [18:11] But let's create a testing volume so that we can upload files without screwing anything up [18:11] Note that the "Ubuntu One" volume always exists [18:11] Creating a volume is a simple enough call: [18:11] === [18:11] def create_volume(path): [18:11] import ubuntuone.couch.auth as auth [18:11] import urllib [18:11] base = "https://one.ubuntu.com/api/file_storage/v1/volumes/~/" [18:11] auth.request(base + urllib.quote(path), http_method="PUT") [18:11] if sys.argv[1] == "create-volume": [18:11] login() [18:12] create_volume(sys.argv[2]) [18:12] === [18:12] You'll see that we make a single PUT request to a specially crafted URL [18:12] There is no error handling in my snippets of code. I'll get into how to handle errors at the end [18:12] Add that to your u1file.py, and now you can call "python u1file.py create-volume testing" [18:12] If you open http://one.ubuntu.com/files/ you should be able to see the new volume [18:13] Congratulations if so! [18:13] You'll also note that I included a call to login() before creating the volume [18:13] This was to ensure that the user was logged in first [18:13] You'll also note that I made this weird auth.request call [18:14] This is a wrapper function provided by ubuntuone-couch that handles the OAuth signature required by U1 to securely identify the user [18:14] This is why you had to log in first [18:14] And the 11.10 version has some important fixes, which is why I backported it for this session [18:14] OK, *now* let's upload a file [18:14] (any questions?) [18:14] Uploading is a two-step process [18:15] First, we tell the server we want to create a new file [18:15] Then the server tells us a URL path to upload the contents to [18:15] I'll give you the code then we can talk about it [18:15] === [18:15] def put(local, remote): [18:15] import json [18:15] import ubuntuone.couch.auth as auth [18:15] import mimetypes [18:15] import urllib [18:15] # Create remote path (which contains volume path) [18:15] base = "https://one.ubuntu.com/api/file_storage/v1/~/" [18:15] answer = auth.request(base + urllib.quote(remote), [18:15] http_method="PUT", [18:15] request_body='{"kind":"file"}') [18:15] node = json.loads(answer[1]) [18:15] # Read info about local file [18:16] data = bytearray(open(local, 'rb').read()) [18:16] size = len(data) [18:16] content_type = mimetypes.guess_type(local)[0] [18:16] content_type = content_type or 'application/octet-stream' [18:16] headers = {"Content-Length": str(size), [18:16] "Content-Type": content_type} [18:16] # Upload content of local file to content_path from original response [18:16] base = "https://files.one.ubuntu.com" [18:16] url = base + urllib.quote(node.get('content_path'), safe="/~") [18:16] auth.request(url, http_method="PUT", [18:16] headers=headers, request_body=data) [18:16] if sys.argv[1] == "put": [18:16] login() [18:16] put(sys.argv[2], sys.argv[3]) [18:16] === [18:16] There are three parts to this [18:16] First is the request to create a file [18:16] We give a URL path and PUT a specially crafted message "{'kind':'file'}" [18:16] Then, we read the local content [18:16] And push it to where the server told us to [18:16] (this is the "content_path" bit) [18:16] The response from the server (and the specially crafted message we gave it) is called JSON [18:17] It's a special format for encoding data structures as strings [18:17] Looks very Python-y [18:17] The 'json' module has support for reading and writing it [18:17] As you can see [18:17] We also use a different base URL for uploading the content [18:17] We use "files.one.ubuntu.com" [18:18] So now, let's try this new code out: [18:18] "python u1file.py put u1file.py testing/u1file.py" [18:18] This will upload our script to the new testing volume we created [18:18] Again, you can visit the U1 page in your browser and refresh it to see if it was created [18:19] If so, congrats! [18:19] Also note that we had to specify the content length and content type [18:19] These are mandatory [18:19] I calculated both in my example (using the mimetypes module) [18:19] But if you already know the mimetype, you can skip that bit of course [18:20] OK, let's try downloading the script we just uploaded [18:20] This is very similar, but uses GET requests instead of PUT ones [18:20] Again, two step process [18:20] We first get the metadata about the file, which tells us the content_path [18:20] And then we get the content [18:20] === [18:20] def get(remote, local): [18:20] import json [18:20] import ubuntuone.couch.auth as auth [18:20] import urllib [18:20] # Request metadata [18:20] base = "https://one.ubuntu.com/api/file_storage/v1/~/" [18:20] answer = auth.request(base + urllib.quote(remote)) [18:20]