Social Help for Sugar: Week 2

So, another week gone. Here’s the report for this week’s work, though I’m not sure if it’s much.

Last week, I had made a working social-help activity that opened up to the forum. From there, I changed a few things so that pressing a shortcut opens up the activity to the respective category of the forum. This presented a bit of a problem – namely that of unique names for categories. We know that the reverse domain names of the activities are unique. However, these make crappy category name. But, something like org.laptop.Terminal as a category would probably confuse the user quite badly. So, we needed some kind of map. Therefore, I’m using a Python dictionary that maps the activity’s unique name to a category name. In the rare case that the category name isn’t unique, we can map the newer activity to a somewhat longer name, I suppose. Anyway, this is a problem solved.

The next thing on my list was to get a way to autofill the registration form details from the sugar shell. For this, I poured over gtk WebKit documentation (which, to my chagrin, is quite scant for PyGTK and so I had to read docs for C++ based GTK) for the better part of a day with no luck. So, I decided to Google a way out of this. No luck there either. If anything, one thing was made clear – WebKit is just a page renderer – there is no way to control what is being rendered. And so, another hopeless pursuit came to a rather disappointing end.

Then, I rather unspectacularly took a 3 day break. More like the break took me. So, as things are, I’m visiting Hyderabad right now and there happens to be a great dam nearby. And my dear friends just had to drag me there with them to the comforts of an absolutely gentle heat of a 45 degree (celsius, mind you) sun in the middle of nowhere. Oh well. I guess I should be thankful I didn’t burn down.

Moving on. So, the next task to be done was to find a solution to the login problem. This I discussed with Paul. Let me quote the mail:

Me: The other thing I wanted to do isn’t entirely clear to me either. I’ll try to describe it though. Now, sugar is used in the XOs and it will be often just one user that uses a laptop. This means that once a user logs in the first time, he should never really need to log in again.

Paul: Sort of true. When you’re dealing with schools and classroom environments you’re probably going to some measure of laptops getting swapped around. For instance, at the end of the year will each child take their XO into their next classroom – or will the XO stay at the classroom and the kids use different XOs each year? It’s up to the school to decide how they handle it, and they might do it differently. Alternatively, there might be a school with 250 students and 50 XOs (two classrooms) – and classrooms share the XOs, class A gets them for a month, and then class B gets them next month

Me: Now, of course the browser will do this automatically unless the user clears the cookies or logs out. As far as I know, there is no option to clear cookies through the browser (the social-help activity) – the user will need to use the terminal to dig into the datastore and delete the cookie jar manually for that.

Paul: I actually suspect Browse is having a little trouble remembering to log people in, even with cookies, after the XO/Sugar restarts. You may want to check 😀

Me: That leaves us the case when user logs himself out. Now, since the user has done so of his own will, I think that it’d be positively odd to just log him back in automatically the next time he opens social-help. So, you see my dilemma. I think that we should allow the user the choice to log out if he wants to do so. Your suggestions on the issue are welcome, of course.

Paul: In my opinion, clear logging in and logging out options are a necessity if we’re not using on-the-fly anonymous accounts, and users want to track questions they’ve asked/answers they’ve given in the past, etc. The user should definitely be allowed to log out (I’m lending the XO to a friend! I’m changing classroom! Leaving the school!) – and it should try to remember when someone is logged in so they don’t have to do it unnecessarily, but it should state their name somewhere so they can see who they are logged in as (Welcome back Prasoon! Is this you?)

So, I think that I’ll just leave it at that. We may decide to add a Gmail like notice popup for that last part. I’ve asked Paul’s opinion on this in a mail recently.

Anyway, then comes the working with the CSS. I’ve asked Paul’s opinion on this too. He has, just today, let me know of a this guide to aid me in the visual styling. Until now, I have been just fiddling about with the default Discourse styling. Nothing solid though. This guide, I hope, will be of much help. There is another thing – the Discourse custom styling system is a bit lacking. The original styles will all remain and our new style will be applied on top of the existing one. Those acquainted with CSS would know this for quite a problem. We’ll have to pile up !importants for this to work (though theoretically we shouldn’t need those, but that’s just how this works). However, this seems to be the way ahead for now – the Ubuntu team’s discourse has indeed done just this. And so will we, until at least the Discourse team provides users with a better way.

On a side note, I also tried to make a bit of a logo. Come, have a good laugh. My friends did 🙂social-help

Oh well. I suppose we can make something like this.

This week, I’ll be writing quite a bit of CSS, I expect, and giving myself quite a few headaches when the styles don’t work as they should. It always happens when I write CSS. Oh well. See you next week.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s