web:config

I present you with a new script to enhance user experience on my.opera, dubbed Scribit.

The script provides the user the hability to edit all his/her forum posts, blog posts and comments, dev.opera comments and widget discussion's page comments without the need of opening a new webpage with the edit form. The script will create a inline editor, that will replace the original post, or comment, so the user can edit it inplace, therefore making editions much more pleasant and quick. The script also displays a inline toolbar with all the available formatting commands used to produce bbcode. The toolbar is not only displayed in the inline editor, but also in the already existing reply boxes in the forums, blogs and at dev.opera.

This script initially only worked for forum posts and was very simple. I coded version 2.0, to submit to the User Javascript contest but by influence of the others the script never got to the juri's inbox. Oh well...

Screenshot with default setup (standard skin)

Screenshot of Quick Edit link

Screenshot of post quick editing (Oxygen skin)

Instructions
The following keyboard shortcuts are supported in the inline editor, producing bbcode formating. Press Ctrl plus any of the following keys:

• b - bold
  
• i - italic
  
• u - underline
  
• s - strikethrough
  
• p - preformatted code
  
• t - insert unordered list
  
• l - align text to the left
  
• g - center text
  
• r - align text to the right
  
• j - justify text
  
• m - insert image
  
• h - create hyperlink
  
• e - insert email link
  
• f - attach file
  
• q - format text as quote
  
• w - whisper text
  
• ENTER - submit post

Later on, I'll make these easier customizable.

The script's configuration has sensible defaults. The entire UI is drawn using the current Opera skin, therefore providing an extra integration with the browser. Note however, that some skin bugs might be releaved. This script was succcessfully tested with Opera's default skin, and some other popular skins.
You can tweak the editor's behavior, although you need to edit the script itself.

This script does a daily new version check, warning the user of the new script version. You can disable this feature though. Check the configuration kCheckForNewVersion.

This entire script was done by me from scratch. The version check code was imported from the myopera-enhancements script, also made by me, and Robin Zalek. I recomend you to check it out.
http://my.opera.com/xErath/blog/2009/02/10/my-opera-community-enhancements

Credit also for AyushJ's quick-reply script for some inspiration.
http://my.opera.com/community/forums/topic.dml?id=185091

Many thanks to Lars Kleinschmidt as well for testing and feedback.

However, the script has much to catch up. The roadmap is:

• finishing html editing support
  
• supporting html to bbcode convertion and back on the fly
  
• adding a 'remove formatting button', trivial for html, hard for bbcode
  
• removing all prompt boxes and replacing them with proper floating
  
• menus providing the user input suggestions, like listing his/her files when the attach button is pressed.
  
• replacing the default new blog post, new form thread, and new dev opera article
  
• making a lovely UI to edit configurations

Etimology: Scribit derives from scribe

Download the script from:
xerath-myopera-scribit.js
Future versions will be announced here, and the script will notify the user of the new version.

For the geeks
Script documentation is available at, generated using JSDoc:
scribit-documentation.zip

All text strings stored by this script are properly grouped to ease the script's localization. Currently, the suported languages are english and portuguese. Other users are encouraged to contribute. The language is autodetected and will match your UI language, but this can be overriden by setting the kPreferedLanguage configuration variable. If the UI language is not supported, english will be used.

Translations code chunk:

var translations = {
    en:{//plain english 
        L_SUBMIT: 'Submit',
        L_CANCEL: 'Cancel',
        L_QUICK_EDIT: 'Quick edit',
        L_QUICK_EDIT_LINK_TOOLTIP: 'Quick edit this post using inline editor',
        L_ERROR_ON_LOAD: 'Error loading post from server',
        L_LOADING_DATA_STATUS_MSG: 'Loading data from server...',
        L_POST_NOT_CHANGED_NOTIF: 'Post not changed (to quit press Cancel)',
        L_SUBMITTING: 'Submitting...',
        L_ERROR: a'Error',
        ...

Have fun!

Note: title kindly adapted from Emperor's 2001 album

Lets do a little experience.
1. Go to the website http://www.asdf.com/
2. Select block content from the right-click menu
3. Add http://www.asdf.com/* to the blocked urls.
4. Now open this url. Here's what you see

5. Go to a unexistent website like http://foo.bar/. Here's what you see

Can you make the difference ? No ? Look a little closer, approach the screen a bit, observe from different angles. Still can't see the different ? Well, the second website has some red in it.

What does this mean ?
Whops ! You stumbled upon a invalid domain and Opera cannot connect. But what about the 1st case ? Opera deliberatly blocked the url.

Now imagine that you just downloaded one of those ad lists online. You start to wonder..hum ! Opera can't render this webpage. It's a Google conspiracy for sure.

Most filter files encoutered online are too generic, and hit too many false positives.
Consider the case described in this thread.
The user complained because Opera blocked an image which add "/ad4" in it's base64 content. Well too bad. You downloaded a too generic filter file, now you hit some false positives. But he was lucky to solve the problem with such a simple case. If you check the OP's filter file, whenever there should be either a dot and an wildcard, or wildcard and dot, there is no dot, becaise the person that did that filter file didn't consider that ad4 could ever be part of a valid url, which that rule would happily block.

Now, why did I initially approach this subject with the asdf.com example ?
Simple. Opera currently does not provide any way to tell the user that some content is blocked. Iframes get blank, not loaded scripts go to the error console and that's it. Opera definetly needs a friendly error page telling the user that a url was blocked. If so, the user would then inspect either the info panel, or whatever, to realize that there is blocked content.

As an extra case, I once saw a user complaining he couldn't open any website that started with http://count*
Where do I recognize that ? Most statistic website's domains start with count. So the poor used downloaded a bad filter file, and actively contributed for Opera not being part of statistics online. The author of that filter file must be proud.

Conclusion: don't accept generic filter files out of ignorance. First inspect them. Tamil has a almost good list, but I consider it too generic. My personal filter file has a very little amount of generic rules. The rest is all full domains, and I rarely see an ad.

Happy browsing (without annoying ads).