(old)Puppy Linux Discussion Forum

zigbert wrote:

jpeps wrote:Wouldn't it be posible to eliminate the timer altoget<action>if true refresh:UPDATE_GUI</action>
her? If something like a new track gets played, an input file gets flagged and the checkbox gets refreshed.

What will make the checkbox reread the inputfile?

jpeps wrote:I don't know what the user clicks to play a track, but something like: (This is linked to another checkbox).

<action>if true refresh:UPDATE_GUI</action>

zigbert wrote:

jpeps wrote:I don't know what the user clicks to play a track, but something like: (This is linked to another checkbox).

<action>if true refresh:UPDATE_GUI</action>

This would only work for song the user actually clicked on (or selected by keyboard). But what about the next song in the playlist ...

jpeps wrote:I guess flagged processes would need to be handled on the script level, which might include loading a new window.

zigbert wrote:

jpeps wrote:I don't know what the user clicks to play a track, but something like: (This is linked to another checkbox).

<action>if true refresh:UPDATE_GUI</action>

This would only work for song the user actually clicked on (or selected by keyboard). But what about the next song in the playlist ...

#!/bin/sh
Fifo=/tmp/myfifo
[ -p "$Fifo" ] || mkfifo "$Fifo"

# First process, runs in background with stdout tied to "$Fifo"
for i in $(seq 1 10) ; do
	echo $i
	sleep 1
done > "$Fifo" &

# Second process, event bound (without timer wakeups)
# This loop will terminate when the OTHER END of the pipe is released (by the above process)
while read j ; do
	echo "read $j"
done < "$Fifo"

rm "$Fifo"

#!/bin/sh
Fifo1=/tmp/myfifo1
[ -p "$Fifo1" ] || mkfifo "$Fifo1"
Fifo2=/tmp/myfifo2
[ -p "$Fifo2" ] || mkfifo "$Fifo2"

process1(){
for i in $(seq 1 3) ; do
	echo $i >&3
	sleep 1
	echo $((i*2)) >&4
	sleep 1
done
}

process1 3> "$Fifo1" 4> "$Fifo2" &

while read j ; do
	echo "j=$j"
done < "$Fifo1" &
while read k ; do
	echo "k=$k"
done < "$Fifo2" &

wait

rm "$Fifo1"
rm "$Fifo2"

So maybe have a shell embedded inside a widget that has a loop that reads from a fifo...

zigbert wrote:

So maybe have a shell embedded inside a widget that has a loop that reads from a fifo...

That is the basic issue with both a progressbar and a timer. It is not the widget itself that uses cpu-power, but the checking loop.


Thank you, I did not know there was something called FIFO!!!
Sigmund

mkfifo /tmp/newFifo 

FifoScript >/tmp/newFifo &

while read n; do
echo "in newFifo"
echo "$n"
done < /tmp/newFifo &

wait
rm /tmp/newFifo

technosaurus wrote:Note: if you echo something to the fifo while a dialog is already displayed, gtkdialog eats it. If we knew where/why the data goes it could be useful knowledge (such as for interprocess communication for stopping/starting/modifying etc...), but until then we just need to close one before opening another.

If you only look at top, it appeared to drastically reduce usage, but I wrote a little C program that gives real memory usage and it turns out that top double dips and will tell you that you have 256Mb used on a 128Mb system if you are running the same program (because the kernel will re-use readonly pages for new instances)

brokenman wrote:
Is it possible to have the dot folders (hidden folders) visible for selection?

find a file on your system something like /root/.config/gtk-2.0/gtkfilechooser.ini
In it there is a setting `ShowHidden=false`. Change it to true.