For Hackweek 11 I thought it’d be fun to learn something about creating Android apps. The basic training is pretty straightforward, and the auto-completion (and auto-just-about-everything-else) in Android Studio is excellent. So having created a “hello world” app, and having learned something about activities and application lifecycle, I figured it was time to create something else. Something fun, but something I could reasonably complete in a few days. Given that Android devices are essentially just high res handheld screens with a bit of phone hardware tacked on, it seemed a crime not to write an app that draws something pretty.

The openSUSE desktop wallpaper, with its happy little Geeko sitting on a vine, combined with all the green growing stuff outside my house (it’s spring here) made me wonder if I couldn’t grow a little vine jungle on my phone, with many happy Geekos inhabiting it.

Android has OpenGL ES, so thinking that might be the way to go I went through the relevant lesson, and was surprised to see nothing on the screen where there should have been a triangle. Turns out the view is wrong in the sample code. I also realised I’d probably have to be generating triangle strips from curvy lines, then animating them, and the brain cells I have that were once devoted to this sort of graphical trickery are so covered in rust that I decided I’d probably be better off fiddling around with beziers on a canvas.

So, I created an app with a SurfaceView and a rendering thread which draws one vine after another, up from the bottom of the screen. Depending on Math.random() it extends a branch out to one side, or the other, or both, and might draw a Geeko sitting on the bottom most branch. Originally the thread lifecycle was tied to the Activity (started in onResume(), killed in onPause()), but this causes problems when you blank the screen while the app is running. So I simplified the implementation by tying the thread lifecycle to Surface create/destroy, at the probable expense of continuing to chew battery if you blank the screen while the app is active.

Then I realised that it would make much more sense to implement this as live wallpaper, rather than as a separate app, because then I’d see it running any time I used my phone. Turns out this simplified the implementation further. Goodbye annoying thread logic and lifecycle problems (although I did keep the previous source just in case). Here’s a screenshot:

The final source is on github, and I’ve put up a release build APK too in case anyone would like to try it out – assuming of course that you trust me not to have built a malicious binary, trust github to host it, and trust SSL to deliver it safely

Enjoy!

Update 2014-10-27: The Geeko Live Wallpaper is now up on the Google Play store, although for some reason the “Live Wallpaper” category wasn’t available, so it’s in “Personalization” until (hopefully) someone in support gets back to me and tells me what I’m missing to get it into the right category.

Updated Update: Someone in support got back to me. “Live Wallpaper” can’t be selected as a category in the developer console, rather you have to wait for Google’s algorithms to detect that the app is live wallpaper and recategorize it automatically.

Since the introduction of P-States in the Intel SandyBridge and newer processors and the introduction of the P-States driver in the kernel since 3.9 there have been some changes to the power management on systems in regards to userspace tools. It has moved from cpufreq to cpupower and you may have written a script in times past to help set the right power management governor for your system. On a system with P-States you find that using cpupower has no effect on the performance whatsoever when you change the governor with cpupower. In order to get high performance out of your system with P-States you will need to look at some parameters into sysfs and change them using the userspace tool cpupower. Lets have a look at what there is for P-States.

Change your directory to /sys/devices/system/cpu/intel_pstate

system:/sys/devices/system/cpu/intel_pstate # l
total 0
drwxr-xr-x  2 root root    0 Oct 21 18:45 ./
drwxr-xr-x 14 root root    0 Oct 21 18:45 ../
-rw-r--r--  1 root root 4096 Oct 21 18:45 max_perf_pct
-rw-r--r--  1 root root 4096 Oct 21 18:45 min_perf_pct
-rw-r--r--  1 root root 4096 Oct 21 18:45 no_turbo

We have the max_perf_pct and the min_perf_pct and if we cat these files we can see their values.

# cat max_perf_pct
100

# cat min_perf_pct
32

One of the things that has always been a bit of a struggle in Firefox for Android is getting reliable video decoding for H264. For a couple of years, we’ve been shipping an implementation that went through great heroics in order to use libstagefright directly. While it does work fine in many cases, we consistently get reports of videos not playing, not displayed correctly, or just crashing.

