So, as part of a semi-Sekrit Projekt, I have been working on trying to get an arbitrary number of <div>s in a web page to behave as popups: they remain hidden until the mouse hovers over specific elements in the page, at which point they appear.

This is not, of itself, all that complicated to do - there's a plethora of solutions out there for this.

Of course, this is me, it's not that simple. I need a bunch of Extra Features for this:

• Popups should not appear immediately on the mouse hovering over the element. I've gone for a 2 second delay there. Similarly, they should hang around for half a second after the mouse leaves the element.
• Any muppet can do simple appear/disappear, these must fade in and out.
• If the user makes the popup appear, they need to be able to move the mouse into the popup and have it remain open.
• The popups must be placed at specific locations relative to the element they are attached to.

The first three of these are not too bad, especially as mootools - a javascript framework to provide a lot of nice new features - can help with things like easy to use timed events, and fading. The problem was the last point on the list.

Mootools provides a few methods to obtain the location of elements on a page (so that you can position one element relative to another). It even provides a position() function that should make the process of positioning one element relative to another trivial. Unfortunately, they are all crap. They either produce different coordinates in different browsers, or completely incorrect coordinates, or bugger all.

And so, I set about making my own code to work it out. There's a fair amount of code out there on the net to do this, too. Again, all the ones I tried fall down in some situations, and I ran into the problem with my own code too: the coordinates returned looked correct - screenshotting the browser window, and plotting the coordinates in a graphics program appeared to show the correct place - but when the left and top of the popup div were set to the coordinates, the popup would consistently appear a significant distance below or to the left of the location it should be.

It took me a couple of hours to finally realise what the problem was, and now it seems so obvious I've no idea why I didn't realise it before: all the solutions I had run into and tried had the unstated, implicit assumption that the element being positioned was in the top level of the document, or all of its parent elements has their css position attribute set to 'relative' or 'inherit'. If one of the parent elements had 'position: absolute' (as the 'main content' container div in my pages does), then the position of the div needs to be relative to that, not the page! Once I'd realised this, the following code represents the solution to locating the position of an element in a page (and it appears to work fine in firefox, Seamonkey, Opera, and Safari. I haven't tried it in IE because, frankly, I don't care it works there or not):

Code:

function getRelativePos(element, xhandle, yhandle) {
var obj = element;
var curleft = 0;
var curtop = 0;

// Work out the top left corner of the specified element.
// Note that we need to stop the search at the first absolute
// position element encountered, as coords for left and top will
// be relative to that element!
while(obj.offsetParent && obj.getStyle('position') != 'absolute') {
curleft += obj.offsetLeft;
curtop += obj.offsetTop;
obj = obj.offsetParent;
}

// If the x handle is set to something other than 'left', deal with it
if(xhandle == 'right') {
curleft += element.offsetWidth;
} else if(xhandle == 'center') {
curleft += parseInt(element.offsetWidth / 2);
}

// Now do the same for the y
if(yhandle == 'bottom') {
curtop += element.offsetHeight;
} else if(yhandle == 'center') {
curtop += parseInt(element.offsetHeight / 2);
}

return { x: curleft, y: curtop }
}

mootools-core is needed for the getStyle() function, but that could be replaced if that causes a problem. For an example of it in action, the mockup page for the system it will be used in can be found here. Leave the mouse over the first columns of the top three rows to see the popup effect.

Even better, I think I should be able to reuse the same code verbatim in the CBT package framework we use in work, to replace the clunky new window popups entirely!

One of the most famous Holy Wars in the computer world is the eternal Pulling Of Beards that is Emacs v Vi, a debate that has raged for decades and will probably continue until the last atoms smear themselves into the entropy death of the universe. Both sides have their points, but I'm firmly in the Emacs camp. Back in the Old Times, I used to use GoldED on the Amiga (which has since become 'CubicIDE' apparently, I'm shocked they're even still going), and when I moved to the linux and windows worlds I spent a fair amount of time using GoldED in WinUAE because I just couldn't find another text editor I liked. Eventually, the process became too clumbersome, and I found myself picking up emacs and its idiosyncrasies.

All of this is just prologue, really. The important part of it is that I am very used to emacs' keyboard incantations now, so things like "I want to cut this region of text" is far more synonymous with 'ctrl+w' than with the 'ctrl+x' most people associate with Cut.

