=== uchobby_afk is now known as uchobby === tenach_ is now known as tenach [12:40] Hello [12:42] sKuarecircle_, hey there, what are you looking for? === harry is now known as Guest1771 === Mohan_chml is now known as IAmNotThatGuy === ApOgEE__ is now known as ApOgEE === IAmNotThatGuy is now known as Mohan_chml === MAfifi is now known as MSK61 === alecu_ is now known as alecu === 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: Ubuntu App Developer Week - Current Session: Manage your source code history! - Version Control with Bazaar - Instructors: MSK61 [15:01] Welcome, everybody. [15:02] May I know who's there by saying hi? [15:02] OK. Seems good. Let's tatart. [15:02] Start*. [15:03] Today's session is about source control(aka other names like revision control, version control, ...etc). [15:03] So what's source control? It's the ability to keep the history of how a software project evolved through different stages. [15:04] It maintains information about who contributed to each feature, when different releases were available, ...etc. [15:04] As if someone were able to take snapshots for a software project across different instants of time. [15:05] Historically, there were two models for version control: centralized and distributed. [15:06] Centralized version control works in a client-server fashion, with the server having all the meta-data for the project, while different contributors check out a working tree for the trunk(or a specific version). [15:06] And every time someone wants to commit, he/she must be connected to the server. [15:07] Distributed, on the other hand, worked on peer-to-peer like fashion. [15:07] Each contributor had the full source tree(with all revisions and history), and any contributor can pull from/push to other contributors. [15:07] Clear so far? [15:08] So which model does bzr follow? [15:08] Fine, it follows the latter model, distributed. [15:09] And this has the benenfit that you don't have to be connected to a server to commit; you can just commit as many versions as you can offline, and then push to another repository when you get connected. [15:09] OK. To start, we first need to install bzr. [15:10] In a terminal, type "yum install bzr". [15:10] Should be pretty fast. [15:12] We'll base our example on plain-text files, but of course it should work with any type of files. [15:12] Now create a directory called "myProj" for example. [15:12] mkdir myProj. [15:13] Now, cd myProj. [15:14] mkdir trunk. [15:14] To crearte a trunk branch(; it may be called anythin). [15:15] Now, in the terminal type echo "Thi's the first line" > hello.txt [15:15] maheshmohan asked: What is a trunk? [15:16] A trunk is conventionally the branch which holds the development(read most recent) snapshot of the software project. [15:16] You can give it any name, but trunk is a famous convention. [15:17] Other SCM(source control management) tools might call it tip, or so,. [15:17] Now inside trunk when you list the files you should see hello.txt [15:18] OK for all? [15:19] So everyone is now inside trunk the trunk folder and sees hello.txt file? [15:20] OK. Now we've created a source file(hello.txt in our case). [15:21] ls -AR should produce something like this http://paste.ubuntu.com/502649/ [15:21] Now issue the command bzr stat [15:23] Get out of the trunk folder. [15:23] Remove it with "rm -r trunk". [15:24] OK? [15:24] Now, being inside myProj, issue the command "bzr init-repo ." [15:25] This's needed to tell bzr to create a repository(a place where it'll maintain a project history in). [15:25] ls -AR should yield http://paste.ubuntu.com/502652/ [15:26] OK? [15:32] I'll illustrate what the steps we did so far were for. [15:33] From scratch: [15:33] mkdir myProj => Create a directory for the bzr repository. [15:33] cd myProj => Enter the directory. [15:34] bzr init-repo . => Tell bzr to initialize the repository with metadata. [15:34] Clear so far? [15:34] Anyone missing should be OK by executing these steps from scratch. [15:34] Now, issue [15:35] mkdir trunk => conventional trunk(development) branch [15:35] A repository can hold several branches, for example branches for different releases, different platforms, ...etc. [15:36] But a repository should contain at least one branch(trunk in our case). [15:36] cd trunk => Enter the branch directory. [15:36] bzr init => Initialize the branch metadata. [15:37] You notice now that two different commands for metada are used, one previously for the repository, and one for each branch you create(just trunk in our case). [15:37] And for the branch, if you're inside the branch directory, you don't have to specify the location(like we did with . in the repo). [15:38] Now, create a source file. [15:38] echo "This's the first line." >> hello.txt [15:38] This command created a source file called hello.txt. [15:38] OK? [15:39] Now issue the long awaited command [15:39] bzr stat => Show the status of changed files in the branch. [15:40] You should get this http://paste.ubuntu.com/502661/ [15:41] This means that bzr has found a strange file(a file that hasn't been added to the source control). [15:41] Now to add it, issue [15:42] bzr add => Add all unknown(new, strange) files to the source control. [15:42] bzr stat => This time it'll show http://paste.ubuntu.com/502663/ [15:43] Which means bzr shows that the file has been added. [15:43] However, all these changes have been made into the working tree. [15:44] Everybody is aware of the working tree concept? [15:45] OK. A working tree is the copy of the source files you're locally using on your computer. [15:45] When you change anything there, it doesn't mean it'll be retained by bzr history management. [15:45] Until you tell bzr to do. [15:45] Clear? [15:46] Now we want to tell bzr to add it as a history point in the history log. [15:47] Issue the command: [15:47] bzr commit => Add the changes as a revision in the history. [15:48] You'll be introuduced by an editor to write a description message for what's been done in this revision. [15:48] Type in any message, like "first release"(without the quotes), and save and close. [15:50] Before, at the very first line. [15:50] rooligan_ asked: before or after the "--------" line? [15:50] Before, at the very first line. [15:50] Now issue the command [15:50] bzr log => Brwose the history of our project. [15:51] http://paste.ubuntu.com/502666/ [15:51] Everyone got that? [15:52] The committer would be different in your case of course. [15:52] Congratulations, you've just created your first release. [15:53] Fine, you don't have to check out because you already have all the history locally. [15:53] If you want to make changes, just make changes and commit again. [15:53] A new release, with a new description message. [15:54] OK. I had many other things to talk about, but there isn't really much time left. [15:54] So I just skim on them. [15:54] For pushes, you can push to a remoate or local branch with bzr push command. [15:54] maheshmohan asked: How can I make my code to colloborate with other developers? [15:55] Basically, bzr push and bzr pull. [15:55] bzr push to publish your changes to another branch, bzr pull to get the recent changes from another branch to your local one. [15:56] Remember that you can always commit locally(as many times as you want), and then push later. [15:57] Now to get help about available commands, just type bzr help. [15:57] bzr help commands. [15:58] The online documentation is also very useful and detailed. [15:59] Other useful, widely used commands, are ls, info, remove, ignore, push, pull, annotate. === 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: Ubuntu App Developer Week - Current Session: Integrate Ubuntu One in your applications - Instructors: rodrigo === MSK61 is now known as MAfifi [16:04] ah, hello! [16:04] shall I start? [16:04] rodrigo_: it's all yours! [16:04] ok, so hi everyone [16:05] my name is Rodrigo Moya, and I work for the online services team at Canonical [16:05] working on GNOME integration of U1 [16:05] I guess you all know what Ubuntu One is, but just in case, I'll do a small introduction [16:06] U1 is your personal cloud, a place where you can store your files and other data that you can sync between machines [16:07] apart from syncing your files, it has integration of syncing of other data, like Tomboy notes, Evolution contacts [16:07] as well as syncing from mobile phones [16:07] so, my talk is about a new library I wrote during Maverick cycle with 2 goals: [16:08] * first, avoid duplication of lots of code in our projects (U1-related) [16:08] * and 2nd, but most important, allow 3rd parties to integrate their apps with U1 [16:08] so, a bit of background [16:08] U1 has 2 components on the desktop, a daemon that takes care of syncing your files [16:09] and a personal CouchDB server to sync notes, contacts, bookmarks, gwibber messages, etc [16:09] for the CouchDB part, we already have good APIs, like couchdb-glib, which is a C GObject-based API with introspection (so has bindings automatically for several languages) [16:10] and desktopcouch, which is a Python API, about which aquarius has already given talks at other developer weeks [16:10] for the file syncing daemon, we already had an API, but it was a DBus API [16:10] while it is great to be able to communicate with it via DBus [16:11] time has proven that 3rd parties don't want to deal with low level details of a DBus API [16:11] also, DBus needs you to take care of asynchronous calls, error reporting, data marshaling, etc [16:11] that's the code we were duplicating in our U1-related projects [16:12] so, the Nautilus plugin and the music store widget (yeah, I forgot to say U1 also has a music store!) and other parts of the system were using this DBus API [16:12] but no 3rd party, till now that I know, has made use of it [16:12] so, I started writing a library (libsyncdaemon) which is a layer on top of this DBus API [16:13] it hides all the complexity [16:13] like async calls, data marshalling, etc [16:13] and offers a GObject-based C API, with introspection for automatic generation of bindings for several languages [16:14] btw, if there are questions, feel free to interrupt me, ping me on #ubuntu-classroom-chat [16:14] so, any question so far? [16:14] ok, no questions :) [16:15] btw, alecu is giving a talk about DBus later on :) [16:15] ok, so this library, given the time constraints I had for maverick, only wraps the low level DBus API, so that's what we'll be looking at [16:16] but I already started adding high level stuff to the API, so for Natty, there should be much easier ways of doing what we'll be showing during the talk [16:17] so, what does wrapping the DBus API mean? [16:17] it means that it provides a similar API than what the DBus thuing offers [16:17] but with a few helpers [16:17] for instance, you don't have to deal with data marshalling [16:18] this is very important, since the DBus API returns a lot of data in dictionaries [16:18] to read the data in the dictionaries, you need to understand what each field means, apart from knowing the names of the fields [16:18] also, it deals with service lifecycle [16:18] it shouldn't happen, but sometimes DBus services die [16:19] there is a way in Dbus to detect that, but it's a bit lowlevel [16:19] so libsyncdaemon does it for you [16:19] so, if the dbus sertvice dies and is restarted, libsyncdaemon will keep working, you won't have to recreate the objects, connect to the signals again, etc [16:20] so, this for some background, so if there are no questions, we can go to see actual code [16:21] ok, seems no questions [16:21] so, let's see some code [16:22] I'll show the C code, and I'll try to guess the Python code equivalent to the C code [16:22] so, in C: [16:22] #include [16:22] in Python: from gi.repository import SyncDaemon [16:23] btw, to see the actual code: bzr get lp:ubuntuone-client [16:23] or if you just want the headers/introspection stuff: [16:23] sudo apt-get install gir1.0-syncdaemon-1.0 libsyncdaemon-1.0-dev [16:24] so, the main object you want to start with is, in C, SyncdaemonDaemon (yeah, redundant :-) [16:24] in Python: SyncDaemon.Daemon() [16:24] this is the main class, and has access to all the functionalities [16:25] first, it provides some functions of its own, not very interesting: [16:25] syncdaemon_daemon_connect (or daemon.connect() in python) [16:25] syncdaemon_daemon_disconnect [16:25] syncdaemon_daemon_quit [16:25] it also deals with the startup problem in u1 syncdaemon itself [16:26] it needs to do a lot of things before he can respond to the DBus calls, so SyncdaemonDaemon object has a "ready" signal [16:26] which signals apps when they can start calling it [16:26] so, for instance, you would do in your app: [16:26] daemon = syncdaemon_daemon_new (); [16:27] g_signal_connect (daemon, "ready", daemon_is_ready_cb, my_data); [16:27] and when your callback is called, you can start doing whatever you want with syncdaemon [16:27] SyncdaemonDaemon also has a lot of signals for notifying the app about status changes, transfers, etc [16:28] so, this is the main object [16:28] and since it wraps the dbus API completely, it provides access to the different interfaces implemented by syncdaemon (the dbus service) [16:29] there are 6 of them, but only a few of them are of interest to us [16:29] there is the config interface, which allows you to check/change the configuration of syncdaemon [16:29] like how much bandwidth to use, etc [16:29] this is not very interesting to apps, so I'll skip it [16:30] ditto for the events interface, it provides notifications of different low level events, so, since we have some high-level ones, I'll skip this one also [16:30] the next one is the filesystem interface [16:30] you can get a handle to it with: [16:31] interface = syncdaemon_daemon_get_filesystem_interface (daemon) <- C [16:31] interface = daemon.get_filesystem_interface () <- python [16:32] this interface allows you to retrieve metadata for a given file or folder [16:32] to get information like whether the file is synced or not, for instance [16:32] metadata = syncdaemon_filesystem_interface_get_metadata (interface, path, TRUE or FALSE) [16:33] this returns a SyncdaemonMetadata object, which contains that information I was talking about [16:33] the next interface is a bit more interesting, so if you're not asleep yet, please listen :) [16:34] this next interface is the folders interface, which allows you to synchronize any folder on your $HOME with Ubuntu On [16:35] that's interesting, because a photo app, for instance, could easily provide a way for synchronizing a photo album to your personal cloud [16:35] (that's the kind of 3rd parties we are looking for, as an example) [16:35] this interface, like all others, is retrieved with: [16:35] interface = syncdaemon_daemon_get_folders_interface (daemon); [16:36] with this interface, you can retrieve the list of folders set up for syncing already: [16:36] GSList *syncdaemon_folders_interface_get_folders (SyncdaemonFoldersInterface *interface); [16:36] or add new folders (your photo album): [16:37] void syncdaemon_folders_interface_create (SyncdaemonFoldersInterface *interface, const gchar *path); [16:37] or delete folders you don't want to be synced anymore: [16:37] void syncdaemon_folders_interface_delete (SyncdaemonFoldersInterface *interface, const gchar *folder_id); [16:37] you can also do things that are not available in the current GUI for maverick [16:37] like subscribing/unsubscribing a folder [16:38] unsubscribing means that you don't want a specific folder to be copied to this machine [16:38] imagine a netbook with very little disk space, you might not want to sync your huge music collection to it [16:39] now, to the most interesting one, since it allows to do a lot of nice things [16:40] there is the notion of public files, whcih are files that you publish via U1 and that everyone can see, no matter if they have an U1 account or not [16:40] this is very nice for, "I'll take a screenshot and show you' kind of things [16:40] this is, again, retrived with: [16:40] interface = syncdaemon_daemon_get_publicfiles_interface (daemon); [16:41] and has a simple call that does everything: [16:41] void syncdaemon_publicfiles_interface_change_public_access (SyncdaemonPublicfilesInterface *interface, [16:41] const gchar *share_id, [16:41] const gchar *node_id, [16:41] gboolean is_public); [16:41] as you can see, it is low level, since it includes stuff you shouldn't be dealing with [16:41] I tried to add a simple publish_file API, where you pass a path only, but it's not as easy as that [16:42] first, publishing a file only works on folders that are setup to be synced to U1 [16:42] but I plan to add it to the high level API [16:42] so, in a screenshot app, for instance, you could add a button that said 'Publish in U1' [16:43] and just call that imaginary high level API (syncdaemon_daemon_publish_file) and the file will be published at a given url [16:43] something like http://one.ubuntu.com/p/Df3dr [16:44] a lot of examples about this raise, like publishing photos from the photo app [16:44] and I'm sure you can find a lot [16:44] the last interface we're going to see is the shares ones, which allows you to share a folder already in U1 with someone else [16:45] as well as deal with shares offered by other users to you [16:45] void syncdaemon_shares_interface_accept (SyncdaemonSharesInterface *interface, const gchar *share_id); [16:45] void syncdaemon_shares_interface_reject (SyncdaemonSharesInterface *interface, const gchar *share_id); [16:45] these 2 are for accepting or rejecting shares by other users [16:46] void syncdaemon_shares_interface_create (SyncdaemonSharesInterface *interface, [16:46] const gchar *path, [16:46] GSList *usernames, [16:46] const gchar *name, [16:46] gboolean allow_modifications); [16:46] void syncdaemon_shares_interface_delete (SyncdaemonSharesInterface *interface, const gchar *share_id); [16:46] and these 2 for sharing with someone or deleting a share [16:47] to finish, I'll talk a little bit about libubuntuone, which was supposed to be a widget library for easy use of U1 features in GTK apps [16:47] there was a contacts picker (the one you see when you click on Ubuntu One->Share in Nautilus [16:47] and a music store widget [16:48] thanks to that music store widget, banshee plugin for the U1 music store was written by directhex in a few days [16:48] so, I think that's all, I'll leave the rest for questions, if there are any [16:49] hmm, no questions, is anyone listening :) [16:49] ah, a question: [16:49] QUESTION: so this will be available in maverick then? [16:49] zinga49, yes, it already is [16:50] what is not available in maverick is a better high level API, but it should probablt be (or part of it) for natty [16:50] QUESTION: and to use it in pyhton i install the above 2 modules? [16:51] well, for only python, you don't need the -dev package, so gir1.0-syncdaemon-1.0 should be enough [16:51] rye (in #ubuntuone) had some code using the automatic Python bindings, so ask him for an example [16:52] so, with this, it should be easy to provide high level stuff integrating with U1 [16:52] I already mentioned some simple examples, but I'm sure you can find lots of apps in Ubuntu that would make sense to have something like that [16:53] like publishing files, etc [16:53] f-spot, gnome-screenshot, etc [16:54] ok, so no more questions? [16:55] QUESTION: rodrigo_, is the client code in maverick already using your library? [16:56] ara, the C parts of it are, like nautilus plugin, tomboy (using a part of the API I didn't mention, which is for registering a user with U1) and the music store widget [16:56] the rest of the client code in maverick is either the daemon itself, which doesn't need this api [16:57] and u1-prefs, which doesn't use the DBus service [16:57] QUESTION: rodrigo_: so, no Python example code yet ;-) [16:58] ara, yes, ask rye in #ubuntuone, he wrote an app to automatically publish files, I think [16:59] also, worthy to say that this has been added in maverick, so the only place that I changed to use it was the nautilus plugin [16:59] which had a lots of complicated code to deal with the DBus stuff [16:59] and the music store widget, which only needed a couple of calls (mainly for tracking transfers) [16:59] so, the already existing code wasn't changed, but I would do asap if I had time :-) === 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: Ubuntu App Developer Week - Current Session: Hacking on 'testdrive' - Instructors: andreserl [17:00] ok, I think we're out of time === RoAkSoAx is now known as andreserl === andreserl is now known as RoAkSoAx [17:01] Alright :) [17:01] Hi everybody! Welcome to the Hacking on TestDrive Session. [17:01] My Name is Andres Rodriguez and I'm a community member. My areas of contribution are MOTU, the Server Team, and the Cluster Stack! (And now application [17:01] programming :)) [17:02] I want to know who's here for the session so that I can begin [17:03] Ok, let's get started then [17:03] Unfortunately, due to some unexpected situations (Fumigation at my place, and Ubuntu won't connect to Wireless-N Router where I'm at), I won't be able to do [17:03] all I wanted to do today. Anyways, today's session is going to be: [17:03] 1. Introduction [17:03] 2. My Experience [17:03] 3. How to Contribute [17:03] 4. Questions [17:04] NOTE: I'll reply any of your questions at the end of the session. [17:04] Just before I begin, please install "quickly" given that it may take some time. [17:04] sudo apt-get install quickly [17:04] let me know when you have quickly installing [17:06] rooligan_: Ok, for those who don't know what quickly is. Quickly is a tool that allows the creation of Ubuntu Apps easily you can read more about it here: https://wiki.ubuntu.com/Quickly [17:06] == Introduction == [17:06] TestDrive is a tool that was originally developed by Dustin Kirkland to test Ubuntu ISO images. He presented the tool at the Ubuntu Developer Summit in [17:06] Dallas last year. Back then, the tool was a shell script. Then, he decided to change it to a single file python script. Nowadays, and with the creation of [17:06] TestDrive PyGTK, it is a collection of classes/modules. It is not perfect, but it works. [17:07] Btw, I'm glad to say that TestDrive PyGTK was my GSoC2010 project for Ubuntu, and my first real experience with python and GTK. [17:07] , though I started working on [17:07] it way before the GSoC. [17:07] now, how many of you here have used or currently use TestDrive? [17:09] ok well, now we all know what TestDrive is: And App to test Ubuntu ISO images, but it is not limited to Ubuntu specific only [17:09] given that we can test other ISO's that are in our harddrive, or even in any other repository [17:09] So anywa,s I'd like now to tell you in a short summary my experience coding it :) [17:09] == My Experience with App Development for/in Ubuntu == [17:09] First of all, I'd like to say that my experience developing TestDrive for Ubuntu was really fun and satisfactory. [17:09] And well it all started when I grabbed the TestDrive python script. The objectives were: [17:09] 1. Modify TestDrive in such a way that it would be easy to attach different fron-ends. [17:10] 2. Add the PyGTK Front-end. [17:10] The first, so called modularization, was to separate the python script's UI code with the "back-end's" code. This would be what we all call MVC. By [17:10] separating this code, I was making sure that I could re-use most of it when Implementing the Front-end. [17:10] Modularization, step 1: So, a class TestDrive was created to handle all the "back-end" work of testdrive, having an UI that just instances an object of the [17:10] class, and access this class' methods to do most of the work. At this point, I had separated TestDrive code in two, a binary (testdrive) and a module [17:10] (testdrive.py). [17:11] Modularization, step 2: Now, given that we use different virtualization methods and that it would be nice to add new ones, we also decided to separate the [17:11] virt method from the testdrive module. For this, we created three virt modules (kvm.py, vbox.py, parallels.py). These modules, do all the configuration [17:11] necessary to run an ISO in the VM, and return a command ready to launch the VM. [17:12] So, so far, we are learning that TestDrive test's ISO by running them in a VM, either using KVM, VirtualBox or Parallellels [17:12] the preferred method is, of course, KVM [17:13] So, what about the PyGTK. Well, after the first step of the modularization, I started working on the Front-end. before starting with it, I figured that it [17:13] would be a good idea to use quickly to create the front-end, and so I did. Quickly is such an amazing tool!! Anyways, I started the front-end with a single [17:13] list of ISOs, then turned into separated categories of ISO's, and so on. [17:14] Now, up to this point, we not only had a command line tool to test ISO, but a simple PyGTK tool with the same purpose [17:14] I faced one problem though! Which was being able to Sync and Run Multiple ISO/VM's at the same time. For that I implemented python threading for Syncing [17:14] ISO's, and that's when I also decided to go for the modularization of Virt Methods, to provide better threading support. [17:14] After this, I also implemented the posibility to add Other ISO's not in the Ubuntu repository. Of course, along all this I worked on other stuff such as [17:14] implementeing the preferences, improving the UI, improving the preferences methods and changed the configuration to configparser, logging capabilities, bug [17:14] fixing, etc etc. [17:15] so, TestDrive PyGTK ended up being a cool tool where I could launch multiple ISO in a VM, or sync them. I also have the possiblity to change preference [17:15] such as how much disk size per VM image, how much RAM to assign, How many CPUs, at all sort of that stuff [17:16] SO, to do all this I pretty much had to learn python and GTK from scratch; and in only three months I learned a lot!! and it was Super FUN. A cool tool that helped me in the process was Acire!! === JanC_ is now known as JanC [17:16] I'm sure that all of you know what Acire is, if not... it is a toold that puts together lots of python snippets that can help any developer by showing them how to implement these snippets [17:17] So yes, this a kinda confusing sum up of how TestDrive PyGTK came to live... anyone has any questions so far? [17:19] Ok then [17:20] OK so now, you might wonder... how can I contribute ?? [17:21] Well, there are many ways to contribute with TestDrive... In fact, couple people already contributed, and471_ is one, am I correct :) [17:22] anyways, to code testdrive I created a Blueprint to track all what was necessary. We had a session at UDS-M in Belgium where we talked about what were the features that ppl wanted to see in teh PyGTK [17:22] most of these features are detailed in: [17:22] https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-testdrive-frontend-gsoc [17:23] If you can see in the section "Work items for ubuntu-later:" [17:23] all those work items are to be done [17:23] most of them is adding simple features or improvements [17:24] However, contributions are not only limited to do that [17:24] There're some other things to be done such as [17:24] - Maintainance and improvements of other Virtualization Methods (VBox and Parallels) - Add new Virtualization Methods (Such as VMWare) - Various other improvements - PyQT4 Front-end [17:24] As I mentioned earlier, TestDrive can either work with KVM, Vbox and Parallels, being KVM the preferred method [17:25] but, I'm not a VBox user and there are lots of VBox users out there [17:25] that use TestDrive with VBox, but since I'm not a user [17:26] I can't always maintain the VBox (or Parallels code) as I can with KVM [17:26] so, we are always looking for people to work on VBox or Parallels, or even, to implement other virtualizations, such as VMWare [17:27] We actually have a bug report asking us to do that, but we (Dustin and me), prefer having someone contribute on that part [17:27] so if you are really interes in crontributed on that,and use VBox, Parallels, or VMWare... jsut ping me sometime [17:27] and you can get started :) [17:28] Now, one things that would be cool too is to have a PyQT4 front-end for Kubuntu [17:28] that would be great front-end to have for those users [17:28] so, there's another place where people who works with PyQT can contribute [17:29] and well, I'll guide you through the development if you wish [17:29] anywas, we also need testers to test and report bugs agains testdrive [17:29] to report any bugs that I might have missed [17:30] I know there are a few, which I'm already planing to address [17:31] but if someone wants to chip in [17:31] you are more than welcom :) [17:31] most of these are mainly improvements to the current code [17:32] however, if you have more ideas that you think might be interesting to have in TestDrive, please bring them on [17:32] well now we;ve been over a few things that it's needed to be done [17:32] but, if you'd like to contribute, how can you get started??? [17:32] it is easy!! [17:32] I'll give you a guided tour through the code :) [17:33] first step is to get the source [17:33] so place yourself in whatever folder you like from your terminal [17:33] and get the latest branch: [17:33] bzr branch lp:testdrive [17:33] and then enter the created folder [17:33] cd testdrive [17:34] rooligan_: :) [17:34] anywas, do you all now have the branch? [17:35] ok while you get it, I'll continue with teh explanation [17:35] when I created the PyGTK with quickly, I did it as a separate project [17:36] and then I had to merge it altogether [17:36] the meging was quite easy [17:37] it was just a correct organization [17:37] of the code in the source directory [17:37] once that was done, everything is done quickly [17:37] :) [17:38] the code is somehow divided like this: [17:38] bin -> contains testdrive-gtk and testdrive binaries [17:38] testdrive -> contains the testdrive.py, and virt modules [17:38] testdrivegtk -> contains all the classes related to the gtk [17:39] data -> contains two directories, media and ui [17:39] media contains all the iamges [17:39] and ui contains the .glade and .xml files for the UI [17:40] so, how can I start working on them [17:40] it is really simple [17:40] first of all [17:40] lets set up our python path [17:40] we are placed somewhere here: '/home///testdrive' [17:41] so we will set it up like: export PYTHONPATH=/home///testdrive [17:41] or export PYTHONPATH=`pwd` [17:41] once that is done === asd is now known as Guest84970 [17:41]