I guess I could do a 3inputsbox to choose username server and channel too
Edit: ok its done but ugly ... will clean it up when it bothers me ... still trying to get around the ping ... pong every 200+ seconds ... maybe fork a while : do sleep 200 echo PONG and kill it with all status changes? ... wait better to fork the dialog and just do a continue (need to see if that works ... can you break/continue from within a loop from a process forked from it?)

technosaurus: Thanks for the mod to ashirc!
Found a vncviewer that only depends on X in old debian sources - attached the viewer part of vnc_3.3.2r2.
Also went through xchat 0.9/1.0/1.2 as I disliked 1.4... ...found that 1.2 is nice and runs well in pupngo apart from some font warnings. Attached static version of that.

Just a note on ashirc and similar apps. Bash has built-in tcp facilities (ash doesn't) that can take the place of telnet/netcat.

Just echo $msg > /dev/tcp/url/port

Where $msg would be the request containing the path of the requested page and various protocol info.

The response will come back on the same path and may contain various header info.(in other words, you can't just redirect it to a file like *.tar.bz2).

echo -e "GET /path/to/file.ext HTTP/1.1\n\n" >/dev/tcp/www.someurl.com/80
cat </dev/tcp/www.someurl.com/80
(the while read trick will fail if file starts any lines with empty space, but should work if you just need the text ... Now to experiment wtith header removal)_________________Web Programming - Pet Packaging 100 & 101

Using x11vnc with the Xvesa build with uclibc/tinyX11 seems to fail if Xvesa is missing XTEST extension (and MITSHM if you do not start x11vnc with -noshm switch). If Xvesa is build with -DXTEST and -DMITSHM x11vnc works ok but it seems that the Xvesa is unstable with MITSHM (freeze). So attached a Xvesa with -DXTEST...seems stable after running a couple of days with it.

maybe it wouldn't be too hard to invert the logic for x11vnc to require -shm to use shared memory instead of -noshm to disable it?

btw, have you been able to build a working Xvesa with tcp removed? I tried but even starting with -nolisten tcp failed ... it seems like maybe something is not ifdef'd. There were a couple of other things that may be easier to do than this if I could just find them - like starting in the highest supported resolution and bpp instead of a fixed one (the default doesn't work well on _all_ systems, but using the highest supported one _should_ ... in theory)_________________Web Programming - Pet Packaging 100 & 101

maybe it wouldn't be too hard to invert the logic for x11vnc to require -shm to use shared memory instead of -noshm to disable it?

btw, have you been able to build a working Xvesa with tcp removed? I tried but even starting with -nolisten tcp failed ... it seems like maybe something is not ifdef'd. There were a couple of other things that may be easier to do than this if I could just find them - like starting in the highest supported resolution and bpp instead of a fixed one (the default doesn't work well on _all_ systems, but using the highest supported one _should_ ... in theory)

Yes - a small patch to revert x11vnc shm logic should do it.

For the Xvesa thing - not sure what you mean...I have no problems running Xvesa with -nolisten tcp. But if you want to have it as default-built-in I think its the /hw/utils.c and /hw/connection.c that needs patching. Btw: The vnc-3.3.2r2 contains source-tree for a cutdown Xvesa server. I haven't tried to build it as my xmkmf is not working well at the moment - but it might have some hints for the Xvesa build.

The tk/tcl builds nicely with uclibc/tinyX11. I only had to add a few functions (FSSaver.o+ReconfWM.o) to Xlib (or actually added them to libtk8.5.a). The result is a static wish at 1552K and a static tclsh at 745K uncompressed (for both it is smaller that the dynamic linked bins). Had to comment out 3 lines in /usr/lib/tk8.5/tk.tcl

to get some of the demos running without errors.
At the moment testing in pupngo to see how many of the auxiliary file that can be removed - best guess now is that you will need approx 500K additional.
Unfortunately the widget demo requires msgcat so haven't been able to run that (reluctant to start compiling static version of the gettext monster...) but browse, hello, rmt, rolodex, tcolor and timer works (ixset needs xset which I also miss).