In Android 4.1, Google added the MediaCodec class to the SDK. This provides a blessed interface to the underlying libstagefright API, so presumably it will be far more reliable. This summer, my intern Martin McDonough worked on adding a decoding backend in Firefox for Android that uses this class. I expected him to be able to get something that sort of worked by the end of the internship, but he totally shocked me by having video on the screen inside of two weeks. This included some time spent modifying our JNI bindings generator to work against the Android SDK. You can view Martin’s intern presentation on Air Mozilla.

While the API for MediaCodec seems relatively straightforward, there are several details you need to get right or the whole thing falls apart. Martin constantly ran into problems where it would throw IllegalStateException for seemingly no valid reason. There was no error message or other explanation in the exception. This made development pretty frustrating, but he fought through it. It looks like Google has improved both the documentation and the error handling in the API as of Lollipop, so that’s good to see.

As Martin wrapped up his internship he was working on handling the video frames as output by the decoder. Ideally you would get some kind of sane YUV variation, but this often is not the case. Qualcomm devices frequently output in their own proprietary format, OMX_QCOM_COLOR_FormatYUV420PackedSemiPlanar64x32Tile2m8ka. You’ll notice this doesn’t even appear in the list of possibilities according to MediaCodecInfo.CodecCapabilities. It does, however, appear in the OMX headers, along with a handful of other proprietary formats. Great, so Android has this mostly-nice class to decode video, but you can’t do anything with the output? Yeah. Kinda. It turns out we actually have code to handle this format for B2G, because we run on QC hardware there, so this specific case had a possible solution. But maybe there is a better way?

I know from my work on supporting Flash on Android that we use a SurfaceTexture there to render video layers from the plugin. It worked really well most of the time. We can use that with MediaCodec too. With this output path we don’t ever see the raw data; it goes straight into the Surface attached to the SurfaceTexture. You can then composite it with OpenGL and the crazy format conversions are done by the GPU. Pretty nice! I think handling all the different YUV conversions would’ve been a huge source of pain, so I was happy to eliminate that entire class of bugs. I imagine the GPU conversions are probably faster, too.

There is one problem with this. Sometimes we need to do something with the video other than composite it onto the screen with OpenGL. One common usage is to draw the video into a canvas (either 2D or WebGL). Now we have a problem, because the only way to get stuff out of the SurfaceTexture (and the attached Surface) is to draw it with OpenGL. Initially, my plan to handle this was to ask the compositor to draw this single SurfaceTexture separately into a temporary FBO, read it back, and give me those bits. It worked, but boy was it ugly. There has to be a better way, right? There is, but it’s still not great. SurfaceTexture, as of Jelly Bean, allows you to attach and detach a GL context. Once attached, the updateTexImage() call updates whatever texture you attached. Detaching frees that texture, and makes the SurfaceTexture able to be attached to another texture (or GL context). My idea was to only attach the compositor to the SurfaceTexture while it was drawing it, and detach after. This would leave the SurfaceTexture able to be consumed by another GL context/texture. For doing the readback, we just attach to a context created specifically for this purpose on the main thread, blit the texture to a FBO, read the pixels, detach. Performance is not great, as glReadPixels() always seems to be slow on mobile GPUs, but it works. And it doesn’t involve IPC to the compositor. I had to resort to a little hack to make some of this work well, though. Right now there is no way to create a SurfaceTexture in an initially detached state. You must always pass a texture in the constructor, so I pass 0 and then immediately call detachFromGLContext(). Pretty crappy, but it should be relatively safe. I filed an Android bug to request a no-arg constructor for SurfaceTexture more than two years ago, but nothing has happened. I’m not sure why Google even allows people to file stuff, honestly.

tl;dr: Video decoding should be much better in Firefox for Android as of today’s Nightly if you are on Jelly Bean or higher. Please give it a try, especially if you’ve had problems in the past. Also, file bugs if you have issues!

I must admit, I’m actually really happy with the Moto360. After reading a load of reviews and speaking to people that already had the device, I was fully prepared for a subpar experience. Maybe that’s the beauty of not being a bleeding edge early adopter :-) The woes that were extolled were many, and the only good thing people had to say were about the stunning good looks; battery life was woeful, not even lasting a day; performance was hit and miss; connectivity to phone was spotty; the list goes on, one almost wonders why on earth I would still want one.

