A vote for a modular use of Puppy Linux

For talk and support relating specifically to Puppy derivatives
Message
Author
User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#46 Post by RSH »

@MochiMoppel

My personal tricks to save settings aren't a part of the Modular Concept.

I just linked this as an reply to nooby!

It is not relevant for this thread, because I can use this Modular Concept(and so the user does) also when using a personal storage file (save file).

Got it NOW?!?!?!

And by the way, just to keep you informed: there is no LazY Puppy Creators (as a multiple) - there is only one: ME.

You should have already know this, if you were able to read and to understand what currently reading.

And again: this here is not for LazY Puppy. Go complain in its EN Forum, if you would have anything to complain about it. Though, I doubt you would get any further answer from me.

This is my last reply to you in this here thread. To me, sorry I have to say this, you are now OUT!
mikeb wrote:I suspect this notion comes from unionfs which slowed down considerably with only a few layers. I regularly have 20 to 40 sfs loaded by default and get no appreciable performance hit on pentium 3 machines which noticed the drag of the standard drive icons in puppy. I noticed mention of some problems with recent kernels and aufs ... not sure of the current situation as 2.6.33 is the newest I normally use.
I also have sfs as small as 200-300k in the set...one per app usually.
Yes, I usually also do have around 30 to 40 SFS Modules loaded, without any noticeable result to Operating Systems performance.

I have SFS Modules from 11KB up to 300+ MB. The funny thing I have noticed so far: time to laod an SFS seems not really to make a difference, if the SFS is sized in KB or even in MB.

That's why I've suspected that there must be a difference between loading an SFS at boot up and loading an SFS via sfs_load.
On the other hand see what's happening in this thread.... not exactly productive when good ideas are getting lost but this is pretty typical and note very little activity in this forum alone reaches the main puppy releases.
Yeah, already noticed this. Though, there is no reasonable point for me to see, why this hasn't changed in those 10 Puppy Linux years.
oldyeller wrote:If you load by the menu when needing a program, does it unload when it is closed? Are the SFS done automatically for loading and unloading and no need for SFS-load on the fly?
If the SFS's application is a real binary, I can freely define if the SFS should be unloaded after its application is exited. Please note the onformation at second post, and there especially read the thread of multi-session CD/DVD (my solution, created for 8-bit). For the use of the Modular Concept, how I do prefer and suggesting it, the use of sfs_load is needed!

This Modular Concept is built on top of sfs_load and all its pretty comfort would get lost immediately, if there wouldn't be shinobar's sfs_load. Though, I'm currently using a little modified version to be able to load SFS from different locations (and not only from boot partition or boot directory). I'm convince by now, I would be able to create this also for the use without shinobar's sfs_load. But why should I try so?
How would you link to a Appdir or load more than 6 SFS?
To laod more than 6 SFS Modules (I assume, you do mean at boot up, when using a save file) also sfs_load can be used. Itself uses a file /etc/init.d/sfs_load for this.

While running the OS, shinobar's sfs_load generates mount point directories automatically for each SFS to load.

