pWidgets 2.5.8

[zigbert]

To get analog clock work I grabbed a lib from Puppy 4.3.1

/usr/lib/libpng12.so.0.22.0
/usr/lib/libpng12.so.0

[mfb]

Whereas the Calendar widget for April 2018 continues to show properly if Sunday is set as the first day of the week; that was far from true if the first day is set to Monday.

My thanks to Zigbert who has very kindly fixed my problem earlier today with his post near the bottom of page 214:
http://murga-linux.com/puppy/viewtopic. ... 4a5#987345

The code shown there needed to replace the current code at:
/usr/local/pwidgets/widgets/scripts/Calendar
and the fix is as shown in the screen shot below.

[davids45]

G'day,

I have a minor problem with the Calendar widget aligning the number dates beneath the day abbreviations.

I looks like the spacing is not including a notional '0' in front of the first 9 numbers so the first two lines are shortened losing alignment to the day headings (screenshot).

Having played with the fonts and font-sizes for the widget to no benefit, I think the problem is in the calendar script, presently:

#! /bin/sh
# Added by MHHP for compliance with ISO 8601

cal_monday (){
LANG=C CAL=`cal`
echo -e "\n$CAL" | cut -c1-2 | grep -v "^ $" > $HOME/.pwidgets/tmp/cal1
echo "$CAL" | cut -c4- > $HOME/.pwidgets/tmp/cal2
paste -d ' ' $HOME/.pwidgets/tmp/cal2 $HOME/.pwidgets/tmp/cal1 > $HOME/.pwidgets/tmp/cal
}

today(){
DATE=`date +%d`
[ `echo $DATE | cut -c1` = 0 ] && DATE=`date +%d | cut -c2`
}
export -f today
case "$1" in
heading_month)
#build calender here to do it only once
if [ `cat $HOME/.pwidgets/widgets/Calendar | grep WEEK_FIRST_DAY | grep MONDAY` ]; then
cal_monday
else
cal > $HOME/.pwidgets/tmp/cal
fi
#---
head -n1 $HOME/.pwidgets/tmp/cal | awk '{print $1" "$2}'
;;
heading_days)
head -n2 $HOME/.pwidgets/tmp/cal | tail -n1
;;
passed)
today
grep -v '[a-zA-Z]' $HOME/.pwidgets/tmp/cal | grep '[0-9]' | awk -F$DATE ' BEGIN {i=0}
($1 == $0 && i==0) {print $1}($1 != $0 && i==0){i=i+1;print $1}';
;;
today)
today
echo $DATE;
;;
comes)
today
grep -v '[a-zA-Z]' $HOME/.pwidgets/tmp/cal | grep '[0-9]' | awk -F$DATE ' BEGIN {i=1}
(i==0) {print $0}($1 != $0 && i==1){i=i-1;print $2}';
;;
esac

The /tmp/cal file mentioned in the script is OK if viewed in geany (screenshot) but when copied (ctrl-c) comes up the same as the widget display:

April 2018
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30

Complications:
I'm using pwidgets modified/beautified by forum member Moat although the calendar widget looks pristine (I added Osmo tasks to the TEXT section which displays below the calendar).
The widget files are stored on my data partition and most Pups' widgets just run via links to these files (such as the screenshot which is from a frugal bionicpup+12). Changing the config in one Pup then affects all the others sharing pwidgets.
This may be a part of my problem if no one else sees calendar mis-aligning in their pwidgets.
For the few Pups that have individually installed pwidgets (no shared links), the calendar is generally well set out and stable.

Thanks for any advice.

David S.

[zigbert]

David
I think you calendar-issue is related to fonts. It looks to me like the font in your screenshot is not monospace.

I just checked my latest calendar-widget in Bionic, and it looks great...

[zigbert]

Kernel info in the 'Puppylinux' widget may give alignment issues if string is too long. The info is grabbed by the uname -r command in /usr/local/pwidgets/widgets/configs/Puppylinux

Code: Select all

# uname -r
4.9.92-lxpup-32-pae

to fix this, I have stripped the result

Code: Select all

uname -r | cut -d'-' -f1

[davids45]

G'day zigbert,

Thanks for taking time to look at my pwidgets issues.

