(OLD) (ARCHIVED) Puppy Linux Discussion Forum Forum Index (OLD) (ARCHIVED) Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info

This forum can also be accessed as http://oldforum.puppylinux.com
It is now read-only and serves only as archives.

Please register over the NEW forum https://forum.puppylinux.com
and continue your work there. Thank you.
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups    
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 24 Jan 2021, 09:01
All times are UTC - 4

 Forum index » Off-Topic Area » Programming
GtkDialog - tips
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
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
PostPosted: 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
View user's profile Send private message 
zigbert


Joined: 29 Mar 2006
Posts: 6629
Location: Valåmoen, Norway
PostPosted: 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
View user's profile Send private message Visit poster's website 
jpeps

Joined: 31 May 2008
Posts: 3217
PostPosted: 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
View user's profile Send private message 
zigbert


Joined: 29 Mar 2006
Posts: 6629
Location: Valåmoen, Norway
PostPosted: 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
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4878
Location: Blue Springs, MO
PostPosted: 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
View user's profile Send private message Visit poster's website 
Dougal


Joined: 19 Oct 2005
Posts: 2504
Location: Hell more grotesque than any medieval woodcut
PostPosted: 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
View user's profile Send private message 
zigbert


Joined: 29 Mar 2006
Posts: 6629
Location: Valåmoen, Norway
PostPosted: 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
View user's profile Send private message Visit poster's website 
jpeps

Joined: 31 May 2008
Posts: 3217
PostPosted: 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
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4878
Location: Blue Springs, MO
PostPosted: 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
View user's profile Send private message Visit poster's website 
Dougal


Joined: 19 Oct 2005
Posts: 2504
Location: Hell more grotesque than any medieval woodcut
PostPosted: 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
View user's profile Send private message 
vovchik


Joined: 23 Oct 2006
Posts: 1538
Location: Ukraine
PostPosted: 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
View user's profile Send private message 
brokenman

Joined: 20 Oct 2011
Posts: 25
PostPosted: 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
View user's profile Send private message 
seaside

Joined: 11 Apr 2007
Posts: 937
PostPosted: 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
View user's profile Send private message 
brokenman

Joined: 20 Oct 2011
Posts: 25
PostPosted: 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
View user's profile Send private message 
disciple

Joined: 20 May 2006
Posts: 7024
Location: Auckland, New Zealand
PostPosted: 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
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 45 of 101 [1505 Posts]   Goto page: Previous 1, 2, 3, ..., 43, 44, 45, 46, 47, ..., 99, 100, 101 Next
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  


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

[ Time: 0.2270s ][ Queries: 13 (0.1676s) ][ GZIP on ]