The expected behaviour is that the utility iterates over the list/map and prints its contents (the de-marshaling aka decoding is handled via dcop/client/marshall.cpp and code for handling lists and maps is there already).
The actual output is this:
<TQMap<TQCString,DCOPRef>>
This seems like a regression, as some KDE3 era DCOP tutorials demonstrate the behaviour
e.g. here.
(My guess is that these extra angle brackets break the demarshal() function. A possible solution —I haven't looked much into the code yet— would be to strip the enclosing angle brackets before attempting to parse the type, but I'm actually curious where these brackets come from at all.)
# System info
TDE: Trinity R14.1.0 [DEVELOPMENT]
OS: Slackware64-current
# Description
When passing a function that returns a TQValueList, a QCStringList or a TQMap to the `dcop` command, like this:
```
$ dcop $(dcopfind konqueror-\*) konqueror-mainwindow#1 actions
```
The expected behaviour is that the utility iterates over the list/map and prints its contents (the de-marshaling aka decoding is handled via `dcop/client/marshall.cpp` and code for handling lists and maps is there already).
The actual output is this:
```
<TQMap<TQCString,DCOPRef>>
```
This seems like a regression, as some KDE3 era DCOP tutorials demonstrate the behaviour
e.g. [here](https://websvn.kde.org/*checkout*/trunk/www/sites/developer/documentation/tutorials/automation/index.html?revision=471709).
~~<small>(My guess is that these extra angle brackets break the `demarshal()` function. A possible solution —I haven't looked much into the code yet— would be to strip the enclosing angle brackets before attempting to parse the type, but I'm actually curious where these brackets come from at all.)</small>~~
Hi,
can you be more specific regarding example and brackets?
this document refers to KDE2
If you mean <TQMap<TQCString,DCOPRef>> I am not sure it was able to list a complex structure in the past
BR
Hi,
can you be more specific regarding example and brackets?
1. this document refers to KDE2
2. If you mean `<TQMap<TQCString,DCOPRef>>` I am not sure it was able to list a complex structure in the past
BR
Hi Philippe,
AFAICR, I don't think it is a regression, rather something that was never implemented on the client 'dcop' side.
Indeed it would be a good thing to add into the client. In such case we also need to see how KDCOP would handle it as well.
The extra brackets probably comes from the client printing statement (haven't checked, just guessing wildly).
Hi Philippe,
AFAICR, I don't think it is a regression, rather something that was never implemented on the client 'dcop' side.
Indeed it would be a good thing to add into the client. In such case we also need to see how KDCOP would handle it as well.
The extra brackets probably comes from the client printing statement (haven't checked, just guessing wildly).
rather something that was never implemented on the client 'dcop' side.
Based on the source code, the client should be able to process TQValueLists and TQMaps, but it wouldn't be able to handle it were the type to be enclosed in something. I'm not sure what is the actual problem here, but I think the code proves at least the point above.
> rather something that was never implemented on the client 'dcop' side.
Based on the source code, the client *should* be able to process [`TQValueList`s](https://mirror.git.trinitydesktop.org/gitea/TDE/tdelibs/src/branch/master/dcop/client/marshall.cpp#L206) and [`TQMap`s](https://mirror.git.trinitydesktop.org/gitea/TDE/tdelibs/src/branch/master/dcop/client/marshall.cpp#L206), but it wouldn't be able to handle it were the type to be enclosed in something. I'm not sure what is the actual problem here, but I think the code proves at least the point above.
If my memory is not mistaken, I had looked into this long ago and when a TQMap is returned by the DCOP call, the client does not receive the actual map object, rather a string saying that is a TMap.
I may be totally wrong, so disregard this comment if it is proven that may memory is wrong. If I had the time, I would look into the code, by right now there are way too many things on my table.
If my memory is not mistaken, I had looked into this long ago and when a TQMap is returned by the DCOP call, the client does not receive the actual map object, rather a string saying that is a TMap.
I may be totally wrong, so disregard this comment if it is proven that may memory is wrong. If I had the time, I would look into the code, by right now there are way too many things on my table.
As demonstrated by the PR it actually must be a regression due to renaming (class names lengths changed and dcopclient wasn't prepared to deal with this).
As demonstrated by the PR it actually must be a regression due to renaming (class names lengths changed and `dcopclient` wasn't prepared to deal with this).
System info
TDE: Trinity R14.1.0 [DEVELOPMENT]
OS: Slackware64-current
Description
When passing a function that returns a TQValueList, a QCStringList or a TQMap to the
dcop
command, like this:The expected behaviour is that the utility iterates over the list/map and prints its contents (the de-marshaling aka decoding is handled via
dcop/client/marshall.cpp
and code for handling lists and maps is there already).The actual output is this:
This seems like a regression, as some KDE3 era DCOP tutorials demonstrate the behaviour
e.g. here.
(My guess is that these extra angle brackets break thedemarshal()
function. A possible solution —I haven't looked much into the code yet— would be to strip the enclosing angle brackets before attempting to parse the type, but I'm actually curious where these brackets come from at all.)Hi,
can you be more specific regarding example and brackets?
<TQMap<TQCString,DCOPRef>>
I am not sure it was able to list a complex structure in the pastBR
Hi Philippe,
AFAICR, I don't think it is a regression, rather something that was never implemented on the client 'dcop' side.
Indeed it would be a good thing to add into the client. In such case we also need to see how KDCOP would handle it as well.
The extra brackets probably comes from the client printing statement (haven't checked, just guessing wildly).
Based on the source code, the client should be able to process
TQValueList
s andTQMap
s, but it wouldn't be able to handle it were the type to be enclosed in something. I'm not sure what is the actual problem here, but I think the code proves at least the point above.If my memory is not mistaken, I had looked into this long ago and when a TQMap is returned by the DCOP call, the client does not receive the actual map object, rather a string saying that is a TMap.
I may be totally wrong, so disregard this comment if it is proven that may memory is wrong. If I had the time, I would look into the code, by right now there are way too many things on my table.
As demonstrated by the PR it actually must be a regression due to renaming (class names lengths changed and
dcopclient
wasn't prepared to deal with this).Fixed with PR #168.