On 23rd of April 2015, Mihai Șucan passed away due to metastatic cancer caused by
RDEB.
My name is Mihai and I work on the
Firefox developer tools. When it comes to web development, I like
both server-side and client-side work. I am mainly interested in web browsers, web standards and related
technologies.
12 March 2010, 16:57
Hello everyone!
In the latest article I wrote about
SVG and Canvas I included a small HTML5 demo which renders a color histogram using Canvas, analyzing any image element. Knowing that the Canvas
API allows developers to also read video frames, I wanted to test
how fast can JavaScript and Canvas render a color histogram while the video plays.
I changed the initial script so that now it works with HTML5 videos. Here is the result:
In this demo I include a small video and a big HD trailer - just out of curiosity I wanted to see something that
barely runs within the browser. The demo works with Opera 10.5 and Firefox 3.6 - tested on Linux and Windows.
Currently, Chromium 5 on Linux crashes when I try to load the page.
I did spend quite some time testing various improvements to the performance of the script. I would note that changing
the script to not access the DOM elements and properties directly, does not bring any important improvements in
execution speed. However, the change to use bitwise operations did make a difference. Further improvements would come
if I would inline functions and remove some of the options. Still, any ideas on how to further improve the performance
of the demo would be welcome.
Working on this HTML5 demo I also explored a new API available in Firefox 3.5: Web Workers. As I expected, the result of adding a web worker to this use-case is not something I am happy with. In a web worker I cannot access the video, nor can I access any of
the canvas elements. I could move only a really small part of the code into a worker, and the performance penalty of sending
the pixels in a message from the main thread to the worker thread is too significant. In the end, it runs quite slower
than the script which does not use any web worker.
26th of June update:
Opera 10.6 beta 1 was released
a few days ago. This release brings support for Web Workers and it is really great to see that
my Web Workers demo works in Opera as well.
Any feedback is appreciated.
Published in:
canvas, demos, firefox, html5, opera, video.
17 February 2010, 14:30
Just a quick note to people around here: Opera Software has recently published a new article I wrote:
SVG or Canvas? Choosing between the two. You can also read the article on my server. As usual, thanks go to Chris Mills for reviewing and providing feedback for improvements to the article.
In unrelated news, things are going fine around here. A new web site I've been working on will be released to the
public pretty soon. More cool stuff will come. ;)
Published in:
canvas, opera, svg, tutorials.
24 July 2009, 12:21
Hello everyone!
I am getting closer to having a Moodle demo ready with PaintWeb integrated. Wednesday I had a very fruitful discussion with my mentor, Martin, on how I should proceed with the implementation
of file saving inside the Moodle data directory. We have come to a conclusion which I am about to implement. More details
soon.
For now, I have registered a Moodle Git repository mirror
over at repo.or.cz. I have also registered a Moodle "fork" where I publish my Moodle branches. You can do:
git clone git://repo.or.cz/moodle/mihaisucan.git ~/src/moodle-mihai
cd ~/src/moodle-mihai
git checkout -b mdl19-paintweb origin/mdl19-paintweb
With that, you can easily and quickly get an always up-to-date Moodle 1.9 stable branch with TinyMCE 3 and PaintWeb integrated. You can already play with PaintWeb in Moodle.
If you only want the TinyMCE 3 editor you can do:
git checkout -b mdl19-tinymce3 origin/mdl19-tinymce3
The TinyMCE 3 branch holds Moodle 1.9 stable with the latest TinyMCE 3 integrated. The work I did on this branch is
best explained in a Moodle forum discussion.
When you want to update your branch simply invoke git pull. Please also check the official documentation
about
how to use Git.
In related news, Opera Software has published the final part of the article serie I wrote about
keyboard accessibility in Web applications. This article details the cross-browser compatibility layer implementation for keyboard events used by PaintWeb.
Enjoy!
Published in:
git, gsoc2009, moodle, opera, paintweb, tinymce, tutorials.
17 July 2009, 11:05
Hello again!
The Google Summer of Code midterm evaluations passed without any problems for me, yay!
I have began work on integrating PaintWeb into Moodle. I will integrate my project into the stable Moodle 1.9 branch and into the upcoming Moodle 2.0 release.
Moodle 1.9 has a very old TinyMCE release (version 2.0) which is not used by
default - the even older HTMLArea is still used. Both do not work in Opera and Google Chrome. For this reason Martin Langhoff,
my mentor, and other Moodle community members have worked on patches to switch to the modern TinyMCE 3 editor. A
clean port of TinyMCE 3 to Moodle 1.9 is available on the
Moodle forums.
The clean port is quite well done, but again, it was "outdated", being from october 2008.
For PaintWeb I took the work Martin did and updated it to the latest Moodle 1.9 stable branch, the latest TinyMCE 3
version, and made additional fixes. One fix was to make the editor show up in Opera, Safari and Chrome, and another
fix was for the script which converts TinyMCE language files to Moodle language files.
PaintWeb integration into Moodle 1.9 will come as a patch on top of the TinyMCE 3 patch. Currently I got PaintWeb
loading fine in TinyMCE, inside Moodle. More work is needed to get file save working. For PaintWeb I did some assorted
fixes for the Makefile, for the overall keyboard accessibility, for multi-language support, and I did improvements to
the TinyMCE plugin.
You can download the updated TinyMCE 3 patch for Moodle 1.9.
The package includes usage instructions.
In other related news, Opera Software has published the second part of the article I wrote about
keyboard accessiblity in Web applications. This article describes the inner workings of the MouseKeys extension for PaintWeb. Make sure you checkout the
updated and improved
source code of the MouseKeys extension in the PaintWeb code tree.
Have fun until the next time!
Published in:
gsoc2009, moodle, opera, paintweb, tinymce, tutorials.
8 July 2009, 14:03
Hello again!
In the past week there was important progress on PaintWeb. I have
published several wiki pages about PaintWeb on Google Code - this documentation comes as an overview or a guide to the entire codebase and the API reference. You can read about how to integrate PaintWeb into your Web application, how to extend PaintWeb, how to package PaintWeb yourself with the Makefile, and how to use the new TinyMCE plugin.
I have completed a new
TinyMCE plugin which allows you to easily and quickly integrate PaintWeb. This plugin allows users to click an "Edit" button which is
overlayed on top of the editable images. The plugin also includes a context menu item (right-click and choose "Edit image"),
and a toolbar button.
I have published a new demo page which shows the latest TinyMCE and PaintWeb working together. Enjoy!
Moodle integration is currently being planned. I wrote my thoughts and questions in a Moodle Docs wiki page about the paint tool integration.
Last, but not least, for the purpose of tracking progress, I have attached a packaged PaintWeb snapshot to the Moodle tracker issue associated with my project.
Olli Savolainen has created some very good mockups as proposals to improve the PaintWeb user interface. His feedback is very much appreciated, and I really hope to get to implement his suggestions as soon as possible.
Thanks Olli!
On a related note, for those interested on
how PaintWeb implements keyboard shortcuts, Opera Software has just published the first part of a series of articles I wrote on this topic. More articles will
be published soon at the Opera Developer community site.
Have fun testing PaintWeb and reading articles about it. Don't forget that I am always looking forward for feedback!
Published in:
api, documentation, gsoc2009, moodle, opera, paintweb, tinymce, tutorials.
23 June 2009, 19:51
Hello again!
The
HTML 5 Canvas specification defines two important methods for text rendering:
fillText() and strokeText(). You also have a measureText() and the associated text-related
properties: font, textAlign and
textBaseline.
The Canvas Text API is only implemented in Webkit (Safari and Chrome)
and in Gecko 1.9.1+ (Firefox 3.5+).
If you want to render text in your Canvas element in Gecko 1.9.0 (Firefox 3.0) you can use their proprietary Canvas text rendering API which is now, obviously, deprecated in favour of the standardized API. They provided the following methods: mozDrawText(), mozPathText(),
mozTextAlongPath() and mozMeasureText(). To style the text you only have the mozTextStyle
property.
In PaintWeb I use the mozPathText() method when the standard
API is not available.
Opera does not support the Canvas Text API. I learned that the
drawImage() 2D context method allows the drawing of SVG document as well - this works only in Opera. I implemented
the text tool by adding a new minimal SVG document which contains a
<text> element. This was updated and drawn in the Canvas element in sync with user interaction. However,
after I completed the implementation I found several bugs:
-
SVG redraw issues. When you update the text styling properties, or when you update the text itself, sometimes Opera
fails to entirely redraw the SVG document, irrespective of the SVG being visible or not.
-
memory leaks (test case). For some unfortunate reason, each
drawImage(svgDocument) leaks some amount of memory. Got a crasher with this, and a system freeze
after filling my physical memory (1 GB) and the swap (1 GB). ;)
-
security violations (test case). Opera considers the SVG
document as being an external resource, thus it marks the Canvas as being "dirty" once
drawImage(svgDocument) is invoked. You can no longer read pixels using getImageData(), nor can you use the toDataURL() method. This broke the PaintWeb history mechanism, the selection tool,
and the "image save" option.
The first two issues I said I can live with, but not with the security violations. Thus, I have disabled the text tool
in Opera. I have reported the last two bugs to Opera with the associated minimal test cases.
If you are interested to render text, you can even attempt server-side "hacks". You could make a server-side script
which renders text, and you can then draw it in your Canvas with an image element. This, however, defeats the purpose
of PaintWeb - I want it to be a "pure" client-side Web application.
Lastly, you can implement "vector drawing" of text using a client-side font definition in some format, and then render
it with basic paths in Canvas. Again, this is beyond the purpose of PaintWeb. Opera will implement Canvas Text some
day. :)
For further details about attempts at rendering text when the standard Canvas Text API is not available, please read
the rendering text blog post wrote by Christopher Clay
at the end of 2006.
Published in:
bugs, canvas, gecko, gsoc2009, html5, opera, paintweb, svg, text, webkit.
28 May 2009, 11:55
Hello everyone!
This week I have completed my work on performance testing and improvements for PaintWeb on the OLPC XO laptop.
During testing it became obvious that something other than the actual Canvas painting was very slow on the XO. The
main performance culprit is that the default Gecko-based browser is configured to render pages using 134 DPI instead of the default 96
DPI. Generally web browsers render pages using 96 DPI. If the XO web browser would do the same the texts and the images
would be far too small - the
XO display is an odd 200 DPI screen perceived as 134 DPI.
PaintWeb's drawing performance was hugely affected by the bilinear scaling of the Canvas elements being done by the
browser on the XO. When I configured the browser to render the page using 96 DPI, the web application became a lot
more responsive.
Martin Langhoff, my mentor, got in contact with Robert O'Callahan from Mozilla. He provided us with lots of help in finding a solution for the performance issue.
We did think about having a CSS property to change the DPI only for the Canvas
elements, or a different CSS property to disable scaling, or some proprietary API for changing the DPI on a single page.
None of these are good ideas, because they allow web developers to start coding for specific DPIs - this is not desired.
Gecko scales pages using integer scaling factors - that's 1, 2, 3, etc - it doesn't use floating point numbers. In a
normal Gecko build the scaling factor for 134 DPI is 1 - because 134 / 96 = 1, so you do not get any scaling. You can
have a scaling factor of 2 or higher if you go above 192 DPI.
Gecko is patched on the XO in a way that it forces
the browser to scale pages using floating-point scaling factors as well. Therefore, for 134 DPI the pages are scaled and
they look really good on the XO screen.
The final solution which I implemented into PaintWeb is to simply scale down the Canvas elements in my document. If I
accurately scale down the elements, Gecko is sufficiently optimized to cancel any scaling and you do not notice any
performance impact. This works really great.
In Gecko 1.9.1 (Firefox 3.5) I can detect the DPI used
for rendering the page with CSS 3 Media Queries. I use this in
PaintWeb. However, the XO only has Gecko 1.9.0 for now, so I cannot determine the DPI. I am forced to do user agent
sniffing to check if the browser runs on the OLPC XO. If it does, then I scale down the Canvas elements using a
different way of calculating the scale-down factor - because Gecko is patched - and I always consider the page is
render using 134 DPI. Fun, huh? ;)
On Opera, on the XO, I did all my testing using 100% zoom level. It ran much better
than Gecko, for obvious reasons (no scaling, yay). Once I fixed the Gecko scaling issue, Opera came second. For some
reason Canvas draws much faster in Gecko than in Opera on the OLPC XO.
Opera cannot render pages using different DPI values other than 96. People use zoom, so, for consistency, I use an old
trick to
measure the zoom level (thanks Arve). Based on
this I scale down the Canvas elements. For some zoom levels, like 200%, the scaling is cancelled and PaintWeb works better.
Unfortunately, Opera does not allow non-integer pixel values, thus the scaling-down is generally not effective...
Another important performance improvement in PaintWeb is the use of timer-based canvas drawing. This means that mouse
move events are either cancelled or coalesced into one. For example, redrawing a polygon with a lot of points for
every mouse move is very slow. The tools in PaintWeb use timers to update the canvas every few milliseconds. This
approach makes PaintWeb feel faster.
Lastly, I now avoid going into the global scope, for things like
Math.round or such. The importance of this change is reduced by the fact the JavaScript that runs is not very
intensive - not too much code is executed for each mouse move event. Such changes become more important the more code you
run. This will be important for the color space visualization I have.
The loading performance will improve greatly once I will make a packager for PaintWeb. Additionally, I will continue
to constantly check the overall performance of the web application on the OLPC XO.
Go ahead and try PaintWeb from SVN trunk. Lots of thanks to Robert
for his great help and to Martin for his assistance and for finding the Gecko patches.
Currently I am working on the new user interface, stay tuned!
Update May 31, 2009: Just published a page on the OLPC wiki about the HTML Canvas performance on the OLPC XO laptops. The page includes code snippets explaining how to work-around the scaling issue.
Published in:
canvas, css, dpi, gecko, gsoc2009, moodle, olpc, opera, paintweb, performance.
14 May 2009, 11:09
Hello everyone!
I have been working on the PaintWeb code refactoring and now I am nearing
completion. The initial PaintWeb 0.5 alpha code was more of a demo - it was all in a single big script. I have now added
jsdoc comments almost everywhere and I did split the code into multiple files - per tools, per extensions, per language,
and more. I have also made important changes to the API. Now
any external code can easily add/remove tools, extensions and keyboard shortcuts.
For more developer-related information please read the latest forum thread I posted on the Moodle forums.
For teachers and potential users of PaintWeb inside Moodle, I have prepared a list of questions on how you would use the paint tool in Moodle.
Martin, my mentor, suggested early in my GSOC application process to also apply
for the OLPC Contributors program. So I did, and my project was accepted.
Even if the OLPC XO has a slow CPU by today's expectations, it's only 400 Mhz, the system works quite nicely. It has
256 MB of RAM and 1GB of disk capacity. The Sugar interface and the activities provided are amazing. People who hear
about these laptops do not know to appreciate the numerous doors such laptops open, doors to knowledge, for all those
children who receive them. They help a lot in learning about computing, maths, music, and more.
The Sugar interface is quite well thought-out. I like the concept of having the neighbourhood, group, home and
activity views.
The default browser, is some Python application embedding Gecko - on par with Firefox 3.0. The performance of the
browser is lacking.
Opera 10 alphas start much faster and feel snappier. The paint tool
feels sluggish as well.
The Gnash plugin
is more of a problem rather than a solution. I installed Flash Player 10, which is sluggish, but at least it works. The
system can play Youtube high-quality videos and even uncompressed DVD videos, with Mplayer over the wireless connection. Flash Player cannot play Youtube videos.
Battery life is good - I can use it about three hours without any problems.
Since last week I have been working on the performance of the PaintWeb application, with the OLPC XO-1 laptop. After
several tests, I have managed to improve things sufficiently such that the paint tool is now usable in Opera 10 on the
XO. Unfortunately, in Browse.xo it's not, at least not by default.
The main performance culprit affecting PaintWeb on the XO is their use of layout.css.dpi. Gecko allows
users to change the
DPI used for rendering Web pages, in order to makes fonts and images smaller or bigger.
So, on the XO the browser is set to use DPI 134, instead of DPI 96. This makes the fonts and images render bigger - with
DPI 96 they would all be way too small. PaintWeb and all the pages feel much slower because Gecko performs bilinear image
resampling.
When I set layout.css.dpi to 96, drawing in PaintWeb becomes real-time. I was amazed to see it works so well.
It's like on my desktop computer. And ... it's even faster than in Opera 10. ;)
If you want, check out the
performance tests yourself. Spoiler: Webkit is the fastest and Gecko is the slowest when running synthetic tests. Obviously, more performance
tests will come - these are only limited to the pencil tool and to the main ev_canvas() event handler from
PaintWeb.
Next on my of list things to do is a new GUI and a packager for the entire
code. Loading PaintWeb is now slower due to the amount of code comments and the increasing number of files. The packager
will compress/minify all the files into a single one.
That's all for now. Any feedback is welcome!
Published in:
canvas, css, dpi, gecko, gsoc2009, moodle, olpc, opera, paintweb, performance, webkit.
23 April 2009, 14:58
Hello everyone!
I have great news this time! I have applied to work for the
Moodle project over the summer within the Google Summer of Code program. My project proposal has been accepted. This means that
over the summer I will be working on integrating the PaintWeb project into
Moodle. Part of this work will also include a complete code reorganization and several important improvements.
Locally I have already started working towards code reorganization and a complete rework of the keyboard shortcuts
support inside PaintWeb is ready. This work will become public very soon.
I am really glad to be working with one of the best open-source educational software. The Moodle community has been
very nice and they welcomed me warmly. Congratulations to every student who has been accepted this year!
On a related note, Opera Software has published a tutorial I wrote about how you can start developing your own paint tool. The code presented is strongly based on my work for PaintWeb. Another new tutorial is now being prepared for
publishing.
Best luck to everybody and stay tuned for more!
Published in:
gsoc2009, moodle, opera, paintweb, tutorials.
9 January 2009, 12:41
Hello everyone and a happy new year!
Opera Software has just published my third tutorial: HTML 5 canvas - the basics. Hopefully, I will have more tutorials coming about canvas and other Web technologies.
With this occasion I have updated my site and I added a new
Tutorials page.
As usual, any feedback is welcome! So, please go ahead and provide me with critiques, suggestions and anything you
deem important.
Published in:
opera, tutorials.
11 May 2008, 18:06
Hello guys!
Opera Software has finally released some serious Web developer tools: Dragonfly. Unlike their first attempt, the bookmarklets, which disappointed, this
time around Dragonfly tries to make up for the time lost. Even if the developer tools should've come earlier, it's
better we get them latter than never.
Firebug is currently the king of Web developer tools. It certainly is the best and
most complete one I've used: good DOM
Inspector, good debugger, good console and a nice API, all
with a good looking GUI. The position of "king" is now challenged by Dragonfly which has some very important ideas.
Packaging and architecture
You can install Firebug as a Firefox extension. Firebug is practically a Web application with additional privileges,
accessing more of the internal API of Firefox.
Dragonfly is similar, but it's not an extension for Opera. It comes as an external Web application for Opera - it's
not native. Yet, like Firebug, it has access to the internal Scope API. The Scope API is a specification written and
implemented by Opera 9.5 beta 2. As such, Dragonfly is not
limited in purpose and possibilities.
Perhaps the most important part of this alpha release of Dragonfly is the Scope API specification which will be publicly available soon. People will be able to build their own set of developer tools for
Opera and other UAs implementing the Scope API. You will be able to build integrated developer
tools into your favorite editors and IDEs. Going even further,
you can implement this into Firefox or other browsers. The possibilities are quite great: you can end-up debugging
multiple instances of Opera's, or you can debug Opera with Firefox and vice-versa, etc. Once you have a Scope server
in Opera and Firefox, as well as a Scope client for each browser, you can pick and choose at any moment the one you
like more.
The Scope API and Dragonfly also work over the network. There you go: you can debug Opera Mobile 9.5 from your Opera
desktop. You can also debug Opera instances running on your friend's computer, via Internet. If someone implements the
Scope API for Firefox, you can debug Firefox from Opera over the Internet.
That's the smart move made by Opera: now Firebug needs to play the catch-up game. Firebug will have to implement this
kind of functionality: we will need ways to debug Firefox running on mobiles, remote Gecko applications. We will also
want integration from the IDE into a running Firefox instance. Unfortunately, I'm not sure if they will simply do it:
or they will come up with yet-another protocol. That would kinda suck. If I am not mistaken some of the advanced IDEs
today already provide JS debugging, but, as far as I know, they don't directly inspect
a live instance of your browser.
Features
In Opera 9.5 beta 2 you can start Dragonfly from Tools > Advanced > Developer Tools. Opera then quickly loads
Dragonfly and caches it. Subsequent loads are from the cache - for now there's a bug which prevents proper caching,
but oh well it's alpha.
The entire Dragonfly Web application is very small given it's power and it loads really fast - they've optimized the
code as much as possible. Probably they have further performance improvements coming. On my Athlon XP 1800+, Dragonfly
doesn't feel slower than Firebug - which is very good.
You have the following tools to play with:
-
Script viewer. You can view all the scripts with syntax highlighting. Firebug doesn't have syntax highlighting.
-
Script debugger. You can set breakpoints and set into/over/out of each line of code. You can inspect
the global scope and the local execution scope. At the moment, you don't have breakpoint condition, like Firebug does.
-
Command line. You can execute any code you want in the global scope, and, while debugging, in the selected
scope from the call stack. This is really useful in many cases.
-
DOM Inspector. Here you can view the entire structure of your document as-is, live. You can inspect
the properties of each node, the computed styles, the matched style rules from your CSS
files, You can also get a nice "layout" view - based on the computed style.
-
Style sheets. Obviously, you can view each of the style files in your document, as they are available
via DOM 2 Styles. Unfortunately, just like Firebug, Dragonfly doesn't show your exact CSS file. Still, in Firebug you
can see your CSS file if you choose to edit it.
-
Console. This is supposed to be an improved console messages viewer in Dragonfly. Currently, it's still
too simplistic for my taste.
Usage tip: Even if officially you can only use Dragonfly as an external window, you can use it inside Opera as well.
Just start Dragonfly, enable the Windows panel, and then drag the Dragonfly window inside the main Opera window.
You'll make Dragonfly usable as any ordinary tab. Go to Tools > Preferences > Advanced > Tabs > Additional
options > there disable "Show close button on each tab" - to enable the MDI mode. Once you do this, you can drag and resize the Dragonfly tab inside Opera.
The bad, for now
Dragonfly is only the first alpha release - I even got Opera to crash once. The problems, sorted by importance:
-
You can't edit anything: node attributes, properties, debug variables, style sheet properties, nothing. You are
stuck. I can't complain: this is coming very soon in subsequent releases of Dragonfly.
- Search is quite buggy in Script view and it's especially unusable in the DOM inspector.
-
We don't have any HTTP headers inspection tool, no way to play with the header requests, no XmlHttpRequest logger,
no DOM Events monitor. These are promised to come soon, as well.
- No JavaScript performance profiler tool.
- No
console object for use inside our Web applications.
- The command line does not yet implement automatic complete.
Given Firebug is a much more mature Web application, when compared to Dragonfly, I can't blame Opera. Most of the
issues will be soon fixed. By then, Dragonfly will be better than the current version of Firebug.
Go ahead and try Opera 9.5 beta 2 and Dragonfly. Make sure you report all the bugs you find.
Published in:
dragonfly, firebug, opera, reviews.
6 October 2007, 17:01
Hello people!
Given the fact I'm constantly checking new Opera builds, I repeat lots
of things. I decided to write my own BASH script which does the common
work.
To better understand how the script works, and what it needs to do for me, here's an explanation of my usual testing
setup.
First, I run Ubuntu Linux. I always keep and use the latest official stable
release of Opera. I don't use the Debian package, because I want to
upgrade more often than the repos. As such, I use the official tar.gz/tar.bz2 packages: I unpack them myself and I
upgrade the files manually.
My stable Opera installation is self-contained within a single folder: ~/bin/opera. My profile is self-contained as
well, within ~/bin/opera/usersettings (the default profile folder). I don't risk using ~/.opera. This way, I can make
sure I always backup my entire Opera nicely - just the usersettings folder. That's where I keep all the Opera files,
including plugins and emails.
I keep the weeklies in a completely separate folder: ~/opera-dev/linux. Here I manually unpack tar.gz/tar.bz2
archives. The nice thing about the Opera archives is you can immediately run them, since they create their own profile
subfolders. This way I can have as many Opera "installations" running simultaneously without any problems.
By now, you can tell I have to manually move the archives I download to a predefined location where I store them.
Also, if I want to test an experimental build with my stable profile, I generally don't have time to do it. That's
because I would have to manually modify the INI files to point to the location of the experimental build, after I copy
the entire stable profile folder. That's boring. :)
As such, here's how to use the Opera2 script:
-
opera2 clean
This removes the profile of your latest Opera build. You can configure where experimental builds are located using
the
DIR_OP_DEV variable.
-
opera2 clean-run
The same as above, but Opera will be started afterwards.
-
opera2 unpack opera-*.tar.bz2/gz
This unpacks the Opera build you want designated by the second argument. The build must be provided as a tar.gz or
tar.bz2 file - as the official ones are. The package will moved to the configured
DIR_OP_PACK, and the content of the archive will be extracted to your DIR_OP_DEV.
-
opera2 unpack-run opera-*.tar.bz2/gz
The same as above, but the script will also start Opera from the extracted folder.
-
opera2 upgrade opera-*
This will "upgrade" the Opera build you want designated by the second argument - a folder name starting with
"opera-" followed by the major and minor version (this is the default naming of Opera builds). If the second
argument is not specified, the current working directory will be used.
The script will copy files from your stable profile folder (defined by DIR_OP_STABLE) to the profile of
the build you specified. The script will also make some changes to several copied files (will replace all paths
pointing to the stable Opera installation folder to the new build).
Warning: Doing this will DELETE the profile of the target Opera build. The script does NOT try to detect if the
destination folder is REALLY an experimental build. Do NOT run this on your Opera stable installation folder.
-
opera2 any thing else (or no arguments)
This will start the latest Opera build from the configured
DIR_OP_DEV with the provided arguments. You can configure other applications to automatically open links
with this script - the latest Opera build.
You should check the script source ... to be sure it will not break your stable installation. :) Always check the
result of running this script before starting Opera.
As you can see, the script is tailored to my needs. Care should be taken when using the script. I am sure it does not
work if your stable installation is configured with "exotic" file paths. The script was only tested with Opera 9.x
builds, on Ubuntu 7.04.
Download the Opera2 script.
Published in:
linux, opera, scripts, ubuntu.
4 September 2007, 18:13
Opera 9.5 Alpha 1 (code named Kestrel) has been released today.
For all web developers who haven't yet checked Kestrel, go ahead and do it. There are many improvements, and lots of
new stuff.
I personally like the performance improvements - see some benchmarks done by NonTroppo.
One of the new features I am looking forward to use daily is history search. I had this in my wishlist for Opera 10. :)
Opera Mail has been improved very much, but lots of work is only under the hood - not many visible changes.
Nonetheless, these are very interesting changes, since I use the Opera Mail client from Merlin. Anyone who uses Opera
Mail long enough knows the famous freezes.
New features for web developers range from fixes to Web Forms 2 support, to new HTML 5-related work, new CSS 3
selectors and properties.
The completely revamped keyboard shortcuts will annoy many
Opera users, but it's all for the better, in my opinion. New users who will try Kestrel, will like it more now, will find
it more comfortable in general usage.
Check out the change logs, and backup your Opera profile -
it's best you pick a separate installation folder.
Related to my site, the current Opera Kestrel build works quite well - dare I say better than Merlin. The Windows
build has some issues with redrawing the menus, and with the generated content text color. Besides that, no access
keys are recognized (try
Shift-Esc).
I recommend you to try the site with Kestrel. You can play with the Web Forms 2 auto-complete in the search fields
with no JavaScript enabled. Also, you'll see lots of fancy text shadows. If you have a slow computer, you'll notice
Kestrel is much faster than Merlin when you use the search fields (with JavaScript enabled). The new ECMAScript engine
is really faster. However, I still find hovering the menus slow on Kestrel. :(
Something less obvious to average users is the improved spatial navigation. There's something I am particularly
impressed: try
Shift+Arrow keys to navigate this web site. You'll immediately notice you can navigate the sub menus, which
normally you cannot do (not in older Opera versions, nor in Firefox). Kestrel actually sends the mouse events to the elements,
as if you use the mouse to hover the elements. This opens up a whole "new world" to those who use the keyboard very much.
Say "bye bye" to the supposed inaccessibility of my site navigation (haha). :)
All in all, Kestrel is going to be a great release. I am looking forward to switch to the new version, when the stable
one is released.
Published in:
kestrel, opera, reviews.
1 November 2006, 16:27
Hello guys!
Today Opera Software has released a new site: The Opera Developer community site.
The purpose is great, and I like major web browsers having their own developer community sites.
As the title of this post announces ... the site already had published my first tutorial :). If you've read my
previous blog posts, it's not a big surprise my first tutorial is about voice interactivity. Currently, very few know
about VoiceXML, and there are very few tutorials. Most of them reach only the level of "Hello world". Therefore, my
tutorial goes much further, by actually telling you how to put voice to use in your site. I didn't write yet-another
tutorial about AJAX, XHTML, CSS, DOM, or JavaScript. I wanted something different.
Go ahead and read the tutorial from dev.opera or from
my own server (mirror).
Thanks very much to TarquinWJ and Jax. The tutorial has reached the level of maturity you are seeing thanks to both of them. :)
Any suggestions or comments are welcome.
Published in:
opera, tutorials, voicexml.
14 July 2006, 17:16
Hello!
Did you know you can enable logging in Opera Chat? It works with Opera 8 and 9. Perhaps with Opera 7 too (I am not
sure).
To enable logging for Opera Chat edit your
mail/accounts.ini file and add/change:
Incoming Log File=c:\path\to\your_file.log
... for the [account] you want.
The generated log is debug mode, almost unreadable by humans. Plus, it's a single file: no separate files for private
messages or channels.
Because of this I have made script that parses the log and generates human readable files.
One tiny problem: Opera does not include the log start/end date (only the time), which forces me to guess the log
date. Log date guessing works by catching all UNIX timestamps sent by the IRC server, user signon, topic date, etc.
The script creates files for private chats, channels and one
$server file
For one file of 166.4 MB on AMD Duron 1.3ghz 512MB RAM with 7200 RPM HDD running Ubuntu 6.06 Linux, PHP 5.1.2 ...
parsing took about 5 minutes. The script generated 135 files (12.3 MB). Average speed: 502 KB/s.
For this release I have optimized the code for better speed, initially this script was 3 times slower.
The script was tested on irc.opera.com and irc.freenode.net.
The output is text, not HTML.
Generally the script should run fine, but you can easily brake it. If you improve the script please send the updated
file to me.
You need only PHP, nothing else. It probably works with PHP 4 too (I only tested with PHP 5.1).
Download the script.
Rename the file to .php. Uploaded as .txt to avoid conflicts.
Thanks and let me know if you find this useful. Any comments suggestions are welcome!
Published in:
irc, opera, scripts.
22 June 2006, 09:53
Another article in Romanian, introducing voice interactivity on the web for new users (not developers!).
Interactivitatea vocală este o suită de standarde web ce permit dezvoltatorilor web să adauge comenzi vocale în
siteuri. În funcţie de capabilităţile siteului, utilizatorul poate să facă absolut tot ce poate cu mouse-ul şi cu
tastatura.
Important de ştiut despre interactivitatea vocală este că un dezvoltator web nu implementează el algoritmii de
recunoaştere vocală şi nici de sintetizare vocală, ei doar programează regulile de recunoaştere vocală şi oferă textul
pentru sintetizare. Adică ... ei asociază, de exemplu, pronunţarea cuvântului "Help" cu o pagină. Bineînţeles că
regulile de recunoaştere vocală pot să fie mult mai avansate, ajungând chiar la recunoaşterea frazelor pronunţate.
Dezvoltatorul web depinde de implementarea navigatorului web (capabilităţile de recunoaştere şi calitatea
sintetizării). Deşi pare "neplăcut" este defapt un avantaj pentru dezvoltatori şi utilizatori. Asta deoarece
utilizatorul nu va auzi pe fiecare site o altă voce şi recunoaşterea vovală va fi întotdeauna la fel de bună. Pentru
dezvoltatori este avantajos din punct de vedere practic: cum ar fi să-şi programeze ei afişarea paginilor web la ora
actuală? În primul rând nu se oferă tehnologiile necesare (adică destul de avansate) pentru a putea face implementări
la standarde web în site-uri.
Pentru a începe să foloseşti interactivitatea vocală pe site-uri este necesar să foloseşti un navigator web ce
implementează aceste tehnologii foarte noi, să ai un microfon bun, placă de sunet şi boxe. Singurul navigator cu aşa
ceva disponibil pentru toţi, la ora actuală, este Opera 9 pentru Windows. Acesta se descarcă de pe
www.opera.com. Se instalează în mod normal. După pornire trebuie activată
capabilitatea de interactivitate vocală: mergi la Tools > Preferences > Advanced > Voice.
Acolo trebuie bifată opţiunea "Enable voice-controlled browsing". Acum Opera va descărca fişierele
necesare.
După cum se observă totul este în limba engleză pentru că Opera Software are momentan implementarea realizată în
parteneriat cu IBM şi ceea ce le-a fost oferit este doar pentru limba engleză, pe Windows.
După descărcare se pot introduce comenzi vocale: trebuie doar tastat Scroll Lock (în funcţie de setările de la Voice Preferences). Pentru a controla navigatorul Opera comenzile încep cu "Opera". De exemplu, "Opera quit", "Opera previous page", "Opera go to home page" şi altele. Pentru mai multe comenzi, uită-te la comenzile vocale
disponibile în documentaţie (tastează F1).
Pentru a cere navigatorului Opera să-ţi sintetizeze vocal textul de pe pagină trebuie doar să-l selectezi şi să
tastezi V sau să dai click dreapta de unde alegi "Speak selection".
Site-uri cu interactivitate vocală sunt foarte puţine. Dacă doreşti să testezi un site cu aşa ceva, intră pe www.robodesign.ro/pronet. Acolo trebuie să treci site-ul la limba engleză (click pe legătura "English" care se găseşte sub bara de navigare a
site-ului, în dreapta). Comenzile vocale disponibile pe prima pagină sunt:
- visit nume-pagină (de exemplu "visit offers", "visit support", "visit contact"
- speak navigation
- speak content
- help
- change language (pe prima pagină)
- news 1, news 2 ... până la 10 (pe prima pagină)
Pentru a testa şi alte comenzi vocale, poţi folosi modulul de administrare al site-ului: www.robodesign.ro/pronet/admin. Acolo poţi adăuga pagini noi ale căror titlu trebuie să-l spui atunci când doreşti să intrii pe pagină folosind o
comandă vocală. Astfel poţi observa cum funcţionează (mai ales dacă te vei uita prin surse).
Utilitatea acestor tehnologii web este evidentă în cazul utilizatorilor cu handicap.
Interesant este de urmărit evoluţia acestor tehnologii web pe viitor.
Published in:
opera, romanian, voicexml.
15 April 2006, 13:19
Hello!
Even if I am not a ((very) big) fan of the whole widgets idea, I saw the usefulness in using them for various quick
info. Such as weather and news aggregation.
There are too many per-site widgets, and weather widgets.
The new Widgets competition organized by Opera motivated
me to make this widget :) - who wouldn't want that PC? Therefore, I present you the Raggregator version 1. :D
Features:
- support for RSS 2.0 and Atom 1 feeds.
-
I don't currently have support for all the 9 incompatible RSS versions.
- unlimited number of feeds.
- minimize any feed you want.
-
few settings can be changed in the widget (if you edit js/settings.js): number of maximum entries per feed, entry
summary length, default feeds, and scroll speed.
-
easy internationalization. *All* strings are in js/messages.js. Any new translations will be gladly posted. I won't
currently add the Romanian translation, I want to first finish the second version of the widget.
I have many new features planned for the second version:
- better support for more feed versions and formats (maybe not only RSS/Atom).
-
the ability to show detailed information for each entry and each feed (beyond the "what's new at a glance").
Something like a ... full-featured feed aggregator: satisfying all my news feed aggregation needs.
- the "minimal mode" which will act like a news ticker (scrolling the title of the feed entries).
-
per-feed settings: auto-update interval, number of entries to show, hide visited entries, hide in news ticker.
-
maybe grouped entries, acting similar to Planet Planet. This would allow
the user to make a single group in which they can add as many feeds as they want. All the feed entries would then be
sorted by date, showing *all* of them as one. This is something I'd prefer in many cases.
-
maybe title editing for each group, for each feed, so you can change the title provided by the author of the feed.
- some display settings, like show dates on/off, show summaries, colours, themes, font size, etc.
- the ability to reorder the feeds (move up/down).
- and more...
Based on the above ideas I want to have some really important structure changes. I want the widget to be *the*
aggregator. :)
After finishing the second widget version ... I might make a site-version, not just a widget (something like the JavaScript RSS/Atom parser by TarquinWJ). I won't keep it Opera-only, *but* I won't do *any*
compatibility-related changes. I'll just stick to the web standards (if Firefox doesn't support them, sorry). Internet
Explorer is, without doubt, out of the discussion.
Have fun using the current version. I hope I'll have time to make the second version - the above ain't guaranteed. :P
Download the file: raggregator.zip.
I have submitted the widget to the competition today, in the very last minutes. Yes, I've been very busy: I worked on
this widget only in the last couple of days.
The experience of making the widget was really interesting. Too bad there's no support for alert, confirm and prompt
within widgets. I also found a bug: crash when using mouse gestures (in the latest weekly build). The bug seems to
affect any widget and any page. One another, more serious, annoyance is in widgets you can't use the title attribute
for any element to show a nice tooltip. Do we have to write our own tooltip scripts for anything simple?
Good luck to all participants in the competition.
P.S. All coding is done only by me. All design is done only by my twin brother.
Update (2006/05/03): To err is human. I was claiming this widget has support for Atom 2 feeds. There's
no Atom 2. There's only Atom 1. Sorry guys.
I don't know how I made this mistake, because I always knew there's only Atom 1.
I found out about this mistake only now because M. David Peterson from atom-syntax mailing list published a message asking Opera staff to fix
the description of my widget.
I have contacted Gautam Chandna (from My Opera staff) and he has fixed
the description (the widget file is OK, no need for updating).
For those wondering if I won the competition: no, I didn't.
Published in:
opera, projects, widgets.
9 December 2005, 17:02
Hello!
I'm bored :) so here I am writing about the
latest buzz.
I read few days ago about some innovation available only in the latest Thunderbird trunk builds: tabs.
Brilliant idea to have tabs in mail clients to. Wow !!! :)
All would be rosy if people wouldn't forget that Opera M2 (the mail client) takes tabs for granted. It was born with
tabs. If you don't believe me, try double-clicking an email. Among allowing you to view multiple emails open in
different tabs, you can also have multiple views/folders opened.
Same goes for spatial navigation.
Now that's cool. Wonder when they will invent the awesome feature of viewing multiple folders at once
in various tabs.
Opera should better advertise these awesome, but, yet-to-be-invented features: voice interaction, BitTorrent support,
MDI, fit to window width, sessions, page zoom, mouse gestures, and some more.
P.S. To fellow Mozillators: I believe Thunderbird is a bit more mature as an email client, compared to Opera M2, not
only based on features, also on the way it's made (a very fine product, like Firefox). Yet, I have to add Opera M2 is
not just a little toy.
My short opinion is ... Firefox and Thunderbird should not play the catch-up game with Outlook and IE (and Opera),
because that's what Microsoft wants everybody to do. Instead, Mozilla Corp. should
pave its own way, with its own unique and innovative features. This is another blog post to post-pone until I am bored
enough to write about. :)
Published in:
email, opera, thunderbird.
4 November 2005, 09:28
Hello!
Yesterday I had to install Windows 98 on a really slow computer by "today's standards", a Pentium I, with only 32 MB.
The computer is a bit unstable. During system installation had some BSODs (probably corrupted RAM and/or damaged
mother board).
This guy will have a broadband Internet connection.
As a browser, I, of course, excluded Internet Explorer as an option.
I got Opera 8.5 with all settings to the minimum (no skin, no smooth zoom, no smooth scrolling, no special effects,
nothing). Booted and worked really fast, loved it ;). I wasn't expecting that. Yet, it causes BSODs on Opera's own site and some other sites (told you the computer is unstable!).
Now, I had to give Firefox 1.0 a try, hoping it's not slower and won't cause as many BSODs
as Opera.
Yet, yesterday I finally saw for the first time the true speed difference in start-up times between Opera and Firefox.
Starting Opera takes less than 3 seconds ... yet with Firefox ... you wait and wait more :), from double to triple
more time. Page rendering, scrolling and overall browser usage is also slower (menus, preferences, etc).
Sadly, there's nothing to configure in Firefox to really make it faster. Also, Firefox crashed on few starts and on
some sites (like mine).
Conclusions:
-
Firefox is not more stable than Opera (nor vice-versa). The stability issues have been caused by the hardware.
- Opera is a lot faster. Really usable on such a slow computer.
The only problem of Opera is PNG rendering. On my site Firefox was a tad faster :).
I actually managed to browse my site with Opera ... but Firefox crashed :).
P.S. This is not an "Opera fan rant". It's clear to me now which browser is faster: Opera. Those who really want to
know which browser is faster got to try them with a really slow computer.
Published in:
firefox, opera, performance.
29 October 2005, 13:19
Hello!
Today I've finished my first UserJS for Opera 8+.
I named it ROBO Sticky
(no good inspiration for a better name). To download, install and learn more about it, visit its "official" page.
The script is based on "Sticky-notes" by Antonio Orlando. I simply didn't like his source code. :) It adds a lot of "noise" in the DOM and I don't wonder why some people
already reported it breaks Gmail.
My UserJS is almost an entire rewrite only for Opera, but it can be made to work on Firefox. Along the way I've made a
lot of improvements, too many to list (bug fixes and nice behavior improvements).
Published in:
opera, projects, userjs.
