Puppy Linux Discussion Forum

MochiMoppel wrote: ↑Sun Jul 17, 2022 8:05 am

misko_2083 wrote: ↑Sun Jul 17, 2022 5:22 am

It can select multiple columns as well:

Code: Select all

P="8 9 a b c d e f"
for a in $P ;do for b in $P;do for c in $P;do
        COLORS=$COLORS"#$a$b$c|<span font='24' bgcolor='#$a$b$c'>      <span font='12' fgcolor='#000'>text</span><span font='12' fgcolor='#fff'>text</span>      </span>|FALSE|<big><tt>#$a$b$c</tt></big>|"
done;done;done
IFS=\|
yad --list --separator= --no-rules-hint --column=dummy --column='512 Pastell Colors' --column=Pick:CHK --column=Values $COLORS --hide-column=1 --print-all --geometry=320x600 | awk '/TRUE/{print substr($1,1,4)}'

Less "awk"ward :

Code: Select all

#!/bin/ash
P='8 9 a b c d e f'
for a in $P ;do for b in $P;do for c in $P;do
	COLORS=$COLORS"|#$a$b$c|<span font='24' bgcolor='#$a$b$c'>      <span font='12' fgcolor='#000'>text</span><span font='12' fgcolor='#fff'>text</span>      </span>|<big><tt>#$a$b$c</tt></big>|"
done;done;done
IFS=\|
yad --list --checklist --separator= --no-rules-hint --column= --column=dummy --column='512 Pastell Colors' --column=Values $COLORS --hide-column=2 --print-column=2 --geometry=330x600 

Yes awk-ward-less
For some reason it feels more comfortable to place the check button it in the middle.

^Previous script.

misko_2083 wrote: ↑Sun Jul 17, 2022 8:46 am

For some reason it feels more comfortable to place the check button it in the middle.

Let me guess why: You are used to have the checkbox toggled when you select anywhere in the row, but yad is a bit odd and doesn't work this way. Selecting a row doesn't do anything. It needs a double-click to toggle the checkbox ... or of course aiming for the box, but that's uncomfortable when the box is at the far end.

I find it more comfortable to select multiple rows in the traditional way: Ctrl+click or Shift+click for larger ranges. Also reduces clutter:

#!/bin/ash
key=$$
IFS=\|
for tab in 1 2 3 ;do
	COLORS=
	case $tab in
		1) P="0|3|6|9|c|f"		header='215 "Web Safe" Colors'	;;
		2) P="8|9|a|b|c|d|e|f"	header='512 Pastell Colors'		;;
		3) P="0|1|2|3|4|5|6|7"	header='512 Dark Colors'		;;
	esac
	for a in $P ;do for b in $P;do for c in $P;do
		COLORS=$COLORS"#$a$b$c|<span font='24' bgcolor='#$a$b$c'>      <span font='12' fgcolor='#000'>text</span><span font='12' fgcolor='#fff'>text</span>      </span>|<big><tt>#$a$b$c</tt></big>|"
	done;done;done
	yad --plug=$key --tabnum=$tab --list --multiple --separator= --no-rules-hint --column=dummy --column="$header"  --column=Values $COLORS --hide-column=1 --print-column=1  &
done
yad --notebook --key=$key --tab="Web Safe" --tab="Pastell" --tab="Dark" --tab-pos=bottom  --geometry=375x600

MochiMoppel wrote: ↑Sun Jul 17, 2022 1:16 pm

misko_2083 wrote: ↑Sun Jul 17, 2022 8:46 am

For some reason it feels more comfortable to place the check button it in the middle.

Let me guess why: You are used to have the checkbox toggled when you select anywhere in the row, but yad is a bit odd and doesn't work this way. Selecting a row doesn't do anything. It needs a double-click to toggle the checkbox ... or of course aiming for the box, but that's uncomfortable when the box is at the far end.

I find it more comfortable to select multiple rows in the traditional way: Ctrl+click or Shift+click for larger ranges.

Could be a habit. Maybe just ticking the end of the line seems natural if you are reading the line from left to right.

To add to the points already made, this is yad's manual about clicks and keys for the list widget.

manual yad 0.42.43 and yad 12.0.0 wrote:

