GtkDialog - tips

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#661 Post by jpeps »

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?
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>

I don't know if the refresh could be triggered by some some initiated process. Probably the user would have to click on something.

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#662 Post by zigbert »

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
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#663 Post by jpeps »

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 ...
I guess flagged processes would need to be handled on the script level, which might include loading a new window.

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#664 Post by zigbert »

jpeps wrote:I guess flagged processes would need to be handled on the script level, which might include loading a new window.
If that was acceptable for the project, it would sure be a working solution.


Sigmund

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#665 Post by technosaurus »

I think there was a partial fix in svn for this already, but for slow to start apps instead of:

Code: Select all

export MAIN='...stuff...'
gtkdialog -p MAIN
Try

Code: Select all

gtkdialog -s <<< '...stuff...'
Or

Code: Select all

gtkdialog -s < /pathto/file
This also works, but will need to make sure previous dialogs are closed before echoing a new one

Code: Select all

#!/bin/sh
mkfifo /tmp/gtkmsg
while ([ -e /tmp/gtkmsg ]) do
gtkdialog -s < /tmp/gtkmsg 2>/dev/null
done &
now you can just echo your dialogs to /tmp/gtkmsg and they will start even faster since gtkdialog is already running

you can still pipe the output of the while loop through a while-read-case like this:

Code: Select all

#!/bin/sh
mkfifo /tmp/gtkmsg
while ([ -e /tmp/gtkmsg ]) do
gtkdialog -s < /tmp/gtkmsg 2>/dev/null |while read LINE || [ "$LINE" ] ;do
  case "$LINE" in
#your case here:
    *=*)eval $LINE;;
    *)echo "$LINE";;
  esac
done &
HTH
-Brad

Edit: forgot to mention, use rm -f /tmp/gtkmsg to stop the gtkdialog daemon process
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#666 Post by Dougal »

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 ...
This can be done with a fifo:

Code: Select all

#!/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"
Note that you can also use different file descriptors (rather than stdout): my distro-building script has functions that are redirected to/from more than one fifo.
For example:

Code: Select all

#!/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...
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#667 Post by zigbert »

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

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#668 Post by jpeps »

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
Interesting thing, you can create chains of them to run at any time. Name the above script FifoScript and:

Code: Select all

mkfifo /tmp/newFifo 

FifoScript >/tmp/newFifo &

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

wait
rm /tmp/newFifo

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#669 Post by technosaurus »

One other usage for named pipes (a.k.a. fifo) and gtkdialog would be to go ahead and spawn gtkdialog while computing needed data to generate the gui, so that gtkdialog is ready to go as soon as the data is ready.

Another would be to handle child window that you only want open one at a time. You can close the other child window and simply echo the variable(s) containing the child dialog to the pipe.

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.

Side note: I started learning about named pipes because I was building multicall binaries and wanted to see the difference in resource usage if it just forked /proc/self/exe, so I needed a way to communicate back to the original running program. 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) so it turned out to be pretty unnecessary except as a useful learning excercise. Maybe not as pointless as my bash html to gtkdialog parser (it was really, really slow to display - now I realize I probably should have just used the -s flag instead of -p and not let it vanish into the ether on a pfix=ram shutdown)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#670 Post by Dougal »

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.
You could try looking at the code...
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)
No. The programs are the ones who usually ask for more memory than they use, hence the VIR(tual) and RES(ident set size) fields in htop.
The kernel just gives them what they ask for, but it also allows you to use more memory than you actually have (you can control that via /proc/sys/vm/overcommit_memory).
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#671 Post by vovchik »

Dear puppians,

Have a look here http://www.murga-linux.com/puppy/viewtopic.php?t=75778 for something probably relevant to this discussion.

With kind regards,
vovchik

brokenman
Posts: 25
Joined: Thu 20 Oct 2011, 23:00

hidden folder select

#672 Post by brokenman »

<hbox>
<text label="Source: " width-request="80"></text>
<entry editable="false" fs-title="Select an existing folder" fs-action="folder">
<variable>SDIR</variable>
</entry>
<button>
<input file stock="gtk-directory"></input>
<action>fileselect:SDIR</action>
</button>
</hbox>

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

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

Re: hidden folder select

#673 Post by seaside »

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

If the dialog is right-clicked, a menu comes up with a "show hidden files" option.

cheers,
s

brokenman
Posts: 25
Joined: Thu 20 Oct 2011, 23:00

#674 Post by brokenman »

Thanks. I guess what i really meant is 'Is it possible to have .dir visible by default?'

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#675 Post by disciple »

Yes, but it applies to all programs using the GTK file selector, not just gtkdialog programs.
I thought it remembered after you changed it by the right-click method... but maybe some programs remember the setting independently rather than using a system wide setting.
If it doesn't change system wide, 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.
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

brokenman
Posts: 25
Joined: Thu 20 Oct 2011, 23:00

#676 Post by brokenman »

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.
Yes. That's what i was looking for. Thanks very much. I didn't even realize a config file was created!

User avatar
don570
Posts: 5528
Joined: Wed 10 Mar 2010, 19:58
Location: Ontario

page full of script examples

#677 Post by don570 »

There's a single page full of script examples for beginners.
A very convenient resource. HERE

and the user manual is HERE


and stock icons are listed HERE



___________________________________________________

User avatar
don570
Posts: 5528
Joined: Wed 10 Mar 2010, 19:58
Location: Ontario

press the Enter key

#678 Post by don570 »

To explain how it is possible to press the Enter key to
input the data to your program I have written a little script.

Just look at the script and run it and you will
understand the method that Zigbert explains on the first page.

Decompress to obtain script.
_________________________________________________
Attachments
demo_script.tar.gz
Decompress to obtain script
(662 Bytes) Downloaded 531 times

User avatar
glene77is
Posts: 196
Joined: Tue 17 Aug 2010, 22:09
Location: Memphis, TN, USA
Contact:

#679 Post by glene77is »

Don 570,
Thanks for the demo script.
Just what I needed to begin with.
Resolved some myterious syntax that was killing my efforts.
Thanks. :D
glene77is
Puppy Linux is more fun than a barrel of M$ monkeys :P
www.geocities.WS/glene77is
glene77is --- {^,^} --- electricity is shocking, Memphis, TN, USA.

User avatar
don570
Posts: 5528
Joined: Wed 10 Mar 2010, 19:58
Location: Ontario

#680 Post by don570 »

Porteus is getting behind the gtkdialog bandwagen :lol:

http://forum.porteus.org/viewtopic.php?f=94&t=1132

Some examples
http://puppy2.org/slaxer/Porteus/Gtkdia ... color.html

_________________________________________________________

Post Reply