So, here is a simple test-script to show how it works. All in all, it's just a svg that rotates the dot to show the changing value. Atm, the knob rotates when dragging mouse up/down on the knob. Maybe this should be extended to left/right actions as well. Please check out the code; it should be easy to understand with some basic bash/gtkdialog/svg knowledge.
The code:
#!/bin/bash
export KNOB_WIDTH=120
export KNOB_COLOR="#A5E8B1"
export CARD_NR=0 #'aplay -l' shows your cards
export SPEAKER=Master
#initial audio level
TMP="`amixer -c $CARD_NR get "$SPEAKER" | grep -m1 'Left:' | cut -d '%' -f 1 | cut -d '[' -f 2`" #volume level
ANGLE=$(($TMP*250/100)) #convert from % to angle (0-250)
echo $ANGLE > /tmp/knob_angle
draw_knob (){ #$1=angle/value, $2=width, $3=color, $4=dot-color
echo '
<svg width="'${2}'" height="'${2}'">
<defs>
<radialGradient
cx="'$((${2}*30/100))'" cy="'$((${2}*30/100))'" fx="'$((${2}*30/100))'" fy="'$((${2}*30/100))'" r="'$((${2}*45/100))'"
gradientUnits="userSpaceOnUse">
<stop offset="1"/>
<stop offset="0"/>
</radialGradient>
</defs>
<circle cx="'$(((${2}/2)+(${2}*4/100)))'" cy="'$(((${2}/2)+(${2}*4/100)))'" r="'$((${2}*46/100))'"/>
<circle cx="'$((${2}/2))'" cy="'$((${2}/2))'" r="'$((${2}*46/100))'"/>
<circle cx="'$((${2}/2))'" cy="'$((${2}/2))'" r="'$((${2}*39/100))'"/>
<circle cx="'$((${2}*28/100))'" cy="'$((${2}*74/100))'" r="'$((${2}*4/100))'" transform="rotate('${1}' '$((${2}/2))' '$((${2}/2))')"/>
</svg>'
}
update (){ #get current, relative position of cursor
read ANGLE < /tmp/knob_angle
Y="`getcurpos | awk '{print $2}'`"
read Y2 < /tmp/cursor_y
ANGLE=$(($ANGLE+(($Y2-$Y)*2))) #the knob's value range is equal to moving mouse up/down 125 px.
[ $ANGLE -lt 1 ] && ANGLE=0; [ $ANGLE -gt 250 ] && ANGLE=250 #keep value inside range
echo $Y > /tmp/cursor_y
echo $ANGLE > /tmp/knob_angle
draw_knob $ANGLE $KNOB_WIDTH "$KNOB_COLOR" "#eee" > /tmp/knob.svg
amixer -c $CARD_NR set "$SPEAKER" $(($ANGLE*100/250))%
}
export -f draw_knob update
draw_knob $ANGLE $KNOB_WIDTH "$KNOB_COLOR" "#eee" > /tmp/knob.svg
echo '
<vbox margin="20">
<timer visible="false" milliseconds="true" interval="100" sensitive="false">
<variable>TIMER</variable>
<action>update</action>
<action>refresh:KNOB</action>
</timer>
<eventbox>
<pixmap>
<variable>KNOB</variable>
<input file>/tmp/knob.svg</input>
</pixmap>
<action signal="button-press-event">getcurpos | awk '"'"'{print $2}'"'"' > /tmp/cursor_y</action>
<action signal="button-press-event">enable:TIMER</action>
<action signal="button-release-event">disable:TIMER</action>
</eventbox>
<text><label>Volume</label></text>
</vbox>' | gtkdialog -s
Be aware that this knob depends on the getcurpos command. This is included in all recent Puppies. But I doubt that you'll find getcurpos in most other distros, so I see this as Puppy-code. You should probably avoid this code if you plan to offer your gui outside the kennel.
This info is added to the Tips and tricks post
No comments posted yet.
Puppies built from Woof-CE uses /usr/lib/gtkdialog/ to unify the look of builtin GUIs. Together with the new vector icon set (in /usr/share/pixmaps/puppy), the gtkdialog lib made it possible to give Puppy a facelift without adding any bloat to the core.
The lib is simple and small. It is meant to reduce the code for repeating requests (as message-boxes), and unify the look for graphical widgets (as scalegrips and svgs). A complete guide how to use the different snippets are found inside each file (open in text-editor). It contains 3 different categories:
1. BOX
These return running gtkdialog boxes with requested info. Gtkdialog is not complex at all, but dead simple boxes often used by Puppy, can be set up with a oneliner. This is not meant as a replacement for Xdialog.
There are atm 4 different types of boxes:
box_help
box_ok
box_splash
box_yesno
Example:
/usr/lib/gtkdialog/box_ok Title error "This is an error"
2. XML
While the box-code produces a running gui, the xml-code is gtkdialog code meant to be embedded inside the parent gui. These are used to unify the look, and is cooperating with pTheme to follow the global theming.
There are 4 xml-snippets available:
xml_button_icon
xml_info
xml_pixmap
xml_scalegrip
Example: - Note the 'xml_info gtk' that activates the gtkdialog-theme set by pTheme.
export GUI='
<vbox space-expand="true" space-fill="true">
'"`/usr/lib/gtkdialog/xml_info fixed puppy_config.svg 60 "This is the header used in Puppy these days. It handles <b>markups</b>."`"'
<button ok></button>
</vbox>'
. /usr/lib/gtkdialog/xml_info gtk #build bg_pixmap for gtk-theme
gtkdialog -p GUI
3. SVG
The svg category returns svg-code to embed in the gtkdialog code. Today, there are 3, but the knob shown in previous post should probably be added here. As expected, the svg bars and text follows the global theming set by pTheme.
svg_analogclock
svg_bar
svg_text
Example:
echo '
<vbox>
<timer visible="false">
<action>/usr/lib/gtkdialog/svg_analogclock 300 > /tmp/clock.svg</action>
<action>refresh:CLOCK</action>
</timer>
<pixmap space-expand="false" space-fill="false">
<variable>CLOCK</variable>
<input file>/tmp/clock.svg</input>
</pixmap>
</vbox>' | gtkdialog -s
No comments posted yet.
The web interface is suited for doing simple things, and has many limitations over the CLI interface. An advanced user of git would probably laugh at us using the simple variant. But when rarely using git, and most of the time just editing existing files, it is just perfect to do the stuff in the web-browser.
The challenge is when we want to upload packages containing lots of files and directories. How do we do this...
1. Create new files and directories
- Go to the source directory - in this example /woof-code/rootfs-packages/.
- Press the Create new file button.
- Write the name of first directory in the textbox - here frisbee.
- Enter / to create the path. The textbox moves right, and are ready for new input.
- When reached target directory, add filename in textbox, and add file content in the editor.
- Add pull request by pressing the Propose file change / Commit changes button.
2. Upload files to existing directory
- Go to the source directory - here /woof-code/rootfs-packages/frisbee/etc/.
- Press the Upload files button.
- Add files by dragging them from your file-browser.
- You'll see your files get added at bottom (marked red).
- Add pull request by pressing the Propose file change / Commit changes button.
Posted on 26 May 2016, 19:59 by 01micko
I have linked to this from the Woof-CE Needs You topic on the forum. Hopefully many people read it and gain some inspiration.
Delete
To make the infra-structure simple; the DB, the sourcelist (search-result-field) and the internal file format (*.pmd), uses the exact same formating. That means, we can dump the raw output of the DB to the gui, a favorite list, or ie. to the smart-add function. This helps a lot when it comes to speed. Sometimes you might forget that pMusic is not compiled binary, but just a bash script.
GeekNote: To be technically correct, the sourcelist and *.pmd file contains only the first 15 columns of the DB format. They have no use of the last items of info.
The DB structure
Let's look at one line of my DB:
/mnt/sdb1/musikk/Tindrum - Drums Of War.mp3|Tindrum|Drums Of War|Drums of war|1|1988|Hard Rock|Live||mp3|175|04:02|117|/mnt/sdb1/musikk/Tindrum - Drums Of War.mp3|gtk-audio|2aa59ada-3dd8-40b7-878a-bb682fca7b30|479933cd-d787-4126-8315-7749ca4781a1|Tindrum|/mnt/home/pmusic storage/albumart/Tindrum - Drums Of War.jpg||,1357415329,1357417187
Most of this is straightforward, but 3 things might not seem logical:
Writing to the DB
pMusic allows 2 major ways to write info to the DB. Either by (1) user interaction or the default (2) silent mode.
(1) user interaction
The static way is to start the indexer (Menu > Music sources > My Music) which scans your system for audio-files and adds the info to the DB. Depending on your music collection, this might take a long time, but place all available information (ID3-tags and stream info) to the DB at once.
(2) silent mode
The default dynamic behavior is to store info as you play. When you press the Play-button, pMusic
All this info must be written to the DB - but that's not straightforward - we can't just start writing...
Keep the DB in shape
In addition, there are mechanisms to keep the DB in shape. When you add a file to the playqueue, pMusic checks it in func_add - functions check_source and fix_db.
If the added file is not already in the DB, ask user to scan the source directory for new music. This message shows up embedded in the main window to not disturb the user too much. It could be that we don't want to respond to this message, and that is just ok.
If the added file has its line in the DB, but not present in your system, something should probably be updated, and this message below will show up. But, if the filename is found in the DB with another path than the defined, pMusic will play the alternative source instead. Therefor, this box is not often seen in recent versions of pMusic.
The Playlist file format
I mentioned earlier the internal file format *.pmd used by ie. the favorites structure. But, for the user, the pMusic format is the *.pmu found in the save box. You can choose to save to an external format as *.m3u or *.pls, but to get the full power of pMusic, *.pmu is the recommended choice. This because it cooperates well with the DB.
*.pmu contains the same info as in the playqueue. This makes it possible to dump a *.pmu into the playqueue, while a *.m3u has to be converted. Since all information in a *.pmu is grabbed from the DB, we can quickly revert, and grab the full track-info back from the DB. This is seen when expanding a *.pmu in the sourcelist (left pane). - We see full track-info including rating calculation. When expanding a m3u/pls we only see the actual info inside the file.
When looking at the playqueue in the gui, you see 3 columns:
Length | Track title | Path
In fact there are 2 more hidden columns, and all are part of the *.pmu file:
Icon | Length | Track title | Path | ID
The Icon holds gtk-play when the play-icon is shown, else it's empty. This will of course always be empty inside a *.pmu file
The ID holds an unique id-number together with the path. This is necessary to avoid conflict when playqueue contains several instances of the same song. The ID keeps track of which of the similar songs you are playing/moving/editing.
Unlike *.m3u, the *.pmu playlist does not handle relative paths. This to stay close to the DB format. Instead pMusic will search for an alternative path if playing track is not found. The statusbar will show this information during search. Code found in func_progressbar.
The short story of the pMusic file formats is:
*.pmd mirrors the DB
*.pmu mirrors the playqueue
This is the basic structure of the pMusic data format.
No comments posted yet.
Finally after 4 years of development and numerous setbacks I have slacko and slacko64 version 7.0 out in the wild! The cover image is the default desktop in slacko64-7.0.The default in slacko-7.0 (32 bit) has greyscale backgrounds and themes but...
Leggi© 2010 - 2021 ItalianPuppy.org. - Cookie Policy