Tim, All,
After the discussion both here and on the suse list about the removal of HAL, that brought up a question that I don't fully understand. I know that everyone is moving away from HAL and that it is the way of the future, but "Why?"
Briefly - what is wrong with HAL? Is it dead upstream? Does is pose limitations on the ability to do X or Y going forward? If so what are X or Y? Is it udev? What?
Like Qt3, all of the past versions of KDE3 and TDE have used HAL and work fantastically - what is the motivation for dumping it?
A short sentence or two would help me understand -- or a simply link to why if you have one will do. Thanks, I just want to make sure I understand the issue better...
On Mon, 07 May 2012 07:03:13 -0500 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
Tim, All,
After the discussion both here and on the suse list about the removal of HAL, that brought up a question that I don't fully understand. I know that everyone is moving away from HAL and that it is the way of the future, but "Why?"
Briefly - what is wrong with HAL? Is it dead upstream? Does is pose limitations on the ability to do X or Y going forward? If so what are X or Y? Is it udev? What?
Like Qt3, all of the past versions of KDE3 and TDE have used HAL and work fantastically - what is the motivation for dumping it?
A short sentence or two would help me understand -- or a simply link to why if you have one will do. Thanks, I just want to make sure I understand the issue better...
It's dead upstream, jettisoned in favour of DeviceKit (upower/udisks/etc.). Apparently, the codebase was too big and complex to be maintained effectively. See:
http://lists.freedesktop.org/archives/hal/2008-May/011560.html
In addition to this, many distros have dropped it. At the time it was dropped from Gentoo, there were some small nuisance bugs due to its functionality overlapping with other hardware backends (disks and other devices showing up twice in some applications was the most common one, IIRC).
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.
On 05/07/2012 08:27 AM, E. Liddell wrote:
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....
On 05/07/2012 10:07 AM, David C. Rankin wrote:
On 05/07/2012 08:27 AM, E. Liddell wrote:
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.
I mean Tim is implementing the replacement currently with his TDE hardware library ( this is still beta ).
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....
Instead of having 10 different projects, why doesn't everyone else join Trinity? We are the largest fork of KDE3. Anyone else is getting hung up on pointless technical arguments. Those people who choose to leave for those arguments are silly because in the end they hurt themselves more. KDE3 has a following and splitting the small developer and userbase up is ridiculous.
Calvin
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
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
On 05/09/2012 09:37 AM, PICCORO McKAY Lenz wrote:
the proyect wash too much time in unusefully thinks like "Greater stability, more features"
Greater stability and more features are "un-useful things?" I find them to be exactly what I am looking for in a desktop environment.
"Monitor and Display gui settings" (that linux real user modifiy at xorg settings in console),
I don't think any sane person with a normal setup has been manually editing their Xorg.conf's in several years... any commercial desktop in the last 10 years has had a GUI display config. it's great!
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..
luckily cmake development can go along _meanwhile_ other problems are resolved. I mean look at how many bug reports and problems have been resolved since 3.5.10 alone.
I don't really see what you are getting at.
Calvin
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
E. Liddell -
PICCORO McKAY Lenz