Ramblings

Note that this work-around is not needed for Opera 9 TP2

Well, some might disagree, but so far it is still by far the most reliable and less resource hungry browser I've used on this side of AmigaOS

Anyway, I'm a helper by nature, for the good and the bad. And sometimes I even end up spending more time helping others than doing my own work. Today I was lucky to help out a Rox user. Rox is a slick desktop environment and might looks like this:



Anyway, so what this user wanted to do, (his nick was menko btw. and he was clever enough to join the Opera IRC channel asking for help), was to let Rox take care of files downloaded by Opera. This is normally done in Opera by setting your preferred file-handler to /usr/bin/rox or similar.



When Opera sends files to file-handlers it normally is clever enough to send off files containing spaces ie. "My Picture.jpg" or "Artist - Song.mp3" as one argument. Either by adding quotes around them, like I just did or by escaping the spaces in the name with backslashes (\) ie "Doc\ 2.txt".

For the technical ones, this is normally pretty automagically done if you use the ANSI C function system(), for instance like this: system('/usr/bin/rox','Me at the beach.jpg');. I have no idea how Opera actually sends off parameters, but I haven't had problems with space in filenames until now reportedly with Rox.

Solution
So, at least as a solution for Rox, and maybe for other file-handlers -- who knows? -- is to use a wrapper script. A wrapper script is what the name suggests; something in between you and what's inside a gift. Or in this example between Opera and Rox. This wrapper script needs to escape or quote the parameters it gets and send it off as one over to Rox. Since perl is my native language and I know it's widely available this is what I did:

roxwrapper.pl:

#!/usr/bin/perl
exec('rox',"@ARGV");

It basically concatenates all arguments with space in between and sends it off as one argument to the rox command.

Remember to let this file be executable, for instance like this: chmod u+x roxwrapper.pl and put it somewhere you can access it from Opera.

Now you should simply use roxwrapper.pl as the file handler in Preferences > Downloads > Handler for saved files > Fallback for files and you should be able to handle filenames with spaces with Opera and Rox too

Or as menko put it: "my woes of browsing to the folder with a filename with a space in is over!"

As many of you know I'm an eager Amiga fan. I also play around with stuff that people don't use until a few years later, like for instance vector graphics.

I discovered Amanith a few months ago, and promised the authors to make it work on AmigaOS 4. I postponed this until some days ago as I had several other projects ongoing and some exams. I thought it would be a lengthy task, but it turned out to be an easy compile. Just had to add some sugar in between and now it cross compiles out of the box with qmake and all.

Amanith is a vector graphics framework utilizing the OpenGL API to achieve accelerated rendering of graphics. By the looks I have had on it it looks pretty good. I haven't been able to test it head to head with AntiGrain though, which already exists for AmigaOS 4.

Here's a screenshot of my results:

It seems the MSIE 7 team has problems tackling the implications of getting a new user agent string. Dave Massy from Microsoft has posted an entry in his weblog about the problems.

User agent sniffing is evil and should be avoided at all costs, and it seems even Microsoft has admitted that, of course only after encountering the problems themselves by preparing a new version of their browser after 7 years, but still, better late than never:

If you run a website please check you are not unnecessarily blocking access based on the browser and version being reported.

And from an entry in the official MSIE7 weblog:

I want to be clear that we do not advocate blocking access to content based on the User Agent string of the browser, as this practice results in users of unknown and newer versions of browsers being locked out. Rather than blocking unknown user-agents, consider using user-agent sniffing only in isolated cases to work around known limitations of specific user-agents.

One of the most important web sites that Microsoft runs is fixed in regards of browser sniffing. I pointed out in an earlier weblog entry that MSDN served different content to Opera browsers, for no specific reasons. What's worse is that it gave it worse and broken content. There was even added an entry in browser.js (A bundled-with-Opera and auto-updated script that runs on websites and fixes them if they are broken) to fix the problem.