--dclick-action=CMD
Set the CMD as a double-click command. When user double-clicked on row,
CMD will be launched with values of all columns as an arguments. By
default double-click selects row and act as OK button for simple
lists, set the checkbox if --checklist specified and do nothing when list
run with --multiple option. When double-click specified Enter acts as a
double-click and Ctrl+Enter acts as an OK button. CMD may contain a
special character `%s' for setting a position for arguments. By default
arguments will be concatenated to the end of CMD. If CMD starts with @,
its output will replace values of current row. This option doesn't work
with --editable.

--select-action=CMD
Set the CMD as a action when selection is changed. CMD will be launched
with values of all columns as an arguments. CMD may contain a special
character `%s' for setting a position for arguments. By default arguments
will be concatenated to the end of CMD. This option doesn't work with
--multiple.

step wrote: ↑Mon Jul 18, 2022 6:08 am

To add to the points already made, this is yad's manual about clicks and keys for the list widget.

manual yad 0.42.43 and yad 12.0.0 wrote:

--dclick-action=CMD
Set the CMD as a double-click command. When user double-clicked on row,
CMD will be launched with values of all columns as an arguments. By
default double-click selects row and act as OK button for simple
lists, set the checkbox if --checklist specified and do nothing when list
run with --multiple option. When double-click specified Enter acts as a
double-click and Ctrl+Enter acts as an OK button. CMD may contain a
special character `%s' for setting a position for arguments. By default
arguments will be concatenated to the end of CMD. If CMD starts with @,
its output will replace values of current row. This option doesn't work
with --editable.

--select-action=CMD
Set the CMD as a action when selection is changed. CMD will be launched
with values of all columns as an arguments. CMD may contain a special
character `%s' for setting a position for arguments. By default arguments
will be concatenated to the end of CMD. This option doesn't work with
--multiple.

One of those would be useful for sending selected color to clipboard through xclip.

Never a dull moment with yad

I thought that only --list would be suitable for my simple color stuff because --text would not obey dimension instructions. But there is --form. A field of type LBL combined with --scroll and --geometry would work - sort of.
Depending on font size LBL tends to break at whitespaces even when plenty of horizontal space is available. I can't figure out what the rule is. Does anyone know? As a remedy I can replace all ASCII spaces with non-breaking spaces   which makes the code hard to read, but if that's the way to go then so be it.

TEXT="<span bgcolor='#f88' font='58'>1 2 3 4 5 6</span>"
yad --form --field="$TEXT":LBL --geometry 500x150

MochiMoppel wrote: ↑Tue Jul 19, 2022 3:10 am

Never a dull moment with yad

I thought that only --list would be suitable for my simple color stuff because --text would not obey dimension instructions. But there is --form. A field of type LBL combined with --scroll and --geometry would work - sort of.
Depending on font size LBL tends to break at whitespaces even when plenty of horizontal space is available. I can't figure out what the rule is. Does anyone know? As a remedy I can replace all ASCII spaces with non-breaking spaces   which makes the code hard to read, but if that's the way to go then so be it.

Code: Select all

TEXT="<span bgcolor='#f88' font='58'>1 2 3 4 5 6</span>"
yad --form --field="$TEXT":LBL --geometry 500x150

label_breaks_line.png

It's better not to depend on text wrapping and font size.
It can behave differently depending on the theme and Gtk3 does text wrapping differently.

BEGIN="<span bgcolor='#f88' font='40'>"; END="</span>"
yad --form --field="${BEGIN}1 2${END}":LBL --field="${BEGIN}3 4${END}":LBL  --geometry 500x150 --scroll

misko_2083 wrote: ↑Tue Jul 19, 2022 8:04 am

It's better not to depend on text wrapping and font size.

I don't want to depend on text wrapping, I want to prevent it. Unfortunately yad lacks a --no-wrap option.
Your code, apart from suffering from the same dependence, is not an option as in my case the LBL text contains more than 100 lines, with defined line feeds after x characters. I don't want yad to meddle with it.

Indeed annoying that LBL does unexpected wrapping.
Don't know if it's useful for your purpose, but no wrap using BTN :

TEXT="<span bgcolor='#f88' font='100'>1 2 3 4 5 6</span>"
yad --form --field="$TEXT":BTN --geometry 500x150

fredx181 wrote: ↑Tue Jul 19, 2022 10:23 am

