=== jsjgruber_ is now known as jsjgruber === callaghan_ is now known as callaghan [08:47] what is ubuntu classroom chat ?? [08:47] can anyone give a light on it ?? [08:50] codingenesis: https://wiki.ubuntu.com/Classroom would be helpful [08:51] i would definitely like to be a part of it.. [08:51] how can i join ?? [12:00] are there scheduled discussion/classrooms in here? if so, where can I access a timetable? [12:02] devcalais: You can see the schedule in the Calender. [12:02] The link to the calender is in the topic [12:13] Cheers. :) [14:08] [15:01] Hello all .. I apologize if this query isn't posted on right channel. After I upgraded to 11.10 I got this msg in recovery mode "var/run/dbus/system_bus_socket connection refused" and I am unable to login in my a/c. [15:01] Someone please help me out === dpm is now known as dpm_ === Wilczek_ is now known as Wilczek === 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 an App Developer Website: developer.ubuntu.com - Instructors: dpm, johnoxton [16:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/09/08/%23ubuntu-classroom.html following the conclusion of the session. [16:01] Welcome everyone to Day 4 of the Ubuntu App Developer Week! [16:02] ok, so let's get started, shall we? === shadeslayer_ is now known as shadeslayer [16:03] So hi everyone [16:03] Again, welcome to Ubuntu App Developer Week and to this session about the App Developer _site_ [16:03] My name is David Planella, and I work on the Community team at Canonical as the Ubuntu Translations Coordinator [16:04] While still working on translations, this cycle I've been spending some time on the app developer side of things, [16:04] that is, contributing to the goal of making Ubuntu a target platform for application developers, [16:04] so that they can easily create or port software in Ubuntu and they can publish it and distribute it to and grow our increasing user base. [16:05] My main area of focus has been so far developer.ubuntu.com, of which we're going to talk today, [16:05] and for this I've had the pleasure of working with the awesome web design team at Canonical. [16:05] Co-presenting this session and representing them we've got the luxury of having John Oxton, [16:05] who's recently joined Canonical and has been doing fantastic work in shaping up the site [16:06] But I'll let him introduce himself best [16:06] * dpm hands the mike to johnoxton [16:06] Hi everyone, as David said, my name is John Oxton and I am a user experience architect on the web team at Canonical. I have been with the company for a few months and this is my first assignment. [16:07] I will be using the word ‘we’ quite a lot as we go along and this is just a shortcut to represent a group of very busy people (inside and outside Canonical) who have given their time generously to this project, not because they have to but because they care about it deeply and believe it to be very important to the future success of Ubuntu. In that light my contributions to this project really are very [16:07] to theirs. [16:07] Ok, enough with the Oscar acceptance speech, let’s get on! [16:07] As has been mentioned the goal of this site is to help get more and better apps into the Ubuntu Software Centre. [16:08] From the developer.ubuntu.com website point of view that is an interesting challenge and not one we can possibly hope achieve in one step. [16:09] Where to begin? [16:09] The first question really is what is an ‘app’ anyway? Is LibreOffice an app? Is Mozilla’s Thunderbird an app? What about Chromium? Skype? Firefox? [16:09] Well the answer is yes and each a very good one but also advanced and relatively mature and, importantly, already on Ubuntu. [16:09] The point being, for this upcoming release we aren’t really targeting developers of these kinds of apps because they are already working it out. [16:10] Of course, nor is the aim to exclude them. [16:10] Instead we want to start a dialogue with individuals, or small teams, with an “itch to scratch” [16:11] or small indie developers/companies who are already making small, useful, or just plain cool, apps for other platforms. [16:11] With that in mind we shaped two personas, and the journeys we’d expect them to make, to reflect these sorts of developers [16:11] and began sketching ideas about how we thought we could encourage and support them through the app development lifecycle. [16:12] For those who’ve never encountered personas, here is a brief summary from UX mag: [16:12] “A persona represents a cluster of users who exhibit similar behavioral patterns in their purchasing decisions, use of technology or products, customer service preferences, lifestyle choices, and the like." [16:13] You can find out more at http://uxmag.com/design/personas-the-foundation-of-a-great-user-experience [16:13] * dpm mentions: before I forget, please feel free to ask any questions throughout the session, prepending them with QUESTION: on the #ubuntu-classroom-chat channel [16:14] So with personas firmly in our head, this is what we sketched: http://madebymake.com/ [16:14] To access the site: Username: developer and Password: ubuntu [16:14] Please keep in mind that our focus here was on the structure of the navigation and the general concept of the site so the visual design seen here is in no way representative of the finished site. [16:14] Feel free to click around, most pages are present; I’ll grab a much needed cup of tea whilst you do. [16:17] Anyway, with that done we hired an independent research company to help us test this prototype. [16:17] We did this because we needed someone neutral to help us really dig for what was good and what was not so good. [16:18] From there we recruited a cross-section of ‘app developers’ who were developing for a variety of platforms; some professionally, some in their spare time. [16:19] We ran them through the prototype you have seen, asking them about their expectations before they clicked through to different pages [16:19] and also talking to them about their usual app development workflow to see if the site could be truly useful to them. [16:19] David, meanwhile, ran an in-depth survey to give us some quantitative data to support or challenge what our qualitative research was suggesting. [16:20] These sessions and the survey were incredibly important. They challenged all of the assumptions we had made and helped us verify that our personas were even closely matching reality. [16:20] In short the response to our first prototype was fairly unanimous: We like where you are going but this isn’t right. [16:20] It also started to hint that our personas were close but not quite close enough. [16:20] With the first round of testing complete we went back to the drawing board and considered everything we’d learnt. [16:20] So what did we learn? [16:21] What came back consistently was: marketing sucks, so just stop it. I just want to ‘Get started’, tell me how to proceed. [16:21] Give me an ‘Hello World!’ app to play with and I want really good documentation. [16:21] Oh, and packaging, I don’t like thinking about packaging if I can help it. [16:21] Just ‘Get started’, hmmmm, this is where things get challenging. [16:21] Linux, and therefore Ubuntu, prides itself on having a rich, flexible development environment [16:22] which is great but also has the potential for confusion for people just starting out [16:22] On the back of the findings we felt we really ought to be a little more decisive and dare to be a little opinionated because without that the site won’t have the clarity it needs to attract developers to the platform. [16:22] Thankfully the springboard for that was already in place in the form of Quickly (https://wiki.ubuntu.com/Quickly) [16:22] and after much debate, for now at least, we’ve put it up front. [16:23] We have stated that THIS is the way to get going when developing for Ubuntu. [16:23] We are aware that this might be a somewhat controversial decision to make and we have been careful to show that there are other options [16:23] but Quickly delivers a route in and a good one as it elegantly stitches together classic, and very powerful, Linux development tools. [16:23] Very importantly it also helps with packaging. [16:24] Something our research has suggested is that whilst great apps are being written for Ubuntu they aren’t making it all the way into the Software Centre. [16:24] Packaging seems to be part of what’s stopping that happening [16:24] Thinking about Quickly, and the tools it brings together, helps shape our content strategy for another important area of the site: Resources [16:24] ... or Reference... or Documentation (we’re still trying to decide what we should call this section). [16:24] Whatever it ends up being called, the potential for this section of the site is enormous and our research suggests it is an area that really could improve the success rate of apps hitting the Software Centre. [16:25] But there is a problem. [16:25] There’s so much content for this section, generally, but it’s all over the place, it’s not well organised in one authoritative spot. [16:25] On the flip side there’s not enough of the right content to help those people who are just getting started; or if there is it’s a real struggle to find it. [16:26] Getting this section right in one hit is impossible without a bigger discussion with developers. [16:26] So we’ve scoped it carefully and our message will be clear: We need help with this! [16:26] Which is where you come in. To begin with let’s keep things simple and engage with you, the community, around a single topic and from there build up the infrastructure we need to make this site something truly special. [16:26] So what next? [16:27] Before we get to that I just want to share a couple more rough sketches with you so you can, hopefully, see the difference the testing made to how we approached the flow of the site. [16:27] and so far they've tested pretty well: [16:27] http://dl.dropbox.com/u/24134/developer/Home.jpg [16:27] http://dl.dropbox.com/u/24134/developer/getstarted.jpg [16:27] http://dl.dropbox.com/u/24134/developer/resources.jpg [16:29] This really has been a very quick skip and a hop through a quite detailed process and I’ve had to boil it down to what I think is the essence of it because I want to leave space for Q&A. [16:29] Suffice to say, the site will go live fairly soon and, once it does, we start listening and we start talking. [16:29] When we launch, we consider it the beginning of something, not the end. This is when the UX processes really start to kick in. [16:29] As I said, I am still fairly new to Canonical and still have to get to know the Ubuntu community better and I need to work out the best ways to collect qualitative feedback and turn it into something actionable. [16:30] I will be talking this through with David, and others, as time goes on. [16:31] My first step, though, is to try and plan a workshop at the upcoming UDS [16:31] so we can investigate any issues that come up in detail, with the aim of coming up with some big themes on which to base future work as well as how we engage with developers in an ongoing discussion about *their* site. [16:31] Meanwhile, I hope you will enjoy your new developer site and find it useful when it launches. [16:31] You can see my notes here: http://pastebin.com/8wwHufVs [16:31] Thank you. [16:32] Awesome, thanks John [16:32] Now you can see how much work is involved behind the planning and creating the concept of such a site [16:33] I'll continue from here on. I see there is a question already, so I'll handle that [16:33] in the meantime, if you've got any other questions so far, feel free to ask [16:33] paglia_s asked: in some words how does quickly work? which languages does it support and which design library (gtk, qt...) ? [16:34] well, the first thing to understand here is that quickly is just a wrapper [16:35] quickly helps us adding the glue to all of the tools we've decided to recommend for developing in Ubuntu [16:36] as such, quickly puts together python, gtk, debian packaging, bzr, launchpad and a few more [16:37] so quickly is a command line tool that provides easy commands to perform actions which otherwhise would be more complicated [16:37] in other words, it hides the complexity for the developer, who can then just worry about coding [16:38] So just to give an example, to package an app, if you've started a project with quickly, in most cases running the 'quickly package' command will be enough [16:38] rather than having to read tons of documentation and learn how to package [16:38] tau141 asked: why does ubuntu recommend PyGtk for creating Applications? [16:39] I was expecting that one :) [16:40] There are many, many good technologies in the open source world and while that is an asset, we do want to make an opinonated choice on the tools we recommend [16:41] Right now python + gtk + debian packaging are the best options to a) provide full integration with the Ubuntu Platform (talk unity, indicators, notification, etc) and b) support the application's full lifecycle [16:41] we want to make it easy for developers to create their apps and publish them in the Software Center [16:42] and for that, we cannot support all technologies and have to concentrate on one we recommend [16:42] right now pygtk (or probably pygi in the near future) is the best option [16:43] which does not mean that when other tools mature or provide better integration with the platform we will not review that choice [16:43] so in short: that's the decision we've done now, but we will continue exploring the options that allow Ubuntu being the best platform of choice for app developers [16:44] tomalan asked: The PyGTK-Project was cancelledin april, are you sure you don't mean the PyGobject-Introspection? [16:44] good point. I mentioned just before that pygtk might need to be reworded to pygi in the near future :) [16:45] afaik quickly has not yet been ported to use gobject introspection [16:45] but it's just a minor detail, whenever it does, we'll make sure to update the site's wording [16:46] ok, so if there are no more questions, let me continue with the rest of the session [16:46] While John mentioned the next Ubuntu Developer Summit (UDS) and future plans, at the _last _ UDS we already devoted a session to discuss the developer site, [16:47] and what you'll be seeing very soon is the result of that work, [16:47] carried out mainly by the web design team with the help of many other folks at Canonical [16:47] One thing I want to stress is that this is just the beginning [16:47] The App Developer Site is just one part (and a key one) of the overall app developer strategy that we're fleshing out as we speak [16:48] This cycle you'll have noticed many of the visible pieces coming together: [16:48] * Jonathan Lange becoming the Developer Program Specialist, [16:48] * the release of the MyApps online portal to streamline the process of submitting apps and get them published in the Software Centre, [16:48] * more apps flowing into the Software Centre... [16:49] You should definitely check out the log of Jonathan Lange's session last Monday [16:49] where he delivered an overview of the vision and the strategy for app development in Ubuntu [16:49] Also Anthony Lenton and Stéphane Graber talked about different aspects of submitting applications through MyApps last Tuesday [16:49] You'll find it all here: https://wiki.ubuntu.com/UbuntuAppDeveloperWeek/Timetable [16:49] And finally, to wrap up the topic with good coverage from all sides, John Pugh will talk about the business side, that is, [16:50] how Canonical makes money from commercial applications to become a sustainable business and better support the development of Ubuntu [16:50] In short, we want to put Ubuntu on the app development map. [16:50] We want to provide a top level experience through a platform that makes it easy for developers to create applications and distribute them to millions. [16:50] There are 10 minutes remaining in the current session. [16:50] We're laying out a set of solid foundations for that goal, and we're going to build upon them [16:50] Developer.ubuntu.com will be a place to present developers with a clear journey that will guide them through the process of creating and publishing applications for Ubuntu. [16:51] Along the way, they will find all the resources that will enable them to make the right design decisions and direct them to the infromation they need in a clear and consistent manner. [16:51] And another important purpose of the site will be to become the starting point to build an app developer community. [16:52] As such, this upcoming release is what we could consider the first iteration of developer.ubuntu.com. [16:52] By Oneiric's release we'll have a site that we can be proud to direct app developers to, with a place that not only is up to the Ubuntu design standards, [16:52] but also to provide application developers the information they need to get started writing applications in Ubuntu. [16:52] That is the primary goal of that iteration, but we are aware that this will not be enough, and that the site will need to evolve and to grow [16:53] So we will need your help to use it, to participate with your feedback and be part of this effort to make Ubuntu the platform of choice for application development and distribution. [16:54] And with this, I think that's all we wanted to cover [16:54] I hope you found our presentation useful, and if you've got any questions, feel free to ask now [16:54] we've still got a few minutes to answer a few [16:55] There are 5 minutes remaining in the current session. [16:58] tau141 asked: so we can help by using it and by givin our feedback! is there any other way to help? [16:59] I think it would be really useful for those who are developing an app or have developed an app to write about their experiences [16:59] or start writing tutorials and letting us know about them [17:00] I think the resources/reference/documentation section would benefit hugely from content like this [17:00] and of course when we go live [17:00] look out for bugs and let us know! === 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: Rapid App Development with Quickly - Instructors: mterry [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 === 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: Developing with Freeform Design Surfaces: GooCanvas and PyGame - Instructors: rickspencer3 [18: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. [18:02] sooo [18:02] hi everybody [18:02] you just missed my best stff [18:03] I was talking in teh wrong channel for the last 2 minutes :) [18:03] so, let's try again ... [18:03] Hello all. Today I will discuss 2 of the APIs that I have used to have a lot of fun with programming for Ubuntnu. [18:03] These APIs are GooCanvas and PyGame. They are both similar in the sense that they provide you with a 2d surface on which you can construct interactive GUIs for your users. [18:03] seriously, I have had tons of fun writing apps with thes over the years [18:04] However, I fonud them to have different strengths and weaknesses. If you choose the correct API it will be more easy and more fun to write yoru app. [18:04] so, why goocanvas or pygame at all? [18:04] A typical desktop app is composed of widgets that a user is used to. Like buttons, entry boxes, and such. [18:04] For these desktop apps, I strongly recommend sticking with PyGtk for the time being. [18:04] like the next year, I think [18:05] PyGtk is the way to go for what I call "boxy" apps [18:05] I use pygtk all the time [18:05] However, sometimes part of an app, or pretty much a whole app, won't need buttons and lists and entry boxes, but will need to display, modify, or animate images, drawings, etc... [18:05] Sometimes in response to user input, sometimes not. [18:05] My goal for this session is to help you choose the right API for those kinds of apps, and to get you started with them. [18:05] please ask questions at any time [18:05] I will check for questions often [18:06] I'll start with GooCanvas because I already did a session on this last year, so there is lots of material. [18:06] https://wiki.ubuntu.com/UbuntuOpportunisticDeveloperWeek/GooCanvas [18:06] basically, I shall copy and past from there, answering quetsions as I go [18:07] thoguh I may skip some to leave room for pygame [18:07] So what is a goocanvas? [18:07] A goocanvas is a 2d composing surface [18:07] You can use it to make pretty much any kind of image [18:08] It's kind of like an api around a drawing program [18:08] So you can have a ton of fun using a goocanvas, because you are pretty much freed from the constraints of a widget library in creating your UI [18:08] goocanvas is cairo under the covers [18:08] and is designed to easily integrate into your gtk app [18:08] So let's add a goocanvas to a pygtk app [18:09] Add it just like a normal pygtk widget [18:09] #set up the goo canvas [18:09] self.goo_canvas = goocanvas.Canvas() self.goo_canvas.set_size_request(640, 480) self.goo_canvas.show() [18:09] tada! [18:09] you have a goocanvas [18:09] Be sure to set the size, otherwise it defaults to 1000,1000, it does not default to the size alloted to it in your window. [18:09] Handle window resizing to resize your goocanvas as well [18:09] !! [18:10] the goocanvas won't automatically change size if it's container changes size [18:10] For example, if your goocanvas is in a VBox, you can do this: [18:10] rect = self.builder.get_object("vbox2").get_allocation() self.goo_canvas.set_bounds(0,0,rect.width,rect.height) [18:10] remember the root item for your goocanvas, you'll need it later often self.root = self.goo_canvas.get_root_item() [18:10] The "root" is like the root of an item tree in XML [18:10] So now that we have a goocanvas, we need to add "Items" to it. [18:10] Anything that can be added to a goocanvas is an Item. It get's it's capabilities by inheriting from ItemSimple, and by implementing the Item interface. [18:11] Let's add an item to the goocanvas to get a look at how it works in general. [18:11] We'll start by adding an image. [18:11] First, you need to get a gtk.pixbux for your image: [18:11] pb = gtk.gdk.pixbuf_new_from_file(path) [18:11] Then you calculate where you want the image to show on the goocanvas. You'll need a top and a left to place most items on a goo canvas. [18:11] For example, to center the image, I do this: [18:11] cont_left, cont_top, cont_right, cont_bottom = self.goo_canvas.get_bounds() img_w = pb.get_width() img_h = pb.get_height() img_left = (cont_right - img_w)/2 img_top = (cont_bottom - img_h)/2 [18:11] it's a bit hard to read, I guess [18:12] but I basically just calculated the pixel center of the goocanvas [18:12] and stored the "bounds" that the calculation returned [18:12] Now I am ready to create the item. [18:12] Note that I create the Item, but there is nothing like goocanvas.add(item) rather, when you create the item, you set it's parent property. [18:12] The parent property is the root of the goocanvas [18:12] This is why I remember the root [18:12] goocanvas.Image(pixbuf=pb,parent=self.root, x=img_left,y=img_top) [18:13] This basic pattern is how you add all other types of items. [18:13] decide where to put the item, and set it's parent property to the root of the goocanvas. [18:13] To remove the item from the goocanvas, you don't tell the goocanvas to remove it [18:13] rather you tell the item to remove itself [18:13] item.remove() [18:13] any questions at all so far? [18:14] In a moment, I'll go on to discuss the types of things that you can add to a goocanvas [18:14] In my mind, there are really 3 types of items [18:14] normal items that you add to draw the stuff you want [18:14] this includes: [18:14] Ellipse, Image, Path, Polyline, Rect, and Text [18:15] the second type is for layout [18:15]