Tiny Core Linux
General TC => Programming & Scripting - Unofficial => Topic started by: ACRizona on November 29, 2010, 07:02:48 PM
-
FLIT is one of those kind of programs that should have a one-instance-only limit.
The cat walked on the touch-pad.... you know the rest of this story.........
I think ALL programs should have a instance-checker.
Flit is a great little-applet ! Perfect for my too-old too-weak batteries.
-
@ACRizona: probably a good idea... although sometimes during development I like to have the old stable version running all the time and then test the new version.
Maybe the default mode could check for a prior instance and if it sees one, bow out gracefully. Then I could have a command-line option to allow multiple instances (maybe with a specified alternative config file). OK, that's on the "probable to-do" list. I'd also like to add a wireless network management applet to Flit soon. But, shhh. Don't tell anyone yet! :-X
-
:-X
-
Laptop battery applet that throttles/stops/starts my "Vampire" wifi card ?.
WOW !!! what a grand idea !
That sucker saps nearly 50% of my battery power, no matter if I'm using it or not.
I have a script that keeps it alive for 240 seconds, then 240 more, 240 more, etc.
( the assumption is, if I dont use it within 240 seconds, it dies ) at this moment, its dead.
I took a 3-day airtrip over the holidays (with my spare battery in luggage ) and did not have to recharge,,, not once, with nearly six hours use.
-
Umm, have you looked into the power management native to iwconfig?
-
ACRizona: In my view only few applications (e.g. super-user daemons) will need to check if another instance of them is already running. For the vast majority something similar could be achieved with a little wrapper script like the following:
tc@box:~$ cat start_once_in_bg.sh
#!/bin/sh
CMD=$1
shift
ARGS="$@"
if [ -n "$( ps -o args | grep "^${CMD}" )" ] ; then
echo "$CMD is already running"
exit 2
else
[ -n "$ARGS" ] && eval "exec $CMD $ARGS &" || eval "exec $CMD &"
fi
tc@box:~$
It should work if you use 'start_once_in_bg.sh APP OPTIONS' and refuses to start 'APP' if another instance is already running. Mind you the test is not completely "safe" as 'APP' , 'sh APP' and '/bin/sh APP' would be seen as three different things.
-
Umm, have you looked into the power management native to iwconfig?
Along with old batteries, I also have old Athereos cards which do not support all the different power-saving functions.
But, if someone was to add WiFi control to an applet like FLIT.... it could throttle the WiFi depending on battery condition.
Plus, it would be as simple as the audio-volume-mute. A slider for time-to-live and on/off button.
-
I've said before: FLIT is the must-have applet for laptops.
1. I wish it was invisible to the desk-top-right-click menu.
Its sorta like Wbar... I know its running !
2. I wish it had a "throttle" for power eating things. Like the WiFi card.
Most laptops will slowly dim the LCD as the battery dies. Shut down disk drives,,, even go to sleep,,, which TinyCore does rather nicely. But, the WiFi card is still ON :P We have a HP laptop that has a WiFi activity light, and a keyboard switch to toggle it ON/OFF. Nice feature.
-
I didn't try it, but laptop-mode-tools might be able to switch off your wifi card?
-
2. I wish it had a "throttle" for power eating things. Like the WiFi card.
Most laptops will slowly dim the LCD as the battery dies. Shut down disk drives,,, even go to sleep,,, which TinyCore does rather nicely. But, the WiFi card is still ON :P We have a HP laptop that has a WiFi activity light, and a keyboard switch to toggle it ON/OFF. Nice feature.
Such power saving features as you mention may differ depending on hardware and/or BIOS.
Have you been looking into all related settings in your BIOS?
And similar into configuration options of your particular wifi chipsets?
The keyboard switch to toggle builtin wifi cards on/off is equivalent to the removal of external cards.
I doubt that FLIT could be suitable for such purposes, or it would require much more code and possibly several dependencies.
-
@tinypoodle: I'm thinking about the next significant iteration of Flit now that Jakob has provided all the features added version 1.3. Here's a little thinking out loud...
1) A future version of Flit (2.0 series?) will include a wireless and wired monitor applets (one instance for each network adapter, but maybe grouped as "show wireless adapters", "show network adapters" in the Flit menu). The wireless version of the monitor applet would...
a) Show a graphical representation of signal strength (maybe a 5-bar display)
b) Indication of traffic volume (and maybe bad packet indication)
c) Show IP addr. and wireless network name (ESSID) if one hovers the mouse pointer over it
d) Launch a separate FLTK networking management application (see below) if you double-click the applet in Flit
2) The wired version of the network applet would...
a) Show a graphical representation of being enabled or disabled
b) Indication of traffic volume (and maybe bad packet indication)
c) Show IP addr. if one hovers the mouse pointer over it
d) Launch the current networking maintenance app from TinyCore Base if you double-click the applet in Flit
3) The fast, light assistant (for) networking ("Flan", although I briefly considered "fast, light assistant for wireless"... hmm ::) ) would...
a) Allow the user to enable and disable the wireless devices, at least through ifconfig and/or iwconfig; may not be able to fully disable the device (depends on how it responds to these standard tools)
b) Scan for available wireless networks, and see name, signal strength, encryption requirements, and other parameters
c) Allow the user to connect to a particular wireless network; at least in the first version(s) this would be accomplished through iwconfig, so some advanced encryption modes may not be accessible
d) Allow the user to save the settings for a particular network and select it from a list of known network settings to easily re-connect in the future
e) Allow an "auto connect" flag for each network (or generic class of networks... "free wifi" would be a built-in choice) and allow the user to prioritize the configured connections, so if the first "auto-connect" choice is detected with reasonable signal strength, it is tried; and if not, the next one in the list is tried; and so on.
f) Check for prior instances when launched, and if it finds one, send it an "appear" signal and exit (this way, Flit can just try to launch Flan, if the 2nd instance of Flan discovers there is a 1st instance, the 2nd can tell the 1st instance to un-iconify and present itself, then the 2nd instance can exit early).
g) Allow each network connection to have either static or DHCP IP numbers
h) Launch the current networking maintenance app from TinyCore Base.
So for this first step, Flan would only depend on wireless-tools.tcz. If we find out that Flan is missing some crucial capability, we can consider adding other dependencies (wireless-supplicant?), but I don't have experience with those, since I seem to be able to do what I want 99% of the time with ifconfig, iwconfig, and iwlist (esp. "iwlist scanning"). Maybe we can have a "hook" to invoke extra network startup or shutdown shell commands if your adapter has and needs those to better manage the power.
Seem like a good game plan? I'm not planning on starting this until the beta 1.3.0 version of Flit is considered complete (no big bugs or convincing change requests) and submitted to the official TC repository, but may have early versions ready for testing within a month or so.
--
Mike Lockmoore
-
:o
FLAN, huh? ;D
-
I'm going to run out of FL words. :P
-
The FLAN PLAN looks great !
I'm a big proponent of the KISS methodology... especially applets like FLIT.
Nearly as simple as the light-dimmer-switch on my wall.
Beyond that, your are talking about a full-function menu-bar application program.
Thats a good idea OK too, but keep in mind, I already own a big AutoDiscover/AutoConnect/slow-noisy-boat-anchor that I'm embarassed to use in an airport.
That's why I carry a TinyCore notebook with a few apps and FLIT !
btw: I like the name FLAN. I'm tinkering with wbar-menu-folders with my script called WBARF ;D
-
I put a "Micro Core" button on my JWM tray (like the Windows "Start" button but with a better OS to hold it up) that has submenus, but I kind of like the clean simplicity of the existing wbar... though the term wbarf was a stroke of genius. :D
As for the fast, light apps - what about putting the "fl" at the end of the name. You could have apps that are helpfl and usefl. It would be beautifl.
-
As for the fast, light apps - what about putting the "fl" at the end of the name. You could have apps that are helpfl and usefl. It would be beautifl.
rofl
-
:D
No, wait! That would be awfl. :-[
-
OK, OK, I've had about enough of this flit !
;D ( do they make smilies with sound ? )
-
OK, OK, I've had about enough of this flit !
;D ( do they make smilies with sound ? )
♪♪♪♪♪♪♪ ;) ♪♪♪♪♪♪♪
-
I couldn't get it to compile - /bin is always empty. I am loading all necessary extensions eg compiletc first.
-
Jur: do you have the Xorg7.5-dev.tcz installed? There are some Xorg headers that are needed to compile Flit.
-
Yes I am loading all header files, including Xorg-7.5-dev.
tc@box:~/temp$ ./build-tcz.sh > jur.log
cp: can't stat '/home/tc/temp/flit': No such file or directory
chmod: usr/local/bin/flit: No such file or directory
tc@box:~/temp$ ./build-tcz.sh
I get different error messages when extracting to /tmp, but boiling down to the same.
-
Jur: sorry I've been away, and even now I don't have much time to reply... is it true you can compile the executable? So it is only the .tcz packaging step that is failing?
Look carefully at the built-tcz.sh script and see if there are any assumptions built into it that do not apply to you. For example, it assumes that you are logged in as the normal 'tc' user, so /home/tc exists. If that is not true, maybe you can modify it. Or maybe the permissions are different in your environment. It's hard for me to guess all the possibilities, of course.
Perhaps that script can be made more generic, so let us know if you find something that could be changed, please share. Thanks.
--
ML
-
No... I have been tinkering with the build script to see what ends up in the directories before packing but it appears not compiling. I am sorry, I haven't looked further into it.
One question: Is this version of flit also compatible with other wms? ie will it be placed in an existing wm tray? This is the reason I ended up noit using it with tint2, it wouldn't go into the treay. Same with jwm.
-
Yes tried that first. IIRC I also posed a Q on this board about it, don't think a solution came out of it.
-
One question: Is this version of flit also compatible with other wms? ie will it be placed in an existing wm tray?
@jur: I don't have first-hand experience trying to use Flit with other WMs yet. The latest updates from Jakob work in his WM and he hopes they work in many others. I would like to hear how it works in various WMs, especially some of the more common ones like JWM. I can PM you about testing a pre-release extension.
--
ML
-
Yes by all means, PM me
-
OK, tried it with openbox wm and tint2 taskbar.
It does not show on all desktops - with or without using the -a option.
It does not go into tint2's tray. (Tint2 seems very compliant wrt tray apps - everything including windows apps goes into the tray if required.) I tried with and without -d (not sure what docking means though.)
-
@jur: Thanks for trying. Hopefully, Jakob can investigate this sometime soon and either offer more usage instructions or a code update.
-
Sorry for getting back to you so late - the pre-christmas time is just busy as hell.
The docking feature is meant to dock into the docking area of the window manager.
The docking option sets "_NET_WM_WINDOW_TYPE_DOCK" for the fltk window which is a property the window manager should interpret and act upon.
This works in the window manager I use (i3) but I have not tested it with other window managers - this window capability will not make flit dock into any tray app (unless the window manager will hand applications with that property automagically to a tray app).
"_NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a Window Manager would keep such windows on top of all other windows."
from http://standards.freedesktop.org/wm-spec/latest/ar01s05.html
In i3 applications with _NET_WM_WINDOW_TYPE_DOCK set are put into a horizontal panel at the bottom of the desktop. Supposedly tint2 will also make use of this window property to make itself a dock application. It's possible that the way I set this property is not working on other window managers - I need to test this.
---
The "show on all desktops" option was pure experimental as my window manager does not yet have this feature (but I need it and will write a patch soon); so thank you for telling me it isn't working like it should.
It sends an event with _NET_WM_DESKTOP = 0xffffffff to the window manager - maybe it should be a window property like _NET_WM_WINDOW_TYPE_DOCK. This also need's further testing.
---
For future updates it might be a good idea to test flit (and other custom) apps on other window managers as well (because the standards set by freedesktop are not always held by all window managers or parts like docking are omited); as this is not big deal I'm willing to do this for the next releases. What wm's are the most important ones for the tinycore community?
I currently think of a testing set like this:
flwm, jwm, fluxbox, i3 (as this is my main window manager)
---
After christmas I may investigate what's needed to make an application like flit cover itself into a dock application like tint2 and make the "on all desktops"-feature work - so thank you very much for your response!
-
-a and -d do not seem to have any effect with jwm-snapshot here.
Multiple instances do not appear to get prevented.
-
Multiple instances do not appear to get prevented.
Do you have the flit version 1.3.0 beta1 or the one from the tc repository?
Check by running
flit -VIf you have the current version please look for a file .flit.pid in your home directory while flit is running and please tell me if it exists (it's contents should be a single number which is the process id of the running flit instance).
-
flit 1.3.0 Beta 1tc@box:~$ ls -l .fli*
-rw-r--r-- 1 tc staff 972 Jan 4 13:01 .flit.conf
tc@box:~$
FWIW, running TC 2.10, but I doubt that would play any role.
-
I cannot get to what I must be missing here - the file should be created when flit is started and deleted after flit has been canceled.
As there is no error checking in place, flit should even crash when it cannot write the pidfile... this seems strange.
-
Pid files in the home directory are probably a bad idea.
If you run a backup, and later shutdown without backup, you will be left with a pidfile in mydata.tgz.
This will cause a problem at reboot.
Some things to consider:
When checking for a pid file, make sure the pid is still running. If not, delete it.
Store your pid files someplace else like /var/run.
-
If you run a backup, and later shutdown without backup, you will be left with a pidfile in mydata.tgz.
Good catch - a scenario particular to TC.
-
It is checked if the pid in the pidfile is valid and an instance of flit!
If not, the pidfile is replaced upon start -> so that is not an issue.
At first I wanted to put the pidfile into /var/run but did not do it because of missing access rights. But it couild be put under /tmp/ instead.
-
Doing some more testing, indeed I did find .flit.pid - no idea why I didn't before.
When running new instances, the content appears to be overwritten with PID of most recent instance.
After exiting the most recent of multiple instance, it's (no longer existing) PID would remain in the file.
-
Okay, thanks for this input which will hopefully give me some hint to find the problem.