Don't know if it's useful for your purpose, but no wrap using BTN:

Not useful but interesting

What I also find interesting is that LBL, though essentially a very simple object, seems to struggle with Pango. I've commented out 2 lines of my previous example that use --list and replaced them with --form and a LBL field. While the list version needs no more than 4sec to display its window, the LBL version needs 11sec. That's a huge delay. Maybe LBL is not designed to handle a very long string. Definitely LBL is out of the race.

key=$$
IFS=\|
sp1=' '                         # 1 non-breaking space
sp6=$sp1$sp1$sp1$sp1$sp1$sp1    # 6 of them
for tab in 1 2 3;do
    COLORS=
    case $tab in
        1) P="0|3|6|9|c|f"      header='215 "Web Safe" Colors'  ;;
        2) P="8|9|a|b|c|d|e|f"  header='512 Pastell Colors'     ;;
        3) P="0|1|2|3|4|5|6|7"  header='512 Dark Colors'        ;;
    esac
    for a in $P ;do for b in $P;do for c in $P;do
#~     COLORS=$COLORS"#$a$b$c|<span font='24' bgcolor='#$a$b$c'>      <span font='12' fgcolor='#000'>text</span><span font='12' fgcolor='#fff'>text</span>      </span>|<big><tt>#$a$b$c</tt></big>|"
       COLORS=$COLORS"<span font='24' bgcolor='#$a$b$c'>$sp6<span font='12' fgcolor='#000'>text</span><span font='12' fgcolor='#fff'>text</span>$sp6</span>$sp1<big><tt>#$a$b$c</tt></big>"$'\n'
    done;done;done
#~  yad --plug=$key --tabnum=$tab --list --multiple --separator= --no-rules-hint --column=dummy --column="$header"  --column=Values  $COLORS   --hide-column=1 --print-column=1  &
    yad --plug=$key --tabnum=$tab --form --field="$COLORS":LBL  --scroll  &

done
yad  --notebook --key=$key --tab="Web Safe" --tab="Pastell" --tab="Dark" --tab-pos=bottom  --geometry=375x600

MochiMoppel wrote: ↑Sun Jul 24, 2022 6:31 am

What I also find interesting is that LBL, though essentially a very simple object, seems to struggle with Pango [...]

I recall having read that GtkLabel widgets aren't meant for a lot of text. This is what I found in gtk2's documentation (gtk3 and gtk4 also say the same).

https://www.manpagez.com/html/gtk2/gtk2-2.24.28/GtkLabel.php wrote:

Description
The GtkLabel widget displays a small amount of text.
[...]
Text layout
A label can contain any number of paragraphs, but will have performance problems if it contains more than a small number.
[...]

Why then :LBL in yad's --form takes 11sec vs. 4sec. for :LBL in --list, my guess, without looking at the source code, is that the gtk widget that implements a list includes its own faster implementation of a "label", while --form uses the slower, vanilla GtkLabel implementation.

step wrote: ↑Sun Jul 24, 2022 9:57 pm

Why then :LBL in yad's --form takes 11sec vs. 4sec. for :LBL in --list, my guess, without looking at the source code, is that the gtk widget that implements a list includes its own faster implementation of a "label", while --form uses the slower, vanilla GtkLabel implementation.

My guess was that lists are defined to be chunks of text (records) and that some kind of parallel processing is going on while a label is processed sequentially, being slow in case of markup.

Not a good guess because even with option --no-markup the speed doesn't improve.
And why is it that the stand-alone LBL widget is slow, but other field labels are not? I would assume that button labels are expected to be much shorter than LBL widgets and therefore are implemented with even more restrictions, but surprisingly using --form field types BTN, CLR, TXT, RO etc. instead of LBL will render the window in 4sec. Their huge labels create no speed problems.

MochiMoppel wrote: ↑Tue Jul 19, 2022 9:29 am

Unfortunately yad lacks a --no-wrap option.

It's trivial to add it to the LBL field in the form dialog.
Keep in mind the window is expanded to fit the label so add --scroll option for very long labels.

@step Pushed to your branch. Needs to be added to the manual after, if you want to merge.

 TEXT="<span bgcolor='#f88' font='64'>1 2 3 4 5 6 7 8 9 10 11</span>"
 ./yad --form --no-wrap --field="$TEXT":LBL --geometry 500x150

  ./yad --form --no-wrap --field="$TEXT":LBL --geometry 500x150 --scroll

 ./yad --form --field="$TEXT":LBL --geometry 500x150

