ReadMe update about WL/WayLand icon/Connection timeout/Acknowledgment of WLRDP configuration/Logging socket layer

[bphd]

Cassowary don't do it himself and it warns you nowhere about that required parameter
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

=> Only useful for full RDP (see details about RAILS). 1. You should add an explanation in the ReadMe to avoid more tickets about that

[bphd]

And give those WayLand apps a favicon. Because if it's not configured, it just have a WayLand icon and well, it's impossible to know what is what with those default icons

=> 2. Add icons to (x)WayLand apps (Cassowary GUI, RDP sessions...)

[bphd]

How to change the timeout of re-connection? Because my VM is utterly slow, it can take 5 minutes to open an app, but Cassowary seems to not wait more than 2 seconds before issuing a timeout

=> No way of changing that other than modifying the timeouts in the Python code. 3. Either explain in the ReadMe where to change such things, either create a GUI parameter

[bphd]

Even when setting WLFreeRDP, it stills try to connect by issuing a XFreeRDP command, which fail, so it can't request the variable to start controlling the VM from the parameters. This should be fixed. Even for test purposes, testers wait for the app to obey and issue WL commands when they set it in the options. Like we say, they know what they do. So it should be parametrable here too

=> 4. Should issue only WLRDP commands when the GUI is configured fully with WLRDP selected

[ DEBUG ] : [ helper -> fix_black_window ] --> Trying to fix black window bug by opening a test window before requested application - 1659961351.385364CMDLINE: xfreerdp /d:"" /u:"user" /p:"password" /v:"192.168.0.1" +clipboard /a:drive,root,/ +decorations /cert-ignore /sound /scale:100 /dynamic-resolution /span /wm-class:"cassowaryApp-echo" /app:"ipconfig.exe"

But with manual option like full RDP session, it issue a WLFreeRDP command and logically open successfully an RDP session, though it haven't "connected" to the VM yet because of what I said prior

[casualsnek]

Please note that using wlfreerdp for anything other than full session does not work, xfreerdp with Xwayland should still be used for running indiviual apps. The failing of [ DEBUG ] : [ helper -> fix_black_window ] should have no effect as it workaround to a bug and is only used to trigger login on server, which if not done just shows black rectangle region on first app launch !

[bphd]

Please note that using wlfreerdp for anything other than full session does not work, xfreerdp with Xwayland should still be used for running indiviual apps. The failing of [ DEBUG ] : [ helper -> fix_black_window ] should have no effect as it workaround to a bug and is only used to trigger login on server, which if not done just shows black rectangle region on first app launch !

Sure, but even without that, I still get a timeout and no connection of Cassowary to the VM. You should add a timeout configuration option. Because here I can just modify the code to extend the timeout for my VM taking 5 minutes to respond

=> See 3. #98 (comment)

And maybe Cassowary can display the command he use to establish the connection. Because the only command he issue is a "useless" one about the black screen workaround and not the actual connection try. He can issue the socket method he use too. Explain what he does and what Windows reply to him. It's a good thing for debug purposes, even if it's not a FreeRDP command

