Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (0)
to General by Kalatti - 2 days, 8 hrs ago -
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 4 days, 5 hrs ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 5 days, 2 hrs ago - more...
 |
vistaus |
2015-05-21
, 22:02
|
|
Posts: 423 |
Thanked: 478 times |
Joined on Sep 2014
@ Netherlands
|
#91
|
WebPirate has a built-in ad blocker which you can define your own rules for but you can also use the browser ad blocker app from Warehouse.
|
|
2015-05-21
, 22:08
|
|
Posts: 2,076 |
Thanked: 3,268 times |
Joined on Feb 2011
|
#92
|
Originally Posted by vistaus
Tried it, nothing comparable really, my local webpage I visit for latest news 90% ads were there and it loaded slower because of this (and rendered as they now use animated html5, year ago it was flash so was free of it, they learned, flash is dead)
WebPirate has a built-in ad blocker which you can define your own rules for but you can also use the browser ad blocker app from Warehouse.
 |
|
2015-05-22
, 08:03
|
|
Posts: 27 |
Thanked: 136 times |
Joined on Feb 2015
@ Italy
|
#93
|
It's impossible to make a "real" AdBlock with the current QtWebKit implementation (Qml side).
Other known issues are:
Me and Webcat's developer have fixed some other issues using Javascript injections, pushing the current QtWebKit implementation beyond its limits, this gives a fairly good browsing experience (but, not perfect, after all
).
For me, these native browsers are a good alternative until Jolla improves its browser.
When (and if) Jolla switches to Qt >= 5.4 (better 5.5), things can be improved using the new QtWebEngine and the missing things can be implemented without issues (I hope :P), and yes, in that case I can consider to develop a real AdBlock implementation.
Other known issues are:
- Proxy Support
- Geolocation
- Plugins Support (for example, flash)
- Unsupported tags like <video> and <svg> (bypassed with Javascript injections and polyfills)
- Pixel Ratio detection (bypassed with a hack)
- The current WebKit implementation (taked from a 2010 development tree, very old for today standards) is vulnerable to FREAK attack and the most recent LogJam
- QtWebkit does not detect when the phone loses internet connection, forcing the user to restart the whole application
Me and Webcat's developer have fixed some other issues using Javascript injections, pushing the current QtWebKit implementation beyond its limits, this gives a fairly good browsing experience (but, not perfect, after all
).For me, these native browsers are a good alternative until Jolla improves its browser.
When (and if) Jolla switches to Qt >= 5.4 (better 5.5), things can be improved using the new QtWebEngine and the missing things can be implemented without issues (I hope :P), and yes, in that case I can consider to develop a real AdBlock implementation.
|
|
2015-05-22
, 08:21
|
|
Posts: 188 |
Thanked: 308 times |
Joined on Jan 2013
@ UK
|
#94
|
Originally Posted by Dax
I wonder if that's why Jolla went with ffx-based rather than webkit?
It's impossible to make a "real" AdBlock with the current QtWebKit implementation (Qml side).
Other known issues are:
- Proxy Support
- Geolocation
- Plugins Support (for example, flash)
- Unsupported tags like <video> and <svg> (bypassed with Javascript injections and polyfills)
- Pixel Ratio detection (bypassed with a hack)
- The current WebKit implementation (taked from a 2010 development tree, very old for today standards) is vulnerable to FREAK attack and the most recent LogJam
- QtWebkit does not detect when the phone loses internet connection, forcing the user to restart the whole application
Me and Webcat's developer have fixed some other issues using Javascript injections, pushing the current QtWebKit implementation beyond its limits, this gives a fairly good browsing experience (but, not perfect, after all
For me, these native browsers are a good alternative until Jolla improves its browser.
When (and if) Jolla switches to Qt >= 5.4 (better 5.5), things can be improved using the new QtWebEngine and the missing things can be implemented without issues (I hope :P), and yes, in that case I can consider to develop a real AdBlock implementation.
Although on the desktop I've tried a load of webkit based browsers and have nearly always gone back to ffx for perfromance reasons (the webkit browsers have always all been slower at rendering and haven't coped with >1-2hr streaming). Currently using a qtwebkit based one at the moment which isn't too bad so far, though is in early development so has some issues.
There's no perfect web browser (rendering engine), and they all have drawbacks. Which one people prefer will depend on their uses, biases, UI preferences and areas where they're happy to compromise. I use all three of the native, depending on various factors. Can't say I have a preference, but they all have good/bad points - and it's useful to see the reasons for some of them.
|
|
2015-05-22
, 08:29
|
|
Posts: 27 |
Thanked: 136 times |
Joined on Feb 2015
@ Italy
|
#95
|
Originally Posted by skanky
Yes, also QtWebKit is deprecated, and that's one more reason for switch their browser to Gecko.
I wonder if that's why Jolla went with ffx-based rather than webkit?
Also, I think that Qt Company have deprecated QtWebKit too soon, giving us, developers, a rendering engine implementation that it is incomplete (QtWebKit 3.0, in Qml), and another one that it isn't 100% complete (QtWebEngine in Qt 5.4).
QtWebEngine implementation is usable in Qt 5.5, but it is in beta state now.
| The Following 3 Users Say Thank You to Dax For This Useful Post: | ||
|
|
2015-05-22
, 08:55
|
|
Posts: 188 |
Thanked: 308 times |
Joined on Jan 2013
@ UK
|
#96
|
Originally Posted by Dax
Interestting as the one I'm using on my desktop is dependent on >=5.2 though 5.4 is installed.
Yes, also QtWebKit is deprecated, and that's one more reason for switch their browser to Gecko.
Also, I think that Qt Company have deprecated QtWebKit too soon, giving us, developers, a rendering engine implementation that it is incomplete (QtWebKit 3.0, in Qml), and another one that it isn't 100% complete (QtWebEngine in Qt 5.4).
QtWebEngine implementation is usable in Qt 5.5, but it is in beta state now.
| The Following User Says Thank You to skanky For This Useful Post: | ||
 |