misko_2083 wrote: ↑Tue Jul 26, 2022 7:12 am

It's trivial to add it to the LBL field in the form dialog.

Trivial for whom?

Keep in mind the window is expanded to fit the label so add --scroll option for very long labels.

Keep in mind that I was using an older version. I'm now in Slacko 8 with yad 0.42.43 (GTK+ 3.24.31) where the bug does not exist anymore. With
yad --form --field="$TEXT":LBL --geometry 500x150 the label expands and does not wrap, regardless of font size (looks like in your first screenshot). Everything seems to be OK now.

MochiMoppel wrote: ↑Tue Jul 26, 2022 8:13 am

misko_2083 wrote: ↑Tue Jul 26, 2022 7:12 am

It's trivial to add it to the LBL field in the form dialog.

Trivial for whom?

Keep in mind the window is expanded to fit the label so add --scroll option for very long labels.

Keep in mind that I was using an older version. I'm now in Slacko 8 with yad 0.42.43 (GTK+ 3.24.31) where the bug does not exist anymore. With
yad --form --field="$TEXT":LBL --geometry 500x150 the label expands and does not wrap, regardless of font size (looks like in your first screenshot).

I fetched step(bro)'s yad and compiled.
It happens with gtk2.

./yad --version
0.42.43 (GTK+ 2.24.33)

And latest yad 12 (Gtk3).

yad --version
12.0 (GTK+ 3.24.24)

MochiMoppel wrote: ↑Tue Jul 26, 2022 8:13 am

yad --form --field="$TEXT":LBL --geometry 500x150 the label expands and does not wrap, regardless of font size (looks like in your first screenshot).

If it does not wrap it could be a bug.
Wrapping in on by default.

MochiMoppel wrote: ↑Tue Jul 26, 2022 8:13 am

Keep in mind that I was using an older version. I'm now in Slacko 8 with yad 0.42.43 (GTK+ 3.24.31) where the bug does not exist anymore. With
yad --form --field="$TEXT":LBL --geometry 500x150 the label expands and does not wrap, regardless of font size (looks like in your first screenshot).

