Looking for confirmation:
When I change the icon theme (KControl->Appearance & Themes->Icons), most of the icons change immediately but not all. I have to restart Trinity to force all icons on the desktop to update to the new theme.
The kwikdisk icon is particularly persnickety at not changing without a Trinity restart.
I do not have sessions enabled during this testing. I delete the ksycoca cache each time before restarting Trinity.
Rarely (I can't repeat) Konqueror icons do not always immediately change either (I have the Konqueror preload option enabled, if that makes a difference). Although almost all of the time the konqueror icons do update immediately.
Darrell
Darrell,
I think your push is still trickling into the servers. I pulled 804 deltas a
couple of hours ago assuming that was the complete patch set, but I just checked
again and there is another 38 deltas in this pull. I don't know how long a patch
set takes to find its final place of rest, but I guess I'll give it another pull
in the morning to make sure.
--
David C. Rankin, J.D.,P.E.
We have a small team. Keeping Trinity moving forward is a challenge. Yet I believe we have a committed and dedicated team, small or not, and somehow we keep moving forward.
I don't expect people to give up their day jobs to support Trinity, but I found this article interesting:
http://www.h-online.com/open/news/item/Independent-software-developers-go-f…
I don't know what fund raising ideas we can use. Selling shirts and coffee cups requires serious overhead and personnel. Yet sometimes I wonder what we could do to keep Trinity moving at a nice speed.
Another idea I had today came from an RSS feed title:
"KDE SC 4.8.4 delivers monthly stabilization update"
After we release R14.0.0, I'm wondering whether we could do something similar. Every month or so we release a point release for Trinity that includes bug fixes and possibly one enhancement request.
Even if we push only two or three bug fixes, this monthly release would show the project is alive and well. A monthly stablization release also is great public relations because the various news people publish those press releases.
A monthly release does not mean a complete overhaul of the mirrors, etc. We would need only resync those packages that change. At three or four bug resolutions that likely would mean only a package or two changes.
A monthly stablization release will be much easier to manage after R14 than trying to backport patches for 3.5.13 because much changed between R14 and 3.5.13. After R14 we should be quite stable (ABI/API) and monthly bug patches should be easy to coordinate among packagers.
Just ideas and thoughts.
Darrell
Would somebody please confirm that the icons used in k9copy are unreadable?
You do not have to have k9copy installed. Use your local GIT sources and try to view the icons:
applications/k9copy/tree/src/icons
I am unable to view the icons.
In the installed version of k9copy, the icons in the Settings menu are blank, which is how I discovered the problem.
I can view all of the icons from the original 1.2.4 sources.
I think somehow the images in the GIT tree have become corrupted. Comparing file sizes between the two source sets shows the files are not the same size.
Fixing the problem is as easy as copying the images from the original sources. I have tested by rebuilding k9copy with the original image files and the Settings images were fine.
I just want confirmation before pushing anything to GIT.
Thanks!
Darrell
Recently Trinity/TDE was added to the list of registered desktop environments: http://standards.freedesktop.org/menu-spec/latest/apb.html. Before that event I have been developing a related patch set. I'm about to push this large patch set, which affects XDG compliance and will help avoid potential conflicts with KDE4. The patch set is an effort to resolve bug report 892.
Almost every module is affected.
The patch set performs the following:
* Updates all occurrences (*.desktop files and source code) of X-KDE-* to X-TDE-*
* In *.desktop files, updates KDE; -> TDE; in all Category keys
* Renames $TDEDIR/share/applications/kde -> $TDEDIR/share/applications/tde
Resolving bug report 892 is important to R14. I have tested the patch set about as far as I can go. The time has arrived for additional eyes to help spot possible remaining bugs. :-)
I am not blindly pushing this patch set. I have been testing the patches for a long time and have been focused on looking for breakage with daily usability testing. Making these global changes has taken me a long time to test. Overall I'm pleased with the effort and excepting possible bugs, I think everybody in the Trinity community will be pleased too.
Do I expect breakage? The conservative answer is probably. No person is capable of knowing every conceivable usage of Trinity. I have tried to be as diligent as possible with my testing, but I don't use every single Trinity feature --- I'm not even aware of them all :-). There is a likelihood I missed something.
With that said, when testing from GIT be sure to use the patched starttde. If you use your own customized starttde, then you need to know where your profile will break. Profile breakage is guaranteed if you don't use the patched starttde, or you don't backport the patch to your customized starttde. Trinity will load and run but oddball things happen when the profile is not updated to match the patch set.
When using the patched starttde there should be no profile problems because starttde updates the profile. This update process is a one-time event and is recorded in kdeglobals. In my testing I did not notice any slowdown in starttde caused by this one time event. Possibly those people with significantly large profiles might see a one-time delay, but probably no more than a few seconds.
I do not claim to being a shell script wizard. I welcome any starttde patching improvements.
Please do not attempt to backport this large patch set to 3.5.13. Please do not attempt to backport the related starttde patches to 3.5.13. These changes are for R14 [DEVELOPMENT] and forward. Backporting will cause breakage.
Known challenges with developing the patch set:
* Update user's profile
starttde will update profile *.desktop files
* User-defined keyboard shortcuts break
starttde will update shortcuts
* User-defined file associations are ignored
starttde will update profilerc
* Sym links to $TDEDIR/share/applications/kde break and must be relinked -> $TDEDIR/share/applications/tde
starttde will fix sym links in Autostart
NOTE: starttde does NOT fix non profile sym links
* One issue I can't update because root permissions are required to fix, but when using $TDEDIRS, be sure to rename $TDEDIRS/share/applications/kde -> $TDEDIRS/share/applications/tde.
Clues include duplication in the TDE menu. Notice I refer to $TDEDIRS and not $TDEDIR.
I tested the patched starttde against a current Trinity profile, a kde3 profile, and a 4-month old profile. All updated as expected.
GIT Testing:
* Please make a backup of your $TDEHOME profile directory.
* The backup profile will help troubleshoot bugs in the patched starttde by providing a convenient way to restore the old profile and retesting.
* The first time the patched starttde runs, as explained there will be some updating of profile files. When the update process completes, starttde will stamp $TDEHOME/share/config/kdeglobals:
[R14 XDG Updates]
Updated=true
* If you find odd things happening, exit the session, delete those two lines from kdeglobals or change the key to false and start TDE again. This will force the patched starttde to run the updates again.
* Report any related bugs to the developer's mail list or in bug report 892.
* Ignoring bugs, the entire patch set and profile updates should be transparent to users. Users should not notice anything.
I will push this patch set in two phases. First, because I have been building and testing the patches outside of my local GIT repository, I'm going to merge those patches with my local tree and run a full build set. That will take most of the day. Then after verifying no obvious build or usability issues, I'll push the patches to the central GIT repository.
I will post another message to the list when I start pushing upstream. Otherwise building from the GIT tree during that period will create some strange results, not in building, but usability. :-)
Basically I'm posting now as a forewarning. :-)
This is a large undertaking, hence my post before pushing the patch set. This patch set is needed one way or another. The sooner we push the sooner we all can test, which is the nature of the GIT sources. I am not expecting traumatic failures because I have been using a patched Trinity in daily usage. Nonetheless, thank you everybody for your patience and confidence!
Darrell
All,
Running kmenuedit from the command line, I received the following:
15:05 valkyrie:~> kmenuedit
15:05 valkyrie:~> libpng warning: Interlace handling should be turned on when
using png_read_image
Is that something that needs to be addressed? Or, is that just a message that
can be turned on/off?
--
David C. Rankin, J.D.,P.E.