What still bugs me in opera (on linux and in general)...
-
A Former User last edited by
You are totally wrong on that, and here is the proof. Opera 58 is based on chromium 71 and that chromium version was released 3 months ago
https://help.opera.com/en/opera-version-history/
Opera 59 (chromium 72 based) is not in beta anymore, while opera 60 (chromium 73 based) is on both beta and developer channels. In fact, given the existing mess, I would not be suprised if opera stable skipped 59 completely and went straight to 60. That would be the best solution imho.
On top of that, let me make an example of how chromium's versioning works in relation to time, and compare it to how opera's versioning does.
- Today, chromium 73 is in stable, 74 is in beta and 75 is in dev. The day that 74 reaches stable, 75 will become beta and 76 will become dev. On the very same day, without any delay.
The same happens in firefox too, but firefox is a different story, not related to ours. - In opera though, things are different. I will use a different set of version numbers because today's is messed up with opera stable being on 58 and both beta and developer being at 60, Let's say opera stable is at 58, opera beta is at 59 and opera developer is at 60 today, so that the number "match".
If opera 59 becomes stable tomorrow, opera beta will stay at 59 and developer will stay at 60 for some time When will they be updated? Sometime in the following days and not on the same day again, because there is no real schedule about it!
And that is what bugs me above when I say that 3 branches are too much for the devs to handle.
- Today, chromium 73 is in stable, 74 is in beta and 75 is in dev. The day that 74 reaches stable, 75 will become beta and 76 will become dev. On the very same day, without any delay.
-
A Former User last edited by
The schedule example? It has nothing to do with what you said.
I was just pointing out that today's opera stable is not based on today's (or even the previous) version of chromium but on an even older one. You said that there is one stable version of opera for each stable version of chromium and I proved you wrong.And you are probably right about the delay due to reborn 3, but try explaining that to a simple user like the ones that started the 3 threads yesterday. All with a different subject/issue yet all pointing to the same problem.
For most of us, regular functionality is more important than a redesign. -
A Former User last edited by
Since my other thread about csd was locked without any notification or explanation, even with a pm, I add the bad csd as another annoyance.
- Ugly csd that can not be removed
https://forums.opera.com/topic/28146/opera-55-getting-rid-of-that-ugly-csd/p.s. If there is any mod that knows the reason it was locked, please pm me.
-
A Former User last edited by
Lets add one more.
- Removal of opera and opera-next from the deb repo
They both are on v12.16, the last one using presto as the rendering engine, and they must have been there since 2014 or so.
Today, they are not even installable, due to the prehistoric dependencies they want$ sudo apt-get install opera Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: opera : Depends: libgstreamer-plugins-base0.10-0 (>= 0.10.16) but it is not installable Depends: libgstreamer0.10-0 (>= 0.10.15) but it is not installable Depends: gstreamer0.10-plugins-good but it is not installable E: Unable to correct problems, you have held broken packages. $ sudo apt-get install opera-next Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: opera-next : Depends: libgstreamer-plugins-base0.10-0 (>= 0.10.16) but it is not installable Depends: libgstreamer0.10-0 (>= 0.10.15) but it is not installable Depends: gstreamer0.10-plugins-good but it is not installable E: Unable to correct problems, you have held broken packages.
So please remove them
Luckily, the yum (rpm) side of the repo contains only the latest packages.
-
A Former User last edited by A Former User
There is a chromium based browser that I refused to use because it was based on electron, or actually a fork of it. When I discovered that it is no longer based on it, I installed it so as to check how it compares to opera, especially on the issues I mention on this thread.
So, after a month of usage, here it goes.Codecs
It is built so as to the system's ffmpeg libraries, so its h264 (and other html5 codec) support is on par with the other browsers on the system.
In fact, I wanted to confirm it that much, that I asked the devs themselves on the project's page on github and they provided all the info.
I learned that the build flag
USE_SYSTEM_FFMPEG=true or false
that I had mentioned months ago no longer exists and now the same thing is done via 2 build flags
proprietary_codecs = true
and
ffmpeg_branding = "Chrome"
I checked them on chromium's build options on debian and arch and they are the same.Search engines
Although there is no way to select the search engine when you right click on some highlighted text, because it defaults to google (or the one you select as default in options), you can delete the search engines you do not use.Keeping up with chromium releases
I have to admit that its devs are doing a great work on that. There is a new release every time a new chromium release comes out from upstream.
Not even the chromium maintainers from my distro are that fast!
And for that reason, their releases are not tied to ubuntu's releasesCsd
Although the browser does come with its own csd, it can be disabled through its options menu.These are my findings so far. There are also some other, less important (to me at least), e.g. the compatibility with extensions from the chrome store.
I won't be leaving opera anytime soon, but I think that if the devs of a lesser known browser can do all that, I am sure that the opera ones can too. -
A Former User last edited by A Former User
Let me add one more.
- Removal of the 32bit packages of chromium-based opera.
Since opera has dropped support for 32bit 2+years ago, please remove the 32bit packages from both the deb and the rpm repo.
Assuming that someone is advanced enough to first install opera's repo and then the browser from it, he can install opera's 32 bit version because the packages are still there! And this leads to more issues, like the one described here
https://forums.opera.com/topic/30291/www-lloydsbank-com-crashes-opera/ -
Lv44EnderShaman last edited by
What bugs me about Opera in Linux, in particular, is the strict adherence to a theme engine that does not support ricing the browser using the native GTK+ and DE themes. Honestly, I've never been fond of the sudden, massive push as of a few years ago to adopt a 'Metro/Material' design aesthetic on desktop or laptop Operating Systems. I want my desktop to look unified, clear, and distinct to use agnostic of any operating system, and I find the best way to do so is to use applications that adopt OS-agnostic theme engines.
I've had this problem on Windows for years now, and I'm aiming to properly switch to Linux completely. And Opera looks, well, honestly very janky with flat windows and icons when compared to my desktop applications on Ubuntu MATE. I don't see how people tolerate it, honestly.
-
minho last edited by minho
Horrible pixelated icon in alt+tab menu of KDE Plasma desktop environment.