After implementing a prototype for sorting functions in Requests, I needed to refine the UI and get the sorting buttons to work correctly with jQuery Mobile. The problem was when I clicked on a button to re-order the list of requests, the action would complete properly, but the selected button would not be highlighted.

This is the ideal view I would like to have:

I re-examined the code in the prototype, and realized these sorting buttons were laid out as control group buttons as follows:

<div data-role="controlgroup" data-type="horizontal">
 <a href="#" onclick="render_list('date'); $('#request_list').listview('refresh'); return false" data-role="button" data-theme="b">Date</a>
 <a href="#" onclick="render_list('requester'); $('#request_list').listview('refresh'); return false" data-role="button">Requester</a>
 <a href="#" onclick="render_list('target'); $('#request_list').listview('refresh'); return false" data-role="button">Target</a>
 <a href="#" onclick="render_list('state'); $('#request_list').listview('refresh'); return false" data-role="button">State</a>
</div>

After some web research, I learned that control group buttons might not provide what I wanted. More than one button in a control group can be active at a time. I also looked at the demos and examples on jQuery Mobile website. For control group buttons, there doesn’t seem to be any highlighting for the selected button. There is a millisecond of color change when the button is being clicked. But after the clicking is finished, the buttons return to their default data-theme. 

One thing I could think of to make this highlighting happen for control group buttons is to dynamically change the data-theme for each selected button, but it seems to be an overkill for this tiny issue.

On the other hand, radio buttons seem to perform exactly the way I wanted. With radio buttons, the highlighting comes automatically once the button is selected (the newly selected button is added to the selector class, as the previously selected one is removed from there).

A second option to fix the button highlighting would be to change the control group buttons to radio buttons. A group of radio buttons always have at least one option selected, and that selected button is always highlighted. This would work perfectly on the Request view page, as requests would always display sorted by date.

(Check out jQuery Mobile documentation on radio buttons)

Switching the UI from control group buttons to radio buttons was easy:

<div data-role="fieldcontain">
 <fieldset data-role="controlgroup" data-type="horizontal" >
 <input type="radio" name="radio-choice-1" id="radio-choice-1" value="date" checked="checked" />
 <label for="radio-choice-1">Date</label>

 <input type="radio" name="radio-choice-1" id="radio-choice-2" value="requester" />
 <label for="radio-choice-2">Requester</label>

 <input type="radio" name="radio-choice-1" id="radio-choice-3" value="target" />
 <label for="radio-choice-3">Target</label>

 <input type="radio" name="radio-choice-1" id="radio-choice-4" value="state" />
 <label for="radio-choice-4">State</label>
 </fieldset>
</div>

But binding an onclick event to the radio buttons took a bit effort. The trick was to use “change” instead of “click.”

 // initial render after page load
$(document).ready(function(){
 render_list("date");
 $("input[type='radio']").bind("change", function(){
 var selection=$(this).val();
 //alert("Criterion changed. Selected: "+selection);
 render_list(selection); 
 $('#request_list').listview('refresh');
 })
});

Now the buttons are correctly implemented. The final Requests views look like the following:

• – – – – – –

Hacked up some quick artwork for a countdown image for the openSUSE Conference 2011.

If you want to use it on your blog, website, whatever, use the following links to the image:

• Large (400x400 pixels): http://counter.opensuse.org/conf/2011/large
• Medium (256x256 pixels): http://counter.opensuse.org/conf/2011/medium
• Small (130x130 pixels): http://counter.opensuse.org/conf/2011/small

If you don't like the artwork, patches are welcome ;)

Obviously, the number of remaining days is updated every day and, hence, that countdown is always up-to-date (it is relative to the CEST timezone though, where the event takes place).

I would like to share some exciting progress on the OBS Mobile Project:

1. Request state has been added to each request;
2. Sorting functions have been implemented for Requests;
3. A search filter has been added to the Request page.

Now, when the user logs into the list of requests, the user will not only be able to see the state of each request, but also sort requests based on 4 criteria:

• request date
• requester’s name
• target project/package
• request state

The user can also filter requests by typing in a keyword:

These new features have been tested in my desktop browsers and on my Android device, and they seem to be working fine.

Please feel free to check out the new features as soon as they are merged to the master. Feedback and comments are always welcome & appreciated.

The last few weeks have seen some a lot of package updates thus keeping our review and checkin team busy. I’d like to mention Sascha Peilicke who reviewed alone this week lots of packages. Have a look at just two numbers: In all of July we had 1001 check-ins and just from August 1st to 4th we had already 276 checkins.

