Skip navigation.

Posts tagged with "linux"

ion3

, , ,

2002-02-07 - Last release of Ion1 (it never had ds/rc/stable)
2004-02-07 - First "stable" release of Ion2
2008-02-07 - First "stable" release of Ion3
2016-02-07 - ?



Tuomo today laconically announced the release of the stable version of the tabbed tiling window manager ion3. Congrats!

linux: opera, flash and plugins

, , ,

Adobe released a new version of Flash Player - and triumphantly announces that "this new XEmbed-enabled plugin should work with Opera now."

We achieved great things in tight work with the Flash team - but here they seem to have mixed something up :smile:

The new Flash version, as mentioned already earlier, does not require XEmbed to run, but a GTK browser - there unfortunately still seems to be confusion about XEmbed and the XEmbed Mozilla extension "spec", which actually has little to do with XEmbed. So much about "standards"…

Obviously, a plugin expecting to run in a GTK browser does not work out-of-the-box in non-GTK browsers… The new Flash plugin is not compatible with the current Opera and Konqueror versions. This means, to put it in simple terms, that Adobe leaves at least 26% of the Linux users (just summing up Konqueror and Opera users) in the dark, forcing them to stick to the old version.

We just released a UNIX plugin milestone snapshot of the upcoming Opera version, allowing not only to run a GTK plugin in a Qt browser, but even going as far as using GTK "to draw directly on the webpage of a Qt browser": Opera and Mozilla are now ready for windowless plugins. Only the plugins are missing now :wink:

The new GTK Flash Plugin does run out-of-the-box in the latest 9.50 snapshot.

32-bit plugins in 64-bit opera

, , ,

I see repeatedly comments that people run 32-bit plugins in 64-bit Opera by using the nspluginwrapper. This wrapper "enables you to use plugins on platforms they were not built for".

However in Opera, as opposed to other browsers, there is no need to go through the hassel of installing an extra plugin wrapper to do that - the operapluginwrapper handles it just fine!

