Last day of Class... then finals!

On Tuesday, we met up to work on our presentation going over all of our work for this semester.  We each took a different part to cover.  My portion of the presentation will be about the bug that we submitted earlier on in the semester.  We've uploaded our presentation, and it can be found here.

Tomorrow is the last day of class.  I can't believe how quickly this semester has flown by.  Also, tomorrow is the poster session.  The poster is ready to go, and I'll be there from 11:30 - 1:30 (right about up until class tomorrow).  I'm hoping we'll find some people interested in our work this semester.

Overall, I'm very satisfied with what we've accomplished this semester.  Of course, Nutri isn't perfect (there's plenty of things that can be done to make it more user-friendly).  However, this will probably have to wait until after our presentation (along with finals and projects from other classes -- too many things going on at the moment).  I plan on working on Nutri after this semester is over.  I've really enjoyed working with Sugar as our open source project for this semester, and I think it's turned out to be a great learning experience for our team.

Almost Done!

This weekend, we made a ton of progress.  An overview of our progress can be found on our team wiki.

We met for almost 4 hours on Sunday, knocking out different tasks that needed to be done.  First of all, we finalized our first official version of Nutri.  We made a few minor tweaks to the image files (so that the activity displayed a little nicer).  After that was finished, Megan took the code and compiled it into the .XO file.

Megan also added our code to the Gitorious repository, which can be found here. This is where future development of Nutri will take place.  Using Git will enable us to work with any other developers that wish to contribute to Nutri, rather than Subversion (like we have throughout the semester).  This way we can still communicate with each other (meaning our team in class), along with other potential contributors.

The activity is now also posted on the sugar activities page!  This is very exciting to see our project actually becoming something that can be used by others.  I hope we'll get good feedback from users.  At the time of writing this, it looks like we already have 2 downloads (although that could just have been us testing it out...).  I'm interested to see how many downloads we get.

The wiki is now up and running! The wiki is where anyone can go to download the XO file, the source code to contribute, or to simply find out more information about Nutri.  Wiki's are the preferred form of documentation for Sugar activities.

Alex spent time working on our final presentation.  I'd rather not discuss too much detail about it on here, as it would give away too many surprises about our presentation.  But let's just say that our "plan" is proving to be a little more difficult than expected.  We may have to change a few things, but we'll see.  We do still have plenty of time to get our presentation together, I believe.

I spent most of my time on Sunday creating the poster for our group.  I was unaware that the poster was due at Noon on Monday, so I wanted to make sure that it was ready to go.  I printed out the poster today, and I'm very happy with it!  I think the poster session on Thursday will be interesting.  Hopefully we will catch interest of some people at the poster session.  I plan on brining my laptop to the session, just in case someone wishes to see the program itself (rather than just the poster).

Another Breakthrough for Nutri

During class on Tuesday, we've made great progress.  We've finally gotten Nutri to display in full screen!  No more windows displaying within sugar.  Also, we've gone ahead and updated our icon to match Sugar's standards.  Sugar requires that we use a black and white icon for our activity.  When an activity is loading in sugar, it changes colors to signify that something is happening.  We've updated the icon so that this takes place while the activity is loading.

What's left:

1.  When you open the activity, there's no way to quit it.  We still need to get the toolbar working, so that the user can end the activity and go back to the rest of the Sugar OS.

2.  Wiki.  We still need to create a wiki page for our activity.  The wiki will have our progress of the activity, bugs, new features, etc.  Of course, it will also describe the purpose of the activity, and how to use it.

3.  Presentation.  We need to start working on our final presentation for this class.  I believe Megan started putting together a powerpoint, but we need to work out more details.

We plan on meeting this weekend to work out all of these.  Overall, I'm very happy with our activity (which I think is now pretty much officially named Nutri).

More Progress

During class on Thursday, we had a major breakthrough with Nutri.  From my last blog post, I mentioned that we found an activity called Log that will help us figure out what the problem is when we try to run our code.  I wasn't that familiar with the code in the first place (Alex is most familiar with it), so I had her take a look at the errors being produced on Thursday.  Within minutes (after tinkering with our code), we finally got Nutri to open up successfully in the Sugar OS!

This was a big breakthrough for us, but there's still plenty to fix.  First of all, the activity didn't function properly when we tried changing things (like setting how many servings the user had, etc.).  Turns out that we lost a few necessary functions to make this work properly (I think Megan had removed them when we were trying to "Sugarize" our activity).  So once we fixed this (and made a few other minor incompatibility changes), Nutri functioned properly.  

The only other coding that is absolutely necessary for us to fix is the window.  Currently, the window within the Sugar OS displays as a separate window inside of Sugar.  This is obviously not ideal.  We want our program to look and feel just like any other activity in Sugar, so we need to figure out how to make our content fit properly in the Sugar window, and not a window of its own.  The Hello World tutorial we followed (along with other examples of sugar activities) use something called a GTK VBox as their outermost container of the Sugar App.  We tried changing ours to this, but it ends up breaking other parts of our code... so we're not sure if this is the solution.