The legal team has also gone through the long list of new packages and package updates during the legal reviews and reduced this week the list from over 100 packages to 12 packages now. Thanks Ciaran and Christoper for your legal review!

Policy

Detailed changes

Coolo explained the current policy on how detailed the changes entry in packages should be:

I repeat what I said before so everyone is on the same page:

Version numbers are per se no information and we want to offer users an easy, standarized way to find out what changed. But it’s not the packager’s job to collect upstream NEWS. So if the upstream project does not offer a summary, then say so in the .changes file, so also the user knows. If the upstream  project does not provide a summary but a detailed web page, then a link is fine too.

Major Package checkins

Desktops

GNOME saw another step to the stable GNOME 3.2.0 with the GNOME 3.1.4 testing release getting pushed into Factory. KDE’s new release 4.7 is now also in Factory.

So far, the new kontact 2.0 version has not been submitted for Factory and you can get it from the KDE repositories. Btw. the openSUSE KDE developers have made the sqlite backend the default for akonadi since the upstream default of mysql caused too many problems. If you’re running already kmail2 and like to switch follow Ismail’s advice to change in ~/.config/akonadi/akonadiserverrc the line Driver=QMYSQL to Driver=QSQLITE.

New packages

New packages include quassel (an irc client) clementine (an amarok competitor) shorewall (new firewall). Also amarok was updated to 2.4.3 and thunderbird got updated together with enigmail.

Mounting /usr in the initrd

Michal Marek updated mkinitrd to mount /usr in the initrd. In the past, we had to move quite a lot libraries and binaries from /usr to the root
partition to allow having /usr as separate partition that can be mounted in all supported scenarios, like via nfs. This led to changes in many places and testing that everything worked as well. With mounting from the initrd, we do not need to move binaries and libraries anymore around.

Michal calls for testers on his blog and is also going to enhance the initrd to support all cases. Right now the simple cases work but support for booting from nfs is not supported yet.

Other interesting bits

openSUSE Conference

Please register now for the conference!

jQuery Mobile Beta 2 Released! http://jquerymobile.com/blog/2011/08/03/jquery-mobile-beta-2-released/

One of the "paper cuts" developers have been having with developing their MonoTouch 4.0.x (and earlier) applications is that for some networking setups, the IP of the developer's workstation detected by MonoDevelop and given to the iPhone or iPad device for debugging purposes is not correct. This often happens if the WiFi is a different network than the network that the developer's machine is connected to (although there are other scenarios as well).

Since it does not seem to be widely known about, allow me to point out that current versions of MonoTouch allow developers to modify the IP that the runtime should connect to for debugging via the iOS Settings app found on any iPhone or iPad (or Simulator). You can see a screenshot of this per-App Settings page in the screenshot to the left. Each of these fields are editable, allowing you to override the defaults filled-in by MonoDevelop.

For our upcoming 4.1 release, Rolf Kvinge and I (but mostly Rolf) have been working on improving this. Rolf has modified the code to check the value of the IP provided in the per-App Settings and if it is set to nil or "automatic", the debugger falls back to checking for a file bundled with the app called MonoTouchDebugConfiguration.txt which can list any number of IP's to try and connect to, each one being on a separate line prefixed with "IP: ". For example:

IP: 10.0.1.31
IP: 192.168.1.31
IP: 204.11.102.79

The runtime will then attempt to connect to each of these IPs asynchronously until it establishes a connection to one of them (at which point it aborts the other waiting connections). This config file solution will hopefully help simplify things for developers a bit by allowing them to pre-configure which IPs to try for their local network configuration w/o having to manually override the iPhone debug settings on the device or simulator.

For Phase 2 of our plan for World Domination, Rolf is hard at work adding support to MonoDevelop and the runtime to allow for USB debugging which will obsolete the above functionality in future versions where the developer has a MonoDevelop which supports USB debugging. For developers stuck on an older MonoDevelop (like 2.4), the solution illustrated above requires no changes to MonoDevelop and so will be available for use.

Hi,

I changed the openSUSE mkinitrd to mount the /usr filesystem in the initrd, if /usr is a separate partition. I hope this will calm down some heated discussions about systemd, udev, etc. It’s not 100% ready yet, some setups like root or /usr on nfs or md might not work as expected (*), but the common usecases should be covered. Try updating mkinitrd from the Base:System project and let me know if it works for you. Before testing it, you should do a backup of your initrd:

# cp /boot/initrd-`uname -r`{,.orig}

and create a section in /boot/grub/menu.lst pointing to the /boot/initrd-*.orig file.