High guys. This may have been spelled out somewhere, but if so I missed it, so please bear with me.
I've been a KDE user since 1.x which was part of SuSE v5.3. Up till KDE4, I was always found KDE to do what I needed.
I have some questions about the future direction of KDE3:
1. Qt4 port - I saw that this is one the roadmap. Is this really neccessary? I know that a lot of my complaints about KDE4 was the useless revamp of the interface, but having to have both Qt3/4 libs was also a huge pain. I'm not against a port if there are compelling reasons for it, but I have seen no compelling reason for KDE4. It uses more memory and space.
I have a lot of older laptops that I find KDE3 to be snappy and KDE4 to be like molassas.
2. What about the other KDE projects like KOffice? I've always made use of KOffice instead of anything else. I find OpenOffice to be bloated.
3. Removal of HAL in favor of udev - Is this something that is going to affect KDE3?
4. Dependencies - I'm not sure how it is on other distros, but I've always found SuSE/openSUSE to suffer from unneccessary dependencies. Not everyone has a Palmpilot device, and most PIMs assume you do and force you to install support for something you don't have. I'm not sure how the core KDE and the other projects handle this. How is Trinity planning to do it?
5. XOrg and KDE3 - on openSUSE 11.3, I can't setup my displays because openSUSE removed it's config program SaX2 and I can't get XOrg to work with my displays. Works fine in openSUSE 11.0/KDE3 because I have SaX2. Is there an alternative for configuring displays?
Sorry if some of this is a repeat. I'm new to the list, but a longtime KDE user.
Thanx
High guys. This may have been spelled out somewhere, but if so I missed it, so please bear with me.
I've been a KDE user since 1.x which was part of SuSE v5.3. Up till KDE4, I was always found KDE to do what I needed.
I have some questions about the future direction of KDE3:
- Qt4 port - I saw that this is one the roadmap. Is this really
neccessary? I know that a lot of my complaints about KDE4 was the useless revamp of the interface, but having to have both Qt3/4 libs was also a huge pain. I'm not against a port if there are compelling reasons for it, but I have seen no compelling reason for KDE4. It uses more memory and space.
Well, KDE4 performance is not indicative of Qt4 performance; rather, it shows the level of bloat that KDE e.V. introduced with their rewrite/reboot of the KDE series. Qt4 should in theory be faster compared to Qt3 when it is executing equivalent code, primarily due to the improved graphics support.
I am currently looking at the possibility of absorbing most of Qt3 into the Trinity project, and only using the core portions of Qt4 for the abstracted access to low-level system interfaces. The Trinity project needs to add support for multitouch, true window transparency etc. to both stay relevant on newer hardware and to improve performance of existing components where possible. A good example of this is the Amarok OSD; since it uses fake transparency it both presents a very dated/bad appearance to the user and eats CPU cycles unnecessarily. Graphics devices from 15 years ago have had hardware shader capability, and if the Qt4 base components will allow such tasks to be offloaded to the GPU instead of slowing down the CPU, I would consider that an improvement.
The Trinity codebase will keep full Qt3 support for quite some time; Qt4 support and the enhancements that stem from it are a separate project at this time.
I have a lot of older laptops that I find KDE3 to be snappy and KDE4 to be like molassas.
- What about the other KDE projects like KOffice? I've always made
use of KOffice instead of anything else. I find OpenOffice to be bloated.
The last KDE3 version of KOffice is part of the Trinity distribution, but no active development is occurring at this time.
- Removal of HAL in favor of udev - Is this something that is going
to affect KDE3?
That's why its on the roadmap. If Trinity does not support udev soon, then compatibility issues will eventually arise with newer distributions, primarily in the areas of power management and hotplug support.
- Dependencies - I'm not sure how it is on other distros, but I've
always found SuSE/openSUSE to suffer from unneccessary dependencies. Not everyone has a Palmpilot device, and most PIMs assume you do and force you to install support for something you don't have. I'm not sure how the core KDE and the other projects handle this. How is Trinity planning to do it?
You may want to ask Robert Xu; he is in charge of the OpenSUSE/RedHat/Fedora packaging. You can find him on the trinity-devel list.
Hope this helps!
Timothy Pearson Trinity Desktop Project
On Thu, Oct 14, 2010 at 3:42 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
Well, KDE4 performance is not indicative of Qt4 performance; rather, it shows the level of bloat that KDE e.V. introduced with their rewrite/reboot of the KDE series. Qt4 should in theory be faster compared to Qt3 when it is executing equivalent code, primarily due to the improved graphics support.
How much is this going to matter for older video chipsets tho? My Thinkpad 390X has a Neomagic 256AV chipset with 2.5MB VRAM. It's not like that's going to support any fancy graphics. I'm not against it so long as I can TURN IT OFF, which is something that the KDE4 devs can't seem to understand.
http://www.thinkwiki.org/wiki/Neomagic_MagicMedia256AV
I am currently looking at the possibility of absorbing most of Qt3 into the Trinity project, and only using the core portions of Qt4 for the abstracted access to low-level system interfaces. The Trinity project needs to add support for multitouch, true window transparency etc. to both stay relevant on newer hardware and to improve performance of existing components where possible. A good example of this is the Amarok OSD; since it uses fake transparency it both presents a very dated/bad appearance to the user and eats CPU cycles unnecessarily. Graphics devices from 15 years ago have had hardware shader capability, and if the Qt4 base components will allow such tasks to be offloaded to the GPU instead of slowing down the CPU, I would consider that an improvement.
Which chipsets? The ATI Mobility M3(Rage128 Based)? Or Radeon/GeForce and higher?
As for Amarok, I don't use it. MPlayer is my media player. A Qt port of Firefox would be great tho........
The last KDE3 version of KOffice is part of the Trinity distribution, but no active development is occurring at this time.
Not an issue so long as it's maintained IMO.
You may want to ask Robert Xu; he is in charge of the OpenSUSE/RedHat/Fedora packaging. You can find him on the trinity-devel list.
Will do. Thanx
On Thu, Oct 14, 2010 at 3:42 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
Well, KDE4 performance is not indicative of Qt4 performance; rather, it shows the level of bloat that KDE e.V. introduced with their rewrite/reboot of the KDE series. Qt4 should in theory be faster compared to Qt3 when it is executing equivalent code, primarily due to the improved graphics support.
How much is this going to matter for older video chipsets tho? My Thinkpad 390X has a Neomagic 256AV chipset with 2.5MB VRAM. It's not like that's going to support any fancy graphics. I'm not against it so long as I can TURN IT OFF, which is something that the KDE4 devs can't seem to understand.
It won't matter at all. Qt4 will fall back to software based overlay if it needs to, in which case the performance difference between the KDE3/Qt3 software overlay and the Qt4 software overlay should be minimal to nonexistent. Also, there will still be the Qt3 version available...
http://www.thinkwiki.org/wiki/Neomagic_MagicMedia256AV
I am currently looking at the possibility of absorbing most of Qt3 into the Trinity project, and only using the core portions of Qt4 for the abstracted access to low-level system interfaces. The Trinity project needs to add support for multitouch, true window transparency etc. to both stay relevant on newer hardware and to improve performance of existing components where possible. A good example of this is the Amarok OSD; since it uses fake transparency it both presents a very dated/bad appearance to the user and eats CPU cycles unnecessarily. Graphics devices from 15 years ago have had hardware shader capability, and if the Qt4 base components will allow such tasks to be offloaded to the GPU instead of slowing down the CPU, I would consider that an improvement.
Which chipsets? The ATI Mobility M3(Rage128 Based)? Or Radeon/GeForce and higher?
Not sure OTOH, but I would expect that any non-vesa-framebuffer drivers (e.g. ATI, Intel, nVidia, etc.) would permit at least partial GPU acceleration of alpha blending functions.
As for Amarok, I don't use it. MPlayer is my media player. A Qt port of Firefox would be great tho........
Try gtk-qt-engine-kde3 and kgtk-qt3-kde3; they will skin GTK apps with Qt widget and allow the use of Trinity file open/save dialogs, respectively.
The last KDE3 version of KOffice is part of the Trinity distribution, but no active development is occurring at this time.
Not an issue so long as it's maintained IMO.
You may want to ask Robert Xu; he is in charge of the OpenSUSE/RedHat/Fedora packaging. You can find him on the trinity-devel list.
Will do. Thanx
On Thu, Oct 14, 2010 at 5:25 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
Try gtk-qt-engine-kde3 and kgtk-qt3-kde3; they will skin GTK apps with Qt widget and allow the use of Trinity file open/save dialogs, respectively.
Doesn't that still have to load the GTK libs? It would be nice to drop Firefox's mem footprint some.
On the Mac side, there's a browser for MacOS 8.6-9.2.2 called Classilla that works reasonably well in 80MB RAM. It doesn't have all the Java and stuff, but I can actually use a 13 year old laptop with 144MB RAM and check my email and even log into Paypal. Now that's lean......
On Thursday 14 October 2010 20:42:39 Timothy Pearson wrote:
The Trinity project needs to add support for multitouch, true window transparency etc. to both stay relevant on newer hardware and to improve performance of existing components where possible.
Please, please, if you do that, have Trinity set to ask what you want _before_ the desktop opens for the first time. I was so pleased when Trinity started up; for many reasons, but not insignificant is the fact that in KDE 3.5.10 (and previous KDEs) I never have to be subjected to all that awful glitz - I can turn it off without ever having been subjected to it.
Lisi
On Sun, Oct 31, 2010 at 14:49, Lisi lisi.reisz@gmail.com wrote:
On Thursday 14 October 2010 20:42:39 Timothy Pearson wrote:
The Trinity project needs to add support for multitouch, true window transparency etc. to both stay relevant on newer hardware and to improve performance of existing components where possible.
Please, please, if you do that, have Trinity set to ask what you want _before_ the desktop opens for the first time. I was so pleased when Trinity started up; for many reasons, but not insignificant is the fact that in KDE 3.5.10 (and previous KDEs) I never have to be subjected to all that awful glitz - I can turn it off without ever having been subjected to it.
+1 A user should be free to make decisions.
On Thursday 14 October 2010 20:42:39 Timothy Pearson wrote:
The Trinity project needs to add support for multitouch, true window transparency etc. to both stay relevant on newer hardware and to improve performance of existing components where possible.
Please, please, if you do that, have Trinity set to ask what you want _before_ the desktop opens for the first time. I was so pleased when Trinity started up; for many reasons, but not insignificant is the fact that in KDE 3.5.10 (and previous KDEs) I never have to be subjected to all that awful glitz
- I
can turn it off without ever having been subjected to it.
Lisi
No desire to change the defaults at all. In fact, what I was mentioning were primarily backend improvements; there are places (e.g. Konsole, Amarok's OSD) where software transparency is used; I would prefer that Qt4 handle that instead of a buggy software routine in Trinity itself.
Tim
On Sun, Oct 31, 2010 at 5:58 PM, Timothy Pearson
No desire to change the defaults at all. In fact, what I was mentioning were primarily backend improvements; there are places (e.g. Konsole, Amarok's OSD) where software transparency is used; I would prefer that Qt4 handle that instead of a buggy software routine in Trinity itself.
I had repeatedly asked that KPersonalizer be ported to KDE4/Qt4 when I had hopes of it actually being useful. Having used KDE since 1.x in S.u.S.E. v5.3, I miss having that pop up on first login. Such a great way to do things.......
openSUSE didn't use it. I can't remember the last version it was used. The package was still there, but not installed by default.....
Ark Linux uses it and it was the first thing that pops up in a new install. It important NOT to over customize trinity because users always customize to their own needs, All 108 of my test volunteers always did. The biggest complaint for all distros in general was over customization. It made it had to set it up to anything usable for them. Its like having to clean up someone else's mess when moving into a new home. As far as my studies show, starting with as simple a kde setup as possible is best. We need sane defaults.
For example, konqueror should be set to treeview, the most popular setting, yet, because MS windows uses icon view (to show off how cool they are) rather than realizing its a file manager and treeview gives the user a big advantage.
I receive tons of tech magazines with research articles about the least liked features of windows, icon view is one of them.
Simple, sane defaults and minimal customization, will make trinity a better UI. KISS is a good idea here.
:) Kate
On 11/1/10, Larry Stotler larrystotler@gmail.com wrote:
On Sun, Oct 31, 2010 at 5:58 PM, Timothy Pearson
No desire to change the defaults at all. In fact, what I was mentioning were primarily backend improvements; there are places (e.g. Konsole, Amarok's OSD) where software transparency is used; I would prefer that Qt4 handle that instead of a buggy software routine in Trinity itself.
I had repeatedly asked that KPersonalizer be ported to KDE4/Qt4 when I had hopes of it actually being useful. Having used KDE since 1.x in S.u.S.E. v5.3, I miss having that pop up on first login. Such a great way to do things.......
openSUSE didn't use it. I can't remember the last version it was used. The package was still there, but not installed by default.....
On 01/11/2010 17:20, Katheryne Draven wrote:
For example, konqueror should be set to treeview, the most popular setting, yet, because MS windows uses icon view (to show off how cool they are) rather than realizing its a file manager and treeview gives the user a big advantage.
Funny to read this, I though about exactly the same while reading the beginning of this thread! +1
Nicolas.
Great minds think alike or is it crazy people? I forget.
On 1/13/11, Nicolas BERCHER nbercher@yahoo.fr wrote:
On 01/11/2010 17:20, Katheryne Draven wrote:
For example, konqueror should be set to treeview, the most popular setting, yet, because MS windows uses icon view (to show off how cool they are) rather than realizing its a file manager and treeview gives the user a big advantage.
Funny to read this, I though about exactly the same while reading the beginning of this thread! +1
Nicolas.
-
Katheryne Draven -
Larry Stotler -
Lisi -
Nicolas BERCHER -
Robert Xu -
Timothy Pearson