I'm looking for help with reorganizing the TDE menu when TDE and KDE4 menu are installed concurrently.
In a word: clutter.
I'm getting ready to push a huge patch set that will help liberate TDE using our own XDG registrations. That effort will help avoid potential conflicts with KDE4. More to come about that patch set (refer to bug report 892), but the patch is looking very good at the moment.
A while ago I filed bug report 977 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=977). Please read the bug report to understand the goal of moving the KDE4 menu items.
I want to create a separate KDE4 top-level menu and let the KDE4 menu appear there.
Although KDE4 apps are uniquely identified with a "[KDE4]" text marker in the menu (created in tdelibs/kio/kio/kservice.cpp), when TDE is installed concurrently with KDE4 there is nonetheless some serious menu clutter. Moving KDE4 menus to their own location would reduce that clutter. Moving allows TDE to display its own set of apps. Users decide which version of duplicate apps they prefer, but moving the KDE4 menu establishes that the user is running TDE.
I'm thinking with the upcoming patch set that moving the KDE4 menus probably is doable. Now is a good time to test this while I finalize testing for the upcoming patch set.
I have nominally tested adding a <Not><Category>KDE<Category></Not> set to prevent KDE4 items from appearing in a menu category. That removes the KDE4 items from the main TDE menu and reduces clutter.
I'm struggling to get the KDE4 menu to appear by itself in the top level. Basically I want to merge /etc/kde/xdg/menus/applications.menu into the TDE applications.menu.
I appreciate any help.
Thanks!
Darrell
Is anybody installing KDE3 and Trinity concurrently? Specifically, both desktops are installed to the same partition set and as appropriate for the respective distro, users can select between either desktop environment?
This requires installing both desktops in different locations, such as /usr and /opt/trinity, or /opt/kde3 and /opt/trinity.
I run both desktops and use KDE3 often to compare/debug Trinity issues. I do this with a separate installations and virtual machines. I would enjoy being able to install both desktops to the same partition set, but I run into serious menu problems that I haven't resolved. Being able to run one user in Trinity and another user in KDE3 for testing would be much better than using a VM (VMs have some limitations).
Thanks much.
Darrell
Latest GIT.
Would somebody confirm whether the "What's This" tooltips work in KControl?
Simply "right-click" on a check box text string. A popup should appear with the text string "What's This?" and when selected, a tooltip help string appears.
The "What's This" tooltips work correctly when I start a KControl module from the minicli or from the TDE Settings menu. They don't work when I try to use them in the full KControl.
Thanks.
Darrell
Tim,
The kwrite crash detailed in bug 979 is NOT fixed. I rebuilt everything today
with updates on both Arch and TDE current through today. The behavior is exactly
the same as before. I don't know what Fedora did to get around the crash, but it
is still there. It may be gcc, but I'd bet it is non-standard compliant code in
TDE that was exposed by the stricter interpretation by gcc 4.7. I'll reopen 979,
but I'm at a loss at what else to do. Backtrace from tonight:
Loaded symbols for /lib/libnss_files.so.2
0x00007f3934e3fe7a in TQChar::unicode (this=0x218ac2e) at ../include/ntqstring.h:198
198 ../include/ntqstring.h: No such file or directory.
(gdb) backtrace
#0 0x00007f3934e3fe7a in TQChar::unicode (this=0x218ac2e) at
../include/ntqstring.h:198
#1 0x00007f3934e3fa7f in TQFontMetrics::charWidth (this=0x2071930, str=..., pos=47)
at kernel/qfont_x11.cpp:704
#2 0x00007f392e3724da in width (tabWidth=<optimized out>, italic=<optimized out>,
bold=<optimized out>, col=47, text=..., this=0x2071910)
at /build/src/tdelibs/kate/part/katefont.h:76
#3 width (tabWidth=<optimized out>, col=47, text=..., fs=..., this=<optimized out>)
at /build/src/tdelibs/kate/part/kateattribute.h:55
#4 KateRenderer::textWidth (this=0x2144930, textLine=..., startcol=0, maxwidth=753,
needWrap=0x7fff40b10b78, endX=0x7fff40b10b6c) at
/build/src/tdelibs/kate/part/katerenderer.cpp:797
#5 0x00007f392e353994 in KateViewInternal::range (this=this@entry=0x2195c00,
realLine=realLine@entry=0, previous=previous@entry=0x0)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1331
#6 0x00007f392e354e52 in KateViewInternal::range (this=this@entry=0x2195c00,
realLine=0,
viewLine=viewLine@entry=1) at
/build/src/tdelibs/kate/part/kateviewinternal.cpp:1418
#7 0x00007f392e3567e9 in KateViewInternal::viewLineOffset
(this=this@entry=0x2195c00,
virtualCursor=..., offset=0, keepX=keepX@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1578
#8 0x00007f392e35a045 in KateViewInternal::makeVisible
(this=this@entry=0x2195c00, c=...,
endCol=118, force=force@entry=false, center=center@entry=false,
calledExternally=calledExternally@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:781
#9 0x00007f392e35a672 in KateViewInternal::updateCursor
(this=this@entry=0x2195c00, newCursor=...,
force=force@entry=true, center=center@entry=false,
calledExternally=calledExternally@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:2204
#10 0x00007f392e35e7e0 in KateViewInternal::editEnd (this=0x2195c00,
editTagLineStart=0,
editTagLineEnd=<optimized out>, tagFrom=<optimized out>)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:3385
#11 0x00007f392e2fb208 in KateDocument::editEnd (this=0x20906f0)
at /build/src/tdelibs/kate/part/katedocument.cpp:1032
#12 0x00007f392e2f523b in KateDocument::paste (this=0x20906f0, view=0x2068bc0)
at /build/src/tdelibs/kate/part/katedocument.cpp:3249
#13 0x00007f392e32cd73 in KateView::paste (this=0x2068bc0)
at /build/src/tdelibs/kate/part/kateview.cpp:1597
#14 0x00007f392e35c422 in KateViewInternal::mouseReleaseEvent (this=0x2195c00,
e=0x7fff40b11480)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:2965
#15 0x00007f3934f2e343 in TQWidget::event (this=0x2195c00, e=0x7fff40b11480)
at kernel/qwidget.cpp:4725
#16 0x00007f3934e98559 in TQApplication::internalNotify (this=0x7fff40b11ce0,
receiver=0x2195c00,
e=0x7fff40b11480) at kernel/qapplication.cpp:2638
#17 0x00007f3934e97be3 in TQApplication::notify (this=0x7fff40b11ce0,
receiver=0x2195c00,
e=0x7fff40b11480) at kernel/qapplication.cpp:2424
#18 0x00007f3935e618d4 in KApplication::notify (this=0x7fff40b11ce0,
receiver=0x2195c00,
event=0x7fff40b11480) at /build/src/tdelibs/tdecore/kapplication.cpp:583
#19 0x00007f3934e2a6b3 in TQApplication::sendSpontaneousEvent (receiver=0x2195c00,
event=0x7fff40b11480) at kernel/ntqapplication.h:526
#20 0x00007f3934e23f53 in TQETWidget::translateMouseEvent (this=0x2195c00,
event=0x7fff40b11990)
at kernel/qapplication_x11.cpp:4381
#21 0x00007f3934e21871 in TQApplication::x11ProcessEvent (this=0x7fff40b11ce0,
event=0x7fff40b11990)
at kernel/qapplication_x11.cpp:3558
#22 0x00007f3934e3cc44 in TQEventLoop::processEvents (this=0x1fd3f80, flags=4)
at kernel/qeventloop_x11.cpp:195
#23 0x00007f3934eab818 in TQEventLoop::enterLoop (this=0x1fd3f80) at
kernel/qeventloop.cpp:201
#24 0x00007f3934eab6e9 in TQEventLoop::exec (this=0x1fd3f80) at
kernel/qeventloop.cpp:148
#25 0x00007f3934e98689 in TQApplication::exec (this=0x7fff40b11ce0) at
kernel/qapplication.cpp:2761
#26 0x00007f39391d43a8 in kdemain (argc=1, argv=0x7fff40b122b8)
at /build/src/tdebase/kate/app/kwritemain.cpp:692
#27 0x000000000040082c in main (argc=1, argv=0x7fff40b122b8)
at /build/src/build/kate/app/kwrite_tdeinit_executable.cpp:2
--
David C. Rankin, J.D.,P.E.
Hi Tim and others,
Is there significant development going on regarding keyboard handling or
maybe character handling?
I'm a bit surprised, because I didn't know this depended on the toolkit,
but with the current nightlies, I'm unable to use my compose key to
compose characters in any Trinity application. In Qt4 and GTK
applications (within Trinity), the compose key works correctly. In the
past, this worked without issues in Trinity as well.
I can imagine this is not noticed by everybody quickly, I myself need to
use compose a lot to type in foreign languages. Let me know if I can
help with reproducing/solving this.
Best regards,
Julius
Ubuntu 10.04 LTS - Trinity 3.5.13
I have seen several konqueror updates recently (via Slavek's PPA.)
But, konqueror's Help > About konqueror reports:
"Konqueror 3.5.10 (using Trinity 3.5.13.1)"
Is it truly still konqueror 3.5.10 from back in the 2009-2010 days?
Has it just been bug fixes until now?
Or, has the Help > About konqueror text never been updated.
Thanks,
Jonesy
--
Marvin L Jones | jonz | W3DHJ | linux
Pueblo, Colorado | @ | Jonesy | OS/2 __
38.238N 104.547W | config.com | DM78rf | SK
All,
Arch is switching to systemd init. I don't know if this will have any impact
on TDE, but older versions have dependency conflicts due to the packages that
have been removed (heimdal from krb5, etc...) Not all systemd related, but I
wonder what other init or sysv dependent packages will need to be fixed for
systemd -- hopefully none at all, but I don't know enough to knnow.
So what do the TDE gurus say? Is there anyone building/running on a systemd
box currently? If not, what problems has anyone heard of caused by systemd (more
importantly -- and known tde specific impacts related to systemd.
Issue/No Issue? Gurus?
--
David C. Rankin, J.D.,P.E.
Hi,
I just upgraded to the nightlies on Ubuntu Precise. Some issues I noticed:
The python-sip package has incorrect 'provides'. Instead of:
Provides: python2.7-sip, sip-api-7.0, sip-api-7.1
It should be:
Provides: python2.7-sip, sip-api-8.0, sip-api-8.1
The shortcut to open the process list, ctrl+esc does not work. It is set
up correctly according to the keybindings configuration.
When looking at the process table in ksysguard, the table just keeps
flashing. It's impossible to actually use ksysguard to kill a program.
Should I report these bugs (or other problems like this)? I tried
everything both with my normal user and with a new test user (clean
homedir).
Best regards,
Julius
Resolving bug report 892 includes important patches to reduce potential conflict with KDE4 and to make our own *.desktop files XDG compliant (recently Trinity/TDE was added to the list of registered environments: http://standards.freedesktop.org/menu-spec/latest/apb.html).
Resolving this bug report is important to release R14.
The gritty work of creating patches to update all *.desktop files for each module is complete. Yet there is hard-coding somewhere deep in the tdelibs/tdebase sources that affixes the location of $PREFIX/share/applications/kde. I want to change that location to $PREFIX/share/applications/tde.
During testing, to change the location to $PREFIX/share/applications/tde, I modify the sources on-the-fly of every module by running the following snippet in my master build script:
echo "Fixing applications path in $APP_SOURCES_DIR."
if [ -d $APP_SOURCES_DIR/cmake ];then
find $APP_SOURCES_DIR/cmake -name TDESetupPaths.cmake -exec sed -i 's|\${SHARE_INSTALL_PREFIX}/applications/kde|\${SHARE_INSTALL_PREFIX}/applications/tde|g' {} \;
fi
if [ -d $APP_SOURCES_DIR/admin ]; then
find $APP_SOURCES_DIR/admin -type f -exec sed -i 's|{datadir}/applications/kde|{datadir}/applications/tde|g' {} \;
fi
find $APP_SOURCES_DIR -type f -exec sed -i 's|share/applications/kde/|share/applications/tde/|g' {} \;
echo
After I resolve the mysterious hard-coding I'll patch each module with this on-the-fly snippet.
tdelibs/tdecore/kstandarddirs.cpp has this snippet:
if (!strcmp(type, "xdgdata-apps"))
return "applications/";
Notice there is no "kde" affixed to the path.
Therefore the "kde" subdirectory is being added somewhere else.
The on-the-fly changes work great and all desktop files get installed to $PREFIX/share/applications/tde. Nonetheless, there is breakage. The hard-coding is real because various components stop working in Trinity. For example, opening the Konqueror Settings dialog reveals that most of the configuration options in the icon list are missing. I can temporarily create a sym link from $PREFIX/share/applications/tde to $PREFIX/share/applications/kde and then everything works again --- evidence of hard-coding.
I've looked and looked and I can't find anything. I would be grateful anybody would help me find this mysterious hard-coding.
Darrell