Just tested here:
Fatdog64-812 with yad 0.42.43 (GTK+ 2.24.33) yad --form --field="$TEXT":LBL --geometry 500x150 and echo ${#TEXT} 12252 ($TEXT without \n and markup):
the label wraps and the yad window expands outside the root window (add --scroll to contain).

Repeating the same test with yad 0.42.43 (GTK+ 3.24.33) prints the following gtk3 error:
(yad_gtk3:15873): Gdk-WARNING **: 11:39:52.027: Native Windows wider or taller than 32767 pixels are not supported
in this case yad keeps running but there is no visible window.

misko_2083 wrote: ↑Tue Jul 26, 2022 8:26 am

I fetched step(bro)'s yad and compiled.
It happens with gtk2.

Code: Select all

./yad --version
0.42.43 (GTK+ 2.24.33)

And latest yad 12 (Gtk3).

Code: Select all

yad --version
12.0 (GTK+ 3.24.24)

Confirmed. yad 12.0 (GTK+ 3.24.31) and yad 0.42.43 (GTK+ 2.24.33) yield the same result here.

step wrote: ↑Tue Jul 26, 2022 9:58 am

Repeating the same test with yad 0.42.43 (GTK+ 3.24.33) prints the following gtk3 error:
(yad_gtk3:15873): Gdk-WARNING **: 11:39:52.027: Native Windows wider or taller than 32767 pixels are not supported
in this case yad keeps running but there is no visible window.

Fair enough I like this subtle sense of humor:

(yad:31109): Gdk-WARNING **: 19:39:09.988: Native Windows wider or taller than 32767 pixels are not supported
(yad:31109): Gtk-WARNING **: 19:39:14.378: infinite surface size not supported

step wrote: ↑Tue Jul 26, 2022 9:58 am

MochiMoppel wrote: ↑Tue Jul 26, 2022 8:13 am

Keep in mind that I was using an older version. I'm now in Slacko 8 with yad 0.42.43 (GTK+ 3.24.31) where the bug does not exist anymore. With
yad --form --field="$TEXT":LBL --geometry 500x150 the label expands and does not wrap, regardless of font size (looks like in your first screenshot).

Just tested here:
Fatdog64-812 with yad 0.42.43 (GTK+ 2.24.33) yad --form --field="$TEXT":LBL --geometry 500x150 and echo ${#TEXT} 12252 ($TEXT without \n and markup):
the label wraps and the yad window expands outside the root window (add --scroll to contain).

Repeating the same test with yad 0.42.43 (GTK+ 3.24.33) prints the following gtk3 error:
(yad_gtk3:15873): Gdk-WARNING **: 11:39:52.027: Native Windows wider or taller than 32767 pixels are not supported
in this case yad keeps running but there is no visible window.

misko_2083 wrote: ↑Tue Jul 26, 2022 8:26 am

I fetched step(bro)'s yad and compiled.
It happens with gtk2.

Code: Select all

./yad --version
0.42.43 (GTK+ 2.24.33)

And latest yad 12 (Gtk3).

Code: Select all

yad --version
12.0 (GTK+ 3.24.24)

Confirmed. yad 12.0 (GTK+ 3.24.31) and yad 0.42.43 (GTK+ 2.24.33) yield the same result here.

When the label is long the window size is increased to display everything even if it goes beyond the screen.
No need to use the form at all, regular window with --text behaves the same. yad --text="$TEXT" --geometry 500x150 where text is very long.

(yad:3269): Gdk-WARNING **: 09:08:34.790: Native Windows wider or taller than 32767 pixels are not supported

But labels are meant to be just labels. When we make a jam we don't write a long text on a jar. We just label it with big letters.
Otherwise we would have to use very small letters to fit.
That's how jam jars work.

In the latest yad markup for TXT fields was added, I'll see later how it works with --no-wrap.
Gtk text views are made for long texts.

if this is how to theme gtk2

dark) GTK2_RC_FILES="$track/gtkrc_snapp" yad --list --plug=$$  <& 9 &

How to theme gtk3?? It is not obvious.

stemsee wrote: ↑Thu Jan 19, 2023 1:18 pm

if this is how to theme gtk2

Code: Select all

dark) GTK2_RC_FILES="$track/gtkrc_snapp" yad --list --plug=$$  <& 9 &

How to theme gtk3?? It is not obvious.

It's different (css styling) and a bit more complicated, I've done some investigating, see here; https://forum.puppylinux.com/viewtopic.php?t=5343 and also here: https://forum.puppylinux.com/viewtopic.php?t=6855
(focused on gtkdialog, but should work with yad gtk3 too)

thanks @fredx181/mention]

That was a good read....caught up on a lot!
cheers

Does anyone know how to output data from yad --text-info without closing?

misko_2083 wrote: ↑Tue Mar 01, 2022 11:58 am

Stemsee this question in google groups got me thinking.
https://groups.google.com/g/yad-common/c/V9Ud3ShAjAk

What if there are two lists in the paned diaog?

Code: Select all

#!/bin/bash
key=$RANDOM

yad --plug=$key --tabnum=1 \
   --select-action="printf '%b\n%b\n%b\n' %s" \
   --list \
   --column=Ne --column=ID --column=EMAIL \
     1 ID mail 7 ID mail 20 ID mail \
| yad --plug=$key --tabnum=2 \
      --list --print-all \
      --editable \
      --row-action="echo -e \"1\\n2\\n3\\n\"" \
      --tail \
      --listen --cycle-read \
      --column=No --column=ID --column=EMAIL &

yad --paned --key=$key --center --orient=Horizontal --splitter=200 --width=800 --height=600

Instead of --select-action, double cick --dclick-action is an alternative here.
This line --select-action="printf '%b\n%b\n%b\n' %s" separates the columns from the output into newlines so it can be piped to another list.
This would work too --select-action="printf '%q\n%q\n%q\n' %s"
For clearing the list in the right pane, fifo pipe can be used instead to send the form feed character.
Or with --editable (like in the script above) to delete the rows by right clicking them and selecting the option from the context menu.
There is also row action which defines the command run when a row is added, deleted or edited.
That list has to have --editable option.
In this script that would be --row-action="echo -e \"1\\n2\\n3\\n\""

