I think this is a very important issue. Maybe a bug-tracker ticket should be created for discussing possible solutions?
Jan Kleks wrote:
I think this is a very important issue. Maybe a bug-tracker ticket should be created for discussing possible solutions?
I think we've already discussed it. My impression is that at the end it comes to man power. With only few developers it's not possible to do implement something better.
I suggest you discuss the topic on the dev thread. Perhaps we can make a roadmap or something and slowly improve some aspects.
regards
On Thursday 06 April 2017 07.46:40 deloptes wrote:
I think we've already discussed it. My impression is that at the end it comes to man power. With only few developers it's not possible to do implement something better.
This is a thought from someone who really doesn't know about Wayland, but if Wayland requires such big changes in the code, this will mean that *lots* of older code will become useless.
If this is true, it might be a big point against a switch. I understand that Ubuntu has always worked "the Microsoft and Apple" way (I mean they decide and the users are to follow), but here is Linux so we may be in for another systemd/syvinit feud.
Thierry
Sorry, mixed up the threads :(
On Thu, 06 Apr 2017 07:46:40 +0200 deloptes deloptes@gmail.com wrote:
Jan Kleks wrote:
I think this is a very important issue. Maybe a bug-tracker ticket should be created for discussing possible solutions?
I think we've already discussed it. My impression is that at the end it comes to man power. With only few developers it's not possible to do implement something better.
I suggest you discuss the topic on the dev thread. Perhaps we can make a roadmap or something and slowly improve some aspects.
Improving KHTML isn't in the cards, I don't think. Previous discussions have focussed around porting the entire browser to a new rendering engine (generally KHTML's descendant Webkit) that already supports the missing CSS3 and HTML5 features. There's just never been enough manpower to do the work.
The Javascript engine probably also needs to be updated. I don't know how susceptible it is to piecemeal upgrades, as opposed to dropping the entire thing and adopting something written for another browser.
E. Liddell
2017-04-06 13:48 GMT+02:00 E. Liddell ejlddll@googlemail.com:
On Thu, 06 Apr 2017 07:46:40 +0200 deloptes deloptes@gmail.com wrote:
Jan Kleks wrote:
I think this is a very important issue. Maybe a bug-tracker ticket
should
be created for discussing possible solutions?
I think we've already discussed it. My impression is that at the end it comes to man power. With only few developers it's not possible to do implement something better.
I suggest you discuss the topic on the dev thread. Perhaps we can make a roadmap or something and slowly improve some aspects.
Improving KHTML isn't in the cards, I don't think. Previous discussions have focussed around porting the entire browser to a new rendering engine (generally KHTML's descendant Webkit) that already supports the missing CSS3 and HTML5 features. There's just never been enough manpower to do the work.
The Javascript engine probably also needs to be updated. I don't know how susceptible it is to piecemeal upgrades, as opposed to dropping the entire thing and adopting something written for another browser.
E. Liddell
To unsubscribe, e-mail: trinity-users-unsubscribe@ lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists. pearsoncomputing.net Read list messages on the web archive: http://trinity-users. pearsoncomputing.net/ Please remember not to top-post: http://trinity. pearsoncomputing.net/mailing_lists/#top-posting
Apart from Webkit there is also QtWebEngine used, for instance, by Otter Browser ( http://browsingthenet.blogspot.com/2016/03/k-meleon-vs-qupzilla-vs-otter-bro...). This engine might be worth considering as well.
An alternative to replacing the rendering engine would be to remove Konqueror's web capabilities altogether (what's the point of have a broken browser?), and adopting another lightweight browser for the TDE (or just removing Konqueror and leaving the matter of installing their favorite browser to the users).
For the time being, when launching Konqueror for the first time it could show a message that web rendering is broken for now, and the TDE Team suggest installing another browser. So that the users won't think that the TDE is outdated or something because of this.
Jan Kleks
On Thu, 6 Apr 2017, Jan Kleks wrote:
2017-04-06 13:48 GMT+02:00 E. Liddell ejlddll@googlemail.com:
On Thu, 06 Apr 2017 07:46:40 deloptes deloptes@gmail.com wrote:
Jan Kleks wrote:
I think this is a very important issue. Maybe a bug-tracker ticket should be created for discussing possible solutions?
I think we've already discussed it. My impression is that at the end it comes to man power. With only few developers it's not possible to do implement something better.
I suggest you discuss the topic on the dev thread. Perhaps we can make a roadmap or something and slowly improve some aspects.
Improving KHTML isn't in the cards, I don't think. Previous discussions have focussed around porting the entire browser to a new rendering engine (generally KHTML's descendant Webkit) that already supports the missing CSS3 and HTML5 features. There's just never been enough manpower to do the work.
The Javascript engine probably also needs to be updated. I don't know how susceptible it is to piecemeal upgrades, as opposed to dropping the entire thing and adopting something written for another browser.
Apart from Webkit there is also QtWebEngine used, for instance, by Otter Browser ( http://browsingthenet.blogspot.com/2016/03/k-meleon-vs-qupzilla-vs-otter-bro...). This engine might be worth considering as well.
An alternative to replacing the rendering engine would be to remove Konqueror's web capabilities altogether (what's the point of have a broken browser?), and adopting another lightweight browser for the TDE (or just removing Konqueror and leaving the matter of installing their favorite browser to the users).
For the time being, when launching Konqueror for the first time it could show a message that web rendering is broken for now, and the TDE Team suggest installing another browser. So that the users won't think that the TDE is outdated or something because of this.
I use konqueror foremost as a file manager _between_ systems (sftp://...) AND as an old browser to check my web pages to insure they play nice when visited by someone using an older browser.
I don't doubt that others do, too. Jonesy
Jonesy composed on 2017-04-06 07:03 (UTC-0600):
I use konqueror foremost as a file manager _between_ systems (sftp://...) AND as an old browser to check my web pages to insure they play nice when visited by someone using an older browser.
I don't doubt that others do, too.
Konq's KHTML is the only remaining web browser engine capable of rendering physical sizes specified by legacy CSS accurately. The physical CSS units cm, mm, in, etc. were changed in the CSS3 specification to be logical sizes. When a display's physical density is matched to logical density by the server, Konq displays physical units accurately at their actual physical sizes. With other web browsers, this is only possible if the physical display density is 96 DPI (uncommon to say the least) and the server's default logical density of 96 DPI is retained.
Recent Gecko browsers do have the capability of rendering at accurate physical sizes when physical and logical density match, but only by using proprietary CSS which doesn't exist in legacy CSS.
http://fm.no-ip.com/Auth/dpi-screen-window.html is a simple means to confirm the foregoing.
2017-04-07 6:03 GMT+02:00 Felix Miata mrmazda@earthlink.net:
Jonesy composed on 2017-04-06 07:03 (UTC-0600):
I use konqueror foremost as a file manager _between_ systems (sftp://...)
AND as an old browser to check my web pages to insure they play nice when visited by someone using an older browser.
I don't doubt that others do, too.
Konq's KHTML is the only remaining web browser engine capable of rendering physical sizes specified by legacy CSS accurately. The physical CSS units cm, mm, in, etc. were changed in the CSS3 specification to be logical sizes. When a display's physical density is matched to logical density by the server, Konq displays physical units accurately at their actual physical sizes. With other web browsers, this is only possible if the physical display density is 96 DPI (uncommon to say the least) and the server's default logical density of 96 DPI is retained.
Recent Gecko browsers do have the capability of rendering at accurate physical sizes when physical and logical density match, but only by using proprietary CSS which doesn't exist in legacy CSS.
http://fm.no-ip.com/Auth/dpi-screen-window.html is a simple means to confirm the foregoing. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
To unsubscribe, e-mail: trinity-users-unsubscribe@list s.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pears oncomputing.net Read list messages on the web archive: http://trinity-users.pearsonco mputing.net/ Please remember not to top-post: http://trinity.pearsoncomputin g.net/mailing_lists/#top-posting
So maybe the old KHTML engine could be transformed into the "legacy mode"?
Jan Kleks composed on 2017-04-07 22:01 (UTC+0200):
2017-04-07 6:03 GMT+02:00 Felix Miata composed:
Konq's KHTML is the only remaining web browser engine capable of rendering physical sizes specified by legacy CSS accurately. The physical CSS units cm, mm, in, etc. were changed in the CSS3 specification to be logical sizes. When a display's physical density is matched to logical density by the server, Konq displays physical units accurately at their actual physical sizes. With other web browsers, this is only possible if the physical display density is 96 DPI (uncommon to say the least) and the server's default logical density of 96 DPI is retained.
Recent Gecko browsers do have the capability of rendering at accurate physical sizes when physical and logical density match, but only by using proprietary CSS which doesn't exist in legacy CSS.
http://fm.no-ip.com/Auth/dpi-screen-window.html is a simple means to confirm the foregoing.
So maybe the old KHTML engine could be transformed into the "legacy mode"?
Maybe do as Konq 4 & 5 do, make it switchable.
Konq 4 offers KHTML and WebKit.
Konq 5 offers KHTML and (QT's) WebEnginePart (aka Blink, aka WebKit fork used by Chromium). http://fm.no-ip.com/SS/KDE/konq5Engines.jpg
On Thursday 06 April 2017 13:14:47 Jan Kleks wrote:
An alternative to replacing the rendering engine would be to remove Konqueror's web capabilities altogether
Please not the ftp - just the browsing "capabilities". It has sadly become a lousy browser, but it is still a great ftp server and client.
Lisi
2017-04-06 15:40 GMT+02:00 Lisi Reisz lisi.reisz@gmail.com:
On Thursday 06 April 2017 13:14:47 Jan Kleks wrote:
An alternative to replacing the rendering engine would be to remove Konqueror's web capabilities altogether
Please not the ftp - just the browsing "capabilities". It has sadly become a lousy browser, but it is still a great ftp server and client.
Lisi
To unsubscribe, e-mail: trinity-users-unsubscribe@ lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists. pearsoncomputing.net Read list messages on the web archive: http://trinity-users. pearsoncomputing.net/ Please remember not to top-post: http://trinity. pearsoncomputing.net/mailing_lists/#top-posting
Yeah, I meant only http browsing features, nothing else. I really like Konqueror as a file manager. But this idea with removing stuff is just for brainstorming purpose. Let's see what the TDE Team would say.
Jan Kleks
Am Donnerstag, 6. April 2017 schrieb Jan Kleks:
2017-04-06 15:40 GMT+02:00 Lisi Reisz lisi.reisz@gmail.com:
On Thursday 06 April 2017 13:14:47 Jan Kleks wrote:
An alternative to replacing the rendering engine would be to remove Konqueror's web capabilities altogether
Please not the ftp - just the browsing "capabilities". It has sadly become a lousy browser, but it is still a great ftp server and client.
Lisi
To unsubscribe, e-mail: trinity-users-unsubscribe@ lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists. pearsoncomputing.net Read list messages on the web archive: http://trinity-users. pearsoncomputing.net/ Please remember not to top-post: http://trinity. pearsoncomputing.net/mailing_lists/#top-posting
Yeah, I meant only http browsing features, nothing else. I really like Konqueror as a file manager. But this idea with removing stuff is just for brainstorming purpose. Let's see what the TDE Team would say.
Jan Kleks
NOt such a good idea. Just look at devuan the last days, or TDE some months ago: when certificates are overdue, all "modern" browsers do not allow you to see the site, 'cause they are so much smarter than the user. konqueror is the last resort in these cases, and I do not want to miss that.
Nik
-
deloptes -
Dr. Nikolaus Klepp -
E. Liddell -
Felix Miata -
Jan Kleks -
Jonesy -
Lisi Reisz -
Thierry de Coulon