We met again this weekend (on Sunday) to try and fix this.  Unfortunately, we didn't have much success.  Alex wasn't able to attend the meeting, so hopefully once we get with her on our further progress, we should be able to overcome this issue.  Once this is resolved (I'm assuming this will be by tomorrow -- at the latest by Thursday), we'll still be on track.  The only thing we'll need to do before we present will be to create our Wiki page, and send in our activity to (hopefully) be approved.  

Nutri Progress

Since Tuesday, we've made some great progress.  During class on Tuesday, we began following this guide that Alex pointed out -- a PyGTK to Sugar tutorial.  This guide showed us an example set of code where someone converted a GTK-based python program into a "Sugarized" version that can be run within Sugar.  This activity helped us figure out what was necessary to convert a GTK-based application into a "Sugarized" activity.  Unfortunately, the guide didn't actually have the source code available for us to compare side by side with ours.  They did, however, provide the .xo file (the Sugar Activity file that can be run within Sugar).  After doing a little research, I realized that .xo files are simply just .zip files but renamed.  So we can easily view the source code of the .xo file simply by saying:

unzip filename.xo

This gave me the contents of the activity for me to better compare our activity to the tutorial's activity.  After comparing and making more changes to our code, I went ahead and tried running our activity in Sugar.  Still no luck.

Making minor changes to the code without getting any feedback from Sugar was going to make it almost impossible for us to figure out what's going wrong, so I searched for a new way to go about "Sugarizing" our activity.  In search of a way to debug our program (within Sugar), I found a very useful activity called Log.  This guide pointed me in the direction of Log.  Log is a Sugar Activity that will display a log file about any activity that is run within Sugar.  So once our activity crashes, we can pull up the Log activity to see why the activity failed to run properly.

While we still haven't gotten the activity to actually run within Sugar yet, this is excellent progress.  Now we actually have a way to figure out why our activity is crashing.  It shouldn't be much longer now before our activity is working properly within Sugar.

Activity Progress

More activity progress:

I'm still trying to get the Activity to work within the Sugar Environment.  On Thursday, I continued following this guide to help me "Sugarize" our pygtk application into a Sugar Activity.  I've gotten the activity to show up in the Activity list (within the OS), but when I launch it, it doesn't display properly.

Megan was using this guide to try and "Sugarize" our activity.  This guide shows major differences in code when converting from a PyGTK application to a "Sugarized" version.  We printed out the code to compare the major differences:

PyGTK Version:

class ReadEtexts():

def main(self, file_path):

Sugar Version:

from sugar.activity import activity
from sugar.graphics import style

class ReadEtextsActivity(activity.Activity):

I think I've made all the differences necessary to "Sugarize" Nutri (the current name given to our Activity).  However, it still doesn't seem to give me any positive result.  Unfortunately, it doesn't seem like Sugar has any form of Debug mode (or even a way for me to know what error is occurring when the Activity launches), it simply says that the Activity failed to start.  I'll keep looking into why this isn't working.  Luckily, I think we're a bit a head of the game anyways, so we have time to work this out.  If I don't get passed this issue by tomorrow, I'll pop my head into the IRC chat and see if anyone can offer some help.

Activity Progress

Since our last class meeting we've made some great progress on the activity.  For starters, in class we were able to finally get the drop-down menu to populate with the data that the user selects. It doesn't sound like it would be that difficult, but it was giving us some trouble.  Since we're now able to get the information from the drop-down box, the next step is to implement the algorithm.

Megan and Austin have been working on the algorithm that we will use to calculate the user's heath status.  Alex took the algorithm and implemented it into our code.  Before, we were unable to really test the algorithm, since we couldn't get any data from the drop-down's.  Now, the algorithm works properly and we're able to retrieve and update the user's Health meter.

My role (at least in this stage of our development) is to figure out the process of converting application over to the Sugar OS.  Currently, our app runs via python directly (in its own separate window).  My goal for this weekend is to take Alex's code and merge it into a working Sugar App.

Other things to do:

1.  Create documentation.  The Sugar community's documentation basically consists of wiki pages.  We need to create a wiki page for our activity's progress.  Some things we can put on here are current bugs, features, feature suggestions, release notes, etc.  Documentation will be useful for anyone else who might be interested in contributing and making changes in the future.

2.  Expand on functionality.  Since our first presentation for the class, we were told to try and get a prototype out as quick as possible, and doing so has caused us to cut back more and more on our functionality (just to get something out ASAP).  So, now that we have something that works (for the most part), we can spend the rest of the semester working on new features and enhancements.  This works out really well for us, because our "goal" for the end of the semester can change.  If we have time to implement more new features, then of course we will.  If time doesn't allow us to create numerous features throughout the remainder of the semester, then we at least will have a completed and polished activity.

Overall, I'm very pleased with our current progress of the Activity.