What a conference!!! openSUSE Asia Summit was unforgettable. The whole event had an amazing feel to it, and I had a rocking time in Beijing. openSUSE really has one of the best and most helpful communities, and the people are amazing. I had the pleasure of interacting with the active organization community. You guys absolutely rock!!!

Here are some of my experiences, and things I learned at the conference:

A little history:
The beginnings of the summit go back a year to Thessaloniki, where the idea of the Asia Summit was first mooted. Due to time constraints and clashes with openSUSE Summit in the US called for the event to be shifted to 2014. I had interacted with Sunny and Max in Thessaloniki and loved the idea of having an openSUSE event in Asia. At oSC14 in Dubrovnik, it was more or less confirmed that the summit would take place.

The Organization Team:
I joined the organization team a little late. The others had already done a lot of the hard work. I helped around a little with the invite letter and the promotion of the logo contest, and trying to find people to help around with the artwork. The opening session, where we welcomed the attendees in our native languages was cool. Also, Sunny’s speech in the beginning, which took us through the past one year was memorable, and I still remember each and every word of it.

I would take this opportunity to thank the openSUSE.Asia Summit
organization team. Today, now the openSUSE.Asia summit has started,
I’m reminded of the journey we took to get here.
I can not forget our weekly meetings, which often lasted to midnight.
I can’t forget 137 cards in trello for the preparation tracking.
And I can’t forget hundreds of emails about the Summit in our mail
boxes.

When we were on the way to reach this summit, we encouraged and
supported each other. Even though we were tired, we never gave up,
because we did believe we would finally be here. It is my honor being
a member of such a great team!

There are 17 people in the organization team, I won’t list everyone’s
name because we are a team, and we couldn’t have make any success
without each of us.

-Sunny

The organization committee did a fantastic job with the event and everything was planned to perfection. I would love to work with you all to host openSUSE Asia Summit next time as well (hopefully in India )

New things:
I absolutely loved the concept of ‘Chops’ where the workshop speakers would put a lovely ‘Geeko’ stamp on the brochure for the participants for the performance in the workshop. More than judging the performance, it gave us a good chance to interact with the attendees and have a lot of fun in the process. The gifts for the speakers and for the chops were great and well thought out. Personally, working with the organization team was very fruitful and I learned how an event of this scale is organized from the ground up. Additionally, being a room coordinator was a novel experience as well.

The Event:
To put the event in a single word: memorable. It was a very well conducted event and the speakers did a great job. The workshops and talks were conducted both the from the point of view of newbies as well as seasoned contributors. I particularly liked Richard’s opening session where the direction that openSUSE (with respect to Factory and Tumbleweed) is taking became clear. There were workshops on Bugzilla and OBS which were really helpful for getting new contributors involved.

Talk is Cheap. Show me the Code:
This was the single biggest lesson I learned during conducting my sessions. While taking the Qt Workshop, I was talking about basic object oriented concepts like Inheritance. The attendees (mostly students from the university) gave me a blank look. I was not sure whether they understood me or not. I ultimately decided to show them some code. They understood that. At that point I realized that there is one universal language that we could communicate with: CODE. That made the job a whole lot easier, and the rest of the sessions went well. I also made some ‘brilliant’ errors during the workshop, which demonstrated some or the other concept with respect to Qt. Overall, had a fun time conducting the workshop.

Food:
Being a vegetarian, I was not sure how I would survive in China. I absolutely indulged myself and tried out plenty of stuff. I have never eaten so much in a conference than I had in Beijing. Thanks to the awesome community guys, specially David who helped me a lot in finding out things to eat. The food was amazing. I can safely conclude that the Chinese take their food seriously. Plus, I learned how to use chopsticks properly. Thanks ftake for that

China and Sightseeing:
This was one trip where I did not do much sightseeing. I had talks for both the days and could not spare the time. To my dismay, I found that visiting the Great Wall requires a full day, and I had just about 6 hours to spare. In the end, I just visited the Forbidden City and the Bird’s Nest (Olympic Stadium). I should have made my travel plans a little better and stayed an extra day.
I found Beijing to be an excellent city. I managed to get around pretty comfortably on the subway despite the language issues. I found the subway system quite effective and very cheap (2 Yuan is dirt cheap). The only problem I faced was the air pollution, which was a little unexpected. Other than that, the people were amazing and really helpful.

