|
| This Week... |
|
Fortune-teller and Keyboard Layout applets for Plasma, KNewsTicker resurrected for KDE 4.0 as a Plasmoid. Rewrite of <canvas> tag support in KHTML. Various new language syntax highlighting in Kate. Internal database storage work in Digikam. More playlist handling work, and support for Magnatune "streaming membership" in Amarok 2. OpenDocument loading of charts in KChart for KOffice 2. Various graphics fixes and a user handbook for the Bovo game. Kolourpaint is now fully ported to Qt4. Continued work on the Eigen 2 library. Further porting away from KDEPrint to the printing facilities provided by Qt4.
|
Will Stephenson provides a summary of the KDE 4 Hack Week at SUSE:
|
This week the KDE team and several of the other KDE people at SUSE held the inaugural KDE Hack Week at the openSUSE office in Nuremberg. The 'Innovation Time Off' concept at Novell allows us to spend a percentage of our time working on projects away from our day-to-day roles, so Klaas Freitag and Cornelius Schumacher (both of the KDE e.V. board) and Andre Duffeck and Daniel Gollub joined Dirk Mueller, Stephan Binner, Luboš Luňák and Will Stephenson in bringing KDE 4 closer to release.
Cornelius worked on KOrganizer, Klaas introduced Strigi to KHelpCenter and tidied its user interface, Will worked on Kopete's usability, Stephan prepared a KDE 4.0beta3 openSUSE based LiveCD, Andre worked on Plasma, adding a context menu to the panel, Daniel prepared a new OpenSync release and worked on Kitchensync, and Dirk worked on the KDE 4.0 Beta 3 release and the new SVN server. Along the way we found time to show off KDE 4 to Novell management, and held the first openSUSE KDE community meeting to make community members' and users' voices heard and open the door to their contributions to KDE on openSUSE.
|
|
Harri Porten answers common questions on the state and future of the KHTML web rendering engine used in KDE:
|
As people on #khtml and elsewhere keep asking the same type of questions I will summarize some of the answers that I can give and which - to my best knowledge - should match the view of other maintainers. This is to inform contributors, bug reporters, other helpers and users about the current state, avoid unfounded irritation and provide the basis for further discussion.
Feedback is greatly appreciated and will be incorporated into an updated version to be placed on konqueror.kde.org or so.
Will KHTML be the HTML rendering engine in KDE 4.0?
Yes. We are currently working on polishing it to get it into shape after so much of the frameworks around it have changed.
Are there any plans to drop KTHML?
No. Despite rampant rumors floating around there are no such concrete plans. We have had several discussions about alternatives but none of the them has yet crystallized as being accepted by the majority as a real option for KDE.
Why don't you pull all the good patches from Apple's WebCore and JavaScript libraries?
We do that to a certain degree since the beginning. More for KJS than for KHTML which is much bigger and platform dependent. Apple's code repository is publicly accessible now which has eased patch extraction. Prior to its opening the code had already forked a lot, unfortunately. Misaligned release schedules, design conceptions and platform needs have also sometimes resulted in incompatible solutions.
Are KDE patches ending up in Apple's code base?
To a small degree only. There were several attempts to establish a tradition of feeding our patches. Apple engineers also sometimes cherry-pick performance improvements on their own - possibly way later than we published it. As the patches at the same time often get reformatted to fit their coding style this does not make the "diff" between the code bases any smaller. As changes never get pushed back to us this is not an overly satisfying experience.
Does KDE profit from Apple's work?
We do in many ways. There are not only improvements and bug fixes that we can adopt but also an increased public awareness of our work and a group of skilled engineers to exchange ideas with. On the downside we are competing for independent contributors and have to live with the fact that some prefer to team up with a shiny and mighty company as opposed to joining our multi-faceted desktop project.
How about joining forces?
This is the obvious solution, of course, and since the beginning there have been various initiatives to establish a common project. So far all such attempts have failed. One has to realize that the Safari team is constantly under immense pressure to produce new features and benchmarks for the next Mac OS X release or whatever Steve Jobs will present at next year's WWDC keynote and does not want to risk giving up full control. As with the Windows version of Safari, work is sometimes done behind the scenes. We have not given up hope of course and hope to find some solution that accommodates the need of all parties.
Why is all of this important?
The attention paid to KHTML and interest in its future is amazing. The number of well-meaning advisors by far outweighs the number of developers actually writing the code. But the interest is fully warranted. The use of Internet technologies will inevitably continue to rise in our applications. And the degree to which we are involved in the development of these technologies will govern our freedom in advancing their use. The Web development environment Quanta built on top of KHTML is such an example. Further opportunities for our mail mail, IRC, blog, news, media, calendaring, messaging and you name it clients are sheer endless. Merely adding a GUI around ready-made 3rd party components will not add much extra value to our framework.
What are maintainers asking for?
To be able to satisfy our user's expectations we need to be able to provide a patched version in case they find a bug. This is particularly important in case of security problems. This requires access to the development repository as well as KDE producing packages out of that repository. Waiting for other vendors to ship bug fix releases is not an option. When it comes to development of new features KDE developers need to have some say into it even if it needs to be coordinated with other parties. In case of KDE-specific needs there needs to be some way to add them.
Isn't this all a rather trivial job?
A Web browser component is about more than plain HTML rendering. Apart from dynamic scripting there is Java, Flash, cookies, URI shortcuts, password managers, security and networking support. And KDE has invested a lot into providing this infrastructure that is being shared with other applications.
How about using QtWebKit ones it comes out?
QtWebKit is a port of the forked KHTML sources that aims at providing a ready-made HTML component to Trolltech customers without relying on KDE (other than incorporating the WebKit sources with KDE origin). It just is a platform port without any influence on the feature set and therefore useless for KDE's purposes. See the "Why is all of this important?" and "What are maintainers asking for?" questions for more details.
So what are the plans?
As the current alternatives would mean dropping our code and losing all influence on development these are not real options. So we'll simply stick to our code base for now and keep on merging in improvements ourselves. The code is pretty good, surpassing other browsers in speed and features in some areas.
Of course, we would be very much interested in joining forces with others having the same development goals. And we'll keep the discussion about cooperation going. One approach I could imagine is to merge our work (thousands of commits done over the recent years) into a WebKit branch and switch over to that one day. This wouldn't be a branch like Nokia's that diverges from the main line more and more. Instead we could branch it off trunk regularly and simply re-apply our KDE-specific patches.
|
|
|
| Contents |
|
|
Bug Fixes |
Features |
Optimise |
Security |
Other |
|
Accessibility |
 |
