Puppy Linux Discussion Forum

[technosaurus]

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

[r4m0n3]

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

[goingnuts]

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.

[technosaurus]

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.

[goingnuts]

[technosaurus]

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/

[goingnuts]

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?

[starhawk]

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.

[goingnuts]

[starhawk]

running pkginstall.sh by itself clears the terminal screen like a CLS command. Using the menu results in the menu refreshing. No readout, not even an error message.

Adding Xorg functionality is equally important to me.

[goingnuts]

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.

[starhawk]

Link to the xorg pet? (for the 090611 pUPnGO)

EDIT: got tired of waiting found it meself. I'll post again to say if it works or not.

[starhawk]

All I get when I un-tar/gz that file is a "tartmp" file. Can you check and make sure it works on your end?

[goingnuts]

[technosaurus]

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)