tde-devels

devels@trinitydesktop.org

4 participants
3812 discussions

Re: [trinity-devel] ldebase - login manager default fonts and distro neutral Greeting
by Calvin Morrison 28 Feb '11

28 Feb '11

Of course! If it is a bug then it should be filed immediately. The point of the bug tracker is to keep things organized. This is a smaller issue so unless it is in the tracker it maybe overlooked. Definitely file that baby. Calvin Morrison

2 1

ldebase - login manager default fonts and distro neutral Greeting
by David C. Rankin 28 Feb '11

28 Feb '11

Next time somebody is in the code near the default settings for Login Manager, have a look at the font size and Greeting line. The current fonts are 22 pt for the Greeting, 10 pt for Failures, and 10 pt for General. I would propose 14, 10, 8. The current greeting welcomes you to Ubuntu. I would propose Trinity? I'll update the default proposals on the wiki as well -- David C. Rankin, J.D.,P.E.

7 11

last post for the Trinity weekend - applications status chart
by David C. Rankin 28 Feb '11

28 Feb '11

Whew, I'm done for the weekend :) Attached is a chart showing the current state of the applications/... cmake ports as well as the errors I encountered trying to build the ones with the old CMakeLists.txt files. (these are just notes I took working through the applications directory) The chart should be self-explanatory. If there is an 'x' in the CMake Port column, that just means a CMakeLists.txt file exists (not necessarily a Trinity CMakeLists.txt file). If there is a date under the Date column, then I was able to build it on Arch. The errors encountered in building are listed in the Error Description column. Ignore the last column. The openoffice calc file is here: http://www.3111skyline.com/dl/dt/trinity/arch/doc/app-cmake-port.ods It would be helpful to keep some type of running list on the status of the port effort. (it may already exist - dunno) Great job to all on Trinity. It's really looking good. -- David C. Rankin, J.D.,P.E.

1 0

Trinity Road Plan
by Darrell Anderson 28 Feb '11

28 Feb '11

Are there plans to start focusing and resolving issues reported in the bugzilla? If so, when (what is the road plan)? Thanks. Darrell

3 2

kgtk-qt3: kfile.h error can't find tqdir.h, (in tqt/tqdir.h) - howto fix?
by David C. Rankin 28 Feb '11

28 Feb '11

Guys, I'm trying to learn how to solve these include errors. At first glance, it looks like the build isn't accepting my: export CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/opt/trinity/include The error I'm dealing with is: [ 7%] Building CXX object kdialogd3/CMakeFiles/kdialogd3.dir/kdialogd.o cd /home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3 && /usr/bin/c++ -march=x86-64 -mtune=generic -O2 -pipe -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -fno-exceptions -fno-check-new -fno-common -O2 -I/home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3 -I/home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3 -I/home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/common -I/opt/trinity/include -I/opt/qt/include -o CMakeFiles/kdialogd3.dir/kdialogd.o -c /home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3/kdialogd.cpp In file included from /home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3/kdialogd.h:4:0, from /home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3/kdialogd.cpp:3: /opt/trinity/include/kfile.h:21:19: fatal error: tqdir.h: No such file or directory compilation terminated. I think the short answer is the cmake files have not been tailored to Trinity, but I'm trying to figure out how to do that. The chain of the error seems simple, /opt/trinity/include/kfile.h includes: #include <tqdir.h> which is in /opt/trinity/include/tqt, so in order for it to be seen as a standard <file.h> include instead of a "tqt/file.h" include, the Trinity cmake setup must do something to tell the compiler to look in /opt/trinity/include/tqt as a standard include directory. I thought that was what I was doing with CMAKE_INCLUDE_PATH=.... What else do we need to do in the cmake files? Thanks :) -- David C. Rankin, J.D.,P.E.

2 3

applications/kde-style-qtcurve builds but looks like old CMakeLists.txt
by David C. Rankin 27 Feb '11

27 Feb '11

Guys, Just an update. I was able to get applications/kde-style-qtcurve to build with the existing CMakeLists.txt, but as with gtk-qt-engine, it doesn't look like a normal Trinity cmake file. This brings the current Trinity packages building on Arch to: trinity-app-amarok-1222475-1-x86_64.pkg.tar.xz trinity-app-gtk-qt-engine-1222892-1.0-x86_64.pkg.tar.xz trinity-app-style-qtcurve-1182805-1-x86_64.pkg.tar.xz trinity-arts-1214641-1-x86_64.pkg.tar.xz trinity-kdebase-1222475-1-x86_64.pkg.tar.xz trinity-kdelibs-1222475-1-x86_64.pkg.tar.xz trinity-kdevelop-1222477-1-x86_64.pkg.tar.xz trinity-kdewebdev-1222551-1-x86_64.pkg.tar.xz trinity-pyqt3-3.18.1-9-x86_64.pkg.tar.xz trinity-qt3-3.3.8-20-x86_64.pkg.tar.xz trinity-tqtinterface-1222551-1-x86_64.pkg.tar.xz Let me know if there are additional modules that should build under cmake. I have been watching svn update and browsing through the applications directory to see what might build. We should keep a list of what is currently ported and should be working. That way we can concentrate building on the new packages to catch build errors. If I can get my hands on a complete list, I'll add it to the HowToBuild wiki page so we have a running list. Also, if we should not expect the apps with the older generic looking CMakeLists.txt to work properly, let me know and I'll hold off making the development packages available to Arch. Thanks. -- David C. Rankin, J.D.,P.E.

