pUPnGO - 6Mb ISO - Basic Building Block Puplet

[jpeps]

Did a ssl version of dillo also but could not read gmail anyway so removed it again. Have fun with these 4in1 must have gtk1 apps.

I wonder if it is just a user agent issue... If not, there is sylpheed-1.0.x

I wish Google would commit to an api (not just mail)

hmm...thought that was working after setting the cookies to ALLOW. Strange that links has no problem.

[goingnuts]

PANZERKOPF: I will check BB hexdump out.
technosaurus: Could be fun to make that 4-5Mb GUI version. If one could load save-sfs and module-sfs from there, some moving around of stuff needed in both initramfs and main-system could be avoided...
Sylpheed might be a solution for mail-client but if dillo could do it...

Might be worth looking deeper in dillos dpi-system - not only to fix https but could extent them to call scripts and do a lot of other stuff...

jpeps: I did allow the cookies but with no luck...might not have done it right. Some hints shows up searching for "dillo google gmail" but could not make it work. I have a static build of links2 with ssl and it just works - as you say - but its double in size compared to dillo - so it would be cool to make dillo work.

Further "progress" with gtk1:

Ran into problems today with my version of uclibc (0.9.27) as it only supports rint in shared builds and no support for rintf. The rint/rintf is needed for mtpaint (and dillo but only rint) so spend some time trying to crawl up to uClibc-0.9.29 but that broke to many of my build scripts.
The solution was to replace the libm.a from uClibc-0.9.27 with the new builded one from uClibc-0.9.29. Then everything works.

So made a static build of mtpaint and did a few test to evaluate resource usage:
mtpaint-3.21 (gtk2) std p412 using shared libs:
Total size (including needed libs): 9367K
ps/top reports use of 15860K after loading a 5K png.

mtpaint-3.21 (gtk1) static build (uclibc/tinyX11):
Total size: 1516K
ps/top reports use of 4144K after loading a 5K png.
If included in a mcb ps/top reports use of 4848K after loading a 5K png.

So although the static builds seems large in size on disk - they seem so use less resources when running...although I compare gtk2 with gtk1 builds.

[jpeps]

jpeps: I did allow the cookies but with no luck...might not have done it right. Some hints shows up searching for "dillo google gmail" but could not make it work. I have a static build of links2 with ssl and it just works - as you say - but its double in size compared to dillo - so it would be cool to make dillo work.

Just compiled dillo-3.1.0 with fltk-1.3. and got into gmail.

cookiesrc:

Code: Select all

DEFAULT DENY
mail.google.com ACCEPT
accounts.google.com ACCEPT

[PANZERKOPF]

Sylpheed might be a solution for mail-client but if dillo could do it...

Another solution:
Busybox has "popmaildir" and "sendmail". Popmaildir can use openssl as helper.

[goingnuts]

jpeps: I can confirm you findings - dillo3 gets into Gmail. If I afterwards start dillo-0.8.6 (without logging out of Gmail inside dillo 3) I also get into Gmail but cant do anything in there (no respond clicking links and no way to read emails etc.). Guess the old https.filter.dpi needs to be recoded...
Thats beyond my skills though so might just stick with links2.

PANZERKOPF: Might be worth a try - a CLI email client based on BB only...maybe with a dialog/Xdialog wrapper?

[jpeps]

jpeps: I can confirm you findings - dillo3 gets into Gmail. If I afterwards start dillo-0.8.6 (without logging out of Gmail inside dillo 3) I also get into Gmail but cant do anything in there (no respond clicking links and no way to read emails etc.). Guess the old https.filter.dpi needs to be recoded...
Thats beyond my skills though so might just stick with links2.

I'm not having a problem with it but I compiled in Slacko along with fltk (also compiled in Slacko). That might be the issue.

[goingnuts]

jpeps: Thanks for tests and guidelines! Made a static build of sylpheed but it ends up in 2,2Mb with ssl-support. Works great though...fast and problem free download of mails from gmail and sends mail too without complains. Followed instructions from here.

Also tried to compile dillo-0.8.6 with all stuff in dpi coming from dillo3 but no luck - getting all kinds of compile errors (was kind of expected...).

I will try to follow the idea of having a dialog/Xdialog wrapper for a CLI mail client...

[technosaurus]

