the proyect wash too much time in unusefully thinks like "Greater stability, more features" (mayor of thems are much like windows gui desktop like), "Monitor and Display gui settings" (that linux real user modifiy at xorg settings in console), "ew widget theme askteroid" (???, theres a lot of v3 themes in kde-app.org), "Enhanced Quick Launch Kicker applet" (all kicker enhanched are windows like enhanches), .... and a-lot-of stuff that are only usefully in ubunwindo like desktops ..
I think the first thing you should do was to begin *ONLY* with the migration to cmake, make a stimated finish, and once the main parts was migrated, start repairing most important faults .. the result will be more focused to expected..
this that i prevously said, permit to know more for non-manpower users know about kde parts and colaborate better with project.. but now project need man powers to port hal, bluetooht and a lot of fixeds! that the reality!
On Mon, May 7, 2012 at 12:10 PM, Darrell Anderson humanreadable@yahoo.comwrote:
Given the reasons it's now an orphan, I don't think
it's wise for us to assume its maintenance (IIRC, Tim has already said
he doesn't want
to, anyway). Best to move on.
Yep, I agree totally. The big question is my mind is (1) time & (2) manpower constraints to implement its removal from tde. Every kde3 project that wants to move forward must be addressing this issue. While it might seem unmanageable for TDE to do it alone, or SuSE to do it alone, or whoever to do it alone, if we could somehow coordinate TDE, SuSE and whoever else (need to ID these) so that a common framework is chosen and the parts of the transition broken down into block 1, 2, 3, .... so that TDE does 1, suse does 2, and so on -- it starts to look a whole lot more doable.
Why not have a central halfreetkde3-wiki or something similar that could host removal standards and server as a patch repository/hub....
Instead of having 10 different projects separately trying to do the same thing 10 different ways, it is far better to have 10 different projects contribute to doing 1 thing the same way....
We have little choice to "move on," but I want to see the existing HAL support remain intact and loosely maintained. At least for the next few releases and until the new detection mechanism is fully developed and mature, which will take a release or two to mature. I believe we can support both with build configuration options.
Keeping HAL support allows users to install Trinity on older hardware with older operating systems. We should remember that many people run older releases of operating systems for many years and do not play the relentless updating game.
Regarding collaboration, like most things in life, that either happens or doesn't. The people supporting KDE3 rather than Trinity have their reasons. We should respect those decisions and they should respect ours. At one time there was fallout because some people did not want the TQt layer. The only way we keep the doors open to those people to help with collaboration is to prove the layer does not cause problems or bugs. We should be honest with ourselves and admit that the transition to TQt did introduce bugs. I believe those growing pains are now behind us. When we demonstrate that no such related bugs exist then that might convince others to return. Until then we learn to be content with what we are doing and let others be content with what they are doing. :-)
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting