Hi all,
I seem to have stumbled into two nasty bugs with gtk-qt-engine:
First, I couldn't use gnome's nm-applet because I was getting this error:
"GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process
is not supported"
Second, I had been having some problems with Google Chrome where changing
the default download directory wasn't working, it simply ignored the
directory I selected in the dialog. This seems to also have been causing me
a similar problema where e-mail attachments wouldn't be attached.
Since removing qtk-qt-engine to test this hypothesis, everything is working
as it should, despite being uglier.
What is worse is that even when selecting what I thought was a GTK3 theme
(oxygen-gtk), I still wasn't able to launch nm-applet and there was no
option to disable this behavior, though I haven't found bugs like this in
the past (and still don't on my Gentoo box running the patched KDE 3.5.10),
though I have seen instances where checkboxes aren't rendering properly.
Should I submit a bug report or has anyone already found and filled
something like this?
Best regards,
Tiago
Hi all,
Kicker has been crashing on me when I hover the "System" menu on KMenu.
It's a Ubuntu 11.10 system, with packages from the sources available on the
website.
Can anyone reproduce this? I merely installed "kubuntu-desktop-trinity".
Also, this meta package should be pulling kpowersave or something that does
power management.
Best regards,
Tiago
Slavek,
As I mentioned in previous posts, the current mechanism in starttde causes $TDEDIRS to be ignored when $XDG_DATA_DIRS is explicitly defined in the environment.
I know what we need to do, but my regex skills are much to be desired. You helped with the last revision and probably can help again. :)
This is what we need to add to the existing snippet regarding $XDG_DATA_DIRS:
* When $TDEDIRS is not defined in the environment, do nothing additional. Leave functionality as is.
* When $TDEDIRS is defined then parse that variable into separate directories. Use those separate directories to form the $XDG_DATA_DIRS variable.
Notes:
Explicitly declaring $XDG_DATA_DIRS will override $TDEDIRS, which must then be explicitly identified in the $XDG_DATA_DIRS string to remain useful. When $XDG_DATA_DIRS is not explicitly declared, then $TDEDIRS is recognized and works as intended. Therefore we need to compensate when explicitly declaring $XDG_DATA_DIRS.
The $TDEDIR variable is intended to be singular and $TDEDIRS plural. When $TDEDIRS exists in the environment then parse that variable into separate directories.
By design, $TDEDIRS should contain whatever is set in $TDEDIR. Therefore any additional directories set in $TDEDIRS are intended to override data files found in $TDEDIR. In both $TDEDIRS and $XDG_DATA_DIRS, those additional directories should be placed before $TDEDIR and before /usr/share.
In $XDG_DATA_DIRS, $TDEDIR should be placed before /usr/share to ensure those data files override anything in /usr/share.
For example, on my system I have the following:
$TDEDIR=/opt/trinity
$TDEDIRS=/usr/local/tde-mods:/opt/trinity
Therefore in my system, $XDG_DATA_DIRS should look like this:
XDG_DATA_DIRS=/usr/local/tde-mods/share:/opt/trinity/share:/usr/share
I know of no limitations for expanding $TDEDIRS. Theoretically then, $TDEDIRS could contain more than two directories, but the last directory in the $TDEDIRS variable should always be what is defined in $TDEDIR.
For example, the following presumably could exist:
$TDEDIR=/opt/trinity
$TDEDIRS=/usr/local/tde-mods:/opt/tde-mods:/opt/trinity
Therefore $XDG_DATA_DIRS would look like this:
XDG_DATA_DIRS=/usr/local/tde-mods/share:/opt/tde-mods/share:/opt/trinity/share:/usr/share
I appreciate any help. Of course, I will test as much as possible.
Thank you!
Darrell
I added a KControl check box control for the shutdown feedback dialog. The one that says "Saving your settings" when logging out.
The underlying support already existed. The check box merely adds a direct way for users to show or disable the dialog box.
The patch provides nominal temporary relief against bug report 922: "When logging out with unsaved file, trinity does not ask to save it," (http://bugs.pearsoncomputing.net/show_bug.cgi?id=922). Currently the only solution to that bug is a work-around of disabling the feedback dialog.
The patch is available through bug report 681 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=681).
Please test. Upon receiving a successful report I'll push to GIT.
Thanks for helping. :)
Darrell
Several days ago we discussed updating the mlt sources.
I looked at that today. I need help knowing how to do this.
1. Many file differences and stupid git requires "git add" for new additions (but needs no help with deletions --- go figure).
2. mlt++ is now part of the mlt sources and would not need to be a separate libary in the source tree.
3. How to add the tqt layer to anything needing that if needed? I think only the qimage module is affected. qimage will know about Qt3 but not TQt3.
4. I'm still confused why we want to keep these sources in the tree when we do not provide anything needing them (unless kdenlive is ported). But I'll still try updating if provided sufficient information.
Darrell
All,
I have opened a bug for handling gcc 4.7 build failure issues:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=958
I have also uploaded a complete set of build logs for the packages listed as
not building due to gcc 4.7 changes. I have set the priority to 'major'. Tim
will need to determine if this is what it should be or whether it should be
elevated for R14. Thankfully the packages that are affected is relatively small.
Thus far:
basket
gwenview
k3b
kima
kipi-plugins
krusader
python-tqt
rosegarden
tdebase ( now requires -fpermissive )
tdegames
tdegraphics
tdepim
tdesdk
The big issue is that distros that ship or update to 4.7 will not be able to
build TDE until these issues are resolved. That eliminates Archlinux as the
build environment updates to build on the current stable release of all packages
(including gcc).
Some build failures may be able to be handled by compiler/linker flags, where
code changes will be required for the rest. The primary culprit seems to be gcc
4.7 implementation of additional features and extensions from C11 and C++11. The
changes are summarized at: http://gcc.gnu.org/gcc-4.7/changes.html
My guess for the lead suspect is:
G++ now correctly implements the two-phase lookup rules such that an unqualified
name used in a template must have an appropriate declaration found either in
scope at the point of definition of the template or by argument-dependent lookup
at the point of instantiation. As a result, code that relies on a second
unqualified lookup at the point of instantiation to find functions declared
after the template or in dependent bases will be rejected. The compiler will
suggest ways to fix affected code, and using the -fpermissive compiler flag will
allow the code to compile with a warning.
template <class T>
void f() { g(T()); } // error, g(int) not found by argument-dependent lookup
void g(int) { } // fix by moving this declaration before the declaration of f
template <class T>
struct A: T {
// error, B::g(B) not found by argument-dependent lookup
void f() { g(T()); } // fix by using this->g or A::g
};
struct B { void g(B); };
int main()
{
f<int>();
A<B>().f();
}
That would explain my need to use -fpermissive to build tdebase last night
where I never needed it before.
Oh, well, the challenges of progress... Let's rip this apart and 'get her
fixed' :)
--
David C. Rankin, J.D.,P.E.