pUPnGO - 6Mb ISO - Basic Building Block Puplet
jwm-2.0.1 static build compiled with uclibc and X11tiny
configured with: --disable-confirm --disable-png --disable-jpeg --disable-xft --disable-fribidi --disable-xinerama --disable-xrender
with the "patch to jwm that remove sticky windows from pager" from here
Shipped as 125k upxed bin. Unpacked 266K - running using only 580K.
Same configuration but with dynamic linking is 124K and use 2636K.
Only bug so far is the time - showing time 2 hours behind - I have no clue to fix that other than setting system time 2 hours in the future Setting timezone to GMT0 also works.
Update 160911: Attached static build of rxvt-2.6.4 169K unpacked - shipped as 85K upxed bin. If ps tells the truth normal rxvt uses 2640K and this static build uses 368K running.
Update 190911: Finally got png to work so ship a build with everything but xft and fribidi enabled (confirm icons png shape xinerama xpm xrender). Unpacked size 413K shipped as upxed bin 204K.
with the "patch to jwm that remove sticky windows from pager" from here
Shipped as 125k upxed bin. Unpacked 266K - running using only 580K.
Same configuration but with dynamic linking is 124K and use 2636K.
Only bug so far is the time - showing time 2 hours behind - I have no clue to fix that other than setting system time 2 hours in the future Setting timezone to GMT0 also works.
Update 160911: Attached static build of rxvt-2.6.4 169K unpacked - shipped as 85K upxed bin. If ps tells the truth normal rxvt uses 2640K and this static build uses 368K running.
Update 190911: Finally got png to work so ship a build with everything but xft and fribidi enabled (confirm icons png shape xinerama xpm xrender). Unpacked size 413K shipped as upxed bin 204K.
- Attachments
-
- rxvt-2.6.4_static.tar.gz
- rxvt-2.6.4 static build compiled with uclibc and X11tiny.
- (83.5 KiB) Downloaded 268 times
-
- jwm-2.0.1_static.tar.gz
- jwm-2.0.1 static build compiled with uclibc and X11tiny.
- (123.35 KiB) Downloaded 317 times
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I made a partially-static compile of dillo3 here:
http://murga-linux.com/puppy/viewtopic. ... 263#564263
(no libstdc++ or fltk-1.3 dependency, just X11, Xft and image libs)
... also I posted my uclibc++ and fltk configs a few posts later
anyhow, it ended up being smaller than the shared libstdc++ build, so it may be useful for using c++ apps (and pretty easy, no extra toolchain required, since it includes a wrapper ... which I was also able to modify to keep out unwanted optimizations flags like -O3 etc...)
btw what version of tinyx11 are you using? amigo's? any patches?
http://murga-linux.com/puppy/viewtopic. ... 263#564263
(no libstdc++ or fltk-1.3 dependency, just X11, Xft and image libs)
... also I posted my uclibc++ and fltk configs a few posts later
anyhow, it ended up being smaller than the shared libstdc++ build, so it may be useful for using c++ apps (and pretty easy, no extra toolchain required, since it includes a wrapper ... which I was also able to modify to keep out unwanted optimizations flags like -O3 etc...)
btw what version of tinyx11 are you using? amigo's? any patches?
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Tested you minimal dillo in P412 - was missing libjpeg.so.7 - but symlink to libjpeg.so.62.0.0 made him start. Looked nice - but crashed trying to go to 'http://goingnuts.dk/linux.asp' with a Segmentation fault
Anyway - would it be possible to do full static build using tinyX11?
I am using amigos tinyX11 - but have added Xt, Xmu, SM, ICE and Xinerama (and added a couple of missing functions to tinyX11) to do this jwm. Attached build of Patriots JWM 2.0.1 with Enhancements and Fixes + the "no-sticky-in-pager-patch", 419K unpacked - shipped as 207K upxed bin. Only excluded fribidi and xft. I think this version of jwm is even better than the official 500...
Update 210911: Found a missing xfunction in the first attached bin that made a defect upper right corner of client windows - sorry. I have uploaded a new build with this fixed.
Anyway - would it be possible to do full static build using tinyX11?
I am using amigos tinyX11 - but have added Xt, Xmu, SM, ICE and Xinerama (and added a couple of missing functions to tinyX11) to do this jwm. Attached build of Patriots JWM 2.0.1 with Enhancements and Fixes + the "no-sticky-in-pager-patch", 419K unpacked - shipped as 207K upxed bin. Only excluded fribidi and xft. I think this version of jwm is even better than the official 500...
Update 210911: Found a missing xfunction in the first attached bin that made a defect upper right corner of client windows - sorry. I have uploaded a new build with this fixed.
Last edited by goingnuts on Wed 21 Sep 2011, 17:56, edited 2 times in total.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
Re:dillo, If it wouldn't be too much trouble to package up your toolchain (any format will do), I can build a compatible minimal uclibc++ toolchain (or 2 or 3 ... sometimes minimal is too minimal ... for example, exceptions and rtti add a lot of bloat, but some programs use exceptions extensively --- geany required a lot of commenting out to get it to build) I posted my .config and other config options in the dillo thread a couple of posts later using
http://git.uclibc.org/uClibc++/snapshot ... er.tar.bz2
http://www.fltk.org/software.php?VERSIO ... 38.tar.bz2
EDIT btw the uclibc++ wrapper is a great template for eliminating the unwanted CFLAGS that upstream imposes on all builds (-O3 can be set to -Os, -finline* can be removed or replaced with -finline-small-functions etc...)
I do a lot of compiling and get a little annoyed with the stream of output clobbering my commands (I know they are still in history but I like to be able to scroll through them still) I also like sometimes having a history file that is not limited to a certain number of lines, so I can check for errors or special -D* defines or CFLAGS passed during compilation. I _had_ been using an Xdialog tailbox but have switched to rxvt + dialog for portability in my pupngo base systems with only X
there is much room for improvement like:
using tee to redirect to file while keeping stderr (if you just remove 2>>/tmp/cmdhist it will stay local but not be logged)
option to not show the output at all or only certain parts etc...
The basic idea here is how terminal emulators work, but missing stdin
(I got the idea while trying to learn to port a terminal to xcb)
http://git.uclibc.org/uClibc++/snapshot ... er.tar.bz2
http://www.fltk.org/software.php?VERSIO ... 38.tar.bz2
EDIT btw the uclibc++ wrapper is a great template for eliminating the unwanted CFLAGS that upstream imposes on all builds (-O3 can be set to -Os, -finline* can be removed or replaced with -finline-small-functions etc...)
I do a lot of compiling and get a little annoyed with the stream of output clobbering my commands (I know they are still in history but I like to be able to scroll through them still) I also like sometimes having a history file that is not limited to a certain number of lines, so I can check for errors or special -D* defines or CFLAGS passed during compilation. I _had_ been using an Xdialog tailbox but have switched to rxvt + dialog for portability in my pupngo base systems with only X
Code: Select all
#!/bin/sh
touch /tmp/cmdhist
rxvt -e dialog --tailbox /tmp/cmdhist 0 0 &
while read CMDS; do
echo " # ${CMDS}" >>/tmp/cmdhist
eval ${CMDS} 2>>/tmp/cmdhist >>/tmp/cmdhist
done
using tee to redirect to file while keeping stderr (if you just remove 2>>/tmp/cmdhist it will stay local but not be logged)
option to not show the output at all or only certain parts etc...
The basic idea here is how terminal emulators work, but missing stdin
(I got the idea while trying to learn to port a terminal to xcb)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
I will try to make a package containing the uclibc used + my present tinyX11 source. It might take a day or two though.
Succeeded today to build links-2.3pre1 static - at the moment without ssl - but ended up in a 2400k bin (removed every language but english). Using 3800K running. Always liked links-2.3pre1 as it provides images, partly support javascript and build with ssl gives access to Gmail and other internet based services...
Succeeded today to build links-2.3pre1 static - at the moment without ssl - but ended up in a 2400k bin (removed every language but english). Using 3800K running. Always liked links-2.3pre1 as it provides images, partly support javascript and build with ssl gives access to Gmail and other internet based services...
-
- Posts: 282
- Joined: Wed 16 Dec 2009, 21:38
- Location: Earth
IMHO Links is best browser for tiny systems. It can work in any mode: text console,goingnuts wrote: Succeeded today to build links-2.3pre1
framebufer console, DirectFB, X. Current release: 2.3
Another fork of links named "Hacked Links":
http://xray.sai.msu.ru/~karpov/links-hacked/
SUUM CUIQUE.
Elinks here!PANZERKOPF wrote:IMHO Links is best browser for tiny systems.goingnuts wrote: Succeeded today to build links-2.3pre1
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
sounds great, and yet another reason for me to clean up Xvesa for a standalone build, and eventually part of a multicall binary of the X essentials
I have worked through this idea in the past and boiled it down to these basic steps:
I have worked through this idea in the past and boiled it down to these basic steps:
- rename each program's main(...) to main_program(...)
use multicall code for the real main(...) from either busybox, embutils, git, wireless-tools, bzip2, gzip or xz (there may be others)
while ([ $errors]) do build && debug ;done
- being able to fork() main_jwm(...) as soon as possible (similar to waitforx)
reduced footprint with static builds
ability to refactor "commonish" code for further footprint reduction
ability to integrate common tools into the gui (like a terminal button similar to showdesktop, or even swallowed in an autohide tray like yakuake)
- Xvesa uses the main from dix/main.c (I think)
lots of problems with "multiple definition of *"
its better to build the whole program at once using all of the *.c files (instead of precompiled *.o files) with the -D* -I* -L* flags etc from a separate standalone build, but causes more multiple definitions due to static declarations essentially becoming global (even moreso if -fwhole-program is used) ... still its probably better to know about them and cause a build error, than to try tracking it down after
I got the -D* -I* and -L* flags etc by piping make through | tr " " "\n" |sort -u
I used the external history file I posted a few posts ago to check that I didn't miss something.
Xvesa's source code is really scattered and difficult to follow
I never considered the effects of mixing C and C++ code
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Tiny front end for minimp3: wmmp3 is a dockapp to control mpg123. I have patched minimp3 to accept "-q" to be quiet when called by wmmp3. Main playlist/dirs and app-name to run for player is set in /root/.wmmp3. Example included in attached package.
So either symlink minimp3 with mpg123 or change the line in /root/.wmmp3 "mpg123 = /usr/bin/mpg123" to "mpg123 = /usr/bin/minimp3"
Compiled wmmp3 (144K) and minimp3 (40K) static.
You can make an additional autohide tray in jwm and swallow wmmp3 - add the following to .jwmrc-tray:
So either symlink minimp3 with mpg123 or change the line in /root/.wmmp3 "mpg123 = /usr/bin/mpg123" to "mpg123 = /usr/bin/minimp3"
Compiled wmmp3 (144K) and minimp3 (40K) static.
You can make an additional autohide tray in jwm and swallow wmmp3 - add the following to .jwmrc-tray:
Code: Select all
<Tray autohide="true" layout="vertical" insert="left" x="-1" y="600" border="2" height="65" >
<Swallow name="wmmp3" width="64">
wmmp3
</Swallow>
</Tray>
- Attachments
-
- snap0001.png
- Running wmmp3
- (7.61 KiB) Downloaded 762 times
-
- wmmp3.tar.gz
- wmmp3+minimp3 patched static builds
- (94.34 KiB) Downloaded 237 times
Last edited by goingnuts on Sun 25 Sep 2011, 05:44, edited 1 time in total.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
here is a proof of concept for making a multicall Xapp binary
it just includes jwm and st ... went fairly smoothly
to add another just follow the templates in "build" and main.c (renaming each app's main() to <app>_main())
it just includes jwm and st ... went fairly smoothly
to add another just follow the templates in "build" and main.c (renaming each app's main() to <app>_main())
- Attachments
-
- Xapps.tar.gz
- binary and links
- (104.32 KiB) Downloaded 217 times
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
COOL! Thanks!technosaurus wrote:here is a proof of concept for making a multicall Xapp binary
it just includes jwm and st ... went fairly smoothly
to add another just follow the templates in "build" and main.c (renaming each app's main() to <app>_main())
Tried to do a bundle of minimp3 and wmmp3: Compiled ok and the saving is approx. 8k (from 40+144 to 176). But there might be a problem with wmmp3 calling minimp3 (when they both are in the same multicall bin) - wmmp3 is forking minipm3 and checking for pid of the fork before playing anything - guess pid might be equal for wmmp3 and minimp3 when launched from the bundle??
Definitely has some interesting potential - imaging Xfm+Xpaint+Xeditor+Xinit+jwm+rxvt etc in one static bin...
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I've replaced st with rxvt and added getgui, made it a little more configurable (main.c is generated now)
Currently it is configured for shared libs... will test as static once I get all the necessary apps in there ... any recommendations ... perhaps dialog compiled against xcurses instead of getgui or something else? Mupdf requires the same libs as jwm (+450kb), which panel applets?
I made a patch a while back to add minimp3 to busybox
but can you just fork() minimp3_main(...) instead of fork exec?
Todo add ifdefs to each main so that apps can be reconfigured and built standalone.
Edit: my Droid changed ifdefs to ideas
Currently it is configured for shared libs... will test as static once I get all the necessary apps in there ... any recommendations ... perhaps dialog compiled against xcurses instead of getgui or something else? Mupdf requires the same libs as jwm (+450kb), which panel applets?
I made a patch a while back to add minimp3 to busybox
but can you just fork() minimp3_main(...) instead of fork exec?
Todo add ifdefs to each main so that apps can be reconfigured and built standalone.
Edit: my Droid changed ifdefs to ideas
- Attachments
-
- build.tar.gz
- binary and symlinks for rxvt, getgui and jwm
- (146.06 KiB) Downloaded 273 times
Last edited by technosaurus on Sun 25 Sep 2011, 23:01, edited 2 times in total.
Changed wmmp3 to use execlp instead of execl and it seems to work (I don't know what I am doing - just T&E). The advantage is that minimp3 still works from CLI, wmmp3 still works with mpg123 if needed and the total size of bin is reduced - compared to build-in minimp3 in wmmp3.
Attached the bundle and image showing wmmp3 running in a second tray with autohide - very convenient and could be expanded with other wmapplets (mixer, diskmonitor etc).
Attached the bundle and image showing wmmp3 running in a second tray with autohide - very convenient and could be expanded with other wmapplets (mixer, diskmonitor etc).
- Attachments
-
- snap0002.png
- (15.47 KiB) Downloaded 710 times
-
- Mp3bundle250911.tar.gz
- Mp3bundle (wmmp3+minimp3 multicall binary)
- (84.03 KiB) Downloaded 248 times
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I wrote some helpers for static binaries that you may find useful
write1 - print string to stdout (saves 7-20kb over printf)
write2 - print string to stderr (saves 7-20kb over printf)
fork_exec - fork and exec a binary
fork_exec_wait - fork and exec a binary and wait for it to return
shift_n - shift an array by n (useful for something like busybox app <args> because you can shift_n(1,argv) and then fork_exec(argv))
wait_pids - waits for a list of pids to finish
swrl - just puts a swirling line on the screen
the attachment uses functions, but if you only use it once a #define may make more sense
etc...
Edit: oops I put wait_pids in there, it is a program, not a function
I do however find it extremely useful is init scripts, and have been meaning to send it to the busybox mail list.
the shell builtin "wait" waits for _all_ pids of children, but we may fork several different trees in an init script and only need to wait for a few of them before continuing with something ... it is for improved boot speed - maybe other uses as well when speed is necessary
swrl is the same code, but shows that we are waiting
write1 - print string to stdout (saves 7-20kb over printf)
write2 - print string to stderr (saves 7-20kb over printf)
fork_exec - fork and exec a binary
fork_exec_wait - fork and exec a binary and wait for it to return
shift_n - shift an array by n (useful for something like busybox app <args> because you can shift_n(1,argv) and then fork_exec(argv))
wait_pids - waits for a list of pids to finish
swrl - just puts a swirling line on the screen
the attachment uses functions, but if you only use it once a #define may make more sense
Code: Select all
#define write2(s) write(2, s, strlen(s));
#define write1(s) write(1, s, strlen(s));
#define fork_exec_wait(a) ({int s,p;if((p=fork())==0){execvp(a[0],a);}else{while(wait(&s)!= p);}})
#define shift_n(i,a) ({ int j=0;while(a[j] != NULL){a[j]=a[j+i];j++;}})
Edit: oops I put wait_pids in there, it is a program, not a function
I do however find it extremely useful is init scripts, and have been meaning to send it to the busybox mail list.
the shell builtin "wait" waits for _all_ pids of children, but we may fork several different trees in an init script and only need to wait for a few of them before continuing with something ... it is for improved boot speed - maybe other uses as well when speed is necessary
swrl is the same code, but shows that we are waiting
- Attachments
-
- libstatic.tar.gz
- (1.67 KiB) Downloaded 238 times
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Thank you for sharing all this! Its really a nice new tool. Tried to add an other wmapplet to the MP3bundle: Static compiled each program was 40+144+131=315K. The multicall binary was 197K. So the last added program only added extra 21K which is close to the size of that program linked dynamic. So for the static build it seems that the more common libs the better the effect on size reduction. And according to ps the mem usage is like if running the single program alone (I think...)
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
Your welcome.
I currently have jwm, rxvt, getgui, xfm and started on xpaint with plans for xedit, mupdf and various panel applets. I am using wary with its toolchain & shared libs though for initial testing, so it may need patching for uclibc (or musl libc) and tinyx11 still. We will see how it goes.
I currently have jwm, rxvt, getgui, xfm and started on xpaint with plans for xedit, mupdf and various panel applets. I am using wary with its toolchain & shared libs though for initial testing, so it may need patching for uclibc (or musl libc) and tinyx11 still. We will see how it goes.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
-
- Posts: 282
- Joined: Wed 16 Dec 2009, 21:38
- Location: Earth
Xfm is great FM but latest one has a bug (cannot open directory). Old Xfm hasn't thattechnosaurus wrote:Your welcome.
I currently have jwm, rxvt, getgui, xfm and started on xpaint with plans for xedit, mupdf and various panel applets.
bug but mouse wheel is unsupported. (this based on my personal experience. Maybe I am wrong?)
Because we like tiny and fast tools, let me ask:
Why not gtk1?
It is fast and small but unfortunately forgotten toolkit. We have lot of apps based on it, even new versions still support it (like MtPaint, MPlayer). IMHO it is better than Athena.
I have build a small desktop system based on Xlibs and Gtk1 - runs very fast even
on very old hardware.
SUUM CUIQUE.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I've already gone there (Xpaint bumped up the size ~= gtk1+deps), the Xaw based tools end up implementing the gtk functionalities in their own way and it gets bloated fast.
I have been playing with Endeavor Mark II (gtk1 based) and wow! lots of potential ... once I finally got it going. It has quite a few builtin tools (file manager, image viewer with slideshow, archiver, recycle bin, hex editor, system monitor, dialog, splash tool, ... and _good_ documentation to boot) I didn't realize it had so much or I probably wouldn't have even bothered. I will probably settle on a choice of emelfm, gentoo or xfm instead, but I am going to archive a copy for posterity.
text editor - minimum profit 3.x
mail - sylpheed 1.x
browser - dillo-0.8.6x
paint - mtpaint
and more from here:
http://wiki.debian.org/GTK+_1.2_leftovers
BTW do you have a patch collection for the ones you have built?
I have been playing with Endeavor Mark II (gtk1 based) and wow! lots of potential ... once I finally got it going. It has quite a few builtin tools (file manager, image viewer with slideshow, archiver, recycle bin, hex editor, system monitor, dialog, splash tool, ... and _good_ documentation to boot) I didn't realize it had so much or I probably wouldn't have even bothered. I will probably settle on a choice of emelfm, gentoo or xfm instead, but I am going to archive a copy for posterity.
text editor - minimum profit 3.x
mail - sylpheed 1.x
browser - dillo-0.8.6x
paint - mtpaint
and more from here:
http://wiki.debian.org/GTK+_1.2_leftovers
BTW do you have a patch collection for the ones you have built?
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Tried to make pupngo a little smaller: Created a multicall bin containing the below apps + added an info-text and installer to the main.c:
Run "initrd_bundle install" as first thing in init.
I know some of this should be included via BB but...
Reduced the size from 226K to 137K - oh yeah! But just to get an estimate of the potential. Its a 40% reduction and if the more heavy stuff like ntfs-3g and e2fsck could be included too its worth the huge amount of time used to make it work...
What to do with multiple defs if they reside in a local lib needed to make an app (ex. merging fileutils and findutils both need their own version of getop.c)?
Code: Select all
#include <unistd.h>
int symlink(const char *path1, const char *path2);
if(!strcmp(basename(argv[0]), "initrd_bundle") && (argc == 1)) {
fputs("Multicall binary containing:\n", stdout);
fputs("disktype, elspci, fusermount, find\n", stdout);
fputs("setserial, hotplug2stdout, cddetect\n", stdout);
fputs("hotplug2stdout_notimeout\n",stdout);
}
if (!strcmp(basename(argv[0]), "initrd_bundle") && (argc > 1)) {
fputs("Installing symlinks...\n",stdout);
symlink("/bin/initrd_bundle", "/bin/disktype");
symlink("/bin/initrd_bundle", "/bin/elspci");
symlink("/bin/initrd_bundle", "/bin/fusermount");
symlink("/bin/initrd_bundle", "/usr/bin/find");
symlink("/bin/initrd_bundle", "/bin/setserial");
symlink("/bin/initrd_bundle", "/sbin/hotplug2stdout");
symlink("/bin/initrd_bundle", "/sbin/hotplug2stdout_notimeout");
symlink("/bin/initrd_bundle", "/sbin/cddetect");
}
I know some of this should be included via BB but...
Reduced the size from 226K to 137K - oh yeah! But just to get an estimate of the potential. Its a 40% reduction and if the more heavy stuff like ntfs-3g and e2fsck could be included too its worth the huge amount of time used to make it work...
What to do with multiple defs if they reside in a local lib needed to make an app (ex. merging fileutils and findutils both need their own version of getop.c)?
-
- Posts: 282
- Joined: Wed 16 Dec 2009, 21:38
- Location: Earth
For my lightweight desktop I am using:technosaurus wrote: text editor - minimum profit 3.x
mail - sylpheed 1.x
browser - dillo-0.8.6x
paint - mtpaint
WM - JWM
filemanager - ROX-Filer, MC.
texteditor - Beaver (or) and Gtkedit.
mail - Sylpheed 1.x
browser - Links and Opera (Newest Opera needs only Xlibs, no Qt or other toolkits)
Paint - mtpaint
Mediaplayer - MPlayer with gtk1 GUI enabled.
Audiomixer - Gamix.
PDF Viewer - XPDF
Image Viewer - GtkSee.
Also I have created several frontends and wrappers for viewing DOC,XLS,CHM, DjVu, Etc.... files.
I borrowed sources and patches from following storages:technosaurus wrote: BTW do you have a patch collection for the ones you have built?
Barry's site http://bkhome.org/sources (Kernels, Live scripts, Xorg,.....).
Amigo's site http://amigolinux.org (GTK1 Apps).
MPlayer and BusyBox are taken from their official sites.
Base system is built from Slackware sources.
P.S.
Sorry, my english is not perfect - maybe some my explanations are difficult
for understanding.
SUUM CUIQUE.