Skip to main content ↑ ↓
Topic: Otter browser and Qupzilla. (Read 5172 times)

Otter browser and Qupzilla.

Hi

First message here, even if I was one of the first people who noticed the news about the newborn browser.

As I already said  elsewhere I consider it a great hope for the people orphaned by the death of the true Opera development, and given I'm not a programmer I'm trying to help with some suggestions.

I suggested a couple of specific details on github, but the one I have in  mind now is more matter than a forum discussion than a bug filing on github, so I subscribed the forum.

Back to the subject, before the born of Otter i used Qupzilla for awhile, and I consider it also a great piece of code.

Now while the goals of both project are not exactly the same, Qupzilla reminds Opera in a lot of details: personalization menu, speeddial, basic theming, a lot of settings are the same and so on...

Unfortunately for the Opera lovers, Qupzilla doesn't aim to replicate opera but "just" to create a multiplatform, lightweight, independent browser.
So we will never see on Qupsilla's todo an email client, an operalink hook, a sidepanel[ s] and so on...

On the other hand, Otter aims to be a viable Opera alternative, but its development was started way later, so is obvious that is less mature.

Now what I'm going to ask:
why not reuse part of the Qupzilla code in Otter (say menus, speeddial and so on) and focus the development efforts on the areas where Qupzilla will never progress (because its different goals), say email/irc/notes integration, operalink emulation, compression support and so on?

I'm not a programmer, but given Qupzilla is opensource, and based on QT like Otter, I guess it's feasible, and I guess that a little cooperation between both the project should lead in better efficiency and in faster development, avoiding to reinvent the wheel, where the features overlaps.

What do you think ?

Thanks in advance for your attention

Re: Otter browser and Qupzilla.

Reply #1 –
The Solutor, it's not always possible to simply borrow some code (licenses are compatible, so it's not a problem), but for sure it could be source of inspiration how some stuff could be done, kind of reference implementation. ;-)
The biggest difference is that QupZilla is focused on single rendering engine (currently QtWebKit, most probably moving to QtWebEngine in future) while Otter aims to support multiple backends (basic support for Gecko should be fairly easy to do using Qt bindings for mozembed).
Nadszedł już czas, najwyższy czas, nienawiść zniszczyć w sobie.
The time has come, the high time, to destroy hatred in oneself.

Re: Otter browser and Qupzilla.

Reply #2 –
If I recall correctly, Emdek said that most of the things that could be taken from e.g. Qupzilla are now already standard Qt 5.2 features. But yeah, it sounds to me like e.g. its speed dial might be worth investigating.

Re: Otter browser and Qupzilla.

Reply #3 –
Quote from: Frenzie on

If I recall correctly, Emdek said that most of the things that could be taken from e.g. Qupzilla are now already standard Qt 5.2 features. But yeah, it sounds to me like e.g. its speed dial might be worth investigating.


Quote from: Emdek on

The Solutor, it's not always possible to simply borrow some code (licenses are compatible, so it's not a problem), but for sure it could be source of inspiration how some stuff could be done, kind of reference implementation. ;-)


Surely I'm aware that is not a simple cut and paste matter but, as you said, could be worth to look in to it, to see if some time can be saved.

Quote
The biggest difference is that QupZilla is focused on single rendering engine (currently QtWebKit, most probably moving to QtWebEngine in future) while Otter aims to support multiple backends (basic support for Gecko should be fairly easy to do using Qt bindings for mozembed).


It's just my personal opinion, but I'm afraid that putting a lot of effort trying to make the browser engine agnostic, can be limiting on the UI side and can "waste" a lot of time on development on something that most of the user doesn't really need/appreciate, even the power users used to Opera.

What I mean is that the average Opera user is already prone to accept some little glitches on the rendering side, while it miss every single UI feature.
After all we have already dozen of browsers, some of them are already multi engine (think to lunascape), but we currently have zero browsers fully resembling Opera.

Otter has already a subset of  the opera features, Qupzilla has ha different subset, Opium has another subset, Firefox (with a ton of extensions) can be somewhat "Operized", but none of them is a real replacement.

