Interfaces that talk across multiple computers, how?

[mister_electronico]

It is strange between the message:

Sorry I haven't had time for this... errands and crazy IRL drama.

I'll get to it when I can...

and the message

mister_electronico wrote:
Thanks for check it and reply.
Thanks. Just responded on other thread.

Now suddenly this message.

Actually... looking at your work, mister_e -- there won't be mouse use in this particular project. It's all keyboard stuff. Maybe make the buttons work using the keyboard?

There seems to be ghost that control our communications.

At the moment I can not think of anything, but I'll think about, look for an event in gtkdialog by keyboard.

Or create hidden buttons which are assigned hot keys.

Think about it, maybe one of the great sages who there are in this forum the give us a solution.

See you.

[mister_electronico]

There the allocation of hot keys in gtkdialog.

http://murga-linux.com/puppy/viewtopic. ... 039#782039


One example:
http://murga-linux.com/puppy/viewtopic. ... 147#782147

[01micko]

Interesting (albeit a bit eccentric ) project!

Hmmm com ports.. this eliminates using a webserver type setup, well it would be possible but a nightmare methinks. Your little pseudo ring network will be slow but with sending tiny chunks of data that shouldn't be a problem.

nc may be your friend on the scripting side of things.

Some interesting resources to get your head around:

http://techtinkering.com/2013/04/02/con ... ver-tcpip/

http://techtinkering.com/2013/03/25/usi ... -machines/

No doubt there are millions more of varying benefit.

Q(s). Ok, putting myself in the Captain's seat... where are we going? What conditions can we expect? What monitoring do we have? (eg: an asteroid or space junk is approaching and we are at warp speed, I gather we won't get much warning?)

Have you any simulation of conditions? (Or at least an idea).

</remove's Captains hat>

I suppose gtkdialog is really your only way to go. But there are considerations. Be aware that gtkdialog is very slow. It's really a layer over a layer (ie: it converts shell code to gui via a C program and that is processor/RAM intensive).

So the coding has to be very efficient , otherwise there will be a lot of latency and that said asteroid would have obliterated the ship and crew to become more space junk.

I'm thinking that 'buttons' are useless in this case since they are useful with WIMP input. I think just changing the colour of the relative images would be enough on the signal of a certain key press. Perhaps for your horizontal 'scaled' images (are they just monitors?) you could use the slider widget or even a progress bar as they can update on input, and also be themed.

You know you don't even need a window manager for X to run. Just start X without calling one.

As for X not playing nice with those odd monitors, try an old puppy (4.1.2 maybe) and use Xvesa. I gather security is not an issue (no net connection) and I also gather that the hardware is a few years old so it should work ok. Or try Iguleder's implementation, uses TinyX iirc, but your hardware needs to be 'free' as there are no firmware binary blobs.

[starhawk]

Wow, the attention of 01micko!

*bows* Ave, Caesar!

Eccentric, yes, comes with the territory I'm afraid.

I'm not familiar with nc. Looked it up, don't see the use (yet?). Enlighten me, please!

As for the conditions bit, I hadn't actually thought of that. That's an interesting idea, I could incorporate that, perhaps. It would be a little hard for me, I think -- I would have to assign a 'terrain type' (for lack of proper term) sort of attribute to each possible coordinate, is the only way I can imagine it. That gets tedious fast, as you might imagine!

Asteroids at FTL speeds would be taken care of by a navigational deflector sort of device. While this isn't Star Trek (I'm much too fat and not blonde enough to be Kirk, for one), the 'navigational deflector' term is convenient and accurate, and I'm sure Paramount/CBS/Viacom/corporate-overlord-of-the-week won't care if I borrow it.

Digging into this perhaps a little more than would be wise --

I can actually tell you how the FarDrive in this simulation would work if it were real. My imagined design for it is based on an unfortunately discredited scientific experiment (read here) wherein a scientist claimed that, basically, bouncing a magnetic field off a rotating superconductor created a mild antigravity-like effect (shielding the mass somewhat from gravity's effects -- remember that 'weight' is in fact the effect of gravity and therefore a force!). I have my doubts about how well the FarDrive would work in real life -- but it's certainly convincing enough to work for a vaguely realistic simulation, unless the players/users are real scientists

Warp Drive, on the other hand, relies on the gravitic effects of an imaginary substance called 'verterium cordtenide' (boy, say that one five times fast!). 'Warp coils' are made of that stuff, and when high-energy plasma gets near it, spacetime bends. The more energetic the plasma, the more bendy spacetime gets -- hence the need for a matter/antimatter reaction for any real speed. When hydrogen and anti-hydrogen collide, they annihilate into nearly pure energy -- but the particles and antiparticles they throw off will cause a chain reaction if you're not extraordinarily careful (the second and more well-known imaginary substance, dilithium, supposedly moderates this out so that it's not an issue). The 'core breach' in Star Trek: Generations was at least partially realistic in that sense -- but antimatter is so amazingly ill-tempered that not only should the ship have gone out in a bang, it should've taken the separated saucer and a considerable portion of the nearby planet with it! (That stuff is nasty.) But of course then there would be no survivors, which would really stink when it comes time to make yet another sequel...

