Ruarí's thoughts

Anonymous writes: how about KDE? :)

Good stuff. Thankfully, i run a dual boot system with Vista and OpenSuse 11.2. So i can test Opera 10.5 goodness in Vista and wait till a Linux build is out

Patience... patience...

Do you have any ideas about when it will be released? At least a guess ... it will be today? It will be days? Weeks? Next year?

That looks very nice, thanks! What about the performance of the UI?

I was putting my hopes to HW rendering through VEGA in Linux, because Opera's UI on Linux is not of the snappiest ones. Software rendering of VEGA is pretty damn fast on Windows, so I hope it will cut in Linux too. Any comments?

The Linux crowd will go all bonkers over this. It looks great Ruario.

yeah i'm waiting for linux version but I hope it will be stable then this windows pre-release

I see you guys broke the systray icon again

bizux writes: Finally the best browser on GTK :D :D

Terje writes: The third screenshot with Gtk native styling looks very nice. So Opera will in fact be able to use my currently selected Gtk theme in eg Gnome or Xfce and likewise for kde? You say "builds that have Gtk Native styling enabled". Does this indicate that Opera will provide different builds for Gtk and Kde styling?

The mac version has Growl support, does this mean we, KDE users, will get KNotify support (which probably is going to be a freedesktop.org standard)? That would be soooo awesome

Actually, from the looks of it it is not GTK at all. I can tell by the pixels. It’s an imitation and it looks eerily close to what the Qgtkstyle produces.

In what way did you remove Qt again? Did you port their engine somehow?

BTW, what bugs me most, and I’m seriously tempted to switch to chromium because of this:

1. Can’t click in embedded Flash
2. Terrible scrolling speed on Intel graphics. Chromium is like butter (e.g. Gmail)

1. Okay, you can cross that one out, I found your earlier blog that helped.

Originally posted by ruario:

Actually, from the looks of it it is not GTK at all. I can tell by the pixels.

Ummm ... care to clarify?

It looks like a faux GTK.

- GTK doesn’t allow that dotted focus box inside a dropdown box.
- The notebook line looks not like Clearlooks. The tabs are not overlapping like Clearlooks.
- The edit field is odd and not properly embedded. No RGBA or something?
- The default button with the outline looks like it has been drawn twice. Clearlooks looks different and nicer.

- Overall spacing is identical with the way Opera has done it with Quick for many years. This type of layout is not doable with GTK itself. (cf: normal GTK dialogs)

I would say this is somehow derived from Qgtkstyle. Because it looks just like Qt Native with "-style gtk".

BTW, I made this skin. I know every pixel in Clearlooks:
http://my.opera.com/community/customize/skins/info/?id=3465

I’m not exactly complaining that this will not give us actual GTK dialogs. I think I was just thrown off by your formulation “Gtk Native styling”. It’s an imitation and not native. The emperor just has a new skin. Err ... or so.

@towolf: Opera is not built with GTK, not now and not in the future. It uses its own toolkit (Quick). In Peregrine on Linux, that toolkit draws using Qt (but doesn't use it for a lot of other things); In Evenes, it only uses X11 drawing primitives.

However, if it's available, Evenes will load GTK and paint widget elements with it. Of course that doesn't make it a GTK application, and it still has to live within the rules of our toolkit. This is similar to how for example Firefox, OpenOffice and the Qt GTK skin engine work. Similarly, on Mac and Windows, we use their native toolkits to paint quick's widget elements.

You should also know that the screenshot Ruari posted is a work in progress - one of the reasons that you don't have a Unix build yet - , and there are known issues at the moment. Those include the issues you mentioned (except for spacing, which will not change any time soon since it is currently a limitation of our toolkit).

And as to being an 'imitation': the elements are drawn with GTK, using GTK. There's no 'imitation' here, they are drawn natively by your native toolkit, be it GTK or Qt.

Thanks, very informative, Arjan. That explanation makes sense to me and I do get the point how this can be called “Native” now.

Maybe it’s just me, but I’m not very fond of OpenOffice and Firefox either, for precisely the same reason. Actually OpenOffice I find so bad, I rarely use it. It seems hacky.

Luckily Opera has very many other strong points to make up for this and me stick around. Mostly the user interaction, keyboard controls, etc.

An EDIT. To end on a lighter note, I very much look forward to a spiffier experience. Cutting out the abstraction must do good things to performance. Take your time to do it right. But first of all enjoy the holidays.

I like it.

I'm ok with it not being "truly" gtk. Firefox really is XUL faking gtk, so it does it well enough that few really complain about it. I'm assuming Opera's toolkit will do something similiar, but workable on both gtk and qt.

If qt4 is installed, will opera ignore it or does qt4 have to be uninstalled from the system? I have one application that needs it. Running xfce with xubuntu 9.10.

You get on posting KDE screencaps, Ruario

I'm more than a bit worried, as every attempt to do the cross-DE toolkit dealio has usually only succeeded on one DE or the other. Firefox and XULRunner for instance, does a great job faking GTk, but on KDE looks awful. OpenOffice does a slightly better job in KDE, but it don't look like a KDE/Qt app either.

Originally posted by ruario:

It won't cause any problem if it is present.

Thanks, that's good to know.

Well-well!
Hope Opera would be able to pick up Qt4 (KDEless) themes.

Waiting for Linux build (-:E

Very nice job that Quick toolkit does, integrating into the DE's look and feel. Good job, Opera.
I'll try getting EDE up and running, in time for the *nix 10.5 release and see how Opera looks in it.
Cheers.

operapup writes: "Known issues: - Slow performance on processors without SSE2 - High memory usage - No Linux build" Are these issues going to be fixed in the upcoming Linux snapshot(s)? Just think of the masses of 'poor' people using Linux. The majority of Linux users are using older PCs (mainly AthlonXP CPUs which lack SSE2 support) and Opera is the only browser that performs *great* on those systems. The browsing speed / snappiness under Linux is even better than what you get under Windows XP. Opera is becoming more and more popular among users of lightweight Linux distros. Firefox is too heavy and uses a lot of RAM, Chrome is full of security holes and lacks a lot of features, SeaMonkey is too buggy and other browsers are out of the league. Opera 10.5 will revolutionize the browsing experience on Linux: The removal of the Qt dependencies and 'native' GTK theming is just what the Linux distros needed. Opera can finally become a part of many lightweight Linux distributions. Bye-bye SeaMonkey and Firefox, say hello to Opera :)

Anonymous writes: What about other toolkits, i.e. FOX? Do I understand this correctly, if I don't have either of GTK or QT, it falls back to plain X? thanks for your work, very very much appreciated :)

Anonymous Coward writes: What's a FOX? Btw, this build is *beautiful*. I'm looking forward to a unix release.

Anonymous Coward writes: Also (before I forget), how should I go about bugging your designers to respect Fitt's law in regard to tabs-on-top-bar design?

Аноним writes: What's wrong with Qt? It's the best library ever was!

I don't see big benefits in removing the Qt dependencies.

Why did you guys make such a big effort to port Opera to Qt4 when dumping it anyway in the next version?
Or may that pain of porting be the reason for dumping Qt?

I would be very interested what the downsides of Qt are for a big software project like Opera with several million installations.

Originally posted by Haegar15:

I don't see big benefits in removing the Qt dependencies.

Why did you guys make such a big effort to port Opera to Qt4 when dumping it anyway in the next version?
Or may that pain of porting be the reason for dumping Qt?

I would be very interested what the downsides of Qt are for a big software project like Opera with several million installations.

My guess, is that part of it is that Qt release keep getting put out...and Opera no sooner gets ported to Qt4.x than Qt4.x+1 comes out...and Opera again looks unlike other apps. My Opera is using Qt4.5.3-and it still doesn't look like all the other Qt apps on my box.

Originally posted by Haegar15:

I would be very interested what the downsides of Qt are for a big software project like Opera with several million installations.

I think you are asking the wrong question; the reason we are dropping Qt is not that there are major downsides, but more that there are very few upsides to using it in our very specific corner of the software market.

The main advantages of Qt are its strength as a UI toolkit and the possibility of deploying the same code across multiple platforms.

But Opera already uses its own cross-platform UI toolkit, with underlying backends written for our different platforms, and our own cross-platform APIs for functionality needed by our browser core, such as networking, file writing/reading, etc. (this is the reason that Opera can use the same core code on basically any device it runs on).

For our Unix builds, the underlying backend implementation used to be implemented with Qt (Windows and Mac use Win32 and Cocoa, respectively). Since we don't use any of the UI toolkit functions of Qt, the usage was basically limited to being a glorified canvas for drawing primitives. This is a task that can very adequately be handled by X11.

Then there's native integration. Contrary to what one might think, integration with the main desktop environments and toolkits on *nix (Gnome/GTK and KDE/Qt) is easier for us without Qt than with.

For GTK integration this is kind of obvious. Qt only got in our way before, and now that it's gone, we have the possibility to integrate natively with GTK's widgets, some of its dialogs, and maybe other features in the future. This will help Opera fit in better in what is the default environment for most of the Linux users. It also means that Opera users don't have to download a library that they might otherwise have no use for.

For KDE/Qt integration, we don't miss anything by not relying on Qt directly. In fact, now that we have the possibility of doing everything without Qt, we also have more freedom in integrating with KDE. While GTK and its associated libraries provides a complete toolkit for 'gnome-like' applications, Qt doesn't quite fulfill the same role in KDE; there's kdelibs, the layer in between that all KDE applications use, and that we previously didn't want to depend on, since it would create even more dependencies for users who were not running KDE. Now that we have a base implementation that always can be used, we can use kdelibs to integrate with KDE where possible.

Having said all of this, this is in no way saying that if you start your own software project you should go the same way. The reason Opera is in this situation is that our core product, a cross-platform rendering engine for web sites and web applications, contains much of the functionality that a UI toolkit would otherwise provide. I wouldn't think it's a good idea to start implementing all of that yourself when starting any other software project, so you would be best off using an off-the-shelf solution, such as Qt or GTK. And in that case, I'd say Qt is certainly a very nice toolkit.

Originally posted by AVL:

For KDE/Qt integration, we don't miss anything by not relying on Qt directly. In fact, now that we have the possibility of doing everything without Qt, we also have more freedom in integrating with KDE. While GTK and its associated libraries provides a complete toolkit for 'gnome-like' applications, Qt doesn't quite fulfill the same role in KDE; there's kdelibs, the layer in between that all KDE applications use, and that we previously didn't want to depend on, since it would create even more dependencies for users who were not running KDE. Now that we have a base implementation that always can be used, we can use kdelibs to integrate with KDE where possible.

This is not quite true anymore since qt4.6 which can use some kde stuff (and even gtk stuff) when present, else fall back on qt but I do prefer Opera being drawn by one toolkit instead of two because I could never get Opera to look right in all parts, some bits of Opera always looked distinctly different from other parts of Opera...

@towolf,

- GTK doesn’t allow that dotted focus box inside a dropdown box.

dotted focus boxes should be banned period...they are so ugly and so 1990... (this goes even more so for gtk's even uglier disabled widget representation (although it looks good in some themes like murrine))

Dag writes: I really miss an "inspect element" button, and "view selected source". Is this hard for you to implement? That said, you guys make me proud :)

Anonim writes: 10.5 will be ready in month or few months? It will be before march?

Thank you!

/me was one asking for a GTK version since 6.05

What if I don't run a DE (neither KDE nor Gnome nor anything else)? What will Opera decide is the "native look"? I have both GTK and QT libs installed.

What seems to happen on 10.10 is that the skin decides what just about all of the GUI widgets look like, which is great as far as I'm concerned.

I'm not using gnome or kde, I hope I won't have to deal with gtk's file saving dialog.

GTK in opera!

Originally posted by jpkotta:

What if I don't run a DE (neither KDE nor Gnome nor anything else)? What will Opera decide is the "native look"? I have both GTK and QT libs installed.

Opera will try to load GTK by default in that case. There is a preference that you can use to force KDE/Qt or to force the 'bare' X11 look. You can always use a third-party skin (or Opera's own, older skin) if you don't like the elements to look native - it is up to the skin designer to decide which elements should be drawn natively and which ones should be skinned.

Originally posted by AVL:

Opera will try to load GTK by default in that case. There is a preference that you can use to force KDE/Qt or to force the 'bare' X11 look. You can always use a third-party skin (or Opera's own, older skin) if you don't like the elements to look native - it is up to the skin designer to decide which elements should be drawn natively and which ones should be skinned.

That's a news I am glad to hear!
Thank you, guys (-:E

from the looks of it, Opera unix is going to have a title bar ?

I thought the windows version didn't have one

Originally posted by pios:

from the looks of it, Opera unix is going to have a title bar ?

I thought the windows version didn't have one

That's probably because it's getting a trend in Windows land to "remove" the title bar. MS started this by themself, by placing extra buttons in the title bar, Chrome took over by integrating the tab bar in the title bar, and now Opera does the same thing.

libray writes: This is encouraging that QT has been stripped and there exists a way for system GTK to be utilized. Will the Opera 10 + Flash 10 + opensolaris (solaris) problem be fixed with this major update? http://opensolaris.org/jive/thread.jspa?messageID=431615 I've had to use the insecure flash 9 in Opera to get around the issue.