In this week's KDE Commit-Digest: As the Summer Of Code draws to a conclusion, functional code imports and work in the avKode Phonon backend, KDevelop Teamwork and Advanced Session Management projects. Work begins on version 2 of the Kross scripting framework. More work on video file support in KPhotoAlbum. New features and streamlining in Konversation and Konsole. New Oxygen icons and other improvements in KGet. The introduction of wizards to automate many tasks in KMobileTools. Initial porting to KDE 4 of the console-based kdepim tools, with Kopete 0.12 moved into the KDE 3.5 branch. Experiments in fast PDF parsing in Strigi.
Dot Categories:
Comments
The KDE project is great. This will be the future of desktop computing.
Long live Penguin.
Can someone post a screenshot of KGet with the new Oxygen icons? Please!
I haven't got a screenshot, but here are (at least) some of the icons:
http://commit-digest.org/issues/2006-08-20/moreinfo/573367/#visual
Danny
Why are Oxygen icons being installed as CrystalSVG?
I thought I read about ktorrent, kget etc. are to be included into KIO (as ioslaves), and that there will finally be some kind of central UI/listview for managing running transfer jobs (pausing, resuming, changing priority etc.)
Am I wrong, or will kget lose its own UI?
basically, getting oxygen should be a no-brainer for curious people ...
svn co svn://anonsvn.kde.org/home/kde/trunk/playground/artwork/Oxygen/theme/svg/ does the trick quite fine
>with changes coming to kwizard, kconfig, khtml (the rather exciting unity stuff)
Does this mean that the Unity stuff will replace khtml?
'Unity stuff'? this is just temporary code name for WebKit's Qt4 backend. It's been already folded in Apple repositories by SVG people.
likely it can give birth to an external project? (eg. KPart alternative to khtml?). Question is if it can gather non-Apple developers followers to become a serious option (hacking WebKit is like working in a Cupertino sweatshop but without the measel wages :-)
> 'Unity stuff'? this is just temporary
> code name for WebKit's Qt4 backend.
Actually, it is a frontend. WebKit is the backend.
Sorry for being picky. :)
> if it can gather non-Apple developers followers
you mean like the kde developers who did the initial port and have continued to work on it? ;)
Actually the kde developers who did the initial port Dirk, Zack and George haven't touched it since, but the KSVG people are moving it forward right now (or backwards since it is now in Apple SVN where no one else can touch it!!).
> "use always the current iconset for all icons"
NOT a good idea. JR has apparently spend considerable time renaming a lot of CrystalSVG icons to HiColor so that they will install as HiColor. Now the current iconset is going to change and someone will have to do the work over again.
The reasonable conclusion is that we need to come up with some way to avoid this unless it was somebody's intention to force everyone to use CrystalSVG.
The standard says:
<<
The lookup is done first in the current theme, and then recursively in each of the current theme's parents, and finally in the default theme called "hicolor" (implementations may add more default themes before "hicolor", but "hicolor" must be last).
>>
Adding more default themes before HiColor is also a bad idea unless it is configurable. Users (that don't use CrystalSVG) are complaining that that the Icon Loader doesn't properly fall back to HiColor -- that they get CrystalSVG rather than HiColor. Gento even patches to try to fix this but I was advised that it doesn't work.
A suggested solution to both of these issues is that additional icon themes should be added AFTER HiColor as a backup to HiColor and that this needs to be configurable (and DeskTop specific).
If that is done: if we don't have an icon in the chosen icon theme then the fall back is first to the inherited themes, second to HiColor and then if we are missing the icon in HiColor the themes in the backup list will be searched. Normally, the first one on the list would be the current default.
If this is done users not wanting CrystalSVG icons will get them ONLY if a HiColor icon does not exist. This is what I, and other users, expect to happen.
I would like to see a tool or script which checks for Iconset completeness, so developers of iconset understand what was missing.
That is a good suggestion.
However, before we do that, we need a list of the icons which we need a iconset to have, and that is the hard part.
I'm pretty sure aseigo was working on this:
http://aseigo.blogspot.com/2006/06/tagging-icons.html