The dillo *.dpi "plugins" each have main() ... meaning that they could be symlinks to an mcb.
I think you may be able to shrink sylpheed-ssl by disabling some algorithms in the Ssl libs, but I'm not sure which ones are necessary.
The other biggy for gtk1 would be gtkserver... Would allow gtkdialog type GUIs (amigo has a couple of alternates archived also - greq & ??)
I seem to have lost my patches for dialog/Xdialog that accept each others syntax, but shouldn't be too hard to recreate if you need them.

[goingnuts]

The dillo *.dpi "plugins" each have main() ... meaning that they could be symlinks to an mcb....

Already done that - they are inside the mcb_gtk...

For the few that have downloaded the mcb_gtk please note that symlink dpid to mcb_gtk is missing in the archive. I have also seen some crash of Xvesa using the build. Not related to the version of Xvesa used but seems more to be related to loss of window focus...or a window manager thing: start dillo - if mouse pointer is hold over jwm task bar for the dillo window X crashes
So use it for fun and inspiration only until more stable bins can be made.

[technosaurus]

Hmm, dillo could even be used as a central interface using busybox httpd and some cgi shell scripts. I started playing with it about a year ago, but lost interest. A lot of the code is just bitrotting in bashbox at the moment, but is really simple actually ...just uses standard <form>s . I was going to build an internet connection wizard with it, but as it turns out there are a lot of little nuances to net setup, so I never finished.

Need to figure out what form methods are supported by the cli browsers, so it could be universal though.

I know it would be 1 extra daemon process, but having a working server can open the door for a lot of other stuff... I could even port a lot of gtkdialog apps, if that is something people are interested in (an audio/video converter would be pretty easy using my woo-ff tool as a template)

Any thoughts on this? Maybe better to wait and work out kinks in the mcb build toolchain first?

One app that I would be willing to spend extra time implementing if someone could help out with dynamic dns part is is an audio/video/content communication app using only httpd and ffmpeg (udp).

[PANZERKOPF]

Thats beyond my skills though so might just stick with links2.

Time to time I was searching lightweight graphical browser and stick with Links2. It has no alternatives (IMHO), though, there is another fork of Links2: LinksH ("Links Hacked"). It has some improvements:
http://xray.sai.msu.ru/~karpov/links-hacked/

PANZERKOPF: Might be worth a try - a CLI email client based on BB only...maybe with a dialog/Xdialog wrapper?[/quote]
If we create wrapper, message editor, ssl wrapper (comes with openssl library) and some another needed tools, seems whole project will become bigger than one sylpheed binary

[technosaurus]

PANZERKOPF: Might be worth a try - a CLI email client based on BB only...maybe with a dialog/Xdialog wrapper?
If we create wrapper, message editor, ssl wrapper (comes with openssl library) and some another needed tools, seems whole project will become bigger than one sylpheed binary

not really - http://bashmail.sourceforge.net/
It does need some updating though, but this is kinda what I was talking about using busybox httpd with cgi shell scripts

[PANZERKOPF]

this is kinda what I was talking about using busybox httpd with cgi shell scripts

Interesting idea. We can create main html page with forms (each form sends arguments to corresponding CGI script) and connect to this page with browser: http://127.0.0.1:some_free_port
In that manner we will get a control panel for manipulate something on local or remote host.
Aslo, such GUI has no dependencies except browser and small http daemon like busybox httpd.

[goingnuts]

I did play a bit with thttpd and an additional fileupload cgi. I did post a package some time ago. Quite small and handy...
Most CLI web browsers support basic form send as far as i have seen so creating a web-based wizard/configuration tool might be the way forward.

For the tiny mail-client there seems to be some to choose between out there - haven't dug onto that yet.

I have been trying to track down the gtk/x-crash problem but no solution yet. If I do a full Xlib toolchain (with uclibc) everything is OK but it adds 400K to each static bin. Problem seems to be that the tinyX-gtk do not set WM hints for window or icon name correctly and that could origin in all three base libs (tinyX/glib/gtk). And jwm just don't like unnamed windows when minimizing and afterwards gets focus.

Its really more complex to troubleshoot a widget like this

I would like to get this settled before moving forward with the gtk mcbs.

[technosaurus]

I am working on a couple of things in Wary right now, but does it change if there is an image with the same name as the mcb symlink in the imagepath? ... fonts kept giving me trouble - I may do a rebuild with /etc/fonts as the FONTDIR so that I can simplify the filesystem a bit