With your confirmation Calendar is good with the right font (monofont.ttf), I found, with all my recent "playing around" with fonts links, the monofont TF file was missing .

I had a similar problem with pdingobats2 which also didn't seem to work in Pups on sda1 via a symlink of the font file from my data partition sda5.

Copying the complete/original ttf files to /usr/share/font/default/TTF in each Pup seems to fix the widget display.

And thank you mind-reading my un-posted concern ( ) about the long kernel text string in some Pups so the widget panel becomes a bit wide and untidy.

Your script edit works .

David S.

[Subito Piano]

215 PAGES!!!! Popular thread....

Has anyone created a pwidget to show one's (external) IP address? I see it's been done in conky...

[davids45]

G'day,

A few posts back, "Our" Bill Gates posted a year and a bit ago the problem he was having getting the Wireless widget to run in a 64-bit Pup:

Now/still I'm now having the same problem .
We've gone wifi on the home network and I slowly trying to get 64-bit Pups to run on my computers. Wireless widget is still fine in 32-bit Pups.

Has anyone been able to run/fix the Wireless widget in a 64-bit Pup?
Could it be a conky problem as the widget config scripts look the same in 32-bit and 64-bit configs, but only the 32-bit runs (screenshots)?

David S.

[davids45]

G'day,

Still trying to find a 64-bit Pup that will run the Wireless widget like every 32-bit Pup does.

Latest checks were with old JustLighthouse Pups but still no success.

JL has a conky display (screenshot) which includes wireless activity. It reports not "wlan0" but "wpl0s29f7u6". Replacing 'wlan0' in the widget files with this 'wlp0s29f7u6' did not fix the Pwidget problem. Not surprising I suppose as the same widget scripts (using wlan0) in 32-bit Pups are all good.

Any suggestions welcome.

David S.

[mikeslr]

Hi Dave,

FWIW

Recent problems (since solved) with wireless strength had me hunting for some way to find out without having to run setup networking each time. Fortunately, although on most of my Puppies I've shifted to use radky's most recent jwmdesk, the Xenialpup64 on my Laptop still uses radky's FbBox, http://murga-linux.com/puppy/viewtopic.php?t=92982

One of the builtin plugins you can choose to appear on the FbBox panel is "Network Status". If selected, current signal strength is always displayed. Left-Click that display and a popup window provides the further information indicated in the attached screenshot.

Radky has a lot on his plate at the moment. But perhaps some one who understands bash can identify the code used in FbBox's plugin and either create a stand-alone taskbar plugin for JWM, or a widget for pwidgets.

[Dry Falls]

Hi David. You can also append to your linux/vmlinuz/append line in grub or other boot menu:

Code: Select all

net.ifnames=0

. This will ensure the "wlan" language is used rather than "wpl0..." or "'encap...", etc. This should fix the older widgets.

-df

edit: also, newer versions of conky (in newer pups) require lua (liblua.so.5).

[davids45]

G'day,