Luckily, now it seems that they have taken their own advice and they are not serving different content anymore. Well done, and welcome to the process of fixing the web. Hopefully this is just the the first step in starting to do things the right way

Two weeks ago Microsoft developers made a fuss about their upcoming version of MSIE that is bumped up to version 7. In addition to get the word out about the update they advised people to start preparing for the new browser. A suggestion was to let web pages be aware of the User-Agent string now containing IE7 instead of IE6. I will refrain from commenting on the advice itself but rather be constructive and advise you how to really prepare for MS Internet Explorer 7. Much-ado about nothing Judging by the calculated "leaks" lately about what MSIE 7 will support and not support, there are relly no real changes that really matter. They will fix bugs, but only the most serious bugs, they will update the browser to follow some standards that break, but only the most important and so on:

In IE7, we will fix as many of the worst bugs that web developers hit as we can, and we will add the critical most-requested features from the standards as well. Though you won’t see (most of) these until Beta 2

- Ok, so lots of fuss about something that is still not out. Talk about smoke and mirrors.

In the web platform team that I lead, our top priority is (and will likely always be) security – not just mechanical “fix buffer overruns” type stuff, but innovative stuff like the anti-phishing work and low-rights IE.

- Yeah, innovation over there probably means "look what the others do"

We fully recognize that IE is behind the game today in CSS support. We’ve dug through the Acid 2 Test and analyzed IE’s problems with the test in some great detail, and we’ve made sure the bugs and features are on our list - however, there are some fairly large and difficult features to implement, and they will not all sort to the top of the stack in IE7.

- Ok, so a rewrite is necessary to make the browser useful? After 6 years since last the release of MSIE 6 you would expect a bit more. Prepare as a user If you want to prepare for MSIE 7, stop using Microsoft Explorer. Use Opera, Firefox, Mozilla, Safari, Konqueror, Galeon, Epiphany or any other browser that follows standards, is being updated and will continue following the open standards in the future. By switching from MSIE to any of those browsers you get an instant boost in your Internet experience, web pages will show up faster, you can do things more efficient, you will be surfing more secure and webmasters can finally concentrate on following the standards instead of adding hacks to make the pages work with MSIE. This means they can concentrate more on making web pages better interface-wise or content-wise in addition of being able to use modern standards to increase the overall quality of web pages. In other words, by ditching Microsoft Explorer right now, you do yourself and the rest of the world a favour. For web developers Prepare for MSIE 7 by dropping all MSIE specific features and embrace the open standards. As a web developer you will save huge amounts of time by only needing to follow the standards and testing pages with proper browsers. If you follow the standards you will get less people complaining about your pages not working, because since you have followed the standards you are doing it "the right way". The responsibility of rendering pages correctly as long as you've made your pages according to the standards is up to the browser manufacturer. Browser manufacturer should like the rest of the world compete about making a solid product rather than web developers degrading their pages just because at a given time one browser is more widely spread than others.

• By using the standards you let users get the most of your web pages by using proper browsers.
• The more web developers that use standards the higher is the chance Microsoft will bother making their browser work with them.
• By stopping making hacks specially for MSIE more pages will work on more browsers.

Standards: http://www.w3c.org Download Opera: http://opera.com/download

It seems the infamous Microsoft is seeking people to work on their excuse of a web browser called Microsoft Internet Explorer.

Did the the ones that has worked on previous versions get fired judging by the resulting product?

Anyway, it seems they aren't looking for Opera users at least. To have at least a tad of Win32 programming experience you would probably need to access their MSDN (Microsoft Developer Network) knowledge base. Which as you can see isn't accessible with Opera.

I guess MSDN is so advanced it uses features not available on modern browsers like Opera, or wait... It works just perfectly if I set Opera to identify as Internet Explorer. Weird...

UPDATE: It seems MSDN is now fixed and does not provide different (and broken) content to Opera browsers. Yay!