Tim, All,
If we want to preserve the application building tutorials for TDE, we may want
to collect those that are applicable from kde.org before they are all removed. I
have found several instances where the examples are either gone or are labeled
to be removed. I've annotated the pages at kde.org for preservation, but in some
seeming "erase all reference to kde3" move, most are slated for deletion. (the
storage and bandwidth requirements for the tutorials are minuscule, so the need
to delete is somewhat confusing)
As food for thought, between the kde3 tutorials at kde.org and the gtk
tutorials at developer.gnome.org/gtk-tutorial/, the gtk tutorial is laid out
much more logically and thoroughly. If we do preserve some of the tutorials for
TDE user/developer reference, my vote would be to follow the gtk lead concerning
depth of explanation and layout. (not the web format, the content level)
Not priority, but I would be interested in what others think regarding
preserving/creating some developer information such as examples and tutorials to
show what is new/changed for TDE development verses KDE3 development. (T/Q
naming, etc..)
--
David C. Rankin, J.D.,P.E.
How is this key/value combination supposed to work? I have tested this on several desktop files and the app or applet still runs multiple instances.
I tested this in 3.5.10 with the same results.
Are there limited conditions under which X-DCOP-ServiceType=Unique is honored?
Darrell
Tim,
As with Libre has anyone looked at dialogs for OpenOffice? Apache
openoffice 3.4 was just released and it works great:
http://www.openoffice.org/download/
It is much.., much... more responsive that LO and avoids a couple of nasty
formatting bugs that affect line/character spacing in LO. Apache OO does have
a nice GTK file browser by default (like the tde browser), but it would be
nice to have an integrated browser for AOO as well.
--
David C. Rankin, J.D.,P.E.
Using recent GIT sources, does DrKonqi work correctly to create backtraces?
When I run crashtest in 3.5.10, DrKonqi creates a backtrace. In TDE all I get is the following message:
"This backtrace appears to be of no use.
This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash."
This worked some time in the past (I am the one who patched tdebase so crashtest would build).
My build scripts all use --enable-debug=full for automake and -ggdb for cmake. The build logs show that the packages are compiling with those flags and the increased package sizes are further evidence.
Yet I can't create a backtrace through DrKonqi. The crashtest binary should be sufficient to test DrKonqi.
Would somebody running a recent GIT please confirm whether they can create a backtrace with DrKonqi?
Thanks.
Darrell
I came across this through my G+ feed:
http://ekaia.org/blog/2012/05/20/long-due-to-do-item-removal-of-qt3-from-de…
I do not think this will affect Trinity much with its own (T)Qt3
packages, but it still seems relevant. I can imagine it may make it
slightly harder to get Trinity into Debian in the future.
Best regards,
Julius
Tim,
Today I am receiving a SIGABRT crash when I try to start Konqueror. I don't have debugging symbols enabled with this build.
My builds from May 14 late afternoon are okay. Therefore the possible candidates for the crash:
d3a9d561 2012-05-15 [tdelibs] Add the ability to force read-only configuration file access in a TDE application
Force tde-config to use read-only access
b45b4bd7 2012-05-15[tdebase] Fix KHTML smooth scrolling control center option
9a948c1a 2012-05-15 [tdebase] Disable keyboard shortcuts for file location moving, as they did not work properly and have very little practical use
b0fa10df 2012-05-15 [tdebase] Add drag and drop to kate file list in manual mode
46a657f7 2012-05-15 [tdebase] Add the ability to reorder documents in kate
Intermixing tdelibs and tdebase packages between the two dates is inconclusive. The only combination that runs fine is using both packages from May 14.
I'll have to debug by reverting patches one-by-one unless you have a hunch what happened.
Darrell
I've noticed many errors in my .xsession-error.log. The main culprit is:
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 19
Minor opcode: 0
Resource id: 0x3600134
The opcode is usually 19 or 20. The errors are mainly caused from gtk
applications written in gtkdialog with many other entries being from
tdeinit.
[tdeinit] Got EXT_EXEC 'kfmclient' from launcher.
[tdeinit] PID 4739 terminated.
At the moment i am softlinking .xsession-errors to /dev/null in my
environment. An ugly fix.
The log fills quite fast. Is this just bad coding of gtk apps?
Kind Regards,
Jay
Just an idea, nothing more:
============================================
Trinity Community,
Those of us involved with developing and supporting the Trinity Desktop Environment want the next release to be the best yet. With that goal we ask you to help us by participating in some simple polls.
1. Which bugs listed in the bug tracker are your favorites as paper cut candidates? A paper cut candidate is bug which in and of itself is insignificant and might be trivial to fix, but when combined with similar bugs creates an overall impression of an unfinished, buggy piece of software.
2. Which bugs listed in the bug tracker are your Most Hated Bugs? This is the type of bug that hampers productivity, causes data corruption or loss, or is something that doesn't work as expected or intended.
3. Which enhancement requests in the bug tracker do you want to see in the next Trinity release?
We will strive to resolve the top 20 vote getters in each of the first two lists and the top five vote getters for the third list.
No priorities are needed. Just provide us your list. Limit the first two lists to 20 items per list per person and the third list to five items per person.
Note: Only bug reports and enhancement requests listed in the bug tracker are eligible for these polls.
Note: Build issues are not candidates because we expect and intend to resolve those issues one way or another before the next release.
Bug tracker: http://bugs.pearsoncomputing.net/
At the bottom of the page the bug tracker contains links for commonly used search criteria. To list all reports filed, use the ALL search criteria. Any list can be sorted by selecting the appropriate column heading link.
Thank you for helping and thank you for supporting and using Trinity!
============================================
Post this or a similar request to all mail lists asking community members to vote.
I believe we have work remaining before we can consider a soft freeze for R14 preparations. These three polls would help us considerably with that preparation. Not to mention providing a good way for community involvement. Get users involved in a nominal way. The resulting corresponding resolutions show users they that have a voice and matter to us. The bug tracker provides a priority mechanism, but these polls help us refine those priorities.
We all are itching for the next official release. Tentatively that release is scheduled for May, this month. Let's ignore hard deadlines and do this right. A serious effort now to make R14 as bug free as practical means fewer bugs for the next cycle. Not to mention more time for us all just to use and enjoy Trinity. For many of us summer is around the corner and all of us look forward to a more leisurely pace. If we truly polish the next release then we all can do just that. :-)
Again, just an idea.
Darrell
Darrell,
Do you have the capability to build Kde3 on gcc 4.7 to test the kwrite issue.
I don't know if you have the same capabilities to build KDE as you do TDE, but
since I don't and since I haven't gotten a confirmation from the SuSE folks, I'm
curious if building 3.5.10 will show the same crash. If you have the sources and
build scripts for it, it is probably worth doing just to see if we can eliminate
the tqtinterface code as a possible source. If it is the same crash in KDE as it
is in TDE, then tqtinterface should be able to be eliminated.
Just a couple of stray thoughts that might add another piece of info to the
puzzle. If it is tdelibs, then I'm not sure that it is even worth doing, but
think about it.
Also, Tim, have you been able to set up a gcc 4.7 build environment yet? I
know you have another 26,539 things to do, but the more eyes we get on this
thing, the sooner we will find the culprit.
If anyone else has thought of another test they would like to see, then just
let me know, happy to do it here -- as long as I know what to do. Thanks.
--
David C. Rankin, J.D.,P.E.