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.
