> For renamed files, get rid of 'NotShowIn='. If NotShowIn=KDE is
>all that is
>needed to prevent the TDE/KDE conflict for those apps that have
>NOT been
>renamed, the warm up 'sed' and make the change. If I recall
>correctly, the only
>downside to eliminating NotShowIn= completely for every desktop
>file is that you
>would get both versions of of KDE3 and KDE4 application in the
>menu. SuSE
>initially changed the title in the KDE4 apps to include KDE4-blah
>which provided
>separation in the menus but the menus did look a bit cluttered
>with double-apps
>everywhere.
>
> Since we have been on this huge renaming kick to prevent
>conflict, then I say
>get rid of 'NotShowIn=' in every application that has been
>renamed. Yes kde4
>with see tde apps, but that is an upgrade, not a problem.
>
> Turn the issue around, does any other desktop include
>'NotShowIn=TDE' to
>prevent TDE from seeing all their apps - no. I don't think we need
>any of these
>training-wheels except in case of direct TDE/KDE name conflict.
I tested this in fluxbox and xfce. I see no Trinity apps in the
menus.
Upon further reflection, although possibly we have been overzealous
with using OnlyShowIn=TDE, I suspect not. We do need to use that
directive for certain apps, but I don't think that is the root
cause of the problem described by the blog author.
I suspect the problem with other environments not seeing Trinity
apps is environment variables. As just about all of us build
Trinity to install to /opt/trinity, not a single environment
default configuration will find Trinity apps with standard
environment variables. Specifically the XDG_* variables that affect
finding trinity files.
I believe then the first hurdle is how to help other environments
find all Trinity *.desktop files.
I wonder whether we should install the menu files to /etc/xdg/menus
rather than /etc/trinity/xdg/menus.
A caveat: when KDE4 is concurrently installed with Trinity, the
respective environment menu can become a hopeless cluttered mess.
This is true in my xfce test. We have a build-time option to add
"[KDE4]" to all KDE menu items, but that might affect only the
Trinity menus. I'd have to run a build test to see any effects on
the Xfce menu.
This topic deserves further investigation.
Darrell
>I'll give it a try. But I learned during the original problem I
>had with sound,
>root uses a completely different sound scheme than normal users in
>TDE. root
>makes use of alsa-raw which bypasses a bulk of the user sound
>config, so it may
>work fine and still not be a permission issue.
If true then file a bug report. There should be no reason why root
should use arts differently than non-root users.
>Since this is virtualbox, I'll just create users doug, sally, ben
>and jerry and have totally different profiles :)
At this point I say stop and test with real hardware. Virtual
machines work great for many things, but your particular problem
needs to be resolved with real hardware. Get a second machine,
create a second partition. I use all of the above for testing.
Darrell
Recently Trinity was given a nominal public review in a blog:
http://anarchic-order.blogspot.com/2014/02/installing-trinity-
desktop-environment.html
The author offered a caveat:
"The Trinity-DE applications are only available through the Trinity-
DE desktop. While all the other applications installed on your
system show up in the TDE menus, because of the way Trinity-DE
loads its menus, if you log in with Xfce, the Trinity-DE
applications will not be seen."
Most Trinity *.desktop files use OnlyShowIn=TDE, which causes the
author's observations.
Should users of other environments (many window managers support a
menu system too) be prevented from using Trinity apps? Probably
not. The original motivation for using OnlyShowIn=TDE is conflicts
and confusion in the Trinity and KDE menus because many apps share
the same name. Perhaps NotShowIn=KDE is more apprpriate than
OnlyShowIn=TDE?
I believe we should resolve this before releasing R14.
Comments?
Darrell
All,
There are a number of png files in TDE that generate errors on opening due to
outdated png header information. I would like to identify which icons these are.
For example when opening khelpcenter I receive the following messages:
03:03 valhalla:~> khelpcenter help:/khelpcenter/releasenotes
khelpcenter: WARNING: Main template file name is empty.
libpng warning: iCCP: known incorrect sRGB profile
libpng error: IDAT: invalid distance too far back
libpng error: IDAT: invalid distance too far back
libpng error: IDAT: invalid distance too far back
libpng warning: Interlace handling should be turned on when using png_read_image
libpng error: IDAT: invalid distance too far back
libpng error: IDAT: invalid distance too far back
libpng error: IDAT: invalid distance too far back
libpng warning: Interlace handling should be turned on when using png_read_image
Apparently, the problem is out-of-date png header information. Searching I
stumbled across a minimal bit of source that is supposed to fix the issue, but
only if compiled on older versions of libpng. Looking at the code, the crux of
it is to rewrite the first 8 bytes of the png header. I've attached it for
experimentation. It builds well on all of the boxes I have, but I suspect you
have to force it to build against libpng 1.2 in order for it to do what it is
supposed to. I'll continue to experiment. If you have few spare minutes give it
a try and let me know if you can see any discernible difference in the new/old
png files. I haven't yet.
--
David C. Rankin, J.D.,P.E.
I have always been suspect of all the cmake conversions as being
incomplete.
Some obvious examples include tdemultimedia and tdewebdev.
Conversions were started but never completed. Other examples
include amarok (bug reports 818, 1917).
Last night I noticed a directory in tdepim that does not compile
because no CMakeLists.txt file was created during the cmake
conversion.
There are other cmake issues, such as no cmake macro was written
for converting man page docbook files to man pages. The automake
packages still compile fine but the cmake converted packages no
longer build the man pages. (Bug report 1830.)
I don't know how we should audit the cmake conversion process.
Possibly one way is search the source tree in the known conversions
for Makefile.am and look for a coexisting CMakeLists.txt. That does
not mean the conversion is complete but would expose certain
incomplete conversions as I discovered last night in tdepim.
We need a way to audit cmake conversions. Any ideas?
Darrell
>> This is getting stranger:
>>
>> Darrell, you were correct, aplay will play .wav files just
>fine. I rebuilt
>> both arts and tdemultimedia - no change. From the command line,
>both 'play' and
>> 'aplay' work fine, but TDE will not play any sound. I open
>kcontrol -> Sound
>> System -> [Test Sound] and I get nothing. I click the litte |>
>next to any sound
>> event file - same result, no sound.
>>
>> Checking .xsession-errors, each time I try playing the a
>sound, I get the
>> following:
>>
>> unix_connect: can't connect to server
>> (unix:/tmp/tdesocket-david/localhost.localdomain-02d0-52f9c6b6)
>> unable to connect to sound server
>> unix_connect: can't connect to server
>> (unix:/tmp/tdesocket-david/localhost.localdomain-02d0-52f9c6b6)
>> unable to connect to sound server
>> unix_connect: can't connect to server
>> (unix:/tmp/tdesocket-david/localhost.localdomain-02d0-52f9c6b6)
>> unable to connect to sound server
>> unix_connect: can't connect to server
>> (unix:/tmp/tdesocket-david/localhost.localdomain-02d0-52f9c6b6)
>> unable to connect to sound server
>> [tdeinit] Got EXEC_NEW 'artsd' from launcher.
>> [tdeinit] artsd is executable. Launching.
>> unix_connect: can't connect to server
>> (unix:/tmp/tdesocket-david/localhost.localdomain-02d0-52f9c6b6)
>> unable to connect to sound server
>> [artsd] There are already artsd objects registered, looking if
>they are active...
>> unix_connect: can't connect to server
>> (unix:/tmp/tdesocket-david/localhost.localdomain-02d0-52f9c6b6)
>> unable to connect to sound server
>> [artsd] ... cleaned 5 unused mcop global references.
>>
>> server status: running, will suspend in 6 s
>> real-time status: no real-time support
>> server buffer time: 53.288 ms
>> buffer size multiplier: 1
>> minimum stream buffer time: 53.288 ms
>> auto suspend time: 7 s
>> audio method: alsa
>> sampling rate: 44100
>> channels: 2
>> sample size: 16 bits
>> duplex: half
>> device: default
>> fragments: 10
>> fragment size: 940
>> [tdeinit] Got EXT_EXEC 'knotify' from launcher.
>> artsd: symbol lookup error: /opt/trinity/lib/libarts_xine.so.0:
>undefined
>> symbol: ao_new_port
>> [tdeinit] Got EXEC_NEW '/opt/trinity/bin/artsd' from socket.
>> [tdeinit] /opt/trinity/bin/artsd is executable. Launching.
>> [artsd] There are already artsd objects registered, looking if
>they are active...
>> unix_connect: can't connect to server
>> (unix:/tmp/tdesocket-david/localhost.localdomain-02e1-52f9c6c6)
>> [artsd] ... cleaned 5 unused mcop global references.
>>
>> Checking /tmp/tdesocket-david/localhost.localdomain-02d0-
>52f9c6b6, it is there
>> and easily accessible, so I don't know what that unix_connect
>error is all
>> about. The bottom line, something is active very differently
>with this set of
>> package regarding sound. Let me know if you have any other
>thoughts. We'll look
>> at this more later.
>>
>
>Just so it is clear. After update from the packages built on 1/29
>to packages
>built on 2/8, sound event notifications no longer work in TDE.
>Using play or
>aplay from the command line in konsole, both WORK FINE:
>
>02:37 valhalla:~> aplay
>/opt/trinity/share/sounds/KDE_Window_Open.wav
>Playing WAVE '/opt/trinity/share/sounds/KDE_Window_Open.wav' :
>Signed 16 bit
>Little Endian, Rate 22050 Hz, Stereo
>02:37 valhalla:~> play /opt/trinity/share/sounds/KDE_Startup_1.ogg
>
>/opt/trinity/share/sounds/KDE_Startup_1.ogg:
>
> File Size: 124k Bit Rate: 125k
> Encoding: Vorbis
> Channels: 2 @ 16-bit
>Samplerate: 44100Hz
>Replaygain: off
> Duration: 00:00:07.95
>
>In:100% 00:00:07.95 [00:00:00.00] Out:382k [ | ]
>Hd:0.1 Clip:3
>play WARN rate: rate clipped 2 samples; decrease volume?
>play WARN dither: dither clipped 1 samples; decrease volume?
>Done.
>
> However, as soon as any sound event in TDE is triggered (such as
>on shade), I
>get the following dumped into the .xsession-errors file:
>
>unix_connect: can't connect to server
>(unix:/tmp/tdesocket-david/localhost.localdomain-04ac-52f9cdd8)
>(The previous message was repeated 2 times.)
>unix_connect: can't connect to server
>(unix:/tmp/tdesocket-david/localhost.localdomain-04e5-52f9cde2)
>[tdeinit] Got EXEC_NEW '/opt/trinity/bin/artsd' from socket.
>[tdeinit] /opt/trinity/bin/artsd is executable. Launching.
>[artsd] There are already artsd objects registered, looking if
>they are active...
>[artsd] ... cleaned 5 unused mcop global references.
>
>/opt/trinity/bin/artsd: symbol lookup error:
>/opt/trinity/lib/libarts_xine.so.0:
>undefined symbol: ao_new_port
>unix_connect: can't connect to server
>(unix:/tmp/tdesocket-david/localhost.localdomain-04e5-52f9cde2)
>(The previous message was repeated 1 times.)
>unix_connect: can't connect to server
>(unix:/tmp/tdesocket-david/localhost.localdomain-05c9-52f9e0cf)
>[tdeinit] Got EXEC_NEW '/opt/trinity/bin/artsd' from socket.
>[tdeinit] /opt/trinity/bin/artsd is executable. Launching.
>[artsd] There are already artsd objects registered, looking if
>they are active...
>[artsd] ... cleaned 5 unused mcop global references.
>
>/opt/trinity/bin/artsd: symbol lookup error:
>/opt/trinity/lib/libarts_xine.so.0:
>undefined symbol: ao_new_port
>
> So where is TDE trying to make the call for the sound event
>resulting in the
>unix_connect error?
Yeah, Linux is ready for the desktop....
You have tested sound with the aplay and play commands, which
validates your hardware and alsa. Start an alternate desktop to at
least isolate the problem to only Trinity.
I don't know about the above messages, but seems arts is not
starting or is not loading completely.
Another idea is permissions. I quite often log into my desktop as
root to test permissions issues. Not tdesu, actually logging in as
root. I don't prescribe to any aspect of the anti-root religion and
logging in as root is a quick way to determine whether a problem is
permissions related.
Also try with a fresh profile. I have a couple of testing accounts
I use to try various things without touching my normal accounts.
With the testing accounts often I 'mv ~/.trinity ~/.trinity.bak'
and then start Trinity. That creates a new ~/.trinity profile
directory. When I finish testing I 'rm ~/.trinity' and then 'mv
~/.trinity.bak ~/.trinity'.
With a fresh profile directory you should hear the stupid login
sound file if arts is loading correctly. This at least narrows the
issue to your profile or Trinity in general.
When I have arts issues I delete the tdesycoca cache files,
~/.mcop, and all the Trinity socket and temporary files. This is a
big reason I don't use graphical logins. I can exit X and be back
to the command line without worrying that the login manager and X
are still running. Provides an easy way to debug and delete files.
I also just now remembered there is an arts config file. Once upon
a time in the KDE3 days that file caused problems with one of the
options, but I no longer remember the details. Anyway, try renaming
~/.trinity/share/config/kcmartsrc.
And yeah, the tdemultimedia conversion to cmake never was completed.
Darrell
> It sounded great. So checking, play is provided by sox 14.4.1-4.
>That begs the
>question, Why does play work fine but aplay fail?
I believe aplay does not support ogg and only supports wav. Don't
ask --- I don't know why.
Darrell
All,
I just installed all of the packages from the 2/8 - 2/10 build. The initial
display of khelpcenter worked fine, but I noticed that I had no sound. After
fighting with sound in the first set of packages, I was surprised that sound
would just quit working in the latest set.
I then opened konsole and tried:
21:52 valhalla:~> aplay /opt/trinity/share/sounds/KDE_Startup_1.ogg
Playing raw data '/opt/trinity/share/sounds/KDE_Startup_1.ogg' : Unsigned 8 bit,
Rate 8000 Hz, Mono
I got a horrible screaching sound from speakers. I then tried:
21:52 valhalla:~> play /opt/trinity/share/sounds/KDE_Startup_1.ogg
/opt/trinity/share/sounds/KDE_Startup_1.ogg:
File Size: 124k Bit Rate: 125k
Encoding: Vorbis
Channels: 2 @ 16-bit
Samplerate: 44100Hz
Replaygain: off
Duration: 00:00:07.95
In:100% 00:00:07.95 [00:00:00.00] Out:382k [ | ] Hd:0.1 Clip:4
play WARN rate: rate clipped 2 samples; decrease volume?
play WARN dither: dither clipped 2 samples; decrease volume?
Done.
It sounded great. So checking, play is provided by sox 14.4.1-4. That begs the
question, Why does play work fine but aplay fail?
Suggestions?
--
David C. Rankin, J.D.,P.E.
I found a 3.5.9 patch to add a trash can dialog to set trash
storage limitations. The dialog would look like this:
http://tokoe-kde.blogspot.com/2008/08/size-limits-for-trash.html
The patch did get submitted in the KDE bugzilla but never got
merged into 3.5.x.
I converted the patch to TQt3 and added an option to populate the
konqueror configuration dialog with a trash icon that should show
the same dialog.
The patch fails to build for me:
/dev/shm/tdebase/tdeioslave/trash/ktrashpropsdlgplugin.cpp:226:
undefined reference to `TrashImpl::trashDirectories() const'
/dev/shm/tdebase/tdeioslave/trash/ktrashpropsdlgplugin.cpp:141:
undefined reference to `TrashImpl::trashDirectories() const'
/dev/shm/tdebase/tdeioslave/trash/ktrashpropsdlgplugin.cpp:61:
undefined reference to `TrashImpl::TrashImpl()'
/dev/shm/tdebase/tdeioslave/trash/ktrashpropsdlgplugin.cpp:62:
undefined reference to `TrashImpl::init()'
If you are interested then I have attached the patch to bug report
1923.
Darrell
>Ok, I have the ultimate solution.
>
>Because 'cppeditor' utilizes many parts of the 'editor', it seems
>useful
>(perhaps only possible), leave visible 'everything' from the
>editor. Drop previous patches and try only this attached.
I rebuilt tqt3 and tdebase and my build logs and error log are
again quiet.
Thank you.
Is this something I have to run all the time or will this be pushed
to git?
Darrell