Wednesday, September 14, 2011

Lynx: Associating filetypes with a program in Windows

After a few hours of trying and failing in lynx.cfg and searching the Internet, I found a reasonably good collection of ideas (kudos to Kenneth Kwok), which served me with inspiration for a working solution.

• The version of Lynx is 2.8.7rel1, unfortunately it doesn't support SSL (gonna work on getting Lynx with that some day...).
N., 15.09.2011. update: A fully functional and SSL-enabled, albeit an older, 2.8.5rel1, version of the browser is available at Claudio Santambrogio's (csant) website (beware that export and other restrictions may still apply to the downloader's country).

As I needed an SSL-based browser, then out of curiosity I started comparing both Lynx browsers' config files and to my great delight found that csant's external app configuration was more elegant than my previous discovery. Jump to a description of how to implement the better solution.

And yes, the options inspired by Kenneth Kwok are still valid, but there are now less scenarios to use them.
• The operating system is Windows xp SP3, other Windows operating systems may also apply, but exact instructions on how to change environment variables were gleaned from this version of Windows.

Unlike in the linked article, it turned out that I didn't need to use a .mailcap file to associate a helper app.

The interesting part is that Windows Lynx (still) requires batch files to send requests for an external application and a path to them must be set as a global or user environment variable.
  • Create a folder that will hold batch files. I created one in
    C:\Program Files\Lynx\Batches
  • Create an environment variable pointing to that path:

    In My Computer/System Properties > go to Advanced tab > click "Environment Variables" button > in the relevant window's "System variables" section > scroll down to Path, select it, click the Edit button;

    In the path editing window, the Path string is long, but you can add a semicolon to the end of the string (if it's missing), then right after the semicolon add

    C:\Program Files\Lynx\Batches

    and that's it. (No additional semicolon required.)

    Click OK to close the window, click OK in Environment Variables window — This will save and update the path in Windows xp (maybe 2000, too) or newer; click OK for System Properties window.

    You won't need to restart unless it's a Windows 9x OS, for which you'd need to edit autoexec.bat, enter a short-form path à la C:\PROGRA~1\Lynx\Batches and restart the system for changes to take effect.
  • Now, in the C:\Program Files\Lynx\Batches folder itself, assuming you only want an image viewer program to be associated, create paint.bat, edit it as follows:
    @ECHO OFF
    C:\WINDOWS\SYSTEM32\Mspaint.exe %1
    ^ In addition, you may wish to add %2 %3 %n — if you know that there may be more arguments passed from Lynx, but there's usually one.
    Save the batch file.
  • In lynx.cfg (opened either via WordPad or Notepad2 or something that supports both CR & LF newlines), go to a certain place in the file by searching for the image/png pattern. There, you will see which MIME types you must activate for each filetype suffix.

    I uncommented (deleted a hash # from the start of the line) all that were web images, such as those concerning .png, .gif, .jpg and .jpeg.
  • Then in lynx.cfg, go to part of the file using the VIEWER: search pattern. There, you will see a list of program commands associated with a particular MIME-type (they are short by default, because they're typically UNIX-specific).
    N., 15.09.2011.:
    Uncomment, or rather, copy, paste, and uncomment those for image formats, and modify the commands to look like this:
    VIEWER:image/gif:start mspaint %s
    VIEWER:image/png:start mspaint %s
    VIEWER:image/jpeg:start mspaint %s
    VIEWER:image/tiff:start gimp-2.6.exe %s #special case
    • The superb catch ^ is where one must use the start command to invoke a program that's located in the Windows Path environment variable.
    mspaint is the command-line name of the Windows Paint program, which is located in C:\WINDOWS\SYSTEM32 and that address is typically set as one of the locations in the Path environment variable.
    gimp-2.6.exe is a different case, where I separately had to include C:\Program Files\GIMP-2.0\bin in the Path environment variable to make it launch, as for some reason it was impossible to use the full program path in the Lynx config file.
    Uncomment, or rather, copy, paste, and uncomment those for image formats, and modify the commands to look like this:
    VIEWER:image/gif:paint.bat %s&:NON_XWINDOWS
    VIEWER:image/png:paint.bat %s&:NON_XWINDOWS
    VIEWER:image/tiff:gimp.bat %s&:NON_XWINDOWS
    VIEWER:image/jpeg:paint.bat %s&:NON_XWINDOWS
    • Up here ^, add paint.bat right after a colon that follows the mimetype;
    %s is the wildcard for the filename to be entered;
    • The ampersand & is there to leave the program in the background. It can be there in Windows, but it's useful in Unix-like systems.
    :NON_XWINDOWS [sic] basically specifies that the targetted application is not an X Window System program and this option can be there, too. In Windows it may mean that the batch program is not exactly a graphical program either.
  • Save the configuration file and I think you should be done.
    Launch Lynx, go to a page with an image file, then on it, press Enter/Return or the left key to activate.
Similar steps can be made for other filetypes and MIME-types (which can be added, btw, since the list in lynx.cfg is non-exhaustive) and you can add programs different than Paint for other filetypes. Above, I have setup a batch file to run The GIMP for the TIFF filetype.

Saturday, September 10, 2011

Absolute positioning of content in a containing block

A less formal alternative title would be "Placing content from the middle of a box into a sidebar to the edge of a containing block"

Context

The problem first occurred when I tried to create a user style for a login page to accomodate small screens (Yes, there are people who use small screens).

The main problem was that I could not change the structure of the not-so-well designed page, so I had to resort to some unorthodox uses of formatting in CSS. Later it turned out ot have some interesting uses in a sister blog.

The basic [formatting] concept behind this is taking content out of normal flow, placing it as a sidebar into the top right edge of the container block, and then making sure that other content (mostly visible text) will then flow around the sidebar box.

While it may sound simple just like that, then implementing a working solution for the first time proved more difficult. The solution that I found out does work, but still contains some caveats. More about it later and below.

In-depth

What does not work

First off, just floating the box to the right is pointless, because the box is positioned according to normal flow and is floated where it's structurally positioned in the page (or text). It is then adjacent to that content which only follows the box in the page structure.

Adding a negative top margin is just as impractical, because it will never be accurate relative to the sidebar's position, as the position of the sidebar still depends on how much space is taken up by preceding objects or text, since relative renderings are always different, depending on fonts, rendering engines and zoom levels.

If you're modifying your own content, then putting the box before the content that initially preceded it defeats the purpose of normal text flow (as seen in Lynx).

The solution

Mostly assuming that the containing block and inner blocks are <DIV> elements, which I so dislike, because they are severely overused.

The points are here in a hierarchically continuous order, so as to present the logic and reasons behind it.
  • The containing block,
    which is to enclose the sidebar and content that should surround it:
    Set its position to relative — This will keep absolutely positioned blocks inside the containing block; otherwise all absolutely positioned blocks will be taken out of all flow and will be (absolutely) positioned relative either to any preceding relatively positioned block in the page hierarchy, or the viewport, which is the topmost block.
  • The sidebar's position must be set to absolute, with most important parametres set like this:

    <DIV STYLE="position:absolute; top:0px; right:0px; width:234px">Textual content<DIV>
    ^ top:0px and right:0px will place the sidebar box to the top right (to right of main content), where position is calculated from the containing block's top and right edges; width:234px — Here you can specify your own width for the absolutely positioned box.
  • And finally, the tricky part — How to make sure that content or text surrounding the sidebar will show next to the sidebar without all of parts of it staying hidden under the sidebar?

    Well, my solution was to place the that content (which precedes the sidebar and is innards) into a relatively positioned DIV& box, with its right margin approximately the amount of the sidebar's width. This ensures that text or content inside that DIV won't stay under the sidebar.

    If the sidebar is long enough to encompass much of the content that follows, then that content should also be encased in a DIV with similar parametres: relative positioning and same margins.

    Caveats:
    • If much of the content left of the sidebar is text, then its flow is limited to the squares of DIV boxes (there must be at least two of them). Normally flowing text could then start well after the sidebar and DIV boxes end.

      Mitigating effects
      One way to mitigate this without creating separate DIVs and their left (or right) margins is to create a ghost DIV with same size properties as the sidebar floated right just under the absolutely positioned sidebar. This has better chances of taking effect if the sidebar's height and width are fixed and that the content is controlled server-side.

      Yes, the "ghost" DIV can contain about the same text, if there's a desire for that ghost DIV to follow the size of the primary DIV (think differences in fonts and zoom levels), but this then may defeat the purpose of having that text in the ghost sidebar, because it would be duplicating. Oh well, solutions can be made both with JavaScript and CSS to make sure this text doesn't appear twice in a text-only or very plain browser (think Lynx).

      Otherwise I was thinking of :before and :after pseudoelements, or of a way to insert a client-side Greasemonkey script.

      This is now the point where one can play around with various options.
    • I found another problem when editing text here in Blogger, where the sidebar height was greater than text next to it, so the sidebar, given that it was absolutely positioned, overlapped past the post tools area. In that sense it's a good thing to try out the size of the sidebar in the DOM Inspector, which allows client-side visual editing of webpage elements under inspection.

      One way to mitigate this would be wrapping all of the affected content, including some preceding the sidebar (where it visually starts) in a DIV and specifying a height greater than the height of the sidebar. The height of the DIV should then allow for some hypothetical differences in size.

This out-of-order sidebar solution works in Firefox 1.0 (Mozilla 1.7.xx, preferably SeaMonkey 1.1.19 or K-Meleon 1.5.4) and newer. It does not work in Internet Explorer 7 (or older), so a workaround must be in place, if there's a large IE-based audience in mind. It should probably work in Internet Explorer 8 or newer.

Saturday, September 3, 2011

Microsoft Security Essentials teeb arvuti aeglaseks?

Kommentaar PM/Tarbija24 artiklile ja selle kommentaaridele

Microsoft Security Essentials[:w:en] programmiga on see jama, et see uuendab väga mahukat moodi ja uuendamise ajal võtab liialt palju arvutiressurssi.

Teine jama on see, et kui arvuti töötab, kuid kui seda ei kasutata, siis hakkab MSE skannima — kujuta ette näiteks ETV-d veebist vaadates ja arvutit otseselt samal ajal mitte kasutades, kui pilt ka väärikal arvutil hakkima ja arvuti aeglaseks läheb.

Lahendus (ingliskeelses Windows XP-s) on järgmine:
Start > Programs > Accessories > System Tools > Scheduled Tasks — seal lülitasin mina välja MPIdleTask eseme.

Soovitan seda teha kogenud kasutajatel näiteks juhtudel, kui nad on sunnitud MSE-ga olema, kuid programmi sellist käitumist ei salli.

K., 15.02.2012. täiendus:
Microsoft Security Essentials programmi uuendamine toimub automaatselt ja sedasi poolenisti eraldi Windows Update teenusest. (Tingimus on, et Windows Update automaatsed uuendused on sisse lülitatud.)

Uuenduste kontrollimine ja automaatne uuendamine toimub iga kord kui Windowsisse sisse logida, sh. peale arvuti sisse lülitamist, peale arvuti "talveunest" sisse lülitamist, peale arvuti unerežiimist sisse lülitamist.

Absoluutselt iga kord. Uuenduste kontroll ja uuendamine võtab endale kogu arvuti tähelepanu ja midagi produktiivset sellel ajal teha ei saa.

Võimalik, et toode oligi mõeldud kodukasutajatele lisaks ka väikeettevõtetes kuni kümnele arvutile (aga ainult seda tüüpi organisatsioonides), seega näiteks väikeettevõtte tööarvutites ei peaks selline uuendamistuhin väga problemaatiline olema, sest väikeettevõtted on tavaliselt väga kitsaste eelarvevõimalustega ja sellises olukorras jääb MSE ainsaks legaalseks tasuta valikuks residentse skanneriga antiviiruste seas.

Tavalisele kodukasutajale, kes arvutit äriks ei kasuta, on olemas ka teistsuguseid variante, nii et MSE-d väga soovitada ei oska.

Saturday, July 30, 2011

ClamWin Antivirus Glue for Firefox

If anyone is still using Firefox 1.5–2.0 and ClamWin, too, then they'd be interested in the subject extension. Unfortunately, this addon has been delisted from addons.mozilla.org and very hard to find from FTP sites (which I tend to trust more).

So I found what turns out to be only one source:
http://pub.vse.cz/pub/Mozilla/addons/771
http://cache.vse.cz/pub/Mozilla/addons/771
The license for the extension is MPL 1.1/GPL 2.0/LGPL 2.1.

Caveat

Version 0.2.4 officially works in Firefox 1.5, but here are instructions in a 18.01.2007 comment to a blog post on similar matters. (The original text was here.)
Instructions in my own words: Download the XPI file (the lowermost is the newest version; if you are not sure, then check the statusbar when mousing over the 0.2.4 file link), extract it into a folder, open install.rdf with an editor that supports CR & LF linebraks (NotePad2 is ok); there, edit the em:maxVersion parameter value from 1.4-something to 2.0.0, compress the decompressed files, then rename the file's .zip (I assume) extension to .xpi, then move the file into an open Firefox window to install. When recompressing, make sure that you're only compressing the selected files and folders within the extracted folder and not the folder itself.

Modern stuff

For people using newer browsers, see the Fireclam extension for both Mozilla Firefox 3 and newer, and SeaMonkey 2 and newer.

Saturday, July 16, 2011

DOM Inspector XPI for older Firefox/IceWeasel browsers

Knoppix is the kind of distro that by default does not include the DOM Inspector, it's only on a CD, and I think I had even spent a month searching for a way to install it from a .deb file to a version of firefox in Knoppix. All in vain, even if I had the supposedly right package, because it would still prove incompatible and thus unusable (would crasshh).

Then, by chance, I found the right way to install the DOM Inspector XPI separately for Linux in those distros, where a package might be missing (such as a relevant .deb package in Knoppix 4.0.2, because it's a snapshot from Debian's testing branch of the time) or not included at all... — By downloading a specific DOM Inspector XPI from the old mozilla.org FTP site, which is archived at mozilla.org's own ftp site:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.0.6/linux-i686/xpi

Caveat in Knoppix and other Live CD-s: You can only install it as superuser, it won't install into the user directory and thus it won't save, but rest assured, you can install it again every time you need it, although it may be tedious for daily use, if that might be the case for some users.

Here's what you have to follow, if you're stuck using a LiveCD, a version of Firefox without DOM Inspector built-in, no package repository to rely on and no package to be found for your particular distro (Knoppix):
  1. Find out what your version of Firefox is in your Live CD (launch Firefox; Help>About). For some Knoppix Live CD's I sometimes use, mine is 1.0.6 for Knoppix 4.0.2 and something else in newer versions of Knoppix. Keep in mind that newer versions of Knoppix include Debian IceWeasel (Knoppix is based on Debian), which is a source-compatible rebranded copy of Firefox.
  2. Exit Firefox, relaunch it as superuser, best with sudo firefox
  3. Go to
    ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/
  4. From there, choose the version of Firefox/IceWeasel/GNU IceCat you are stuck using (if using a browser click the relevant version folder link);
  5. Once there, browse to a folder called linux or linux-i686 and there browse to the xpi folder. Note down the address in a separate editor.
  6. (Make sure that ftp.mozilla.org is the allowed domain to install XPI's)
  7. Click on adt.xpi (the XPI for DOM Inspector), which should be at the very top of the directory listing, go through the extension installation procedure. If after installation you don't see the extension listed, don't worry. Restart Firefox again as superuser, via sudo (you should now know how to use it). Verify that DOM Inspector is installed by checking the Tools menu. Exit the sudo'd Firefox.
  8. Start user-mode Firefox and you should see the DOM Inspector appear there.
  9. To maintain that you still have the XPI for future use, save it to local storage (a memory stick, for example) by downloading it in a normal-user firefox session from the same FTP address.
Now, I haven't been able to find out an XPI of the DOM inspector for older versions of Firefox that would actually work as an extension installed into the user profile, so until then, it's more of a case for frequent users of DOM Inspector in older Firefox browsers on a Live-CD of reinstalling the XPI after every restart.

Settings for DOM Inspector can be changed through about:config, then search using the inspector string.

Monday, May 23, 2011

Putting stuff before a counter with CSS and associated caveats

I thought this too important to be passed up, so here's only a very rough draft of what I discovered. And because I was only revisiting this subject right about now, I have yet to get my own head around all this, with more detailed explanations.
(Blogger had nasty issues with updating their software, so a number of blogs were in read-only mode and so instead of writing this up I was occupied with other things. The good thing is that Blogger have been very responsive in addressing the posting outage.)


When tallying personal data and opinions for what was ostensibly a list of items in a text file, I wanted to find out how in an ordered HTML list (a numbered list with <OL> tags) I'd be able to use Cascading Style Sheets (CSS) to place some special items before counters (usually numbers, but CSS 2 standard has expanded counters to be much more) as markers of some sort.

The main point was to make a more informative and interesting list... Well, yes, but this turned out to be a far more difficult exercise than I first thought.

For an intro, the following describes the differences in rendering between Mozilla Firefox 2 and Mozilla Firefox 3+. Because these browsers use the Gecko rendering engine, which is used by other browsers, then here's also a quick browser side-by-side of the rendering engine's branches:
Gecko 1.7Gecko 1.8.1Gecko 1.9 and newer
Mozilla Firefox 1.0Mozilla Firefox/IceWeasel 2Mozilla Firefox/IceWeasel 3+

Mozilla Application Suite 1.7
SeaMonkey 1.1SeaMonkey 2+
K-Meleon 1.5K-Meleon 1.6+

What follows is example CSS code with some comments. I haven't yet had all the time to describe everything, but bear in mind the lede.
OL.Eurovisioon {counter-reset:item; list-style-position:outside}

OL.Eurovisioon LI {display:block;}


/*display:block ^ loses the browser's automatic numbering;
• The items must be displayed as block, so as to make sure that the later width attribute applies. */

OL.Eurovisioon LI:before {float:left; content:'miskitekst\ ' counter(item) '.'; counter-increment:item; border:solid 1px gray; padding-right:5px; width:82px; text-align:right; line-height:1.1em; color:navy; white-space:nowrap} /* these work... */

/* ^ • Floating them left makes sure that the items are displayed like in a standard ordered list;
item must be inside counter(), item is also specified for counter-increment;
text-align:right aligns numbered counters right and so makes it more list-like again;
white-space:nowrap makes sure that when increasing text size, text inside blocks wouldn't wrap and add in height and take away from the structure.

Caveats:
Once the items are all displayed as text-block or inline, the width attribute does not apply anymore. Displaying as block and floating to right works in Firefox 4 (I'm also assuming 3.0+), but not in SeaMonkey 1.1 and anything with the Gecko 1.8.1 engine (see the above table) and the caveat applies to all older browsers.). Setting the display to text-block or inline fixes the issues in SeaMonkey 1.1, only that setting width attributes does not work then. */

OL.Eurovisioon > LI.plus:before {width:82px; content:'\ sisu\ ' counter(item) '.\ '; text-align:right; color:blue} /* somehow works */

OL.Eurovisioon > LI.plus {list-style-position:outside}
^ Is this really necessary?
Moreover, the list already contains tabular data; including informative content with :before or :after pseudo-classes means that this data won't be indexed and may be lost to search engines. Non-graphical and older browsers won't be able to see such content.

I, of course, thought that I'd never see the day when my own fancy CSS implementation would not be visible with something like SeaMonkey 1.1.19.

The correct rendering is supported by Mozilla Firefox and IceWeasel 3 (probably since 3.0), SeaMonkey 2, Google Chrome (Version 11 does, so I'm assuming a host of earlier versions do, too), and the latest Konqueror, Apple, and Opera fare. Internet Explorer 7 does not support this. Bleh.

So here's the example list:
  1. tekst
  2. teine tekst
  3. kolmas tekst
  4. neljas tekst
with corresponding code in HTML:
<OL CLASS=Eurovisioon>
<LI>tekst</LI>
<LI CLASS=plus>teine tekst</LI>
<LI>kolmas tekst</LI>
<LI>neljas tekst</LI>
</OL>
So long I still have to use Mozilla Firefox 1.0, I must still use a simple HTML table. At least the advantage is that most browsers will be able to see the content. The table in question is here.

As the information was laid out in a text file, it nevertheless turned out to be tabular data, which was actually much simpler to organise into a table, rather than implement complex CSS for the same.

Tuesday, May 10, 2011

Collapsing elements in Firefox 1.0

As I was perusing Yahoo Mail Classic in Mozilla Firefox 1.0, it turned out that there was a linked block element half-blocking the sign-out link at the top of the page and in May this year, those links stopped being underlined when hovered over — this made targeting the pointer too difficult to click on the sign-out link. If I click on that block element, it will jump to a position on the page, then, somehow the block element probably moves and probably frees up the space above the sign-out link... Or whatever.

Turned out that the culprit was an invisible non-collapsed block that contained a "Skip to conent" link, which was meant for browsers like Lynx, Links, Elinks, Netscape 4.x, and other older fare (Lynx is still maintained :). This is really the fault of site coders, who instead of specifying display:none in the element's style, only specified visibility:none. The former would have collapsed the whole element, the latter only makes it invisible, but still usable and visually existent in the document structure.

If positioning is important, then one design solution is to specify a low z-index for the invisible DIV element and a correspondingly higher z-index for code that contains links (an unordered list). In CSS, z-index specifies how elements are layered with respect to each other: a higher value means that an element is above (or in front of) all other elements and a lower value (if somewhere is a higher value specified) means that the element is below, or behind higher-valued elements.

First I tried the Adblock Plus (ABP) extension, but that didn't work: ABP 0.7.0.2 is the last version for Firefox 1.0, but lacks functionality to collapse/hide elements by their id. Only the next version, 0.7.1, starts supporting this. I've written about it previously.

As I was looking for a solution, the Greasemonkey extension caught my fancy. The last to support Firefox 1.0 is 0.5.3.
Version 0.5.3 is also the last one of Greasemonkey to install on SeaMonkey 1.1, but it doesn't work.

The solution is to first install xSidebar (If the current stable versions won't want to install, then version 1.0.1 or 1.0.2 might install properly). Then on the back of xSidebar a modified Greasemonkey extension can be installed. So for SeaMonkey 1.1, Greasemonkey 0.8.2 mod is the order of the day. Note that if you have Adblock Plus 1.0.2 installed, its toolbar button will vanish. But no worries: You can turn on the Adblock Plus status bar icon from Tools > Adblock Plus Preferences...
Greasemonkey is a powerful tool to change the look and functionality of online sites and web pages client-side, but alas, it is not very easy and requires knowledge of HTML, JavaScript and CSS.

There are many instructions online on how to incorporate custom JavaScript and CSS snippets into your browser equippped with Greasemonkey and how to specify server whitelists and blacklists. I might introduce the same instructions here or put them up somewhere else.

While I thought I just had the solution, it then turned out that the block element was only equipped with a class parameter and no ID. I had also learned that only recent and modern versions of Greasemonkey now support the JavaScript getElementbyClass functionality, but I only have an outdated version.

Well, no matter: Greasemonkey 0.5.3 supports getElementbyId, but that really is not the most important thing, because Greasemonkey also allows injecting snippets of Cascading Style Sheets with JavaScript. And CSS is power.

Yes, while the DIV element did not have the ID parameter in it, it still had the CLASS parameter specified and the solution looks like this:
document.styleSheets[0].insertRule('A[class~=yucs-skipto-search] {display:none}', 0);
/* ^A is the linked element;
• Square brackets in the selector are used for conditional matching in the form of ELEMENT[attribute=value] — In this case, the {display:none} CSS block applies when yucs-skipto-search is found anywhere in an A tag's class attribute value (which the next point is about);
~= means that the pattern for the element attribute may be any matching part inside class, because when I looked at the source, the class parameter contained more than just yucs-skipto-search.
display:none collapses the element. */

document.styleSheets[0].insertRule('A[target=_top]:hover {text-decoration:underline !important;}', 0);
/* ^ In this line, Any hovered link tag A where the target parameter exactly contains _top must be underlined when hovered over. Note that instead of ~= for any matching part inside A[TARGET ]there is a single equals sign = for an exact match. !important overrides anything provided previously and makes sure that the these links are underlined when hovered over. */
So much for now.