=> __5. Be vebosy/logging about what he does on the socket level and what Windows replies (either being on the connection part or the fetching part. "send ] --> Sending message to server" "init_connection ] --> Attempting to connect to server" isn't enough). Add explanations in the ReadMe about what trick he does on that socket level

[casualsnek]

Please note that using wlfreerdp for anything other than full session does not work, xfreerdp with Xwayland should still be used for running indiviual apps. The failing of [ DEBUG ] : [ helper -> fix_black_window ] should have no effect as it workaround to a bug and is only used to trigger login on server, which if not done just shows black rectangle region on first app launch !

Sure, but even without that, I still get a timeout and no connection of Cassowary to the VM. You should add a timeout configuration option. Because here I can just modify the code to extend the timeout for my VM taking 5 minutes to respond

And maybe Cassowary can display the command he use to establish the connection. Because the only command he issue is a "useless" one about the black screen workaround and not the actual connection try

Thank you for feedback, i will consider allowing timeout configuration !

Cassowary does display the full command for application being launched through freerdp.
But if you mean the command that cassowary issues to connect to windows for things like application list, shares/association settings, then it cannot be displayed as there is no command being used and it is done internally via code using sockets connection to server application installed in windows !

[bphd]

Please note that using wlfreerdp for anything other than full session does not work, xfreerdp with Xwayland should still be used for running indiviual apps. The failing of [ DEBUG ] : [ helper -> fix_black_window ] should have no effect as it workaround to a bug and is only used to trigger login on server, which if not done just shows black rectangle region on first app launch !

Sure, but even without that, I still get a timeout and no connection of Cassowary to the VM. You should add a timeout configuration option. Because here I can just modify the code to extend the timeout for my VM taking 5 minutes to respond
And maybe Cassowary can display the command he use to establish the connection. Because the only command he issue is a "useless" one about the black screen workaround and not the actual connection try

Thank you for feedback, i will consider allowing timeout configuration !

Cassowary does display the full command for application being launched through freerdp. But if you mean the command that cassowary issues to connect to windows for things like application list, shares/association settings, then it cannot be displayed as there is no command being used and it is done internally via code using sockets connection to server application installed in windows !

I use Windows Pro. I don't know if it has such servers apps. Can you redirect me to lines of the software where it issues those sockets connections? And where the timeouts are set for this precise case? Because I want to get a connection today, but I will test your GUI timeout option the day you'll get it out
Because the problem is that I'm stuck for now, without that connection I can't use most Cassowary functions. Just the full RDP, but I don't need Cassowary for that

=> See 3. #98 (comment) and 5. #98 (comment)

[casualsnek]

Because the problem is that I'm stuck for now, without that connection I can't use most Cassowary functions. Just the full RDP, but I don't need Cassowary for that

I think you somehow forgot to install windows server component. If you have not you need to download and extract https://github.com/casualsnek/cassowary/releases/download/0.6/cassowary-0.6-winsetup.zip in windows and set it up !

Follow the instructions 'on windows' section of https://github.com/casualsnek/cassowary/blob/main/docs/2-cassowary-install.md

After installing cassowary's windows component and restarting the vm, it should be able to connect !

By the way, the timeout for client connection is set at: https://github.com/casualsnek/cassowary/blob/main/app-linux/src/cassowary/client.py#L49

[bphd]

Because the problem is that I'm stuck for now, without that connection I can't use most Cassowary functions. Just the full RDP, but I don't need Cassowary for that

I think you somehow forgot to install windows server component. If you have not you need to download and extract https://github.com/casualsnek/cassowary/releases/download/0.6/cassowary-0.6-winsetup.zip in windows and set it up !

Follow the instructions 'on windows' section of https://github.com/casualsnek/cassowary/blob/main/docs/2-cassowary-install.md

After installing cassowary's windows component and restarting the vm, it should be able to connect !

By the way, the timeout for client connection is set at: https://github.com/casualsnek/cassowary/blob/main/app-linux/src/cassowary/client.py#L49

I've already done the Windows part and my problem is still here

It will be better to follow 3. #98 (comment)

Even after changing the line to 5000 and wait a longer time than it takes for the VM to respond normally, I still get a timeout from Cassowary. This socket part needs more logging to know why exactly it can't establish connection (see 5. #98 (comment))

OK, now I don't understand anything. I tried to connect locally while Cassowary was trying, and it stopped its stale and a window appeared where the RDP session was here and Cassowary returned that the connection was successful. So for Cassowary to establish a connection, he needs his session... To be stolen? That totally not a clear way to connect and not easily reproducible. And even after that. Now my timeout are not in the connection section but are now on the tabs where Cassowary tries to get information. That's the same problem. From what I understand : When I'm not connected locally, I get a timeout at VM connection. When I'm logged locally, I get a timeout at Cassowary tab information fetching. For totally unknown reasons, sometimes the connection happen, sometimes it times out, whether someone is connected locally or not

=> 6. If possible, the setup procedure should be clarified about how to get a successful connection from the beginning. Because here it seems that a local connection has changed something for Cassowary, and it wasn't signified in the manual