Page 1 of 4
Posted: Fri 29 Feb 2008, 07:49
by zigbert
You have a lot of good ideas here. There must come a 0.5
Posted: Fri 29 Feb 2008, 10:41
by Lobster
Zigbert
To be less aggressive, should we rename 'KILL process' to 'Make process sleep to the end of eternity'
'End Process' is fine. Have you ever had someone say,
'I don't want to kill. Kill what anyway?'
We take these terms for granted. I am used to the term 'packages'
but most people know packages as 'software'
These geek names and idiosyncrasies add up
Removing one or two where we can makes a difference
to new users and Window refugees . . .
Posted: Mon 03 Mar 2008, 18:49
by zigbert
Version 0.5
See main post
Posted: Sat 08 Mar 2008, 22:38
by disciple
The labelling is confusing now:
You select the "kill signal" (which may or may not end a process) to control the signal sent by the "end process" button. Or did I misunderstand something?
Posted: Sun 09 Mar 2008, 08:21
by zigbert
Thank you, Disciple!
Let's say: End process with signal
Posted: Mon 10 Mar 2008, 00:40
by disciple
Or maybe "send signal to process" or something.
I actually thought "kill process" and "kill signal" were all right, even if the actual signal is not necessarily a kill signal, and they offend some of the more loopy "non-violence" people - it was fairly obvious what was meant. But having two terms for the same thing, one of which is also used for something else, was a bit over the top
Posted: Wed 12 Mar 2008, 04:25
by disciple
Also, I just realized that even though the default signal must be kill or something, as it does end processes, the thing to select the signal show "no signal" until you click on something else in it.
Posted: Fri 28 Mar 2008, 12:55
by disciple
I think the answer is "not really", but is it possible to automatically select the next process in the list after killing a process?
Posted: Fri 28 Mar 2008, 17:05
by zigbert
I have not been able to preselect an item in a list with gtkdialog. Lets hope someone has and reads our posts.
Posted: Tue 06 May 2008, 15:29
by zigbert
Version 0.6
See main post
Posted: Thu 17 Jul 2008, 21:24
by linuxcbon
Puppy 4.1 A4
Code: Select all
# pprocess
sh: locate: command not found
Posted: Fri 18 Jul 2008, 08:52
by zigbert
sh: locate: command not found - does no harm.
Posted: Fri 10 Apr 2009, 07:27
by zigbert
Version 1.0
See main post
Posted: Thu 27 May 2010, 15:55
by zigbert
Version 2.0
See main post
Changelog
- Process-list updates every forth second.
- Simplified gui.
- Replaced search-funtion with instant filtering.
- Simplified structure for language support.
- Remove --center parameter. - is not suited for gui-scaling. (thanks to panzerpuppy)
- NLS Added: LOC200, 131
- NLS Changed: LOC108
- NLS Removed: LOC_REFRESHED, QUIT, LOC101, 102, 103, 109, 110, 112, 113, 114, 115, 130
Posted: Fri 25 Jun 2010, 19:38
by zigbert
Version 2.1
See main post
Changelog
- monofont in list to get better aligment.
- 'Power off/reboot' button with -s switch
- German and Norwegian translations
- NLS added: LOC119
- NLS removed: LOC110, 117
- Bugfix: Language detection (thanks to mave)
Posted: Thu 08 Jul 2010, 21:54
by playdayz
Hey Zigbert, I am full of good news today. Pprocess 2.1 causes a problem in luci-210 testing. When I click Pprocess from the menu, it does not open and the keyboard is dead. I use CTRL-ALT-BS to exit x and restart X and then the keyboard is back. Pprocess does not do this--I just checked on the same luci. Thanks.
Posted: Fri 09 Jul 2010, 02:02
by BarryK
dead keyboard and mouse have also been reported in Spup 0.3, as soon as Pprocess is started -- reported by edoc.
Posted: Fri 09 Jul 2010, 05:48
by zigbert
Version 2.1.1
See main post
Pprocess 2.1 in luci was not the same Pprocess 2.1 that shows up on my daily system.
Some idiot has uploaded wrong code.
Still, I could not reproduce the bug in luci...... Please confirm the bug with Pprocess 2.1.1. - I would not be surprised if it all works ok now, since 2.1.1 uses 'ps' instead of 'top' as its backend.
Sigmund
Posted: Fri 09 Jul 2010, 06:06
by tubby
I see you have removed the locals from your compile, i was wondering if it was those lines of code that broke the one in spup. In my spup i changed the en-us to en-gb in the locals folder.
Posted: Wed 18 Aug 2010, 03:59
by wow
Bug:
Code: Select all
#set language
TMP="`ls -1 $PROGPATH/locals/ | grep $LANG`"
. $PROGPATH/locals/en_US:english #always run to fill gaps in translation
[ "$TMP" != "en_US:english" ] && . $PROGPATH/locals/$TMP 2> /dev/null
Auto language selection(pprocess, pmusic, pfind and others) will not work with a format different than xx_XX, locales like mine (es_PE.uft8) won't load automatically because of extra characters (.utf8).
Workaround: something like this:
Code: Select all
#set language
TMP="`ls -1 $PROGPATH/locals/ | grep ${LANG%.*}`"
. $PROGPATH/locals/en_US:english #always run to fill gaps in translation
#fallback to macrolanguage if available (ISO 639-1 two letter code: en, es, fr, etc.)
[ -z $TMP ] && TMP="`ls -1 $PROGPATH/locals/ | grep ${LANG%_*}:`" && echo $TMP
[ "$TMP" != "en_US:english" ] && . $PROGPATH/locals/$TMP 2> /dev/null
Ok, so now it will work with linguistically distinct variants like pt_PT and pt_BR and also work with "es" for "spanish", "us" for english, etc. when needed instead of trying to load es_AR, es_PE, es_ES, en_AU, en_GB, en_US.