|
| This Week... |
|
Final commits for KDE 4.0 Final before the tagging freeze. KDE 4.0 Final tagged for release. Lots of optimisations and bugs fixed across KDE. Kickoff menu items can now be added to the Plasma desktop or panel. Improved resize and rotate for Plasma applets. Document list sorting in Kate. Various progress in KDevelop. Mailody moves towards using Akonadi for its IMAP functionality, various improvements in Akonadi. Start of a KHotNewStuff2 implementation in Kalzium for downloading molecular files. Experimental IVTV support in the Kalva video player. KGet uses more of the shared implementation of BitTorrent from KTorrent. Printing support for the DVI backend in okular. Improved text handling, support for printing multiple page sizes in a single document, and a much-anticipated Table Flake shape in KOffice (with further work on the Music Flake shape). Lots of work on colour manipulation for KOffice. Kile begins to use Kross as its scripting framework. Start of a new KDE game, KTank. GetHotNewStuff support disabled in okular, search runner disabled in Plasma for KDE 4.0. KHexEdit moved to the unmaintained module. The new Oxygen wallpapers, splashscreen, and sound theme are imported into KDE SVN for KDE 4.0.
|
Nuno Póvoa describes his work on the Oxygen sound theme for KDE 4.0:
|
KDE came to me on the first "proper distro" I ever installed, in its 3.2 incarnation I think (the non proper one being "Floppix" :). I've always preferred it to other environments, sticking with distributions that, at the time, were tailored with KDE in mind. Slackware and Mandrake to name those that survived on my desktop the longest. So fast-forwarding maybe about 6 years I started making the sound theme for my current Kubuntu desktop - I was just bored with Kubuntu's login sound and decided to roll up my sleeves and get it going. The outline of it was done after a few hours, and a few weeks later I decided to post it on kde-look.org. The feedback was rather good, and someone said that it would be nice if Kimper (that was the theme's original name) was the default sound theme for KDE 4... who was I to oppose, right? Then a week later Nuno Pinheiro from the Oxygen icon theme sent me an email and invited me to work a bit more on the theme without too many modifications, because according to him it already had the Oxygen "zen" aura around it. I was shown some mockups of Oxygen's graphical environment and was really blown away by the sheer quality of it, and so a few meetings later I officially started working on the theme to fulfill not only my own audiophile (hah! yeah right!) fetish, but make it a bit more universal.
The idea behind Oxygen's sound theme is really to make it coherent and to have recognizable patterns that will aid the user in awareness of what kind of event is taking place - not by sounding a distinctive and out of place sound, but by enabling the user to recognize a rhythmic pattern within the same sound set. So the sound used is always the same throughout the theme making the user feel "at home", as there are no sharp turns or unexpected or violent mood shifts... just Tao (or so I hope). So with regular usage of the system one starts to recognize that every event that exposes information is portrayed by a single note: an error is a single note followed by a chord, a question is a single note followed by a short melodical phrase and so forth... so there's a rhythmic pattern that distinguishes the sounds; as opposed to other solutions out there, that rely on making the user jump off the chair every time something happens.
The opinions on the theme outside kde-look - and now that it is an official Oxygen project - have been quite mixed. Some people bash it without a moments thought because they play it in their music player of choice and obviously fail to recognize the pattern. I've also read some criticism on the sound used as being "shallow" (what you hear is a 50/50 mix of Electric Piano and Acoustic Piano), whilst others fell in love with it and the developer reaction has been quite nice, since I ended up doing sounds for other applications within KDE in accordance to Oxygen's style (the KDE game Kollision, for example). One of the hardest bits of this whole deal has actually been dealing with the harsh criticism. I think people fail to understand that when it comes to something like artwork there is no consensus. Unlike application development, you can't implement something and not make it clash with something else... adding a feature to artwork usually means a drastic enough alteration to change the whole feel of the piece. You can't please everybody... for the exact same reason you have so many sections in a music store: every one wants to listen to something different.
However, I respect that criticism, and one of the things I'd love to do for KDE 4.1 is two other sound themes with completely different auras to them, so everyone would have 3 themes to choose from and be happy... or at least close!
My experience with the KDE community was great, from "in-house" with the Oxygen team, through to developers looking for sounds for their applications... just great. I'm looking forward to developing the current theme further, adding more distinct themes, and creating more sounds for other applications within KDE. It's been a great experience all together and truly an honor to be a part of the Oxygen team and a contributor to KDE.
|
|
In a now semi-famous and widely read piece, Aaron Seigo this week addressed certain points about the impending KDE 4.0 release. As an important clarification on the most important release of the KDE project, I have reposted it here for the record. It is long - reflecting the extended development period of KDE 4 to date - but a great summary as we move into the next phase of development:
|
Now that 4.0.0 is tagged and out and that bit of worry and concern is behind me for the moment, I wanted to take a moment to talk really bluntly about 4.0. In particular, I'm going to address some of the common memes in fairly random order that i see about kde 3.5 and 4.0. I'm going to speak bluntly (though not rudely =) so prepare yourself ;)
Meme 1: What is the future of 3.5?
This year, as with most years since KDE3 emerged, there have been huge deployments of KDE 3 based software. These deployments will not shift for years to come, no matter what KDE4 is. This is because large institutional deployments (government, corporate, educational, etc) typically have 3-7 year cycles (sometimes even longer) between major changes. Patches and security fixes? Sure. Major revamps? No. This alone ensures that KDE3 will remain supported for years. Why? Because there are users. That is how the open source dev model works: where there are users, there are developers; as one declines so does the other. The developers tend to be a step ahead of the users for software that is progressive, but you'll also find that they have a foot in the here and now too (as well as the past, often).
KDE3 is still open in our svn so that bug fixes, security fixes, etc. can continue to be made. KDE 3.5.x is a rather solid desktop system and really doesn't need a huge amount of work given what it is today; the work to move it to the next level is what we refer to as KDE4, of course. This means that the efforts needed to put into it aren't huge to keep it viable. However, efforts that do go into it are welcome.
While the core KDE team will continue to concentrate our work on KDE4 since that is the long term direction of things, it is fully expected that our partners (which include some KDE core team members as employees/members) will continue supporting and even developing on KDE3 issues. The central project will also be around to lend a helping hand with advice and what not; I did that for a person the week before I left for holidays in December, actually, so it's not wild hypothesis but solid theory.
For those familiar with the open source method, the above probably sounds .. well .. obvious. That's because it is .. for those familiar with the open source method. We will find in this blog entry that many of the concerns people raise come from not acknowledging how Free(dom) software is created via the open source method.
Meme 2: KDE 4.0 isn't what a business would do
I've read exactly this statement with those literal words, but I've also read and heard what are essentially the same things put slightly differently. Well, not to play Captain Obvious too much here, but: KDE is not in the business of proprietary software. There are two parts to that statement:
KDE is not a business: we are not selling a product to the mass market. We are a development team creating the resource which can be sold to the mass market. This is an important distinction since we go through an R&D process that is very open, something that a business would have a hard time doing. We also don't pay volunteers per hour, commit or line of code. There are many things, you see, that we don't do that a business does, and vice versa. The fact that people are getting confused on this point shows how well we've done presenting KDE to the world, but we're not a business and we're not about to start pretending to be one to satisfy chin-waggers at the expense of what works for us.
... and that's a salient point: By asking KDE to behave like a proprietary company these people are asking KDE to abandon what has worked for us all these years. They are asking us to abandon our identity, to cease doing what resulted in the Free software desktop going from non-existent in the mid-90s to parity in just over 10 years. Remembering that we started 15 years (and multi-billions of dollars) behind our competition that's a pretty impressive success story.
At the same time, KDE works with business. We have relationships with companies at many levels, technical and otherwise. In order to provide good guidance to our partners we've been pretty blunt about what 4.0 is. That is because while KDE itself isn't a business, we have a large business ecosystem around us. We are a good business partner, even if we ourselves aren't a business. I know, this is rather paradigm shifting for a lot of people out there, but that's what makes it fun and enjoyable for so many of us.
KDE is not a proprietary software product: this is another obvious statement, but it's one people seem to forget. While there is proprietary software that gets written using KDE technology, KDE itself is not and never will be proprietary.
In the open source method you release early, you release often. By doing so, a progression is presented that people can follow with fairly blunt (often overly pessimistic) guidance along with it, e.g.: "foobar v 0.0.1: will eat your children". In theory you can't do that with proprietary software due to the distribution mechanism and economic repercussions (though many companies do anyways), but with open source it is exactly what one must do to get the production wheels turning.
KDE 4.0.0 is our "will eat your children" release of KDE4, not the next release of KDE 3.5. The fact that many already use it daily for their desktop (including myself) shows that it really won't eat your children, but it is part of that early stage in the release system of KDE4. It's the "0.0" release. The amount of new software in KDE4 is remarkable and we're going the open route with that. Which brings us to the next meme:
Meme 3: Just keep releasing alphas until it's ready
Ah, the "until it's ready" idea. Some would say 3.5 isn't ready; software never really is from a perfectionist's standpoint. It's so complex and full of ever springing promise that one can never reach that point of perfection; usually we are just happy with "better than good enough" and call it a day at that point.
KDE 4.0 isn't yet "better than good enough"; so why don't we just release more betas? When one perpetually releases alphas/betas a few things happen: people don't test it aggressively enough, third party developers don't get involved, core developers continue doing blue sky development rather than focusing on release qualities.
Between the RC's and the tagging of 4.0.0 the number of reports from testing skyrocketed. This is great, and shows that when I assert "people don't test when it's alpha or even beta" I'm absolutely correct. This is not about tricking people either: people seem to forget that the open source method is based on participation not consumption. So testers look for a cue to start testing; that is their form of participation. "alpha" and even "beta" is often not enough of a cue, especially today when so many of our testing users are not nearly as technically skilled with the compiler, debuggers, etc as the typical Free software user was 10 years ago.
The KDE4 libraries are ready for application development, as testified to by the quality KDE4 apps that exist today. However, third party application developers tend to be a conservative lot, and rightly so. They wait for user base migration, they wait for stability in the APIs, etc. They want to know when to start working with the new awesomeness, and for most of them that isn't "alpha" or "beta". The libraries crossed that stage in quality and reliability many months ago and so it is only fair to mark them as such.
Finally, the amazing maturation at all levels of KDE 4.0 software that has happened since the last beta shows just how focusing developers off of blue sky development and onto release quality code is important. The delta speaks for itself.
Meme 4: KDE doesn't do time based releases
When I hear this statement, I know I'm either dealing with someone who has been around the community for less than 2 years or has a long term memory problem. KDE has traditionally done time based, not feature based, releases: the project would set a target date, people would create a list of expected features they can do in that time, features that didn't make the target date would get punted to the next release.
In my time with the project we have done 2 feature based releases: both for major overhauls of the entire system. The first one resulted in the pedigree that would become KDE 3.5. The second one is KDE 4.0.
In that same time period we did 8 time based major releases (2.1, 2.2, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5) and countless time based minor releases (8 for 3.5 alone). In each of these releases a target was set and in the overwhelming majority of these cases that target date was hit.
With 4.0 behind us and marching towards 4.1, we'll be back to these time based releases.
Meme 5: What's the quality of KDE 4.0?
KDE 4.0 rocks in a number of ways. Whether one looks at the new frameworks (solid, phonon, akonadi et al) or the revamped existing ones (kconfig getting multiple back end support, the UI-less kdecore), or examines the apps like okular or kdeedu or the games or dolphin or ksnapshot or konsole (ok, I won't list every app) or many of the new workspace features like composite and widgets or the new artwork or ... you get the picture. There's a lot that is just amazing.
What leaves people wondering about quality is that there is a disparity between our stated end goals and 4.0. This is, to be blunt, due to a lack of experience on their part: most people have never been involved in the creation of something great. We're involved in making something great that will end up spanning a decade of effort and be used for even longer than that. To be able to accomplish such a thing one requires the ability to see beyond today and into the uncertain future. They also need to be able to adjust and shift that vision as things evolve (ergo the shift from tenor to strigi/nepomuk, even though the end result is essentially the same ideas). It is simply not possible, without extreme luck similar to winning the lottery, to create something great without that vision. This is not my idea, this is the result of pretty much every bit of research and practical analysis from the business operations world.
More on the concept of vision
To re-affirm: our stated goals for KDE4 remain and they haven't gone anywhere. In fact, KDE 4.0 is the first proof that this is not only vision or, worse, vapour: we're putting it into action. However, long term vision is not met in a short term effort. Vision of the end is what directs immediate efforts into mid-term and eventually long-term successes. We will get there, and probably beyond what we currently imagine, with the releases that will follow. Each stop along the way will rock harder, and none of them will suck. Importantly: nont of it would be possible without the vision.
So it's ironic that some would see the vision we are committed to as reflecting on us in a bad way, since it's what is enabling us to deliver a great product not just today but in the future. Companies usually keep this vision internal and you never really get to see it from the outside. Sure, the ghosts of the vision get communicated eventually through marketing slogans (if they do their job right, anyways =), executive communications, AGMs, etc. but generally it's internalized.
KDE is an open project, however, so we can't talk about our vision without it getting "out there". There is simply no way for us to "keep our light hidden beneath a basket". So while it's ironic, it's not an unexpected consequence: most of our audience is simply used to being on the outside. They are not used to freedom, they are not used to openness, they are not used to being privy to the internal world of others.
For better or worse, there is no way we can shield them from being able to see our vision. As a project we need to talk about it with each other a lot: openly, loudly, even argumentatively at times. So everyone gets to see it, and some mistake the vision creation and maintenance process for marketing effort or spin; they are unrelated. What's funny is that community news sites will actually pick up the evolution of our vision as news events; it's undeniable that people find it interesting, which is pretty cool.
So to achieve what we want to, I've come to realize that I'll take it on the chin, so to speak, from some people who aren't able (yet?) to internalize what this process is all about. I can't in good conscience suggest we divert in response to this particular set of feedback, though, as it would cripple the project in the long term.
Many companies in Europe and North America have been criticized by the business management community for a couple decades now of not investing enough in mid-term (let alone long-term) projects. They have trouble doing so due because they allow themselves to be led by the nose by the financial and consumer markets copuled with vision-lacking internal assignment of resources. Yes, you're reading that right: listening to the short term consumeristic demand of the populace has been a major component of the march towards much of the stagnation and crappy products and services we get to deal with today. Ignoring the short term is foolish, but not investing in the mid-term is equally so.
I don't expect the populace to suddenly get long-term vision; I do expect serious organizations to stop setting their agendas by the flawed clock of the short term thinking that (inevitably?) dominates large societies of people.
To bring it into high-relief: KDE3 is our current product line for production, and KDE4 is our mid-term production line. For there to be any KDE worthy of succeeding KDE 3.5, we needed a mid-term project. No short-term project would cut it. We're at the beginning of where we can bring KDE4 into "current produce line" condition, which is to say that KDE4 is that transition period from mid-term to short-term project. That's exciting, and one more reason 4.0 rocks.
Epilogue
To close I'd like to recognize that KDE as a project is not perfect; we are made of fallible humans engaged in an amazingly complex process. All the same, the people involved are pretty amazing and competent. We're on a good path right now as a result of those people. If you find this process hard to understand that, try to adjust your assumptions and deeply internalize the concepts of the open source method since that is our guiding light. In spite of some of you finding it hard to understand this process, we won't betray you by switching to an inferior plan just because it fits your assumptions better. Even those who are most concerned today will thank us further on down the road.
Ok, enough about that. I've said what needs to be said and won't say more about it from here on out. I have a huge backlog of blog topics to cover that are more interesting and positive in nature. I'll do my best to keep them shorter than this one ... but no promises there ;)
|
|
The last week included the final days of KDE 4.0 development before the total tagging freeze on Friday, January 4th. As expected, the lull in development of the week before was smashed this week, with 3307 commits (646 more than last week, which wasn't even an exceptionally slow week!), and more importantly, I found the commits this week to be more interesting: there are more than double the number of selected commits in this issue than in the last.
|
By the time the next issue of the Digest is released, KDE 4.0 Final will have been officially released to the world (January 11th is the expected release date). Though many people within the KDE project would not have expected such a marathon development effort back in 2005, when KDE 4 was only in the imaginations of developers, it is what it is - and everyone I know in the KDE project is proud of our collective acheivements. The future is now, and it looks brighter than ever.
|
|
| Statistics |
|
| Contents |
|
|
Bug Fixes |
Features |
Optimise |
Security |
Other |
|
Accessibility |
 |
|
|
|
|
|
Development Tools |
![[*]](/images/standard/bugfixes) |
![[*]](/images/standard/features) |
|
|
![[*]](/images/standard/other) |
|
Educational |
|
|
![[*]](/images/standard/optimise) |
|
|
|
Graphics |
|
|
|
|
|
|
KDE-Base |
|
|
|
|
|
|
KDE-PIM |
|
|
|
|
|
|
Office |
|
|
|
|
|
|
Konqueror |
|
|
|
|
|
|
Multimedia |
|
|
|
|
|
|
Networking Tools |
|
|
|
|
|
|
User Interface |
|
|
|
|
|
|
Utilities |
|
|
|
|
|
|
Games |
|
|
|
|
|
|
Other |
|
|
|
|
|
|
|
Bug Fixes |
|
|
|
Educational |
|
Inge Wallin committed changes in /trunk/KDE/kdeedu/marble:
|
Fix bug 154700: Newly downloaded maps are not usable without restarting Marble
TODO: make downloaded mapthemes uninstall when the user clicks "Uninstall". This may be a bug in GHNS, though, and this code should reflect deletions as well as additions. |
|
|
|
|
|
|
|
|
|
|
|
|
Germain Garand committed changes in /trunk/KDE/kdelibs/khtml:
|
.Cope with set{Vertical,Horizontal}ScrollBarPolicy not being virtual anymore in Qt 4. Too bad we actually thought we reimplemented them.
How viciously stealth such a bug can be is beyond description ;(
major bug 153036. |
|
|
|
|
|
|
|
|
Charles Samuels committed changes in /trunk/KDE/kdelibs/khtml/rendering:
|
Allow padding of form elements in the case of border-box, which causes the form element widget to get bigger but its active region to stay the same size.
This is sometimes used to put little icons on lineedits.
In the case of the content-box model, the padding goes around the form element, as it is today (also the default in non-quirky mode).
There's still a strange bug with how the scrollbar on scrollable widgets doesn't have any hover effects and it has the "text input" cursor. But that's not a regression and is tolerable, so we decided to accept it until we have a chance to clean up render_replaced.
Reviewed repeatedly by Germain. |
|
|
|
|
|
|
|
|
Robert Knight committed changes in /trunk/KDE/kdebase/apps/konsole/src:
|
Fix bug where search result highlights in the terminal display did not move when the display was scrolled. When the search bar is active, update the filters and the view whenever it is scrolled or the output otherwise changes.
This has a perceptible (but in future fixable) performance impact when scrolling with the search bar active. |
|
|
|
|
|
|
|
|
|
|
Germain Garand committed changes in /trunk/KDE/kdelibs/kdeui/widgets:
|
fix the "Lock/Unlock Toolbars" feature so that its state is remembered accross application restart.
also fix a bug in KToolBar where the Lock/Unlock toggling in the toolbar contextual menu would go out of sync from one toolbar to the other. |
|
|
|
|
|
|
|
|
|
|
|
|
Jakob Petsovits committed changes in /trunk/KDE/kdebase/apps/dolphin/src:
|
ARGH!
No, but really, we can't ship Dolphin with a missing toolbar icon. And no, I have no clue why it won't use that "pics" folder that I was generating for that icon.
Apologies? |
|
|
|
|
|
|
Kévin Ottens committed changes in /branches/KDE/4.0/kdelibs/kdeui:
|
Reverting commit 757034 which was completely preventing to configure any global shortcut. This issue will obviously require more investigation...
OK'd by Tom Albers.
We probably want that hotfix in the 4.0.0 tag. Otherwise we're shipping a desktop where we can't configure the desktop related (kwin, krunner, plasma) shortcuts and any other global shortcuts.
Dirk, any chance to get that in the release? |
|
|
|
|
|
|
|
|
KDE-PIM |
|
Jason vanRijn Kasper committed changes in /trunk/KDE/kdepim/kpilot:
|
* Forward-porting rev 754992 from 3.5 branch:
* Fixing bug reported by Pablo Yepes on kdepim-users mailing list. We did severe goofiness with middle names... The Palm can't handle them, so we blindly tacked firstname + " " + lastname and stuck it into the Palm's firstname field. The problem is that whenever a copy from palm->pc is done, the kludged first name is transferred to kabc ("firstname middle").
And, it's compounded by every change in either direction. It's an ugly hack and I've removed it. The only way to work around it would be to add an additional check for !firstname.endsWith(abEntry.additionalName()), but that's even sillier. Stop the insanity! |
|
|
|
|
|
|
|
|
|
|
|
|
Features |
|
|
|
Anders Lund committed changes in /trunk/KDE/kdesdk/kate:
|
implement document list sorting.
works here, but please test, as kde 4 is not usable for me, and i consequently almost never launches anything from it. |
|
|
|
|
|
|
Hamish Rodda committed changes in /trunk/KDE/kdevelop/plugins/valgrind:
|
Working, at last - for memcheck, that is. I ported to QXmlStreamReader and that allowed me to feed the XML in as it was received (contrast to the old QXmlSimpleReader, which threw up end of file errors and the like).
I guess it will need a compatability mode for non-xml producing tools
Also the app output still goes to /dev/limbo, not sure why... |
|
|
|
|
|
|
|
|
Frederik Gladhorn committed changes in /branches/work/kdeedu_parley/libkdeedu/keduvocdocument:
|
Enable the readers including kvtml-1 also in code and finish porting it to a works somewhat state.
Reading subwordtypes is still not working because they are not created correctly in the init section of the compability class.
Remove last references to usage stuff (no one will miss it).
Some cleanup of the horrible horrible kvtml-1 reader code.
I will have to drop the kvtml-1 writer. Too much effort and too many things that cannot be saved in the old format. |
|
|
|
|
|
|
|
|
Frederik Gladhorn committed changes in /trunk/KDE/kdeedu:
|
Redo of the lib. Merge of the 4.1 branch to trunk.
This is a rather big change, which affects the apps using libkdeedu.
I guess there are quite a few bugs left. So far I know the destructor of either expression or translation sometimes seems to double delete. Need to look into that.
Start an experimental new practice app that is independent of the main app. Still hardly anything implemented there.
Parley: New main window gui using dock windows. The edit entry dialog does no longer exist. It is much nicer to edit vocabulary now.
Ported KHangMan, KAnagram, KWordQuiz and Parley
Notes:
- Containers: There are two subclasses for KEduVocContainer.
KEduVocLesson and KEduVocWordType. This is very benificial as from now on, I can use the same models/views for both in parley. Leitner boxes are also easy to realize subclassing the containers.
-The KEduVocDocument class was huge and contained some functions specific to expression handling. This redundand api has been removed.
Instead the document now contains one root lesson (KEduVocDocument::lesson()) to manage all entries. This lesson can contain entries directly as well as child lessons. This makes it easy to access all vocabulary entries by using doc->lesson()->entriesRecursive() which collects all entries including those from sublessons.
- Lessons and word types are now able to contain child lessons/word types to an arbitrary depth.
- Entries can be in multiple lessons.
- Expression->translation() now returns a pointer. This is more consistent and avoids some reference trouble. In general now everything is a pointer (containers also).
- KWordQuiz now saves the size hints per document in the kconfig. This could also be used for cell heights.
- KWordQuiz only edits entries in the top level lesson. I'll change it to use all entries in the document.
- Statistics in Parley are disabled for now, needs to be rewritten.
- Usages have been removed completely.
- Comparison forms do no longer have a proper class but only two strings.
Eventually it should be considered making them a class to support male/female again. The base form should always be the adjective/adverb itself.
I hope everything works, but I must have missed something. Bug me. |
|
|
|
|
|
|
|
|
Graphics |
|
Gilles Caulier committed changes in /branches/extragear/kde3/graphics/digikam:
|
digiKam from KDE3 branch: important changes here : add capability to display count of items in all Folder View.
The number of items contained in virtual or physical albums is now displayed on the right of album name.
If a tree branch is collapsed, parents album sum-up the number of items from all undisplayed children albums.
Count of items is performed in background by digiKam KIO-Slaves.
A new option from Setup/Album dialog page can toggle on/off this feature.
Screenshot of digiKam in action using this new feature can be seen at this url:
http://bugs.kde.org/attachment.cgi?id=22233&action=view
Folder view witch supports this feature are:
- Physical Albums from left side bar.
- Virtual Date Albums (calendar) from left side bar.
- Virtual Tags Albums from left side bar.
- Virtual Tags Albums from Captions & Tags right side bar tab.
- Virtual Tags Albums Filter from right side bar.
Note: for performance reasons, Search folder view do not support count of items. Search queries on digiKam database can take a while and slow down digiKam reactivity. See B.K.O 96388 story for details... |
|
|
|
|
|
|
Marcel Wiesweg committed changes in /trunk/extragear/graphics/digikam/libs/database:
|
Use DBus to dispatch change notifications about the database from slaves (and from other running instances).
The Changeset objects are serialized as DBus custom types and emitted with identifiers of the sending process and the affected database.
Slaves emit signals with their object implementing the org.digikam.DatabaseChangesetRelay interface.
"Masters" emit signals with a different object implementing the interface, meant for peer masters, and receive signals from both.
Changesets are received and dispatched like local signals. |
|
|
|
|
|
|
|
|
|
|
|
|
Pino Toscano committed changes in /trunk/KDE/kdegraphics/okular:
|
Start adding a configuration to toggle anti-aliasing for both text and graphics.
Let the Document propagate these settings to the backends, if they query for them. |
|
|
|
|
|
|
Marcel Wiesweg committed changes in /trunk/extragear/graphics/digikam/libs/database:
|
Add methods to read to structures from the database, similar to the PhotoInfoContainer for DMetadata.
The information is read by ImageScanner, this is because this class knows the dirty details of how to read information into the db, so it is the best place to know how to interpret them.
The API to retrieve the containers of course is added to ImageInfo |
|
|
|
|
|
|
|
|
|
|
|
|
Luboš Luňák committed changes in /trunk/KDE/kdebase/workspace/kwin:
|
Support for getting PropertyNotify events - effects can have their own properties for communication with something outside of kwin.
Intended now mainly for a better taskbar thumbnails effect. |
|
|
|
|
|
|
Jakob Petsovits committed a change to /trunk/KDE/kdelibs/cmake/modules/KDE4Macros.cmake:
|
Add missing icon contexts to the kde4_install_icons() macro.
In case you didn't know it (I didn't as of a few minutes ago):
You can use the exact icon context names in the filenames of your installed icons. If you ever wondered where the "app" in ox22-app-mykdeapplication.png came from: that's just KDE 3 compatibility. Using the real name of the context, "apps", works just as well: ox22-apps-mykdeapplication.png
(This also works with "actions", "status", "places" and whatever icon contexts the icon naming specification defines.) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Harri Porten committed changes in /trunk/KDE/kdelibs:
|
|
ugly but makes khtml use Qt Unicode support without restricting licensing of apps using libkjs. Todo for later release: pick up more advanced impls in JSC for Qt 4.3. |
|
|
|
|
|
|
Brad Hards committed changes in /trunk/playground/libs/kcabinet:
|
OK, now it really works with Cabinet files that are spread over more than one block (i.e. >32K in size).
The missing part came from a hint from Mark Adler, who advised:
Someone else was emailing me about this recently. They found out that each subsequent block uses the previous 32K block as a dictionary. You can use inflateSetDictionary() to set the dictionary for the next block before decompressing.
Also, update the unit test. I wasn't reading the khexedit display correctly. |
|
|
|
|
|
|
|
|
|
|
Alex Merry committed changes in /trunk/KDE/kdebase/workspace/libs/plasma:
|
Improve the resize/rotate interface:
We now have a separate resize button. The rotate button just rotates.
The resize button scaled with fixed aspect ratio by default, or freely with CTRL.
It's trivial to change it so it resizes freely by default (or to change the access key) if we want. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Emanuele Tamponi committed changes in /trunk/koffice/krita/plugins/painterlyframework:
|
|
Changed the infrastructure. Now both half and float are supported (half still to load in the registry, but it should work flawlessly) and a variable number of wavelengths (just for testing purposes, while looking for the best number). Tests work. |
|
|
|
|
|
|
|
|
Jan Hambrecht committed changes in /trunk/koffice:
|
* implemented support for putting text on QPainterPath
* added support for text anchor for simple text shape
* some api changes in simple text shape
* ported svg text import to simple text shape |
|
|
|
|
|
|
Michel Ludwig committed changes in /trunk/extragear/office/kile/src:
|
- Start to use Kross as scripting framework.
- Split the kilejscript.* files into separate binding and script manager implementations.
- Remove references to KJS. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cyrille Berger committed changes in /trunk/koffice:
|
* introduce merging of meta data store
* add some UI to select the merging strategy
* add three merging strategy : drop, priority to bottom layer, only equal meta data |
|
|
|
|
|
|
|
|
Boudewijn Rempt committed changes in /trunk/koffice/plugins:
|
|
Registery the table shape using the right element type and context (for standalone tables, something OOo cannot do, apparently). |
|
|
|
|
|
|
|
|
|
|
David Jarvie committed changes in /branches/KDE/3.5/kdeutils/kmilo/generic:
|
Use KMix master device to adjust volume and mute. It uses a newly committed addition to KMix's DCOP interface which allows the master device to be determined.
Fixes commit 624936 which broke things completely for laptops which don't use device 0 as the master.
This patch was contributed by Kelvie Wong. |
|
|
|
|
|
|
David Faure committed changes in /trunk/playground/utils/charm/trunk/Charm:
|
Added RMB / Rename Task, so that double-clicking a task (in the name column) can start the timer, like in karm.
(renaming a task is a very very rare operation, so we don't need in-place renaming for that) |
|
|
|
|
|
|
|
|
|
|
|
|
Optimise |
|
Educational |
|
Jasem Mutlaq committed changes in /trunk/KDE/kdeedu/kstars/kstars:
|
The INDI network backend was migrated to fully use Qt, this along with changes in the INDI parser led to orders of magnitudes improvement in processing and constructing on the fly devices. Binary BLOBs gained the most advantage, loading an average FITs file from the CCD now takes 20% of what is used to take.
It is now possible to start multiple devices managed by one INDI server vs the one-device-one-server behavior before. This model has also resulted in unifying server and local devices with remote devices and that in turn greatly simplified the code. Now that this is the 4.1 branch, there is quite a bit of refactoring to improve consistency. |
|
|
|
|
|
|
|
|
|
|
Germain Garand committed changes in /trunk/KDE/kdelibs/khtml:
|
rework CSS3 opacity, for correctness and workable speed.
* Try hard to minimize the painting region.
* Blend layers atomically after off-screen rendering.
* Rework the PaintBuffer so that it can provide multiple buffers.
* Each transparent object must define a new stacking context so that their rendering sub-tree appears as atomic to ancestors, as wanted by CSS3. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Urs Wolfer committed changes in /trunk/KDE/kdebase/runtime/pics/oxygen/scalable/actions:
|
Optimize PNG files again.
Last optimization has been done almost two years ago. There a lot of new files in trunk (e.g all Oxygen stuff).
It's not the correct time to do that again (before the release).
This run saves again around 10MB of diskspace without any restrictions. |
|
|
|
|
|
|
Urs Wolfer committed changes in /trunk/KDE/kdebase/runtime/pics/oxygen/scalable/actions:
|
Re-compress svgz files with:
find . -name "*.svgz" -exec advdef -z -4 '{}' \;
That saves around 6MB in trunk without any restrictions.
Also correct the svn mimetype for all svgz files which had a wrong one (which is thy reason why my fist commit failed...) with:
svn propset svn:mime-type 'application/octet-stream' |
|
|
|
|
|
|
Other |
|
|
|
Educational |
|
Torsten Rahn committed changes in /trunk/KDE/kdeedu/marble/src/lib:
|
- Beautify version number a bit more ;-)
- Bumping up the maximum zoom position of the slider. Once the data is in place that should allow a maximum zoom down to about 100m/pixel. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Emanuele Tamponi committed changes in /trunk/playground/graphics/tamponi/painterlyframework/utilities/src/ipg:
|
Finally, I decided to use both the "good mix" profile and the "good" profile. This means that while "good mix" provides better mixing capabilities, it's not sure that it will converge for every color, so it's better suited to be use with KisKSLCColorSpace.
The "good" profile always assure to converge into a reasonable reflectance spectrum, so it will work with both KSLC and KSQP. makedefault.* script are provided to generate the the default profile that are loaded with Krita. |
|
|
|
|
|
|
|
|
|
|
|
|
KDE-Base |
|
Urs Wolfer committed changes in /trunk/KDE/kdebase/workspace:
|
Update artwork for logout dialog:
New Oxygen design
The sourcecode has no new features. I have only changed coordinates, colors and such things.
Due to render problems in Qt, we use a 'pre'-rendered svg image (exported as png and imported again into the svg).
The real source svg is also included: shutdowndialog.source.svg
I have also moved the button svgs into the main theme svg (with a different object id).
This dialog needs some more love after feature freeze is over:
* do not hardcode fonts and colors
* improve strings
* probably change buttons layout
* ...
For informations of the moon image used, see the CREDITS file (photo released under a Creative Commons license).
I think this file should be enough; if not, please tell me.
Thanks a lot Pinheiro for the great work! |
|
|
|
|
|
|
|
|
Jeremy Paul Whiting committed a change to /trunk/KDE/kdelibs/knewstuff/knewstuff2/core/coreengine.cpp:
|
default to automationOn automation policy, comment out extra unneeded code to load entries again based on automation policy, cache feeds with the feedname instead of the three question marks that were in there, cache entries in the componentnamed subfolder they belong to
Caching is now almost functional, except that cached entries are added to the feed and their equal internet entries are also added to the same feed currently... I'll try to find a BC way around that tomorrow hopefully. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Jason Stubbs committed a change to /trunk/KDE/kdebase/workspace/plasma/plasma/plasmaapp.cpp:
|
|
Dynamically set the pixmap cache size to the greater of 1.1 times the screen resolution and 1% of physical system memory. This should be enough to carry over until there's many SVG based applets available for people to run and overload their systems with. ;) |
|
|
|
|
|
|
Luboš Luňák committed changes in /trunk/KDE/kdebase/workspace/kwin:
|
Don't apply DimInactive effect to override-redirect windows. Things like popups should be short-lived and mostly for the active window anyway.
Possibly could be revisited in the future when support for window grouping for unmanaged windows gets implemented too. |
|
|
|
|
|
|
|
|
Will Stephenson committed changes in /trunk/KDE/kdebase/workspace:
|
|
Add new Display systemsettings category to group the display settings. Recycling kcontrol's Display i18n, so shouldn't hurt too much. Change semi-ok'ed by Thomas Reitelbach on kde-i18n-doc |
|
|
|
|
|
|
Aaron J. Seigo committed changes in /trunk/KDE/kdebase/workspace/plasma/desktoptheme:
|
new panel and dialog backgrounds, but QSvgRenderer is misreporting the size of the elements by one px each! i have no idea why and have banged my head against this one for hours now. *sob*
maybe zack can find something wrong here; the svgviewer example in qt doesnt render it properly either (there's an extra line in between the grouped elements even at 100% zoom); zack: if you dont' have time energy or care to look at this don't worry, it's just a long ball to you as i'm baffled atm. |
|
|
|
|
|
|
|
|
Jason Stubbs committed changes in /trunk/KDE/kdebase/workspace/libs/plasma:
|
Speed up the toolbox animations a bit. Arbitrary values, but 250ms still looks smooth here whereas 200ms (what I really wanted) doesn't. Nothing else appears to use Phase::moveItem() at the moment so am changing it directly.
The duration change in ToolBox is so that the moveItem() animation and customAnimation match up exactly. |
|
|
|
|
|
|
Aaron J. Seigo committed changes in /trunk/KDE/kdebase/workspace/plasma/desktoptheme:
|
it occurred to me that by making border stretchable we could avoid the dotted border problem.
it does lead to a slight odd "center highlight" effect on the top (again due to QSvgRenderer getting the size of this element wrong) but it looks way better; this svg will still suck for panels on the top, left or right because you'll just get a black border...
but then since when was artwork in plasma ever something anyone actually paid any concern over. =( |
|
|
|
|
|
|
Aaron J. Seigo committed a change to /trunk/KDE/kdebase/workspace/plasma/applets/icon/icon.cpp:
|
arbitrary upper limits are probably not a good idea; just don't make them so big if you won't want them that big. as for cpu usage, even HUUUGE icons on my 1.8Ghz machine don't even make plasma cough.
i'm sure with complex enough svg icons and a slow enough processor it would have a rendering impact but, again, just don't make them so frigging huge then. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Riccardo Iaconelli committed changes in /trunk/KDE/kdebase/workspace:
|
Get rid of the old wallpapers, get in a new test one, and uncomment some code in the dialog to make packages work.
Forgive us if you're without wallpapers for one hour, we're fixing this to get the new wallpapers in! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rafael Fernández López committed changes in /trunk/KDE/kdelibs:
|
This field should have never been translated. It began to be translated really late, and it was breaking KPluginSelector. This field is internal and never is shown to the user.
Plasma will need to use an extra field for using internationalized categories. Thanks to Bille, aacid, annma and everyone involved. |
|
|
|
|
|
|
|
|
Jakob Petsovits committed changes in /trunk/KDE:
|
|
I removed that "network" sucker icon two times already, but it likes to go the way of the undead. Having this one was one of the few icon showstopper issues (potentially impeding icon theme interoperability) and no matter how frozen the Oxygen theme is now, this icon needs to go. |
|
|
|
|
|
|
|
|
|
|
Robert Knight committed changes in /trunk/KDE/kdebase/apps/konsole/user-doc:
|
|
Move out of date documentation into historic/. I am not removing it from the repository completely because the content may still be of interest to some people. The remaining README files in this directory are still mostly relevant and correct. |
|
|
|
|
|
|
Peter Penz committed a change to /trunk/KDE/kdelibs/kio/kio/previewjob.cpp:
|
|
Increase default preview size from 1 MB to 5 MB. TODO: it would be nice if PreviewJob would provide a static getter method for accessing the default size, so that applications like Dolphin - which allow to change the size - know the initial value. |
|
|
|
|
|
|
Aaron J. Seigo committed a change to /trunk/KDE/kdebase/workspace/libs/plasma/widgets/tooltip.cpp:
|
* 150ms delay for already shown tooltips, just as we did with kicker, to prevent overwhelming lower end cpus (or network connections, for that matter)
* 500ms delay for new tooltips up from 300ms which worked rather nicely in kicker as well
(trying to learn from kicker, not forget it ;) |
|
|
|
|
|
|
KDE-PIM |
|
Tom Albers committed changes in /trunk/playground/pim/mailody:
|
Mailody prepares for a rewrite based on the akonadi backend. Because kdepim will not be released and we do not wat to depend on kdepim, we include a copy of akonadi via a svn external.
Akonadi comes with some dependencies, like maildir and some files of libkdepim. This commit should deal with all that. |
|
|
|
|
|
|
Allen Winter committed changes in /trunk/KDE/kdepim/korganizer:
|
by default, put the views toolbar on the right side of the app.
there are simply too many views now to go along the top.
of course, users can move this toolbar if they like.
hope this doesn't break the HIG. |
|
|
|
|
|
|
Volker Krause committed changes in /trunk/KDE/kdepim/akonadi/server:
|
- disable the MySQL/Embedded plugin for now, it's currently not used and causes linking problems on Debian-based 64bit systems
- don't hardcode the path to mysqld |
|
|
|
|
|
|
Multimedia |
|
Nikolaj Hald Nielsen committed changes in /trunk/extragear/multimedia/amarok/src/playlistbrowser:
|
This has got to rate among the top hacks of the year.... Make the PodcastCategoryDelegate's resize when they are selected so that additional info can be displayed.
Qt does not handle this use case very gracefully as the sizeHint function is not even called in many cases unless you kick the view rather hard.
Also, the option.state is never selected in sizeHint for some reason... |
|
|
|
|
|
|
Jakob Petsovits committed a change to /trunk/KDE/kdemultimedia/kscd/docking.cpp:
|
Don't know if I'll make friends with that one, but kscd should use its app icon for docking like all the other nice apps do.
It doesn't do playback visualization or any fancy stuff, so there's no additional value that gets lost when switching back to the original kscd icon. (And the previous dock icon was just a simple audio CD anyways.) |
|
|
|
|
|
|
Koos Vriezen committed changes in /trunk/extragear/multimedia/kmplayer/src:
|
Remove the playlist resolving also changing the on status of the play button
Select input on the embedded windows and children to get in fullscreen a chance to get out of it by hovering over the bottom of the video.
Also the key press of 'f' is working. Needs a bit more thinking what to do with flash, now in a khtml page, moving the mouse too easily triggers the controlbar popup up (not that this is very funny, and hey this is an extra gear :).
Fix issue that flash and phonon would often disappear when going to fullscreen. |
|
|
|
|
|
|
|
|
Tejas Dinkar committed changes in /trunk/playground/network/kopete/protocols/bonjour:
|
The New Year's Commit... Happy New Year (esp all in #kopete)
Introducing the BonjourContactConnection, which is a class that wraps a QTcpSocket, which will soon be an attribute in BonjourContact. XMPP-related Code should be here |
|
|
|
|
|
|
|
|
|
|
Tom Albers committed changes in /trunk/KDE/kdenetwork:
|
|
lanbrowsing is not ready for release and the maintainer has asked for removal to the unmaintained area. The functionality has been replaced by zeroconf if I understand correctly. |
|
|
|
|
|
|
|
|
Urs Wolfer committed changes in /trunk/KDE/kdenetwork:
|
|
Enable KGet Torrent plugin when BTCore (KTorrent) can be found on system. We need to think about that: probably we will copy a snapshot from the ktorrent lib to KGet later? |
|
|
|
|
|
|
|
|
|
|
Emanuele Tamponi committed changes in /trunk/koffice/krita/plugins/painterlyframework:
|
|
Almost definitively remove sRGB <-> RGB conversions because they're not useful in terms of visualizations and give bad mixing performance. Use the latest profile as default since it mixes veeeeery well. Don't compile anymore KisKSLinearColorSpace and remove it from the tests. Probably other fixes I don't remember. |
|
|
|
|
|
|
|
|
Emanuele Tamponi committed changes in /trunk/koffice/krita/plugins/painterlyframework:
|
Definitively, QP is not the better way to achieve good conversions from RGB because it needs to be *too* precise, loosing other performances (it's slow, for example, and gives not perfect mixing capabilities).
Anyway, it's good enough to work with 6 (six!) wavelengths.
Last note: I noticed that compositing may not work perfectly (and it's not intended to). |
|
|
|
|
|
|
|
|
Emanuele Tamponi committed a change to /trunk/koffice/krita/plugins/painterlyframework/channel_converter.h:
|
A complete understanding and evaluating of this colorspace would take probably another year, because it depends on a set of parameters and equations that I've "invented" without studying their consequences and behavior.
It would be interesting in future work to study a bit what happens to the colorspace when you change the equations and paramethers while keeping the basic conditions.
First try (and last, for now): change the blackening function from
Rb = B_2 * R^2 + B_1 * R + B_0
to
Rb = B_2 / R + B_1 * R + B_0
the mixing capabilities are pretty much the same but I can see a wider spectrum of greens |
|
|
|
|
|
|
|
|
|
|
Emanuele Tamponi committed changes in /trunk/koffice/krita/plugins/painterlyframework:
|
Various changes. Most important:
- now the color space loading code is much cleaner
- the tests have been rewritted in order to do some checks and they works great
- the mixing test has been disabled (completely removed) because I need to rewrite it as it will be the base upon which I'll draw all the graphs I'll need in future works. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Jakob Petsovits committed changes in /trunk/KDE/kdebase/runtime/pics/oxygen:
|
ruphy said they wouldn't kill me, he also says he can't commit it for some technical reasons, plus the transform-move icon is used in several places because it has been promised. (And would be missing otherwise.)
Committing the new icon, transform-move, on ruphy's behalf.
Forgive me for breaking the tagging freeze. |
|
|
|
|
|
|
Utilities |
|
Friedrich W. H. Kossebau committed changes in /:
|
Moving KHexEdit to the Off, as dicussed with the release team.
Is only halfways ported to KDE4 (compiles at least) and has no active maintainer.
Let's hope Okteta is ready for KDE 4.1 to close the gap this is leaving.
Kept the Okteta libs and parts in the subdirectories core, gui and parts, as they are maintained and used. |
|
|
|
|
|
|
Jakob Petsovits committed changes in /trunk/KDE:
|
|
Use Oxygen icons in kgpg, and rename those to more understandable names. Dropped some of the custom icons, we have rather nice replacements in Oxygen for those. |
|
|
|
|
|