So my hope is that the focus will not be lost during Otter's development.

I don't know how it sounds in English or in Polish languages, but in Italy we have a said: "better is the enemy of good", in my personal experience that said is right. ;)

Re: Otter browser and Qupzilla.

Reply #4 –
There're few geek web browser now.

i think Qupzilla, Midori, Otter should be The Three Musketeers. :)
Fortuna fortes juvat.

Re: Otter browser and Qupzilla.

Reply #5 –
The Solutor, in worst case not all features will be available in each backend. ;-)
Nadszedł już czas, najwyższy czas, nienawiść zniszczyć w sobie.
The time has come, the high time, to destroy hatred in oneself.

Re: Otter browser and Qupzilla.

Reply #6 –
Quote from: The Solutor on

Otter has already a subset of  the opera features, Qupzilla has ha different subset, Opium has another subset, Firefox (with a ton of extensions) can be somewhat "Operized", but none of them is a real replacement.

So my hope is that the focus will not be lost during Otter's development.

I think the focus and plan of the development is doing just fine. What is lacking is pace. I can't do code myself and I don't know where to find developers with free time in their hands, with a burning desire and sense of commitment to achieve something in the free-and-open-source department.

Quote from: Emdek on

The Solutor, in worst case not all features will be available in each backend. ;-)

I have had no use for multiple engines in a single browser myself. I simply use different browsers to achieve different tasks. E.g. one browser where I store all the cookies and am constantly logged in to as many places as possible, another browser in case of rendering/access glitches in the first browser, a third browser because it runs better on limited hardware, a fourth browser for stealth purposes, a fifth just for the fun of trying it, etc.

As I understand it, your idea with the multiple rendering engines is to use them like a web developer tool. I'd argue that multiple rendering engines does not make sense for average users, such as myself. However, I believe these interests can be combined as follows.

Out of the box, have a different profile (interface) per rendering engine. It would be like Opera's interface setups and sessions in one. Have two-three (as many as the rendering engines included) sessions with their appropriate interfaces pre-configured and labelled transparently, like 'Internet Explorer', 'Mozilla', 'Emulate Text Browser - Accessible Design Debugger' etc.

In my mind, it's supposed to work like this: The user discovers the thing called sessions (or setups or profiles, to me it seems it would be a good idea to combine them to some extent, to give a proper look-and-feel feedback which one is being in use). By switching to a different session, the interface changes along with the rendering engine. This accomplishes multiple things at one go:

- The sessions, when labelled transparently for rendering engines, tell the user what these buttons or menu items are going to do
- This way the user sees the immediate purpose of sessions (if the user has use for the purpose or not is another thing, but at least the purpose is clearly there)
- When changing a session, the interface also changes, e.g. with the label 'Internet Explorer' to an Internet Explorer-like interface, to give complete and constant feedback to what session is in use

For power users, such as professional web developers, of course there should be also another way to fast-switch the rendering engines/modes of display without changing anything else. My main argument is that this cannot work the same way for average users. If average users download a browser with multiple rendering engines and are supposed to make use of the different engines, then making a special pre-configured session/setup/profile for each rendering engine ready to use out of the box is a way to invite them to give it a try, and to see the purpose not just behind different rendering engines, but also behind different setups/sessions/profiles.

Re: Otter browser and Qupzilla.

Reply #7 –
@ersi, the easiest way to do that is to use existing feature called profiles, they allow to have completely separated settings etc.
And yes, probably we should have some way to mark window, to let easily identify to which profile it belongs (the same could apply to sessions and private windows).

BTW, while it should be doable to for example set in site specific preferences which backend should handle specified page (so for example you could navigate from page rendered by QtWebKit to page rendered by QtWebEngine or something different) it gets complicated when we want to preserve tab history, each backend handles it differently and it's one of reasons why address bar is disabled for "about:" pages. ;-)
Nadszedł już czas, najwyższy czas, nienawiść zniszczyć w sobie.
The time has come, the high time, to destroy hatred in oneself.