The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Pleased with QtBrowser
by Josep on Wednesday 16/Apr/2008, @12:17
|
I was referreing more about on it's user interface than on it's HTML engine.
Although combining file management and web browsing in Konqueror has some valuable advantages, in it's current form it creates more confusion and complexity which are reflected in it's user interface.
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by eds on Wednesday 16/Apr/2008, @12:18
|
Disclaimer: I'm not a KHTML developer
I think KHTML devs never see Webkit in KDE as bad, but they still want to develop their very own rendering engine, what's wrong with that? Having alternatives is always good, moreover you can't force people what to do in their free time.
I support Webkit in KDE, but disposing KHTML now is just a plain stupid idea comes from people who does not know how open source works. I'm sorry, but seems you do not really understand how open source works. Saying: dump this because we have better alternative maybe will work in proprietary world. (I also hate when people say that KOffice is a waste of effort because we already have OpenOffice.org)
As long as KHTML still have developers behind them and still have users, it will *not* die. If finally KDE project has decided to ditch KHTML but the developers still exist, KHTML can be continued outside KDE.
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by Iuri Fiedoruk on Wednesday 16/Apr/2008, @14:49
|
Well, yes and no.
You see, a lot of users did not wanted the dying of kicker, but it happened for better (at least we hope so). :)
But yes, I'm not saying khtml must die now, but webkit is the future, soon or later it will be one of the dominant engines.
Look at maemo, qt, safari, iPhone, android and you see a bright future for it.
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by Luca Beltrame on Wednesday 16/Apr/2008, @22:29
|
"You see, a lot of users did not wanted the dying of kicker, but it happened for better (at least we hope so). :)"
I'm sure you're well intentioned and aren't doing this in bad faith, but why, *every* time you post about Plasma, you take shots at it?
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by eds on Wednesday 16/Apr/2008, @22:50
|
He is a well known strong supporter of old good kicker and Webkit. He doesn't really like plasma (KDE 4.0.x version of plasma to be more precise) and really likes to discredit KHTML ;)
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by Iuri Fiedoruk on Thursday 17/Apr/2008, @05:39
|
Yes and no :)
Plasma 4.0 = trash, crash, poor, less than alfa-quality.
Plasma 4.1+ = gold, awesome, impressive, shiny.
I was not being sarcastic, I've already asked forgiveness to Aaron Seigo (and can ask how many time it is needed, he can ask me to do so as many times he wish, I don't mind), because I think his *vision* of plasma as substitute to the old desktop is right and plasmoids development will be more easy than creating a cake.
The problem is that plasma is far from ready now, and I won't even talk about way back when 4.0 was released.
The main idea of plasma was having a stable base where developers could create widgets without changes in the code each new kde version and that plasma updates could be distributed indepentent of KDE release cycles. I've asked Aaron, and he said this will happen on 4.1 and afterwards.
So, long history short: After KDE 4.1 plasma is the king, if they had released kde 4.0 as kde4-developer-edition I would have nothing to complain.
I just have strong opinions, as Aaron does.
Our last struggle was about removing those crappy mini-icons on plasmoids. He did not liked my (and other opinions) and we kind of crashed, but that does not mean I don't respect and admire him, I just won't help get his ego bigger because a big ego leads to bad decisions ;)
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by eds on Wednesday 16/Apr/2008, @22:39
|
Well, kicker died because all the developers have agreed that it must die, and porting all those kicker applets would be just waste of time. In the case of KHTML, none of KDE developers say KHTML shall die ;)
Well, we just see, whether KHTML will die as what you wish or it will still strive as an alternative rendering engine. With the introduction of KHTML in Windows, I'm sure KHTML will get more market share.
(And safari in Windows is not as good as Safari on Mac, I prefer Firefox over Safari in Windows, and if Konqueror has been stabilize on Windows, surely I'll use Konqueror)
Alternative is good, do you know even there are more smaller open source rendering engines which have smaller market share - even maybe less than 0.001% market share? Like Netsurf for RiscOS, which is quite capable despite it is still very young and ultra-lightweightness.
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by Jim on Thursday 17/Apr/2008, @03:53
|
> I support Webkit in KDE, but disposing KHTML now is just a plain stupid idea comes from people who does not know how open source works. I'm sorry, but seems you do not really understand how open source works. Saying: dump this because we have better alternative maybe will work in proprietary world. (I also hate when people say that KOffice is a waste of effort because we already have OpenOffice.org)
This is complete nonsense. There's nothing wrong or anti-open-source about dropping a branch when a fork is a better option. It's exactly what happened with GCC/EGCS. Do you think that the GCC developers don't know how open source works?
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by eds on Thursday 17/Apr/2008, @04:19
|
Nonsense, they are not the same. For the case of EGCS, the FSF themselves who officially announced that they officially terminated old branch of GCC and made EGCS the new GCC. For KHTML vs WebKit case, the (current) KHTML devs still do not want to drop KHTML until several issues have been addressed. Note that they are not opposed in this idea, they just want some issues to be addressed first. So in this case, there is no agreement yet.
And even in the case of KDE really wants to kick KHTML from official KDE (KDE 5 maybe?), everybody is free to maintain KHTML outside KDE.
Really, nothing wrong with dropping a branch or a fork, but you cannot force your opinion to some people who are willing to maintain it. And why the heck we need to drop a stable and actively developed rendering engine?
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by Jim on Thursday 17/Apr/2008, @05:32
|
> For the case of EGCS, the FSF themselves who officially announced that they officially terminated old branch of GCC and made EGCS the new GCC. For KHTML vs WebKit case, the (current) KHTML devs still do not want to drop KHTML until several issues have been addressed. Note that they are not opposed in this idea, they just want some issues to be addressed first.
So why are you accusing luri of not understanding how open source works when he says that "webkit is the future"? He didn't demand that they drop it immediately or anything like that.
> And even in the case of KDE really wants to kick KHTML from official KDE (KDE 5 maybe?), everybody is free to maintain KHTML outside KDE.
Yes, just like anybody is free to maintain the old pre-EGCS GCC. What's your point?
> Really, nothing wrong with dropping a branch or a fork, but you cannot force your opinion to some people who are willing to maintain it.
Who is trying to force anything?
And if there's nothing wrong with dropping a branch, then why are you saying that doing so is anti-open source?
> And why the heck we need to drop a stable and actively developed rendering engine?
Josep already posted some good reasons why.
By definition, you can't drop something that isn't actively developed, so using the fact that it is actively developed as a reason to not drop something is circular logic.
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by blauzahl on Thursday 17/Apr/2008, @10:05
|
> He didn't demand that they drop it immediately or anything like that.
He sure implies they might as well.
> Josep already posted some good reasons why.
He didn't post good reasons. He posted poor reasons, and he didn't even bother trying the most recent version of Konqueror to compare. Instead he implies it is so buggy he couldn't even get it to work. It works just fine for me, so if he's having problems, he should be filing bugs.
> By definition, you can't drop something that isn't actively developed, so using the fact that it is actively developed as a reason to not drop something is circular logic.
I'd like to point out that khtml is still under active development. Look at the changelogs for the 4.0.x releases. It's also pretty stable: in all the time I've played with 4, I've only crashed Konq once, and once I reported it, it was fixed within the day.
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by Jim on Thursday 17/Apr/2008, @11:00
|
> > He didn't demand that they drop it immediately or anything like that.
> He sure implies they might as well.
No, he didn't. Saying something "is the future" is *explicitly* making a statement not about the present, but the future.
> > Josep already posted some good reasons why.
> He didn't post good reasons.
Fast startup, fast rendering, really simple, very easy to use... they sound like decent reasons to me.
> he didn't even bother trying the most recent version of Konqueror to compare.
Would that be the version of Konqueror tied to the version of KDE that end-users have been told *time and time again* to stay away from because it isn't finished yet? Are you surprised that people are actually taking this advice?
> if he's having problems, he should be filing bugs.
No, if he's having problems, then that justifies his preference for another browser. You can't blame users for choosing a more stable competitor instead of helping you track down bugs.
> I'd like to point out that khtml is still under active development.
I wasn't saying otherwise. I was pointing out that isn't a reason not to drop it.
|
[
Reply To This | View ]
|
|
Re: Pleased with QtBrowser
by dr on Wednesday 16/Apr/2008, @14:51
|
disagree 100%
I remember a few years ago the exact same comments being made about khtml with regard to gecko. If the khtml developers had just said 'gecko is the future' would there even be a webkit today?
so I for one am glad developers continue to provide alternatives and don't take the easy way out and just say 'why bother there is already program XYZ that does that?'
dr.
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by Patcito on Wednesday 16/Apr/2008, @16:27
|
khtml developers didn't go for gecko because it was too messy to make it work with KDE although they tried to integrate it so they could get rid of KHTML. Now that webkit is there, most KHTML original developers have switched to it because it is more supported than khtml and easy to integrate in KDE.
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by anon on Wednesday 16/Apr/2008, @17:22
|
They switched because they are paid to work on webkit.
|
[
Reply To This | View ]
|
|
khtml
by blauzahl on Wednesday 16/Apr/2008, @15:05
|
You're assuming that khtml developers are actually opposed to to webcore. It ends up being a lot more complicated than that, and it doesn't help that they don't tend to say much, preferring instead to code.
But I think you'd want a proper solution where we don't lose KDE features, such as the kwallet integration, spell checking in form widgets, and our public DOM api (without which applications such as Kopete cannot function).
Developers want to be able to make new releases, with features and bugfixes at the same time as the rest of KDE, and not wait for Apple to make a release first, then wait 6 - 9 months for Trolltech to release a new version of QtWebKit based on Apple's latest version (and then you wait longer for a KDE release that uses it).
While we're at it, QtWebkit is a port of Apple's WebKit. It isn't bug-for-bug compatible. Webkit doesn't come with any graphics or networking or rendering code, all of that is written in the port. Currently QtWebKit implements only a subset of Safari's features. So you lose various features that currently exist in khtml.
If you change the user agent, you too can make konqueror work with gmail. That is what QtBrowser is currently doing; it lies and says it is Safari. If we did this for all websites by default, then nobody would know that anyone was using Konqueror. It wouldn't show up in their webserver statistics. Which is better? To work with sites that assume there is no browser other than Firefox or perhaps Explorer? Or to prove that we exist?
Disclaimer: I'm not a khtml developer, but I'm also not telling lies. And if I am, I'm sure the actual developers will correct me.
|
[
Reply To This | View ]
|
Re: khtml
by MamiyaOtaru on Friday 18/Apr/2008, @13:42
|
Thank you for this post. I am so tired of hearing that webkit is a panacea. It's controlled by an outside entity, and to get to KDE has to go through another outside entity. There will be lead time for each new version.
There will be issues integrating it into KDE. Anyone who thinks webkit can just be dropped into Qt, much less KDE should read this: http://zecke.blogspot.com/2008/01/joys-of-debugging-webkit.html
I don't link to that to somehow try to prove that webkit in KDE won't work, it's just to show that there are issues getting webkit to work on any platform where it isn't native (pretty much anything but OSX). It's a lot of work getting it working in Qt, never mind KDE.
And yeah, in so many cases it seems like people want the browser string. Thing is, those people don't need a new rendering engine to get the browser string they want. I wish they'd just change it in their copy of Konqueror and stop agitating for webkit. If webkit proves to be superior (including how easy it is to get working and current in KDE) then it will happen, with or without boosterism on the dot.
|
[
Reply To This | View ]
|
|
Re: Pleased with QtBrowser
by MamiyaOtaru on Friday 18/Apr/2008, @14:32
|
"like Dolphin better"
That's fine, but I don't appreciate calls to remove Konqueror's file browsing functionality as long as Dolphin's dirtree sidepanel isn't up to snuff. Running the latest Dolphin now I see I can now copy and paste and stuff using the dirtree (yay) but it still doesn't show the root directory, and there's no way to change the dirtree's root. Konqueror's much maligned vertical tabs provide a way to switch between / as dirtree root and ~ as dirtree root.
I can live without that of course, but not showing the current root at all still irks me greatly. Combine that with edit mode (instead of navigate) in the address bar and lack of an 'up' button (which people wanted removed from konqueror for years for some reason) and there's no easy way to get to the dirtree's root.
It's coming along nicely though, a lot of stuff I had to complain about regarding Dolphin's dirtree implementation are no longer applicable, as I saw when I installed it from debian experimental. So that's nice.
At any rate, I quite like Nautilus' dirtree. Showing multiple roots (/, ~, /mnt/X, /mnt/Y, etc) at once is quite nice. Something like that would be grand for Dolphin.
At any rate, the changes I'm seeing are making me feel a lot better about KDE4.
|
[
Reply To This | View ]
|
Re: Pleased with QtBrowser
by MamiyaOtaru on Friday 18/Apr/2008, @14:33
|
Aaand I see I can add the up button back. yay. Would still love to see the root in the dirtree, but hey. That's what I get for using edit mode instead of the breadcrumb :-/
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
