26 Aug
2012
26 Aug
'12
8:49 p.m.
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
26 Aug
26 Aug
9:35 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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.
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.
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
All overrides are at compile time.
Tim
9:52 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
9:55 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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 
27 Aug
27 Aug
5:58 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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.
--
David C. Rankin, J.D.,P.E.
7:08 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On 08/26/2012 04:55 PM, Timothy Pearson wrote:
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.
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...
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
7:11 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On 08/26/2012
04:55 PM, Timothy Pearson wrote:
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.
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...
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
8:35 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
8:40 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
8:58 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
9:06 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
9:13 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
Did the
OpenSuse KDE3 people resolve this problem?
No, they build HAL just as I do for Ubuntu. 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
9:23 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On Monday 27 August 2012 23:58:52 Darrell Anderson wrote:
--
Serghei
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?
9:23 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On Monday 27 August 2012 23:58:52 Darrell Anderson wrote:
I think OpenSuse use my udisks2 backend.
--
Serghei
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?
9:29 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On Monday 27 August 2012 23:58:52 Darrell Anderson
wrote:
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
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?
9:34 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
Did the OpenSuse KDE3 people resolve this problem?
I think OpenSuse use my udisks2 backend.
9:38 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
Did the
OpenSuse KDE3 people resolve this problem?
I think OpenSuse use my udisks2 backend.
9:40 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
> 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?
9:45 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On Tuesday 28 August 2012 00:29:10 Timothy Pearson wrote:
Of course, can be activated on compile time or in runtime. There is the
initial commit:
https://github.com/serghei/kde3-kdebase/commit/27cc062c6b172fd6e93addb51026…
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/~norbert…
At this moment I run my KDE3 on top of patched Qt, without any problem.
On Monday 27
August 2012 23:58:52 Darrell Anderson wrote:
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? 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? Thanks!
Tim
--
Serghei
9:48 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On Tuesday 28 August 2012 00:29:10 Timothy Pearson
wrote:
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/27cc062c6b172fd6e93addb51026…
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/~norbert…
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
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.
9:52 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
28 Aug
28 Aug
12:56 a.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
3:57 a.m.
New subject: [trinity-devel] Tim: TDEHWLIB
========================================
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
3:24 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
========================================
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
7:04 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
9:15 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
<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
29 Aug
29 Aug
12:01 a.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
1:28 a.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
9:08 a.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On Wednesday 29 August 2012 04:28:54 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.
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.
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
1:07 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On 29 August 2012 05:08, Serghei Amelian <serghei(a)thel.ro> wrote:
On Wednesday 29 August 2012 04:28:54 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.
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
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.
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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)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
1:19 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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.
1:25 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On 29 August 2012 09:19, David C. Rankin <drankinatty(a)suddenlinkmail.com> wrote:
On 08/29/2012 08:07 AM, Calvin Morrison wrote:
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.
--
David C. Rankin, J.D.,P.E.
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)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
4:56 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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.
6:37 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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 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
2:13 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
2:17 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On 29 August 2012 10:13, Timothy Pearson <kb9vqf(a)pearsoncomputing.net> wrote:
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.
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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)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
6:40 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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/UnderstandingTheTQTI…
Darrell
7:39 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
7:48 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
30 Aug
30 Aug
6:17 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
8:46 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
========================================
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
11:30 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
========================================
Inserting a DVD
Nothing happens. No desktop icon, no dialog.
I'll look into it.
11:51 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
========================================
Inserting a DVD
Nothing happens. No desktop icon, no dialog.
I'll look into it.
1 Sep
1 Sep
7:14 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
========================================
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
8:01 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
========================================
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
9:09 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
10:09 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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.
11:19 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
11:47 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
2 Sep
2 Sep
12:42 a.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
12:57 a.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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. :-)
1:20 a.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
1:35 a.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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.
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
3:03 a.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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.
3:24 a.m.
New subject: [trinity-devel] TDEHWLIB: Missing Mounting dialog
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
3:53 a.m.
New subject: [trinity-devel] TDEHWLIB: Missing Mounting dialog
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
5:28 a.m.
New subject: [trinity-devel] TDEHWLIB: Missing Mounting dialog
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
31 Aug
31 Aug
3:16 a.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
1 Sep
1 Sep
8:25 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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
29 Aug
29 Aug
2:53 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On Wednesday 29 August 2012 17:13:27 Timothy Pearson wrote:
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).
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.
Well, I think that original Qt3's API is powerful enough, it needs just some
underground tweaks (like glib eventloop support).
--
Serghei
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.
3:09 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
On Wednesday 29 August 2012 17:13:27 Timothy Pearson
wrote:
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.
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. 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.
Well, I think that original Qt3's API is powerful enough, it needs just
some
underground tweaks (like glib eventloop support). 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.
3:32 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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).
--
Serghei
1:14 p.m.
New subject: [trinity-devel] Tim: TDEHWLIB
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.
--
David C. Rankin, J.D.,P.E.
4494
days inactive
4501
days old
66 comments
6 participants
participants (6)
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Mag. Dr. Nikolaus Klepp -
Serghei Amelian -
Timothy Pearson