|
2015-05-22
, 10:10
|
|
Posts: 1,389 |
Thanked: 1,857 times |
Joined on Feb 2010
@ Israel
|
#97
|
Originally Posted by szopin
True, i have about 5 pages loaded and other precached, i think it depends on the size of the content as there is memory optimization.
Are those 33 tabs active (automatically updating live content)? I'm willing to bet 5RUB, they are not, so you have 32 cached pages, and only one tab, not really impressive.
Also who the hell browses pages, you send an email to a program to fetch it and email back to you, the real open source fanboi way
(btw webcat has active tabs, so they load new posts on imageboards in the background, but yeah, doubt 30 tabs will work, 32 'bookmarks' plus one tab isn't really that taxing)
But you can't have it all. But as i like to "open new tab" option it would load page, so if i open several pages all of them are loaded and than i can read one by one and close. Most of other pages i left open are in "read it later" mode.
| The Following User Says Thank You to ZogG For This Useful Post: | ||
|
|
2015-05-22
, 10:30
|
|
Posts: 1,389 |
Thanked: 1,857 times |
Joined on Feb 2010
@ Israel
|
#98
|
Originally Posted by P@t
You are right, but i was not talking about it, my point was that it's not cool to tell "we do not need it" or "we have this instead" if something is not done properly, but people keep doing it.
@ZogG I think you insist a bit too much on this: I am not sure many people would claim the 3-limit tab as a nice feature.
If you have more with BB10, good for you.
Let me add one point: this is clearly possible to have much more than 3-tab in sailfish os browser, but usually only 3 are kept in memory, so that if you have more, you may have to reload the tab if you want it back.
That limit is probably more related to Jolla phone than to the SFOS browser per se: they had to do that because Jolla phone is having less memory than most competitors.
We can hope for more optimisation for sure and it will come at some point
BB10 and its browser (because this is what you use mostly) is maybe more optimised in that regards, at least for the moment.
I know that the point is made so often but for sure, Jolla is a small company (compared to any other competitor) and by far. They cannot work on all aspects at the same time, they do prioritize and much more than other companies.
We know the weaknesses
and we know the strengths.
to have a Jolla is more to be in a (small) boat for a journey than to be in the beach taking the sun
And about small company. True and unfair for them to compete with huge companies with huge resources and option to make phones with top HW. But still it's mostly excuse. As they decided to make something and they want to compete in market, all this are excuses. They knew it ahead and they went for it. It's like to have professional runners and not trained person in competition, you can't expect from judges to give sympathy for him just because he is not trained and tries his best, if he is not ready, he should not compete or to be ready to be last one and acknowledge it. There is no place for sympathy, it's about competition. And if most Jolla community telling how Android(btw i myself do not like it, but that's not the point) is closed and how Jolla is superior and when they proved wrong, even in matter of openess, they suddenly turn it to "but they are small" or "it';s not their fault, but 3rd parties". It's wrong as at the end of the day the reason doesn't matter, the fact is the fact. And i paied 400euro i did not do it for charity or sympathy, i expected certain thigns that were promised(openess and opensourcing things) or to be unlike and modern smartphone and not "but they are still small". But at the end of the day, while Jolla has really a lot of advantages over other phones(real Linux, terminal, Qt, latest opensource technologies), with all that they still to be smartphone with at least mid range features of the todays smartphones, otherwise i do not see the point from not using even N900(just coz of UI? or TOH that was used to promote Jolla at first day but except few awesome community memebrs work all we got expensive covers with colours and ringtones, btw nothing about it lately while it was huge promotion on the start, coincidence?).
We all forget, while i do respect a lot of sailors and there are a lot of talents, but a lot of companies do, the question is about directions. We all agree that google is evil now, but they use a lot of opensource and still help opensource projects, but it's all about their own needs mostly. Same with Jolla, we need to see their direction and remember it's not a charity. If jolla want to compete with other smartphones it would be unacceptable to tell about each failure that it's coz they are small, after all for me as end user it's irrelevant as i pay even more expensive price for same specs for OS that after 2 years(or even more?) still can't deliver a lot of things. And please do not tell me that iOS and Android lack a lot at start, as they lack competitiors too, they introduced something new and made a standard after all. If Jolla want to do that they at least have to have something innovative and new UI and proove of concept of TOH, which is dropped for tablet and when i asked if there would be support and compatability for second phone, i got no answers. So basically everytime we compare or say what's wrong with Jolla we get same excuses and no real answer.
|
|
2015-05-22
, 11:34
|
|
Posts: 1,746 |
Thanked: 1,832 times |
Joined on Dec 2010
|
#99
|
is it less clunky than the old implementation?
|
|
2015-05-22
, 12:04
|
|
Posts: 27 |
Thanked: 136 times |
Joined on Feb 2015
@ Italy
|
#100
|
Originally Posted by m4r0v3r
Is this question related to my post?
is it less clunky than the old implementation?
If yes, QtWebEngine's api are similar to QtWebKit's one, but there should be more things implemented/supported, the rendering engine is more recent, and, according to the information provided by Qt 5.5 roadmap, it is based on Blink shipped with Chromium 40.
But, I think that Sailfish OS 2.0 will be shipped with Qt 5.2 (there is an interesting topic on TJC) and there is no immediate plan to upgrade Qt.
Another option should be that they allow the usage of Gecko in 3rd party software (Mail application uses QtWebKit and it is vulnerable to FREAK and LogJam), so there is less fragmentation and makes the system safer.