Maybe strace can help?

also here is my scratchpaper on doing httpd with cgi

Code: Select all

#need to add some backslashed quotes in case of multiword inputs

htmlchecheckbox() {  # generate a checkbox $1=name followed by a value
   echo "<input type=checkbox name=$1 value=$2 />$2"
}

htmlcombobox() { # generate a dropdown list $1=name followed by a list of values
   echo "<select name=${1:-combobox}>"
   shift
   for x in $@ do echo "<option value=$1>$1</option>"; done
   echo "</select>"
}

htmldeflist() { # word1 "the definition" word2 "....
   echo "<dl>"
   while $1 do
      echo "<dt>$1</dt><dd>$2</dd>"
      shift 2
   done
   echo "</dl>"
}

htmlentry() { # generate entry box $1=name ...default value?
   echo "<input type=text name=${1:-entry} />"
}

htmlformbegin() {
   echo "<form action=cgi-bin/ashbox.cgi method=get>"
}

htmlformend() {
   echo "</form>"
}

htmlframebegin() {
   echo "<fieldset><legend>${1:-frame}</legend>"
}

htmlframeend() {
   echo "</fieldset>"
}

htmlheader() { #$1=title $2=stylesheet $3=background image
   echo "<html><head><title>${1:-PleaseAddTitle}</title><link rel="stylesheet" href=${2:-stylsheet.css}></head><body alink=#ff0000 background=${3:-background.jpg} bgcolor=#ffffff link=#0000ff text=#000000 vlink=#ff00ff><img src=${3:-background.jpg} alt=${3:-background.jpg} id=bg>"
}

htmlpassword() { # generate password box $1=name
   echo "<input type=password name=${1:-pwd} />"
}

htmlradiobutton() { # generate radio buttons $1=name followed by a value
   echo "<input type=radio name=${2:-radio} value=$1 />$1";done
}

htmlsubmitbuttonimage() { #todo

}

htmlsubmitbuttontext() {
   echo "<input type=submit value=$1 />"
}

htmltextarea() { # generate a text area $1rows high by $2 cols wide followed by default text
ROWS=$1;COLS=$2;shift 2         #Note row and column can also be %
echo "<textarea rows=$ROWS cols=$COLS>$@</textarea>"
}

htmltext() { # $@ is text
echo "<pre>$@</pre>" |tr "\n" "\\" |sed 's/\\/"<br>"/g' #need to check & improve this
}

htmlparsequerystring() { #parse the query string to get VAR (VAR==$1) from var=param (var==$2)
$1=`echo "$QUERY_STRING" | sed -n 's/^.*$2=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"` 
#may need an eval of $1 ???
}

htmlimage() { #show an image $1=image $2=hyperlink $3=alt_text $4=height $5=width....
echo "<img src=$1 height=$4 width=$5 />"  #todo
}

[goingnuts]

technosaurus: Thanks for the help and hints!

The problem with setting window name in the gtk app builds with tinyX11/uclibc seems solved!

Even though compiled with --disable-nls gdk/gtk insist on using Xlib lc-family and friends (and its a huge family with a number of friends!).

By modifying source of gdkwindow.c (function "gdk_window_new") to use XSetWMName/XSetWMIconName instead of XmbSetWMProperties (who is the lc-demanding function) everything works ok.

Maybe a patch to jwm to accept windows without names might be a nice feature to do in the future...is it a bug:?:

Attached and updated mcb_gtk containing Xdialog-2.3.1, dillo-0.8.6 (without ssl), emelfm-0.9.2, mp-3.3.13 and mtpaint-3.21 in one 2173K static bin (905K upxed)

Copy to /usr/bin and run "mcb_gtk --install".

As always errors and bugs are spotted after submission so use with caution!

[technosaurus]

It may be worth trying a newer version of jwm 2.1.0 was released in September and Joe has been extremely active upto and since then. (Note: at v530 the source grows substantially )

I also looked into the Xvesa/xvfb differences with possible solution:
move const KdCardFuncs vesaFuncs = { ... }
from vesainit.c to vesa.c
then merge vesainit.c and fbinit.c into a kdinit.c using the same mechanisms used in the mcb to select which function

Code: Select all

