After reading through ldir’s latest release I found a few bugs which have now been fixed in ldir 1.7.10.
I’ve also rewritten the icon file type check, so we assume some common file types are available and then add any new ones to the array on that call, so if that type is found again in that folder, the icon is already known. All in all resulting in a considerably faster speed for listing the same file types or common files.
There are more extensions supported than listed but I chose not to include them all but you can if you wish.
I will also be looking at overhauling the icons and providing them as a pack allowing you to self host which at the moment isn’t possible due to licesning issue.
Yes, I know… No updates for nearly 12 months and then two come along in the same week!
ldir version 1.7.9 is now 10% smaller than 1.7.8! As well as saving minimal disk space, it’s also had some speed increaces.
The only downside is that we had to remove error code 3 from the function in order to speed it up; there are more speed increases to be had if I could reliably detect the file type icons with a fail over if there isn’t a type without utilising cURL.
If you want to customise ldir to not do those checks and just ignore unknown file type icons then the following code alterations will make a significant speed increase.
Change: (approx line 160)
$img = "unknown.png";
$type = "Unknown File";
//Remove this check to speed things up.
$img = strtolower($ext).".png";
$type = strtoupper($ext)." File";
Added better support for styling – Removed inline width CSS & Added CSS styles for each column
Removed some linebreaks.
Removed/Condensed some code (upto 7% smaller)
Custom UserAgent in CURL Opts.
So in simple terms, I’ve made it tell dropbox (the icon host) that it’s a web app, removed clutter around the code, condensed a few lines and added selectors rather than inline css so styling it (and making it responsive) should be much easier.
If you’re writing a new responsive website which seems to be the way to go for a single maintained site that is accessable via mobiles, tablets and phones then here’s some key screen resolutions to be targeting:
Extra Info & Estimated Date
Typically non-smart phones (and Smartphones c.2005)
Typically older smartphones (c.2008)
Typically older smartphones (c.2008)
Low-End Smartphones (c.2010 onwards)
Low-End Computers (c.2000) and mid-range tablets
Mid Range Computers (c.2005)
Current Computer Screen (c.2010 onwards)
HD TVs, High-End Smart-Phones/Tablets
Laptops, Computers and High-End Smartphones/Tablets
Typically Laptops and Computers
ipad & 2
iPhone 1, 2, 3 & 3G
iPhone 4, 4S
This is just a small list of resolutions that’s in use out int he wild so to speak. The varying resolutions does make it slightly harder to get a consistant experience throughout but as long as your site looks good in the first list then you will have hit the majority of devices (as long as you remember to test portrait and landscape!).
As you can also see, Apple has recently decided to use strange resolutions in their devices where as most newer smart phones are 800×1280.
If you’re creating a responsive layout then there’s lots of resources out there to create a fluid grid to reflow the content when the screen size changes. I personally recommend Zurb’s Foundation but the latest version doesn’t support IE7; although IE7 usage is shrinking.
I was recently writing a batch script to auto-install service packs onto windows, detecting the OS version was relatively simple and there’s plenty of scripts on the internets to do this; on the otherhand, detecting between 32 and 64bit architectures is much more complicated.
Microsoft has a KB artictle with batch script code to do this which is great apart from it doesn’t work under a standard user account and might not even work on an admin account (it didn’t work on my domain admin account), so if MS can’t supply code that works is there even a detection method?
Some people suggest that you should be searching for the %programfiles(x86)% variable which is only on 64bit systems, this is great apart from it didn’t work either.
I then stumbled by chance on a great solution which is to check the %PROCESSOR_ARCHITECTURE% variable. This worked great! I have been told that if the machine has WMI disabled then this wouldn’t work but most systems have WMI enabled.
If "%PROCESSOR_ARCHITECTURE%"=="AMD64" (
"X:\Windows 7 x64 SP1.exe" /passive /norestart
) ELSE (
"X:\Windows 7 x86 SP1.exe" /passive /norestart
That’s the code that I’m now using to detect the architecture of the systema nd install the correct SP, although it will attempt to install the 32bit Service pack onto 64Itinium machines; an extra check can be included to test for that but I’m unlikely to stumble upon an Itinium based system in my 20 PC office…