PaDS 1.1.4 - updated version of 1.0.4

Miscellaneous tools
Message
Author
ITSMERSH

#41 Post by ITSMERSH »

There's a good chance just changing that filter to 'All Files' will enable the directories and files to be entered/selected.
This was meant to NOT to change it to 'All Files' within the code, but to change it in the file selector. Sorry, if there was any misunderstanding.

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

#42 Post by davids45 »

G'tag RSH,

Thank you for the instant replies :shock: .

Here is my line 326 in the script you noted:
<action>my_RSH_gtk_fileselect_workaround "Load" "$(cat /tmp/my_return_file_containing_the_results.txt)" "*.*|*.deb|*.pet|*.tar.gz|*.sfs|*.txz|*.tazpkg" "directory" "/tmp/my_return_file_containing_the_results.txt"</action>
With the PaDS pet I'd downloaded, I tried again in a Stretch7.5-k3.16.45 (same result as yesterday) and now in a Bionicpup-18.05-k4.9.96 (both frugal Pups on sda1).
In Bionic just now, I was prompted to install the tools debs on first running PaDS and did this (2 .debs installed).

I ran PaDS (second screenshot), but again, in the 'Add files...' step, I could not select a sub-directory in sdb3 - I tried to double-click on the Puppy_Archive sub-directory of sdb3 (first screenshot) but nothing happened.

The sfs files I want to merge into one sfs are several more sub-directories down in my Puppy_Archive on sdb3.

I could try again by moving these sfs to a /root location in a Pup to see if that is a work-around?
The sfs are all quite small as they are all made of symlinks so I can run these programs in new Pups on my frugal partitions while having the full-sized programs on my large data partitions.
This is working well with my many 32-bit Pups but I lack a sfs-combiner in the 64-bit Pups. I can combine the 64-bit sfs with the 32-bit combiner in a 32-bit Pup then drop the resulting sfs into the 64-bit Pup partition's root but I was hoping to find a tidier method using just the 64-bit Pups for the merging/combining.

Thanks again for your help and patience.

And your English is much better than my hochschule Deutsch (one year, about 50 years ago!).

David S.
Attachments
select-subdirectory-in-sdb3-fail.jpg
clicking on PuppyArchive sub-directory doesn't open this sub-directory
(80.35 KiB) Downloaded 193 times
pads113-bionic-start.jpg
starting PaDS in a BionicPup
(127.38 KiB) Downloaded 191 times

ITSMERSH

#43 Post by ITSMERSH »

Ok,

for my N.E.M.E.S.I.S. developments I have permanently installed Bionic Pup 18.05. So I booted into that Puppy, installed PaDS 1.1.3 and could reproduce the issue.

Seems to be caused by newer version of gtkdialog, as it works well in Puppies pre Bionic Pup (Tahr, Xenial).

Now there's two ways to solve this for some period until I will be able to upload a updated version.

1. When choosing the directory to select .sfs (or any other) files, just click the butten on the lower right corner and select 'All Files'. Change the location in that file selector once (to /root/ for example) and then back to the file system.

All directories shold now allow to be entered.

2. Change the code in file /usr/local/pd2sfsgui/petsNdebs2sfsgui at line 326 from:

Code: Select all

"*.*|*.deb|*.pet|*.tar.gz|*.sfs|*.txz|*.tazpkg"
to:

Code: Select all

""
Yes, only keeping the double-quotes with no spaces within !!! :!:
Attachments
Screenshot.jpg
(94.9 KiB) Downloaded 181 times

ITSMERSH

#44 Post by ITSMERSH »

Any results?

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

A few quick tests yesterday

#45 Post by davids45 »

G'tag RSH,

I've tried PaDS in a few 32-bit and 64-bit Pups with little success. Firstly as a pet (+.debs), but then I tried to make an sfs of Pads and the two extra deb packages so I could easily unload it from a Pup if PaDS did not run as hoped. I have a PaDS sfs with the 32-bit debs and another with the 64bit/amd debs.

Test results
No slacko-based pup (2) got past selecting the working directory; the Pup freezes with a gtk panel appearing on the task bar. The extra files needed for the gui being .deb files may have been part of this failing?