*ahem*

The image color changing would be sufficient, yes -- and I could definitely go for a 'slider' or 'progress bar' for the load gauges.

The monitors are 480x234 resolution, I fully anticipate having to muck around like heck with xorg.conf to beat everything into submission there.

Hardware is a sextet of HP t5630W thin clients. Specs here, although I'll probably upgrade the RAM to 2gb. I have to say, you've got me quite worried about how slow GTKDialog potentially will be -- VIA's CPUs are always incredibly pathetic in terms of their processing power, and these clients use the 'Eden' sub-series where they make 'em even lower power to avoid having to put up with a little fan noise (not worth it if you ask me, but not too many people pay me any attention, so here we are).

[01micko]

I'm not familiar with nc. Looked it up, don't see the use (yet?). Enlighten me, please!

nc is pretty nifty, you can open ports (software ports) telnet over it, send messages, run commands - all sorts of remote stuff and you can easily script it and as a bonus it is a busybox applet, so should be there and very light. Visit the links in my previous posts if you have a networked machine nearby.

---

I made a little demo program for gtkdialog (doesn't use nc or anything, just changes the images) - attached.

I know it looks nothing like what you want but it demonstrates how to get key presses working with just images, since buttons are useless to you.

Just extract the tarball and click the script and press h, i, j & k. They are the active keys. Watch the bottom row.. (top 2 don't work, they are just to fill up the gui )

[greengeek]

Nice. How to access row 1 and 2?

[01micko]

Nice. How to access row 1 and 2?

Almost there! I'll post a file later.

[mister_electronico]

Amazing program.
Very interesting NC.

[01micko]

Amazing program.
Very interesting NC.

Yes, very handy too, it can even transfer files.

-----

Here we go, V2 of the gui.

-------------------------------------------------------------------

EDIT

Now to do something useful (sort of - well it might keep you amused for 100 seconds )

REQUIRES: xdotool

make a script and call it xdo

Code: Select all

#!/bin/sh

x=0
while [ $x -lt 100 ];do 
	my_key=$(( ( RANDOM % 18 )  + 1 ))
	case $my_key in
		1)k=a ;;
		2)k=b ;;
		3)k=c ;;
		4)k=d ;;
		5)k=e ;;
		6)k=f ;;
		7)k=g ;;
		8)k=h ;;
		9)k=i ;;
		10)k=j ;;
		11)k=k ;;
		12)k=l ;;
		13)k=m ;;
		14)k=n ;;
		15)k=o ;;
		16)k=p ;;
		17)k=q ;;
		18)k=r ;;
	esac

	xdotool key $k
	
	x=$((x + 1))
	sleep 1
done

Start the gui

Code: Select all

./demo.sh

start xdo

Code: Select all

./xdo

Make sure the gui 'Panel' comes back into focus by clicking it.

Chuckle for a second.

=======

Using nc

REQUIRES: a networked computer on same subnet NOTE: this is insecure! You may want to disconnect from the net. Your choice.

On the computer you have been playing with, which has xdotool, and the scripts xdo and demo.sh (call it the server) run the gui

Code: Select all

./demo.sh

Then start nc with the -l option, -p [port] option and -e [prog] - ./xdo as the arg.

Code: Select all

nc -l -p 3333 -e ./xdo

Get the IP address of your 'server'.

Make sure the 'Panel' gui is in focus.

On the remote computer, ie, the other one (client) call nc like so:

Code: Select all

nc [the Ip address of server] 3333

eg: nc 192.168.0.3 3333

Have another giggle as you watch the server gui jump around for ~100 seconds.

[mister_electronico]

Very clever way to create the program in gtkdialog, I think it already has starhawk everything he need to start his project and a good work ahead.

[starhawk]