re: tcp - building without -DTCPCONN failed ... I'll try it again though, I may have removed other defines too.

tcl/tk really should just combine altogether they are only a single test away from being able to be a multicall binary
if you do a diff of tclappinit.c and tkappinit.c ... essentially tkappinit.c is tclappinit.c with an extra code block to run the tk interpreter

continuing on further the hwish in hv3 is tkappinit.c with an extra line to run the tkhtml interpreter
(I haven't explored this any further, it may be this way for other compiled tk apps)

Turns out that msgcat is an internal tcl-function...
Also seems that if you have a static build of tk tclsh is not needed.
So attached a stripped down pet (removed man/encodings/msg etc) with tcl/tk 8.5 static build (uclibc/tinyX11) that runs all demos of tk witout errors in pupngo (no shared libs at all needed). The demos and images-folders can be deleted - saving approx. 900K on disk - but included to have something to test with - leaving us with a total size on disk for tcl/tk approx. 1700K (if wish is upx ultrabrute compressed...).
Now we only need to find all those tk apps to replace the gtk1 apps (editor, ftp, archive, mail, paint, chat etc.).

20130513: Removed attachment as forum does not support file size anymore.Last edited by goingnuts on Mon 13 May 2013, 14:14; edited 1 time in total

pamcclamrock is on this forum, so you could PM him for the pre-gnocl versions, which were actually made after I requested some gnocl versions - so I know the guy is very helpful!_________________Akita Linux, VLC-GTK, Pup Search, Pup File Search

I was in the process of learning tcl/tk and after pouring over several examples, realized a major portion of its power lies in the ability to load modules on the fly (it is still excellent even without dynamic loading).
needed for tcl-gtk-0.5, hv3, filerunner, brlcad and many other top tk apps

This made me rethink the mcb direction - what difference would it make to uses shared versions of the tiny libs?
... my gut check says it could be an overall win, but I would probably end up wanting to have an xz compress squashfs image icluded in the kernel's initramfs so that the entire thing does not get uncompressed with the kernel, but then I would also need bootstrap code to mount the squashfs image on root

so, knowing I would need code that included "squashfs" and "#include <sys/mount.h>" ... I googled it to see what it turned up ... lo and behold I got something that even included unionfs - awesome

Using x11vnc with the Xvesa build with uclibc/tinyX11 seems to fail if Xvesa is missing XTEST extension (and MITSHM if you do not start x11vnc with -noshm switch). If Xvesa is build with -DXTEST and -DMITSHM x11vnc works ok but it seems that the Xvesa is unstable with MITSHM (freeze). So attached a Xvesa with -DXTEST...seems stable after running a couple of days with it.

I don't know if I've got the wrong end of the stick here, but I connect this with a post I made the other day, and wonder if there's something useful here with freenx?

I know the feeling - would be nice to have a department full of developers to whom you could give your ideas and get the job done...and then...maybe not...might take the fun out of it.
I tried to do a version of wish with the load enabled, as I hoped it was a loading tech and not related to static/dynamic builds. I did not succeed the build though...but still think/hope that there are a way out to link static build external libs...?

Aitch: I will look into that - thanks!

Meanwhile I have spend some time trying to build gqview with uclibc/tinyX but seems to need a lot of patching (probably of the gdk/gtk/pixbuf-libs). So remembered trying out danpei some time ago and did a quick build test: Builds nicely and honestly: Much more clean interface than gqview in my opinion. So attached static build of danpei.

As alternative to learn tcl/tk we could backport gtkdialog to gtk1. I did a first try and got a static build that actually run some of the scripts correctly. Used gtkdialog-0.56 as a starting point and uclibc/tinyX11 and just deactivated what was in the way of functions and defines during compile and linking...

All in all it might not be too difficult - the initial linker errors below - not a long-long list I think:

Meanwhile I have spend some time trying to build gqview with uclibc/tinyX but seems to need a lot of patching (probably of the gdk/gtk/pixbuf-libs). So remembered trying out danpei some time ago and did a quick build test: Builds nicely and honestly: Much more clean interface than gqview in my opinion. So attached static build of danpei.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum