The time now is Sun 24 Jan 2021, 09:01
All times are UTC - 4 |
Page 45 of 101 [1505 Posts] |
Goto page: Previous 1, 2, 3, ..., 43, 44, 45, 46, 47, ..., 99, 100, 101 Next |
Author |
Message |
jpeps
Joined: 31 May 2008 Posts: 3217
|
Posted: Wed 01 Feb 2012, 12:34 Post subject:
|
|
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.
|
Back to top
|
|
 |
zigbert

Joined: 29 Mar 2006 Posts: 6629 Location: Valåmoen, Norway
|
Posted: Wed 01 Feb 2012, 12:50 Post subject:
|
|
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 ...
_________________ Stardust resources
|
Back to top
|
|
 |
jpeps
Joined: 31 May 2008 Posts: 3217
|
Posted: Wed 01 Feb 2012, 13:30 Post subject:
|
|
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.
|
Back to top
|
|
 |
zigbert

Joined: 29 Mar 2006 Posts: 6629 Location: Valåmoen, Norway
|
Posted: Wed 01 Feb 2012, 14:20 Post subject:
|
|
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
_________________ Stardust resources
|
Back to top
|
|
 |
technosaurus

Joined: 18 May 2008 Posts: 4878 Location: Blue Springs, MO
|
Posted: Fri 03 Feb 2012, 12:24 Post subject:
|
|
I think there was a partial fix in svn for this already, but for slow to start apps instead of:
Code: | export MAIN='...stuff...'
gtkdialog -p MAIN | Try Code: | gtkdialog -s <<< '...stuff...' | Or Code: | gtkdialog -s < /pathto/file |
This also works, but will need to make sure previous dialogs are closed before echoing a new one
Code: | #!/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: | #!/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 github repositories. I may eventually get around to updating my blogspot.
|
Back to top
|
|
 |
Dougal

Joined: 19 Oct 2005 Posts: 2504 Location: Hell more grotesque than any medieval woodcut
|
Posted: Fri 03 Feb 2012, 15:27 Post subject:
|
|
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: | #!/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: | #!/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
|
Back to top
|
|
 |
zigbert

Joined: 29 Mar 2006 Posts: 6629 Location: Valåmoen, Norway
|
Posted: Sat 04 Feb 2012, 19:50 Post subject:
|
|
Quote: | 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
_________________ Stardust resources
|
Back to top
|
|
 |
jpeps
Joined: 31 May 2008 Posts: 3217
|
Posted: Sat 04 Feb 2012, 20:23 Post subject:
|
|
zigbert wrote: | Quote: | 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: |
mkfifo /tmp/newFifo
FifoScript >/tmp/newFifo &
while read n; do
echo "in newFifo"
echo "$n"
done < /tmp/newFifo &
wait
rm /tmp/newFifo
|
|
Back to top
|
|
 |
technosaurus

Joined: 18 May 2008 Posts: 4878 Location: Blue Springs, MO
|
Posted: Sat 04 Feb 2012, 21:36 Post subject:
|
|
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 github repositories. I may eventually get around to updating my blogspot.
|
Back to top
|
|
 |
Dougal

Joined: 19 Oct 2005 Posts: 2504 Location: Hell more grotesque than any medieval woodcut
|
Posted: Mon 06 Feb 2012, 14:43 Post subject:
|
|
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...
Quote: | 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
|
Back to top
|
|
 |
vovchik

Joined: 23 Oct 2006 Posts: 1538 Location: Ukraine
|
Posted: Mon 06 Feb 2012, 15:55 Post subject:
|
|
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
|
Back to top
|
|
 |
brokenman
Joined: 20 Oct 2011 Posts: 25
|
Posted: Sun 11 Mar 2012, 20:36 Post subject:
hidden folder select Subject description: Folder chooser can choose hidden folders? |
|
<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?
|
Back to top
|
|
 |
seaside
Joined: 11 Apr 2007 Posts: 937
|
Posted: Sun 11 Mar 2012, 21:09 Post subject:
Re: hidden folder select Subject description: Folder chooser can choose hidden folders? |
|
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
|
Back to top
|
|
 |
brokenman
Joined: 20 Oct 2011 Posts: 25
|
Posted: Wed 14 Mar 2012, 21:41 Post subject:
|
|
Thanks. I guess what i really meant is 'Is it possible to have .dir visible by default?'
|
Back to top
|
|
 |
disciple
Joined: 20 May 2006 Posts: 7024 Location: Auckland, New Zealand
|
Posted: Thu 15 Mar 2012, 04:35 Post subject:
|
|
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
|
Back to top
|
|
 |
|
Page 45 of 101 [1505 Posts] |
Goto page: Previous 1, 2, 3, ..., 43, 44, 45, 46, 47, ..., 99, 100, 101 Next |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|