Thanks mikeslr and Dry Falls for your interest and replies.
Still thrashing about in 64-bit land without success (or knowledge of what I'm doing - as usual ).

However I did find how to add the wifi IP address to the working 32-bit Wireless widget (added red text to wirelss config file) ......

TEXT
${color white}${font pdingobats2:bold:size=20}0${font DejaVu:bold:size=11}${color yellow} Wireless
${color lightblue}${font DejaVu:size=10}${wireless_essid wlan0}${color orange}${font}${alignr}${wireless_link_qual wlan0}
${color green}${wireless_link_bar 10 wlan0}
${color lightblue}IP Address:${color orange} ${addr wlan0}

Result is in screenshot.

Will continue to try to work out a 64-bit pwidget wireless fix but maybe I just need to use conky-only in 64-bit?

David S.

[mikeslr]

Hi all,

I rather like pWidgets. But I also like DogRadio which has conky as a dependency. On its own, pWidgets-2.5.8-x86_64 worked fine under Xenialpup64. So does DogRadio if Conky is installed via PPM. However, if instead of that Conky pWidgets with its included conky 1.6.1 is used, DogRadio will work, but pWidgets will not start complaining about a missing config file.

The work-around is to first install Conky via PPM as part of the DogRadio install. Then install the pWidgets pet. Both pWidgets and DogRadio will then function.

[ndujoe1]

are these two libs available online, then? thanks

/usr/lib/libpng12.so.0.22.0
/usr/lib/libpng12.so.0

[mikeslr]

Hi ndujoe1,

Which Puppy? Although libraries may have the same name, and sometimes it doesn't make a difference, it's always better to use a library compiled for your operating system.

On xenialpup64 --from which I'm posting-- pfind located both /usr/lib/libpng12.so.0.22.0 and /usr/lib/libpng12.so.0. Examination of these showed that they were symbolic links to /usr/lib/libping12.so.0.54.0.

libraries are almost always backward compatible. That is, when a specific library such as libping12.so.0 is sought by an application, the application will use a later version, such as libping12.so.0.54.0 if you create a symbolic link to it and give the symbolic link the name of the file the application was designed to use. If the symbolic link doesn't already exist, you can create it. OPEN A TERMINAL IN THE FOLDER OF THE RECENT LIBRARY* and use this template:

ln -s NAME_OF_EXISTING_LIBRARY NAME_SOUGHT_BY_APPLICATION

Example

ln -s libping12.so.0.54.0 libping12.so.0

-----
* This isn't absolutely necessary, and sometimes is wrong. But it's easier. When necessary you can similarly create a symbolic link in one folder to a library in another folder. But then you'll have to specify paths, such as:

ln -s /usr/local/lib ABC.so.75 /usr/sbin/lib/ABC.so.76

The above can be entered from anywhere. You don't have to enter the path of the folder in which you've opened the terminal.
--------
Before we go hunting for other versions: Do you already have any libping12.so files on your system? If you open Puppy Package Manager and type libping12 in its search box, what results does it show?

[Mike Walsh]

@ ndujoe1:-

Whilst I do fully agree with Mike that you really ought to use dependencies compiled for your particular Puppy, I've had a rummage around in my big "box of toys" (I have a directory, full to the brim with all kinds of assorted dependencies.....a legacy of many Puppy 'lib-chases' over the years!), and have come across these two:-

A 32-bit libpng12.so.0.27.0, together with "so.0" sym-link
A 64-bit libpng12.so.0.37.0, together with "so.0" sym-link

There's one of each, since we don't know what Pup you're running. Both are slightly newer than that which you say you want, so by the law of averages, backward-compatibility should work in your favour. I've attached them to this post; unzip it, and each is in its own folder.

Can't hurt to try.... (*shrug*)

[For future reference, this:-

http://old-releases.ubuntu.com/ubuntu/pool/

.... is a good place to hunt for older, 'age-related' libs. Canonical's listings for many of these date back to the days of 'Gutsy Gibbon', or earlier - 12 years or more. Mikeslr will also tell you that pkgs.org is another good 'hunting-ground'.....with which I, too, concur:-

https://pkgs.org/ ]


Mike.

[mikeslr]

"[For future reference, this:-

http://old-releases.ubuntu.com/ubuntu/pool/

.... is a good place to hunt for older, 'age-related' libs".

Nice find, Mike. Thanks for posting it. Added to my Bookmarks.

[Mike Walsh]

"[For future reference, this:-

http://old-releases.ubuntu.com/ubuntu/pool/

.... is a good place to hunt for older, 'age-related' libs".

Nice find, Mike. Thanks for posting it. Added to my Bookmarks.

@ Mike:-

I've been using that one for a while. Despite the fact that pkgs.org often comes up trumps when I'm on the hunt for something, they only really publish 'updated' stuff for distros within the last 5 years. 'Old-releases' at /ubuntu/pool is a damn good place to find age-related libs for the older, 'buntu-based Pups like Precise or Lucid.

It's certainly worth having a rummage through, because they give approximate dates when stuff was added to the repo.....so for Precise, look for versions around the 2011/2012 time-frame, and for Lucid, around the 2009/10 mark.

Anything I can use to keep some of the earlier, really good 'buntu-based Pups going, I will make use of. I'm not proud; I'll grab stuff from anywhere I can..!

They do, of course, have stuff in there all the way up to the current releases, too. It all helps.


Mike.