Archive for August, 2008

Linux accelerated video with nvidia dual view

Wednesday, August 27th, 2008

As one might now, with multimonitor setups Windows must have a primary and a secondary display: only one of those can have accelerated video overlay, or to put it simple: the user can’t choose on which monitor the fullscreen movie will play simply by dragging the player onto the desired display and pressing fullscreen there; if he or she presses the fullscreen on the secondary monitor, the video still will be played on the other on and video mirroring is being phased out from the drivers (I’d rather not comment on that).

Just my two cents: it works in Linux like a charm. Setting up is easier: the nvidia control panel applet and tray icon on Windows tend to do funny things for me, yet things “just work” on Linux (one of those very rare cases). So, what are the things I don’t like?

  1. KDE3, apart from annoying bugs, is customization galore and a really mature desktop (display/desktop setup is ver easy): now going away, thanks to opensource stubbornness
  2. While on windows, though buggy, I can get away with the nvidia tray applet and change profiles on the fly, on Linux I have to restart the XServer (as usual). I know that services still go on, but for the casual user restarting X means closing all the applications (it’s fine with me by the way, what’s not fine is X dying losing those apps)

Now here’s a screenshot from the setup: on the left Big Buck Bunny (in smplayer), on the right Wings3d and GlxGears.

Javascript frameworks in mixed environments

Tuesday, August 26th, 2008

Now that I have finished removing Prototype from our main product page and closed all variables and objects into a dedicated namespace, I’m getting more and more suspicious with Proto:

Prototype is a very good and convenient framework and the protoypic nature of javascript is very cool; on the other hand most people do not realize how javascript frameworks can collide or cause namespace pollution. So, just my two cents on the topic: whenever there’s a slight chance that a project will need to have mixed client side frameworks, stay away from Prototype (and last time I checked MooTools‘ code, it also did some protoypic enhancements to builtin javascript objects). If a page can or may incorporate 3rd party scripts, where this third party is not competent enough (like a widget from Noname(tm) company), where whitelabel partnership is an option or where mutliple frontend developer teams are working on the same project, be very suspicious.

Unobtrusive and namespace-aware frameworks I know about are Yahoo’s YUI, Dojo, jQuery (with noconflict) and possibly some others am not really aware of. Choosing Prototype for a general and mixed server-client side framework (I know about RoR, today I checked out Prado, which also uses Prototype) is “not very convenient” and greatly reduces flexibility in certain aspects.

Installing a 32 bit Firefox with Flash and Java on Debian Lenny

Saturday, August 23rd, 2008

As usual, Debian is annoying at times, but it is pretty stable and fast; Lenny is currently Beta 2 and I wanted to give it a try; since my Windows is 32 bit and I wanted to test the 64 bit Lenny, I had to install it onto my machine (not just inside a vm). I did a barebone install (no xserver) as usual and added bits step by step, this way I have more control over packages, but that’s not what we’re here for.

Since Debian still has no usable multiarch support and I want both Flash and Java in my browser (I know, shame on me) I installed a chrooted Debian for this case. Last time I did this I installed an Ubuntu (Gutsy Gibbon), but this time I wanted to keep it minimal, hence the debootstrap: as of today ndispluginwrapper is not stable enough, the 64 bit java plugin is nonexistent, openjdk/icedtea is not the best and the gnash/swfdec combo is still immature.

  1. To install a minimal Lenny into a chrooted environment, follow this tutorial. Use schroot, in this case it’s much better than dchroot or plain old chroot.
  2. Set the schroot type to directory (in /etc/schroot/schroot.conf) and /dev to mount-defaults (just bellow /tmp, pretty much the same)
  3. Now you can decide, whether you want you browser just for you, or system-wide; since my machine is essentially a workstation, I prefer ~/bin: extract an i686 Firefox there.
  4. Inside the chroot: apt-get install libgtk2.0-0 libxt6 libxtst6 gtk2-engines libasound2
  5. Now download the flash plugin (yes, it’s easier than the “Debian way”) and copy the .so file into plugins dir (there you go, you have flash)
  6. Download Sun Java (yes, it’s easier than the “Debian way”), install (erm, run the bin file) to wherever you want and then symlink the normal plugin into the Firefox plugins directory. You can read the instructions on Sun’s site, but basically that’s it.

Now we have Java AND flash; cool.

And what about Lenny? So far I really like that I can have the old KDE (I’m waiting for 4.2 or 4.3, I still don’t want 4.1) and that things are snappy and fast (only one segfault so far, LOL).

Just a sidenote: (as usual) I’ve found that installing the nvidia binary driver and then holding back the kernel is much easier than the hassle with module assistant; unfortunately ntfs-3g automounting was a major pain in the back (even with pmount), so I’m falling back on the readonly driver for now, but apart from these, things are fine.

Just another slider component

Friday, August 22nd, 2008

Had been working on this component for some time: now that we’re speeding up our pages and removing everything prototype (mostly because we do know why clean namespaces are good), a new slider for the in house framework is needed. Right now it is pretty flexible, clean, uses event subscriptions / fireevents, can be used for double or single sliders etc.

Edit: I have removed the slider demo from this page, since this code is proprietary code, reverse engineering and reusal is prohibited according to company policy; the “free” version I made after revising and fully rewriting this one is available at my site.

Arguments.slice()

Friday, August 15th, 2008

As one might know, arguments in javascript are not exactly arrays; they most of the time acts like arrays, but most array methods are missing, which is bad – but apart from whining, what can we do if we need slice() for example?

Let’s assume we want to do this:

arguments.slice(2);

As others noted, the easiest way is to convert the arguments object into a real array object first, then call slice:

$A(arguments).slice(2)

$A is the shorthand for toArray conversions in Prototype; iterating through the given parameter is pretty time consuming, all we should see is a function call:

var $A = function(obj) { return Array.prototype.slice.call(obj); };

Squeezing the arguments through a real slice will result in an array, that’s why we call the slice with the given parameter (begin and end params are not used here).

The in house framework we’re working with, is a “clean” framework, where we never ever touch builtin objects’ prototypes (so if we have to include parts from our page on a partner’s site, it will not cause any problems for him or her); the creator of the framework choose a different way for truncating arguments, which is equally nice:

slice(arguments, 2);

In order to make this work, we need:

var Array_slice = Array.prototype.slice;
function slice(object){ return Array_slice.apply(object, Array_slice.call(arguments, 1)); }

Now, let’s take a clooser look:
Array_slice.apply(object, Array_slice.call(arguments, 1));
has two parameters:
object: the “first” parameter, the argument-list itself
sliced call: the “second” parameter, the actual number itself.

Just a sidenote: why do we use call in the inside and apply on the outside? Because apply requires two parameters: the object to operate on and an array of parameters; call itself simply requires a list.

While this implementation may seem to be more complicated at first, it’s interesting to see a different approach from the usual $A way.