On its own, this is also not a problem. Until you realise that seamonkey (my browser of choice, given that Opera still has Issues for me) binds ctrl+w to 'Close current tab or window', and then things get nasty. I have this habit, when editing text in text areas, of unconsciously using emacsism: selecting a piece of text to cut only to hit the close window key because my brain is in the wrong editor mode is... infuriating. To make matters worse, seamonkey does not have any remotely sane method of remapping controls (as far as I can tell, it requires hacking chrome files, but I've never been able to get it to work).

This gets even worse when I accidentally do it while working in the course development wiki for work, and end up wiping 15 minutes of editing by pressing the wrong key shortcut. Yesterday, after racking up something like 3 or 4 hours of lost work because of that mistake, I finally snapped and started to look at ways to add a window close confirm to mediawiki.

It turns out it's actually remarkably simple to do, at least in recent browsers. In the end, all it took was editing two files. Here, in case anyone is interested, is how to do it.

First, some javascript is needed to handle the close warning. This can't go in MediaWiki:Common.js otherwise it would completely mess up navigating through the wiki, it pretty much requires editing the MediaWiki files. At the bottom of skins/common/edit.js add the following lines:

Code:

var needToConfirm = true;
window.onbeforeunload = function (){
if(needToConfirm)
return "Are you sure you want to close this edit window?";
}

This creates a variable used as a flag to determine whether the user needs to confirm window close or not, and then registers an anonymous function as the callback for the onbeforeunload event for the window. This will prompt the user to confirm the window close if the confirm flag is true. With that in place, the user will be prompted to confirm closing the window every time they attempt to exit an edit page in the wiki, unfortunately they will be prompted even if they use the Save or Preview. To get around that, a few lines need to be added to includes/EditPage.php.

This is slightly trickier, as it means inserting code in the midst of existing code. The easiest thing to do is look for

Code:

public function getEditButtons(&$tabindex) {

and then, in each of the '$temp = array(' blocks in that function, add the following line:

Code:

'onclick' => 'needToConfirm = false',

So, for example:

Code:

$temp = array(
'id' => 'wpSave',
'name' => 'wpSave',
'type' => 'submit',
'tabindex' => ++$tabindex,
'value' => wfMsg('savearticle'),
'accesskey' => wfMsg('accesskey-save'),
'title' => wfMsg( 'tooltip-save' ).' ['.wfMsg( 'accesskey-save'$
);

Has the onclick line added so that it becomes:

Code:

$temp = array(
'onclick' => 'needToConfirm = false',
'id' => 'wpSave',
'name' => 'wpSave',
'type' => 'submit',
'tabindex' => ++$tabindex,
'value' => wfMsg('savearticle'),
'accesskey' => wfMsg('accesskey-save'),
'title' => wfMsg( 'tooltip-save' ).' ['.wfMsg( 'accesskey-save'$
);

Now, the user will be prompted whenever they attempt to close, cancel, or navigate away from an edit page, but not when they hit Save Page, Preview, or Changes.

I'm vaguely tempted to submit this as a patch to MediaWiki and see what happens, as it's already saved my arse twice...

So, I have another web application in the early throes of development. As ever, I decided to reuse chunks of my hard-working perl module based web framework to implement it, only this time I was forced to look long and hard at what I was doing.

One thing I hadn't fully realised until I looked at things carefully was just how much commonality there was between my web apps. For example, http://www.starforge.co.uk/ and http://myst.starforge.co.uk/ share very large amounts of code: the starforge site totals 5955 lines of code, ORB comes out at 6769 loc, and the two have 3087 lines in common (52% of the starforge site code is reused verbatim in the ORB!)

However, to my slight embarrassment, that shared code was actually duplicated in both apps (for example, both the starforge site and the ORB had identical copies of phpBB3.pm, Template.pm, and several other modules) There were a few minor differences between some modules used by the two apps, but with some rewriting and refactoring I have been able to get to the point where I have been able to move the common modules out into a shared location, and I can now safely work on the shared code or the webapp specific code without worrying about fixing a bug in a module in one of them but forgetting to fix the same bug in the other.

I can also easily create another webapp using them without having to worry about having the latest versions!

On top of that, it also means that I can make them available for anyone who wants them - the tarball containing the source can be found here, while the documentation for the modules (generated by doxygen from the source) can be viewed online here. If you are interested, go look and play around with them, and poke me if you have any questions or suggestions.

And now, back to the thing that triggered this in the first place...

As I noted in #code yesterday, I think I have an unhealthy obsession with attempting to represent system designs diagramatically. And almost never in 'accepted' standards like UML (which I tend to view as the Unusuable Modeling Language - any modeling system that requires a course to use properly has missed the point, guys) but using some odd system that shows flows of data or objects, and systems that process them, that I've never really been able to fully place properly in any "standard" modeling framework. This is somewhat demonstrated by this refinement to the ImageHandler diagram from a couple of entries back:

This tells me what I need to know to tackle the implementation: it shows me which components of the system need to talk to each other, where things come from and go to, and notes about how to do it thrown in. I rather suspect that it's not really a huge help to any other coder, as there's probably a lot of tacit information I have omitted. But, it works for me, and I'm hardly being held to some Forced Standard. Of course, the diagram will also evolve as I implement things and find better ways to do things¹. That, in turn, may open up other directions for development and improvement...

But anyway, what it does tell me right now is that, now that I have the code done to implement the Request Queue, Thumbnail Cache, and Image Cache, the next thing I really need to concentrate on is the code to allow the image loader threads to save data into the disc cache: SDL_image does not - for some reason probably related to it not being 'interesting', or something - provide any functions to save as png/jpeg/etc, despite relying libraries that provide those facilities for loading, so I need to put something together to do that before I can start to build the loader threads.

¹ some time (when it isn't 23:16) I will Rant on the subject of designs, models, managers, and unrealistic expectations. But not now, because it is 23:16, and I need to be up at 7:00 tomorrow to commute. Blegh.

I've slacked off a bit with the Online Recipe Book system, but I've just finished the summary page (as much as is possible now anyway), and fixed up the pagination controls for the recipe index pages.

Big remaining sections are:

• the search facility.
• the menu planner.
• the ingredient manager (to allow slightly reworded ingredients to be merged or mass renamed).

That said, the current code status:

Code:

Scanned 6379 lines (289496 characters) in 16 files
Shortest file: 107 lines (../public_html/index.cgi)
Longest file: 1461 lines (../public_html/blocks/ManageRecipes.pm)
Average file length: 398 lines (18093 characters)
Number of functions: 149
Av. functions per file: 9
Minimum function length: 1 lines (../public_html/blocks/Block.pm::set_error)
Maximum function length: 172 lines (../public_html/blocks/ManageRecipes.pm::view_recipe)
Average function length: 27 lines
Longest line: 314 characters (../public_html/blocks/ManageRecipes.pm line 1323)
Comments: 118426 of 289496 characters (40.91%)
Whitespace: 87391 of 289496 characters (30.19%)

File length histogram
Frequency
.---------------------------------------------------------------
57 | ## (2, 12%)
114 | # (1, 6%)
171 | ### (3, 18%)
228 | ## (2, 12%)
L 285 | (0, 0%)
e 342 | # (1, 6%)
n 399 | ### (3, 18%)
g 456 | ## (2, 12%)
t 513 | (0, 0%)
h 570 | (0, 0%)
627 | (0, 0%)
i 684 | (0, 0%)
n 741 | (0, 0%)
798 | (0, 0%)
b 855 | (0, 0%)
y 912 | # (1, 6%)
t 969 | (0, 0%)
e 1026 | (0, 0%)
s 1083 | (0, 0%)
1140 | (0, 0%)
1197 | (0, 0%)
1254 | (0, 0%)
1311 | (0, 0%)
1368 | (0, 0%)
1425 | # (1, 6%)
`---------------------------------------------------------------

Function length histogram
Frequency
.---------------------------------------------------------------
0 | ######################## (24, 16%)
L 8 | #################################### (36, 24%)
i 16 | ######################## (24, 16%)
n 24 | ######################## (24, 16%)
e 32 | ####### (7, 4%)
s 40 | ######## (8, 5%)
48 | ###### (6, 4%)
p 56 | ######## (8, 5%)
e 64 | #### (4, 2%)
r 72 | ### (3, 2%)
80 | (0, 0%)
f 88 | ## (2, 1%)
u 96 | (0, 0%)
n 104 | (0, 0%)
c 112 | (0, 0%)
t 120 | (0, 0%)
i 128 | (0, 0%)
o 136 | (0, 0%)
n 144 | (0, 0%)
152 | # (1, 0%)
160 | (0, 0%)
168 | ## (2, 1%)
`---------------------------------------------------------------

Line length histogram (empty lines omitted)
Frequency
.--------------------------------------------------------------
0 | ########################################### (698, 13%)
14 | ########################################################## (935, 17%)
28 | ######################################## (652, 12%)
42 | ############################################ (714, 13%)
C 56 | ####################################### (638, 11%)
h 70 | ############################################## (741, 13%)
a 84 | ######################### (404, 7%)
r 98 | ############ (199, 3%)
s 112 | ########## (167, 3%)
126 | ##### (93, 1%)
p 140 | ### (55, 1%)
e 154 | # (17, 0%)
r 168 | # (23, 0%)
182 | (10, 0%)
l 196 | (2, 0%)
i 210 | (1, 0%)
n 224 | (0, 0%)
e 238 | (1, 0%)
252 | (1, 0%)
266 | (0, 0%)
280 | (0, 0%)
294 | (0, 0%)
308 | (1, 0%)
`--------------------------------------------------------------