pUPnGO - 6Mb ISO - Basic Building Block Puplet
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I just grokked my jwm_menu_create code to work with 9menu, so now we have a window manager independent application menu.
http://www.murga-linux.com/puppy/viewtopic.php?t=77660
still todo? - gtkdialog1 version
http://www.murga-linux.com/puppy/viewtopic.php?t=77660
still todo? - gtkdialog1 version
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].
Hi all!
This is nice project and it´s great to follow the development.
Id like to "build" on this too but my expertise is on a level where adding stuff isn´t that simple without installer. pkg-inst_rmv.pet would help I guess, but how do I get to use it first?
I´ve been also wondering what it would take to use pUPnGO on a touch screen computer (7" and limited resources)? Referring to my skills, would you suggest a puplet created for this use or would it be worth trying with this one (anyone done it already?)
cheers
This is nice project and it´s great to follow the development.
Id like to "build" on this too but my expertise is on a level where adding stuff isn´t that simple without installer. pkg-inst_rmv.pet would help I guess, but how do I get to use it first?
I´ve been also wondering what it would take to use pUPnGO on a touch screen computer (7" and limited resources)? Referring to my skills, would you suggest a puplet created for this use or would it be worth trying with this one (anyone done it already?)
cheers
r4m0n3: pUPnGO does have the cli "pkginstall.sh" which will install tar.gz, tcz, pet, sfs, tgz, rpm, deb and gz.
So you could pack the pUPnGO iso with all the packages you need and install after boot.
Concerning the touch screen I have no clue - never worked with that - but sounds like real fun!
I have worked a bit further with xhippo. It turns out to be a quite mature. Fixed dnd for files with spaces (most of my mp3 files are with spaces...) and added icons. Went to last version 3.5...after that the author seems to be focused on potamus which is much more gtk2ish. Attached image of the present state of the modified xhippo and a static build. Pm me if you need the patches.
So you could pack the pUPnGO iso with all the packages you need and install after boot.
Concerning the touch screen I have no clue - never worked with that - but sounds like real fun!
I have worked a bit further with xhippo. It turns out to be a quite mature. Fixed dnd for files with spaces (most of my mp3 files are with spaces...) and added icons. Went to last version 3.5...after that the author seems to be focused on potamus which is much more gtk2ish. Attached image of the present state of the modified xhippo and a static build. Pm me if you need the patches.
- Attachments
-
- snap0001.png
- (17.65 KiB) Downloaded 1178 times
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
for touchscreen to work we would need to rebuild xvesa with tslib - There are patches @ my previous link
Edit: you'd also need an app like xvkbd or svkbd (would be a good idea to add these to an mcb build with a tslib patched xvesa)
NEWS: I have been working on simplifying the entire directory tree for speed, compatibility and size. Part of this just involved making redundant directories into symlinks (this speeds up, for example, PATH and LD_LIBRARY_PATH searchs, since there is only 1 to search), but recently I have been flattening the kernel module directories into a single directory. This has showed better results than I even expected: ~20% size reduction, huge performance boosts for modprobe, depmod, etc... Although it simplifies parts of coding, there _is_ existing code that does depend on the directory structure being in place - (dougal's /usr/sbin/updatenetmoduleslist.sh for example) ... so far everything has been pretty easy to patch.
Edit: you'd also need an app like xvkbd or svkbd (would be a good idea to add these to an mcb build with a tslib patched xvesa)
NEWS: I have been working on simplifying the entire directory tree for speed, compatibility and size. Part of this just involved making redundant directories into symlinks (this speeds up, for example, PATH and LD_LIBRARY_PATH searchs, since there is only 1 to search), but recently I have been flattening the kernel module directories into a single directory. This has showed better results than I even expected: ~20% size reduction, huge performance boosts for modprobe, depmod, etc... Although it simplifies parts of coding, there _is_ existing code that does depend on the directory structure being in place - (dougal's /usr/sbin/updatenetmoduleslist.sh for example) ... so far everything has been pretty easy to patch.
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].
How? A quick test in pUPnGO showed equal size of zdrv-sfs for flat and normal directory-structure of the modules. A timing (in qemu...) showed very equal performance of running depmod -a....~20% size reduction, huge performance boosts for modprobe, depmod
Using build in "modules.*" in the zdrv skips the need for running depmod at first boot which gives faster boot than running depmod...
The "modules.*" weight around 1,3Mb unpacked but only around 120K packed. What am I missing to benefit from your findings?
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
the 20% size savings was on a 2.6.32 kernel (Wary=squashfs4) and *.ko modules (no individual .gz compression) When squashed with a tree structure, I get a 24+Mb sfs file and under 19Mb flattened (module.* makes little difference on either) ... there are multiple factors that could push it down 1)the directories may account for some 2)the files being in the same directory may allow compression to cross multiple files and eliminate globally shared code (the stuff needed by all modules as well as elf structures and common strings or the directory tree my be throwing some other wrench
As for the differences - module compression, squash3 vs 4, cpu and ram???
I'm also squashing the 2.6.32 directory itself ... it just makes better sense to mount it on /lib/modules/2.6.32 rather than keep empty parent directories
Edit - more cool X stuff here:
http://unixb4coffee.hubpages.com/
As for the differences - module compression, squash3 vs 4, cpu and ram???
I'm also squashing the 2.6.32 directory itself ... it just makes better sense to mount it on /lib/modules/2.6.32 rather than keep empty parent directories
Edit - more cool X stuff here:
http://unixb4coffee.hubpages.com/
Code: Select all
/* minimal defaulttextviewer (view only) for gtk1 */
#include <stdio.h>
#include <gtk/gtk.h>
int main( int argc, char *argv[] ){
GtkWidget *window, *text;
FILE *infile;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_set_usize (window, 640, 480);
gtk_signal_connect (GTK_OBJECT (window), "destroy", gtk_main_quit, NULL);
text = gtk_text_new (NULL, NULL);
infile = fopen(argv[1], "r");
if (infile)
{
char buffer[1024]; int nchars;
do
{
nchars = fread(buffer, 1, 1024, infile);
gtk_text_insert (GTK_TEXT (text), NULL, NULL, NULL, buffer, -1);
} while (nchars == 1024);
fclose (infile);
}
gtk_container_add (GTK_CONTAINER (window), text);
gtk_widget_show_all(window);
gtk_main ();
return(0);
}
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].
Further test on the mcb...Not quite sure how to read those informations...
is it a proof of shared memory between the different applications spawn from the mcb?
is it a proof of shared memory between the different applications spawn from the mcb?
- Attachments
-
- snap0000.png
- (22.62 KiB) Downloaded 988 times
Tried pUPnGO 090611 on my wonderfully picky and catankarous Dell Latitude CPi. Unfortunately, the only graphics driver that seems to work properly on that old laptop is the generic Xorg driver (the neomagic driver produces ...interesting... results). Xvesa wreaks havoc -- every other vertical line is used and the colors are Gulden's brown-mustard "yellow" (or Koop's if you use that stuff instead) and a dark seasick green -- and the whole thing kernel panics (I suspect, just some 640x480 artifacting, nothing intelligible left) after a few minutes!
Is there a way to (size-frugally) incorporate Xorg into pUPnGO with *only* the generic driver? My understanding is that this config would work on most systems to begin with... and one would still get to choose Xvesa if one wants that.
MUCH-LATER EDIT: just found out (via a different system) that the package installer is broken in that version.
Is there a way to (size-frugally) incorporate Xorg into pUPnGO with *only* the generic driver? My understanding is that this config would work on most systems to begin with... and one would still get to choose Xvesa if one wants that.
MUCH-LATER EDIT: just found out (via a different system) that the package installer is broken in that version.
Attached revised versions of pkginstall.sh and pkgremove.sh.
Some bash specific substitutions failed when ash was only shell in the previous versions.
As for getting Xorg to play in pUPnGO try installing xorg_xorg_full_dri-7.3 official pet and needed libs accordingly (not tested...).
Or try using the static build of Xfbdev posted earlier in this thread. The kernel in pUPnGO V412 060211 - version is build with support for that.
Some bash specific substitutions failed when ash was only shell in the previous versions.
As for getting Xorg to play in pUPnGO try installing xorg_xorg_full_dri-7.3 official pet and needed libs accordingly (not tested...).
Or try using the static build of Xfbdev posted earlier in this thread. The kernel in pUPnGO V412 060211 - version is build with support for that.
- Attachments
-
- pkgins_rem-300412.tar.gz
- (6.96 KiB) Downloaded 378 times
np - you got help asking for service...starhawk wrote: EDIT: got tired of waiting found it meself..
The pkginstall.sh works ok here. You wont get Xorg with the xorg_xorg_full_dri-7.3 alone...
Try look at the official pets for P412 or other version ex. here, unpack them and strip down for your needs, repack and install in pUPnGO...ex. here
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
Just an fyi, I _am_ still working on fixing kdrive/tinyx, so that it _is_ a viable option. Its just kind of difficult to cherry pick the patches from the Xorg tree, since they never really paid any attention to whether changes broke the kdrives (which is why they were mostly removed) ... so I am using Xfree86-4.8 as the base and patches that I have found for those.
background:
Pulling out just one of Xvesa or xfbdev would be fairly simple, but there are quite a few platform specific options with some hardware acceleration that would be a shame to throw out (ati, i850, itsy, ipaq, SDL, ... many more). This involves fixing dix/main.c so that it either works more like a multicall binary that calls the proper functions based on how it is invoked (and therefore renaming a lot of functions and probably using a hacky global variable) ... or ... shifting "main" to the various drivers themselves (which would still require some function renaming, but better lend itself to making a multicall binary without hacky global variables). The second option would make it much more portable and even allow us to have a libkdrive/libtinyx ... saving space on shared library type distros and making it easier to update the universal xservers (vesa and fb) or test/add platform specific ones or even a new universal one for modern PCs that uses something like opengl/opencl. I currently only plan to support linux/bsd, so the nest of ifdefs for extinct platforms and corporate unices (what is the plural of unix?) will be minimized (If one of them wanted to sponsor the project, I'd be open to maintaining a separate tree though) ... for mac/windows hopefully there is a way to use xnest/xephyr type of driver so that the majority of platform specific code can go in there (it would have to be from an outside contributor though) ... anyhow its a lot of code and my 'g','r','e','p' keys have almost completely faded from my keyboard and my left mouse button is busted from it already - In the mean time, try the Xvesa from tinycore with the tcl version of pupngo (or their minimal Xorg package), since it is the closest to being up to date (it is newer and the mouse works better due to a patch, and a few other niceties but it doesn't have the remove-ugly-background patch AFAIR)
background:
Pulling out just one of Xvesa or xfbdev would be fairly simple, but there are quite a few platform specific options with some hardware acceleration that would be a shame to throw out (ati, i850, itsy, ipaq, SDL, ... many more). This involves fixing dix/main.c so that it either works more like a multicall binary that calls the proper functions based on how it is invoked (and therefore renaming a lot of functions and probably using a hacky global variable) ... or ... shifting "main" to the various drivers themselves (which would still require some function renaming, but better lend itself to making a multicall binary without hacky global variables). The second option would make it much more portable and even allow us to have a libkdrive/libtinyx ... saving space on shared library type distros and making it easier to update the universal xservers (vesa and fb) or test/add platform specific ones or even a new universal one for modern PCs that uses something like opengl/opencl. I currently only plan to support linux/bsd, so the nest of ifdefs for extinct platforms and corporate unices (what is the plural of unix?) will be minimized (If one of them wanted to sponsor the project, I'd be open to maintaining a separate tree though) ... for mac/windows hopefully there is a way to use xnest/xephyr type of driver so that the majority of platform specific code can go in there (it would have to be from an outside contributor though) ... anyhow its a lot of code and my 'g','r','e','p' keys have almost completely faded from my keyboard and my left mouse button is busted from it already - In the mean time, try the Xvesa from tinycore with the tcl version of pupngo (or their minimal Xorg package), since it is the closest to being up to date (it is newer and the mouse works better due to a patch, and a few other niceties but it doesn't have the remove-ugly-background patch AFAIR)
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].
Got the *.tar.gz working -- apparently 7zip was flagging the .tar file as a directory in Windows (or Windows was making a very incorrect assumption!). I un-*.gz'd it using GZip (found on the 'net) and did the untarring with 7zip and it worked.
Gaah another reason to switch, albeit a small one. Either way: not your archive, my extracting methods.
I'll take a look at the Xorg pet you provided, as I've too little knowledge of how things work to know safely what to strip from a package.
EDIT: *.pet does not work. Install from within GUI = black screen, X cursor, nothing useful present. I think you cut out a little too much
I'll take a look at the original *.pet and see what I can do.
Gaah another reason to switch, albeit a small one. Either way: not your archive, my extracting methods.
I'll take a look at the Xorg pet you provided, as I've too little knowledge of how things work to know safely what to strip from a package.
EDIT: *.pet does not work. Install from within GUI = black screen, X cursor, nothing useful present. I think you cut out a little too much
I'll take a look at the original *.pet and see what I can do.
I installed xorg 7.3-1 base, server, and drivers-full from the Puppy4 ibiblio repository, and "stole" (borrowed) the shell scripts xorgwizard, xrandrshell, xserverwizard, and input-wizard, from Puppy 412 not-retro.
I try to run xorgwizard and it doesn't work -- crashes instantly. xserverwizard says that gtkdialog2 is missing. My guess (although I can't read that fast) is that xorgwizard needs the same.
Is this something I can fix with a symlink, or do I need to learn to code something here?
I try to run xorgwizard and it doesn't work -- crashes instantly. xserverwizard says that gtkdialog2 is missing. My guess (although I can't read that fast) is that xorgwizard needs the same.
Is this something I can fix with a symlink, or do I need to learn to code something here?
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
That means it works but you need a window manager ... jwm is the best supported and highly configurablestarhawk wrote:EDIT: *.pet does not work. Install from within GUI = black screen, X cursor, nothing useful present. I think you cut out a little too much
this is my hacky way to get X up without adding extra tools
Code: Select all
Xorg & sleep 5 && jwm -display :0
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 haven't tested the xorg-pet in all the past pupngo versions but it works here in my test bench.... Try running xorgwizard from outside X (command prompt) that way you wont get the missing gtkdialog2 stuff. xorgwizard need some helpers to function (ddcprobe and dmidecode) although you can configure xorg via xorgwizard without if. Also some long options are used for grep and sort which the busybox version does not understand.
The xorg pet contains a xorgwizard modified to use gtkdialog1 (you can use the static versions provided in the programming area) - and with the described changes mentioned above.
After installing the xorg pet try starting X from command prompt with "xinit". If Xorg is symlinked to X and jwm startup is described in /root/.xinitrc - Xorg and jwm should start up ...
The xorg pet contains a xorgwizard modified to use gtkdialog1 (you can use the static versions provided in the programming area) - and with the described changes mentioned above.
After installing the xorg pet try starting X from command prompt with "xinit". If Xorg is symlinked to X and jwm startup is described in /root/.xinitrc - Xorg and jwm should start up ...
Thanks, I'll try that.
BTW, a couple of general questions probably better for the Programming forum...
(1) what does it mean to "statically" compile something? (I know you don't rub it with Cling Wrap! )
(2) when you strip things down, how is that done? Do you delete unnecessary files out of *.pets, or do you actually rewrite lines of code? or both?
I'm a total n00b with this stuff.
EDIT: might want to take a look at the referred thread -- the two *.gz files (of which I need one) won't gunzip. I posted my troubles in that thread.
BTW, a couple of general questions probably better for the Programming forum...
(1) what does it mean to "statically" compile something? (I know you don't rub it with Cling Wrap! )
(2) when you strip things down, how is that done? Do you delete unnecessary files out of *.pets, or do you actually rewrite lines of code? or both?
I'm a total n00b with this stuff.
EDIT: might want to take a look at the referred thread -- the two *.gz files (of which I need one) won't gunzip. I posted my troubles in that thread.