DCOP CLI tool does not handle lists/maps #166

Closed
opened 2 years ago by blu.256 · 6 comments
Collaborator

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.

(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>~~
blu.256 added the SL/regression label 2 years ago
Collaborator

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, 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
Owner

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).
Poster
Collaborator

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.
Owner

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.
Poster
Collaborator

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).
Poster
Collaborator

Fixed with PR #168.

Fixed with PR #168.
blu.256 closed this issue 2 years ago
blu.256 added this to the R14.0.13 release milestone 2 years ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TDE/tdelibs#166
Loading…
There is no content yet.