PPM2

[mavrothal]

feature request.

I would like the search field to 'auto clear' on mouse over, like in the new pfind. would make it middle click friendly.

In pFind this is done only for the original text, "Search text", which in PPM2 does not exist. So middle click can be used fine.
To do it for any string would generate more problems than solution as if you try for example to correct your entry by moving the cursor with the mouse to another point would erase everything and you would have to retype it.
I guess this is the reason that Zig does not implement this for any string in pFind too.

what about a button to clear the field then?

I would rather not.
I think that another button there would be unnecessarily confusing and I do not think I have seen this in any other app, gtkdialog or not. I think you can always delete first and drag-select after if you are to middle-click in the field.
Another option would be to delete the entry after the search is done, but maybe some people want to search again say after the first installation of "music player"
Anyway, if anyone provides a patch for one or the other, I would certainly consider it.
Pock Zigbert

[666philb]

it's not that confusing.... see the clearfields addon for firefox & palemoon https://addons.mozilla.org/en-us/firefo ... ar-fields/

it's just a very handy feature. at the moment i inevitably already have the middle click primed and end up pasting it after whatever's already in the search field and then deleting the unwanted item.

all those wasted clicks

[mavrothal]

it's not that confusing.... see the clearfields addon for firefox & palemoon https://addons.mozilla.org/en-us/firefo ... ar-fields/

I avoid addons
I'm not sure if gtkdialog can do that (gtkdialog-experts please suggest)
The patch below clears the field and shows as in the picture (which I find ugly'sh)

Code: Select all

--- a/usr/local/petget/pkg_chooser.sh	2015-03-09 12:47:51.703307914 +0200
+++ b/usr/local/petget/pkg_chooser.sh	2015-03-09 14:59:12.820006982 +0200
@@ -458,7 +429,7 @@
       
         <text space-expand="true" space-fill="true"><label>""</label></text>
 
-        <entry width-request="80" activates-default="true" is-focus="true" secondary-icon-stock="gtk-find">
+        <entry width-request="80" activates-default="true" is-focus="true" primary-icon-stock="gtk-close" secondary-icon-stock="gtk-find">
           <variable>ENTRY1</variable>
           <action signal="activate">/usr/local/petget/findnames.sh all</action>
           <action signal="activate">refresh:TREE1</action>
@@ -466,6 +437,7 @@
           <action signal="secondary-icon-release">/usr/local/petget/findnames.sh all</action>
           <action signal="secondary-icon-release">refresh:TREE1</action>
           <action signal="secondary-icon-release">/usr/local/petget/show_installed_version_diffs.sh & </action>
+          <action signal="primary-icon-release">clear:ENTRY1</action>
         </entry>
       
         <text space-expand="true" space-fill="true"><label>""</label></text>

[666philb]

perfect!

thankyou

[mavrothal]

PPM2 is now in the testing branch woof-CE.

The updated pet (v2 not v2.0) in the first post has what is actually in woof-CE now and hopefully soon, in a puppy near you.

PPM bugs, for PPM2 or the original, can still be reported here.

[ASRI éducation]

PPM2 is now in the testing branch

Thank you mavrothal.
French translation is ready.

[MochiMoppel]

WARNING! Lengthy post ahead!

When I modified petget to work from console again, some gtk/pup-dialog warnings were made to work also in console via dialog, because a simple echo message is easy to miss among other console output.

Easy to miss? You are the master of the script. You can decide what terminal output the user sees and what not. Take the Puppy boot screen as an example. None of these lines stops and asks the user for confirmation. If you now flood the screen with useless debugging junk (set -x is new!) you shouldn't deplore that the user might miss an important message. Besides: The important - now dialogified - message is always one of the last two. It's hard to miss the last 2 messages appearing on the screen.

But I finally see the reason for our differences. You picture petget to be used interactively by a user, I see it as a tool to be used interactively and in scripts. I'm sure that we find a solution that addresses your and my concerns. My problem may be easier to understand when I describe my use cases.

Use case 1
As almost every user I use Puppy when X is running. As many users I don't use a savefile. To get Puppy ready after booting into the desktop I run a configuration script. One of the tasks in the script is to load some security and other pets, so part of the script may look like this:

Code: Select all

# Stop unneeded services
/etc/rc.d/init.d/cups stop

# Install newest openssl
petget /mnt/sdb1/pets/openssl-1.0.1k-i486-1_slack14.1.txz
petget /mnt/sdb1/pets/openssl-solibs-1.0.1k-i486-1_slack14.1.txz

#configure JWM
sed -i '/root[=:]/ s/3/6/' /etc/xdg/templates/_root_.jwmrc

While this script does its thing I want to go down and fetch my morning coffee. I expect the script to run unattended. As a master of ppm you probably can see immediately that this doesn't work. Petget has no silent mode, it is not scriptable. Although I obviously need no silly "Ready to install" and "Installed successfully" message, I can't suppress them.

Use case 2
This time I'm sitting in front of the screen. The task is to run the Midori browser. Since I seldom do, I keep the Midori package in a local folder, together with the necessary dependency pets. Unfortunately Midori requires 9 packages to install, too cumbersome to do it manually, so everything goes into a script:

Code: Select all

petget lib-blabla1.pet  #install dependency 1
petget lib-blabla8.pet  #install dependency 8
petget midori.pet       #install midori
midori                  #run midory
petget -lib-blabla8.pet #uninstall dependency 8
petget -lib-blabla1.pet #uninstall dependency 1

Here again I don't want to be bothered by messages. All I want to do is run the browser as quickly as possible, and when I'm done petget may uninstall the stuff - in silence! In an ideal world petget would install all pets in 20 seconds and the browser would load.

The problem
Logical next step: Stop the dialogs. There is one switch in petget and all its child scripts that determines if dialogs are displayed or not. If the variable $DISPLAY is empty, the scripts assume that I'm running without X and hence can't display GUI dialogs, so as a substitute they echo a message and return control back to petget. In order to silence the GUI dialogs, all I have to do is set $DIALOG to an empty string before entering the script and set it back to normal after the script is finished. Currently this works perfectly,but you probably can see that with ppm2 disaster looms.

At this point I should make clear that I'm not concerned about petget itself. I use my modified petget version and it is lean and fast and knows all tricks I want it to know, e.g. above mock script in use case 2 actually reads

Code: Select all

petget -q /mnt/sdb1/pets/midori   # quietly install all pets found in folder /mnt/sdb1/pets/midori 
midori                            # run midory
petget -uq /mnt/sdb1/pets/midori  # quietly uninstall all pets found in folder /mnt/sdb1/pets/midori 

I should be happy since the above $DISPLAY trick allows me to use the current child scripts installpkg.sh and removepreview.sh completely unaltered. Everything is accomplished just by a modified petget. But with the new, dialogified child scripts that come with ppm2 the ballgame changed. Consider above use case 2: If I run the midori script a second time while midori is running, the script will bump into the new "Hehe, already installed!" dialog for terminal use, and since $DISPLAY is empty, the screen doesn't respond. A freeze for an apparent reason and not a bug.

I see 2 ways out of this dilemma and both should be acceptable for you.

Solution 1
Provide an option to keep silent. You already introduced the flag /tmp/install_quietly. Be consequent and provide this option for ALL dialogs, not just a few. E.g. there is no option for the "Already installed" dialog. . This would allow me to abandon the $DISPLAY trick and would be consistent with ppm2. I wouldn't care any more about your beloved dialogs as long as I can prevent them.

Solution 2
The real solution will sound shocking for you: Remove ALL dialogs from child scripts, and I mean ALL - GUI and non-GUI.
Let me explain:
The code of installpkg.sh and removepreview.sh used to be integrated into petget. Then developers decided to put the code into separate scripts. This made it possible to access these installation and uninstallation routines from other scripts. The first to use them was downloadpkgs.sh (aka ppm) . These scripts are not designed to be used stand-alone, they are designed as little helpers for a parent script and they should act like any other command line tool used by the parent. As such they have only 2 functions: Receive an "order" from the parent, do what they are told to do and when they are finished report back to the parent. And when they run into trouble? They note what went wrong and report the error back to the parent. Command line tools NEVER report directly to the user in front of the screen or stop the flow with dialogs, they ALWAYS report only to the script from which they were called. It is the job of the parent script to decide, how to respond to messages from the various helper scripts and tools it is using.

Here an example of what is bad when children "speak" (hopefully understandable also for non-programmers):
When petget is ready to start installation it calls installpkg.sh, then twiddles its thumbs and waits patiently for installpkg.sh to report back with a success story. It knows that when it receives an "exit 0" it means OK and it can move on to call JWM to create the menu. Meanwhile the child installpkg.sh finds that the package is already installed. The child doesn't tell the parent right away, instead it stops and holds up a fancy placard: "Hey, there is nothing to do for me. The package is already installed". It then waits until the user tell him "OK, I've read it. Now put down the placard". Unfortunately the placard was visible to the whole world, but not to the parent. At least the child sends a message to the parent: "exit 1". When the parent receives the message, it stops its thumb twiddling and reads. It doesn't say "exit 0", so something must have gone wrong. But what? The child knows 20 different checkpoints from where it should report any errors. It does, but it always reports back "exit 1", nobody taught him how to count. The parent has not much to go for, and since it doesn't even know if the child flashed a placard, it has to hold up its own placard with a message as broad as possible: "Installation failed".

From a user perspective above example is a bad experience. The user receives 2 dialogs. The first one is pretty accurate and tells him not to worry. After all it should be good news that the installation is already done. Then immediately after that he sees a second message telling him that the installation "failed". Wouldn't it be so much better if he gets only one message? Would all 20 "exit 1" errors be properly numbered, petget would know what went wrong and issue a meaningful message. From a developer perspective it would mean less code in the child scripts, easier maintenance and with individual exit codes - I don't have to tell you that - much easier debugging.

I don't know if you embrace or even understand what I am trying to say. I'm not a teacher and I failed miserably in the past to make you understand my point, but having now dedicated 6 weeks of my lifetime to untangle this code chaos I don't want to see this effort go to waste.

[mavrothal]

MochiMoppel,
Let's first agree that there is no bug or freeze in PPM2.
You obviously run into touble when you try to utilise it in unintended ways (scripted). But this is a different "problem" and certainly not a PPM problem.

For the specifics now.
Petget is not designed to run unattended and I actually believe that to have the infrastructure for a completely silent/scripted package installation (ie without the user even knowing it!) is a very bad idea. Imagine a script or a pet that someone posts for fun, and its pinstall script uses this function to download and install anything in your puppy without you having a clue. Or you can imagine much more malicious approaches with such an infrastructure in place. Specially in a system that runs as "root" by default.
Of course I'm sure you are totally capable to revise petget to do that (and post it for others that may want to use it) but please do not ask for this to become the standard in Puppylinux. Much more do not call it a bug and do not "attack" the developers for not implementing it.

Regarding the messages from the various PPM scripts, you should keep in mind
a) that the same scripts are used in all different modes of PPM2 (including classic),
b) that letting the user knowing what is going on is in puppy culture (actually few pages back you participated in an "argument" supporting this)
c) that PPM is catering primarily to the average/novice linux user and its UI should be analogous
d) that (again) you use PPM2 in an an unintended and actually counter-advised way (scripted).
Once more, you can not "demand" your preferences to become the norm and assign "bugs" to anything that is not.

However, before you answer to any of these I would advise you to try the final version of PPM2 first.

[Jasper]

Hi mavrothal,

I first, successfully, uninstalled MochiMoppel's ppm pet; then I installed your latest version.

I was unimpressed that there was no facility to automatically update my chosen repositories and, for my personal preferences, it had nothing to offer - so I uninstalled it.

I got the brilliantly worded and supposedly helpful message shown in the screen shot and it seems to me that's a bug (or "my" problem).

My regards

[mavrothal]

I was unimpressed that there was no facility to automatically update my chosen repositories

You mean if you press the "update now" button in the "Update repositories" tab of the configuration/preferences window nothing happens or that you did not see/find the update button in the "Update repositories" tab or something else?

I uninstalled it.

I got the brilliantly worded and supposedly helpful message shown in the screen shot and it seems to me that's a bug (or "my" problem).

If I understand correctly the message says that the 'ppm_auto-2" package that you just removed, is removed!
If you are wondering why you get a PPM2 message since ppm2 is removed, is because (as always), what is removed is the files. The script is still running in the memory till you quit it or it exits normally (as all scripts do) and it's finishing the job it started. If you want to consider it a "bug" there is not much I can do about it.
If you mean something else, apologies for my limited understanding (again). Please explain.
All I can offer at this point regarding this issue is that I'm sure next time you open PPM will not be this "useless PPM2".
Thanks for your input.

[ASRI éducation]

Petget has no silent mode, it is not scriptable. Although I obviously need no silly "Ready to install" and "Installed successfully" message, I can't suppress them.

Of course I'm sure you are totally capable to revise petget to do that (and post it for others that may want to use it)

I agree with mavrothal. For most users, the use of PPM with silent mode seems risky.

There are a few months I needed a silent petget installation. I changed the original script and I renamed it petget-silent. I've never posted it but if needed...

Regards,

[bigpup]

b) that letting the user knowing what is going on is in puppy culture
c) that PPM is catering primarily to the average/novice Linux user and its UI should be analogous

I totally agree!!!
Any message telling you it is working, did or did not, are good to see.

There was a time (early days of PPM) when PPM told you nothing about what was happening.

You never really could tell if it was working or not.
When program packages were very small, it was not a real problem.
Most only took a few seconds to download or install.

When programs got bigger, downloads and installs took much longer.
PPM looked more like it was locked up and not working, when in fact, it was.

Adding info messages told you it is working or is not and why.

[bigpup]

I think MochiMoppel is trying to point out a better way (method) to code PPM.

I think mavrothal is saying.
I spent so much time on this thing.
I am just happy to see if it works at all and is usable.
We can figure out better coding methods later.

Here an example of what is bad when children "speak" (hopefully understandable also for non-programmers):
When petget is ready to start installation it calls installpkg.sh, then twiddles its thumbs and waits patiently for installpkg.sh to report back with a success story. It knows that when it receives an "exit 0" it means OK and it can move on to call JWM to create the menu. Meanwhile the child installpkg.sh finds that the package is already installed. The child doesn't tell the parent right away, instead it stops and holds up a fancy placard: "Hey, there is nothing to do for me. The package is already installed". It then waits until the user tell him "OK, I've read it. Now put down the placard". Unfortunately the placard was visible to the whole world, but not to the parent. At least the child sends a message to the parent: "exit 1". When the parent receives the message, it stops its thumb twiddling and reads. It doesn't say "exit 0", so something must have gone wrong. But what? The child knows 20 different checkpoints from where it should report any errors. It does, but it always reports back "exit 1", nobody taught him how to count. The parent has not much to go for, and since it doesn't even know if the child flashed a placard, it has to hold up its own placard with a message as broad as possible: "Installation failed".

From a user perspective above example is a bad experience. The user receives 2 dialogs. The first one is pretty accurate and tells him not to worry. After all it should be good news that the installation is already done. Then immediately after that he sees a second message telling him that the installation "failed". Wouldn't it be so much better if he gets only one message? Would all 20 "exit 1" errors be properly numbered, petget would know what went wrong and issue a meaningful message. From a developer perspective it would mean less code in the child scripts, easier maintenance and with individual exit codes - I don't have to tell you that - much easier debugging.

[bigpup]

Hi mavrothal,

I was unimpressed that there was no facility to automatically update my chosen repositories.
My regards

I think what he is talking about is when you click on "update now", it makes you decide on each repository to update or not.

What he wants is you click on "update now" and it just updates the repositories.
You do not have to decide anything else.

[mavrothal]

Hi mavrothal,

I was unimpressed that there was no facility to automatically update my chosen repositories.
My regards

I think what he is talking about is when you click on "update now", it makes you decide on each repository to update or not.

What he wants is you click on "update now" and it just updates the repositories.
You do not have to decide anything else.

I'm sorry, interpreting Pythia's words is not my strong point. Specially on a subject that was not the case in puppy and never came up before, when PPM2 was "open for suggestions".

Regarding automatic update of active repos, In contrast to other distros puppy leaves it up to the user which repos to use and to that extend which repo's to update. Updating only what is selected means that repos included latter will be outdated or be forced to re-update everything to update just one new repo. Given that updating some repos can also be a long and space demanding process since they need to be translated in a format PPM understands, is important the user to be in control.
Another consideration about the repo update process is that the 0setup script that does that is also used by woof in the puppy-building process and should behave accordingly.

So, to the person that wants to recode that part, you are very welcome, but please try to consider the above (and probably more).

[mavrothal]

I think MochiMoppel is trying to point out a better way (method) to code PPM.

I think mavrothal is saying.
I spent so much time on this thing.
I am just happy to see if it works at all and is usable.
We can figure out better coding methods later.

Here an example of what is bad when children "speak" (hopefully understandable also for non-programmers):
When petget is ready to start installation it calls installpkg.sh, then twiddles its thumbs and waits patiently for installpkg.sh to report back with a success story. It knows that when it receives an "exit 0" it means OK and it can move on to call JWM to create the menu. Meanwhile the child installpkg.sh finds that the package is already installed. The child doesn't tell the parent right away, instead it stops and holds up a fancy placard: "Hey, there is nothing to do for me. The package is already installed". It then waits until the user tell him "OK, I've read it. Now put down the placard". Unfortunately the placard was visible to the whole world, but not to the parent. At least the child sends a message to the parent: "exit 1". When the parent receives the message, it stops its thumb twiddling and reads. It doesn't say "exit 0", so something must have gone wrong. But what? The child knows 20 different checkpoints from where it should report any errors. It does, but it always reports back "exit 1", nobody taught him how to count. The parent has not much to go for, and since it doesn't even know if the child flashed a placard, it has to hold up its own placard with a message as broad as possible: "Installation failed".

From a user perspective above example is a bad experience. The user receives 2 dialogs. The first one is pretty accurate and tells him not to worry. After all it should be good news that the installation is already done. Then immediately after that he sees a second message telling him that the installation "failed". Wouldn't it be so much better if he gets only one message? Would all 20 "exit 1" errors be properly numbered, petget would know what went wrong and issue a meaningful message. From a developer perspective it would mean less code in the child scripts, easier maintenance and with individual exit codes - I don't have to tell you that - much easier debugging.

Let me repeat what I said before.
Please try to use the final version of PPM2.
The example quoted simple does not happen!!!

[Jasper]

Hi guys,

The message I published was not merely deficient in punctuation and spelling it was so poorly written as to be unintelligible, even misleading. Please read it again - very carefully.

I suggest it is redrafted and whilst I may not understand the intended meaning - if it has to always cover every possible outcome (simple or complex) I proffer the screen shot as a starter.

Words such as automatically and simultaneously should be read and used with care and whilst bigpup has understood exactly what I meant, he is incorrect in assuming what I wanted.

My regards

[bigpup]

Please try to use the final version of PPM2

OK.
I am confused.
Is the ppm_auto-2.pet in the first post the one you are talking about?

We no longer have a PPM2 that shows as V2?

Not sure if you know about this,

I am not sure if you added this as part of the ppm_auto-2.pet or it got added by Tahrpup updates.

In Tahrpup, when you run the Tahrpup updates, it adds the clear search field button in PPM.
So, this becomes part of PPM.

Seems to be working OK.

[Moat]

The message I published was not merely deficient in punctuation and spelling it was so poorly written as to be unintelligible, even misleading.

Agreed - the (mis)use of the english language in that posted statement is so poor as to be... almost... amusing! It makes no sense, at all.

Bob

[mavrothal]

bigpup,
what is in the first post is what is in woof-CE.
Phil is using an additional option he requested and I provide it, that is not included in woof-CE. I do not know if there are other changes in his version.
What I pointed out is that what MM was referring to and you quoted, was already changed few days back.
Jasper
Thanks. Now is clear what you were referring to (classifying this as a "bug" made it particularly difficult for me to understand since I was looking for functional issues that bugs usually imply).
If you find the opportunity you may want to reinstall and take a look at the install "view details" window and suggest analogous changes.
BTW "Listing of uninstalled dependencies still needed" is the wrong message and it would actually be a real bug if true and indeed PPM was removing needed packages.
The message suppose to suggest "Listing of installed dependencies that you may not need anymore"
Jasper, Moat (others)
I'm actually surprised that 4 months now no one offered any specific suggestions on wording, as English is neither mine nor Zigbert's native language (not to mention that the code rather than the message was our focus).
Text messages are also very easy to correct in the code without affecting any functions, other than your amusement, so I would be happy to incorporate them. The only concern should be to fit nicely in the available space and not be too wordy (which is particularly difficult for non english majors).