Problemstilling

Nogen gange kan det være svært at få resten af verden til at forstå, at Internet Explorer ikke er den eneste browser. TDC var en af de tungnemme, da de blev sat på opgaven. Mac brugere oplever ofte at få beskeden "Vi understøtter ikke Mac med digital signatur". Det er dog ikke helt sandheden, da de fleste offentlige institutter rent faktisk godtager det, hvis man installerer den korrekt. Som regel virker det, hvis den installeres i Firefox, men det er dog ikke altid. Installering i ens Keychain er desværre ikke nok til, at det fungerer i Safari.

Løsningen er dog enkel... Når signaturen placeres korrekt på maskinen kan de fleste signatur Java applets finde signaturen uden problemer, og man behøver derfor ikke at trykke "Gennemse..", hvilket i nogen tilfælde heller ikke er muligt (eksmepelvis på dele af personregistrering.dk).

Fremgangsmåde

Åbn din signatur i Safari (f.eks. Digital Signatur for Jens Jensen.html).

Tryk på Gem Digital Signatur knappen, Tryk OK til Advarslen om formatet. En dialog om placering kommer op.

Tryk herefter CMD+Shift+G. En dialog om sti kommer op.

Tast: ~/.oces og tryk enter.

Tryk enter for at bekræfte placeringen i denne særlige mappe.

Færdig. Fremover skulle det se nogenlunde sådan ud:

• Faster login process using Basecamps new features
• New, slim interface design
• Bug fixes

Go ahead, Download a copy, it's free!

Update: Version 1.1 released. Contains some minor fixes and additions.

So I wrote a small function to prune Django. There's a good chance I'll clean up the code for submission to the django-tagging codebase.

Download source

With respects to the people behind sf.net for the good work they've done over the years I feel there are still major issues that are so basic that I simply wouldn't consider sf.net as a place to host my projects.

But it's easy to throw stones at abstract problems - let me be specific. SourceForge devs, here's a few suggestions:

"Remember Me" broken

I'm a developer of jEdit where I take care of Mac-related issues. Being so, I follow the devel-list and at least once a week I visit the tracker to read up on issues. It seems that each time I visit I have to log in. Each time I check "Remember Me" but apparently so with no effect.

Login redirection

Related to the issue about "Remember Me" I am always redirected to "My Personal Page" upon login, not the link I came from or tried to access. This means having to click through several pages and refreshing before I can do whatever I need on the tracker.

Bad performance

I think it's a general complaint with sf.net but I am still bothered by the slow performance of the tracker. I haven't used the new tracker that much - it's certainly a better one but the general performance of the site could still be greatly improved.

If you must change the frontpage, here's a few suggestions to improve the relevance:

Global statistics

Remove them. It may be fun to watch for sf.net devs but really - what's the relevance for users? Users need something they can relate to but the numbers are unfamiliar and can't be compared to anything a regular user or dev know of. The graphical bars still doesn't give a context that seems interesting.

If you really insist on keeping this, make "Popular" the default display.

Recent releases

Consider adding user-engaging information such as "Most recent Project releases" - it would be a helpful and fun way to discover new projects and will give sf.net a feel of "being alive".

Keep "Project of the Month"

This is the primary part of the front page I find relevant.

Rename "Build"

"Build" is not a psychological trigger word for someone looking for a place to host their project. Usability is about user tendency and expectation. The word Build doesn't really say "get your open-source project hosted here for free"... it says get your project built. If the primary product was automated nightly builds, I would use the word "Build" or the like. But this really isn't the core of sf.net, is it?

SourceForge needs to catch up with the tendencies and features around the world. It seems that only recently they've waken up and discovered they are lacking behind. Depending on the preferred source version control system I would prefer Bitbucket.org or Google Code - overall simplicity wins me over regardless of the frontpage.

Download it

I owe some credit to Inkscape, which is an open-source vector drawing program. It actually has a bitmap vector tracing function.

Download it.

I've come across a few Javascript libraries that tries to make frontend work easier. Since I began using jQuery (Thanks to Oscar from GMTA) I've discovered a few ways to make life easier.

Usually you would style a text input element something like this in CSS:

input[type=text] { border: 2px dashed #f00; background: #ff0; }


But IE6 doesn't do attribute-selectors. So until the marketshare of IE6 is low enough (and customers stop insisting) we need alternatives. But how?

The immediate replacement

With jQuery you can actually do a query for all input types much like the CSS selector. Doing this together with a little CSS, and you've got a powerful replacement:

<script type="text/javascript">
$("input[@type=text]").addClass("text");
</script>
<style type="text/css">
input.text { border: 2px dashed #f00; background: #ff0; }
<style>


The result

And the result is as expected, fully automated:

Other input types?

So what about other input types? I usually just repeat the process, since it's a nice and clean way, so I have the following snipplet in my base.js, which is included on all pages like we do on Pagegangster.com:

$(document).ready(function() {
// * Enable ability to custom style all input elements based on their type
// * The equivalent CSS selectors doesn't work in IE 6 (and 7?)
$("input[@type=text]").add("input[@type=password]").addClass("text");
$("input[@type=checkbox]").addClass("checkbox");
$("input[@type=radio]").addClass("radio");
$("input[@type=submit]").addClass("submit");
$("input[@type=button]").addClass("button");
$("input[@type=image]").addClass("image");
$("input[@type=file]").addClass("file");
// .......
}


The non-jQuery and independent way

But to be honest the most optimal way of doing this would be to create a small script that uses document.getElementsByTagName('input') and matches on the 'type' attribute... So here it is a bit more generic but without the dependency on jQuery:

<script type="text/javascript">
var inputs = document.getElementsByTagName("input");
for(var i in inputs) {
inputs[i].className += " " + inputs[i].type;
}
</script>


It's actually a bit faster this way, so one would argue the latter method is better.

The solution is to add the following to ~/.Xdefaults:

*.multiClickTime: 500

and run:


xrdb -merge ~/.Xdefaults

to merge the newly created settings into the running X server. Settings will apply at next Java app. startup.

You can replace 500 with a number in milliseconds that you wish to set the doubleclick time(out) to.