Thank you thank you thank you 01micko!

I'm a little distracted at this very moment (I have the bothersome habit of keeping a dozen or so projects on simmer all at once, and switching between them when I can work on one and not another) but I should be able to look at that later today.

I uhm don't have a working network switch or router tho. I have one switch but I don't think I have a power supply for it right now, I'll have to check.

I'm definitely looking forward to checking this out tho.

[starhawk]

My network switch (Linkskey LKS-SG8P) may or may not work -- I have a compatible power supply, sort of, it's got the wrong tip. 5.5mm outer dia. 2.5mm inner dia. barrel plug... the switch requires a 2.1mm inner dia. plug. You'd be surprised at how much difference 0.4mm makes -- could cause some issues here.

I may see if it "kinda sorta" works with the wrong-size plug, since it's the right voltage and can handle 1-1/2x the current (remember electricity is always pull not push)... but I'm a little skittish about that.

[01micko]

Here you go, a 'sort of' working version of the pwr gui, works over the network too. Includes 'server' and 'client' programs.

read README.md

[starhawk]

Very nice Ran the demo... I see what you mean about slow, holy crap. That 2-3sec lag is really not going to fly here (going with the theme, lol) -- especially since I was testing it on my NICE computer (HP T610 Plus) rather than the already-slow systems I'm going to be using...

Any decent way to speed that stuff up?

[mister_electronico]

Very good Job, 01micko.

I have not tried the network part but what is the part of gtkdialog program works well.

In my case it responds almost immediately to the pressure of the key.
I am working over pentium --- 3 core maybe is this the different.

I think the way you have to make separate images is much clever than as I made in a previous post to make a single image of svg.

I will try to study all your program and understand well.


I've been working on my 4-panel displays, and when the program has to refresh gtkdialog many images SVG once it becomes slow.

I am analyzing the why and eventually came to the conclusion that it is precisely the cast of the action to refresh the image.


I have not had much time because of work, but this weekend I hope to put my conclusions.

Excellent program 01micko.

Greatings.

[starhawk]

What KIND of Pentium, mister_e? It matters -- a lot.

[01micko]

There isn't much I can do with the speed of the key presses. I just tested on my slower machine (compaq cq60, celeron T1600 @ 1.66 GHz, 1 GB RAM) and the gui took over 8 seconds to start, but key response time is <300 ms (milliseconds) which is ok. I would think that a key response of <1s would be 'ok'. That should be achievable on anything that puppy runs on.

Things to consider:

• turn off sound service
• turn off dbus
• turn off cups
• turn off any other service you don't need
• change cpu governor from 'on demand' to 'performance'
• turn off rox (extreme cases)

Try the attached gui, which now caches itself in /tmp as well as the images. It will significantly decrease startup time (after 1st run) but I doubt it will do much for key press response times.

(there are also other improvements and an option to have faster gauge refresh[fast machines only], larger res or both, because it's tiny on my 1600x1050!)

[starhawk]

Maybe that was me, then, and not the program -- I was looking at the gauge displays... took a while for them to update, it looked like.

But, again, that could be me.

[01micko]

Maybe that was me, then, and not the program -- I was looking at the gauge displays... took a while for them to update, it looked like.

The default is 5 seconds. In the gui I just posted it is still 5 seconds, but if you have a decent cpu it can be overridden with demo_2pwr.sh tm which brings it down to 2 seconds. The reason it is 5 is that the GTK timer widget is very cpu intensive. I can't do much about that except maybe write my own function in C using a file descriptor to detect changes and using select() to fire the action (which is probably how GTK does it anyway) but the fact it's running from a script could be the limiting factor.

The whole thing would be much faster in C but I haven't got time for that! Plus you don't know C and you will need to make mods to construct the other 2 interfaces.

PS: in the gui I posted half an hour ago, run demo_2pwr.sh -h for an overview of new options.

[starhawk]

Ahhhh, the 5sec thing explains it. I was thinking it would update instantaneously (idiot that I am lol).

Er, how CPU intensive are we talking? Systems involved here would be running this, JWM, and basically nothing else but the most absolutely necessary background processes... although the GTKDialog bit /would/ be full screen...

I'll probably use TahrPup 6.0.2 so that I have the latest GTKDialog, but I could go with something else should that be recommended. While I'm thinking about it -- as an aside, sort of -- I know that there's a way to disable services from within Puppy, via Bootmanager I think (it's different in Caro Vanguard which is my daily driver Pup) but can you do that manually and if so how?