>I was thinking a little bit different way - for example:
>
>[R14 XDG Updates]
>Updated=R14.0.0
>
>or (maybe better - can cover also changes during development
>versions and also easier for comparison in shell)
>
>[R14 XDG Updates]
>Updated=20130407
>
>Where timestamp is not date of the conversion for user, but the
>internal date of r14-xdg-update script, which make conversion.
Makes sense. Or use the time stamp of tdelibs/tdecore/tdeversion.h
or TDE_VERSION_STRING from tdeversion.h
Darrell
>This is from the quickbuild nightly builds on quantal (might be an
>issue as well)
Could be.
What happens when you press F4 to open konsole in the respective
directory and then type the ls command?
Darrell
>> What happens in icon view?
>
>The icons appear, but no text.
>
>Also the system menu in kicker is blank, icons but no file names.
Rings a bell. I checked the bug tracker and found nothing. Found
nothing in the mail list archives.
Who built the packages?
Darrell
>I have one small suggestion. Script r14-xdg-update writes to the
>configuration key Updated. If the script could contain internal
>version
>number (or timestamp), it could to key Updated write this value
>and then
>this value use to decide whether to execute again or not.
>
>Such solution could cover any subsequent updates. And it would not
>depend on testing the specific renamed files. What do you think?
Sounds like a good idea.
I never envisioned needing the script long-term, but I'm horrible
at predicting the future. Hopefully by the time R15 is the main
trunk in GIT we no longer need the script. Until then, perhaps we
should embrace your suggestion. :)
Currently we use the following:
[R14 XDG Updates]
Updated=true
Perhaps change that to:
[R14 XDG Updates]
R14.0.0-Updated=true
If we do that then what mechanism do we use in the script itself to
track this? I'm thinking of corner cases such as a user updates
from 3.5.13.1 to R14.0.2 or something like that. Corner cases
always ruin parties. :)
Darrell
On Tue, 16 Apr 2013 12:14:29 -0500 "Calvin Morrison"
<mutantturkey(a)gmail.com> wrote:
>A totally new installation. New computer!
When you select the Settings menu, do you see all config icons?
What happens in icon view?
Darrell
On Tue, 16 Apr 2013 11:09:18 -0500 "Calvin Morrison"
<mutantturkey(a)gmail.com> wrote:
>Hi guys,
>
>on my nightly builds, there are no filenames in konqueror!
>
>Any ideas?
Yes. An improperly updated profile from 3.5.13->pre-R14.
There is a script at $PREFIX/bin/r14-xdg-update that is supposed to
run automoatically the first time $PREFIX/bin/starttde is run. That
is starttde and not startkde. If there were no problems then
~/.trinity/share/config/kdeglobals should have a new key entry:
[R14 XDG Updates]
Updated=true
You should also have seen several related stdout messages in your
user .xsession-error log.
You can run the r14-xdg-update script at any time.
* Log out of Trinity.
* Log in at a console (not xterm).
* Run '/opt/trinity/bin/r14-xdg-update force'
I believe only Slavek and I have done any serious testing of the
r14-xdg-update script. Possibly you have run into some new corner
cases that need to be added. Run the script with the force
parameter and observe the output messages.
Darrell
Tim,
How much does Trinity already parallelize startup? Is there more we
can do?
The following article is interesting with respect to developing a
"KDE Lite":
https://blogs.kde.org/2013/04/11/hackweek9-lightweight-kde-desktop-
project-updated
The idea of parallelizing the startup is in the last paragraph.
Darrell
The tdesdk package, kapptemplate, contains a bunch of admin/.git
files that get installed to
$PREFIX/share/apps/kapptemplate/admin/.git/.
Why is the build pulling these admin/.git files into the package?
Darrell