In this week's KDE Commit Digest (all in one page):
Kalzium adds gradients and crystal structure data.
KOffice supports loading of embedded objects from OASIS format.
khtml improves XHTML handling.
Kopete adds full text search of history, styles, receiving files and buzzing in Yahoo, and work continues on video device support.
KDE 4 work continues with some applications able to run.
Dot Categories:
Comments
I don't understand. Konqueror 3.4 doesn't support XHTML:
http://bugs.kde.org/show_bug.cgi?id=52665
Has XHTML support been added to HEAD recently? The commit digest says:
"Merge/port/implement XHTML namespace selectors, and a few other XHTML
improvements."
This sounds like it's adding features in related things like CSS that are intended to work with XHTML, but under the assumption that XHTML support is already there. At the moment, Konqueror treats XHTML as HTML, which violates the XML 1.0 and XHTML specifications.
XHTML support is a big task, it's not just a case of piping XHTML documents through an HTML parser.
well, who cares about specifications if it renders correctly and 70% of all pages do not comply.
xhtml = html more strict.
> who cares about specifications if it renders correctly
XHTML has differences in CSS and the DOM. "Displaying like HTML" is not rendering correctly in many cases, even once you leave out the mandatory error handling.
"Who cares about specifications?" is a very short-sighted attitude to take anyway. Every major browser release going back to Netscape 1.2 has broken things for people who thought that they don't have a problem because it works in most browsers.
> 70% of all pages do not comply.
Huh? You are either talking about pages served as text/html, in which case 70% non-compliance is way too low and is completely irrelevent to XHTML anyway, or you are talking about pages served as one of the XML media types, in which case 100% of pages *do* comply, because if they didn't, they'd break in all other XHTML browsers.
I don't think you understand. Konqueror is the ONLY browser I know of that fails this part of the XML specification. Even Internet Explorer gets that bit right!
>who cares about specifications if it renders correctly and 70% of all pages do not comply?
according to that guy from Novel, people that don't take shower care :)
Bug #52665 is just a report of lots of small issues many of them that had nothing in particular to do with XHTML. From a cursory glance it looks like all the problems reported in the bug have been fixed.
And no, Konqueror doesn't treat XHTML as HTML and never has, except possibly when the mime-type detection have failed.
> Bug #52665 is just a report of lots of small issues many of them that had nothing in particular to do with XHTML.
Allan, I'm the reporter of that bug, there's no need to explain it to me. And practically every comment was directly related to XHTML.
> From a cursory glance it looks like all the problems reported in the bug have been fixed.
You obviously didn't click on the testcase; it still fails.
> Konqueror doesn't treat XHTML as HTML and never has, except possibly when the mime-type detection have failed.
Not failing on parsing errors is one example of Konqueror treating XHTML as HTML.
Differences between CSS in XHTML and HTML is another example of Konqueror treating XHTML as HTML (hint: try styling tbody elements when you don't have any tbody tags).
Differences between the content models of the and element types is another example of Konqueror treating XHTML as HTML (try commenting the contents out).
Those three examples are all failing for me right now in Konqueror 3.4.0, where they work just fine in Firefox and Opera, and have done for as long as they've supported XHTML IIRC.
No I tried all the test cases, and saw no remaining issues. The first one fails in a parse error, the second adopts the right charset, and the last runs the script in both cases.
The only problem right now is that Konqueror doesn't advetise its XHTML support in the HTTP header.
Notice that the commit as mentioned fixed many other small bugs, some of which helped a lot more test cases than adding namespaces, they were just small one-liner bug-fixes.
> No I tried all the test cases, and saw no remaining issues. The first one fails in a parse error
I'm not seeing that in 3.4.0, which is why I was asking if it had changed.
> Notice that the commit as mentioned fixed many other small bugs
I would have liked to have figured that out myself, but the server isn't responding for me so I can't read what they are :).
> The only problem right now is that Konqueror doesn't advetise its XHTML support in the HTTP header.
I'll start adding testcases for the problems I see with 3.4.0.
But please add more XHTML test cases which you think we should handle. It has been low priority, but I am fixing them now in order to learn the XML side of KHTML.
Sorry, but KHTML *did* treat XHTML as HTML, at least in the past (for examples replacing /> by > to be again HTML compatible, not respecting of <?xml encoding=""?> and so on...)
Have a nice day!
hey Derek, it looks like you forgot to mention that one in the new :)
"Now it is possible to delete a transfer using the popup menu :-)
Wow! With this in place and all the minor fixes to the bittorrent
plugin I did today, kget is pretty fuctional again (but there is still a
lot of work to do..). The most exciting stuff is the Felix's bittorrent
plugin that, after a little bit of testing, seems to be ok!!
Great work, Felix!!
Now I can be happy all next week :-)"
Wooo! KGet supporting BitTorrent would be very nice (no need to load up the java VM and Azureus, or even have them installed)! Will KGet's support be pretty much like how the official client's GUI would look (or use to a year or so ago, pretty much like just a download window in IE w/o much additional information)? Or will it have more information like Azureus?
First of all I would like to remember everyone that this feauture (and obviously others) will ship with kget in kde4.
My plan is to provide a detailed widget showing the most important informations about the torrent. I don't think it will ever reach the level of Azureus in terms of provided info, since this would lead to a bloated gui, but the useful ones will be there.
How about downloading from multiple urls simultaniously like DAP (download accelerator) or D4X (Downloader for X)
Am looking at the code to try understand how they implemented it in D4X but i've quickly realizing how tricky it maybe to implement with KIO.
Also ftp search wouldn't a bad idea...
regards,
Sam
What do you mean with FTP search?
I meant for normal download (not torrent) Kget could have an option FTP search feature that searches for mirrors etc thus having multiple source for the same download. This can speed up downloads by Kget detecting and avoiding busy mirros.
"Initial upload of SuperKaramba to kdereview."
Just thought it was news worthy. ;)
cheers,
Ryan
I am eagerly waiting for KDE 3.4.1, it was supposed to be released on 25th may, doesn't it?
The schedule was to tag on 23th May
http://developer.kde.org/development-versions/kde-3.4-release-plan.html
So it cannot be released in just two days!
Have a nice day!
http://www.kde.org/info/3.4.1.php says May 31st, 2005
holly shit, that's today!!!
:)))))))))))))))))))))))))))
Hi Derek,
Maybe you're already aware of it, but SVN revision numbers are marked as bugnumbers in the digest. A nice candidate of a dirty hack in the script :)