Tim,
1. Does TDEHWLIB require pmount? Although available as a third-party package --- something similar to PPAs --- pmount is not a stock package in Slackware. Slackware 14.0 no longer supports HAL but supports udisks, udisks2, and upower.
2. If -DWITH_HAL=ON and -DWITH_TDEHWLIB=ON, does TDEHWLIB override during run-time? If yes, can TDEHWLIB be disabled at run-time, or only during compiling?
Darrell
Tim,
- Does TDEHWLIB require pmount? Although available as a third-party
package --- something similar to PPAs --- pmount is not a stock package in Slackware. Slackware 14.0 no longer supports HAL but supports udisks, udisks2, and upower.
Yes, it requires pmount. No, I am not going to support udisks and friends due to the fact that they require the use of DBUS, and every time I attempt to do anything with DBUS I come away battered and bruised. ;-) Not only that, but there is a history of radical API changes that makes it hard to justify the effort required to get them working.
- If -DWITH_HAL=ON and -DWITH_TDEHWLIB=ON, does TDEHWLIB override during
run-time? If yes, can TDEHWLIB be disabled at run-time, or only during compiling?
Darrell
All overrides are at compile time.
Tim
Yes, it requires pmount. No, I am not going to support udisks and friends due to the fact that they require the use of DBUS, and every time I attempt to do anything with DBUS I come away battered and bruised. ;-) Not only that, but there is a history of radical API changes that makes it hard to justify the effort required to get them working.
Then if a distro no longer supports HAL and does not provide pmount as a stock package then there will be no auto mounting functionality in TDE?
Darrell
Yes, it requires pmount. No, I am not going to support udisks and friends due to the fact that they require the use of DBUS, and every time I attempt to do anything with DBUS I come away battered and bruised. ;-) Not only that, but there is a history of radical API changes that makes it hard to justify the effort required to get them working.
Then if a distro no longer supports HAL and does not provide pmount as a stock package then there will be no auto mounting functionality in TDE?
Darrell
Correct. You can blame various upstream system developers for that. ;-)
As an aside, if someone else would like to add a plugin to tie into DBUS for automount and such, I would be willing to work with them on the TDE API side to make sure that the task can be accomplished. I just refuse to rely solely on projects which both use DBUS and are constantly being replaced with a newer completely incompatible version.
Tim
On 08/26/2012 04:55 PM, Timothy Pearson wrote:
Correct. You can blame various upstream system developers for that. ;-)
As an aside, if someone else would like to add a plugin to tie into DBUS for automount and such, I would be willing to work with them on the TDE API side to make sure that the task can be accomplished. I just refuse to rely solely on projects which both use DBUS and are constantly being replaced with a newer completely incompatible version.
Tim
What would it take to identify those upstream packages (a small reasonable list) that are critical to TDE function (the way you want it to function) and just bring that code over to prevent all of this incompatibility frustration. I know I feel it -- when it feels like the rug has been pulled out from underneath you -- by some whacky upstream change.
Following upstream is surely easier, but when you cannot count on them being there, that seems like a shaky foundation to build a house on...
HAL, pmount, udisk, udisk2 is a good example of a constantly moving target where key functionality of TDE is at risk.
I don't know if this even makes sense to do, but it just seems like TDE should pick the one it wants to dance with, and stick with it.
The inevitable downside of course is that there is some break at some point in the future (kernel or otherwise) that would make this solution not work, but it looks like doing it this was would allow you to recode once (whenever a major shift occurred) as opposed to recoding over-and-over for every little change in upstream personality (HAL, udisk, udisk2, pmount, ...)
Just food for thought for the smart folk.
On 08/26/2012 04:55 PM, Timothy Pearson wrote:
Correct. You can blame various upstream system developers for that. ;-)
As an aside, if someone else would like to add a plugin to tie into DBUS for automount and such, I would be willing to work with them on the TDE API side to make sure that the task can be accomplished. I just refuse to rely solely on projects which both use DBUS and are constantly being replaced with a newer completely incompatible version.
Tim
What would it take to identify those upstream packages (a small reasonable list) that are critical to TDE function (the way you want it to function) and just bring that code over to prevent all of this incompatibility frustration. I know I feel it -- when it feels like the rug has been pulled out from underneath you -- by some whacky upstream change.
Well, that is why I designed the TDE HW library to function on top of procfs. Based on historical record, the chances of procfs disappearing from the kernel are much, much smaller than the chances of a u* package radically changing or becoming deprecated.
Following upstream is surely easier, but when you cannot count on them being there, that seems like a shaky foundation to build a house on...
Precisely.
HAL, pmount, udisk, udisk2 is a good example of a constantly moving target where key functionality of TDE is at risk.
Yes, I agreem. Note however that the pmount dependency is very small; TDE only calls it as an external program, and the only thing that would break if pmount were to disappear would be mounting of disk/media devices.
As you look at the code I have written over the past year, you can see I have been attempting to abstract all of these functions into a simple, easy-to-use, standardized TDE API that new (or old) applications can use to easily gain access to information that is normally very difficult to retrieve. Another main function of this structure is to effectively separate the (complex and prone to upstream breakage) backend code from the user application code, obviating the need for full rewrites of TDE applications code when upstream backends change.
Tim
On 08/26/2012 04:55 PM, Timothy Pearson wrote:
Correct. You can blame various upstream system developers for that. ;-)
As an aside, if someone else would like to add a plugin to tie into DBUS for automount and such, I would be willing to work with them on the TDE API side to make sure that the task can be accomplished. I just refuse to rely solely on projects which both use DBUS and are constantly being replaced with a newer completely incompatible version.
Tim
What would it take to identify those upstream packages (a small reasonable list) that are critical to TDE function (the way you want it to function) and just bring that code over to prevent all of this incompatibility frustration. I know I feel it -- when it feels like the rug has been pulled out from underneath you -- by some whacky upstream change.
Well, that is why I designed the TDE HW library to function on top of procfs. Based on historical record, the chances of procfs disappearing from the kernel are much, much smaller than the chances of a u* package radically changing or becoming deprecated.
Following upstream is surely easier, but when you cannot count on them being there, that seems like a shaky foundation to build a house on...
Precisely.
HAL, pmount, udisk, udisk2 is a good example of a constantly moving target where key functionality of TDE is at risk.
Yes, I agreem. Note however that the pmount dependency is very small; TDE only calls it as an external program, and the only thing that would break if pmount were to disappear would be mounting of disk/media devices.
As you look at the code I have written over the past year, you can see I have been attempting to abstract all of these functions into a simple, easy-to-use, standardized TDE API that new (or old) applications can use to easily gain access to information that is normally very difficult to retrieve. Another main function of this structure is to effectively separate the (complex and prone to upstream breakage) backend code from the user application code, obviating the need for full rewrites of TDE applications code when upstream backends change.
Tim
Whoops, that should read "...rewrites of TDE application code when upstream backend libraries or daemons change".
Tim
As you look at the code I have written over the past year, you can see I have been attempting to abstract all of these functions into a simple, easy-to-use, standardized TDE API that new (or old) applications can use to easily gain access to information that is normally very difficult to retrieve. Another main function of this structure is to effectively separate the (complex and prone to upstream breakage) backend code from the user application code, obviating the need for full rewrites of TDE applications code when upstream backends change.
I have pmount installed on a system without HAL. Automounting is not working on that system.
In my build script I enable only WITH_HAL or WITH_TDEHWLIB:
if [ -x /usr/sbin/hald ]; then BUILD_HAL=${BUILD_HAL:-ON} BUILD_TDEHWLIB=${BUILD_TDEHWLIB:-OFF} else BUILD_HAL=${BUILD_HAL:-OFF} BUILD_TDEHWLIB=${BUILD_TDEHWLIB:-ON} fi ... -DWITH_HAL=${BUILD_HAL} \ -DWITH_TDEHWLIB=${BUILD_TDEHWLIB} \ ...
Here are the symptoms:
* In the device icon popup menu, selecting Properties no longer shows the Mounting tab in the dialog.
* Digital camera icon never appears.
* Inserting a USB flash drive into a different physical port results in using a default desktop icon label. with a HAL system, once configured, I can insert a USB drive into any port and the icon label remains consistent.
* There seems to be no support to convert existing device icon labels, requiring the user to reconfigure from scratch.
* Safely Remove does not always work.
* Inserting a DVD results in a much longer delay than with HAL enabled systems to show the dialog prompt.
* Ejecting the DVD from the popup menu does not work.
I do not experience these symptoms when building with a HAL system.
Darrell
As you look at the code I have written over the past year, you can see I have been attempting to abstract all of these functions into a simple, easy-to-use, standardized TDE API that new (or old) applications can use to easily gain access to information that is normally very difficult to retrieve. Another main function of this structure is to effectively separate the (complex and prone to upstream breakage) backend code from the user application code, obviating the need for full rewrites of TDE applications code when upstream backends change.
I have pmount installed on a system without HAL. Automounting is not working on that system.
In my build script I enable only WITH_HAL or WITH_TDEHWLIB:
if [ -x /usr/sbin/hald ]; then BUILD_HAL=${BUILD_HAL:-ON} BUILD_TDEHWLIB=${BUILD_TDEHWLIB:-OFF} else BUILD_HAL=${BUILD_HAL:-OFF} BUILD_TDEHWLIB=${BUILD_TDEHWLIB:-ON} fi ... -DWITH_HAL=${BUILD_HAL} \ -DWITH_TDEHWLIB=${BUILD_TDEHWLIB} \ ...
Here are the symptoms:
- In the device icon popup menu, selecting Properties no longer shows the
Mounting tab in the dialog.
Digital camera icon never appears.
Inserting a USB flash drive into a different physical port results in
using a default desktop icon label. with a HAL system, once configured, I can insert a USB drive into any port and the icon label remains consistent.
- There seems to be no support to convert existing device icon labels,
requiring the user to reconfigure from scratch.
Safely Remove does not always work.
Inserting a DVD results in a much longer delay than with HAL enabled
systems to show the dialog prompt.
- Ejecting the DVD from the popup menu does not work.
I do not experience these symptoms when building with a HAL system.
Darrell
I cannot understate the amount of functionality that was lost when HAL was abandoned. It will take a long time to rebuild everything to the same level of functionality that once was available through HAL.
I assume basic manual (non-automatic) mounting is working on your test system?
Tim
I cannot understate the amount of functionality that was lost when HAL was abandoned. It will take a long time to rebuild everything to the same level of functionality that once was available through HAL.
Doesn't matter what was lost. :-) TDE is DEAD without automounting. I don't envision any user tolerating that loss of functionality. "Long time" won't cut the cheese with most users --- they'll move on.
Did the OpenSuse KDE3 people resolve this problem?
I assume basic manual (non-automatic) mounting is working on your test system?
I did not try anything related to that. Why bother with convoluted circa 1999 mounting work-arounds? :-(
Darrell
I cannot understate the amount of functionality that was lost when HAL was abandoned. It will take a long time to rebuild everything to the same level of functionality that once was available through HAL.
Doesn't matter what was lost. :-) TDE is DEAD without automounting. I don't envision any user tolerating that loss of functionality. "Long time" won't cut the cheese with most users --- they'll move on.
Did the OpenSuse KDE3 people resolve this problem?
No, they build HAL just as I do for Ubuntu.
I assume basic manual (non-automatic) mounting is working on your test system?
I did not try anything related to that. Why bother with convoluted circa 1999 mounting work-arounds? :-(
Darrell
I think I was not clear enough. ;-) What I mean is if you double-click on the device icon, does TDE mount the device? If not, is an error generated?
Remember that in order to use pmount on certain distributions your user needs to be part of a certain group on the system. See http://manpages.ubuntu.com/manpages/natty/man1/pmount.1.html.
Tim
Did the OpenSuse KDE3 people resolve this problem?
No, they build HAL just as I do for Ubuntu.
Looks like they have udisks2 support:
http://lizards.opensuse.org/2012/06/02/kde3-gets-udisks2-backend/
I think I was not clear enough. ;-) What I mean is if you double-click on the device icon, does TDE mount the device? If not, is an error generated?
I'll have to test more methodically to record exact sequences of events and messages.
Remember that in order to use pmount on certain distributions your user needs to be part of a certain group on the system. See http://manpages.ubuntu.com/manpages/natty/man1/pmount.1.html.
Users are members of the plugdev group. I also tested as root with the same results.
Darrell
On Monday 27 August 2012 23:58:52 Darrell Anderson wrote:
I cannot understate the amount of functionality that was lost when HAL was abandoned. It will take a long time to rebuild everything to the same level of functionality that once was available through HAL.
Doesn't matter what was lost. :-) TDE is DEAD without automounting. I don't envision any user tolerating that loss of functionality. "Long time" won't cut the cheese with most users --- they'll move on.
Did the OpenSuse KDE3 people resolve this problem?
On Monday 27 August 2012 23:58:52 Darrell Anderson wrote:
I cannot understate the amount of functionality that was lost when HAL was abandoned. It will take a long time to rebuild everything to the same level of functionality that once was available through HAL.
Doesn't matter what was lost. :-) TDE is DEAD without automounting. I don't envision any user tolerating that loss of functionality. "Long time" won't cut the cheese with most users --- they'll move on.
Did the OpenSuse KDE3 people resolve this problem?
I think OpenSuse use my udisks2 backend.
On Monday 27 August 2012 23:58:52 Darrell Anderson wrote:
I cannot understate the amount of functionality that was lost when HAL was abandoned. It will take a long time to rebuild everything to the same level of functionality that once was available through HAL.
Doesn't matter what was lost. :-) TDE is DEAD without automounting. I don't envision any user tolerating that loss of functionality. "Long time" won't cut the cheese with most users --- they'll move on.
Did the OpenSuse KDE3 people resolve this problem?
I think OpenSuse use my udisks2 backend.
Ah, OK. Was this implemented in a manner that could be included into TDE as an alternate backend?
Thanks!
Tim
Did the OpenSuse KDE3 people resolve this problem?
I think OpenSuse use my udisks2 backend.
Ah, OK. Was this implemented in a manner that could be included into TDE as an alternate backend?
Here is the patch:
https://github.com/serghei/kde3-kdebase/commit/27cc062c6b172fd6e93addb510
One change I think is needed for TDE, in kioslave/media/kcmodule/CMakeLists.txt, the include_directories section. TDE probably needs an "if (WITH_HAL)... else" test to use the original as-is lines. That way the modules build correctly on HAL-enabled systems.
Darrell
Did the OpenSuse KDE3 people resolve this problem?
I think OpenSuse use my udisks2 backend.
Ah, OK. Was this implemented in a manner that could be included into TDE as an alternate backend?
Here is the patch:
https://github.com/serghei/kde3-kdebase/commit/27cc062c6b172fd6e93addb510
One change I think is needed for TDE, in kioslave/media/kcmodule/CMakeLists.txt, the include_directories section. TDE probably needs an "if (WITH_HAL)... else" test to use the original as-is lines. That way the modules build correctly on HAL-enabled systems.
Darrell
It looks like we can port that patch to TDE with minimal effort. Is there any way to get github to export the entire patch as a plain-text diff?
Thanks!
Tim
Did the OpenSuse KDE3 people resolve this problem?
I think OpenSuse use my udisks2 backend.
Ah, OK. Was this implemented in a manner that could be included into TDE as an alternate backend?
Here is the patch:
https://github.com/serghei/kde3-kdebase/commit/27cc062c6b172fd6e93addb510
One change I think is needed for TDE, in kioslave/media/kcmodule/CMakeLists.txt, the include_directories section. TDE probably needs an "if (WITH_HAL)... else" test to use the original as-is lines. That way the modules build correctly on HAL-enabled systems.
Darrell
It looks like we can port that patch to TDE with minimal effort. Is there any way to get github to export the entire patch as a plain-text diff?
Thanks!
Tim
I should mention that this new backend complements TDEHWLib, but does not replace it. ;-) TDEHWLib provides much more than the (crude) automount support, which appears to have recently failed.
Tim
On Tuesday 28 August 2012 00:29:10 Timothy Pearson wrote:
On Monday 27 August 2012 23:58:52 Darrell Anderson wrote:
I cannot understate the amount of functionality that was lost when HAL was abandoned. It will take a long time to rebuild everything to the same level of functionality that once was available through HAL.
Doesn't matter what was lost. :-) TDE is DEAD without automounting. I don't envision any user tolerating that loss of functionality. "Long time" won't cut the cheese with most users --- they'll move on.
Did the OpenSuse KDE3 people resolve this problem?
I think OpenSuse use my udisks2 backend.
Ah, OK. Was this implemented in a manner that could be included into TDE as an alternate backend?
Of course, can be activated on compile time or in runtime. There is the initial commit: https://github.com/serghei/kde3-kdebase/commit/27cc062c6b172fd6e93addb510269...
Anyway, it still need some improvements (i.e. better integration with polkit, support for cameras, etc). My polkit agent is almost ready, but it will need Qt3 patched to support glib mainloop (which was developed few years ago by Norbert Frese).
http://web.archive.org/web/20070524141039/http://www.scheinwelt.at/~norbertf...
At this moment I run my KDE3 on top of patched Qt, without any problem.
Thanks!
Tim
On Tuesday 28 August 2012 00:29:10 Timothy Pearson wrote:
On Monday 27 August 2012 23:58:52 Darrell Anderson wrote:
I cannot understate the amount of functionality that was lost when HAL was abandoned. It will take a long time to rebuild everything to the same level of functionality that once was
available
through HAL.
Doesn't matter what was lost. :-) TDE is DEAD without automounting. I don't envision any user tolerating that loss of functionality. "Long time" won't cut the cheese with most users --- they'll move on.
Did the OpenSuse KDE3 people resolve this problem?
I think OpenSuse use my udisks2 backend.
Ah, OK. Was this implemented in a manner that could be included into TDE as an alternate backend?
Of course, can be activated on compile time or in runtime. There is the initial commit: https://github.com/serghei/kde3-kdebase/commit/27cc062c6b172fd6e93addb510269...
Anyway, it still need some improvements (i.e. better integration with polkit, support for cameras, etc). My polkit agent is almost ready, but it will need Qt3 patched to support glib mainloop (which was developed few years ago by Norbert Frese).
http://web.archive.org/web/20070524141039/http://www.scheinwelt.at/~norbertf...
At this moment I run my KDE3 on top of patched Qt, without any problem.
Can you send in a patch for consideration? If it looks sane we may very well include it in our next Qt release (3.5.0).
Thanks!
Tim
Qt3 patched to support glib mainloop (which was developed few years ago by Norbert Frese).
http://web.archive.org/web/20070524141039/http://www.scheinwelt.at/~norbe rtf/common_main_loop/
At this moment I run my KDE3 on top of patched Qt, without any problem.
Can you send in a patch for consideration? If it looks sane we may very well include it in our next Qt release (3.5.0).
Thanks!
Tim
Attached.
Here is a first attempt to log the symptoms of tdehwlib. The tdebase build options:
-DWITH_HAL=OFF -DWITH_TDEHWLIB=ON
The first section explains the correct/proper behavior in a system with HAL:
-DWITH_HAL=ON -DWITH_TDEHWLIB=OFF
======================================== Digital camera ========================================
With HAL:
Powering on the camera while connected to a USB port shows a desktop icon almost immediately. A dialog appears asking me what to do. The lsusb command lists the device. When disconnecting or powering off, the icon disappears almost immediately.
With TDEHWLIB:
Powering on the camera while connected to a USB port does not show a desktop icon. No dialog appears asking me what to do. The lsusb command lists the device.
======================================== Inserting a DVD ========================================
With HAL:
After about 7 seconds an icon appears on the desktop. A dialog appears asking me what to do. The dialog (correctly) does not include an option to "Download Photos with Digikam." Using the desktop popup menu, selecting Properties shows the Mounting tab in the dialog. Using the desktop popup menu, the device mounts in /media. Using the desktop popup menu, the device unmounts. Using the desktop popup menu, the device ejects.
With TDEHWLIB:
Nothing happens. No desktop icon, no dialog.
======================================== Floppy drive ========================================
With HAL:
When configured in Configure Desktop -> Behavior -> Device icons, an icon appears on the desktop for unmounted floppy. Using the desktop popup menu, selecting Properties shows the Mounting tab in the dialog. Using the desktop popup menu, the device mounts in /media/floppy, as configured. Using the desktop popup menu, the device unmounts.
With TDEHWLIB:
When configured in Configure Desktop -> Behavior -> Device icons, an icon appears on the desktop for unmounted floppy. Using the desktop popup menu, selecting Properties does not show the Mounting tab in the dialog. Using the desktop popup menu, the device mounts in /media/fd0, not as configured. A dialog (incorrectly) appears asking me what to do. The dialog (incorrectly) includes an option to "Download Photos with Digikam." Using the desktop popup menu, the device unmounts. A dialog (incorrectly) appears asking me what to do. The following appears in the xsession log:
[tdeinit] Got EXEC_NEW 'kio_media' from launcher. [tdeinit] Got EXEC_NEW 'kio_media' from launcher. [FIXME] UNCLASSIFIED DEVICE name: fat_cache type: (null) subsystem: slab driver: (null) [Node Path: (null)] [Syspath: /sys/kernel/slab/fat_cache] [(null):(null)] [FIXME] UNCLASSIFIED DEVICE name: fat type: (null) subsystem: module driver: (null) [Node Path: (null)] [Syspath: /sys/module/fat] [(null):(null)] [FIXME] UNCLASSIFIED DEVICE name: fat_inode_cache type: (null) subsystem: slab driver: (null) [Node Path: (null)] [Syspath: /sys/kernel/slab/fat_inode_cache] [(null):(null)] [FIXME] UNCLASSIFIED DEVICE name: vfat type: (null) subsystem: module driver: (null) [Node Path: (null)] [Syspath: /sys/module/vfat] [(null):(null)] [FIXME] UNCLASSIFIED DEVICE name: nls_cp437 type: (null) subsystem: module driver: (null) [Node Path: (null)] [Syspath: /sys/module/nls_cp437] [(null):(null)] [tdeinit] PID 12290 terminated. [FIXME] UNCLASSIFIED DEVICE name: nls_iso8859_1 type: (null) subsystem: module driver: (null) [Node Path: (null)] [Syspath: /sys/module/nls_iso8859_1] [(null):(null)] [tdeinit] Got EXEC_NEW 'kio_system' from launcher. [tdeinit] Got EXEC_NEW 'kio_media' from launcher.
======================================== USB flash drives ========================================
With HAL:
After about 5 seconds an icon appears on the desktop. The device automounts, per my configuration. The lsscsi command lists the device. The lsusb command lists the device. The device icon label remains the same regardless of which physical port the device is connected. Using the desktop popup menu, selecting Properties shows the Mounting tab in the dialog. The device mounts in /media. Using the desktop popup menu, the device unmounts. Using the desktop popup menu, selecting Safely Remove and the icon disappears.
With TDEHWLIB:
After about 30 seconds an icon appears on the desktop. The device does not automount, per my configuration. The lsscsi command lists the device. The lsusb command lists the device. The device icon label does not remains the same regardless of which physical port the device is connected. Using the desktop popup menu, selecting Properties does not show the Mounting tab in the dialog. Using the desktop popup menu, the device mounts to /media/sdf1 and not to the directory name I configured. Using the desktop popup menu, the device unmounts. Using the desktop popup menu, selecting Safely Remove, the icon sometimes disappears and sometimes does not.
======================================== Summary ========================================
As first step I suspect fixing the missing dialog Mounting tab will help. I'm guessing because the tab and dialog are missing, tdehwlib is ignoring everything the user has configured about a device. The global mount options in KControl->Peripherals->Storage Media does appear to be functional, but without the dialog Mounting tab for each device, each device can't be configured or verified.
Darrell
======================================== Digital camera ========================================
With HAL:
Powering on the camera while connected to a USB port shows a desktop icon almost immediately. A dialog appears asking me what to do. The lsusb command lists the device. When disconnecting or powering off, the icon disappears almost immediately.
With TDEHWLIB:
Powering on the camera while connected to a USB port does not show a desktop icon. No dialog appears asking me what to do. The lsusb command lists the device.
With a HAL-enabled system, connecting my camera results in a desktop icon labeled "USB Imaging Interface." The icon label "USB Imaging Interface" comes directly from the HAL sources, hald/linux/device.c. Makes sense then when HAL is not installed then no such icon label appears.
I don't know what interface names are used in tdehwlib to create related camera icon labels. Possibly those snippets could be taken from the HAL sources to create familiar desktop icon labels.
Possibly some additional debug messages are needed in tdehwlib to help troubleshoot these bugs.
Darrell
======================================== Digital camera ========================================
With HAL:
Powering on the camera while connected to a USB port shows a desktop icon almost immediately. A dialog appears asking me what to do. The lsusb command lists the device. When disconnecting or powering off, the icon disappears almost immediately.
With TDEHWLIB:
Powering on the camera while connected to a USB port does not show a desktop icon. No dialog appears asking me what to do. The lsusb command lists the device.
With a HAL-enabled system, connecting my camera results in a desktop icon labeled "USB Imaging Interface." The icon label "USB Imaging Interface" comes directly from the HAL sources, hald/linux/device.c. Makes sense then when HAL is not installed then no such icon label appears.
I don't know what interface names are used in tdehwlib to create related camera icon labels. Possibly those snippets could be taken from the HAL sources to create familiar desktop icon labels.
Possibly some additional debug messages are needed in tdehwlib to help troubleshoot these bugs.
Darrell
It looks like the apparent lack of functionality is caused by two main things: 1.) The TDEHW backend does not yet have per-device mount configuration support written for it. Now that I am aware of the missing functionality I will see what I can do to add it in.
2.) Some of the other problems, such as unmounting not always working, may be bugs in udev and/or the kernel, as I remember fighting with similar bugs when I was developing the TDEHW library. What kernel and udev versions are you running?
Tim
It looks like the apparent lack of functionality is caused by two main things: 1.) The TDEHW backend does not yet have per-device mount configuration support written for it. Now that I am aware of the missing functionality I will see what I can do to add it in.
I ask that first we add Serghei's udisks2 code. Even if incomplete most/all systems today no longer supporting HAL have udisks/udisks2 installed. TDEHW might be the best long-term option, but having udisks support seems sensible. Perhaps in the short term we focus on udisks support and focus on TDEHW for the long-term.
2.) Some of the other problems, such as unmounting not always working, may be bugs in udev and/or the kernel, as I remember fighting with similar bugs when I was developing the TDEHW library. What kernel and udev versions are you running?
Slackware 14 RC3:
kernel 3.2.28 udev 182 udisks 1.0.4 udisks2 1.98.0 upower 0.9.17
I have not tested removable devices with other desktop environments to determine whether the problem is solely TDE. I suspect probably so because there are many people testing Slackware 14 and no such reports have surfaced.
I successfully patched HAL, rebuilt tdebase, and retested on Slackware 14 RC3. The TDE results remained intermittent. I suspect there is a conflict between HAL and udisks. I did not try removing udisks and I won't pursue that. Tampering that deep with the upstream packages ends hope of support and ends hope of user motivation to use TDE.
My 2 cents: I expect no more than one more release candidate before Slackware 14 goes live. Slackware is not the first distro to offer a HAL-less system. Actually, the opposite generally is true. That is, Slackware usually is one of the last to adopt major changes like that. Thus, if Slackware no longer supports HAL and is supporting udisks, then the transition is pretty much complete in the Linux based world. In other words, TDE needs to support HAL-less systems. Users are not going to wait or care. :-)
Darrell
<snip>
My 2 cents: I expect no more than one more release candidate before Slackware 14 goes live. Slackware is not the first distro to offer a HAL-less system. Actually, the opposite generally is true. That is, Slackware usually is one of the last to adopt major changes like that. Thus, if Slackware no longer supports HAL and is supporting udisks, then the transition is pretty much complete in the Linux based world. In other words, TDE needs to support HAL-less systems. Users are not going to wait or care. :-)
Darrell
To put things bluntly, unless we attract new developers TDE will become a niche product very quickly. The bugtracker is evidence of that; I can't keep up with the workload (not for free anyway) and neither can anyone else around here from what I can see. Things keep changing for the sake of change and all anyone can do in the Linux desktop world nowadays is keep reinventing the wheel, wasting time and effort on a less functional, uglier, more simplified rewrites of programs we already had years earlier.
We have lost one good developer (Serghei) already due to additional splintering of the KDE3-continuation projects. I don't know if the momentum exists to keep the traditional desktop alive at this time, or if it will simply need to be re-invented many years from now after it has completely died out.
This is not a pleasant thought. I don't know what happens to a society when productive tools to execute complex, creative tasks are made unavailable to most individuals, and I really don't want to find out.
Tim
To put things bluntly, unless we attract new developers TDE will become a niche product very quickly. The bugtracker is evidence of that; I can't keep up with the workload (not for free anyway) and neither can anyone else around here from what I can see. Things keep changing for the sake of change and all anyone can do in the Linux desktop world nowadays is keep reinventing the wheel, wasting time and effort on a less functional, uglier, more simplified rewrites of programs we already had years earlier.
We have lost one good developer (Serghei) already due to additional splintering of the KDE3-continuation projects. I don't know if the momentum exists to keep the traditional desktop alive at this time, or if it will simply need to be re-invented many years from now after it has completely died out.
This is not a pleasant thought. I don't know what happens to a society when productive tools to execute complex, creative tasks are made unavailable to most individuals, and I really don't want to find out.
Nor do I. This is not a fun topic, but one that has been brewing a while. :-(
We need to face reality.
Of late I have grown cynical about free/libre software. As noted, too many changes for the sake of change. A significant idea behind Trinity is we offer a desktop environment that does not change for the sake of change and supports traditional desktop computer workflows. While we have not changed, the underlying support structure has changed. As we have seen the past few months, the changes have raised havoc with our ability to keep pace.
We're not alone. Browsing the web indicates many people are frustrated by these changes.
Regardless, these underlying changes have created a buggy Trinity. I am using Trinity GIT, but the paper cuts, regressions, and build issues are hurting. The cumulative effect is frustrating.
From my perspective we already are a niche project. Progress is slow. As noted, we lack developers. The bug tracker grows. Usability and buildability deteriorates.
I suspect the OpenSuse KDE3 folks are drowning too. Browsing the web indicates the OpenSuse KDE3 project is just as much a niche project as TDE.
Can we join forces? Together we might remain a niche desktop, but with a combined effort we could see meaningful progress.
I suspect the KDE3 and Trinity camps could work together --- but the proverbial olive branch is to strip the TQ interface from Trinity. Basically, that interface layer is why certain developers left Trinity. I appreciate that if we want to use Qt4 tools we must avoid symbol collisions. A fundamental question is whether using Qt4 tools is sufficient reason to keep the two camps separated. If that layer was removed and we merged forces, will we all collectively be better off? Or is going our separate ways, which is to eventual project deaths, the preferred option?
I don't know how much backporting or patching the OpenSuse people are doing with KDE3. My experience using both KDE3 and TDE concurrently is TDE provides some nice additional features that KDE3 lacks. Despite the growing bug tracker size, TDE offers some good bug fixes lacking in KDE3. That is, using Trinity sources without the TQ layer probably would sound inviting to the KDE3 developers.
My gut says that without additional developers or a combined effort that both KDE3 and TDE are, for all intents and purposes, dead.
I don't have answers but I am looking at options. I am preparing myself for changes. I could continue using an older Slackware release to avoid the problems of HAL-less support. Possibly in several months Trinity has excellent HAL-less support, but will anyone other than niche users care? One way or another, any related decision means I stop supporting Trinity in Slackware and only offer my build scripts and support myself.
Or I use a different desktop such as Enlightenment, LXDE, or even KDE4 as my basic HAL-less foundation and then use certain Trinity apps on top of that foundation. Yes, even KDE4, despite the evil triplets and the ugly Oxygen.
Or I use a completely different desktop environment, learn a new set of apps, and move on.
I'm looking at my workflows and am facing tough decisions. I suspect I'm not alone. All options, including a buggy Trinity or a poorly redesigned KDE4, are not fun options. These options all include some pain to one degree or another. Returning to the propriety world of operating systems is not an option for me. Therefore as free/libre developers continue shooting themselves in the foot, my choices reduce to what causes me the least pain and not what causes me no pain.
The idea of the OpenSuse KDE3 people and TDE people working together is more palatable to me than other options. If eliminating the TQ interface layer is the means to motivate both camps to join forces then I vote to strip that layer. Without joining forces I see no future for either desktop and will reconcile myself to making some tough decisions.
Someone once wrote that people should accept what can't be changed, seek courage to change what can be changed, and seek wisdom to know the difference. We can't change the underlying changes taking place in free/libre software. Those changes mean swimming in the rapids for a long while to find less turbulent water, or swimming ashore and getting out of the water. In the end, there is no shame if we decide to close shop. We lasted much longer than anybody expected or hoped. There is no shame in standing for a cause and one day ending the cause. Standing for a cause requires courage. Or we decide that a very slow moving niche project is acceptable. One way or another, something has to give. We need to deal with the reality that we lack people and can't keep pace.
Darrell
I suspect the KDE3 and Trinity camps could work together --- but the proverbial olive branch is to strip the TQ interface from Trinity.
From a technical perspective this would be a MAJOR, if not FATAL, step backward. Once this is done we would relegate ourselves permanently to the back waters of desktop environments, solely because we will NEVER be able to be fully compatible with (or use internally) Qt4, Qt5, or any future Qt products. Keep in mind that Qt4+ -based programs make up a large chunk of the halfway-decent new applications being generated for Linux, and that lack of proper integration between Qt4/TDE would likely prevent anyone from even trying TDE, let alone using it on a daily basis.
If anything I would propose the opposite, that the KDE:KDE3 developers adopt the minor object renaming that is required to fix the Qt4 compatibility problem and come work with us. While the original tqtinterface was difficult to use and undocumented, the new TQt layer is nearly transparent and the oly visible change is the use of TQ* objects instead of Q* objects. I routinely convert TQt3 code to Qt3 code using nothing but find+replace ("TQ"-->"Q" and "ntq"-->"q"), so the changes are not drastic.
Just my $0.02 from the technical perspective. If it were not for TQt3 providing some assurance of long-term future compatibility with the latest+greates Linux applications, I would have stopped work on TDE long ago.
Tim
On Wednesday 29 August 2012 04:28:54 Timothy Pearson wrote:
I suspect the KDE3 and Trinity camps could work together --- but the proverbial olive branch is to strip the TQ interface from Trinity.
From a technical perspective this would be a MAJOR, if not FATAL, step backward. Once this is done we would relegate ourselves permanently to the back waters of desktop environments, solely because we will NEVER be able to be fully compatible with (or use internally) Qt4, Qt5, or any future Qt products. Keep in mind that Qt4+ -based programs make up a large chunk of the halfway-decent new applications being generated for Linux, and that lack of proper integration between Qt4/TDE would likely prevent anyone from even trying TDE, let alone using it on a daily basis.
I don't understand this obsession for Qt4+ and KDE4. KDE4 is every time a step behind GNOME. For this reason I preffer to patch a little the Qt3 to support glib mainloop and then I will develop various applications based on excellent libraries provided by GNOME community. Moreover, glib integration is not broke Qt3 API, so I don't need to patch any of older KDE3 apps.
If anything I would propose the opposite, that the KDE:KDE3 developers adopt the minor object renaming that is required to fix the Qt4 compatibility problem and come work with us. While the original tqtinterface was difficult to use and undocumented, the new TQt layer is nearly transparent and the oly visible change is the use of TQ* objects instead of Q* objects. I routinely convert TQt3 code to Qt3 code using nothing but find+replace ("TQ"-->"Q" and "ntq"-->"q"), so the changes are not drastic.
Minor hack or no, it is ugly. Replacing strings automatically introduces a risk to make unwanted changes (which sometimes are translated in strange and hard to hunt bugs).
In any case, KDE3 will not dissapear so soon, my business is running on top of KDE3, so i'm forced to maintain it :)
On 29 August 2012 05:08, Serghei Amelian serghei@thel.ro wrote:
On Wednesday 29 August 2012 04:28:54 Timothy Pearson wrote:
I suspect the KDE3 and Trinity camps could work together --- but the proverbial olive branch is to strip the TQ interface from Trinity.
From a technical perspective this would be a MAJOR, if not FATAL, step backward. Once this is done we would relegate ourselves permanently to the back waters of desktop environments, solely because we will NEVER be able to be fully compatible with (or use internally) Qt4, Qt5, or any future Qt products. Keep in mind that Qt4+ -based programs make up a large chunk of the halfway-decent new applications being generated for Linux, and that lack of proper integration between Qt4/TDE would likely prevent anyone from even trying TDE, let alone using it on a daily basis.
I don't understand this obsession for Qt4+ and KDE4. KDE4 is every time a step behind GNOME. For this reason I preffer to patch a little the Qt3 to support glib mainloop and then I will develop various applications based on excellent libraries provided by GNOME community. Moreover, glib integration is not broke Qt3 API, so I don't need to patch any of older KDE3 apps.
If anything I would propose the opposite, that the KDE:KDE3 developers adopt the minor object renaming that is required to fix the Qt4 compatibility problem and come work with us. While the original tqtinterface was difficult to use and undocumented, the new TQt layer is nearly transparent and the oly visible change is the use of TQ* objects instead of Q* objects. I routinely convert TQt3 code to Qt3 code using nothing but find+replace ("TQ"-->"Q" and "ntq"-->"q"), so the changes are not drastic.
Minor hack or no, it is ugly. Replacing strings automatically introduces a risk to make unwanted changes (which sometimes are translated in strange and hard to hunt bugs).
In any case, KDE3 will not dissapear so soon, my business is running on top of KDE3, so i'm forced to maintain it :)
-- Serghei
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
A couple of thoughts here,
1. Bugs. Yes there are still bugs in this software, I do not think there is any "drowning" going on. Yes with the hard work of Darrell, Slavek and David we have seen many any many of these small to medium bugs be resolved. Meanwhile Tim has taken on serious bugs. Users are reporting problems, but for every user that reports problems there is anothre user that is not having any problems.
2. HAL.... Darrell you said you think people are leaving trinity because of HAL? Users do not give a flying fark about HAL or what it is. I suspect few of them understand or even have knowledge of it's existance. What is imperative is that no matter what backend is used, the functionality is the same and the transistion is seamless.
I say push a SRU, a bug fix release. That will help spark interest, and help users get the updates they need.
Calvin
On 08/29/2012 08:07 AM, Calvin Morrison wrote:
I say push a SRU, a bug fix release. That will help spark interest, and help users get the updates they need.
Calvin
+1 - Thus my interest in testing how doable something like that was. Answer - on Arch -- it's done. With a few additional papercut fixes, TDE 3.5.13-sru (3.5.13.1) is ready for official release.
This is the type of "smaller bite at the apple" I was talking about.
On 29 August 2012 09:19, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 08/29/2012 08:07 AM, Calvin Morrison wrote:
I say push a SRU, a bug fix release. That will help spark interest, and help users get the updates they need.
Calvin
+1 - Thus my interest in testing how doable something like that was. Answer - on Arch -- it's done. With a few additional papercut fixes, TDE 3.5.13-sru (3.5.13.1) is ready for official release.
This is the type of "smaller bite at the apple" I was talking about.
-- David C. Rankin, J.D.,P.E.
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
Not to mention at this point in time, Trinity 3.5.13 has many many problems. Many users who go to our home page see 3.5.13, and then have issues immediately, give up and never look back.
So lets make 3.5.13 SRU a release asap!
I say push a SRU, a bug fix release. That will help spark interest, and help users get the updates they need.
Calvin
+1 - Thus my interest in testing how doable something like that was. Answer
- on Arch -- it's done. With a few additional papercut fixes, TDE
3.5.13-sru (3.5.13.1) is ready for official release.
This is the type of "smaller bite at the apple" I was talking about.
Please make it an official release!
Nik
- HAL.... Darrell you said you think people are leaving
trinity because of HAL? Users do not give a flying fark about HAL or what it is. I suspect few of them understand or even have knowledge of it's existance. What is imperative is that no matter what backend is used, the functionality is the same and the transistion is seamless.
I did not write or imply any such comment. I wrote that I don't envision anybody using Trinity when automounting is broken, which is now the case on any HAL-less system.
Darrell
I don't understand this obsession for Qt4+ and KDE4. KDE4 is every time a step behind GNOME. For this reason I preffer to patch a little the Qt3 to support glib mainloop and then I will develop various applications based on excellent libraries provided by GNOME community. Moreover, glib integration is not broke Qt3 API, so I don't need to patch any of older KDE3 apps.
This is a matter of opinion. ;-) I used to program GTK applications, and in my opinion they are very hard to code and maintain past a certain size and complexity level. Qt3/4/5 applications on the other hand seem more scalable, and those libraries provide many useful features in their respective APIs which were lacking when I last tried the GTK libraries.
Minor hack or no, it is ugly. Replacing strings automatically introduces a risk to make unwanted changes (which sometimes are translated in strange and hard to hunt bugs).
At this point most, of not all, of those bugs have been found and stamped out. There is no real reason not to use TQt3, with its better compatibility and continued development, except for personal preference. :-)
Tim
On 29 August 2012 10:13, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
I don't understand this obsession for Qt4+ and KDE4. KDE4 is every time a step behind GNOME. For this reason I preffer to patch a little the Qt3 to support glib mainloop and then I will develop various applications based on excellent libraries provided by GNOME community. Moreover, glib integration is not broke Qt3 API, so I don't need to patch any of older KDE3 apps.
This is a matter of opinion. ;-) I used to program GTK applications, and in my opinion they are very hard to code and maintain past a certain size and complexity level. Qt3/4/5 applications on the other hand seem more scalable, and those libraries provide many useful features in their respective APIs which were lacking when I last tried the GTK libraries.
Minor hack or no, it is ugly. Replacing strings automatically introduces a risk to make unwanted changes (which sometimes are translated in strange and hard to hunt bugs).
At this point most, of not all, of those bugs have been found and stamped out. There is no real reason not to use TQt3, with its better compatibility and continued development, except for personal preference. :-)
Tim
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
A nice technical document about TQt3, and other developments would be really helpful on the website. I would also like to see our Trinity HCI model on the website.
A nice technical document about TQt3, and other developments would be really helpful on the website. I would also like to see our Trinity HCI model on the website.
http://www.trinitydesktop.org/wiki/bin/view/Developers/UnderstandingTheTQTIn...
Darrell
Darrell,
I recently pushed patches that should restore the majority of the mount backend functionality when compiled with TDEHWLib instead of HAL. These patches affect tdelibs, tdebase, and tdegraphics, so you will need to recompile all three from the latest GIT before trying out the patches.
Please let me know which areas are still regressed compared to HAL after this patchset has been applied.
Thanks!
Tim
I recently pushed patches that should restore the majority of the mount backend functionality when compiled with TDEHWLib instead of HAL. These patches affect tdelibs, tdebase, and tdegraphics, so you will need to recompile all three from the latest GIT before trying out the patches.
Please let me know which areas are still regressed compared to HAL after this patchset has been applied.
I'll rebuild but I can build those specific packages only at night. I'll need a day or two to test and report.
The irritating regression right now is the empty dialogs I'm seeing. :-(
Darrell
I recently pushed patches that should restore the majority of the mount backend functionality when compiled with TDEHWLib instead of HAL. These patches affect tdelibs, tdebase, and tdegraphics, so you will need to recompile all three from the latest GIT before trying out the patches.
Please let me know which areas are still regressed compared to HAL after this patchset has been applied.
Here are my latest test results:
======================================== Digital camera
Powering on the camera while connected to a USB port shows a desktop icon almost immediately. When disconnecting or powering off the camera, the icon disappears almost immediately. I have Trinity configured to autostart digikam when the camera is detected and with TDEHW digikam now starts automatically.
As far as I can tell, camera support now works as expected.
======================================== Inserting a DVD
Nothing happens. No desktop icon, no dialog.
======================================== Floppy drive
When configured in Configure Desktop -> Behavior -> Device icons, an icon appears on the desktop for unmounted floppy. Using the desktop popup menu, the device mounts in /media/fd0, although configured in mediamanagerrc as /media/floppy. The device does unmount when using the popup menu.
======================================== USB flash drives
After about 30 seconds an icon appears on the desktop. This is much longer than with HAL. The device does not automount, per my configuration. The device icon label changes when I use a different physical port. Using the desktop popup menu, the device mounts to /media/sdf1 and not the mount point I configured. Using the desktop popup menu, the device unmounts. Using the desktop popup menu, selecting Safely Remove, the icon does not disappear.
======================================== Summary
Needing attention:
* Using the desktop popup menu, selecting Properties does not show the Mounting tab in the dialog for any of the removable devices.
* TDEHW does not honor the mount points used in mediamanagerrc.
* For USB flash drives, the device icon label changes when the physical port is different. The icon label is not the same as when connected under HAL.
Proposal:
Here is a snippet from my mediamanagerrc:
[UserLabels] /org/freedesktop/Hal/devices/platform_floppy_0_storage=Floppy /org/freedesktop/Hal/devices/volume_uuid_3D46_02C4=Cruzer 16GB USB /org/freedesktop/Hal/devices/volume_uuid_4840_B9DA=Buffalo 1GB USB /org/freedesktop/Hal/devices/volume_uuid_4CAB_C505=Kingston 8GB USB /org/freedesktop/Hal/devices/volume_uuid_4CAF_CC9B=Cruzer 8GB USB /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-2/1-2:1.0/host7/target7:0:0/7:0:0:0/block/sdf/sdf1//dev/sdf1=Cruzer 16GB USB /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-5/1-5:1.0/host8/target8:0:0/8:0:0:0/block/sdf/sdf1//dev/sdf1=Cruzer 16GB USB
Notice that under HAL, after using the GUI to rename the icon label, the volume_uuid_3D46_02C4 icon label is "Cruzer 16GB USB." I can insert the device to any physical port and the icon label remains the same because the label is related to the device UUID.
Under TDEHW the default icon label for that device is CRUZER because TDEHW is not using UUID. After I use the GUI to change the icon label to "Cruzer 16GB USB," the first "sdf1" entry above is created. When I insert the device into a different USB port, the default name once again is CRUZER. Once again I use the GUI to change the icon label to "Cruzer 16GB USB," but a another entry is created in mediamanagerrc. This behavior will irritate users. :-)
To be seamless ("just works") TDEHW should use the existing mediamanagerrc information. How TDEHW detects devices need not match the group key labels in mediamanagerrc. Users will not enjoy needing to rename the icon labels. They will not enjoy needing to rename the label again when they use a different physical port.
I recommend using the same identity scheme used under HAL by using the device UUID and using the same key labels and values. That would resolve both the icon label and mount point problems.
Darrell
======================================== Inserting a DVD
Nothing happens. No desktop icon, no dialog.
I'll look into it.
======================================== Floppy drive
When configured in Configure Desktop -> Behavior -> Device icons, an icon appears on the desktop for unmounted floppy. Using the desktop popup menu, the device mounts in /media/fd0, although configured in mediamanagerrc as /media/floppy. The device does unmount when using the popup menu.
I don't have a floppy drive readily available at the moment to debug with; you may want to file a bug report on this (relatively minor) issue so that it isn't forgotten in the future.
======================================== USB flash drives
After about 30 seconds an icon appears on the desktop. This is much longer than with HAL. The device does not automount, per my configuration. The device icon label changes when I use a different physical port. Using the desktop popup menu, the device mounts to /media/sdf1 and not the mount point I configured. Using the desktop popup menu, the device unmounts. Using the desktop popup menu, selecting Safely Remove, the icon does not disappear.
That does not sound right at all. TDEHWLib should not be using the device path as the icon label, and the other issues sound like they may be a udev or kernel problem. Can you try with a blank mediamanagerrc and see if any of those issues go away?
Also of some use would be if you could do the following: 1.) Go into kcontrol->Peripherals->Hardware Devices 2.) Open the Disks tree 3.) The USB flash device you are trying to mount should show up in that subtree; double-click on it 4.) Send me one screenshots of each tab in the hardware information dialog that pops up
The referenced kcontrol module offers a graphical view into how the TDE hardware library views your system, and as such is quite useful for debugging. If something shows up as wrong in that module, it's a pretty good bet that the device in question will not work properly elsewhere in the TDE system.
======================================== Summary
Needing attention:
- Using the desktop popup menu, selecting Properties does not show the
Mounting tab in the dialog for any of the removable devices.
TDEHW does not honor the mount points used in mediamanagerrc.
For USB flash drives, the device icon label changes when the physical
port is different. The icon label is not the same as when connected under HAL.
<snip>
It is not feasible to recreate the UDI strings originally generated by HAL, as HAL's internal structure is quite different than the TDE HW backend. HAL uses many internal hacks/strings, which contributed significantly to its unmaintainability and subsequent deprecation; I do not want to repeat that mistake.
The loss of old media manager settings will exist with any replacement media backend unless great pains are taken to generate UDI strings exactly the way HAL did; this issue is not unique to the TDEHWLib backend.
Tim
======================================== Inserting a DVD
Nothing happens. No desktop icon, no dialog.
I'll look into it.
Two new commits just went into GIT, in tdelibs and tdebase. This should resolve most of the CD/DVD handling problem and might resolve your floppy drive problem as well.
If you can, please check to see if unmounting a CD or DVD causes an unwanted media insertion popup dialog to appear. This happens on my test system because udev fires a media removed event followed by a media inserted event, and TDE dutifully shows the popup on media insert. This should probably be fixed upstream in udev, as I don't know if TDE would be able to reliably distinguish between this spurious event and the user reinserting the same disk.
Tim
======================================== Inserting a DVD
Nothing happens. No desktop icon, no dialog.
I'll look into it.
Two new commits just went into GIT, in tdelibs and tdebase. This should resolve most of the CD/DVD handling problem and might resolve your floppy drive problem as well.
If you can, please check to see if unmounting a CD or DVD causes an unwanted media insertion popup dialog to appear. This happens on my test system because udev fires a media removed event followed by a media inserted event, and TDE dutifully shows the popup on media insert. This should probably be fixed upstream in udev, as I don't know if TDE would be able to reliably distinguish between this spurious event and the user reinserting the same disk.
Tim
Please disregard the last part regarding udev and spurious events; I inserted a line of incorrect code accidentally and drew an incorrect conclusion.
There is a second patch now in tdebase GIT that should fix the popup issue with CDs/DVDs.
Tim
======================================== Floppy drive
When configured in Configure Desktop -> Behavior -> Device icons, an icon appears on the desktop for unmounted floppy. I can mount the device with the popup menu. Using the desktop popup menu, the device mounts in /media/fd0, although configured in mediamanagerrc as /media/floppy.
Note: Under HAL the default configuration is to poll the device every two seconds. I long ago disabled that option because the clicking sound is irritating, especially for a device that is used seldom. TDEHW does not seem to poll floppy drives.
======================================== Inserting a DVD
After about 30 seconds an icon appears on the desktop. A much longer waiting period than with HAL. A dialog appears asking me what action to take. I can mount the device with the popup menu through the dialog or through the device popup menu. I cannot perform an Eject through the popup menu. I have to use the drive eject button. Running 'eject -T dvd" from konsole does not work either but did under HAL.
======================================== USB flash drives
After about 30 seconds an icon appears on the desktop. A much longer waiting period than with HAL. I have my USB flash drives configured to automount. Under TDEHW they do not automount. The device icon label changes when I use a different physical port. Using the desktop popup menu, the device mounts to /media/sdf1 and not the mount point I configured. Using the desktop popup menu, the device unmounts. Safely Remove does not work.
======================================== Compact flash cards
I removed the compact flash card from my camera and inserted into my card reader. An icon appeared. Like the USB drives, Safely Remove does not work. Oddly, the icon is a USB flash drive rather than a sd_mm icon.
========================================
======================================== Summary
Overall, device recognition seems to be working for all devices. So that is good progress. Most issues are after recognition.
* Device recognition/response is much, much slower than under HAL. I wait a long time for icons to appear. I suspect many users will treat that behavior as breakage.
* The Mounting tab in the Properties popup dialog is not available.
* Without the Mounting tab there is no method to configure mount options for individual devices.
* Mount points are not configurable and are not the same as used in mediamanagerrc.
* TDEHW does not honor the previous mount points used in mediamanagerrc. I use mount points that make sense to me: /media/kingston_8gb, /media/cruzer_8gb /media/cruzer_16gb, /media/buffalo_1gb, etc. Mounts points of /media/sdf1, /media/sdg1, etc. do not make sense to me because I can't easily distinguish multiple devices. Likewise with the floppy mount point. /media/floppy makes more sense to me than /media/fd0.
* TDEHW does not use the existing icon labels used in mediamanagerrc.
* For CD/DVDs, the Eject option is not working. Unmounting must be performed separately. After unmounting, the Eject option does not work. I can eject only with the drive eject button.
* For USB flash drives, the device icon label changes when the physical port is different. I suspect many users will treat that behavior as breakage.
* For USB devices the Safely Remove option does not work. Specifically, the icon does not disappear.
Darrell
======================================== Summary
Overall, device recognition seems to be working for all devices. So that is good progress. Most issues are after recognition.
- Device recognition/response is much, much slower than under HAL. I wait
a long time for icons to appear. I suspect many users will treat that behavior as breakage.
The Mounting tab in the Properties popup dialog is not available.
Without the Mounting tab there is no method to configure mount options
for individual devices.
- Mount points are not configurable and are not the same as used in
mediamanagerrc.
- TDEHW does not honor the previous mount points used in mediamanagerrc. I
use mount points that make sense to me: /media/kingston_8gb, /media/cruzer_8gb /media/cruzer_16gb, /media/buffalo_1gb, etc. Mounts points of /media/sdf1, /media/sdg1, etc. do not make sense to me because I can't easily distinguish multiple devices. Likewise with the floppy mount point. /media/floppy makes more sense to me than /media/fd0.
TDEHW does not use the existing icon labels used in mediamanagerrc.
For CD/DVDs, the Eject option is not working. Unmounting must be
performed separately. After unmounting, the Eject option does not work. I can eject only with the drive eject button.
- For USB flash drives, the device icon label changes when the physical
port is different. I suspect many users will treat that behavior as breakage.
- For USB devices the Safely Remove option does not work. Specifically,
the icon does not disappear.
Darrell
Thank you for the information. Can you please send in the screenshots I asked for earlier? Those screenhots would help me debug the label problems.
Regarding the slow detection of devices, I do not see that here, and when combined with the eject failure it sounds like udev is just plain buggy on your system. For instance, eject works fine here (eject is not a TDE program). To determine if udev really is this slow on your system, please run this in a terminal: udevadm monitor
Watch the output of that command on the terminal as you plug in a USB drive--is there immediate activity, or do you have to wait 30 seconds for that command to output that it has detected a new drive?
Please remember that there is NO good, stable replacement for HAL anywhere in the Linux ecosystem. TDE can only work with the information given to it by several upstream projects such as udev, and if those projects don't function correctly on your system you may need to revert to using HAL until they fix their bugs.
Thanks!
Tim
Thank you for the information. Can you please send in the screenshots I asked for earlier? Those screenhots would help me debug the label problems.
Which screenshots are those? I must have missed that email. If you mean pictures of each device icon, I'll post some soon.
Regarding the slow detection of devices, I do not see that here, and when combined with the eject failure it sounds like udev is just plain buggy on your system. For instance, eject works fine here (eject is not a TDE program). To determine if udev really is this slow on your system, please run this in a terminal: udevadm monitor
Ah, that partially reveals what is happening. :-) udev is detecting devices immediately but the icons do not appear for a long time.
I have been testing with my primary traveling 16 GB USB flash drive. When I tested with a 8 GB USB flash drive, the icon appeared within two seconds.
I don't know what is happening here. There is a huge volume of udev spew when I insert the 16 GB USB flash drive. The icon does not appear until the spew ends.
Similar spew happens with the 8 GB drive, but much less in volume, and the icon appears much sooner.
The 16 GB device contains thousands of files, such as music files, photos, videos, portable apps, etc. Yet the 8 GB device contains many files too (hundreds/thousands), although not as many as the 16 GB device.
The 16 GB device is a Cruzer and the 8 GB device is a Kingston.
I tried a 8 GB Cruzer and the same slow icon appearance. I tried a 1 GB Buffalo and the icon appeared quickly.
All of the flash drives have many files on them.
At this time the only commonality I notice is Cruzer manufacturing. Possibly with the newer udev package there are some rule changes causing this weird effect. I don't know. I have not tested with a different desktop environment.
I have to reboot to run the same same tests on a HAL system. I'll add to the report later.
Please remember that there is NO good, stable replacement for HAL anywhere in the Linux ecosystem. TDE can only work with the information given to it by several upstream projects such as udev, and if those projects don't function correctly on your system you may need to revert to using HAL until they fix their bugs.
Yes, I understand that. I don't know why HAL was abandoned when HAL was working well. Yet know that TDEHW is coming along nicely. Sure, bugs exist, but we're making progress. :-)
Darrell
Thank you for the information. Can you please send in the screenshots I asked for earlier? Those screenhots would help me debug the label problems.
Which screenshots are those? I must have missed that email. If you mean pictures of each device icon, I'll post some soon.
Here is the message: http://trinity-devel.pearsoncomputing.net/?0::9840
I don't like the fact that the mount options dialog is not appearing. Your other issues are probably somewhat related to the fact that you are manually modifying mediamanagerrc, therefore you do not know which strings to use for the new TDEHWLib groups (nor should you have to!). At this time I do not know why the mounting options tab appears for me and not for you.
Tim
Which screenshots are those? I must have missed that email. If you mean pictures of each device icon, I'll post some soon.
Here is the message: http://trinity-devel.pearsoncomputing.net/?0::9840
I don't like the fact that the mount options dialog is not appearing.
Oh, okay. Well, not much to show because the tab is just plain missing. Regardless, here are screen shots of the icon labels:
With HAL:
http://humanreadable.nfshost.com/trinity/build_logs/icons-all-good.png
With TDEHW:
http://humanreadable.nfshost.com/trinity/build_logs/icons-all-goofy.png
The devices are in the same desktop order for both systems.
Your other issues are probably somewhat related to the fact that you are manually modifying mediamanagerrc, therefore you do not know which strings to use for the new TDEHWLib groups (nor should you have to!). At this time I do not know why the mounting options tab appears for me and not for you.
I don't manually modify mediamanagerrc, except through the dialogs. That is, I don't edit the file.
Here is some more information:
======================================== Icon appearance times (same physical port used every time):
Slackware 13.1, with HAL:
Kingston 8GB: 7.5 seconds Buffalo 1GB: 6 seconds Cruzer 8 GB: 6 seconds Cruzer 16GB: 6 seconds Slackware Current installation DVD: 16.5 seconds Slackware 12.2 installation CD: 20.5 seconds
======================================== Slackware 14.0 RC4, with TDEHW
Kingston 8GB: 3.5 seconds (faster) Buffalo 1GB: 1.5 seconds (faster) Cruzer 8 GB: 10.5 seconds (slower) Cruzer 16GB: 24.5 seconds (much slower) Slackware Current installation DVD: 15.5 seconds (~ same) Slackware 12.2 installation CD: 13.5 seconds (faster)
I did not perform repeated tests to derive average times.
============ FRESH PROFILE ============ Slackware 14.0 RC4, TDEHW
USB icon appearance times:
Kingston 8GB: 2 seconds (faster) Buffalo 1GB: 2 seconds (faster) Cruzer 8 GB: 10.5 seconds (slower) Cruzer 16GB: 24.5 seconds (much slower) Slackware Current installation DVD: 14.5 seconds (~ same) Slackware 12.2 installation CD: 14.5 seconds (~ same)
Mounting tab: Missing, but there now is a Meta Info tab that I never have seen before.
Safely Remove: does not work
CD/DVD Eject: does not work
======================================== Seems the missing mounting tab is not profile related. Something else must be causing that.
Seems something might be amiss with the Cruzer flash drives. Based upon the spew output I'll lean toward udev at the moment. I need to test further in a different desktop environment.
Regarding the compact flash disk icon: with HAL the device icons appears using the smart_media icon. With TDEHW the icon is a USB device (as seen in previous screen shots). That bug hopefully is easy to fix. Screen shot with HAL:
http://humanreadable.nfshost.com/trinity/build_logs/compact-flash-icon.png
Darrell
Which screenshots are those? I must have missed that email. If you
mean
pictures of each device icon, I'll post some soon.
Here is the message: http://trinity-devel.pearsoncomputing.net/?0::9840
I don't like the fact that the mount options dialog is not appearing.
Oh, okay. Well, not much to show because the tab is just plain missing. Regardless, here are screen shots of the icon labels:
With HAL:
http://humanreadable.nfshost.com/trinity/build_logs/icons-all-good.png
Had you assigned those labels to the drives in the past, or did they appear that way the first time you ever plugged them in?
HAL may have been doing some additional magic behind the scenes that I was not originally aware of...
Tim
With HAL:
http://humanreadable.nfshost.com/trinity/build_logs/icons-all-good.png
Had you assigned those labels to the drives in the past, or did they appear that way the first time you ever plugged them in?
In the past. Use the icon popup menu, select Properties, select the General tab, and modify the text.
We can do this under TDEHW too, but the change is retained only on a physical port basis. Change the physical port that the device is attached and the icon label must be changed again. Considering that many systems these days have several USB ports that are easily accessible, that means several edits for the same device. TDEHW needs a way to keep the same icon label regardless of which physical port is used.
The UUID scheme would be one way to retain that information. :-)
Darrell
With HAL:
http://humanreadable.nfshost.com/trinity/build_logs/icons-all-good.png
Had you assigned those labels to the drives in the past, or did they appear that way the first time you ever plugged them in?
In the past. Use the icon popup menu, select Properties, select the General tab, and modify the text.
We can do this under TDEHW too, but the change is retained only on a physical port basis. Change the physical port that the device is attached and the icon label must be changed again. Considering that many systems these days have several USB ports that are easily accessible, that means several edits for the same device. TDEHW needs a way to keep the same icon label regardless of which physical port is used.
The UUID scheme would be one way to retain that information. :-)
The UUID information is used by TDEHWLib for this exact reason. This all sounds like something wasn't built using the latest GIT HEAD.
Can you use a fresh )blank) mediamanagerrc file, assign a name to your USB drive, then post the resultant mediamanagerrc file to the list? That would help me determine exactly what is going wrong.
Thanks!
Tim
The UUID information is used by TDEHWLib for this exact reason. This all sounds like something wasn't built using the latest GIT HEAD.
Built with GIT sources from Friday. I just now did a git pull on both tdebase and tdelibs and I have the latest TDEHW patches.
Can you use a fresh )blank) mediamanagerrc file, assign a name to your USB drive, then post the resultant mediamanagerrc file to the list? That would help me determine exactly what is going wrong.
With a fresh new profile, before editing the icon labels through the popup menu, the mediamanagerrc file does not exist.
Here is a mediamanagerrc file after manually editing the icon label from the popup menu:
[UserLabels] /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-2/1-2:1.0/host18/target18:0:0/18:0:0:0/block/sdg/sdg1//dev/sdg1=Buffalo 1GB USB /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-2/1-2:1.0/host20/target20:0:0/20:0:0:0/block/sdg/sdg1//dev/sdg1=Cruzer 8 GB USB /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-5/1-5:1.0/host17/target17:0:0/17:0:0:0/block/sdf/sdf1//dev/sdf1=Cruzer 8GB USB /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-5/1-5:1.0/host19/target19:0:0/19:0:0:0/block/sdf/sdf1//dev/sdf1=Buffalo 1GB USB
As you can see, the icon label is being retained on a physical port basis and not UUID.
Unlike the current mediamanagerrc with HAL, there is no mount information for any devices in mediamanagerrc. I know of no way to add that information or the format of those strings.
Darrell
The UUID information is used by TDEHWLib for this exact reason. This all sounds like something wasn't built using the latest GIT HEAD.
Built with GIT sources from Friday. I just now did a git pull on both tdebase and tdelibs and I have the latest TDEHW patches.
Can you use a fresh )blank) mediamanagerrc file, assign a name to your USB drive, then post the resultant mediamanagerrc file to the list? That would help me determine exactly what is going wrong.
With a fresh new profile, before editing the icon labels through the popup menu, the mediamanagerrc file does not exist.
Here is a mediamanagerrc file after manually editing the icon label from the popup menu:
[UserLabels] /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-2/1-2:1.0/host18/target18:0:0/18:0:0:0/block/sdg/sdg1//dev/sdg1=Buffalo 1GB USB /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-2/1-2:1.0/host20/target20:0:0/20:0:0:0/block/sdg/sdg1//dev/sdg1=Cruzer 8 GB USB /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-5/1-5:1.0/host17/target17:0:0/17:0:0:0/block/sdf/sdf1//dev/sdf1=Cruzer 8GB USB /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-5/1-5:1.0/host19/target19:0:0/19:0:0:0/block/sdf/sdf1//dev/sdf1=Buffalo 1GB USB
As you can see, the icon label is being retained on a physical port basis and not UUID.
OK, I see the problem in the code. I'll see what I can do about it.
Unlike the current mediamanagerrc with HAL, there is no mount information for any devices in mediamanagerrc. I know of no way to add that information or the format of those strings.
You shouldn't need to know that information. I don't understand why the mount options tab is not showing up in the Properties dialog of the removable device on your system.
Tim
Unlike the current mediamanagerrc with HAL, there is no mount information for any devices in mediamanagerrc. I know of no way to add that information or the format of those strings.
You shouldn't need to know that information. I don't understand why the mount options tab is not showing up in the Properties dialog of the removable device on your system.
All users need to know the information --- how else can they change the desired mount options? Granted, solve the missing dialog and then we see what happens next. I'm sure something is different between Slackware and Ubuntu that neither of us see at the moment because we don't use the other system. :-)
Where is the code for displaying the Mounting tab? Perhaps if I browse I might find some clues related to my setup.
Darrell
Where is the code for displaying the Mounting tab? Perhaps if I browse I might find some clues related to my setup.
I found the code and I think I see the problem.
In tdebase/kioslave/media/CMakeLists.txt:
tde_conditional_add_subdirectory( WITH_HAL propsdlgplugin )
When I build with WITH_TDEHWLIB=ON, I set WITH_HAL=OFF because HAL is not installed. If I recall correctly, you have said that you are compiling with your own HAL package, which means you build WITH_HAL=ON. That is why you see the dialog tab and I don't.
The question is how to properly patch the CMakeLists.txt file? Are those dialogs truly conditional on HAL? If not then perhaps all we need is this change:
AS IS:
tde_conditional_add_subdirectory( WITH_HAL propsdlgplugin )
CHANGE TO:
add_subdirectory( propsdlgplugin )
Darrell
Where is the code for displaying the Mounting tab? Perhaps if I browse I might find some clues related to my setup.
I found the code and I think I see the problem.
In tdebase/kioslave/media/CMakeLists.txt:
tde_conditional_add_subdirectory( WITH_HAL propsdlgplugin )
When I build with WITH_TDEHWLIB=ON, I set WITH_HAL=OFF because HAL is not installed. If I recall correctly, you have said that you are compiling with your own HAL package, which means you build WITH_HAL=ON. That is why you see the dialog tab and I don't.
The question is how to properly patch the CMakeLists.txt file? Are those dialogs truly conditional on HAL? If not then perhaps all we need is this change:
AS IS:
tde_conditional_add_subdirectory( WITH_HAL propsdlgplugin )
CHANGE TO:
add_subdirectory( propsdlgplugin )
Darrell
Yep, that's it! Go ahead and commit that to GIT.
Good work!
Tim
The question is how to properly patch the CMakeLists.txt file? Are those dialogs truly conditional on HAL? If not then perhaps all we need is this change:
AS IS:
tde_conditional_add_subdirectory( WITH_HAL
propsdlgplugin )
CHANGE TO:
add_subdirectory( propsdlgplugin )
Yep, that's it! Go ahead and commit that to GIT.
Good work!
I just finished testing the patch (before reading your response). The patch works. I now have a Mounting tab. :-)
Darrell
Two new commits just went into GIT, in tdelibs and tdebase. This should resolve most of the CD/DVD handling problem and might resolve your floppy drive problem as well.
The only problem I had with the floppy device is the mount point is not the same as I have configured in mediamanagerrc. Under HAL, using the popup menu options Properties->Mounting (tab) dialog, I long ago set the mount point to /media/floppy. Without the Mounting tab, there is no GUI method of changing that. From what I see, under TDEHWLIB, there is no way to configure the mount point, which defaults to /media/fd0, or any, other mount option, to override the global options.
For example, in my global mount options I do not have any device automount. I change that for my USB flash drives. Of course, floppies can't be configured that way. That is why I have an Unmounted Floppy device icon on my desktop. Through that icon I can use the popup menu to mount the floppy. Note: under HAL I have floppy polling disabled because the clicking noise slowly drives a person insane. :-)
If you can, please check to see if unmounting a CD or DVD causes an unwanted media insertion popup dialog to appear. This happens on my test system because udev fires a media removed event followed by a media inserted event, and TDE dutifully shows the popup on media insert. This should probably be fixed upstream in udev, as I don't know if TDE would be able to reliably distinguish between this spurious event and the user reinserting the same disk.
As I mentioned previously, I can run these particular builds only at night (only one computer, different OSes, different partitions, etc., requiring a reboot when I'm done for the day with my main setup). Thus, I won't be able to test until sometime tomorrow. :-)
I did not see mentioned with the latest patches whether the Mounting tab is restored in the device icon popup Properties dialog. The Mounting tab provides GUI access to specifying the desired mount point and other related mount options for a device, which override the global options.
I believe we need migration code to convert the existing mediamanagerrc data to the format used by TDEHWLIB. I don't envision users cheerfully accepting that they have to rename all of the removable device icon labels, mount points, etc., especially if no GUI access is provided. End-users will treat the HAL->TDEHWLIB change as a WTF moment. :-)
Seems using UUID is a reasonable method to generate the icon label. The mediamanagerrc file contains references to HAL terminology, but within those key names/values is the UUID of each device. The UUID is always discoverable and some code could be added to grep mediamanagerrc for that UUID. When found, use kreadconfig to grab the respective key values and under the new TDEHWLIB key/value scheme, that becomes the icon label, mount point, etc. All of the information is there, we just need to convert to the new TDEHWLIB key names and values. That the old HAL key names/values remain in mediamanagerrc is no big deal or concern and nobody but you, me, and maybe three other people will notice. Users are not going to notice (or care) that new packages are built with TDEHWLIB rather than HAL, but they will notice breakage with icon labels, mount points, etc. :-)
Darrell
It is not feasible to recreate the UDI strings originally generated by HAL, as HAL's internal structure is quite different than the TDE HW backend. HAL uses many internal hacks/strings, which contributed significantly to its unmaintainability and subsequent deprecation; I do not want to repeat that mistake.
Sure, I understand. Let me explain differently. I am not suggesting we recreate the UDI strings from the old mediamanagerrc, which are based upon how HAL works. I'm suggesting we grep those strings to create the new TDEHW strings by extracting the UUID related information.
TDE probably can already extract the UUID when I device is connected. TDEHW should use that code. We then grep the old mediamanagerrc for that UUID and extract the related information. For example, suppose I insert my Kingston 8GB flash drive. For that one device my existing mediamnagerrc looks like this:
...
[/org/freedesktop/Hal/devices/volume_uuid_4CAB_C505] atime=false flush=true mountpoint=/media/kingston_8gb quiet=false ro=false shortname=lower sync=false uid=true utf8=true
...
[UserLabels] /org/freedesktop/Hal/devices/volume_uuid_4CAB_C505=Kingston 8GB USB
...
When I insert that device, TDE/TDEHW discovers the UUID, and then TDEHW greps mediamanagerrc for that UUID. Then TDEHW, either through kreadconfig or its own code, extracts the information. Rather than a [UserLabels] string that looks like this:
[UserLabels] /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-2/1-2:1.0/host7/target7:0:0/7:0:0:0/block/sdf/sdf1//dev/sdf1=Cruzer 16GB USB
Which changes when I insert the device into a different physical port, we create a strings like this:
...
[volume_uuid_4CAB_C505] atime=false flush=true mountpoint=/media/kingston_8gb quiet=false ro=false shortname=lower sync=false uid=true utf8=true
...
[UserLabels] volume_uuid_4CAB_C505=Kingston 8GB USB
...
If whoever developed the code for mediamanagerrc under HAL had used this direct string approach, we would not need to create new strings under TDEHW. :-) My point is that the UUID is discoverable and dependable and can be used to create the new mediamanagerrc strings.
Perhaps the first time TDE is started under TDEHW, TDEHW automatically updates mediamanagerrc rather than wait for those devices to be inserted.
The loss of old media manager settings will exist with any replacement media backend unless great pains are taken to generate UDI strings exactly the way HAL did; this issue is not unique to the TDEHWLib backend.
Yes, I understand that mediamanagerrc will be a tad cluttered until we get this all debugged. :-)
Darrell
On Wednesday 29 August 2012 17:13:27 Timothy Pearson wrote:
I don't understand this obsession for Qt4+ and KDE4. KDE4 is every time a step behind GNOME. For this reason I preffer to patch a little the Qt3 to support glib mainloop and then I will develop various applications based on excellent libraries provided by GNOME community. Moreover, glib integration is not broke Qt3 API, so I don't need to patch any of older KDE3 apps.
This is a matter of opinion. ;-) I used to program GTK applications, and in my opinion they are very hard to code and maintain past a certain size and complexity level.
I say about glib libraries, not about gtk ones. For example, kopete can be a simple shell for libpurple, knetworkmanager can be a shell around libnm-glib, the same thing I did for kpolkit-agent and so on. Even KDE4's polkit-qt-1 is a simple bridge between Qt4 and libpolkit-1.
Moreover, KDE4 libraries tend to be very tight linked to KDE4 core libraries, while the GNOME libraries often depends only to glib (which is used anyway by KDE3/TDE, for example in aRts and other modules).
Qt3/4/5 applications on the other hand seem more scalable, and those libraries provide many useful features in their respective APIs which were lacking when I last tried the GTK libraries.
Minor hack or no, it is ugly. Replacing strings automatically introduces a risk to make unwanted changes (which sometimes are translated in strange and hard to hunt bugs).
At this point most, of not all, of those bugs have been found and stamped out. There is no real reason not to use TQt3, with its better compatibility and continued development, except for personal preference.
Well, I think that original Qt3's API is powerful enough, it needs just some underground tweaks (like glib eventloop support).
On Wednesday 29 August 2012 17:13:27 Timothy Pearson wrote:
I don't understand this obsession for Qt4+ and KDE4. KDE4 is every
time a
step behind GNOME. For this reason I preffer to patch a little the Qt3 to support glib mainloop and then I will develop various applications based on excellent libraries provided by GNOME community. Moreover, glib integration is
not
broke Qt3 API, so I don't need to patch any of older KDE3 apps.
This is a matter of opinion. ;-) I used to program GTK applications, and in my opinion they are very hard to code and maintain past a certain size and complexity level.
I say about glib libraries, not about gtk ones. For example, kopete can be a simple shell for libpurple, knetworkmanager can be a shell around libnm-glib, the same thing I did for kpolkit-agent and so on. Even KDE4's polkit-qt-1 is a simple bridge between Qt4 and libpolkit-1.
So you are suggesting that we use glib backend (non-GUI) libraries to power TDE native frontends. This is an interesting idea that merits some additional research.
Moreover, KDE4 libraries tend to be very tight linked to KDE4 core libraries, while the GNOME libraries often depends only to glib (which is used anyway by KDE3/TDE, for example in aRts and other modules).
Of course, this is why I have not used any Qt4/KDE4 libraries in the TDE core, however it would be nice to be able to provide a plugin or two that leverage portions of KDE4 that are more powerful than the TDE equivalent (KHTML/Webkit for instance).
Qt3/4/5 applications on the other hand seem more scalable, and those libraries provide many useful features in their respective APIs which were lacking when I last tried the GTK libraries.
Minor hack or no, it is ugly. Replacing strings automatically
introduces
a risk to make unwanted changes (which sometimes are translated in strange and hard to hunt bugs).
At this point most, of not all, of those bugs have been found and stamped out. There is no real reason not to use TQt3, with its better compatibility and continued development, except for personal preference.
Well, I think that original Qt3's API is powerful enough, it needs just some underground tweaks (like glib eventloop support).
OK, here is a single example of how TQt3 is more powerful than Qt3 in the context of cross-toolkit drawing operations:
If I want to draw a widget element on an X11 pixmap in Qt3, I have to create a full widget object, configure it, "show" it, then bitblt its contents to the desired pixmap. With TQt3 I can simply command the style subsystem to paint the desired element(s) directly to the desired pixmap.
As an aside, the aforementioned Qt3 sequence of painting events is the root cause of most of the GTK style engine performance and stability problems that KDE and TDE users have experienced over time. Sometimes API changes actually introduce new functionality; you should take a look at the latest Qt3/TQt3 versions in our GIT tree before saying Qt3.3.8 is sufficient for everything. ;-)
Tim
On Wednesday 29 August 2012 18:09:12 Timothy Pearson wrote:
[...]
Sometimes API changes actually introduce new functionality; you should take a look at the latest Qt3/TQt3 versions in our GIT tree before saying Qt3.3.8 is sufficient for everything. ;-)
Tim
I didn't say that there is no room for improvements :) I'm just against aggressive changes in API. KDE3/TDE is an ecosystem and changes in core API destroys it (as KDE4 did).
On 08/28/2012 07:01 PM, Darrell Anderson wrote:
I suspect the KDE3 and Trinity camps could work together --- but the proverbial olive branch is to strip the TQ interface from Trinity. Basically, that interface layer is why certain developers left Trinity. I appreciate that if we want to use Qt4 tools we must avoid symbol collisions. A fundamental question is whether using Qt4 tools is sufficient reason to keep the two camps separated. If that layer was removed and we merged forces, will we all collectively be better off? Or is going our separate ways, which is to eventual project deaths, the preferred option?
The benefit in joining forces with Ilya's effort at openSuSE, is that not only do they have a lot of talent with current tde experience (Serghei, Robert, Ilya, etc...), but they also have a couple of the original KDE3 developers serving in advisory capacity (Stephenson, primarily...). The value in that type of experience cannot be understated in helping quickly narrow down issues, but also in providing direction for solutions to those problems that work kde/tde wide without integration problems.
Simply trying to keep up with the insane core compiler and library changes in the past 4 months have been a nightmare, starting with HAL, libpng, gcc, ffmpeg, and the list goes on ... None that difficult to handle in isolation, but combined, and combined with the attempt to advance R14 at the same time, it is simply overwhelming.
Smaller bites at the apple are called for during times of rapid change. There is nothing wrong with stabilizing R14 and releasing it HAL based while tdehwlib incubates a bit longer. The HAL replacement will take a great deal of work and a great deal of time to implement. HAL does so many different and varied things that TDE relies on, that expecting to simply replace it in a couple months time will lead to nothing but more frustration.
Since SuSE is in the same boat, it just makes sense to work together to craft a replacement that works for KDE/TDE. Those are the only two project that will care about the end product of the effort, but both will have equal stake in it being a reliable and robust replacement for HAL.
Whether it is called tdehwlib or HAL2 doesn't matter. The fact of the matter is both need a HAL2.
So the options are to either join forces and jointly develop a replacement, or each separately attempt to invent a replacement. The latter will take a great deal longer and simply interject additional incompatibility in two different versions of kde3.
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Mag. Dr. Nikolaus Klepp -
Serghei Amelian -
Timothy Pearson