The only issue is that you need to be using the 32-bit operapluginwrapper in a 64-bit Opera to run 32-bit plugins. Currently the only way to do so is to download a 32-bit Opera (I'd reccomend downloading a tarball), extract it, and replace the installed (64-bit) wrapper with the operapluginwrapper from the 32-bit package - and voilà, all 32-bit plugins should work out-of-the-box.

Currently this is manual work (sorry for that), but we are looking into having this handled at installation time - and have a way of seamlessly dealing with both 32-bit and 64-bit plugins (since you'll need the 64-bit wrapper for the 64-bit plugins…).

which is which?

, , , ...

Right - we have "UNIX" builds for desktop Opera.

And even though it isn't a really correct label for this family of builds, it means builds for Linux, FreeBSD and Solaris, for the Intel, the PowerPC and the Sparc architecture, for 32-bit and for 64-bit architectures, each one in several builds, and each build in several packages. In short: a jungle.

Additionally, there have been some new builds in Kestrel Alpha 1.

So which exactly is the package you need to fetch? This depends on the operating system, the OS version, the architecture, etc. Let me provide you with a short summary on which build is exactly what.


Linux
intel-linux
  • .1 static - qt3 static build, gcc 2.95
  • .5 shared - qt3 shared build, gcc 3
  • .6 shared - qt3 shared build, gcc 4
  • .9 static - qt4 static build, gcc 4
There is an experimental .10 build at the moment, which is a qt3 static build, gcc 4.

ppc-linux
  • .1 static - qt3 static build, gcc 2.95
  • .3 shared - qt3 shared build, gcc 3
  • .6 shared - qt3 shared build, gcc 4

sparc-linux
  • .1 static - qt3 static build, gcc 2.95
  • .2 shared - qt3 shared build, gcc 2.95

x86_64-linux
  • .2 shared - qt3 shared build, gcc 4


FreeBSD
intel-freebsd
  • .1 static - qt3 static build, FreeBSD 4
  • .5 static - qt3 static build, FreeBSD 5
  • .3 shared - qt3 shared build, FreeBSD 5
  • .4 shared - qt3 shared build, FreeBSD 6
  • .7 shared - qt3 shared build, FreeBSD 7

amd64-freebsd
  • .1 shared - qt3 shared build, FreeBSD 6


Solaris
intel-solaris
  • .1 static - qt3 static build, Solaris 10

sparc-solaris
  • .1 static - qt3 static build, Solaris 8
  • .2 shared - qt3 shared build, Solaris 8
Note that the Solaris 8 builds will also work on higher versions of Solaris.


So what?

On Linux there is the additional complication to understand which build you'll need for which version of your distro. It would be far too long to give a full overview on that, but here are some hints for some major distros:

You'll need the Linux .6 build for:
  • Debian Etch, Sid and Lenny
  • Ubuntu Edgy and Feisty
  • Fedora Core 5, 6 and 7
  • openSUSE 10.x
  • Slackware 11.0 and 12.0


You'll need the Linux .5 build for:
  • Debian Sarge
  • Linspire 5.0 and 5.1
  • Skolelinux 2.0
  • Xandros


I'll assume that FreeBSD and Solaris users are smart enough to figure out which builds they need for their OS version :wink:

HtH :smile:

qt4

, , ,

Opera 9.5 now offers also experimental static Qt4 builds on intel-linux - you do not need Qt4 to be installed in order to use them. Just fetch the intel-linux .9 package, select the Qt Native skin in Tools > appearance > skin and then try

$ opera -style plastique


to see Opera using the Qt plastique style. If you have more nostalgic inclinations, try either of

$ opera -style motif
$ opera -style cde
$ opera -style windows


Looking for GTK integration instead? Try

$ opera -style cleanlooks


But be warned - there are several known issues: cleanlooks for one takes ages to startup! there are a few crashers here and there, and the speeddial configuration dialog has some *cough* issues…

Have fun - and as always, feedback is welcome! :smile:

kestrel and plug-ins

, , ,

Kestrel is finally out!

Among the many new features, there are huge improvements to plug-ins on UNIX: we implemented the GTK main loop, which will allow GTK-based plug-ins to work - like the new Flash 9 Beta 2, mplayerplug-in, and many more! No need anymore to recompile mplayerplug-in again, you should now be able to just use the one that comes with your distro.

There'll be more details following, but in the meantime feel free to give it a try - go download Kestrel!

diamondx

, , , ...

A picture is worth more than a thousand words - see DiamondX in Opera:smile:

what about flash?

, , , ...

People are starting to wonder about the newest Flash Player plug-in not working in Opera. Just a quick update to this:

The new Flash plug-in is not implementing XEmbed, but the XEmbed Mozilla extension "spec" (well, it isn't really a spec) - it is actually a GTK plug-in trying to run its GTK main loop in the Opera (Xt) pluginwrapper: obviously this will not work :wink: The new Flash plug-in is not backwards compatible - it is not working in current versions of Konqueror and Opera, but only in Firefox.

We are looking into it. Stay tuned :smile:

defaults

, , , ...

I have been asked more than once how Opera on UNIX systems decides which applications are handling which MIME types, and which one of these is chosen as the default handler. Let me start off by saying that this is a jungle: each system, each desktop environment, and possibly each version of the environment handle it in some more or less subtly different way. Freedesktop.org has made some attempts at unifying the system of defaults, and has come some way to deciding how to allow applications to declare which MIME types they can handle - but when it came to define the defaults, unfortunately they could not yet agree. It is work in progress, and managing to have a spec for this will make things much more easy. For the time being we are parsing MIME type handlers, not protocols.


Default handlers

Opera checks the following files to find the default handlers. The XDG_DATA_DIRS environment variable tells us where to find most of those files. Typically in /usr/share/mime/ are

aliases
specifies MIME type strings that are aliases to each other;
globs
aid file for guessing MIME type based on the filename;
subclasses
defines a MIME type to be a subtype of another one, so that any handler of the supertype is also a handler for this type;
application/*.xml
XML file to describe a MIME type;

and we also parse:

mimeinfo.cache
maps MIME types to applications with no specific preference;
defaults.list
GNOME file to specify defaults;
*.desktop
desktop files are available for both applications and MIME types;
mailcap
a configuration file to map MIME types to handlers.

The upcoming kestrel version has improved handling of above resources, and will also handle:

gnome-vfs.applications
lists applications and the MIME types each one supports
kderc
provides among other things the path where to find the KDE settings (typically /etc/kderc)
~/.kde/share/config/profilerc
User specific KDE mapping of MIME types to application (and defaults)

We also parse the index.theme file to make everything look much more pretty :smile:

multi-window

, , , ...

I work in multiple client frames on several virtual desktops. My main Opera instance is running in one frame, but often I do have URLs in other frames that I want to see in Opera, as for exmaple in the frame irssi is running in, or in any other terminal I might be reading some documentation in. It is tedious to switch back and forth the various virtual desktops to reach the main Opera instance and Paste and go to the new URL. I have rather Opera coming to me - but starting Opera each time I quickly just want to look at something is no fun… (Opera's startup time isn't know to be the fastest, if you have mail and feeds in your Opera as well)

So I always only deal with opera -newwindow and have that opening a new window of the currently running instance on my virtual desktop: applications that need a browser to view documentation or help get that command, irssi has an alias that allows me to open it directly from within the irssi session, bash has an appropriate alias…

My emacs keyboard bindings for Opera also have the Ctrl-x k binding to easily close the current window.

et voilà, I have an Opera window readily available wherever I am working, without having to give up my huge sessions, and without having to wait for Opera to start up.


Note: make sure not to close a window with several tabs in it if you want to have them part of your session: currently there is unfortunately no way of restoring an accidentally closed window (accidentally closed tabs are easily re-opened), but, pssst, this is fixed in Kestrel.

Yet another note: Emacs will have multi-tty support in the next-but-one version (23). The multi-tty branch has just been merged to the Savannah CVS repository.
November 2009
S M T W T F S
October 2009December 2009
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30