... good, isn't it? :) try putting superkaramba with "kroller.sez" in front of people (make sure it's KDE 3.5.1 or above that you use).

after significant periods of time using kroller (the original, by caspian) or kroller.sez, people _do_ miss it - like the MAC rollerbar, it's just incredibly in-your-face and obvious as to what you're supposed to do.

click da icon, da program run. very visual. very satisfying. very pretty. very quick.

the advantage of using kroller.sez is that it reads the user's KDE system menu options and presents those at them.

none of this crap obscure text file editing shit.

social networking site framework

well... i am pleased to say that i have a decent application framework that can be used to switch between AJAX and "plain" modes - using the same content, giving exactly the same look irrespective of the "mode". this is crucial to successfully being able to have google adsense work correctly as google adsense cannot work correctly - at all - with AJAX sites. you just can't do it! the stupid javascript that you must insert into the page doesn't even _work_.

i've had to "templatise" - by putting things into python and have a function which constructs AJAX or "plain" on-demand for the following things:

• all hrefs
• all form actions and all form submit buttons
• all "subsections" of web pages (think "child windows" in a GUI app)

the hrefs i handle in AJAX mode by calling a javascript function ajax_dlink('thedivid', 'thehref... &source=thedivid'), and in "plain" mode by adding "&source=thedivid&__mainpage__=index" to the end of the href.

in both cases, the "source=" argument is stripped out _before_ the actual page is constructed; the rest of the URL is then stored in a dictionary, using "thedivid" as the key into the dictionary.

later on, in the case of "plain" mode, whenever a "child window" - or subsection page - named "thedivid" is encountered, this URL is retrieved, the "loading" of that URL is simulated - its python function called - and the content is "substituted" into the parent's web page as the inner HTML of the relevant < div /> tag!

in the AJAX case, what i do is add in an extra AJAX call into the main index page, which will cause the browser to request that "child" page to be substituted into the DOM model at the browser end.

the result is that even when someone causes a "refresh" on the page, the "constructed" page is recreated (because the history of all "subsections" is stored in that dictionary).

i suppose i could do it on the server, in the same way as the "plain" mode - but.... naaaah :)

forms, forms, forms. these didn't turn out to be as tricky as i thought, after i decided that every submit, instead of returning content, should instead do a redirect to the page containing the content.

in this way i have a way to "catch" things and make a decision about where the actual destination should be - and also strip out any further bits which should go into that dictionary of child-window-state-info.

i'm surprised that it all seems to be hanging together as nicely as it does, and i look forward to experimenting to create an automatic "frames" mode at some point, just to see if i can.