I will explain the new event-handling in Pmusic 2.4.0. It is a smarter way to update gui on non-user-actions. User-actions is mouse-clicks and key-entries, and is the common way to interact between user and gui. An example of updating the gui on a non-user-action in Pmusic is the loading of id3-tags for files shown in the file-browser....
When clicking on a directory, the browser field refreshes and shows the content of the new directory. Now, Pmusic continues with a background process to read the id3 information of the files. When finished, the browser field should be updated by the new info. - Without the user to click anywhere.
The solution is to either use a <progressbar> which runs its <action> when reaches 100% or a <timer> which acts at a given interval. Older Pmusic releases used the <progressbar> solution while recent code uses a <timer>. Both solutions has the downside that they uses an amount of cpu power. In a complex gui with several non-user actions this could end up with several cpu-hungry <timers> updating their unique widget(s) of the gui.
Pmusic has used 2 <timers> running constantly to update their defined gui-part. You might think that 1 <timer> would be enough, - it could refresh all wanted widgets - it wouldn't harm if the refreshing didn't change anything. BUT, refreshing has an effect on the focus handling. It simply resets the focus, which means that:
- scrolling in <table> is moved to top.
- what you are about to write in an <entry> is cleared.
- Your selected item in the <tree> is not selected anymore
- ...
The idea of Pmusic 2.4.0 was to update all kinds of trackinfo (meta-tags, lyrics, albumart, discography, ...) when a new track starts playing. This would not be possible with the underlaying event-handling in Pmusic because it would either suck you cpu-power (with several <timers>), or a global refreshing would make it impossible to be a user (because of focus issues). Also, there is a fact that too many refreshing <action> on a <timer> will increase cpu-usage as well.
So the solution has been to add ONE <timer>, which refreshes a small set of <checkboxes> that (if true) refreshes a single or group of widgets.
<checkboxes> can be set true or false by their <input file>, so we can simply 'echo true' to its <input file>. The <timer> runs its <actions> each second, and the <checkbox> will be refreshed by its <input file>. The code could look like this:
Code: Select all
<checkbox visible="false">
<label>a</label>
<variable>UPDATE_GUI</variable>
<input>cat /path/UPDATE_GUI</input>
<action>if true refresh:PLAYLIST</action>
<action>if true refresh:ARTWORK</action>
<action>if true refresh:BUTTON_PLAY</action>
<action>if true echo false > /path/UPDATE_GUI</action>
<action>if true refresh:UPDATE_GUI</action>
</checkbox>
All actions will run only if value is true. To avoid more than one refreshing we reset <input file> and the <checkbox> value to false. Now it will be silent until next time we 'echo true > inputfile'.