|
|
|
|
|
Development Tools |
![[*]](/images/standard/bugfixes) |
![[*]](/images/standard/features) |
|
![[*]](/images/standard/security) |
![[*]](/images/standard/other) |
|
Educational |
|
|
|
|
|
|
Graphics |
|
|
|
|
|
|
KDE-Base |
|
|
![[*]](/images/standard/optimise) |
|
|
|
KDE-PIM |
|
|
|
|
|
|
Office |
|
|
|
|
|
|
Konqueror |
|
|
|
|
|
|
Multimedia |
|
|
|
|
|
|
Networking Tools |
|
|
|
|
|
|
User Interface |
|
|
|
|
|
|
Utilities |
|
|
|
|
|
|
Games |
|
|
|
|
|
|
Other |
|
|
|
|
|
|
|
Bug Fixes |
|
Development Tools |
|
Hamish Rodda committed a change to /trunk/KDE/kdevelop/languages/cpp/cppparsejob.cpp:
|
|
Prevent trying to translate cursors against an unopened file - revision 1 is always the "file has been opened" revision (unless starting a document from scratch... potential bug here but truly very minor if so, especially in comparison to the crashes this fixes for now) |
|
|
|
|
|
|
|
|
Aron Boström committed changes in /trunk/KDE/kdegames/bovo:
|
Finally fix a bug that has been there since the very dawn of Bovo.
When switching theme, the background was left untouched outside of the grid, which wasn't very pretty when the new theme had another background color.
(Don't tell anyone, part of this is a really, really duct tape solution.)
Also: remove previous duct tape fix from high contrast theme. |
|
|
|
|
|
|
|
|
|
|
Sebastian Pipping committed changes in /trunk/KDE/kdelibs/kate/syntax/data:
|
Fixes for C/C++ highlighters:
- Recogize comments after #define (#108370)
- Folding for for all proprocessor conditionals (only for "#if 0" before) (#124362)
- Folding for multi-line comments was missing in C++ highlighter
- Error marking for preprocessor lines not in #(define|elif|else|endif|if|ifdef|ifndef|include)
- Sync notice added
- Version number incremented to same value |
|
|
|
|
|
|
Rafael Fernández López committed a change to /trunk/KDE/kdebase/apps/dolphin/src/infosidebarpage.cpp:
|
On the Information panel the further information such as "Date", "Size", "Type" was being cut off if it was being shrinked. That shouldn't happen. This prevents this information to be hidden or cut off, and so this is always shown.
Albert: I also solved the previous bug you reported (places view not showing selected items at the first click) on a different commit |
|
|
|
|
|
|
Rafael Fernández López committed changes in /trunk/KDE/kdelibs/kdeui/icons:
|
|
This code fixes the icon loading for 4.0. This code _needs_ to be reviewed when Qt 4.4 is out. I will personally take a look on this when the time comes. Right now, as the SVG renderer is just broken on Qt, what we do is to resize from PNG's. |
|
|
|
|
|
|
Jaroslaw Staniek committed a change to /trunk/KDE/kdelibs/kdeui/kernel/kstyle.cpp:
|
The patch fixes sort indicator (PE_IndicatorHeaderArrow element):
only 'down' arrow was displayed before.
All KStyle-based styles were affected like Oxygen or Plastik, so only plastique worked properly.
As a sanity check I test QStyleOptionHeader::sortIndicator and State_UpArrow/State_DownArrow flag. |
|
|
|
|
|
|
|
|
Hamish Rodda committed changes in /trunk/KDE/kdelibs/kate:
|
Fix katepart so that the whole view does not re-layout and repaint on each keystroke.
This is essentially removing a hack I inserted when I was porting and having difficulties with drawing. It is a rather large change to how things work even though the amount of code changed is relatively small. Please notify me if you find any rendering regressions. |
|
|
|
|
|
|
Networking Tools |
|
David Faure committed changes in /trunk/KDE:
|
Rename default emoticons theme from Default to kde4.
Existing config files can still say "Default", the code interprets that as "kde4".
Found emoticons in use in kopete and kpimutils (for e.g. kmail); no kde4-konversation yet. |
|
|
|
|
|
|
|
|
|
|
Office |
|
Thomas Zander committed changes in /trunk/koffice/libs:
|
Fix usecase where enlarging the actual document (like adding a page in kword) would move the view down a bit on every page-add.
Loading a big document (which adds pages after loading) now correctly keeps the canvas on the position it started on. |
|
|
|
|
|
|
Features |
|
|
|
Games |
|
Aron Boström committed a change to /trunk/KDE/kdegames/doc/bovo/index.docbook:
|
Add Bovo documentation. Look out for:
* Bad English and lack of logic.
* It builds, but I can't seem to figure out how to view it.
Now, it just needs a review (and subsequent corrections). |
|
|
|
|
|
|
|
|
Marcel Wiesweg committed changes in /trunk/extragear/libs/libkexiv2/libkexiv2:
|
Merge changes to get information for new database schema in digikam:
GPS:
- split up in getGPSLatitudeNumber, getGPSLongitudeNumber, getGPSAltitude
- add checks that the denominator is not (I have one RAW image here, KODAK-DCSPRO.DCR, where invalid info with denominator 0 is returned. In any case, 1/0 is not 0)
- add getGPSLatitudeString, getGPSLongitudeString to get XMP-like GPS strings
- add a setGPSInfo method which takes the XMP-style strings
- add methods to convert from/to XMP-style string format
- add a method to convert to user-displayable numbers (in ° ' '' between 0 and 60)
Exif:
- add getDigitizationDateTime
Xmp:
- add getXmpTagVariant to get an XMP tag value as a QVariant (similar to getExifTagVariant, but with support for LangAlt etc.) |
|
|
|
|
|
|
|
|
Marcel Wiesweg committed changes in /trunk/extragear/graphics/digikam/libs/database:
|
- Add an initial implementation of the V4toV5 major schema upgrade - move Images and Albums to new tables - create one AlbumRoot from KConfig info - create file filter settings from KConfig info - TODO: one complete scan - port Rating, Comment, Date (overwrite values read by ImageScanner with those found in the db!)
- modify and rearrange parts of the updater logic |
|
|
|
|
|
|
|
|
KDE-Base |
|
Christopher Blauvelt committed changes in /trunk:
|
|
SolidDevice engine is feature complete and ready for inclusion in trunk. |
|
|
|
|
|
|
David Faure committed changes in /trunk/KDE/kdelibs/kdecore:
|
KService: support for storing Actions defined in .desktop files into ksycoca4.
While writing the unit test for this, I noticed that the binary representation (like, in ksycoca) of a single KService was 3700 bytes. This is because KConfigGroup::entryMap returns all translated entries. After filtering those out, the KService is down to 755 bytes; and the whole ksycoca4 went from 9.0M to 1.5M!
Seems to be an unexplained KConfig behavior change, which should be fixed, though. |
|
|
|
|
|
|
Maksim Orlovich committed changes in /trunk/KDE/kdelibs/khtml:
|
A major rework (really rewrite except for the graphics bits) of the <canvas> support, to fix the fundamental problems the previous implementation had. Essentially, it used to store all the bits in the renderer, and have the painting state split between an ephemeral painter (which went away on every repaint), and the JS context object. The way it's spec'd in HTML5 is that the canvas element/its context manage the canvas area and the painting state, and the renderer merely scales. So, I did the following:
1) The context, gradients, patterns, are all proper DOM objects, giving the information the expected lifetime.
2) The DOM context object keeps track of all the painting state itself, updating the painter as needed, and provides the canvas APIs
3) khtmlImLoad gets a new CanvasImage class, that provides a way of using its scaling cache features for this sort of thing. It's not a great fit (it's really meant for something more static), but it's reasonable
4) The JS part is now just a standard wrapper object, with some extra parameter checking, and a bit of code to split the type-unsafe things nicely.
Should we perhaps provide this as part of our C++ DOM in 4.1 or a later 4.0.x release?
5) In general, this was brought in line with HTML5 as best as I could, not being a graphics guy. At least the type checking should be close... assuming I understood it right
There are still gaps/missing features and bugs, of course, but this should serve as a solid foundation.
Various portions were reviewed by Allan, Germain, Harri and Fredrik, hopefully totally covering everything.
(Oh, and I need to figure out how to testcase this properly; I've been using a bunch of web-available testsuites, but we need something for khtmltests) |
|
|
|
|
|
|
Clarence Dang committed a change to /trunk/KDE/kdelibs/kdeui/actions/kfontaction.cpp:
|
Make KFontAction mostly work -- at least enough for changing font in KolourPaint:
* Make changing the font in the GUI update the action (call i.e. setFont())
* Make programmatically calling setFont() update the GUI, but not fire a signal (mimicks KDE 3.5 behavior)
* Make createWidget() set the created combobox to the action's current font
This took a surprising amount of time to write (don't ask). |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