1 0

KDESU
by Keith Daniels 27 Feb '11

27 Feb '11

> Re: KDESU > From: Darrell Anderson <humanreadable@...> > Date: Sat, 11 Dec 2010 19:52:20 -0800 (PST) > Some things I noticed when using kdesu to open Kate. > 1. In the password dialog box there was no check box to remember the > password. > 2. For my root user I have Kate configured to use a pink background > rather than white. That serves as a simple reminder I am working as > root and not as a normal user. Yet in Trinity, after launching through > kdesu, Kate did not display the background as pink but white. > Superficially that seems to indicate Kate inherited the normal user's > properties rather than root's. > 3. After running kdesu to open Kate, I continually received DCOP > error messages of the effect that KLauncher could not be reached via > DCOP. Basically I had to restart my desktop session thereafter to > launch apps. > Comments? Confirmations? Hi Darrell It, doesn't look like you can respond to archive post that were not delivered directly to your mail box. I hope this kludge I'm making works and you get this post. I am assuming you are using Ubuntu or Debian. For this problem I think they are a lot alike. I am running Ubuntu. When I was a webmaster I kept doing the same thing over and over and got different results every time. <grin> This problem is sorta like that. Slight differences in how you set your system up make this problem give different results for different computers. Yes this is confirmed. Here is what I think is going on from days, weeks, months.... of experimenting and banging my head on the wall. When you kdesu, kdesudo, etc to root you are not using roots copy of Kate you are using yours. Sorta like you do when you use fish or sftp to access a remote computer using xwindows. That means you don't "really" have roots complete environment and if the settings are not exactly right you have all kinds of problems like you mention. You have the permissions to go anywhere and open and write to all files but there are a lot of other "settings" you don't receive the benefits of, like you would as a real root user. I noticed that it seemed like half the configurations were stored in roots config files and half in mine. Kate wasn't bad but Konqueror was a pain to try to use like that. I think the DCOP issue is a case where the DCOP server is seeing some of the signals or request from the root xserver and when it queries Klauncher it goes to root instead of your server--and roots Klauncher is not installed. In fact as little of the Xwindows and KDE software as possible is installed in roots xwindow system. The Root Whackers "had" to leave a place for root to exist--since Linux was basically built around the concept--but they did strip as many of the root environment variables as they could (including all KDE and DBus settings) and yet still have Linux run. For example both KDEHOME AND KDEDIR are not in roots environmental variables. This has caused some problems and caused issues like you had. I think that they will sooner or later break Linux by all the contortions they go through in the code to prevent users from playing with their root. I hope I'm around to laugh at them. <grin> I decided to find a way to run root's version of Kate, Konqueror and kcontrol so I could have control of their environment and configuration files. I did it and it works real well for the regular work you need to do as root. There are still at few weird things here and there that I have not fixed like not being able to run the "Configure Konqueror" application "consistently" without actually logging in as root in a real xwindow session. Sometimes it works sometimes it doesn't. But I am working on it It's nice to finally have my Root applications (run from my xwindow session) that have their own colors, title bar, icons, etc.--which helps keep me from thinking I am in one of my local applications--which usually are also open at the same time. Like you, I'm sure. Also it makes it easier to drop to root on my system then ssh to one of my other computers and run the other computer's root version of a Xwindow application. I also finally figured out how to run an xwindow session as root and that really helped to figure out how to make the local su to root apps work correctly. If you are not against working with the full power of root, (Though not logged in to xwindows as root) I will tell you what I did to solve the problem. The basic idea is that you have to create a root password, fix and export a bunch of environmental variables that were left out, install some missing software, fix some permission issues and finally give yourself permission to use everyone else's xwindow server on that computer (su to root doesn't give you that). After that there are various ways to run the root programs. I prefer su. The icons I use run local scripts that let me setup a lot more options than Klanucher would. Here is the su part of my kate script. su -l -c '/opt/kde3/bin/kate --caption ROOT' root This starts up Kate a LOT faster than using "kdesu kate" from an icon. The only draw back is that I have an extra terminal window open as well as Kate. Hope this helps. Keith

3 3

svn - applications/gtk-qt-engine will builds as is, but the cmake files look a bit rough...
by David C. Rankin 27 Feb '11

27 Feb '11

Just a note: applications/gtk-qt-engine builds with the current CMakeLists.txt in the directory. But the file looks like a generic cmakelists pulled from a project other than Trinity. I don't think it matters from looking at the simplicity of the code. Without the Trinity check included, you do have to supply a complete set of cmake variables with path, pkgconfig, etc. included. I don't think it will cause problems later, but it is somewhat of an oddity to look in a CMakeLists.txt and not see Serghei's familiar Trinity header :) The build produces the following package files: 02:06 supersff:~/arch/tnotes> cat flist/trinity-app-gtk-qt-engine-list.txt ------------------------------------------------------------ Package: trinity-app-gtk-qt-engine 1222892-1.0 ------------------------------------------------------------ /usr/ /usr/lib/ /usr/lib/gtk-2.0/ /usr/lib/gtk-2.0/2.10.0/ /usr/lib/gtk-2.0/2.10.0/engines/ /usr/lib/gtk-2.0/2.10.0/engines/libqtengine.so /usr/share/ /usr/share/themes/ /usr/share/themes/Qt/ /usr/share/themes/Qt/gtk-2.0/ /usr/share/themes/Qt/gtk-2.0/gtkrc From what I can tell -- it looks complete. If you notice something missing, let me know. -- David C. Rankin, J.D.,P.E.

1 2

konqueror sftp:// URL handling broken with openssh >= 5.6 (open a bug?)
by David C. Rankin 27 Feb '11

27 Feb '11

Tim, Robert, Serghei, All There is an error in konqueror sftp URL handling that causes sftp from konqueror to fail. I first reported this back in October 2010 on the various lists reporting that the konqueror url syntax 'sftp://user@host:port/path' no longer works after an update to one of the associated packages (probably openssh >= 5.6). IIRC, I also forwarded it to Tim at the time. (~ 10/7/2010) Back in October, sftp 'in konqueror' continued to work to boxes where ssh was on the standard port 22, but would fail if sftp had been moved to a high port. 'fish' continued to (and continues in Trinity to) work to both standard and non-standard ssh ports. Fast-forward to 'today' with Trinity svn. (1) sftp in konqueror fails to work at all: http://www.3111skyline.com/dl/dt/trinity/err/ssh/ss-err-enc-talk2ssh.jpg the sftp target host in the screenshot above (dcrgx2) has ssh on the standard port 22. Now konqueror will not talk to any host - on standard or high port. (2) fish continues to work just fine (both standard and high ports) http://www.3111skyline.com/dl/dt/trinity/err/ssh/ss-fish-OK.jpg (standard) http://www.3111skyline.com/dl/dt/trinity/err/ssh/ss-fish-OK-high-port.jpg (high) (3) sftp from the command line in Trinity (konsole) works fine to either high or standard ports: http://www.3111skyline.com/dl/dt/trinity/err/ssh/ss-sftp-cli-OK.jpg So the problem is definitely with konqueror's handling of the sftp URLs and how it passes that information to openssh. This is a distribution generic problem with KDE3 after the change to openssh (I'm pretty sure). In older releases of distros (like SuSE 11.0 - sftp in konqueror continues to work normally) The bottom line for Trinity going forward is that the normal konqueror sftp syntax of: sftp://user@host:port/dir1/dir2 is broken. This is confirmed as a konqueror problem because, in Trinity (and kde3 in general), the command line syntax: sftp -Pport user@host:/dir1/dir2 continues to work fine. So as does 'fish://'. I have researched this issue for a couple of months and the best I can tell is the problem is in kdebase/kioslave/sftp. There were references to an old Gentoo bug that fixed ksshprocess.cpp line 101 to regarding and openssh 3.6 problem with "ssh-userauth2 successful:", but I know that doesn't have anything to do with the current problem. It may be the same file that needs fixing now, but different problem. For Trinity, do we want to open up a bug report so this one can be tracked, or do we want to work it from the mailing list? Either way, the fix is probabl simple, but this is a biggie for sftp functionality. Thanks. -- David C. Rankin, J.D.,P.E.

4 7

Trinity kcontrol crash changing icon sets
by David C. Rankin 27 Feb '11

27 Feb '11

I'm not sure where this bug lies, but when you go to kcontol -> icons and attempt to choose another icon set for Trinity, kcontrol segfaults. This is another one of those bugs that I saw and reported on the various lists 4-5 months ago, but I don't know if anything was ever done. IIRC the though was that the bug was in some 'icon parser' that reads the icon package or directory and cannot handle the format of of the new icon sets. I'm pretty sure some underlying package changed (haven't a clue which), but in my old suse 11.0 install, I can read and use just about any icon package. In Trinity, I can't change from the default?? It's repeatable 100% of the time. Just add any of your favorite icon packages to /usr/share/icons, then go to kcontrol -> icons and try and use it, kcontrol will segfault. I'll try and get more details, but if anyone else has noticed this, please add your info here as well. Thanks! -- David C. Rankin, J.D.,P.E.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels