G'day All, Is there a Trinity Live CD/DVD with kernel => 3.5 ?? Thanks, Glen
On 12/01/13 23:00, Glen Cunningham wrote:
G'day All, Is there a Trinity Live CD/DVD with kernel => 3.5 ?? Thanks, Glen
Is that a need for some specific hardware?
The (unofficial) ExeGNU Debian Wheezy live image is at 3.0.4
It has a remaster utility if anyone wants to try a rebuild. (linux-image-3.7 is now in Debian Experimental)
There are other images for pclinuxos and fedora but I don't know what kernel is used there.
David
Thanks for the quick reply, David.
On Sunday 13 January 2013 10:57:58 David Hare wrote:
On 12/01/13 23:00, Glen Cunningham wrote:
G'day All, Is there a Trinity Live CD/DVD with kernel => 3.5 ?? Thanks, Glen
Is that a need for some specific hardware?
Yes, the oldest kernel that supports the hardware (specifically the AMD graphics card) is 3.5.
The (unofficial) ExeGNU Debian Wheezy live image is at 3.0.4
Tried that - won't boot.
It has a remaster utility if anyone wants to try a rebuild. (linux-image-3.7 is now in Debian Experimental)
I'm not smart enough to do that. :-( Besides, the latest ExeGNU live CD won't boot, so the remaster utility cannot run.
There are other images for pclinuxos and fedora but I don't know what kernel is used there.
Tried all 3 "official" live CDs. None have a new enough kernel. I now have a fair selection of current Trinity Live CDs.
The hardware (Samsung 355E5C-A01) is not particularly new (got it fairly cheaply as an end-of-model-runout) but the AMD hardware did not get supported properly until kernel 3.5.
So far, the only live CD that boots and installs reliably is Mint-14, but as a GOF in little-kid mode, I want a TDE desktop.
I've searched the list archives and there are several mentions of installing Trinity on Mint but none are detailed enough for a GOF.
Glen
Thanks, Alexandre.
On Sunday 13 January 2013 11:40:53 Alexandre Couture wrote:
G'day All, Is there a Trinity Live CD/DVD with kernel => 3.5 ?? Thanks, Glen
My PCLOS tde liveCD is at: 3.2.18
Downloaded that, will not boot on the AMD hardware. See my earlier post.
and the Fedora 17 tde livecd is at: 3.5.4
Downloaded F17 this AM -- it has kernel 3.4.4-5.fc17.x86_64 which can be booted into a text-only terminal. No doubt, if I was smart enough, it could be upgraded to 3.5.4, but without any GUI it is way beyond my limited capabilities. :-(
Glen
My PCLOS tde liveCD is at: 3.2.18
Downloaded that, will not boot on the AMD hardware. See my earlierpost.
Very surprising to find PC hardware today that have difficulties in booting linux...
and the Fedora 17 tde livecd is at: 3.5.4
Downloaded F17 this AM -- it has kernel 3.4.4-5.fc17.x86_64 whichcan be booted into a text-only terminal. No doubt, if I was smart enough, it could be upgraded to 3.5.4, but without any GUI it is way beyond my limited capabilities. :-(
Glen
Oops, forgot to mention this detail: On the Trinity desktop environment website, go in the LiveCDs section (in the top part of the website), then you'll find the Fedora livecd with Trinity 3.5.13.1 Thanks! -Alexandre
On Sunday 13 January 2013 12:11:35 Alexandre Couture wrote: <snip>
Oops, forgot to mention this detail: On the Trinity desktop environment website, go in the LiveCDs section (in the top part of the website), then you'll find the Fedora livecd with Trinity 3.5.13.1 Thanks!
That is the one that I tried thismorning. It has kernel 3.4.something and I'm not smart enough to upgrade it to a newer kernel. G.
That is the one that I tried thismorning. It has kernel 3.4.something and I'm not smart enough to upgrade it to a newer kernel. G.
I think that it's because you took the 64bit version. The 32 bit version is the one I have downloaded in November and it has the kernel version I said. I booted it in VirtualBox to check the version number in the TDE Control Center.
-Alexandre
On Sunday 13 January 2013 13:09:19 Alexandre Couture wrote: <snip>
I think that it's because you took the 64bit version. The 32 bit version is the one I have downloaded in November
OK, Alexandre, will download and try the 32-bit one. Takes a couple of hours on this slow connection. Will post the results.
FWIW. I added the Trinity repositories to the 64-bit Mint install using the instructions at ... http://www.trinitydesktop.org/wiki/bin/view/Documentation/UbuntuBinaryInstallation but only got the dreaded "404 not found" message when I tried to "apt-get update" - bugger! Where have the repos gone? G.
I think that it's because you took the 64bit version. The 32 bit version is the one I have downloaded in November
OK, Alexandre, will download and try the 32-bit one. Takes a couple of hours on this slow connection. Will post the results.
We'll end up understanding what the other means... :)
FWIW. I added the Trinity repositories to the 64-bit Mint install using the instructions at ... http://www.trinitydesktop.org/wiki/bin/view/Documentation/UbuntuBinaryInstallation but only got the dreaded "404 not found" message when I tried to "apt-get update" - bugger! Where have the repos gone? G.
I don't know much about debian-derived distros but maybe you should check again later, maybe the servers were down?
-Alexandre
Dne ne 13. ledna 2013 Glen Cunningham napsal(a):
On Sunday 13 January 2013 13:09:19 Alexandre Couture wrote:
<snip>
I think that it's because you took the 64bit version. The 32 bit version is the one I have downloaded in November
OK, Alexandre, will download and try the 32-bit one. Takes a couple of hours on this slow connection. Will post the results.
FWIW. I added the Trinity repositories to the 64-bit Mint install using the instructions at ... http://www.trinitydesktop.org/wiki/bin/view/Documentation/UbuntuBinary Installation but only got the dreaded "404 not found" message when I tried to "apt-get update" - bugger! Where have the repos gone? G.
Which distribution you wrote in the apt source?
Slavek --
G'day Slávek,
On Wednesday 16 January 2013 06:56:35 Slávek Banko wrote:
Dne ne 13. ledna 2013 Glen Cunningham napsal(a):
<snip>
FWIW. I added the Trinity repositories to the 64-bit Mint install using the instructions at ...
http://www.trinitydesktop.org/wiki/bin/view/Documentation/UbuntuBinaryInstallation but only got the dreaded "404 not found" message
when I tried to "apt-get update" - bugger! Where have the repos gone? G.
Which distribution you wrote in the apt source?
quantal because that is indicated in /etc/apt/sources.list.d/ubuntu.list for Mint-14 Should I have used "precise"? Is it possible/advisable to mix precise with quantal?
Perhaps there are not yet trinity repos for qantal?
No big deal. It is just my desire to have a working TDE on the "new" laptop, but I can wait. G.
On Tuesday 15 of January 2013 22:30:03 Glen Cunningham wrote:
G'day Slávek,
On Wednesday 16 January 2013 06:56:35 Slávek Banko wrote:
Dne ne 13. ledna 2013 Glen Cunningham napsal(a):
<snip>
FWIW. I added the Trinity repositories to the 64-bit Mint install using the instructions at ...
http://www.trinitydesktop.org/wiki/bin/view/Documentation/UbuntuBinaryInst allation but only got the dreaded "404 not found" message
when I tried to "apt-get update" - bugger! Where have the repos gone? G.
Which distribution you wrote in the apt source?
quantal because that is indicated in /etc/apt/sources.list.d/ubuntu.list for Mint-14 Should I have used "precise"? Is it possible/advisable to mix precise with quantal?
Perhaps there are not yet trinity repos for qantal?
No big deal. It is just my desire to have a working TDE on the "new" laptop, but I can wait. G.
For Quantal is not yet official release in stable branch. You can use apt source with preliminary packages for 3.5.13.2. See:
https://quickbuild.pearsoncomputing.net/~slavek-banko/+archive/axis/+package...
Slavek --
On Wednesday 16 January 2013 11:23:26 Slávek Banko wrote:
On Tuesday 15 of January 2013 22:30:03 Glen Cunningham wrote:
G'day Slávek,
On Wednesday 16 January 2013 06:56:35 Slávek Banko wrote:
Dne ne 13. ledna 2013 Glen Cunningham napsal(a):
<snip>
FWIW. I added the Trinity repositories to the 64-bit Mint install using the instructions at ...
<http://www.trinitydesktop.org/wiki/bin/view/Documentation/UbuntuBi naryInst allation> but only got the dreaded "404 not found" message
when I tried to "apt-get update" - bugger! Where have the repos gone? G.
Which distribution you wrote in the apt source?
quantal because that is indicated in /etc/apt/sources.list.d/ubuntu.list for Mint-14 Should I have used "precise"? Is it possible/advisable to mix precise with quantal?
Perhaps there are not yet trinity repos for qantal?
No big deal. It is just my desire to have a working TDE on the "new" laptop, but I can wait. G.
For Quantal is not yet official release in stable branch. You can use apt source with preliminary packages for 3.5.13.2. See:
https://quickbuild.pearsoncomputing.net/~slavek-banko/+archive/axis/+ packages?field.series_filter=quantal&start=0&batch=150
Slavek
Thanks Slávek. Excuse my ignorance, but what are the actual exact lines to add to the sources.list(s) to point to these? Thanks in antic, Glen
Dne st 16. ledna 2013 Glen Cunningham napsal(a):
On Wednesday 16 January 2013 11:23:26 Slávek Banko wrote:
On Tuesday 15 of January 2013 22:30:03 Glen Cunningham wrote:
G'day Slávek,
On Wednesday 16 January 2013 06:56:35 Slávek Banko wrote:
Dne ne 13. ledna 2013 Glen Cunningham napsal(a):
<snip>
FWIW. I added the Trinity repositories to the 64-bit Mint install using the instructions at ...
<http://www.trinitydesktop.org/wiki/bin/view/Documentation/UbuntuBi naryInst allation> but only got the dreaded "404 not found" message
when I tried to "apt-get update" - bugger! Where have the repos gone? G.
Which distribution you wrote in the apt source?
quantal because that is indicated in /etc/apt/sources.list.d/ubuntu.list for Mint-14 Should I have used "precise"? Is it possible/advisable to mix precise with quantal?
Perhaps there are not yet trinity repos for qantal?
No big deal. It is just my desire to have a working TDE on the "new" laptop, but I can wait. G.
For Quantal is not yet official release in stable branch. You can use apt source with preliminary packages for 3.5.13.2. See:
https://quickbuild.pearsoncomputing.net/~slavek-banko/+archive/axis/+ packages?field.series_filter=quantal&start=0&batch=150
Slavek
Thanks Slávek. Excuse my ignorance, but what are the actual exact lines to add to the sources.list(s) to point to these? Thanks in antic, Glen
Currently, it is for Quantal one source, where is everything:
deb http://ppa.quickbuild.pearsoncomputing.net/slavek-banko/axis/ubuntu quantal main
Slavek --
On Thursday 17 January 2013 01:43:49 Slávek Banko wrote:
Dne st 16. ledna 2013 Glen Cunningham napsal(a):
On Wednesday 16 January 2013 11:23:26 Slávek Banko wrote:
On Tuesday 15 of January 2013 22:30:03 Glen Cunningham wrote:
G'day Slávek,
On Wednesday 16 January 2013 06:56:35 Slávek Banko wrote:
Dne ne 13. ledna 2013 Glen Cunningham napsal(a):
<snip>
FWIW. I added the Trinity repositories to the 64-bit Mint install using the instructions at ...
<http://www.trinitydesktop.org/wiki/bin/view/Documentation/Ubun tuBi naryInst allation> but only got the dreaded "404 not found" message
when I tried to "apt-get update" - bugger! Where have the repos gone? G.
Which distribution you wrote in the apt source?
quantal because that is indicated in /etc/apt/sources.list.d/ubuntu.list for Mint-14 Should I have used "precise"? Is it possible/advisable to mix precise with quantal?
Perhaps there are not yet trinity repos for qantal?
No big deal. It is just my desire to have a working TDE on the "new" laptop, but I can wait. G.
For Quantal is not yet official release in stable branch. You can use apt source with preliminary packages for 3.5.13.2. See:
https://quickbuild.pearsoncomputing.net/~slavek-banko/+archive/ax is/+ packages?field.series_filter=quantal&start=0&batch=150
Slavek
Thanks Slávek. Excuse my ignorance, but what are the actual exact lines to add to the sources.list(s) to point to these? Thanks in antic, Glen
Currently, it is for Quantal one source, where is everything:
deb http://ppa.quickbuild.pearsoncomputing.net/slavek-banko/axis/ubuntu quantal main
Thanks again, Slávek. That worked --- just needed to add the "--allow-unauthenticated" option to apt-get as I could not find a public key.
Now have some new problems but will start a new thread for that. Glen
Slavek
On Thursday 17 of January 2013 05:43:55 Glen Cunningham wrote:
Thanks again, Slávek. That worked --- just needed to add the "--allow-unauthenticated" option to apt-get as I could not find a public key.
Now have some new problems but will start a new thread for that. Glen
Slavek
apt-key adv --keyserver keyserver.quickbuild.pearsoncomputing.net --recv-keys 80479E11
Slavek --
David Hare's amazing EXE GNU/Linux has made it onto Distrowatch. Well done David. And yes Trinity gets a mention. Lets hit this up the rankings. http://distrowatch.com/table.php?distribution=exe
That is very kuhl, indeed! I will be visiting the EXE GNU/Linux distrowatch page daily.
Cheers,
Elcaset
On Mon, Jan 21, 2013 at 3:50 AM, Gareth Waite garfilth@gmail.com wrote:
David Hare's amazing EXE GNU/Linux has made it onto Distrowatch. Well done David. And yes Trinity gets a mention. Lets hit this up the rankings. http://distrowatch.com/table.php?distribution=exe
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Exe has been around a few years now, since even before TDE officially supported Debian. It's good to see a little recognition and that there are a few out there who actually like and use it. I don't know how Distrowatch got to hear of it and don't do much to promote it anywhere beyond this mailing list.
It seems still to be the only live build with TDE on an otherwise straight Debian base. The intention is to provide both a useful live environment in itself and a relatively simple installation method .
Exe also aims to be relatively "lightweight" and uses a good balance of packages while minimising "bloat" (a common criticism of kde3x when it was mainstream) The TDE "meta" is not used here and careful attention is given to excess "recommends" packages.
There are however limits to what one person can do. How good it is depends on others testing and bug-reporting... although so far feedback has been mostly positive, there doesn't seem a lot wrong with it. In any case it will continue at least through to Wheezy, the upcoming Debian stable release.
If Exe helps in turn give TDE some positive publicity, that's also the intention. Thanks to TDE devs who made Exe possible and those on this mailing list who helped test it.
David
David,
Thanks for creating & maintaining Exe GNU/Linux. That is a surprise that that it got on distrowatch without you submitting it. I wonder who did. Porteus Linux stopped using TDE, & replaced it with razor-qt. So, Exe is the only distro on distrowatch that uses TDE. Therefore, Exe really is helping quite a lot to promote TDE.
Compared to modern desktop environments, TDE isn't bloated at all. That's not meant to be a slap in the face to KDE 4, though. I use KDE 4 on newer hardware & TDE on older hardware, and love them both.
Cheers,
Elcaset
On Thu, Jan 24, 2013 at 7:31 AM, David Hare davidahare@gmail.com wrote:
Exe has been around a few years now, since even before TDE officially supported Debian. It's good to see a little recognition and that there are a few out there who actually like and use it. I don't know how Distrowatch got to hear of it and don't do much to promote it anywhere beyond this mailing list.
It seems still to be the only live build with TDE on an otherwise straight Debian base. The intention is to provide both a useful live environment in itself and a relatively simple installation method .
Exe also aims to be relatively "lightweight" and uses a good balance of packages while minimising "bloat" (a common criticism of kde3x when it was mainstream) The TDE "meta" is not used here and careful attention is given to excess "recommends" packages.
There are however limits to what one person can do. How good it is depends on others testing and bug-reporting... although so far feedback has been mostly positive, there doesn't seem a lot wrong with it. In any case it will continue at least through to Wheezy, the upcoming Debian stable release.
If Exe helps in turn give TDE some positive publicity, that's also the intention. Thanks to TDE devs who made Exe possible and those on this mailing list who helped test it.
David
------------------------------**------------------------------**--------- To unsubscribe, e-mail: trinity-users-unsubscribe@** lists.pearsoncomputing.nettrinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.** pearsoncomputing.net trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.** pearsoncomputing.net/ http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.** pearsoncomputing.net/mailing_**lists/#top-postinghttp://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Thursday 24 of January 2013 19:59:50 C W wrote:
Porteus Linux stopped using TDE, & replaced it with razor-qt.
So it is very sad information for me. I like to occasionally used Porteus because of TDE. KDE4 is not for me and RazorQT is incomparable with a comprehensive desktop environment, such as TDE.
Slavek --
Am Donnerstag, 24. Januar 2013, 10:59:50 schrieb C W:
I use KDE 4 on newer hardware & TDE on older hardware, and love them both.
same here :) in fact, kde4 (> 4.9.4) has now reached a state, where even akonadified kde-pim is usable (though still sluggish and somewhat unstable). plus, it has lots of matured apps, like blogilo, digikam etc. and konqueror as a web browser ist really usable (konqueror from TDE is not). so, for modern hardware, I now recommend kde4. on older hardware, however, kde4 is a no-go, while TDE still runs fine. just use another browser (chromium, e.g.)
Werner
Am Donnerstag, 24. Januar 2013, 10:59:50 schrieb C W:
I use KDE 4 on newer hardware & TDE on older hardware, and love them both.
same here :) in fact, kde4 (> 4.9.4) has now reached a state, where even akonadified kde-pim is usable (though still sluggish and somewhat unstable). plus, it has lots of matured apps, like blogilo, digikam etc. and konqueror as a web browser ist really usable (konqueror from TDE is not). so, for modern hardware, I now recommend kde4. on older hardware, however, kde4 is a no-go, while TDE still runs fine. just use another browser (chromium, e.g.)
Werner
While KDE4 has definitely improved, and in fact several components are now quite usable and sometimes even better than their TDE counterparts, the overall usability of the KDE workspace still seems suboptimal to me.
I am currently looking into methods of using the improved KDE4 components to enhance portions of TDE (e.g. Konqueror) while keeping the same stability and usability we currently have. Stay tuned. :-)
Tim
Am Donnerstag, 24. Januar 2013, 13:55:57 schrieb Timothy Pearson:
While KDE4 has definitely improved, and in fact several components are now quite usable and sometimes even better than their TDE counterparts,
this is a fact that just can't be denied.
the overall usability of the KDE workspace still seems suboptimal to me.
hm, I just use it more or less the same way I do with TDE. never touched the so called activities (which didn't work anyway, once I tried) nor the intrusive cashew :) krunner (ALT+F2), a central workspace tool, is great, however.
I am currently looking into methods of using the improved KDE4 components to enhance portions of TDE (e.g. Konqueror) while keeping the same stability and usability we currently have. Stay tuned.
sounds good ;-)
Werner
On Thursday 24 January 2013 10:55:57 am you wrote:
I am currently looking into methods of using the improved KDE4 components to enhance portions of TDE (e.g. Konqueror) while keeping the same stability and usability we currently have. Stay tuned. :-)
Tim
This interests me. Debian Squeeze/TDE3.5.13-2
PDF capability is a primary concern here. Not sure how all the parts work together but I track ,ghostscript, poppler, and the various apps that use them.
I never know why a pdf someone sends me can not be opened, so I try to be as current as possible with pdf and releated software. 'About:kpdf- based on xpdf 2004-2005,'
Does Okular improve compatability or is it more the underlying libraries.?
I am currently looking into methods of using the improved KDE4 components to enhance portions of TDE (e.g. Konqueror) while keeping the same stability and usability we currently have. Stay tuned. :-)
Tim
Tim, While I agree that some KDE4 apps are better than the TDE version (Dolphin is the first example of it, mostly because it appeared at the end of the KDE3 era), I fear that TDE will loose it's memory footprint over current KDE, which is in my opinion, the main reason to use TDE.
On my Asus EEE with 512mb of RAM (soldered onboard, and I have some swap space)), the first release of PCLOS 2010, which was the first version of it to run KDE4, the speed was minable, but still usable. I was able to install the system from the livecd and it worked. With the current release, I could only install it with the option from the boot menu to just launch the installer, without the whole desktop. After rebooting, when the installation is complete, the computer couldn't even boot to the complete desktop completely. It crashes and it's out of RAM. Even on my main computer, a Core 2 Duo with 2gb of RAM, for no reasons, KDE4 takes sometimes 5 x more time to load and get to the desktop. Running the latest version of PCLOS was even the reason I had to buy a newer computer, because my P4 with 768mb of RAM wasn't fast enough.
With TDE on my Asus EEE, everything works fast and flawlessly. I don't want to use incomplete or ugly ''lightweight'' desktop, or else I'll simply use IceWM. If KDE4 parts are to be used in TDE, it will probably seriously loose its advantage of being faster, at least for me. Firefox is almost the web standard and for using it sometimes, Konqueror on KDE4 is not much better than the version on TDE. KHTML hasn't evolved enough for worthing it, and WebKit is slow and not compatible with everything. I am not a developer, and I have no idea if it is possible to do, but if the avenue of trying to integrate the Gecko web engine of Mozilla is possible, it would be much better!
Just my opinion. -Alexandre
I am currently looking into methods of using the improved KDE4 components to enhance portions of TDE (e.g. Konqueror) while keeping the same stability and usability we currently have. Stay tuned. :-)
Tim
Tim, While I agree that some KDE4 apps are better than the TDE version (Dolphin is the first example of it, mostly because it appeared at the end of the KDE3 era), I fear that TDE will loose it's memory footprint over current KDE, which is in my opinion, the main reason to use TDE.
<snip>
I do understand your concern. I will not be replacing any TDE component that is still superior to its KDE counterpart; for a KDE component to be a candidate for replacement it must: 1.) Provide all the functionality and configurability of its TDE counterpart 2.) Be better than its TDE counterpart in at least one respect (performance, stability, compatibility with new file formats, etc.) 3.) Not use an appreciably higher amount of CPU or RAM, even in non-GPU accelerated rendering modes 4.) Not drag in any system services or libraries which violate Point #3 above; this intrinsically excludes the entire KDE PIM suite due to the bloated indexing services required for operation
The only items that I am aware of that might fit this list of criteria are kwin, a handful of kcontrol modules, and possibly some smaller KDE applications such as Okular. kwin is my current focus, and so far seems to work very well without increasing the memory or CPU footprint. kwin also satisfies Point #2 above by presenting a much smoother action in high resolution TDE sessions when compared with twin due to its integrated compositing engine.
Mozilla has explicitly stated that it will not support embedding Firefox sessions in any third party application, and has removed all programming hooks needed for doing so. This leaves TDE with three long-term options: 1.) Use Webkit (preferred) 2.) Investigate embedding a Chromium instance 2.) Completely remove the KHTML kpart (not recommended)
I would prefer to embed a Webkit browser kpart, as I expect website compatibility with Webkit to increase in the future, and a full-featured Webkit widget already exists.
Now that some KDE components are finally stabilising and becoming true replacements for their KDE3 counterparts, we should be attempting to reintegrate this new and improved technology into TDE where appropriate.
Thoughts are of course welcome on these topics!
Tim
<snip>
I do understand your concern. I will not be replacing any TDE component that is still superior to its KDE counterpart; for a KDE component to be a candidate for replacement it must: 1.) Provide all the functionality and configurability of its TDE counterpart 2.) Be better than its TDE counterpart in at least one respect (performance, stability, compatibility with new file formats, etc.) 3.) Not use an appreciably higher amount of CPU or RAM, even in non-GPU accelerated rendering modes 4.) Not drag in any system services or libraries which violate Point #3 above; this intrinsically excludes the entire KDE PIM suite due to the bloated indexing services required for operation
The only items that I am aware of that might fit this list of criteria are kwin, a handful of kcontrol modules, and possibly some smaller KDE applications such as Okular. kwin is my current focus, and so far seems to work very well without increasing the memory or CPU footprint. kwin also satisfies Point #2 above by presenting a much smoother action in high resolution TDE sessions when compared with twin due to its integrated compositing engine.
Mozilla has explicitly stated that it will not support embedding Firefox sessions in any third party application, and has removed all programming hooks needed for doing so. This leaves TDE with three long-term options: 1.) Use Webkit (preferred) 2.) Investigate embedding a Chromium instance 2.) Completely remove the KHTML kpart (not recommended)
I would prefer to embed a Webkit browser kpart, as I expect website compatibility with Webkit to increase in the future, and a full-featured Webkit widget already exists.
Now that some KDE components are finally stabilising and becoming true replacements for their KDE3 counterparts, we should be attempting to reintegrate this new and improved technology into TDE where appropriate.
Thoughts are of course welcome on these topics!
Tim
Galeon is an example of non-mozilla browser using Gecko as a core and on the wikipedia page of gecko, there is a list of other browsers using it: http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29 There is even a gecko render module for wine that is used for windows programs who needs web rendering.
I know that they are talking about separating apps from the big kdelibs for kde5 and qt5, which is already released, and it will probably help a lot, but for now, does using apps like Okular or kwin involves loading the big kdelibs?
-Alexandre
I suggest using webkit. It is same, simple, and used all over. I spent a little bit of time working with it in GTK and it was a pleasure. There are non-hacky qt libraries to use webkit with, so I think it is the obvious option.
On 24 January 2013 17:45, Alexandre Couture ac586133@hotmail.com wrote:
<snip>
I do understand your concern. I will not be replacing any TDE component that is still superior to its KDE counterpart; for a KDE component to be a candidate for replacement it must: 1.) Provide all the functionality and configurability of its TDE counterpart 2.) Be better than its TDE counterpart in at least one respect (performance, stability, compatibility with new file formats, etc.) 3.) Not use an appreciably higher amount of CPU or RAM, even in non-GPU accelerated rendering modes 4.) Not drag in any system services or libraries which violate Point #3 above; this intrinsically excludes the entire KDE PIM suite due to the bloated indexing services required for operation
The only items that I am aware of that might fit this list of criteria are kwin, a handful of kcontrol modules, and possibly some smaller KDE applications such as Okular. kwin is my current focus, and so far seems to work very well without increasing the memory or CPU footprint. kwin also satisfies Point #2 above by presenting a much smoother action in high resolution TDE sessions when compared with twin due to its integrated compositing engine.
Mozilla has explicitly stated that it will not support embedding Firefox sessions in any third party application, and has removed all programming hooks needed for doing so. This leaves TDE with three long-term options: 1.) Use Webkit (preferred) 2.) Investigate embedding a Chromium instance 2.) Completely remove the KHTML kpart (not recommended)
I would prefer to embed a Webkit browser kpart, as I expect website compatibility with Webkit to increase in the future, and a full-featured Webkit widget already exists.
Now that some KDE components are finally stabilising and becoming true replacements for their KDE3 counterparts, we should be attempting to reintegrate this new and improved technology into TDE where appropriate.
Thoughts are of course welcome on these topics!
Tim
Galeon is an example of non-mozilla browser using Gecko as a core and on the wikipedia page of gecko, there is a list of other browsers using it: http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29 There is even a gecko render module for wine that is used for windows programs who needs web rendering.
I know that they are talking about separating apps from the big kdelibs for kde5 and qt5, which is already released, and it will probably help a lot, but for now, does using apps like Okular or kwin involves loading the big kdelibs?
-Alexandre
Galeon is an example of non-mozilla browser using Gecko as a core and on the wikipedia page of gecko, there is a list of other browsers using it: http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29 There is even a gecko render module for wine that is used for windows programs who needs web rendering.
Interesting! I wonder how much work it would be to create a Gecko-based Web browser widget though.
I know that they are talking about separating apps from the big kdelibs for kde5 and qt5, which is already released, and it will probably help a lot, but for now, does using apps like Okular or kwin involves loading the big kdelibs?
-Alexandre
kwin is the only application that won't involve loading kdelibs5, and as that support is not yet in kwin I can't officially switch to kwin instead of twin at this time. However, AFAIK work is underway to make an independent version of kwin that does not rely on KDE's libraries, therefore we should be looking at what will be needed to make the switch once that version is available.
The dependency on kdelibs5 means most pure KDE applications and components are essentially off limits to TDE, however as a result of the KDE4 transition many applications now only depend on Qt4, or offer a version that does not depend on KDE. As a result we will only need to be concerned with Qt4 library overhead for most components, which should be minimal.
Tim
However, AFAIK work is underway to make an independent version of kwin that does not rely on KDE's libraries, therefore we should be looking at what will be needed to make the switch once that version is available.
Who guarantees that kdelibs5 will not be pulled in again later?
Nik
However, AFAIK work is underway to make an independent version of kwin that does not rely on KDE's libraries, therefore we should be looking at what will be needed to make the switch once that version is available.
Who guarantees that kdelibs5 will not be pulled in again later?
Nik
We do, by maintaining a GIT submodule referencing the correct version of kwin. If kdelibs5 is pulled back in we simply freeze kwin again until upstream repairs the damage. ;-)
Tim
Timothy Pearson wrote:
The dependency on kdelibs5 means most pure KDE applications and components are essentially off limits to TDE, however as a result of the KDE4 transition many applications now only depend on Qt4, or offer a version that does not depend on KDE. As a result we will only need to be concerned with Qt4 library overhead for most components, which should be minimal.
Do you really think kdelibs5 is a fully off limits? I tried to see if I could get the early KDE4 version of Kicker to run on KDE 4.9 and it turned out to work quite ok and not too slow once I had it mostly working.
I could imagine some kind of migration path where applications would migrate one by one from tdelibs to kdelibs5 in the future.
Julius
On 2013-01-24 15:50 (GMT-0600) Timothy Pearson composed:
Mozilla has explicitly stated that it will not support embedding Firefox sessions in any third party application, and has removed all programming hooks needed for doing so.
So Camino is no more?
This leaves TDE with three long-term options: 1.) Use Webkit (preferred) 2.) Investigate embedding a Chromium instance 2.) Completely remove the KHTML kpart (not recommended)
I would prefer to embed a Webkit browser kpart, as I expect website compatibility with Webkit to increase in the future, and a full-featured Webkit widget already exists.
http://fm.no-ip.com/SS/dpi1920x1200x144-gecko-konq3-chromium-konq4.png demonstrates that there is a cost to users of high density displays when Webkit is used to display web content. What cannot be seen in the screenshot is that Chromium's behavior matches IE, Opera and Safari, which is that physical units don't actually exist except when physical display density is in fact 96 DPI. Gecko also matches that fixed 3:4 pt:px ratio, but provides a workaround through the proprietary mozmm unit that is unnecessary for KHTML to display physical units at their actual size whenever desktop DPI matches physical display DPI.
I vote stick to KHTML.
URL to test for yourself: http://fm.no-ip.com/Auth/dpi-screen-window.html
On 2013-01-24 15:50 (GMT-0600) Timothy Pearson composed:
Mozilla has explicitly stated that it will not support embedding Firefox sessions in any third party application, and has removed all programming hooks needed for doing so.
So Camino is no more?
I don't know, sorry. :-) When I looked into this many months ago the interface to the Firefox core was being deprecated and removed, and I have heard no information to the contrary since.
This leaves TDE with three long-term options: 1.) Use Webkit (preferred) 2.) Investigate embedding a Chromium instance 2.) Completely remove the KHTML kpart (not recommended)
I would prefer to embed a Webkit browser kpart, as I expect website compatibility with Webkit to increase in the future, and a full-featured Webkit widget already exists.
http://fm.no-ip.com/SS/dpi1920x1200x144-gecko-konq3-chromium-konq4.png demonstrates that there is a cost to users of high density displays when Webkit is used to display web content. What cannot be seen in the screenshot is that Chromium's behavior matches IE, Opera and Safari, which is that physical units don't actually exist except when physical display density is in fact 96 DPI. Gecko also matches that fixed 3:4 pt:px ratio, but provides a workaround through the proprietary mozmm unit that is unnecessary for KHTML to display physical units at their actual size whenever desktop DPI matches physical display DPI.
I vote stick to KHTML.
URL to test for yourself: http://fm.no-ip.com/Auth/dpi-screen-window.html
To everyone on this list, how does the KDE4 version of KHTML compare with WebKit? Better or worse compatibility with most websites? If KHTML is pretty much the same as WebKit as far as CPU/RAM usage and website compatibility, the easiest solution would be to integrate KHTML as a kioslave in very much the same way as the old version of KHTML works now in TDE...
Thanks!
Tim
To everyone on this list, how does the KDE4 version of KHTML compare with WebKit? Better or worse compatibility with most websites? If KHTML is pretty much the same as WebKit as far as CPU/RAM usage and website compatibility, the easiest solution would be to integrate KHTML as a kioslave in very much the same way as the old version of KHTML works now in TDE...
Thanks!
Tim
The KHTML version in kde4 is not much more evolved than the one in tde. It has many problems with big websites such as facebook. This is one of the things that surprised me the most of kde4: khtml hasn't improved to the point of being comparable with the other modern browsers. Many times you click on what is a button in other browsers and it does nothing, this is on PCLOS 2012 with kde 4.8
Webkit has better compatibility but it is quite slow. I have seen somewhere that in Konqueror from kde4, you can choose between webkit (from qt4) and the internal khtml. Webkit should use less cpu because it doesn't stall on every javascript as the older khtml.
-Alexandre
Webkit has better compatibility but it is quite slow.
Did you just randomly come up with this idea? As far as I can tell Webkit is like usual, neck in neck with chrome and firefox for rendering and JS performance test.
Calvin
Webkit has better compatibility but it is quite slow.
Did you just randomly come up with this idea? As far as I can tell Webkit is like usual, neck in neck with chrome and firefox for rendering and JS performance test.
Calvin
Of course, I came in with this idea just randomly :)
These browsers have to be tested on a slower computer to see the difference between them. -Firefox is, from the tests I can do on a slower computer, faster than the others (it excludes dillo, you'll understand why... I love it, but it's incomplete) Chrome seems to have the best implementation of Webkit, but it is a modified version of it. -Webkit-based browsers (like arora and others) have a nice render, but it takes a lot of cpu, so it end up being slow on a slow computer. -KHTML, when it doesn't freeze on a Javascript, is comparable in cpu use and speed to Webkit, but it loads all the pictures first and only when every single picture is loaded, it displays the text of the page, so it's very long to see something when you are not on broadband.
It's sure that they all have their advantages and inconvenients, but they are amplified on a slower computer. This might be why you haven't seen much difference between different rendering engines on your computer.
-Alexandre
Am Donnerstag, 24. Januar 2013, 23:40:33 schrieb Timothy Pearson:
To everyone on this list, how does the KDE4 version of KHTML compare with WebKit? Better or worse compatibility with most websites? If KHTML is pretty much the same as WebKit as far as CPU/RAM usage and website compatibility, the easiest solution would be to integrate KHTML as a kioslave in very much the same way as the old version of KHTML works now in TDE...
I use konqueror currently with the webkit kpart rendering enabeled - this does usually work reasonably well on sites where the khtml part has problems. sometimes, khtml is better, though. switching rendering engine is a breeze, once figured out, how to do it :) can't say anything about ram/cpu-usage.
Werner
On 2013-01-24 23:40 (GMT-0600) Timothy Pearson composed:
Mozilla has explicitly stated that it will not support embedding Firefox sessions in any third party application, and has removed all programming hooks needed for doing so.
So Camino is no more?
Its last release was close to a year ago, but.....
I don't know, sorry. :-) When I looked into this many months ago the interface to the Firefox core was being deprecated and removed, and I have heard no information to the contrary since.
SeaMonkey isn't Firefox, yet it uses the same Necko and Gecko as the latest Firefox, and gets released concurrently with each FF version bump. Whether or not SM includes Firefox in its UA string is optional. So it seems there must be a way if there's enough will.
http://fm.no-ip.com/SS/dpi1920x1200x144-gecko-konq3-chromium-konq4.png
To everyone on this list, how does the KDE4 version of KHTML compare with WebKit? Better or worse compatibility with most websites? If KHTML is pretty much the same as WebKit as far as CPU/RAM usage and website compatibility, the easiest solution would be to integrate KHTML as a kioslave in very much the same way as the old version of KHTML works now in TDE...
Since WebKit was started as a fork of KHTML by Apple, it seems the KDE developers must be backporting WebKit changes into KHTML in a cherry picking fashion, that is to say, leaving out parts that cause display density to be ignored, and whatever forces the 3:4 pt/px ratio. As "works" example, you can see in the screenshot that current KHTML includes web font support, and nominal rendering difference between Konq 4 and latest FF.
Hi everyone! I have found some infos about what has been a prototype of a Kpart Gecko web render. It seems to be named ''kecko'' at some places. These links are of about 2004-2005:
If something could be done with it, here they are: http://dot.kde.org/2004/09/11/akademy-hackers-port-mozilla-qtkde http://osdir.com/ml/kde.redhat.user/2005-04/msg00118.html http://www.mozillazine.org/talkback.html?article=5263 http://lists.debian.org/debian-qt-kde/2004/10/msg00217.html
Some other infos about WebKit: http://www.osnews.com/story/21765/_QtWebKit_KPart_Is_Not_the_Answer_for_Konq...
Have a nice day! -Alexandre
Hi Timothy
The only items that I am aware of that might fit this list of criteria are kwin, a handful of kcontrol modules, and possibly some smaller KDE applications such as Okular. kwin is my current focus, and so far seems to work very well without increasing the memory or CPU footprint. kwin also satisfies Point #2 above by presenting a much smoother action in high resolution TDE sessions when compared with twin due to its integrated compositing engine.
But kwin has much trouble with multi screen systems. It can't scale images across two or more monitors and has a bugs in calculating the window size - i.e. minimize and maximize a windows shows holes in the window borders.
Hope, that multi screen will be tested exentsive than the bugs in KDE4 in this area stops me using it.
Fine regards Rolf
Hi Timothy
The only items that I am aware of that might fit this list of criteria are kwin, a handful of kcontrol modules, and possibly some smaller KDE applications such as Okular. kwin is my current focus, and so far seems to work very well without increasing the memory or CPU footprint. kwin also satisfies Point #2 above by presenting a much smoother action in high resolution TDE sessions when compared with twin due to its integrated compositing engine.
But kwin has much trouble with multi screen systems. It can't scale images across two or more monitors and has a bugs in calculating the window size
i.e. minimize and maximize a windows shows holes in the window borders.
Hope, that multi screen will be tested exentsive than the bugs in KDE4 in this area stops me using it.
Fine regards Rolf
Interesting! Martin, do you know if these bugs are still present in kwin?
For what it's worth, twin will not be replaced in the R14.0 cycle, but kwin should be available as an unsupported option for R14.0 so that we have time to find and fix problems such as the one you described above.
Also, I use multiple monitors on a daily basis, and have a older triple head setup specifically for testing unusual configurations, so this issue would have shown itself very quickly once kwin testing progressed to that point. ;-)
Tim
On Thu, 24 Jan 2013, Werner Joss wrote:
Am Donnerstag, 24. Januar 2013, 10:59:50 schrieb C W:
I use KDE 4 on newer hardware & TDE on older hardware, and love them both.
same here :) in fact, kde4 (> 4.9.4) has now reached a state, where even akonadified kde-pim is usable (though still sluggish and somewhat unstable). plus, it has lots of matured apps, like blogilo, digikam etc. and konqueror as a web browser ist really usable (konqueror from TDE is not). so, for modern hardware, I now recommend kde4. on older hardware, however, kde4 is a no-go, while TDE still runs fine. just use another browser (chromium, e.g.)
Werner
I don't know enough about kde4 to judge the maturity of its apps (and I turn off akonadi as soon as I install so that's moot for me) but I have noticed that a couple of times I haven't noticed I was running kde4 (say on netrunner). (you can notice not noticing, after the fact.)
it still takes some wrestling to simplify the interface to what I like whereas tde3 looks like what I want almost out of the box, I just have to remove bits of eye-candy like 'scenic' backgrounds and adjust fonts, etc.
(it's weird, the 'desktop' metaphor; normally one's real desktop is out of sight; one doesn't decorate it. (or does one?))
can someone explain in very brief terms what the use of 'plasmoids' is?
F.
<snip>
can someone explain in very brief terms what the use of 'plasmoids' is?
AFAIK if you remember SuperKaramba, Plasmoids are pretty much the same concept with a completely different implementation.
Any KDE4 users, please correct me if I am wrong. :-)
Tim
On Thu, 24 Jan 2013, Timothy Pearson wrote:
<snip> > can someone explain in very brief terms what the use of 'plasmoids' > is?
AFAIK if you remember SuperKaramba, Plasmoids are pretty much the same concept with a completely different implementation.
Any KDE4 users, please correct me if I am wrong. :-)
Tim
I bet you are right but I have no idea what 'superkaramba' is. don't want to clog the list so I can just look up 'plasmoid'; I was just hoping for a quick fix for my ignorance. got what I deserved, I guess.
F.
Am Donnerstag, 24. Januar 2013, 14:04:01 schrieb Timothy Pearson:
<snip>
can someone explain in very brief terms what the use of 'plasmoids' is?
AFAIK if you remember SuperKaramba, Plasmoids are pretty much the same concept with a completely different implementation.
Any KDE4 users, please correct me if I am wrong. :-)
hm, plasmoids, well... they are just litte apps which live in the system tray, like the so called mini-applications (kicker-applets) from kde 3.x/TDE. they seem to be easier to develop than full-fledged c++ programs due to the use of QML/javascript as their base.
Werner
On Thu, 24 Jan 2013, Werner Joss wrote:
Am Donnerstag, 24. Januar 2013, 14:04:01 schrieb Timothy Pearson:
<snip>
can someone explain in very brief terms what the use of 'plasmoids' is?
AFAIK if you remember SuperKaramba, Plasmoids are pretty much the same concept with a completely different implementation.
Any KDE4 users, please correct me if I am wrong. :-)
hm, plasmoids, well... they are just litte apps which live in the system tray, like the so called mini-applications (kicker-applets) from kde 3.x/TDE. they seem to be easier to develop than full-fledged c++ programs due to the use of QML/javascript as their base.
Werner
ok, I'll have to boot up my kde4 (or reinstall it); I didn't at the time have a sense that the plasmoids were tied to a 'system-tray' (I take your word for this!) or maybe I'm confusing them with 'activities'.
thanks.
F.
On 24 Jan 2013, Felmon Davis told this:
On Thu, 24 Jan 2013, Werner Joss wrote:
hm, plasmoids, well... they are just litte apps which live in the system tray, like the so called mini-applications (kicker-applets) from kde 3.x/TDE. they seem to be easier to develop than full-fledged c++ programs due to the use of QML/javascript as their base.
Werner
ok, I'll have to boot up my kde4 (or reinstall it); I didn't at the time have a sense that the plasmoids were tied to a system-tray' (I take your word for this!) or maybe I'm confusing them with 'activities'.
That would be because they're not tied to a system tray. They can (and do) live on the desktop background, too. (Where, uh, they are normally covered by other windows...)
On Mon, 28 Jan 2013, Nix wrote:
On 24 Jan 2013, Felmon Davis told this:
On Thu, 24 Jan 2013, Werner Joss wrote:
hm, plasmoids, well... they are just litte apps which live in the system tray, like the so called mini-applications (kicker-applets) from kde 3.x/TDE. they seem to be easier to develop than full-fledged c++ programs due to the use of QML/javascript as their base.
Werner
ok, I'll have to boot up my kde4 (or reinstall it); I didn't at the time have a sense that the plasmoids were tied to a system-tray' (I take your word for this!) or maybe I'm confusing them with 'activities'.
That would be because they're not tied to a system tray. They can (and do) live on the desktop background, too. (Where, uh, they are normally covered by other windows...)
I see. well, I seldom look at my desktop so I guess this isn't for me anyway.
F.
I keep hoping that rekonq will become much more stable, or that konqueror will work with yahoo web mail, but it's been years, & that still hasn't happened. So, I'm happy to use Firefox until KDE & TDE can get a KDE web browser to work well.
Overall, I'm very happy with KDE & TDE, though.
On Thu, Jan 24, 2013 at 11:43 AM, Werner Joss werner@hoernerfranzracing.dewrote:
Am Donnerstag, 24. Januar 2013, 10:59:50 schrieb C W:
I use KDE 4 on newer hardware & TDE on older hardware, and love them both.
same here :) in fact, kde4 (> 4.9.4) has now reached a state, where even akonadified kde-pim is usable (though still sluggish and somewhat unstable). plus, it has lots of matured apps, like blogilo, digikam etc. and konqueror as a web browser ist really usable (konqueror from TDE is not). so, for modern hardware, I now recommend kde4. on older hardware, however, kde4 is a no-go, while TDE still runs fine. just use another browser (chromium, e.g.)
Werner
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 01/21/2013 03:50 AM, Gareth Waite wrote:
Thought I'd send the link around again so everyone can hit the page and keep Distrowatch's page rank up. :)
David, I see you've posted a couple newer Wheezy ISOs, 25-Jan-2013 and 30-Jan-2013. Are these different enough from the 10-Jan-2013 ISO to warrant a download?
In the last few days I've installed the 10 Jan ISO on an HP laptop and a Gateway netbook with excellent results on both. The netbook was quite sluggish with Windows XP but is almost snappy with Exe.
On 05/02/13 15:02, Dan Youngquist wrote:
On 01/21/2013 03:50 AM, Gareth Waite wrote:
Thought I'd send the link around again so everyone can hit the page and keep Distrowatch's page rank up. :)
David, I see you've posted a couple newer Wheezy ISOs, 25-Jan-2013 and 30-Jan-2013. Are these different enough from the 10-Jan-2013 ISO to warrant a download?
In the last few days I've installed the 10 Jan ISO on an HP laptop and a Gateway netbook with excellent results on both. The netbook was quite sluggish with Windows XP but is almost snappy with Exe.
Exe is getting updated fairly often now, as wheezy gets closer. Maybe every couple of weeks or sooner if new stuff is added or a bug is found. Newer images will have all updated Debian packages and TDE from Slavek's repo of the marked date.
I meant to post this but got busy recently. More updates soon.
Apart from updates to existing stuff the latest addition is gtk-youtube-viewer (YouTube with no browser, no flash) and installer/snapshot improvements. A (minimal) XFCE has replaced LXDE as alternative desktop. Some language support improvements, more to do.
Loaded a few netbooks with Exe recently, I'm not surprised Debian+TDE beats XP for performance!
No need to reinstall, just do regular dist-upgrades till it's all officially "stable"
Newer "unofficial" packages can be found at http://exegnulinux.net/apt/ That repo is actually preconfigured in /etc/apt/sources.list.d but only Debian and TDE official repos are enabled by default
David
greets!
I just installed tde-pclinux on a netbook and I am quite impressed!
for one thing, I've been having trouble getting the mic on skype to work on various installs on this netbook (Aspire ONe 725-0802). I did get it to go in two or so versions of tde after significant struggle, in some others, not yet. but it works fine in netrunner and now I discover no problem with tde-pclinux!
there are other goodies here but a couple of questions:
(a) the main one is the windows and panel don't seem to have borders. I'm using kde-classic; how can I have distinct borders?
(b) secondarily, there is a lot of software here, which is cool but I want to remove a lot of it. specifically, is there a way to remove all the games and edutainment all at once?
(c) I'm basically an apt-get person, long while since I've rpm-ed; evidently one can use apt-get which I would like to stick to using. any concerns here in the long run? should I go back to rpm?
F.
I just installed tde-pclinux on a netbook and I am quite impressed!
Thank you very much!
for one thing, I've been having trouble getting the mic on skype to work on various installs on this netbook (Aspire ONe 725-0802). I did get it to go in two or so versions of tde after significant struggle, in some others, not yet. but it works fine in netrunner and now I discover no problem with tde-pclinux!
there are other goodies here but a couple of questions:
(a) the main one is the windows and panel don't seem to have borders. I'm using kde-classic; how can I have distinct borders?
I think that the problem is just the color scheme I used to make the windows borders the same color as the grey of the windows, to give a more kde-like theme. Changing the color theme in the TDE control center should give the result you wants.
(b) secondarily, there is a lot of software here, which is cool but I want to remove a lot of it. specifically, is there a way to remove all the games and edutainment all at once?
Go in Synaptic, (the 5th icon from the right on the panel, if I know how to count...), wait forever for Synaptic to load its packages lists, click on any package in the list and type trinity. All the TDE packages starts by trinity and you can remove the ones you don't want. Right-click on a package you don't want and click on remove. For some reasons, some packages that looks like they shouldn't have dependencies on all TDE.
Also, one thing to note is that these games and edutainment packages doesn't take that much disk space. I know that that it all adds up to make something bigger, but it might be kept without loosing that much disk space, especially on a regular HDD.
(c) I'm basically an apt-get person, long while since I've rpm-ed; evidently one can use apt-get which I would like to stick to using. any concerns here in the long run? should I go back to rpm?
PCLinuxOS uses apt-get and Synaptic, with back-ends for RPMs. I personally prefer to use Synaptic, because it's a graphic tool, but if you follow the instructions given in the web page that appeared when you booted your PCLinuxOS system for the first time, it will be okay to use apt-get in text mode. If you want to look back at this file, go in the ''Trinity TDE'' folder in your ''home'' folder and in the ''First boot'' folder, you'll find the instructions. Here is what concerns using apt-get in text-mode on PCLOS: ''DO NOT USE apt-get update and apt-get upgrade from the command line. This has never been the recommended way. If you insist on using command line, the correct procedure is apt-get update and apt-get dist-upgrade. ''
F.
Have fun with my PCLinuxOS non-official TDE remaster! -Alexandre
On Sun, 13 Jan 2013, Alexandre Couture wrote:
I just installed tde-pclinux on a netbook and I am quite impressed!
Thank you very much! [...]
it's very good but I seem to be encountering some problems. first I'll respond quickly to your comments but then post separately on an issue I have which is much more important.
there are other goodies here but a couple of questions:
(a) the main one is the windows and panel don't seem to have borders. I'm using kde-classic; how can I have distinct borders?
I think that the problem is just the color scheme I used to make the windows borders the same color as the grey of the windows, to give a more kde-like theme. Changing the color theme in the TDE control center should give the result you wants.
I can't find a way to get borders but I'll try again later. the color theme trick doesn't seem to work but I may simply be missing something.
[...]
thanks for advice on synaptic and games.
Also, one thing to note is that these games and edutainment packages doesn't take that much disk space. I know that that it all adds up to make something bigger, but it might be kept without loosing that much disk space, especially on a regular HDD.
alright but I'd rather remove the stuff. I can remove the tabs on the menu when I get the time.
(c) I'm basically an apt-get person, long while since I've rpm-ed; evidently one can use apt-get which I would like to stick to using. any concerns here in the long run? should I go back to rpm?
PCLinuxOS uses apt-get and Synaptic, with back-ends for RPMs. I personally prefer to use Synaptic, because it's a graphic tool, but if you follow the instructions given in the web page that appeared when you booted your PCLinuxOS system for the first time, it will be okay to use apt-get in text mode. If you want to look back at this file, go in the ''Trinity TDE'' folder in your ''home'' folder and in the ''First boot'' folder, you'll find the instructions. Here is what concerns using apt-get in text-mode on PCLOS: ''DO NOT USE apt-get update and apt-get upgrade from the command line. This has never been the recommended way. If you insist on using command line, the correct procedure is apt-get update and apt-get dist-upgrade. ''
too late now! I did an 'apt-get upgrade'. may be connected to my problems.
Have fun with my PCLinuxOS non-official TDE remaster! -Alexandre
thank you for your labors and your advice!
I am encountering some issues so I'll see how far I can get.
F.
greetings!
I've got Alexander Couture's tde port to pclinux on an Acer Aspire One 725-0802 and am encountering a couple of issues.
when I try to change the resolution from 1024x768 to 1280x720, I get a "kcmshell signall 11" error. the resolution does change but does not survive a boot.
this netbook has several other distros all happy with this resolution.
any thoughts?
F.
I've got Alexander Couture's tde port to pclinux on an Acer Aspire One 725-0802 and am encountering a couple of issues.
when I try to change the resolution from 1024x768 to 1280x720, I get a "kcmshell signall 11" error. the resolution does change but does not survive a boot.
this netbook has several other distros all happy with this resolution.
any thoughts?
F.
Hi! On PCLinuxOS, the main place to go to change the display resolution is in the PCLOS Control Center (right beside the Synaptic icon on the taskbar). In the Hardware section, click on ''Configure video card'' I don't know exactly why, but it doesn't always work as it should when it is made at other places...
Have fun with my remaster! -Alexandre
On Sun, 13 Jan 2013, Alexandre Couture wrote:
I've got Alexander Couture's tde port to pclinux on an Acer Aspire One 725-0802 and am encountering a couple of issues.
when I try to change the resolution from 1024x768 to 1280x720, I get a "kcmshell signall 11" error. the resolution does change but does not survive a boot.
this netbook has several other distros all happy with this resolution.
any thoughts?
F.
Hi! On PCLinuxOS, the main place to go to change the display resolution is in the PCLOS Control Center (right beside the Synaptic icon on the taskbar). In the Hardware section, click on ''Configure video card'' I don't know exactly why, but it doesn't always work as it should when it is made at other places...
ah, I should have thought of that! that does do the change without error; I haven't tried to reboot.
I have some other problems to post.
F.
Have fun with my remaster! -Alexandre
On Sunday 13 of January 2013 19:25:03 Felmon Davis wrote:
greetings!
I've got Alexander Couture's tde port to pclinux on an Acer Aspire One 725-0802 and am encountering a couple of issues.
when I try to change the resolution from 1024x768 to 1280x720, I get a "kcmshell signall 11" error. the resolution does change but does not survive a boot.
this netbook has several other distros all happy with this resolution.
any thoughts?
F.
I think it might be related to error 1334, which is already fixed for the upcoming R14 and 3.5.13.2.
Slavek --
-
Alexandre Couture -
C W -
Calvin Morrison -
Dan Youngquist -
David Hare -
Felix Miata -
Felmon Davis -
Gareth Waite -
Glen Cunningham -
Greg Madden -
Julius Schwartzenberg -
Mag. Dr. Nikolaus Klepp -
Nix -
Rolf Schmidt -
Slávek Banko -
Timothy Pearson -
Werner Joss