A Stretch Pup also stopped at the selecting the 'Load' directory that has the sfs to merge = the original problem I had.

A Bionic 32-bit and 64-bit Pup did not work, freezing the Pup or stopping at the 'Load'.

But I found a Xenial Pup (xenial75-k4.4.95) was good and I made a combined sfs as I had hoped :D :D .
I haven't tried my all-in-one PaDS sfs in this Pup to check my sfs is OK - I'll delete the pet files and re-do this test with the sfs.

Other thoughts
I was wondering if Muppy-Filer (which I install (sfs) in every 32-bit Pup as it is such a useful little program) is conflicting in someway with PaDS?
I manually deleted PaDS in one Pup (via the .packages files list), including deleting a couple of 2012-dated lib files (which seemed a bit old?) and later found Muppy-Filer had stopped running.
So I thought of a possible conflict if these lib files were part of Muppy-Filer as well as PaDS?

Is there a quick way to find the gtk version in a Pup - you did say this could be important?

I apologise that my testing has been very brief and a bit random so far, but with your extra feedback (your last post suggestions), I will try to be a bit organised from now on :oops: .

I will concentrate on my 64-bit Pups as these do not have a sfs-combiner as far as I know and do not have Muppy-Filer.

Thanks again.

David S.

ITSMERSH

#46 Post by ITSMERSH »

PaDS doesn't come with any libs to install. So, there's nothing that could cause conflicts between PaDS and the Muppy Filer.

Could you make some testings (using those Puppies where PaDS failed) after applied/used the changes/instructions I suggested in my last post?

I need to have the results, to make sure, what to change in next version of PaDS.

What's the two extra deb packages you are talking about?
but then I tried to make an sfs of Pads
Should work from .sfs loaded as far as I can see (if it works in general)...

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

libs for xdotool

#47 Post by davids45 »

G'day RSH,

I'm a little bit further with my problems/tests.

Only trying 64-bit Pups since my last post.

For easy testing in a range of my Pups, I made a sfs of PaDS-1.1.3 and then one using links to PaDS files on my data partition. Loading and unloading an sfs is far better than removing pets for me. And when PaDS is ready, I will be using it as a sfs shared around my Pups.

During making these sfs, I had problems with the different library directories in different Pups - lib, lib32, lib64 and odder ones with i386 or gnu or other confusing-to-me words in their names. Much simpler with 32-bit Pups with everything in /usr/lib. This confusion of lib directories for 64-bit Pups was why I gave up with these 64-bit Pups in past explorations in the 64-bit world.

When PaDS did not work....
The problems seemed to be in the xdotool part?
The GUI was fine to start and then to pick a working directory, but then stopped with the 'Load' and a gtk 'message' on the task bar (but no dialog box).
After failures with Slacko Pups and the sfs made with the 64-bit .deb versions of the xdotool files (2 needed according to the repository), I made another PaDS sfs using the Slacko repository of xdotool (only one file needed). And the lib directories were simpler (just lib and lib64) in Slacko.

PaDS successes.....
My PaDS-slacko sfs is working with some of my Slacko64 Pups (including a LxPupSc64), sometimes I need to do the 'All files' selection during the 'Load' stage if it looks like a frozen 'Load' window.
So your 'All files' recommendation has been useful.

I haven't tried my slacko-PaDS sfs in a non-slacko Pup yet.

My original .deb PaDS links-sfs has now worked in two Xenial64 Pups with the 'All files' step. And I had a success with a Slacko64-630 Pup but not with the newer ones on my 64-bit frugals partition.

Next I will make your suggested edit:
2. Change the code in file /usr/local/pd2sfsgui/petsNdebs2sfsgui at line 326 from:
Code:
"*.*|*.deb|*.pet|*.tar.gz|*.sfs|*.txz|*.tazpkg"

to:
Code:
""
and see how this goes in both my PaDS-sfs and various Pup breeds.

My problems with libraries in the sfs may be just my problem in navigating the 64-bit differences when creating my sfs.
So there may be no difference because of where the xdotool library file comes from - just where I put it?

I agree that the older 64-bit Pups are better with PaDS at present, and hope you have a gtk magic wand to bring newer Pups into line.