void InitCard (char *name){
    KdCardAttr	attr;
switch ( FIRST_FIVE(argv[0][0],argv[0][1],argv[0][2],argv[0][3],argv[0][4]) ) {
	case FIRST_FIVE('x','v','f','b','d') : KdCardInfoAdd (&fbdevFuncs, &attr, 0);
	case FIRST_FIVE('X,'v','e','s','a') : KdCardInfoAdd((KdCardFuncs *) &vesaFuncs, &attr, 0);
	default : return 1;
}

void InitOutput (ScreenInfo *pScreenInfo, int argc, char **argv){
    KdInitOutput (pScreenInfo, argc, argv);
}

void InitInput (int argc, char **argv){
KdInitInput(&LinuxMouseFuncs, &LinuxKeyboardFuncs);
//touchscreen support goes here
}

int ddxProcessArgument (int argc, char **argv, int i){
int	ret;    
if (!(ret = vesaProcessArgument (argc, argv, i)))
	ret = KdProcessArgument(argc, argv, i);
return ret;
}

btw this is what I currently have for checking the mcb name:

Code: Select all

#include "mcb.h"
#define FIRST_FIVE(x1,x2,x3,x4,x5)	(((((((((x5)<<8)|(x4))<<8)|(x3))<<8)|(x2))<<8)|(x1))

int main( int argc, char** argv ){
argv[0]=basename(argv[0]);

switch ( FIRST_FIVE(argv[0][0],argv[0][1],argv[0][2],argv[0][3],argv[0][4]) ) {

#ifdef MCB_DILLO
	case FIRST_FIVE('d','i','l','l','o')   :
		return(dillo_main(argc,argv);
#endif

#ifdef MCB_EMELFM
	case FIRST_FIVE('e','m','e','l','f')   :
		return(emelfm_main(argc,argv);
#endif
...

it works but I get this on newer compilers:
warning: assignment makes pointer from integer without a cast

currently writing a wrapper for gcc that will handle nuances like:
always includes the *FLAGS you want
never includes the *FLAGS you dont
future support for:
linking the objects inside the static libs directly by using ar -x to extract them to a dir and then replacing -lsomelib with lsomelib/*.o (needed for fvisibility=hidden)
selectability of C/C++ library (musl, uclibc and uclibc++)

Edit: I posted a mixed shared/static build of mupdf here:
http://www.murga-linux.com/puppy/viewtopic.php?t=61922
needs only X11, Xext, freetype, jpeg and png (patches attached here)

[goingnuts]

It may be worth trying a newer version of jwm 2.1.0 was released in September and Joe has been extremely active upto and since then. (Note: at v530 the source grows substantially )

I also looked into the Xvesa/xvfb differences with possible solution:
move const KdCardFuncs vesaFuncs = { ... }
from vesainit.c to vesa.c
then merge vesainit.c and fbinit.c into a kdinit.c using the same mechanisms used in the mcb to select which function

Admitted...haven't checked the development of jwm for a long time but did a quick test of the current 547. The no windowname-crash is fixed but new things popped up: Desktop totally covered if background set (ROX is running behind but invisible), respecting GNOME hint removed so "desklaunch" unusable now (spawns windows for every icon) and not on every desktop, still STICKY windows are shown in pager and apps like root-tail have no chance showing anything. So although a lot of new wanted features are taking care of it still seems to be a moving target...

Cool solution with the Xvesa/Xfbdev! I´ll check it out. Thanks!

I have done some initial test of diethotplug-0.4 to replace udevd and most of the pupevent-scripts. Eliminate the need for all the rules in /etc/udev and gives a less complex file-structure. Seems very fast and also seems to find and load most of the modules. Attached - place in /sbin...

[technosaurus]

excellent - it appeared to build on Wary's 2.6.32 kernel also (btw it appears to be kernel version dependent - I assume you were using the 4.1 kernel?)

[goingnuts]

excellent - it appeared to build on Wary's 2.6.32 kernel also (btw it appears to be kernel version dependent - I assume you were using the 4.1 kernel?)

Not sure about the kernel dependency...Yes build on P412 (kernel 2.6.25.16). Tested a little further: Finds non-active netcards, usb hotplug works and also find 3-5 more things than if using udevd...
Not sure about loading of firmware - might not work for that...
Also it seems to work without the content in /ect/modules.