PDA

View Full Version : First impressions on G6



mhund
August 5th, 2015, 09:52 AM
Hi Ron,

long time no see. But I'm still with girder over the years; just using G5 in my home installation. After a while I started today to play a little bit around with G6 and didn't come very far.

1. I didn't get a connection to the service of a remote mashine. The client "girder remote" ui tries to connect to that server but it stays in "connecting" mode. A local "Remote connection" on the server's mashine works well with the same connection data.

2. In the event list in the UI I see only girder events, allthough there a many plugins activated providing other events (e.g. keyboard input). Can I still "learn" events like in G5?

3. Can I save GML files also at dedicated locations?

4. can this bee because of windows 10 I have installed on all PCs?

Sofar some initial questions - I hope not too dump. My G5 is working properly but I don't want to stick with the old stuff :-)

regards,

Martin

Ron
August 5th, 2015, 10:04 AM
Welcome back!

1. Did the auto-detection work or did you specify the ip and port number your self? Firewall?

2. That list will fill up as events come in (it's shows static events as exported by plugins and dynamically as other events come in). But of course you can drag and drop from the logger as always

3. Currently we're saving the files to APPDATA\Local\Promixis\Girder 6. You can export but Girder keeps the files there.

4. Running Windows 10 here, works as expected.

mhund
August 5th, 2015, 11:16 AM
Thanks for the fast reply, Ron.

1. No autodetection. There is a VPN connection inbetween. The client and the server are comming out of different IP segments. But the two networks are connected and this works properly beside the issue.
By the way: Without VPN it seems to work - but I had to manually add "girder6service.exe" in the windows firewall in addition to "girder6.exe". This was not done automatically while installation. Is this what is expected?

2. I do not see any events comming in - neither in the event section on the left nor in the logger.

3. & 4. ok. I understand.

mhund
August 5th, 2015, 11:22 AM
Additional to 2: I tested with keyboards input events. Nothing happens. I tested other events (Task Create) which works well. So maybe an issue arround the keyboard plugin.

Ron
August 5th, 2015, 11:28 AM
1. Different versions of Windows have had different firewalls. I'll have to see if there is a clear-cut way to do that now.

2. Strange. Are you running the back-end on the same machine that you are pressing the keyboard on? Did you enable the "Keyboard Input" plugin?

mhund
August 5th, 2015, 11:45 AM
to 2.: Interesting. It works, when I start "girder local" or "girder remote in process" mode. It works not in "girder remote local network" mode. Maybe a keyboard-plugin-specific behaviour.

mhund
August 7th, 2015, 06:37 AM
Hi Ron,

just found out that on my server girder is not listening at port 1024 (which I understand would be the default setting) but on port 20000. Is this explainable? How can I set the port the girder service is listening? Didn't find anything where to configure the service execpt of setting the password.

would be glad to get a quick replay :-)

thanks in advance,

Martin

mhund
August 7th, 2015, 06:48 AM
can give me the answer by my self. Found this post:

http://www.promixis.com/forums/showthread.php?21792-Port-Selection&p=149676#post149676

In thie referred file I see port 20000. Still the question why this was selected instead of 1024 which is not ocupied. Nevertheless - it works now over VPN.

Still keeps the problem with the keyboard input plugin. But this isn't critical for me. I just wanted to select keyboard input for my first tests of G6.

Ron
August 7th, 2015, 10:01 AM
Why 20000 vs 1024,... defaults somewhere :) sorry for the confusion.

The way the keyboard plugin is programmed is that it (currently) only listens for keypresses on the machine that is running Girder's core ( in your case the remote machine ).

mhund
August 7th, 2015, 10:55 AM
Hi Ron,

as already said in Post #6: It seems that you wanted to implement it this way. But it seems not to be :-)


to 2.: Interesting. It works, when I start "girder local" or "girder remote in process" mode. It works not in "girder remote local network" mode. Maybe a keyboard-plugin-specific behaviour.

My test wasn't with a remote server but both with a local server running on the same PC like the client. I just used three methods to connect to this local server:

1. "girder in same process": works
2. "girder remote local" doesn't work
3. "girder remote over Internet" connecting to the own IP doesn't work

nevertheless - I will check it.

Ron
August 7th, 2015, 10:57 AM
(Not trying to argue here)

