== Current Session: Rapid App Development with Quickly - Instructors: mterry == {{{#!irc [17:00] So if there are no more questions, the last bit is just to thank you for your participation and hope you've enjoyed the session! :-) [17:00] Logs for this session will be available at http://irclogs.ubuntu.com/2011/09/08/%23ubuntu-classroom.html following the conclusion of the session. [17:01] Hello, everyone! [17:01] Thanks to dpm and johnoxton for the awesome session [17:01] Mine piggybacks on that by giving more information about quickly [17:01] I'm a maintainer of quickly and will give a brief overview of what it is, how to use it [17:02] Please ask questions in the chatroom, I'll try to answer them [17:02] So first, here's a link for the wiki page of quickly: https://wiki.ubuntu.com/Quickly [17:03] Quickly is at its heart a templating system. It is designed to give a user a quick start of sample code and allow you to modify it easily and quickly(!) into a full program [17:04] It has a lot of boiler plate code that gets you started, and commands to simplify common application tasks like packaging it up, saving to bzr, publishing to users in a PPA [17:04] It's designed, as is developer.ubuntu.com, to make opinionated choices about technologies (which makes the task of teaching new users a lot easier -- just teach one thing) [17:05] But since new quickly templates can be written, new sets of opinionated choices are easy too [17:05] For example, someone might one day write a Kubuntu template, to make app dev on Kubuntu easier [17:06] And lastly, quickly is supposed to make app dev on Ubuntu fun, by letting the user focus on the good stuff, not the boring administrative stuff [17:06] In 11.04, we have four templates: ubuntu-application, ubuntu-cli, ubuntu-flash-game, ubuntu-pygame [17:06] ubuntu-application is PyGTK based to make graphical apps [17:06] ubuntu-cli is Python based for making command line apps [17:07] ubuntu-flash-game is like it sounds, you drop a flash file into place and quickly handles the rest [17:07] ubuntu-pygame is pygame based, which is a Python library for making games easy [17:07] There was a question last session about why PyGTK and not GObject Introspection [17:08] We'd like to use PyGI, but due to technical details (it's difficult to automatically guess dependencies then), we haven't made that jump yet [17:08] Hopefully we will during the 12.04 cycle [17:08] Our goals for 11.10 are rather modest, focusing just on some outstanding bugs [17:09] OK, enough intro. Let's do something! [17:09] You can install it easily enough by running: "sudo apt-get install quickly" [17:09] This will install all sorts of programming goodies [17:10] Once installed, try running "quickly create ubuntu-application test-project" [17:10] The 'create' is the command to quickly to say "start a project", the 'ubuntu-application' tells which kind of project, and the last argument names the project [17:11] You'll now have a folder called "test-project" with a bunch of files [17:11] It will also open a window [17:11] This is what your project looks like already! It has a window, menubar, etc [17:12] This will all be easy to change, but it's a quick start, something to modify [17:12] So why don't we try doing that [17:12] We'll look into changing the UI a bit [17:12] Run "quickly design" to open Glade, which is a graphical UI builder [17:13] Using glade well is a whole 'nother talk, but if you have any questions, I'll be happy to answer them [17:13] For now, just note that you can select things, change properties on the right, and add new widgets from the toolbox on the left [17:14] Quickly automatically hooks your Glade UI files together with your code [17:14] I'll give a brief overview of what you can do in Glade [17:15] Layout in Glade (and in GTK in general) is done via Boxes (like VBox or HBox) that arrange them in rows or columns [17:15] You can change a widget's position in a box in the properties dialog (2nd packing tab) [17:16] The packing tab is where you can adjust a lot of the layout of a widget. The first tab is where you control specific widget functionality (like the text on a label, etc) [17:16] OK, so enough Glade. [17:16] I'll briefly mention here, to learn more about quickly, you can also run "quickly help" to get an overview of commands [17:17] Or you can run "quickly tutorial" to get a more complete tutorial that you can walk through at your own pace [17:17] That will walk you through creating a full app [17:18] Back to my overview, another important command is "quickly add dialog dialog-name" [17:18] Let's say you want to add a quit-confirmation dialog or something [17:19] By running the above command, quickly will generate a new Glade file and a new Python file to handle any special code you may want for the dialog [17:19] After running the command, you may want to close out Glade and reopen it with "quickly design" to open the new Glade file that you just created [17:20] Now to use that new dialog from code, open your code with "quickly edit" [17:20] This opens all your Python files in the gedit text editor [17:21] You can open your new dialog from existing code by doing something as simple as "from project_name.DialogName import DialogName" [17:22] Then creating new dialogs with DialogName() [17:22] Another thing Quickly makes easy for you is signals [17:23] Whenever a user clicks on a button, starts typing in a field, or closes a window, a signal is generated inside GTK [17:23] If you want to run some code in response to an action, you need to add a signal handler in code [17:23] Normally, this is a bit tricky to coordinate between Glade's files and Python's files [17:24] But Quickly will automatically join widgets in Glade to Python code if you name your signal handler correctly [17:24] Let's say you want to do something in response to a widget you named "button1" being clicked [17:24] Open the widget window's Python file, and add a function called "on_button1_clicked(self, widget, data=None)" [17:25] The trick is to name it on_WIDGETNAME_SIGNALNAME [17:25] And Quickly will find it and join it up [17:25] Another thing to note about Quickly is how your code is even organized [17:26] I've talked about opening a window's Python file, but what does that mean? [17:26] You'll have three subfolders in your project folder [17:26] One is "bin", one is "project_name", and the last is "project_name_lib" [17:26] Quickly 'owns' files in bin and project_name_lib [17:27] 'bin' holds a wrapper that Quickly uses to find the rest of your files once it's installed on disk [17:27] 'project_name_lib' holds a bunch of convenience boiler plate code that Quickly provides. But you shouldn't modify it, as Quickly may update that code on you [17:27] The real goods are in the 'project_name' folder [17:28] There you'll find a file with some utility code (like command line argument handling) and a file for each window in your project [17:28] And a file for your preferences [17:29] The wrapper will create ProjectWindow class, and that's the entry point to your program [17:29] If you wanted to take an existing project and drop it into a Quickly shell project, or even wanted to start with a Quickly project but not really use any of the code, the only actual requirement is that you have a ProjectWindow class [17:30] Once that code runs, you can do whatever you like [17:30] Another thing Quickly does for you is use a logging framework [17:30] You'll see existing code use log calls [17:31] Run your project ("quickly run") in verbose mode ("quickly run -- --verbose") to see the log output [17:31] When debugging, you can add new log calls (or just use plain old print statements) [17:32] Another, more precise, method of debugging is to use the command line python debugger pdb [17:32] Acts like gdb but for python [17:32] I've not used it a bunch (print statements tend to be quicker and easier) [17:32] But if you have a really tough bug, pdb can be a help [17:33] OK, so let's say you have your app, version 1.0 [17:33] You'll want to start being able to release it [17:34] In general, there are three levels of testing a finished program: (1) locally, by the developer, (2) a wider, but still limited, group of testers, and (3) everyone (an actual release) [17:34] Quickly will help with all 3 [17:35] But before we create any packages at all, let's set up a bit of metadata about your project [17:35] Add your name and email to the AUTHORS file that Quickly created for yu [17:35] you [17:35] Also define a license for your project with "quickly license BSD" or similar. [17:35] GPL-3 is the default [17:35] So no need to run anything if that suits you fine [17:36] Open the project-name.desktop.in file in your project directory too [17:36] It has a Categories line that you can edit to adjust where in the menu structure it will show up [17:36] See defined categories here: http://standards.freedesktop.org/menu-spec/latest/apa.html [17:36] And finally, edit setup.py in your project directory [17:37] Near the bottom are some metadata bits like description, website, author name again [17:37] With all that in place, let's make a package! [17:37] For local testing by you yourself, "quickly package" will create a package [17:37] It will create it in the directory above your project folder [17:38] So install it with "sudo dpkg -i ../test-project_0.1_all.deb" or some such [17:38] Then it should appear in your menu [17:38] And be runnable from the Terminal with "test-project" [17:38] Once you think it seems alright, you're ready to distribute to the rest of your testers [17:38] This involves a PPA [17:39] A Personal Package Archive [17:39] In your Launchpad account, you can create new PPAs [17:39] First you need SSH and GPG keys, explained in the Launchpad help: [17:39] https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair [17:39] https://help.launchpad.net/YourAccount/ImportingYourPGPKey [17:40] Also set DEBEMAIL and DEBFULLNAME in .bashrc, the same as what was in your GPG key [17:40] And then run ". ~/.bashrc" to pick up the new settings in your current Terminal [17:41] (that's a period as a command) [17:41] Just a bash trick to run a script in the current environment [17:41] For instructions on actually creating a PPA: https://help.launchpad.net/Packaging/PPA [17:41] Phew [17:42] With that all set up, all you need to do to publish a new testing version of your project is "quickly share" [17:42] This will package up your current code and put it in your PPA [17:42] It will pick its own version (though you can provide one, see "quickly help share") [17:43] The version used will be based on the last release [17:43] It won't increment the actual version number, but just a version suffix [17:43] Since it's just a testing package [17:44] If you want to make a full release to the wider public, use "quickly release" [17:44] It helps to have a project created in Launchpad and associated with your quickly project [17:44] (use "quickly configure lp-project project-name" for that) [17:45] Then Quickly can automatically make project release announcements for you [17:45] dpm asked: I've been reading the quickly help, and I'm still not sure I get it: what's the difference between the 'quickly share' and 'quickly release' commands? [17:46] So "share" uses a version suffix like -public1 [17:46] It releases into your PPA, but that's it [17:46] "release" will actually increment your main version number to something like 11.09 [17:47] (These version changes can be overridden on the command line) [17:47] Release will also, if a Launchpad project is associated, make a release announcement and close the milestone [17:48] So there isn't *much* difference, more of a semantic one. Release just does a few thing extra [17:48] I also recommend using different PPAs for "sharing" and "releasing" [17:48] You can specify a ppa with "quickly share --ppa mterry/testing" for example [17:48] That way, you can have a "testing" PPA and a "stable" PPA [17:49] So it's good to get in the mental habit of thinking that there are two types of publishing [17:49] One for testers, one for everyone [17:50] I suppose there's one more level of publishing actually [17:50] And that's to the Software Center [17:50] Quickly has a few tools to help you prepare your app for the Software Center (whether it's a free or proprietary one) [17:50] There is the "submitubuntu" command [17:50] There are 10 minutes remaining in the current session. [17:51] This will publish to a PPA just as "release" does [17:51] But it will do some of the legwork to prepare the package for the App Review process [17:51] Notably, it will install everything into /opt [17:51] And it will set some bits of packaging metadata up like "where is the app screenshot" and such [17:52] You can prepare a local deb with such changes by using "quickly package --extras" === wangerin1 is now known as wangerin [17:52] See https://wiki.ubuntu.com/AppReviews for more information about such requirements [17:53] That's all I had prepared! [17:53] I'm happy to answer Quickly questions if ya'll have any [17:55] There are 5 minutes remaining in the current session. [17:56] MDesigner asked: what resources do you recommend for learning Glade and Python, specifically geared toward Ubuntu/Unity development? [17:56] Heh, well, the previous session was on developer.ubuntu.com [17:57] That aims to be the answer to that question [17:57] It already has some content, but it's hoped to flesh that out a bit [17:57] For example, I'll be writing a tutorial for it on how to integrate Ubuntu One Files in your app using Python (I also have a talk on that tomorrow) [17:58] For learning Python in general, Dive into Python is a great resource [17:58] Google that and you'll get results [17:58] I'm not sure there are great tutorials out there for Glade specifically [18:00] For Unity integration, http://unity.ubuntu.com/ has some info. Like http://unity.ubuntu.com/projects/appindicators/ has links for documentation }}}