When are bugs going to receive attention?
I don't eat my own dog food. Despite some enhancements, I continue using KDE 3.5.10 rather than Trinity 3.5.12.
I expended a lot of energy last autumn packaging Trinity 3.5.12 for Slackware 12.2. My personal schedule prevented further packaging efforts, but now that I again have some time, I am not motivated to package for recent releases. Why? There are many usability bugs that render Trinity frustrating. Many of which do not exist in KDE 3.5.10.
I filed bug reports for all of the problems after discussing them in this list. Not a single bug I filed in the bugzilla has been touched. I don't know C++ and that frustrates me because I can't fix the problems.
Some of the bugs in Trinity are carry overs from KDE3 and have existed a long time. Consider the bug of using kdeconfig as root user. Every time root uses kdeconfig, the applet creates a .kde folder in the system root directory. I have to add special lines to my rc.local to check and delete that directory.
Could I use Trinity despite all the usability bugs I reported? I could but I won't. For example, the kdesu bugs I reported leave me quite frustrated. I use kdesu many times each day and that tool works as expected in KDE 3.5.10.
A primary reason cited by many people for liking KDE3 is the desktop is highly configurable yet simple. No cruft like KDE4. People do not have to run a sqlite database in the background just to check email. People running KDE3 are not interested in a social or semantic desktop. Reading reviews and comments indicate overwhelmingly that many users detest Nepomuk, Strigi, and Akonadi. KDE3 is far more configurable than Xfce or LXDE without the cruft of KDE4. KDE3 can be run on more older hardware than KDE4 can ever hope. In other words, KDE3 is already a good desktop. Hence the dismay by many with the utter abandonment by the developers.
Trinity brought hope to such users. Many users of Trinity and KDE 3.5.10 do not want additional bling. They want a highly configurable yet stable desktop. In other words, the immediate focus should be bug quashing.
I appreciate the effort to move to a more modern build environment with cmake and interoperability with QT4. Those are good long-term goals and should continue, but I suspect those efforts have little to nothing to do with the immediacy of swatting bugs. Usability bugs are solved at the code level and not the build level.
If the reason for not quashing bugs is a lack of C++ coders, then Trinity is doomed right now.
My Slackware 12.2 system remains usable. Yet as time moves forward I cannot install or update certain packages because of the typical but awful lack of backwards compatibility found in free/libre software. Therefore I am facing the unpleasant decision of updating to a more recent release of Slackware. That means moving to a different desktop environment. I don't relish that decision, which is why I supported Trinity.
With the lack of bug quashing my enthusiasm for Trinity has diminished. Time for the rubber to meet the road. I am studying KDE4 and preparing for a possible migration. I would rather support Trinity but I have to face reality. So do all end-users who might prefer Trinity.
Packages must be readily available for end users. Other than Debian/(K)Ubuntu and Slackware 12.2, no other systems are listed as being supported. Such a short list supports the idea that Trinity is a niche product.
With the release of KDE 4.5.x series, and now 4.6, some people have written that KDE4 is ready for serious usage and has surpassed KDE3 in quality. Doesn't matter whether the proclamations are true or tainted --- the typical end-user believes the statements. Regrettably, such proclamations relegate Trinity to the status of niche product and the majority of users are not going to follow. Therefore any hopes of wide scale Trinity usage is fighting windmills. The only hope for Trinity is to provide a superb product for those who choose Trinity. Long-scale survival efforts such as with cmake and QT4 support are noble efforts but does nothing to push Trinity now. End-users don't care how packages are built. They only want to download and install packages. End users have to ask themselves a basic question: is Trinity a viable choice for desktop environments?
Being stable and bug-free goes a long way toward spawning interest in Trinity. As KDE4 increases in popularity and pushes Trinity further into niche product status, people will use Trinity because they do not want the massive cruft of KDE4 or the limited flexibility of Xfce and LXDE. Yet if Trinity is buggy then willingness to use Trinity disintegrates. That is now my unfortunate position.
I'm willing to support this project and have proven as much in the past. Many of the build issues that were fixed to allow building on a non-Kubuntu system were a result of my testing last summer. For many weeks last summer I think Tim and I were the only ones actively working with Trinity. I single-handedly created packages for Slackware 12.2. I can continue adding value in that respect, but I can't fix bugs without a healthy understanding of C++ and the overall desktop environment. Obtaining that level of knowledge and expertise requires many months of study.
I likely have stirred a hornet's nest with these comments. Yet so many bugs remaining untouched is a troubling sign. I am willing to try to package Trinity for the next Slackware release, but not until many bugs are quashed.
The Ubuntu people had a project called 100 Paper Cuts. I plea for the Trinity 101 Paper Cuts Project.
Darrell
On Friday 04 March 2011 21:20:12 Darrell Anderson wrote:
When are bugs going to receive attention?
I don't eat my own dog food. Despite some enhancements, I continue using KDE 3.5.10 rather than Trinity 3.5.12.
I expended a lot of energy last autumn packaging Trinity 3.5.12 for Slackware 12.2. My personal schedule prevented further packaging efforts, but now that I again have some time, I am not motivated to package for recent releases. Why? There are many usability bugs that render Trinity frustrating. Many of which do not exist in KDE 3.5.10.
Do you have a list of bugs that were introduced in Trinity and were not present in KDE 3.5.10?
On Friday 04 March 2011 21:20:12 Darrell Anderson wrote: When are bugs going to receive attention?
I don't eat my own dog food. Despite some enhancements, I continue using KDE 3.5.10 rather than Trinity 3.5.12.
I expended a lot of energy last autumn packaging Trinity 3.5.12 for Slackware 12.2. My personal schedule prevented further packaging efforts, but now that I again have some time, I am not motivated to package for recent releases. Why? There are many usability bugs that render Trinity frustrating. Many of which do not exist in KDE 3.5.10.
We have a very small team. We started out with just two team members, We have an expanded effort for development, and from what I've seen, most (all?) of the extra team doesn't know C++ and Qt, which leaves Tim to deal with the bugs himself during his limited free time. The extra help is working on learning cmake to help move us away from autotools.
If I had the time (and a new hard disk), I'd learn C++ and Qt to help bug squashing, but having two days that "might" be "mostly" free and "maybe" a couple hours on my other days is not enough to learn at a fast enough speed to be of much use.
We don't have a stable 3.5.13 release anyway, so you already have the latest stable 3.5.12 release. However, if you feel you can help squash bugs, feel free to grab our code from svn, look through the code, and submit patches on the bugtracker for the appropriate bug. If you can't help, then try to recruit some C++/Qt people to TDE to help expedite the process.
On Friday 04 March 2011 21:20:12 Darrell Anderson wrote:
When are bugs going to receive attention?
I don't eat my own dog food. Despite some enhancements, I continue using KDE 3.5.10 rather than Trinity 3.5.12.
I expended a lot of energy last autumn packaging Trinity 3.5.12 for Slackware 12.2. My personal schedule prevented further packaging efforts, but now that I again have some time, I am not motivated to package for recent releases. Why? There are many usability bugs that render Trinity frustrating. Many of which do not exist in KDE 3.5.10.
Do you have a list of bugs that were introduced in Trinity and were not present in KDE 3.5.10?
Darrell,
Please remember that we are delaying the 3.5.13 release until CMake porting is complete and a sizable chunk of those bugs have been fixed. I would encourage you to check back later and not dismiss the project immediately. We have far too few developers to get everything fixed in a timely manner; once CMake is complete our development team will definitely be focused on the remaining bugs.
Tim
Mostly all I have seen in this list for the past few months are cmake reports. Nothing about other aspects.
I regularly check the svn patch list. I do not check the bugzilla for resolutions because I never receive notices the bugs have been patched. Between the two I knew the bugzilla was receiving very little tender loving care.
When 3.5.13 is released is not as important to me. The effort to quash bugs is important. I would attempt to build packages for Slackware Current if I saw such serious progress. I'm not going to build packages when I already know certain bugs will drive me batty trying to use the system. Nor am I going to offer packages to the Slackware community knowing such bugs exist and I cannot fix them directly.
I truly wish I could code in C++. I can't. I can compile packages and test build processes and packages. I doubt Trinity would be in the condition found today for other distro packagers if we hadn't quashed many, many build process bugs last summer.
I received the distinct impression last autumn that 3.5.13 was going to focus on bug quashing and cmake and qt4 support would occur in parallel in the background. Hence my surprise many months later and the reason for my original post.
In my mind, 3.5.13 is a point release and should focus on bugs. The transition to cmake warrants something more than a point release. Perhaps version 3.6. That way end users know something significant occurred. If 3.5.13 is not going to be released unless and until cmake is fully supported, then I suggest not releasing as 3.5.13 but 3.6.
I prefer to see 3.5.13 as the next release and focus on serious bug quashing. That would allow additional time after the transition to cmake to ensure the new build process works on all distros. As of 3.5.12, the build process probably works on most distros. Quashing bugs should not affect that build process. I'll guess that I'll run into some build problems with Slackware Current, which is three releases beyond 12.2, for which I built packages. Yet at least we are not introducing new variables into the build process by moving to cmake. However, last fall when we did this, a significant number of the build problems were related to not properly including header files and tqt related problems. Those kinds of build bugs need to be fixed regardless of using automake or cmake.
Darrell
--- On Fri, 3/4/11, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
From: Timothy Pearson kb9vqf@pearsoncomputing.net Subject: Re: [trinity-devel] Bugs, bugs, bugs To: trinity-devel@lists.pearsoncomputing.net Date: Friday, March 4, 2011, 1:57 PM
On Friday 04 March 2011 21:20:12
Darrell Anderson wrote:
When are bugs going to receive attention?
I don't eat my own dog food. Despite some
enhancements, I continue using
KDE 3.5.10 rather than Trinity 3.5.12.
I expended a lot of energy last autumn packaging
Trinity 3.5.12 for
Slackware 12.2. My personal schedule prevented
further packaging
efforts, but now that I again have some time, I am not
motivated to package for
recent releases. Why? There are many usability
bugs that render Trinity
frustrating. Many of which do not exist in KDE
3.5.10.
Do you have a list of bugs that were introduced in
Trinity and were not
present in KDE 3.5.10?
Darrell,
Please remember that we are delaying the 3.5.13 release until CMake porting is complete and a sizable chunk of those bugs have been fixed. I would encourage you to check back later and not dismiss the project immediately. We have far too few developers to get everything fixed in a timely manner; once CMake is complete our development team will definitely be focused on the remaining bugs.
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 03/04/2011 10:01 PM, Darrell Anderson wrote:
Mostly all I have seen in this list for the past few months are cmake reports. Nothing about other aspects.
I regularly check the svn patch list. I do not check the bugzilla for resolutions because I never receive notices the bugs have been patched. Between the two I knew the bugzilla was receiving very little tender loving care.
When 3.5.13 is released is not as important to me. The effort to quash bugs is important. I would attempt to build packages for Slackware Current if I saw such serious progress. I'm not going to build packages when I already know certain bugs will drive me batty trying to use the system. Nor am I going to offer packages to the Slackware community knowing such bugs exist and I cannot fix them directly.
I truly wish I could code in C++. I can't. I can compile packages and test build processes and packages. I doubt Trinity would be in the condition found today for other distro packagers if we hadn't quashed many, many build process bugs last summer.
I received the distinct impression last autumn that 3.5.13 was going to focus on bug quashing and cmake and qt4 support would occur in parallel in the background. Hence my surprise many months later and the reason for my original post.
In my mind, 3.5.13 is a point release and should focus on bugs. The transition to cmake warrants something more than a point release. Perhaps version 3.6. That way end users know something significant occurred. If 3.5.13 is not going to be released unless and until cmake is fully supported, then I suggest not releasing as 3.5.13 but 3.6.
I prefer to see 3.5.13 as the next release and focus on serious bug quashing. That would allow additional time after the transition to cmake to ensure the new build process works on all distros. As of 3.5.12, the build process probably works on most distros. Quashing bugs should not affect that build process. I'll guess that I'll run into some build problems with Slackware Current, which is three releases beyond 12.2, for which I built packages. Yet at least we are not introducing new variables into the build process by moving to cmake. However, last fall when we did this, a significant number of the build problems were related to not properly including header files and tqt related problems. Those kinds of build bugs need to be fixed regardless of using automake or cmake.
Darrell
Hi Darrell,
As I mentioned on the list today, we have a major problem already. Trinity 3.5.12 with Automake just plain *will* *not* *build* on modern systems, so we are losing a lot of potential help for the bugs every day that CMake is unfinished. Very few people will purposefully downgrade (and break) their entire build system just to fix a Trinity bug or two. Also we cannot release something that is known not to build on 90% of current Linux distributions. The problem was far more pervasive than I originally thought, so I had no choice but to block on CMake and bump its priority to critical.
It's unpleasant I know, but I don't see any other way to do this.
Tim
On Saturday 05 March 2011 07:06:56 Timothy Pearson wrote:
As I mentioned on the list today, we have a major problem already. Trinity 3.5.12 with Automake just plain *will* *not* *build* on modern systems, so we are losing a lot of potential help for the bugs every day that CMake is unfinished. Very few people will purposefully downgrade (and break) their entire build system just to fix a Trinity bug or two. Also we cannot release something that is known not to build on 90% of current Linux distributions. The problem was far more pervasive than I originally thought, so I had no choice but to block on CMake and bump its priority to critical.
It's unpleasant I know, but I don't see any other way to do this.
But KDE 3.5.10 builds well for OpenSUSE 11.4. Is that automake issue only Trinity-specific?
What exactly breaks? Is this possibly a distro related issue?
Darrell
--- On Sat, 3/5/11, Ilya Chernykh neptunia@mail.ru wrote:
From: Ilya Chernykh neptunia@mail.ru Subject: Re: [trinity-devel] Bugs, bugs, bugs To: trinity-devel@lists.pearsoncomputing.net Date: Saturday, March 5, 2011, 6:01 AM On Saturday 05 March 2011 07:06:56 Timothy Pearson wrote:
As I mentioned on the list today, we have a major
problem already.
Trinity 3.5.12 with Automake just plain *will* *not*
*build* on modern
systems, so we are losing a lot of potential help for
the bugs every day
that CMake is unfinished. Very few people will
purposefully downgrade
(and break) their entire build system just to fix a
Trinity bug or two.
Also we cannot release something that is known not to
build on 90% of
current Linux distributions. The problem was far
more pervasive than I
originally thought, so I had no choice but to block on
CMake and bump
its priority to critical.
It's unpleasant I know, but I don't see any other way
to do this.
But KDE 3.5.10 builds well for OpenSUSE 11.4. Is that automake issue only Trinity-specific?
What exactly breaks? Is this possibly a distro related issue?
Darrell
It's not distro specific:
"Noteworthy changes in autoconf version 2.64
The internal macro AH_CHECK_HEADERS has been removed; while this is an internal change that should not mean anything to properly-written autotools, this actually breaks packages using the KDE 3.x autotools-based build system, in particular the KDE_CHECK_HEADERS macro. To work with autoconf 2.64, KDE3-based software should replace the calls to the KDE-specific macro with equivalent calls to the proper, standard AC_CHECK_HEADERS macro, after properly setting up the language to C++ if needed."
In other words, we can spend a lot of time rewriting the Automake system, OR we can port to a newer and better build system in probably the same amount of time it would take to fix Automake.
Tim
Then I vote that the next release be 3.6 and not 3.5.13. Too huge a transition for a point release.
Darrell
As I mentioned on the list today, we have a major problem already. Trinity 3.5.12 with Automake just plain *will* *not* *build* on modern systems, so we are losing a lot of potential help for the bugs every day that CMake is unfinished. Very few people will purposefully downgrade (and break) their entire build system just to fix a Trinity bug or two. Also we cannot release something that is known not to build on 90% of current Linux distributions. The problem was far more pervasive than I originally thought, so I had no choice but to block on CMake and bump its priority to critical.
It's unpleasant I know, but I don't see any other way to do this.
Tim
On 5 March 2011 12:07, Darrell Anderson humanreadable@yahoo.com wrote:
Then I vote that the next release be 3.6 and not 3.5.13. Too huge a transition for a point release.
Darrell
I would agree here, except for the fact that absolutely no one except package maintainers and the developers will notice the transistion to cmake.
On Saturday 05 March 2011 21:41:31 calvin morrison wrote:
Then I vote that the next release be 3.6 and not 3.5.13. Too huge a transition for a point release.
Darrell
I would agree here, except for the fact that absolutely no one except package maintainers and the developers will notice the transistion to cmake.
In addition to changing the build sytem it is also possible to add more applications, styles, icon themes etc.
Here is a list of bugzilla reports I believe are unique to Trinity and not inherited from KDE3.
268, 'Headers Present But Cannot Be Compiled' Warning Messages When Compiling 288, kdelibs icon bug 289, KInfoCenter Not Purged from Desktop and Still Contains Two Modules 290, Libcarddav: Cannot build in Slackware 12.2 291, DCOPReply messages in xsession-error log 292, TQTinterface Build Bugs 294, KControl Zeroconf Service Discovery Module 296, New Trinity Profile Error Messages 299, Samba: Something in Trinity Tries to Access Samba Config Files 306, Desktop Device Icon Arrangement 320, Branding Issues 335, Konqueror Icon Activation Effect 339, Duplicating upstream efforts 343, Update Outdated Kaffeine 346, Building amarok refuses to support mp4 tag writing 346, Building amarok refuses to support mp4 tag writing 350, Source tarball permissions are goofy 363, ktorrent is not the most recent version 385, Unmounted removable device icons do not appear on the desktop 387, Kicker/Panel Clock Font Display Looks Weird 388, KDESU Dialog Box Behavior 389, Activation Effects 390, Akregator Fails to Fetch Feeds Without KRB5 Installed 392, Desktop Device Icon Placement 393, Incorrect kdesu Behavior When Opening Kate 394, Problems with DCOP After Using kdesu
Here is a list of bugzilla reports I believe were inherited from KDE3.
230, Amarok Keyboard Shortcuts Do Not Work Correctly 242, Akregator forces external browser to front 244, Kate: Restore ability to specify the number of files in the Most Recently Used list 251, Kicker/panel has no configuration option to stop scrolling among apps 252, Panel handle pointers (the black arrow heads) are too large. 257, Ark: Disabling the warning message associated with opening files in an external viewer. 258, ksmserver: Logout confirmation fadeaway is too slow with older hardware 259, kompare does not always terminate properly, leaving the process running 261, kompare default 'Compare Files or Folders' dialog box behavior is flawed 270, KFileDialog: Provide an option to disable tooltip popups when hovering over long file names 293, Kde-config Incorrectly Creates a Profile Folder in the System root directory 297, Numerous "X Error: BadWindow" and "X Error: BadAccess" Messages 298, Libpng Warning Messages 300, Scroll Bar Width 301, Kompare does not maintain a correct mru list 302, Akgregator does not provide a keyboard shortcut or menu option to select and delete all feeds. 303, Safely Unmount does not always remove the icon from the desktop 304, KAlarm does not accept date changes to existing reoccurring actions 305, Akregator provides no configuration option to ignore favicons 336, ksystemlog bugs and enhancements 347, Amarok Sym Links Incorrect 348, kdebindings man pages split into two locations 353, KOffice will not build with GraphicsMagick 1.3.12 or 1.2.10 installed 386, Show Desktop behavior 427, NumLock light does not reflect actual state
This list is incomplete. I did not peruse the entire bugzilla. I browsed the reports I filed and some of those that affect me but filed by others.
Because of the efforts to move to cmake, possibly 29 of the reports I filed could be closed after the transition to cmake proves successful. That is approximately 6.5% of the 451 reports on file. I have not listed any of those reports.
Bear in mind the KDE3 sources used to start the Trinity Project were from Kubuntu. The sources were not the generic sources directly from the upstream KDE repository. In other words, the first Trinity sources contained 'buntu patches that the generic version did not. Slackware used the unpatched generic sources from the upstream KDE repository. Therefore people familiar only with 'buntu might never have seen the problems reported in the bugzilla because they presume KDE has "always worked that way" when that is not the case. An example is the kdesu behavior. Because the 'buntu developers only support sudo, the kdesu tool is broken on a non 'buntu system.
I hope this helps. :)
Darrell
--- On Fri, 3/4/11, Ilya Chernykh neptunia@mail.ru wrote:
From: Ilya Chernykh neptunia@mail.ru Subject: Re: [trinity-devel] Bugs, bugs, bugs To: trinity-devel@lists.pearsoncomputing.net Date: Friday, March 4, 2011, 1:21 PM On Friday 04 March 2011 21:20:12 Darrell Anderson wrote:
When are bugs going to receive attention?
I don't eat my own dog food. Despite some
enhancements, I continue using
KDE 3.5.10 rather than Trinity 3.5.12.
I expended a lot of energy last autumn packaging
Trinity 3.5.12 for
Slackware 12.2. My personal schedule prevented further
packaging efforts,
but now that I again have some time, I am not
motivated to package for
recent releases. Why? There are many usability bugs
that render Trinity
frustrating. Many of which do not exist in KDE
3.5.10.
Do you have a list of bugs that were introduced in Trinity and were not present in KDE 3.5.10?
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Saturday 05 March 2011 06:17:38 Darrell Anderson wrote:
Here is a list of bugzilla reports I believe are unique to Trinity and not inherited from KDE3.
343, Update Outdated Kaffeine
Strange. I have Kaffeine 0.8.8 under KDE 3.5.10. Was it intentionally downgraded in Trinity?
Do you use DVB in 0.8.8? I can build 0.8.8 in Slackware and 0.8.8 runs. Yet the DVB functions are broken. I have no such problems when building 0.8.7.
Darrell Anderson http://humanreadable.nfshost.com/
--- On Sat, 3/5/11, Ilya Chernykh neptunia@mail.ru wrote:
From: Ilya Chernykh neptunia@mail.ru Subject: Re: [trinity-devel] Bugs, bugs, bugs To: trinity-devel@lists.pearsoncomputing.net Date: Saturday, March 5, 2011, 5:54 AM On Saturday 05 March 2011 06:17:38 Darrell Anderson wrote:
Here is a list of bugzilla reports I believe are
unique to Trinity and not
inherited from KDE3.
343, Update Outdated Kaffeine
Strange. I have Kaffeine 0.8.8 under KDE 3.5.10. Was it intentionally downgraded in Trinity?
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Saturday 05 March 2011 20:15:47 Darrell Anderson wrote:
Do you use DVB in 0.8.8? I can build 0.8.8 in Slackware and 0.8.8 runs. Yet the DVB functions are broken. I have no such problems when building 0.8.7.
What is DVB? I only found a "DVB" entry in the menu which deals with sides ratio. If I choose it, the output becomes stretched horizontally.
BTW. as I see, Trinity also has an old KTorrent, was it made intentionally as well?
DVB: Digital Video Broadcasting. In other words, watching TV with a TV capture card. Version 0.8.8 fails to work for me in that respect. 0.8.7 works fine.
I filed bug report 363 about the ktorrent version.
Darrell
--- On Sat, 3/5/11, Ilya Chernykh neptunia@mail.ru wrote:
From: Ilya Chernykh neptunia@mail.ru Subject: Re: [trinity-devel] Bugs, bugs, bugs To: trinity-devel@lists.pearsoncomputing.net Date: Saturday, March 5, 2011, 12:56 PM On Saturday 05 March 2011 20:15:47 Darrell Anderson wrote:
Do you use DVB in 0.8.8? I can build 0.8.8 in
Slackware and 0.8.8 runs. Yet
the DVB functions are broken. I have no such problems
when building 0.8.7.
What is DVB? I only found a "DVB" entry in the menu which deals with sides ratio. If I choose it, the output becomes stretched horizontally.
BTW. as I see, Trinity also has an old KTorrent, was it made intentionally as well?
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Saturday 05 March 2011 22:22:55 Darrell Anderson wrote:
DVB: Digital Video Broadcasting. In other words, watching TV with a TV capture card. Version 0.8.8 fails to work for me in that respect. 0.8.7 works fine.
Oh I fugured out what is it. Is there a public server on the net?
Public server for what?
Darrell
--- On Sat, 3/5/11, Ilya Chernykh neptunia@mail.ru wrote:
From: Ilya Chernykh neptunia@mail.ru Subject: Re: [trinity-devel] Bugs, bugs, bugs To: trinity-devel@lists.pearsoncomputing.net Date: Saturday, March 5, 2011, 2:01 PM On Saturday 05 March 2011 22:22:55 Darrell Anderson wrote:
DVB: Digital Video Broadcasting. In other words,
watching TV with a TV
capture card. Version 0.8.8 fails to work for me in
that respect. 0.8.7
works fine.
Oh I fugured out what is it. Is there a public server on the net?
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
A TV capture card receives the TV signal over the air. Either through an antenna or satellite dish connection. A coax cable connects the card to the antenna.
Darrell
--- On Sat, 3/5/11, Ilya Chernykh neptunia@mail.ru wrote:
From: Ilya Chernykh neptunia@mail.ru Subject: Re: [trinity-devel] Bugs, bugs, bugs To: trinity-devel@lists.pearsoncomputing.net Date: Saturday, March 5, 2011, 4:22 PM On Sunday 06 March 2011 00:58:18 Darrell Anderson wrote:
Public server for what?
For DVB so I could test it.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Sunday 06 March 2011 02:06:07 Darrell Anderson wrote:
A TV capture card receives the TV signal over the air. Either through an antenna or satellite dish connection. A coax cable connects the card to the antenna.
There are IP address and port entry fields in Kaffeine. Thus I suppose the receiver may be separated from the computer.
On Saturday 05 March 2011 22:22:55 Darrell Anderson wrote:
DVB: Digital Video Broadcasting. In other words, watching TV with a TV capture card. Version 0.8.8 fails to work for me in that respect. 0.8.7 works fine.
I filed bug report 363 about the ktorrent version.
Anyway it is interesting why the versions are older. Was Trinity branches before KDE 3.5.10?
On Saturday 05 March 2011 22:22:55 Darrell Anderson wrote:
DVB: Digital Video Broadcasting. In other words, watching TV with a TV capture card. Version 0.8.8 fails to work for me in that respect. 0.8.7 works fine.
I filed bug report 363 about the ktorrent version.
Anyway it is interesting why the versions are older. Was Trinity branches before KDE 3.5.10?
A few applications were released upstream of Trinity after they were copied to SVN. ktorrent and kaffeine were among them. Yes, they should be upgraded in the Trinity SVN before 3.5.13 is released.
Tim
On Sunday 06 March 2011 04:37:26 Timothy Pearson wrote:
Anyway it is interesting why the versions are older. Was Trinity branches before KDE 3.5.10?
A few applications were released upstream of Trinity after they were copied to SVN. ktorrent and kaffeine were among them. Yes, they should be upgraded in the Trinity SVN before 3.5.13 is released.
Does it mean that other software can also be outdated in Trinity? I thought it is based on 2009 KDE3 branch...
On Sun, Mar 6, 2011 at 6:50 AM, Ilya Chernykh neptunia@mail.ru wrote:
On Sunday 06 March 2011 04:37:26 Timothy Pearson wrote:
Anyway it is interesting why the versions are older. Was Trinity branches before KDE 3.5.10?
A few applications were released upstream of Trinity after they were copied to SVN. ktorrent and kaffeine were among them. Yes, they should be upgraded in the Trinity SVN before 3.5.13 is released.
Does it mean that other software can also be outdated in Trinity? I thought it is based on 2009 KDE3 branch...
I thought it was based on 3.5.10...
Yes, other software can be outdated if it was updated after the sources for 3.5.10 were grabbed for Trinity. I think that is where he is getting at.
On Monday 07 March 2011 05:22:09 Kristopher Gamrat wrote:
Yes, other software can be outdated if it was updated after the sources for 3.5.10 were grabbed for Trinity. I think that is where he is getting at.
I believe Kaffeine and KTorrent were not updated since 3.5.10 release otherwise we had older version in OpenSUSE. Am I wrong?