I think I can see 'light at the end of my tunnel' of PaDS difficulties - after all, I have now made combined 64-bit sfses from my many individual application sfs for my Slacko and Xenial 64-bit Pups.

So thanks for your continued tolerance and good advice.

David S.

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

update of tests as sfs-combiner

#48 Post by davids45 »

G'day RSH,

I've been using PaDS with the edit to line 326 you suggested and I have not had any problem of freezing or making selections in any 64-bit Pup I have run PaDS in, using it as my 'home-made' links-sfs from your .pet and the 64-bit xdotool lib.

One small comment.
In a made-today 64-bit LxPupSc64-18.06+3, I ran the PaDS sfs to merge all my applications sfses into a single all-applications-sfs to load into each Xenial64 Pup. I'd already made a slacko all-apps-links-sfs with MU's 32-bit SFS-Combiner in an old 32-bit Pup for the LxPupSc64s.

First screenshot shows the PaDS window - no problem choosing a working directory nor a 'Load' directory (next screenshot shows these directories to be merged).

PaDS then made the wanted Xenial-all-sfs sfs plus its md5 check-file in the working directory.

I had made the working directory the directory where I store my all-links.sfses for each Puppy type. So I needed to delete the now unwanted copies of the single app sfses that were copied here during the marge process (third screenshot).

I wonder if a third dialog box (optional?) could be "easily" included in PaDS to tell PaDS where to put the merged sfs rather than in the working directory. Saves me copying it from the working directory to where I store it, or having to delete the working file copies when I made the working directory my sfs-storing directory.
If not "easily" done, or would be too complicated for the user, that's OK. I just need to get used to how to use PaDS the way it is.

Thanks once again for this useful package as my SFS-Combiner replacement in 64-bit Pups

David S.
Attachments
PaDS-setup-to-merge-sfs.jpg
PaDS window successfully set up to merge sfs files
(110.43 KiB) Downloaded 432 times
directory-of-selected-sfs-to-merge.jpg
directory of 17 sfs to be merged into one all-links-sfs
(89.01 KiB) Downloaded 413 times
new-sfs-but-all-copied-also.jpg
everything in working directory
(104.04 KiB) Downloaded 411 times
preferred-result-combinedsfs.jpg
putting the result in a particular directory?
(25.68 KiB) Downloaded 413 times

ITSMERSH

#49 Post by ITSMERSH »

Hi davids45.

I never combined several .sfs into a single one.

Though, I know PaDS is copying the .sfs to a different location to extract. Probably there's just a variable not setup or even wrong values in it. This could have happened, as I took code from my X-PaDS to update PaDS.

Going to check this and fix it in next version.

Thanks for the report.

Edit:

In the images you attached I can not read the paths used in complete.

Could you post the full paths used, please?

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#50 Post by rockedge »

Code: Select all

I wonder if a third dialog box (optional?) could be "easily" included in PaDS to tell PaDS where to put the merged sfs rather than in the working directory. Saves me copying it from the working directory to where I store it, or having to delete the working file copies when I made the working directory my sfs-storing directory.
I agree that would be a great little option.

Thanks RSH for the work...it's a nice little package

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

Paths for my PaDS

#51 Post by davids45 »

G'day RSH,

I'm holding my 64-bit stuff on my sdb3 data partition (it's about 300GB of my 500GB sdb drive). My 64-bit Pups are together on sdb6 (about 30GB, with about a dozen 64-bit Pups at present, and about twenty sfs packages there while I sort out what these Pups need by way of a boot-mounted sfs to do what I want. I'm hoping to have just one all-apps-as-links-sfs per Pup 'breed' when I'm finished).

My working directory for PaDS is mostly:

/mnt/sdb3/SFS-Temp

My 'Load' directory is usually of the form:

/mnt/sdb3/Puppy_Archive/sfs_files/64bit/****

****=[A 64-bit Puppy directory holding the individual sfs-links apps I want to add for that particular Puppy as a single combined sfs - so I have at present, Xenial, Slacko Tahr and Stretch directories]

Have I missed a path you'd like to know?

As a bit more background, the starting point of all this is:

/mnt/sdb3/Puppy_Archive/sfs_files/64bit/originalFilesForLinking/

..... where I keep my full (expanded) application packages directories and (expanded) links versions made from these. I then create my app-links sfs with Muppy-Filer from the links-only directories with dir2sfs.
When I've made the links-sfs of an application (e.g. libreoffice-6.0.2), I move this sfs to my master directory of individual application links-sfs.
For each Puppy version, I then copy from the master directory to the directory I made for each Puppy, each links-sfs I need to add to that Pup. These become my 'Load' directory for PaDS.
Some Pups come with some apps already installed or miss some lib files, so I cannot use just the one all-in-one sfs for all my 64-bit Pups.

Mostly, I still boot from a 32-bit Pup on sda1 (its data partition is sda5) where I've set up things as I like :D . I'm trying to do the same for the 64-bitters which is proving a bit difficult :roll: .

I hope this answers your request and helps explain my present 'folly'.

David S.

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

Combining 64-bit sfs - .desktop problem

#52 Post by davids45 »

G'day RSH,

I have found a problem when using PaDS to combine lots of sfs into one SFS.

I began a thread when I found a strange Menu problem in my 64-bit Pups:

http://www.murga-linux.com/puppy/viewtopic.php?t=114054

and have now worked out the problem is in PaDS when just combining sfs files.

The 'second' step in PaDS to edit each sfs menu (.desktop file) creates unwanted extra lines in existing .desktop files.
Screenshots in that thread show these added lines and their effect.
The new line (e.g. 'Name[language]=' without following text) are read during jwmrc menu creation in preference to the original 'Name=(my app)'.

So when I load the combined sfs, the Menu has lots of blanks.

Is it simple to modify PaDS so this menu creation 'second step' is only carried out when making new sfs from pets, etc.?
Or to offer a clickable button to miss this step so existing menus/desktop files are left as they are?

Or make a new package (spun off from PaDS) that is only a combiner of sfs files (like the old 32-bit SFS-Combiner)?

Thanks,
David S.

ITSMERSH

#53 Post by ITSMERSH »

If it comes to the GUI where to edit the contents of the .desktop files, you need to edit the entries related to the current language (or even to the chosen language, if you had chosen a different one).

If you don't edit those entries, they don't have any values at all, of course. So, this is NOT a problem of PaDS, but a neglect by the user.

This GUI mentioned should have buttons to open the directory of the .desktop files, to edit them in a text editor for example. It's easy, to remove entries without values (if you don't want to fill those entries with meaningful values) before exiting the GUI and continuing the build of the .sfs.

To remove that code or to change it doesn't make sense if it comes to users different to EN users.

ITSMERSH

#54 Post by ITSMERSH »

PaDS 1.1.4 uploaded.

See opening post.

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

Using PaDS as a simple SFS combiner

#55 Post by davids45 »

G'day RSH,

Thank you for continuing to investigate my problem when I'm using PaDS as a possible replacement in 64-bit Pups for the 32-bit-only SFS-Combiner.

I will test PaDS-1.1.4 and see how it goes and report back.

My apologies for using PaDS in a different way to how you meant PaDS to be used, so am grateful of your time spent looking at my 'off-topic' use of PaDS.

David S.

ITSMERSH

Re: Using PaDS as a simple SFS combiner

#56 Post by ITSMERSH »

davids45 wrote:G'day RSH,

Thank you for continuing to investigate my problem when I'm using PaDS as a possible replacement in 64-bit Pups for the 32-bit-only SFS-Combiner.

I will test PaDS-1.1.4 and see how it goes and report back.

My apologies for using PaDS in a different way to how you meant PaDS to be used, so am grateful of your time spent looking at my 'off-topic' use of PaDS.

David S.
Hi davids45.

No need to apologize.

Since I can't test PaDS under all Puppies and circumstances/uses, I'm dependent on reports where PaDS seems to need some updates/fixes/modifications.

I'm very interested to get this to work and to be used universal in all Puppies possible.

So, please continue to use/test/report. :D

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

PaDS114 success in 32-bit Pup

#57 Post by davids45 »

G'day RSH,
As a test, I ran PaDS-1.1.4 as an sfs in a 32-bit Frugal Pup, combining two large sfs files, one of many smaller applications already combined into one sfs, and a LibreOffice sfs.
This took a little time as these are 'full' sfs files not just sfs files made only of links as I usually do.
I then mounted the resulting sfs (almost 1GB :shock: ) and checked some of the .desktop files in it.
All checked had the extra lines from the earlier PaDS (1.1.3) combined sfs but the 'Name [en]=' line was now not blank but had duplicated the text of the 'Name='.
So the right-click 'Menu' for all these had text, not the blank lines as before.
A good result!!

Unfortunately, I could not make an sfs of PaDS-1.1.4 that would run in a 64-bit Pup. I think I did not get the right 'xdo..' lib file in the right lib directory so 64PaDS stalled with a gtk problem when I was trying to select the 'Load' sfs directory.
I could set the working directory and give the new sfs a name. The 32-bit PaDS-1.1.4 did not run in the 64-bit Pup when tried once.

I'll be away travelling for a couple of weeks so cannot sort out this 64-bit problem until back home - I don't have 64-bit Pups on my laptop and I can't take my desktop with its collection of 64-bit Pups on my travels :) .

In the meantime, maybe someone else on the forum can try PaDS-1.1.4 in a 64-bit Pup and let me know which version of 'xdotool' and its required lib needs to go where in a 64-bit system with its numerous lib directories and links, so 64PaDS-1.1.4 will combine many sfs into one with good menu texts.

Thanks,
David S.

ITSMERSH

Xdotool 64bit

#58 Post by ITSMERSH »

So the right-click 'Menu' for all these had text, not the blank lines as before.
A good result!!
That's good...

Attached Xdotool 64bit - probably will work?

Be careful when traveling. It's a weird world...

EDIT:

Extract the archive and do NOT copy the directory. Search for the binary and the lib and copy them separately to their desired location - directories in that archive are not for 64bit, sorry!
Attachments
Xdotool64-compiled-in-Tahr.tar.gz
Xdotool 64bit
(46.39 KiB) Downloaded 156 times

User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

64PaDS-1.1.4

#59 Post by davids45 »

G'day RSH,

I'm back from our trip to our drought-ridden outback, and after de-dusting the car, have managed to make a working sfs of PaDS-1.1.4 for my 64-bit Pups from your last post information.

I've attached this to this post so you can check the files against your originals. I deleted a .xcf icon that looked unnecessary, and put the 64-bit xo...so.2 lib file in both /usr/lib/ and in /usr/lib64/ as I don't know which is used. I cannot recall any other changes I made but there could be some :oops: .

From this 'full' sfs, I made an all-links PaDS sfs which also runs for me and will be the one shared to all my 64-bit Pups via a combined sfs of all my applications in link form.

Testing so far:
Using LxPupSc64-18.06+5, and putting the sfs files to combine in the working directory, I have made combined sfs of three 64-bit large browser sfs files.
I had to choose the 'All files' option, not the default "." option during adding the sfs files.
I ignore the PaDS second stage menu/desktop file editing as there are too many already in my sfs files being combined.

Next testing will be:
Make an all-in-one 64-bit sfs from about thirty sfs of my individual apps; this is what I do in 32-bit Pups with MU's SFS-Combiner that is incompatible in 64-bit Pups.

Thanks again for your efforts and help with this,

David S.

Post-script:
"Next testing" done, with a PaDS-combined sfs file (from about 30 original sfs files) now running my apps in this 64Xenial75 Pup.
No missing name text in any desktop file so right-click menus are all good.
Am adding 64PaDS114-links.sfs to my combined all-links-apps sfs file for each 64Pup group.
Attachments
64PaDS114a.sfs.gz
remove the trumped-up .gz and I hope you'll have a 'normal' 64-bit sfs to try out (not my all-links version)
(80 KiB) Downloaded 143 times

User avatar
01101001b
Posts: 123
Joined: Thu 09 Mar 2017, 01:20
Location: Buenos Aires, Argentina

#60 Post by 01101001b »

ITSMERSH wrote:PaDS 1.1.4 uploaded.
Quite an interesting tool! Thank you! ("This tool encourages laziness and rounding corners" :shock: There'll be always people who'll love to talk cr@p :roll: )

Regards!

Post Reply