If you observed:

1. "girder in same process": works
2. "girder remote local" doesn't work
3. "girder remote over Internet" connecting to the own IP doesn't work

Then that is as expected. The remote local which I assume is a local service instance, which runs on a different desktop and doesn't see the key presses you do on a different desktop things make sense. I can add keyboard capturing on the UI end as well.

mhund
August 7th, 2015, 11:40 AM
(sorry - don't want to bother you - just understand)

So maybe it is because I do not understand the separated desktops-thing. I thought it is as simple like: UI and server on same PC means one keyboard and one plugin listening for key presses.

Ron
August 7th, 2015, 11:49 AM
no problem. it's all new I understand

yeah if the back-end and front-end are running on different desktops (even if it's the same computer) only the active desktop gets the keystrokes. Probably best to have an option to catch keystrokes on the front-end as well.

mhund
August 7th, 2015, 12:03 PM
I see. Thanks. Didn't expect that the server (as a service) is dedicated to any desktop; i mean - it runs also when no user is logged in and no desktops are active at all. In addition to that there is only one desktop configured on the pc

Ron
August 7th, 2015, 12:08 PM
Service Applications run on their own desktop. That desktop is always there in addition to your own desktop.

mhund
August 7th, 2015, 12:26 PM
Thanks. This was the missing link for me.

mhund
August 11th, 2015, 05:22 PM
Hi Ron,

I just have to come back to this issue to make it cristal clear to me. Background: My girder use case is running on a living room PC working as server and TV front end. I use girder also for controlling TV / media software which means girder has to send keyboard commands to windows applications running on the desktop in the context of the current user. Am I right with the following assumptions:

1. to be able to maintain windows apps running on the user desktop (keyboard, open/close, ...), I need girder server to run in the same process like the girder front end which is running in the user context. It will not work with girder running as a service. Right?

2. The PC has no physical keyboard and is so to say unattended. I need to access to girder remotly by a separat PC's girder front end. I can connect remotely to the girder server running in the front end process in the same way like I connect to a girder server running as a service. Right?

3. When I remotly connect to the girder server running in the front end process, the server behaves different like a server running as a service in sense of configuration (password-setting, port-setting, ...). After restarting girder in a common process, passwords and ports are resetted to default. Right?

4. Girder (server) has no option to start with windows in "one process" / "hidden in tray" mode as it was with G5. Right?

Thanks for some answers in advance and sorry for the dummy questions. I just feel better if i understand g6 better. By the way: Today I was so brave that I switched over to g6 on my productive system allthough my family kills me if the home server / tv is not working. As I'm still alive, you can see that it works sofar :-)

Ron
August 11th, 2015, 08:06 PM
1. Yes, Girder needs to run in the same desktop session as the windows you are trying to control. BUT here is the trick, you can start a Girder front-end in the desktop session you are trying to control, have it connect to the backend in the service session. Then in Window targetting also fill in the "Session" box. Set that Session value to the "front-end" value of your choice. ( make sense? )

2. Correct

3. As you have figured out by now Girder it self consists of a front-end and a back-end (NetRemote is also a front-end but is a different thing for this discussion). The back-end stores all the settings in it's session. So if the back-end runs in the service session it will store it's settings in a different spot from if you run Girder's back-end in the user session. That is what is confusing you I think. So passwords are not reset to default, they are just loaded from a different location.

4. Sure, you can pass a few commandline arguments ( see the manual ) to make Girder start in process in the tray bar. Just create a shortcut and place that in the startup menu.

Does that help? I feel the back-end front-end thing is confusing, but powerful once you get it.

mhund
August 12th, 2015, 09:13 AM
Hi Ron,

1. Makes sense. Thank you for the trick. So what I understand is, that a girder client is not only a UI-client, but also something like a server's satelite. Being so, it can send events to the server as well as execute actions on behalf of the server. Maybe I missed that but if not it's worth to spend a sentence about that in the manual.
It works - by the way - very well. Have changed it to make the service run more independend than a single-process installation.

3. I see the server-as-service stores the settings in that file settings.json. To me it seems that the server-in-process does not store this data at all. After restart, password is the defalut one again.

4. works fine. Thank you.

I get more and more insights in your idea of G6. It is complex as well as powerfull. Allways a tradeoff to keep it intuitive.