TSP:

Thanks to the openSUSE Travel Support program, that I, and many others got to attend the event. It is really an amazing program, and I hope that contributors use it very effectively.

After about a year in the making for MimeKit and nearly 8 months for MailKit, they've finally reached 1.0 status.

I started really working on MimeKit about a year ago wanting to give the .NET community a top-notch MIME parser that could handle anything the real world could throw at it. I wanted it to run on any platform that can run .NET (including mobile) and do it with remarkable speed and grace. I wanted to make it such that re-serializing the message would be a byte-for-byte copy of the original so that no data would ever be lost. This was also very important for my last goal, which was to support S/MIME and PGP out of the box.

All of these goals for MimeKit have been reached (partly thanks to the BouncyCastle project for the crypto support).

At the start of December last year, I began working on MailKit to aid in the adoption of MimeKit. It became clear that without a way to inter-operate with the various types of mail servers, .NET developers would be unlikely to adopt it.

I started off implementing an SmtpClient with support for SASL authentication, STARTTLS, and PIPELINING support.

Soon after, I began working on a Pop3Client that was designed such that I could use MimeKit to parse messages on the fly, directly from the socket, without needing to read the message data line-by-line looking for a ".\r\n" sequence, concatenating the lines into a massive memory buffer before I could start to parse the message. This fact, combined with the fact that MimeKit's message parser is orders of magnitude faster than any other .NET parser I could find, makes MailKit the fastest POP3 library the world has ever seen.

After a month or so of avoiding the inevitable, I finally began working on an ImapClient which took me roughly two weeks to produce the initial prototype (compared to a single weekend for each of the other protocols). After many months of implementing dozens of the more widely used IMAP4 extensions (including the GMail extensions) and tweaking the APIs (along with bug fixing) thanks to feedback from some of the early adopters, I believe that it is finally complete enough to call 1.0.

In July, at the request of someone involved with a number of the IETF email-related specifications, I also implemented support for the new Internationalized Email standards, making MimeKit and MailKit the first - and only - .NET email libraries to support these standards.

If you want to do anything at all related to email in .NET, take a look at MimeKit and MailKit. I guarantee that you will not be disappointed.

I hope all who have been using the appliance are enjoying it and finding it useful. I felt it time to update the appliance to include patches to the latest known threats and critical updates to OpenStack.

Latest version 4.0.3

Changes from Github Project

• Refreshed the Update Repositories to contain latest patches
• Applied latest Updates to the Appliance

Following up on KDE’s announcement of the latest stable release, we have now packages available for 12.3 and 13.1 (a 13.2 repository will be made available after it is out). You will find them in the KDE:Current repository. Current users of this repository will get the new release automatically once they update.

Why you should upgrade? You can take a look at the list of changes to get an idea. These fixes touch many important KDE applications, including KMail, Okular and Dolphin.

Packages are also on their way to openSUSE Factory.

As usual, bugs with the packaging should be reported to openSUSE and upstream bugs should be reported to KDE.

Also, if you like what KDE is doing and you feel you can not contribute directly, you may want to support this end of year fundraiser.

Geckos are taking over China, at the openSUSE Asia Summit to be held this coming weekend in Beijing. It is the first time that an openSUSE event of this scale is being held so far east of the Geeko Meridian. The organizing committee has worked their socks off for the event, and things are shaping up well. The schedule is ready and their are some great talks lined up. Overall, it promises to be a great event. As for me, I am going to speak about the Google Summer of Code, openSUSE Activities in India and a workshop on the Qt Framework.So, see you in Beijing

http://summit.opensuse.org

For this task we need newest version of libgreattao and tao-manager application. You can download tao-manager from my home page. You can download newest version of libgreattao from svn of SourceForge,.

---

Our configuration window

Firstly, we take care about configuration window. In this example we looks on ready class of configuration dialog belonged to “modern” design.

This window contains buttons on the left side, labels and edits. In standard design are placed tabs instead of buttons. In modern design clicking on the button will switch view.

The code are below: