bluem / pashua Goto Github PK

It appears that Pashua is not currently a signed application, which means that it isn't passing Apple's application notarization requirement. It doesn't appear to be affected on Intel based Mac computers, but is an issue on the M1. I'm unable to launch Pashua.

The link to the Pashua homepage doesn't work; it just opens the "projects" page in bluem.net, which suggests GitHub back under the Pashua heading. So I could only find some docs for Pashua in archive.org.

Similarly, the link to your thoughts on Apple is broken, and I suspect that'd be a valuable thing to have.

A script I run that uses Pashua reported this error in the log but I can't find any information about it:

2019-08-19 12:30:11.240 Pashua[60263:767515] apply_selection_policy_once: avoid use of removable GPUs (via net.bluem.pashua:GPUSelectionPolicy->avoidRemovable)

Is this just a notification or a terminating error?

Over the years, requested by a number of users: being able to control the order in which a user can tab through the elements.

I would like to contribute Dutch localization.
If that's OK, I'll work on a PR.

I have XCode 10, how do I deal with that? Just work from it, but only commit added resource files to git?

I've noticed that Pashua will assign focus (which UI element is highlighted and ready to accept input) to the first element of "text" type. Is there some way to disable focus or define it manually?

As JSON is ubiquitous and supported in every major language, Pashua should optionally support returning dialog data as JSON. In addition, it should be feasible to read the configuration as JSON instead of Pashua’s proprietary format.

Using the examples supplied with Pashua, I'm getting the following error:

Pashua was called with the deprecated -e option, which has been ignored since 2014. Please do no longer use this option.

What needs to be done to get rid of that error?

FYI, the phrase "Please do no longer use this option." is not proper English. One of the following is better:

"Don't use this option any longer."

"No longer use this option."

And while the use of "please" is nice and polite, it's really not needed in this context.

Marc

BTW, I just started using Pashua the other day and I'm blown away by what it allows me to do. Finally I can write graphical front ends to my PHP scripts. Nice!

defaultbutton and cancelbutton are not always needed in a GUI since you can create custom buttons and cancel the dialog by either clicking the window or quitting the app.

Example:
Embedding custom buttons to have a user select an option doesn't require a confirmation button for the dialog.

Hello Carsten,

I love the new dark modes. But it seems like I'm missing a step or setting that needs to be done before compiling the project with Xcode because some variables don't get populated. I'm not even sure if this is an Xcode thing or if you run a script before building. (I'm not very experienced in Xcode at all.)

In any case, the about window still shows the variable names (or template strings?):

The documetation.html file doesn't get build at all and is missing from the app file. Another indication of a build step that I'm missing here because the source file is an XML file.

Thanks a lot for keeping Pashua alive because I use and love it for years now. Pashua brought shell scripts to a whole new level for me!

This would be more consistent with other parts of macOS or Apple software.

It's possible you get the following error message with Pashua:

Or textual:

-[__NSCFString count]: unrecognized selector sent to instance 0x7f91e05237d0

This is probably due to misspelling option on a popup-control (or combobox/radiobutton), so you should fix your Pashua-configuration (workaround).

However, Pashua should provide a proper error message for this.

There is a bug when pasting text into a textfield that contains a newline.

When you have a Pashua form with the following control:

name.type = textfield
button.type = defaultbutton

and you copy/paste the following text into it (only select one newline):

Line one
Line two

When pasting you see the text Line two in the textfield. When you leave the field by pressing the tab-key, you see 'Line one`. Now press the OK button. Pashua will return the following text:

name=Line one
Line two
button=1

Expected behaviour

For starters, when pasting the newlines should be removed (or replaced by spaces).

Also, a control should never output text with multiple lines. When not converting new lines, Pashua should return this (like a textbox control would handle it:

name=Line one[return]Line two
button=1

Pashua’s current dialog configuration is ugly, redundant and verbose, and as it is a proprietary format, there is no 3rd party code which could be used for parsing it.

It seems to me that using YAML instead would be a much better fit. As this would be a BC break, a feasible approach (on the Pashua side) could be: try to parse the dialog configuration as YAML, then use the Pashua legacy format. This ways, Pashua users could choose when to migrate their scripts.

Pashua should open any file with the .pashua extension. That would be very useful when you are developing forms. Just double click the form in Finder, and Pashua shows the form.

I've made a proof of concept which will spawn an AppleScript app that handles the "on open". When the Pashua form is closed, the output will be written to a log-file which can be viewed with Console.app (however I'm hardly using that functionality. It's mostly checking if it looks right).

I'd like to say a huge "thanks" to Carsten for this incredible resource. I've been building apps with Pashua for a few months now and am deeply indebted to this project.

I'm wondering if there might be plans to implement any type of support for grouping UI elements. I'm currently using a solution involving loading png images to use as horizontal rules, but I'd really love to see something like this:

Given the nature of this project, I'm sure there's frequent requests for functionality (such as interaction with a script, or nested modals) that fall outside its scope. I'm hoping this isn't one such idea.

My thinking is that a user could define the beginning and end of element groups using a syntax like this:

*.groups = 2
*.group = soccer
*.group = hockey

soccer.txt.type = textfield
soccer.txt.default = This element is in Group 1

hockey.txt.type = textfield
hockey.txt.default = This element is in Group 2

In addition to being able to declare elements as mandatory, it would be nice to be able to define valid / invalid input, for example through a RegEx.

This would be much easier to build if Pashua had a working implementation of #1 on which this feature could be based.

When launching this configuration:

d.type = date
d.label = Example date
d.default = 2007-05-30 17:00
d.time = 1

I get this dialog (which looks slightly different than the one in the docs):

How can the user see wether the time is AM or PM?

PS: I'm on OS X 10.11.6, Pashua v 0.10.3

Ran into this issue while building out a workflow using Pashua in a zsh script (the default in macOS Catalina). Normally I would just switch over to either bash or sh but I am specifically using zsh for associative arrays.

When running in bash/sh I have no issue. When I run zsh I get the following:

(eval):3: command not found: txfUserName
(eval):5: command not found: txfAssetTag
(eval):6: command not found: popBuilding

Which occurs for every element variable I try to return.

Any suggestions?

This is how my config is configured:

txfAssetTag.type = textfield
txfAssetTag.label = Asset Tag
txfAssetTag.default = " "
txfAssetTag.width = "$confWidth"
txfAssetTag.x = 180
txfAssetTag.y = 150

popBuilding.type = popup
popBuilding.label = Building
popBuilding.option = $PashuaBuildingNames
popBuilding.width = "$confWidth"
popBuilding.mandatory = 0
popBuilding.x = 180
popBuilding.y = 100

Motivation: choosing the optimum position and size. The generic approach currently used does not work equally well for controls as different as a textfield and radiobuttons

Pashua exits with zero even when loading a pashua template with errors. Pashua shows a dialog window describing the error, but does not exit non-zero. I would expect that the exit code is different from 0, when the program encounters an error of any kind.

Calling Pashua from within bash scripts, it would be useful to detect such failures and act accordingly. Since there are no variables set by Pashua after such an error and no output given neither after successful nor unsuccessful exit, an error can't be detected easily.

With an exit code, it would be easier:

pashua_run "my_template_with_errors.pashua"
if [ $? -ne 0 ]; then
  # treat error
elif [ $cb -eq 1 ]; then
  # cancel was pressed
...

Please introduce exit codes for Pashua. Thank you!