There is no need to link to AppDirs, because you can run them from every location you want to store it. But AppDirs aren't really a part of this here. It could be a nice addition, but I'm not an expert for this - still learning while doing some of this stuff (like the RoxApp Builder, which isn't a part of this here as well). If you want to know anything about AppDirs or RoxApps or Program Folders, go to RoxApp Builder thread in Puppy Projects Forum and do read my information over there. There are also some links to a few RoxApp Dirs for the use on un-unioned SFS Modules (I think, un-unioned means: not mounted to the pup_roX directories, instead mounted to /mnt or anywhere else).
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#47 Post by mikeb »

I think it was shinobars sfs load I looked at ..... as mentioned it or whatever it was did load to ram if there was enough space ...that would take longer the larger the file but the same would apply to one at boot.
If we are dealing with aufs itself I have noticed it can take a few seconds for files to propagate through the system when dealing with an sfs with thousands of files...the devx is a good example, but it probably takes longer for menus to sort out so its not a problem as such.

Just as an aside I am fiddling with the initrd at the moment and it takes 1.5 seconds to run the init script including loading a 94mb pup sfs to ram on a pentium 3.

Here's the module activate/deactivate script I have on puppy in use at the moment. I am a slob and should tart it up but it does the job.
Its in the right click rox menu and toggles load/unload.

Code: Select all

#! /bin/sh

## script to insert and remove sfs files.....for puppy kernel 2.6.21 and above seem fine with this..

MODULE="$1"
NAME="`basename $MODULE | tr ' ' '_' `"  ##remove spaces for later...easier life

if [ "`mount | grep "$NAME "`" = "" ]; then
	## insert module...note if mounted already will not try and insert...probably a good thing
	## TODO.....resize and add into tmpfs if enough room...or small....or the rest loaded .. hmmmm..
	##note slax only does this if inside the union....need test for this? 
	MODE="activate"
	#must remember to makes nodes if all used
	NEXT=$(losetup -f 2>/dev/null) 
	if [ "$NEXT" = "" ]; then
		NR=$(find /dev/loop* | cut -b 10- | sort -n | tail -1)
		NR=$(expr $NR + 1)
		NEXT=/dev/loop$NR
		mknod $NEXT b 7 $NR 2>/dev/null
	fi
	mkdir -p /initrd/$NAME
	mount-FULL -o loop -t squashfs "$MODULE" /initrd/$NAME
	busybox mount -t aufs -o remount,add:1:/initrd/$NAME=ro unionfs /
	if [ $? -eq 0 ]; then
		#fixmenus
		touch /root/.config/xfce4/desktop/menu.xml
		[ "`pidof X`" != "" ]&& Xdialog --timeout 4 --msgbox "Inserted $NAME" 5 40
		echo "Inserted $NAME"
		exit
	fi
else
	MODE="deactivate"
	busybox mount -t aufs -o remount,del:/initrd/$NAME unionfs /
	busybox umount /initrd/$NAME
	rmdir /initrd/$NAME
	if [ $? -eq 0 ]; then
		#fixmenus...do first before dialog as faster
		touch /root/.config/xfce4/desktop/menu.xml
		[ "`pidof X`" != "" ]&& Xdialog --timeout 4 --msgbox  "Removed $NAME" 5 40
		echo "Removed $NAME"
		exit
	fi
fi

[ "`pidof X`" != "" ]&& Xdialog --timeout 4 --msgbox "Unable to $MODE $NAME" 5 40
echo "Unable to $MODE $NAME"
note fixmenus is there but commented out as I have xfce4.
note 2...this mounts the sfs just under the rw layer which logic dictates it should be.

mike

dancytron
Posts: 1519
Joined: Wed 18 Jul 2012, 19:20

#48 Post by dancytron »

I've mainly contributed by answering simple questions occasionally, but I've thought about this for awhile. I think to do what RSH is talking about, the first thing is to build an infrastructure that makes it accessible to mere mortals (as opposed to Woof, which is only accessible to real developers).

The first step is to produce a barebones main sfs file that only has what is necessary to install and run the system. Just the stuff to configure the hardware, a desktop, the Load SFS program, Remaster Script and Pupsaveconfig. That would be the base to allow creating a modular system. Pupsaveconfig lets you decide how to handle the save file. Load SFS lets you add modules to the system.

Then create another sfs that has setup utilities, including the PPM, Gparted, all the utilities to configure the desktop, all the utilities to create and edit pets and sfs files, etc etc. All the stuff to setup Puppy, as opposed to just use it.

Finally, you'd have a DevX sfs file that has the compiling tools just like it does now.

With these three pieces, you can then create sfs files to make a modular system, create pet files to install to save file (or use as a basis to remaster the main sfs file), use the PPM to install Ubuntu or Slackware packages to install to save file (or use to remaster the main sfs file), compile programs from the source etc.

It gives a lot of flexibility to create custom modular (or not modular) distributions without dealing with Woof.

Anyway, just a thought.

User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#49 Post by RSH »

mikeb wrote:If we are dealing with aufs itself I have noticed it can take a few seconds for files to propagate through the system when dealing with an sfs with thousands of files...the devx is a good example, but it probably takes longer for menus to sort out so its not a problem as such.
Yes.

As far as I know, shinobar's sfs_load is mounting an AUFS, to load SFS Modules. Also I have noticed a -sometimes- huge delay until the sfs_load GUI to execute an application from the currently loaded SFS appears on the screen. I have noticed also, this is dependent to the WM in use.

My experiences:

- JWM needs sometimes to be refreshed manually (though, it is fast)
- IceWM is also fast and I did never ever need to refresh it manually
- Openbox is really fast, even for a full menu like I do have over here (currently 821 .desktop files in /usr/share/applications)

BUT:

- when FbPanel is used as the panel for Openbox these 821 .desktop files (menu entries) resulting in an huge delay
- this huge delay is related to FbPanel itself
- the code, producing this issue is to be found in /usr/sbin/fixmenus

Code: Select all

if (grep "openbox" /etc/windowmanager) then
	[ `which variconlinks` ] && variconlinks #100404 for my fbpanel pkg.
	[ `which tempicons` ] && tempicons
fi
- responsible line is: [ `which variconlinks` ] && variconlinks #100404 for my fbpanel pkg
- this line creates a huge amount of icons from all over the running OS for the FbPanel to use

Currently I don't have any other WM/Panel installed, than Openbox and Tint2. If loading my LP2_WindowManagers.sfs Openbox (the OS) will use automatically FbPanel instead of tint2. Therefor I have modified /usr/sbin/fixmenus to execute refresh/rebuild of Openbox menu at first - before any else WM/Panel is refreshed/rebuild.

So, while FbPanel is stiil updating its icons, I can run any newly added application from Openbox menu immediately.

Also, I don't use sfs_load as it is supposed to use. I do use it only as back end script, since I have my own GUI to load/unload SFS Modules and all the menu entries already built into the OS. So, there is no need to run /usr/sbin/fixmenus when loading an SFS by the use of sfs_load in back end (console) mode. That's why shinobar has introduced option --skip-fixmenus in sfs_load version 1.9 and above. Especially for the use of the SFS P.L.U.S. RunScripts!

Code I usually do use, to load any SFS Module:

Code: Select all

sfs_load --cli --skip-fixmenus --quiet "$LP2BDL/$SFS_file"
Code I usually do use, to unload any SFS Module:

Code: Select all

sfs_load --unload --cli --skip-fixmenus --quiet "$LP2BDL/$SFS_file"
$LP2BDL is current boot directory, like: /mnt/sdd1/LazY
$SFS_file is the SFS Module to load, like LP2_WindowManagers.sfs
Just as an aside I am fiddling with the initrd at the moment and it takes 1.5 seconds to run the init script including loading a 94mb pup sfs to ram on a pentium 3.
Mine is a bit slower than yours, since I've added some stuff to be able to load each SFS Module I want to load at boot up - just by an option to be placed in a boot menu entry in menu.lst (or even entered in console)

This

Code: Select all

lpextsfs=LP2_XorgHigh.sfs
will load the XorgHigh automatically at boot up. It goes straight to where the zdrv.sfs usually goes: /intird/pup_z.

However, I really don't care about the speed of booting the OS, if it has been done in 20, 40 or even 60 seconds etc.pp. since I'm usually brushing my teeth, washing my face, entering the bathroom or pulling off my clothes when returning to home, at such boot times. :lol:
Here's the module activate/deactivate script I have on puppy in use at the moment. I am a slob and should tart it up but it does the job.
Its in the right click rox menu and toggles load/unload.
Yes, I can load/unload SFS Modules by clicking it as well. Plus: I do have a Openbox menu Category (menu pipe), which offers to me all current loaded SFS Modules to be unloaded, when clicking its menu entry.

Sorry, but can't post an image at the moment, because I'm still using the MochiMoppelTest-called LazY Puppy 2.0.2-005 EN version by using the created save file - still works, but this version hasn't included above named Openbox feature.
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#50 Post by RSH »

dancytron wrote:I've mainly contributed by answering simple questions occasionally, but I've thought about this for awhile. I think to do what RSH is talking about, the first thing is to build an infrastructure that makes it accessible to mere mortals (as opposed to Woof, which is only accessible to real developers).

The first step is to produce a barebones main sfs file that only has what is necessary to install and run the system. Just the stuff to configure the hardware, a desktop, the Load SFS program, Remaster Script and Pupsaveconfig. That would be the base to allow creating a modular system. Pupsaveconfig lets you decide how to handle the save file. Load SFS lets you add modules to the system.

Then create another sfs that has setup utilities, including the PPM, Gparted, all the utilities to configure the desktop, all the utilities to create and edit pets and sfs files, etc etc. All the stuff to setup Puppy, as opposed to just use it.

Finally, you'd have a DevX sfs file that has the compiling tools just like it does now.

With these three pieces, you can then create sfs files to make a modular system, create pet files to install to save file (or use as a basis to remaster the main sfs file), use the PPM to install Ubuntu or Slackware packages to install to save file (or use to remaster the main sfs file), compile programs from the source etc.

It gives a lot of flexibility to create custom modular (or not modular) distributions without dealing with Woof.

Anyway, just a thought.
Hi.

This sounds like you could be the one to get involved in development of my latest version of the SFS P.L.U.S.!

If you are interested in this, let me know.

RSH
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#51 Post by mikeb »

Yes I notice fixmenus did some mad stuff making it slow..I hacked it down in lucid and dumped it a long time ago in the rest.
Xfce4 uses xdg desktop file handling so it just needs a trigger to refresh it when a module loads...at least the version on puppy does but its quick.

Hmm once upon a time '_525.sfs' on the end of an sfs would mean it would load at boot...no configs, no boot parameters...just add the file and done.
The simplicity of such a system was ok as a no brainer to get a modem module built before I knew anything about linux.

My speed point was that even with a bundle of modules there is only a few seconds involved....one reason is the usually contiguous nature of the sfs files. fast boots and shutdowns for that matter are more significant on anything battery powered....and for impatient users like me :D

Slax does things a little differently to puppy at boot.
It actually builds a bare union with ONLY the tmpfs for changes (or save file or folder) The modules themselves including the core system are all then loaded on-the-fly afterwards in the same manner as the finally booted system. Layer order is determined by the module naming order with say 001 at the bottom...zzz at the top so giving full control in that area. Does make for a very simple boot script....(the functions used are in a file which is common to the initrd and main system since they are identical) One other difference is there is one shared tmpfs for both modules and the read/write layer which does give a simpler picture of ram space usage. It also means there is no need to resize the tmpfs to fit in further modules and determining space left is easier. I tried sharing tmpfs on puppy and it worked but could not be done without moving certain union mount points so upsetting some scripts.

Dancytron...a build a bear puppy...like the slax live builder... always seemed like a good concept. Being modular the kernel can be a drop in too.

mike

User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#52 Post by RSH »

Hmm once upon a time '_525.sfs' on the end of an sfs would mean it would load at boot...no configs, no boot parameters...just add the file and done.
Nice option. Did never heard of that.

Sounds smarter to me than the so-called ADRV option made by jemimah (hm, can't remind the name of the OS, I think Carolina is a successor of it)
My speed point was that even with a bundle of modules there is only a few seconds involved....one reason is the usually contiguous nature of the sfs files. fast boots and shutdowns for that matter are more significant on anything battery powered
Ok, I see.

I'm only using desktop computers. Do not own any other and don't want to.
I tried sharing tmpfs on puppy and it worked but could not be done without moving certain union mount points so upsetting some scripts.
I doubt, I could do such things. So, seems that you are more an expert than I'm (of course I'm not).

However, I will try now to add to latest version of my SFS P.L.U.S. suggestion by mavrothal of ability to download SFS Modules at first boot (from CD) to be able to have some testings without to install the OS first.

I might be offline for a few days. Hopefully returning back to here exploring lots of new and interesting posts (maybe some more individual used solutions for a Modular Concept?).

RSH
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

dancytron
Posts: 1519
Joined: Wed 18 Jul 2012, 19:20

#53 Post by dancytron »

RSH wrote: Hi.

This sounds like you could be the one to get involved in development of my latest version of the SFS P.L.U.S.!

If you are interested in this, let me know.

RSH
I'd be happy to do some testing and give feedback. I'm not sure if I'd be any help doing actual development.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#54 Post by mikeb »

The tmpfs merge was just to see if it can be done...its ok as is as tmpfs can be resized on the fly and I try to keep to the puppy layouts for compatability.

The _525.sfs was the puppy 1 and 2 way... a simple
ls /path/to/drive/*_${PUPPYVERSION}.sfs detected any sfs.

I added _uni.sfs for modules that are ok on many puppy versions such as thunderbird with _sfs4.sfs for later kernels.

Have offline fun

Mike

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#55 Post by sunburnt »

mikeb; Yes, I think you`re right that running aufs is it`s main cpu/ram load.
Adding more layers after that probably doesn`t effect things as much.
Which makes it pretty usable for what RHS is talking about.

# There`s a lot of terminology floating around.

no-install apps. = Any app. that`s ready to run ( SFS and AppDir ).
non-union = Using a image file ( Squash-SFS or Save ) without unioning it ( AppDir ).
AppDir = Same as RoxApp. Rox now calls RoxApp - Appdir.


# RHS; What`s your opinion of a bare O.S. with only base apps., using app. modules only.?
Reduces download bandwidth, and users don`t have to ask how to delete unwanted apps.
Only a dev. or two are needed to maintain the O.S., but many app. builders are needed.
.

User avatar
Moose On The Loose
Posts: 965
Joined: Thu 24 Feb 2011, 14:54

#56 Post by Moose On The Loose »

RSH wrote:
Moose On The Loose wrote:Doing it wrong can lead the the problem of incompatible shared libraries and the like.
Such would mostly be an (unsolvable) problem by using PET instead of SFS. Some of my LazY Puppy Systems have Jack Audio installed which conflicts with two of my VLC SFS Modules, because of different shared QT libraries
In the past, I have solved the library issue with scripts that set up links to stuff. It works out a lot like plugging and unplugging SFS. The programs can't be used at the same time when that is done.

I also can on some things get the source and do a compile with static linking. It makes the programs bigger but it can solve some shared library issues.

Since a pet is really just a TGZ archive, an "installer" could be made to create an SFS for each new thing you install as a pet so the SFS modularity method can be transparent to the user.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#57 Post by mikeb »

Version conflicts... the idea of building your apps on a base system so they will work is a valid one.... debian squeeze apps will work on debian squeeze.

Random packages built on random systems is the problem here and the desire to grab packages from the big boys who have a totally different build agenda.

The other way is to build on a system (the target one!!!!) that steps back a year or two.... much more likely to produce a universal result.... such as libreoffice do this. With puppy this probably makes the best sense as there are so many variations.

Static binaries... yes one approach ...again adopted by many builders especially games I find.... not just static binaries but statically linked libs so all is in one folder. The thoughts about the build system still apply...I cannot use most of the programs on portable linux as they are built on a recent ubuntu.

Building a system around rox is nice but hits the snag of what happens with a different desktop/window manager and file browser.

I think RSH is away for a few days so might be a while before he replies.

mike and his toes

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#58 Post by sunburnt »

Yep, as amigo keeps saying: Tool chain, tool chain, tool chain. Puppy badly needs one...
Yeah, most portable apps I`ve tried are not so portable. Good idea, bad implementation.
Ubuntu is bloated, but size isn`t important ( ask your girl friend :lol: ). Lots of good apps.
Any pkg. type has trouble changing WM, desktop, taskbar, themes, graphic tool kits, etc.
One of Puppy`s big sore spots ( sooo many...). And it would be a fairly easy one to fix too.

Amigo made a AppDir setup that compiles the app into a new AppDir. Very nice...
Source packages are easy to find, so my Virtual Apps package would go well with this.
It`s an empty AppDir except for scripts to download, compile, and setup. Very small.
This arrangement will support all the variants ( OR, just have one O.S., not many ).
That... Or each app builder makes app packages, one for each variant type ( NOT good ).

>>> Sorry for straying from the modularity theme RSH.
.
Last edited by sunburnt on Thu 07 Nov 2013, 07:01, edited 1 time in total.

User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#59 Post by RSH »

sunburnt wrote:Sorry for straying from the modularity theme RSH
Ha...

I'm not really straying from the modularity theme.

But, since Linus Torvald has had said: Talk is cheap, show me the code., there is always to do some work, to be able to show some code.

I want to show you the code, which still needs some work.

Doing long posts with facts and replying to replies takes a lot of time for me to do in EN. Really, you all can't imagine that from reading my posts.

Such time is often better used, when working on progress and/or suggestions.

Even such is hard for me to do, since I'm jumping from here to there, because each work on a new suggestion often offers new ideas to me, that also often have nothing to do with the suggestion to work on. It has just happened again!

However, lot's of new and interesting postings here. So, a short post is possible for me to do.

I have made some progress and therefor some good news to publish - maybe tomorrow (we'll see).

So, (as said in the old days): stay tuned!

RSH
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#60 Post by sunburnt »

Good to hear from you RSH, I was worried you`d become disgusted with your thread.

If my idea of Virtual Packages interests you, you should see what I have done.
Current work is on a general purpose world mirrors GUI for the Virtual Apps.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#61 Post by mikeb »

Doing long posts with facts and replying to replies takes a lot of time for me to do in EN. Really, you all can't imagine that from reading my posts.
Lived in france for a while so understand that one....
but you managed to troll batter effectively hopefully leaving a quiet productive thread.. :)

I developed my systems some moons ago and have solid frameworks that just get the odd update now and then but happy to throw in my experiences and anything else that might be useful.

@sunburnt ... updated mut this week (ext4 and stripped out all the logging/debug stuff),...thought the sources were lost... the busybox of drive handling ... added it to the initrd too. Puppy lacks c programmers and I am not one either but some functions are better handled in binaries.

Hijack over :)

Ok we await your needs, questions, statements, tap dancing, jokes RSH but we are not groupies :D

mike

User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#62 Post by RSH »

sunburnt wrote:Good to hear from you RSH, I was worried you`d become discussed with your thread.
No.

I'm just on duty. :D :lol:
If my idea of Virtual Packages interests you, you should see what I have done.
Current work is on a general purpose world mirrors GUI for the Virtual Apps.
Of course, I am interested.

Some of this probably could be used to refine/extend the RoxApp Builder.
mikeb wrote:Ok we await your needs, questions, statements, tap dancing, jokes RSH but we are not groupies
Ah, Ok.

So, stay tuned is like a saying to groupies?

I think, I remember me knowing this saying from the old days, back when I was a child and listening to a few GB/US Radio Stations. Germany was split/divided then and also occupied by the US/GB/FR allies (Western Germany).

Aahhh, I should remind my saying: to not to start any off topic discussion... :lol:

Ok, I'm still at work. After finishing it I'll have to "fix" my bicycle, which means, to make it ready for the use at winter times. This might take a day as well. I think I'm ready to turn back to here with all good news to offer, on Saturday.
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#63 Post by mikeb »

After finishing it I'll have to "fix" my bicycle, which means, to make it ready for the use at winter times.
hmm no tread on the tyres, not smooth chain, boot lets in water and velcro on snow hats.... yes must get busy too...

Mike

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#64 Post by sunburnt »

RSH; What RoxApp Builder are you referring to? Your`s, or maybe amigo`s?
I`d like to see it`s method of app. enabling, and it`s arrangement of RoxApp structure ( if any...).

Can you give us a short hint of what project/code you`re working on? An app. package setup?

Modularity: Most simpler apps., and bigger ones that work well as AppDir can be that way.
This simplifies adding/removing the apps. as no sfs_load is needed, and fewer union layers.
Organize: Make uncooperative apps as SFS files, and bundle the ones with common deps.

mikeb; I seem to recall mut from Puppy`s earlier days. Replaced by pmount or hotpup?
My latest is staring at Xwindow, and, Xlib, XCB programming examples.
Want to make base window with all common needed events and methods to draw on.
Like many (technosaurus) I`m sick of GTK+ and want a new tool kit, and a common api.
.

User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#65 Post by RSH »

Yeah, a short reply is possible.

Currently I'm working on SFS P.L.U.S. Version 4 - (3.8.9 at the moment).

Adding option based on mavrothal's suggestion to download SFS Modules to specific location, at first use of a Puppy (when using from CD, since one can't download to CD, which then is the LP2BDL - boot directory (usually it loads from and downloads to this location)).

Also, mikeb mentioned something about ROX or RoxApps and other WMs like XFCE, e17 etc.

All Programs/Functions of SFS P.L.U.S. are easily to be used by right-click action, which will only work in a Rox Filer Window. They can be used also from a menu entry, but this will add 25 entries to the setup menu (or was it utilities?).

So, I'm working on a GUI to be able to execute/use all SFS P.L.U.S. Programs/Functions from within this GUI. Will reduce added menu entries down to 1 - if needed or wanted!

Since I'm able to use the SFS P.L.U.S. Suite to create RunScripts from:

- SFS Modules
- Portable Linux Applications
- Portable Wine Applications
- Wine Installation Packages
(Forum Utilities - LazY WInstND - paused - for further information, if interested)

and so, I felt in love with the idea of creating RunScripts from RoxApps.

RoxApp Builder: I did refer to the RoxApp Builder (forum Puppy Projects) of mine - did not know, there was any other.
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

Post Reply