[GH-ISSUE #255] Additional settings to connection using protocol

kerem commented

2026-03-01 17:18:04 +03:00

Owner

Originally created by @majkinetor on GitHub (Jun 5, 2022).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/255

Originally assigned to: @majkinetor, @VShawn on GitHub.

Current protocol implementation feels uncomplete. Mostly because you can't map CLI parameters to GUI fields per connection.

So after #239, I started using wfreerdp, and it works nice and presents less problems to me on specific connections then RDP. For example, with #254 I can no longer use RDP to connect to my media center, but wfreerdp works nice. Also, on that particular machine RDP via PRM is problematic (I get popups and sometimes it can't find machine?). So I switched to wfreerdp and noticed that its cumbersome to tweak its parameters - when I need full screen resolution or remote audio for example, I need to change protocol, but then, all other connections depending on that protocol are changed. Fix for this is to create another protocol just to change single parameter.

Original protocol ideas are here and they included mapping CLI options to GUI params. But since that may be non-trivial to implement, how about we make it quick and trivial and add just one field for all connections using protocols, Additional Settings that will be joined with the one that is given in protocol definition by adding it as a suffix (so complete command line will be <CmdParameter> <AdditionalSettings>). This is also in line with RDP that has this very same option.

So, if protocol is given:

Exe path: C:\wfreerdp_nightly_build\wfreerdp.exe
CMD Parameter: /v:%PRM_HOSTNAME% /u:%PRM_USERNAME% /p:%PRM_PASSWORD% +decorations

if I have this in connection:

Additional Settings: /f /audio-mode:1

The resulting CMD line will be specific to that connection and some mandatory things will be set for all connections.

In the case of wfreerdp, it allows me to tweak any connection independently very much the same as with regular RDP, just via CLI. I add markdown note with URL to parameters and call it a day. I imagine this is very useful for any protocol.

Note that this RDP feature has autocomplete list:

We could have this with any protocol by allowing one to add all possible options in a list that PRM will later use to filter it out.

/cc @dethknite

Originally created by @majkinetor on GitHub (Jun 5, 2022). Original GitHub issue: https://github.com/1Remote/1Remote/issues/255 Originally assigned to: @majkinetor, @VShawn on GitHub. Current protocol implementation feels uncomplete. Mostly because you can't map CLI parameters to GUI fields per connection. So after #239, I started using wfreerdp, and it works nice and presents less problems to me on specific connections then RDP. For example, with #254 I can no longer use RDP to connect to my media center, but wfreerdp works nice. Also, on that particular machine RDP via PRM is problematic (I get popups and sometimes it can't find machine?). So I switched to wfreerdp and noticed that its cumbersome to tweak its parameters - when I need full screen resolution or remote audio for example, I need to change protocol, but then, all other connections depending on that protocol are changed. Fix for this is to create another protocol just to change single parameter. Original protocol ideas are [here](https://github.com/1Remote/PRemoteM/issues/61#issuecomment-760897667) and they included mapping CLI options to GUI params. But since that may be non-trivial to implement, how about we make it quick and trivial and add just one field for all connections using protocols, _Additional Settings_ that will be joined with the one that is given in protocol definition by adding it as a suffix (so complete command line will be `<CmdParameter> <AdditionalSettings>`). This is also in line with RDP that has this very same option. So, if protocol is given: - Exe path: C:\wfreerdp_nightly_build\wfreerdp.exe - CMD Parameter: `/v:%PRM_HOSTNAME% /u:%PRM_USERNAME% /p:%PRM_PASSWORD% +decorations` if I have this in connection: - Additional Settings: `/f /audio-mode:1` The resulting CMD line will be specific to that connection and some mandatory things will be set for all connections. In the case of wfreerdp, it allows me to tweak any connection independently very much the same as with regular RDP, just via CLI. I add markdown note with URL to parameters and call it a day. I imagine this is very useful for any protocol. Note that this RDP feature has autocomplete list: ![image](https://user-images.githubusercontent.com/85767/172072698-7b7d85c3-af5f-4390-a2e5-71434ae60bb3.png) We could have this with any protocol by allowing one to add all possible options in a list that PRM will later use to filter it out. /cc @dethknite

kerem

2026-03-01 17:18:04 +03:00

closed this issue
added the
meta-enhancement

general-supportive
labels

kerem commented

2026-03-01 17:18:05 +03:00

Author

Owner

@dethknite commented on GitHub (Jun 6, 2022):

Nice. Certainly would make using alternate RDP implementations much less cumbersome. The VNC hack was really limited and eventually I gave up trying to implement it as hardcoding too many variables just didn't work.

@dethknite commented on GitHub (Jun 6, 2022): Nice. Certainly would make using alternate RDP implementations much less cumbersome. The VNC hack was really limited and eventually I gave up trying to implement it as hardcoding too many variables just didn't work.

kerem commented

2026-03-01 17:18:05 +03:00

Author

Owner

@majkinetor commented on GitHub (Jun 6, 2022):

I didn't have a problem where "it just didn't work", but its totally unpractical and cumbersome for sure.

@majkinetor commented on GitHub (Jun 6, 2022): I didn't have a problem where "it just didn't work", but its totally unpractical and cumbersome for sure.

kerem commented

2026-03-01 17:18:05 +03:00

Author

Owner

@dethknite commented on GitHub (Jun 6, 2022):

It doesn't work if a user/pass to a server is different.. as the pass has to be hardcoded.

@dethknite commented on GitHub (Jun 6, 2022): It doesn't work if a user/pass to a server is different.. as the pass has to be hardcoded.

kerem commented

2026-03-01 17:18:05 +03:00

Author

Owner

@majkinetor commented on GitHub (Jun 6, 2022):

Nah, use this: /v:%PRM_HOSTNAME% /u:%PRM_USERNAME% /p:%PRM_PASSWORD%.
PRemoteM will then set this based on connection and its GUI options.

@majkinetor commented on GitHub (Jun 6, 2022): Nah, use this: `/v:%PRM_HOSTNAME% /u:%PRM_USERNAME% /p:%PRM_PASSWORD%`. PRemoteM will then set this based on connection and its GUI options.

kerem commented

2026-03-01 17:18:05 +03:00

Author

Owner

@dethknite commented on GitHub (Jun 6, 2022):

/p:%PRM_PASSWORD% didn't work for me

@dethknite commented on GitHub (Jun 6, 2022): /p:%PRM_PASSWORD% didn't work for me

kerem commented

2026-03-01 17:18:05 +03:00

Author

Owner

@majkinetor commented on GitHub (Jun 6, 2022):

That is strange. Try copy/paste my command above because that is exactly what I copy pasted from my protocol and it works on multiple connections... U use 0.7 beta.

@majkinetor commented on GitHub (Jun 6, 2022): That is strange. Try copy/paste my command above because that is _exactly_ what I copy pasted from my protocol and it works on multiple connections... U use 0.7 beta.

kerem commented

2026-03-01 17:18:05 +03:00

Author

Owner

@VShawn commented on GitHub (Jun 9, 2022):

I didnt make a alternate runner for RDP because there are too many params in RDP.

how about we make it quick and trivial and add just one field for all connections using protocols, Additional Settings that will be joined with the one that is given in protocol definition by adding it as a suffix

I thought about this approch months ago.

what stopping me to make implement:

Too hardcore for unskilled pepole if we make UI like this:
Noticed We may loss the tab feature support for RDP if start with cli. (currently tab view can not handle a hosting window like KiTTY switch between full-screen and non-full screen)

@VShawn commented on GitHub (Jun 9, 2022): I didnt make a alternate runner for RDP because there are too many params in RDP. > how about we make it quick and trivial and add just one field for all connections using protocols, Additional Settings that will be joined with the one that is given in protocol definition by adding it as a suffix I thought about this approch months ago. what stopping me to make implement: 1. Too hardcore for unskilled pepole if we make UI like this: ![](https://user-images.githubusercontent.com/85767/172072698-7b7d85c3-af5f-4390-a2e5-71434ae60bb3.png) 2. Noticed We may loss the tab feature support for RDP if start with cli. (currently tab view can not handle a hosting window like KiTTY switch between full-screen and non-full screen)

kerem commented

2026-03-01 17:18:05 +03:00

Author

Owner

@majkinetor commented on GitHub (Jun 9, 2022):

Too hardcore for unskilled people if we make UI like this:

Yet we have this kind of hardcore in RDP? Also, custom protocols are NOT for unskilled people.

Noticed We may loss the tab feature support

Not sure what you mean, but this can not be true. The end effect of this additional field would be exactly the same as we have now, just way less awkward to use.

@majkinetor commented on GitHub (Jun 9, 2022): > Too hardcore for unskilled people if we make UI like this: Yet we have this kind of hardcore in RDP? Also, custom protocols are NOT for unskilled people. > Noticed We may loss the tab feature support Not sure what you mean, but this can not be true. The end effect of this additional field would be exactly the same as we have now, just way less awkward to use.

kerem commented

2026-03-01 17:18:05 +03:00

Author

Owner

@VShawn commented on GitHub (Jun 9, 2022):

tab feature support I mean:

with hosting wfreerdp.exe, this full screen button won't work in current tab window.

@VShawn commented on GitHub (Jun 9, 2022): tab feature support I mean: ![image](https://user-images.githubusercontent.com/10143738/172787767-3b8020d3-3295-44e6-b5a3-40f9164e454b.png) with hosting wfreerdp.exe, this full screen button won't work in current tab window.

kerem commented

2026-03-01 17:18:05 +03:00

Author

Owner

@majkinetor commented on GitHub (Jun 9, 2022):

dog.310? :) LOL

with hosting wfreerdp.exe, this full screen button won't work in current tab window.

Well, that is irrelevant to this problem, no? I doubt this can be fixed with "CLI protocol" - even if you know exact parameter to make it full screen, you will need to restart the process to apply it. Seamless work for random CLI protocol would require some form of IPC which is protocol specific and can not be done this way (or full blown PRM plugins which is a lot of work). This feature is not meant to provide ultimate user experience but to just make it work on acceptable level within PRM connection management system.

In the meantime, not being able to specify CLI protocol specifics on any connection makes this feature almost unusable.

@majkinetor commented on GitHub (Jun 9, 2022): dog.310? :) LOL > with hosting wfreerdp.exe, this full screen button won't work in current tab window. Well, that is irrelevant to this problem, no? I doubt this can be fixed with "CLI protocol" - even if you know exact parameter to make it full screen, you will need to restart the process to apply it. Seamless work for random CLI protocol would require some form of IPC which is protocol specific and can not be done this way (or full blown PRM plugins which is a lot of work). This feature is not meant to provide ultimate user experience but to just make it work on acceptable level within PRM connection management system. In the meantime, not being able to specify CLI protocol specifics on any connection makes this feature almost unusable.

kerem commented

2026-03-01 17:18:06 +03:00

Author

Owner

@VShawn commented on GitHub (Jun 9, 2022):

also parameter translate is needed

e.g. in we stroe 2 as multi-screen flag

github.com/1Remote/PRemoteM@582bde4529/Ui/Model/Protocol/RDP.cs (L20-L25)

while wfreerdp.exe using CLI parameter /multimon as multi-screen flag

which means we need translate 2 to /multimon when RDP using runner wfreerdp.exe.

@VShawn commented on GitHub (Jun 9, 2022): also parameter translate is needed e.g. in we stroe `2` as multi-screen flag https://github.com/1Remote/PRemoteM/blob/582bde452913050088fe70afcab2f4cde40cb758/Ui/Model/Protocol/RDP.cs#L20-L25 while wfreerdp.exe using CLI parameter `/multimon` as multi-screen flag which means we need translate `2` to `/multimon` when RDP using runner wfreerdp.exe.

kerem commented

2026-03-01 17:18:06 +03:00

Author

Owner

@majkinetor commented on GitHub (Jun 9, 2022):

Not sure about it:

https://github.com/awakecoding/FreeRDP-Manuals/blob/master/User/FreeRDP-User-Manual.markdown#command-line-interface

@majkinetor commented on GitHub (Jun 9, 2022): Not sure about it: https://github.com/awakecoding/FreeRDP-Manuals/blob/master/User/FreeRDP-User-Manual.markdown#command-line-interface

kerem commented

2026-03-01 17:18:06 +03:00

Author

Owner

@majkinetor commented on GitHub (Jun 4, 2023):

I will close this because I the entire protocol feature needs to redesigned from zero, its too cumbersome currently which we will do in discussion.

https://github.com/1Remote/1Remote/discussions/432

@majkinetor commented on GitHub (Jun 4, 2023): I will close this because I the entire protocol feature needs to redesigned from zero, its too cumbersome currently which we will do in discussion. https://github.com/1Remote/1Remote/discussions/432

Rows
Columns

[GH-ISSUE #255] Additional settings to connection using protocol #2145