In this week's KDE Commit-Digest: Various work across Plasma, including improved applet handles with monochrome icons, work on the Weather Plasmoid and the start of an extender-based notification applet. Continued development in PowerDevil, including support for suspend. Long-standing "slow deletion of many files" bug is finally fixed. A System Settings module for choosing the default file manager. Basic implementation of red eye reduction in Gwenview. A generator for G3/G4 fax documents in Okular. Support for filter plugins in Kst. More work on code completion in KDevelop 4. Start of a D-Bus interface in Lokalize. First working implementation of KMenuEdit global shortcuts. Work on supporting different resources in the Akonadi OpenSync plugin. The return of Ark context-menu actions. Liechtenstein, Oman, and San-Marino maps in KGeography. Previews of slide transition effects in KPresenter now happen directly on the affected slide. A KFormula widget is extracted from KOffice and moved into kdelibs for use in other KDE applications. Work on porting Keep, a backup utility, to KDE 4. NEPOMUK query libraries move from kdereview to kdebase/workspace, with the search KIO slave moving into kdereview. A KDE 4 port of KnowIt, a note taking application, is imported into KDE SVN. Eigen 2.0 Beta 1 is tagged for release. Read the rest of the Digest here.
Comments
There is shortage in manpower in KHTML project. I think there are just three persons working in KHTML (Germain, Rafael and Maksim). I think khtml project needs more manpower and fresh blood.
Other rendering engines do not have manpower shortages. And the 3 people working on khtml are doing a phenomenal job, but let's face it keeping up to other browsers is becoming harder and harder.
In earlier years khtml was advanced and I believe this is primarily to do with the fact that web development happened on a slower pace. Nowadays it is just moving too fast.
Getting fresh blood is easier said than done. It is hard in the first place as khtml isn't exactly a glamorous job, and doubly so when other rendering engines have so much more momentum.
> Getting fresh blood is easier said than done. It is hard in the first place as > khtml isn't exactly a glamorous job, and doubly so when other rendering
> engines have so much more momentum.
And even more so when there is FUD going around from one's "friends" telling people the project is dead.
But really, there is an opportunity for gutsy people who want to contribute yet --- do you want to be a mercy of a few corporations, or do you want to keep KDE infrastructure in community's hands and match those with far more resources blow-for-blow by developing smarter?
"And even more so when there is FUD going around from one's "friends" telling people the project is dead."
It's not dead, but it's not going well, and the people who actually initiated KHTML many years ago have accepted the inevitable and are working on WebKit. KHTML will not be able to do what the original poster in this thread wants standing by itself, that much has become clear for the past *ten years*.
"do you want to be a mercy of a few corporations, or do you want to keep KDE infrastructure in community's hands"
Why are you using Qt then? There is also no rule, written or unwritten, that says a web rendering engine is a part of KDE's infrastructure. Additionally, that's just implied FUD about WebKit and probably Gecko as well. People are contributing and using them without the 'big bad corporation' influence you are trying to insinuate.
> the people who actually initiated KHTML many years ago [...]
> are working on WebKit
come on, that "founding father" crap is getting old...
and I'm sure they do not want to be reminded of that either, as all the two of them did is sold out their names on complacent revisionist PR articles.
I've been reading every WebKit commit messages since 14/11/2005, that's 24000+ of them, so I guess if those KHTML 'founding fathers' were contributing en masse to the core engine, I'd have noticed by now... :-)
The only guy that used to contribute to KHTML in 1999 that's working on the engine is Antti, an Apple engineer.
Which is not surprising given the WebKit engine is more than ever *locked up* by Apple engineers. They are happy to accept patches from the occasional student commiter, that will later on be duly engaged by Apple if he proves valuable, but anytime a corporation or organization attempts to contribute something, anything, significant it is mercylessly drawn into pointless bickering or their patches are let to rot in the bug system.
Trolltech engineers (now Nokia) for instance have never ever made *even a single* contribution to the core engine. Never. How awkward is that for an alleged "key contributor"?
All they do is porting to Qt, fixing the Qt build, fixing the Qt build system, and other spiritless work, adapting to code whose behaviour has been decided for them by Apple engineers alone.
For more of the same, have a look at the latest thread of poor Google engineers that have not yet understood the rules of the game, trying to propose a new URL framework on WebKit mailing lists and being told to basically stick it somewhere by the whole gang of Apple employees:
https://lists.webkit.org/pipermail/webkit-dev/2008-October/005200.html
https://lists.webkit.org/pipermail/webkit-dev/2008-October/005221.html
an instructive read.
This is what trolls like you want as a future for KDE?
This is your ambition for a lively and innovative free desktop?
Well, thank you for your point of view...
> People are contributing and using them without the 'big bad corporation'
> influence you are trying to insinuate.
they are being abused, and are even willing to be abused for now,
for the sake of the comfort they get from it.
does your Nokia shipped webkit engine says "Webkit Free Software project" as vendor when you paste the below?
data:text/html,alert( navigator.vendor )
no, it says "Apple Computer, Inc" and that's just the real situation today,
so be honest and don't try to lie about it.
very interesting. go team kthml go :-)
"The only guy that used to contribute to KHTML in 1999 that's working on the engine is Antti, an Apple engineer."
Lars Knoll and George Stalkos to name another two famous contributors over the years, but hey, let's not let facts get in the way of painting WebKit as some Apple oriented anti-KHTML spin because that's all you have left.
"Trolltech engineers (now Nokia) for instance have never ever made *even a single* contribution to the core engine. Never. How awkward is that for an alleged "key contributor"?"
The thing is, they don't have to. That's why there is QtWebKit and not QtKHTML, amongst one other key concern which is that more sites actually work properly with it. But, hey, let's not let practical matters that matter to users and developers alike get in the way of politics.
"For more of the same, have a look at the latest thread of poor Google engineers that have not yet understood the rules of the game, trying to propose a new URL framework on WebKit mailing lists and being told to basically stick it somewhere by the whole gang of Apple employees"
It still doesn't make the code any less useful to Google or they would have used something else. I don't recall many KHTML developers, the ones who are left at any rate, being less of a pain in the ass to deal with.
"no, it says "Apple Computer, Inc" and that's just the real situation today,
so be honest and don't try to lie about it."
Alas, all anyone cares about is their web pages rendering correctly. Arguing about anything else is fruitless, and alas, after ten years plus KHTML is simply not going to achieve that goal by itself. Ever.
> Lars Knoll and George Stalkos
They just maintain the Qt port, they do not work on the engine.
(as the rest of your post is back to repeating your usual heinous drivel and does not bring anything new, I'll just ignore it. Thanks ;-)
Why KDE if the Linux desktop has 5% marketshare?
I wish this could be stickied somehow
Isn't this just one more reason to stop having a "fork" (ok, I know the khtml is the original and webkit is the fork) instead of investing time and energy into integrating webkit that have tons of people and groups like google, nokia and apple working on? For me, and a thousand sorry if I'm wrong, it just looks like an ego thing.
I still do not see any reason why khtml must survive, exept the developers do not accept that most users just want webkit?
I use firefox in Linux, and will switch ASAP to Google Chrome, because, I'm sorry to say, it is sad to me also, but webkit evolved much-much over khtml.
"I still do not see any reason why khtml must survive"
It's part of kdelibs in KDE4, so it must be supported until at least KDE5. That's just one reason.
OK, you're right of corse, so let me correct the sentence:
"I still do not see any reason why khtml must be used in a default engine in konqueror of better alternatives do exists".
Thanks!
The only "alternative" html engine for Konqueror that I'm aware of is the webkit KPart, which is still very immature. Calling it "better" at this early stage is a bit of a stretch, if you ask me.
No. I prefer stick to khtml and does not move to webkit. We need the freedom to do what we want in our web rendering engine ! I suggest to do a campaign to attract more developer to khtml .
Actually, you don't even have to know c++ or be super smart to dive into deep khtml core code, just helping testing, dealing with bugs, reducing test pages (compare 2 reports: website doesn't render correctly or specific value of css attribute in some particular case doesn't work) will be a great help to project. And that should be something our Free community provides, in proprietary world you don't expect users to act
If you want fixes, please report bugs to bugs.kde.org, not here. We do our best to fix things, but we have to know about the problems to fix them.
P.S. The dot favicon thing is a Qt bug.
Ark was in serious need of some love since the 4.0 launch, and from what I've been reading on the Planet, it has been receiving some. I am very curious to try a recent build. Thanfully openSUSE provides near-snapshot builds.
Ark was in serious need of love since it was first created, IMO, so the recent developments are very much appreciated by me :)
xarchiver is generally the second GTK app on my system, due to Ark. (Firefox being first) This was true for KDE3 too. The interface did a whole bunch of unintuitive crap that "just worked" in xarchiver.
But then xarchiver started segfaulting opening up .tar.gzs and all was dark in the land of archive-managing-on-my-computer. Ark in KDE 4.1 came a long way, but at the time of release (and right now for all of us 4.1.x users) still has a long way to go. Luckily 4.2 should fix all these issues, and all will be well with the Force. Er, the cause for my computer with less GTK. ;-P
Agreed, it always annoys me when when distributions has it as default for compressed files. I much more prefer using Konqueror with KIOslaves and servicemenu.
It's nice to see that the range of KFormula is being expanded. However, I am still looking for a formula editor that translates LaTeX into a scalable formula representation that is well integrated and that used LaTeX for rendering. OOoLatex for OpenOffice is a killer app for me, I'd like to see something similar in KOffice.
It would be quite a big dependency for KOffice to depend on LaTeX.
text says "Now almost all the UML widgets use TextItemGroups and TextItems to display their text which has cleaned freed them" - it seems it could do with one of those words ;)
Thanks, Danny, for the Digest!
I really appreciate the design of Powerdevil (kded daemon, system setting configuration, profiles, plasmoid). I wonder if wifi/network support should be done the same way: a kded daemon checking available wifi networks, a system settings configuration to configure connections as profiles and allowing for full configuration (including routing) and a plasmoid to monitor networks and select profiles to use.
Seconded!
Take a look at:
http://websvn.kde.org/*checkout*/trunk/playground/base/plasma/applets/ne...
For openSUSE there's already a version in the buildservice, though I haven't tried this out yet:
http://software.opensuse.org/search?baseproject=openSUSE%3A11.0&p=1&q=ne...
have fun :)
Yes, please. +1 from me.
Please ditch those OpenSuse tools that doesn't integrate at all, doesn't follow mainstream development and has very slow release cycles (yes, knetworkmanager, I'm looking at you).
I disagree. IMHO the design of NetworkManager, with a system level daemon, is dead on. The design of PowerDevil (and most other power management tools), using daemons that live in the desktop session, is quite flawed. The latter don't allow for power management when no user is logged in, and it is not clear what should happen when more than one user is logged in. Relying on the whole desktop stack also makes these tools unreliable. In particular, kded will be no more stable than the least stable application that latches onto it. On one of my machines, I have to kill and restart kded at least once daily.
So, please take those sexy configuration tools, separate out the daemon part, design a DBUS protocol for specifying power management settings for communicating between the GUI and a *system level* daemon, and make power management just work!
You are so right, doing the network with a desktop session daemon would be even worse. And it would be totally useless in the enterprise, where centralized passwordservers are very common (In my experience NetworkManager does not work particularly well in such cases either:-(). Not to mention breaking stuff like NTP on bootup.
I was talking about wifi, not all network, and this is usually something done on user space anyway.
Do you guys ever consider that a good part of computer users just run their own laptop or desktop, not servers?
I mean you don't need X11 on a server either...
Well I was actually talking about wifi too, never mentioned anything about servers.
And using wifi on a laptop, or even with wired ethernet, in a corporate setting are close to useless with such session dependant tools. You are forced to first log in with a cached account, then you need to get the network running before you have to (manually) log in to your network resources/disks etc.
What I'm talking about is basically a tool to change the current configuration easily which does not stop you from having defaults. After all, it will still use wpa_supplicant and DHCP (which already run as a system daemon), which means you'll connect to default network at boot anyway if it's available.
Changing wifi network configuration is usually something you do when connected, not something done in background anyway.
Typically, I'd like something like wicd, which works well but is not completely well integrated in KDE.
I agree. There is actually work on a FreeDesktop.org specification for a DBUS interface, so this type of thing should be possible (PowerManager?).
You're talking about something different.
Powerdevil uses Solid and this uses whatever power management tool goes underneath. This means you can still have power management when nobody is connected, it just means the default power management settings (or last Powerdevil settings, I don't know) is used.
Powerdevil makes power management very simple in the exact situation where you need it (someone on his laptop or on his desktop wanting to change manually the configuration for a specific occasion) without being mandatory for power management to happen.
And what I propose would be exactly the same, since Solid would use something like NetworkManager for network configuration anyway.
There's nothing wrong wanting something that works now and is actually somewhat futureproof (nothing stops Powerdevil to use in the future some daemon doing the job). Especially since doing daemons that seem able to deal with every situation seems to be a complicated enough task to postpone anything usefull for years.
Bottom line : since Powerdevil is actually more or less what you described : a daemon, separated from the configuration tool and from the monitoring GUI, all talking using DBUS, it's closer to what you want than anything existing. I guess that once there will be a system-level daemon doing the job, the porting effort will be small. Please do go on and write such daemon.
Since then, I'm happy there's something working.
PowerDevil currently (as in current SVN) supports the standard FreeDesktop.org DBus interface. If a system daemon were running in the background (obviously, using the standard communication interface), PowerDevil would never be launched at all. As a result, zero porting effort would be necessary. Am I correct?
>> A KDE 4 port of KnowIt, a note taking application, is imported into KDE SVN. <<
Anyone knows what's up with Basket? Is it still developed? I love this tool: http://basket.kde.org/
Ask on #basket-devel, and report back with your findings :)
There has been activity as recently as 24 Sep 2008 so I presume it is still in active development.
Source for kde4 is at http://github.com/kelvie/basket/tree/master.
I'm impressed with the work being done in Umbrello, it looks really great. Being able to segment the lines is just what I need for my projects full of inter-class links.
Actually Umbrello is one very nice tool in KDE (gladly the 4 version is not like the KDE3 one that crased often) that no one really praises as we should.
I agree. This looks really nice. I think it would look even better if the lines where somewhat smoother and if the colors would be "cooler". Maybe its possible to use the oxygen color scheme or something like this. Besides that it looks cool, even though I dont have a use for this.
When I look at it I think this is kind of similar to a mind mapping software. I think this would be a great addition to the koffice suite. Right now I work a hell lot with mind mapping software and it can really stramline your workflow.
Is it a "parser" for fax documents, or a "generator"? Has the font rendering regression in Okular versus KPDF 3.x been addressed yet?
if I choose minimum memory usage strategy in okular, it crashes less often.
So you've reported all the crashes you get? Or expect them to be fixed miracously?
> if I choose minimum memory usage strategy in okular, it crashes less often.
Which crashes?
And beside that, there's exactly nothing in the code that would make a difference so radical to produce crashes between low memory and high usage configurations.
It's an okular generator, which means it generates pixmaps so the app can show you the contents. yeah probably it's a bad name for non okular developers.
Has the font rendering regression in Okular versus KPDF 3.x been reported yet?
> Is it a "parser" for fax documents, or a "generator"?
"generator" is the internal name for Okular document backends.
> Has the font rendering regression in Okular versus KPDF 3.x been addressed yet?
Nope, as Okular does not do own rendering (unlike KPDF).
Rendering bugs in PDF documents go to the Poppler bug tracking system, https://bugs.freedesktop.org, "poppler" product.
Heh... the announcement is not out yet, but Kubuntu has already pushed out the 4.1.2 packages, and they're frickin' awesome. At least two of my major pet peeve bugs have been fixed (cursor works nicely again in location bars, Klipper doesn't pop up its "Actions" menu twice anymore), and Plasma feels smoother every time I try to make it work for me. Spelling errors in text boxes are now underlined with those wavy lines instead of being painted red. And probably tons of stuff that I haven't discovered yet.
Whoo! That's the way to make the wait for 4.2 worthwhile!
KFormula as a widget could bring MathML support to KHTML, couldn't it?
If I remember correctly, this is one of the ideas of it.