Ahh! It took a while, but I finally got it!

stemsee wrote: ↑Thu Jan 19, 2023 8:05 pm

thanks @fredx181/mention]
Does anyone know how to output data from yad --text-info without closing?

If you're using the latest yad 12.x series, then right-click the text-info dialog to find "save" and more options:

--text-info --editable --file-op and right-click white area for save option

--text-info --editable will output text to stdout

For yad 0.42.43 ....

Not possible - --text-info is not a text output dialog; it's for viewing text only.

However, you could add a --button with an associated click action to save the contents of text-info dialog to a file of your liking. Trivially, if you run --text-info --filename=FILE.txt then save FILE.txt to some other file. Same if you run --text-info < FILE.txt. If you run PROCESS | yad --text-info... first create a backing file with tee or awk, such as

PROCESS > tee /tmp/FILE.txt; yad --text-info --button="save!command_to_save_/tmp/FILE.txt_to_desired_file" < /tmp/FILE.txt

All of the above untested.

step wrote: ↑Sat Jan 21, 2023 1:22 pm

you run PROCESS | yad --text-info... first create a backing file with tee or awk, such as

PROCESS > tee /tmp/FILE.txt; yad --text-info --button="save!command_to_save_/tmp/FILE.txt_to_desired_file" < /tmp/FILE.txt

So I do not see that edits in text-info would be saved....isn't it just re-saving the input file as is, to some new file? I will test it out. If it doesn'T work then a quick and automatic close and reopen would do it. Would it be possible to close a plug, without crashing it, and reopen in the same paned gui?

stemsee wrote: ↑Sat Jan 21, 2023 1:32 pm

step wrote: ↑Sat Jan 21, 2023 1:22 pm

you run PROCESS | yad --text-info... first create a backing file with tee or awk, such as

PROCESS > tee /tmp/FILE.txt; yad --text-info --button="save!command_to_save_/tmp/FILE.txt_to_desired_file" < /tmp/FILE.txt

So I do not see that edits in text-info would be saved....isn't it just re-saving the input file as is, to some new file?

Editing text-info text in yad 0.42.43 is not possible. You must use yad 12.x to be able to edit text in a text-info dialog. For 12.x I showed you --editable --file-op, that's how you can edit (and save with right-click) and output (edited) text.

Would it be possible to close a plug, without crashing it, and reopen in the same paned gui?

No.

Yes, i got it, i'm just trying to save user from 'leg work' , in 0.42.43 there is also right click > select all > copy, then User could paste into a new document and save .... but that's about 8 clicks....not efficient. It has to be one click or not at all!

EDIT: When i type into the text-info window, there has to be a buffer holding the content, and I just need to flush that buffer to file....easy peasy! Or ... have the button command set off a function with xdotool to automate copy paste and save as "$1".

If text-info isn't a specific requirement, you could use --form instead:

yad --form --field=:txt "$(cat FILE.txt)"

this will allow editing and prints to stdout. You'll need to pipe it into sed to expand "\n" to newline.

As a matter of reviewing and / or editing bash scripts frontended with yad I think that a simple convention of function naming is in order. Maybe conventions already exist which I know nothing about. But I think it will be in good form if we can name functions for list and form in an agreed pattern especially for yad --list

--select-action "selectfn" or "single_clickfn"
--dclick-action "dclickfn" or "double_clickfn"
--row-action "rowfn" or "row_actionfn"

naming according to the trigger of the function rather than the purpose of these particular functions.

numbers can be intrafixed between the 'body' and the -fn, "select_2_fn" for subsequent yad --list instances in the same script. I realise that yad --form presents more difficulty but the buttons could by ordered by alphabet and or number. Maybe it seems impersonal, but I bet it would make debugging, or editing by others simpler.

As computing power increases I believe there is evidence that bash scripts will be closer in performance to assembly rather than further away, eventually making the difference negligible.

Any thoughts?

why aren't these loops outputting scale values?

 yad --form --field=:SCL "bash -c \"while sleep 1; do printf "%s\n" "%1"; done \""  --field=:SCL "bash -c \"while sleep 1; do printf "%s\n" "%2"; done \"" --field=:SCL "bash -c \"while sleep 1; do printf "%s\n" "%3";  done \"" --print-partial &