Re: FVWM: Questions for translation of manpages to Japanese
Shigeharu TAKENO <[EMAIL PROTECTED]> writes: > shige 08/06 2008 > > > I am a fvwm user in Japan. I have two questions for translation > of manual pages of fvwm. > > 1) I and some members of my Lab translated manual pages of old > fvwm (fvwm-2.0.46/fvwm95-2.0.43a) to Japanese and we opened them > in our web page > > http://takeno.iee.niit.ac.jp/%7Efoo/fvwm-jman/fvwm-jman.html > (written in Japanese) > > Are there any problem to open them for the license ? If any > problems exist, I will close the web page. > > 2) I am now translating the manual page of fvwm-2.4.19 (fvwm2.1) > to Japanese. If the translation complete, does it allow to open > them as the similar style above ? Fvwm95 is a different project. Creating a translation of the Fvwm man pages is OK.
FVWM: Some items on a wish list
Hi. After some recent experiences setting up an old laptop, I noticed the following, which some might regard as shortcomings. If anyone who has more knowledge about how the internals of fvwm are put together would like to do a little hand-holding, then I am quite willing (and probably able, though not familiar with the code organization of fvwm, as yet) to try to help out. A list of two items follows: 1. Apparently, there is no support for PNG icons. If I want to do something like borrow an icon from somewhere, or if a piece of software comes with its own PNG icon in the package, then I have to convert the icon to XPM format in order to use it. For me, it is not a big deal to do the conversion, but perhaps it would be nice if PNG format were recognized, too? 2. For a laptop, there are such things as battery and temperature sensors. Fancy environments such as KDE have support for things like indicators for the battery. I wonder how hard it would be to provide this for fvwm? Actually, I conjecture that this would not require a deep dive into the code at all, but rather the hooking up of some already-existing program into a display "icon" something like the load indicator, which already has been done a long time ago. But I wonder if anyone has done this, or thought of it? Theodore Kilgore
Re: FVWM: Some items on a wish list
On Wed, 6 Aug 2008 13:29:57 -0500 (CDT) [EMAIL PROTECTED] wrote: > 1. Apparently, there is no support for PNG icons. If I want to do > something like borrow an icon from somewhere, or if a piece of > software comes with its own PNG icon in the package, then I have to > convert the icon to XPM format in order to use it. For me, it is not > a big deal to do the conversion, but perhaps it would be nice if PNG > format were recognized, too? Eh? You just need to compile against libpng -- of course PNGs are supported. > 2. For a laptop, there are such things as battery and temperature > sensors. Fancy environments such as KDE have support for things like FVWM is not a desktop environment; several apps exist to display this just fine. Look on freshmeat. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci.
Re: FVWM: Some items on a wish list
Hi, About png's Thomas already answered. I'll just add that is also supports svg on latest revisions. Check the man page for more info. On Wed, 6 Aug 2008 13:29:57 -0500 (CDT) [EMAIL PROTECTED] wrote: > 2. For a laptop, there are such things as battery and temperature sensors. > Fancy environments such as KDE have support for things like indicators for > the battery. I wonder how hard it would be to provide this for fvwm? > Actually, I conjecture that this would not require a deep dive into the > code at all, but rather the hooking up of some already-existing program > into a display "icon" something like the load indicator, which already has > been done a long time ago. But I wonder if anyone has done this, or > thought of it? I'll say a couple more of words about this. Fvwm is a window manager, and this is no the kind of functionality that a wm should have. IF you want everything working -almost- out of the box, use a Desktop instead. FvwmButtons is an interesting module that can swallow any application. Temperature metters, system tray applets, mail notification applets, clocks, etc. can be embedded simply into FvwmButtons, so, it looks a bit odd to me to hard code such features into fvwm itself. If you want it, add it into your config, that's how fvwm is and I doubt it will change. You can also use gkrellm and conky if you preffer monoliths instead of having a lot of small applets/metters running. -- Jesús Guerrero <[EMAIL PROTECTED]> pgp76Ru3CtsDb.pgp Description: PGP signature
Re: FVWM: Some items on a wish list
At Wed, 6 Aug 2008 20:59:00 +0200 [** ISO-8859-1 charset **] JesúsGuerrero <[EMAIL PROTECTED]> wrote: > > > Hi, > > About png's Thomas already answered. I'll just add that is also supports > svg on latest revisions. Check the man page for more info. > > On Wed, 6 Aug 2008 13:29:57 -0500 (CDT) > [EMAIL PROTECTED] wrote: > > > 2. For a laptop, there are such things as battery and temperature sensors. > > Fancy environments such as KDE have support for things like indicators for > > the battery. I wonder how hard it would be to provide this for fvwm? > > Actually, I conjecture that this would not require a deep dive into the > > code at all, but rather the hooking up of some already-existing program > > into a display "icon" something like the load indicator, which already has > > been done a long time ago. But I wonder if anyone has done this, or > > thought of it? > > I'll say a couple more of words about this. Fvwm is a window manager, and this > is no the kind of functionality that a wm should have. IF you want everything > working -almost- out of the box, use a Desktop instead. Right. The whole point of Fvwm is to be a fairly lightweight window manager. There is no need to add extrainious functionallity to it. One of the reasons *I* use Fvwm is that is is NOT like Gnome or KDE -- both of which are overloaded with extrainous functionallity. I wrote a Tcl/Tk wrapper for the ACPI battery info for my laptop -- would you like the code? I could upload it somewhere, if anyone is interested. There already exists a an APM flavor of battery monitor (xapm) out there somewhere. > > FvwmButtons is an interesting module that can swallow any application. > Temperature metters, system tray applets, mail notification applets, clocks, > etc. can be embedded simply into FvwmButtons, so, it looks a bit odd to me to > hard code such features into fvwm itself. If you want it, add it into your > config, that's how fvwm is and I doubt it will change. > > You can also use gkrellm and conky if you preffer monoliths instead of having > a lot of small applets/metters running. > > -- Robert Heller -- Get the Deepwoods Software FireFox Toolbar! Deepwoods Software-- Linux Installation and Administration http://www.deepsoft.com/ -- Web Hosting, with CGI and Database [EMAIL PROTECTED] -- Contract Programming: C/C++, Tcl/Tk
Re: FVWM: Some items on a wish list
If what you need are light apps to swallow them into FvwmButtons what I used to use were window maker doackapps, there are quite a lot of them, and they are really nice and simple to use and configure. I guess you already know about them, but just in case :) -- Jesús Guerrero <[EMAIL PROTECTED]> pgpY3mjgbI3Z5.pgp Description: PGP signature
Re: FVWM: Issue with moving detatched Qt 4 toolbars left/right
"Johnny Ljunggren" <[EMAIL PROTECTED]> writes: >Hello > >>>> First detach a toolbar and move it somewhere on the screen. Then >>>> release and select again and try to move left or right. The >>>> position is locked sideways, but can be moved vertically. >>> Is there some way to pay one of the Fvwm developers to look at this, >or >>> could you point me to roughly where in the code this is handled? >> this is from the Fvwm source file fvwm/events.c >> At least part of the Qt logic is in file: >> qt-x11-opensource-src-4.3.5/src/gui/widgets/qtoolbar.cpp >I've dug with a big shovel into this and have come up with this: >The 'fault' on the fvwm side is in the method >__handle_cr_on_client(...) (events.c) where the cre.value_mask never >has the CWX bit set. For test purposes I did: >cre.value_mask |= CWX; >and then it works as it should. To figure out why CWX was never set I >looked in the qt source code and found in file qwidget_x11.cpp, method >setGeometry_sys(...): >e.xclient.data.l[0] = StaticGravity | 1<<8 | 1<<9 | 1<<10 | 1<<11 | >1<<12; >The first four bits are set to StaticGravity=1010b which will match CWY >(10b) but not CWX (01b). I'm not sure I follow this part. How does value_mask match to data? >I'm not an expert on this but it seems to me that it is not correct to >check for CWX/CWY at all. I found some links but don't have enough X >knowledge to interpret either way: >[1]http://standards.freedesktop.org/wm-spec/1.4/ar01s09.html >[2]http://tronche.com/gui/x/xlib/window/attributes/gravity.html >What side effects would it have to remove the check for CWX/CWY in this >method? Cool, I did some poking around but didn't get that far. Fvwm is examining the configure request to see if it's a request to move the window. Fvwm says if X/Y isn't being changed, the window isn't being moved. That seems right to me. >BTW: Style * MWMDecor overrode the DecorateTransient style, so that's >why I was a bit lost... Interesting.
Re: FVWM: Some items on a wish list
2008/8/6 <[EMAIL PROTECTED]>: > The laptop is running, over on the other side of the room, because I have > been involved in doing some security upgrades on it, while dealing with > e-mail over here. So I just went over there and ran "sensors" and it says > there are none. There is something called "smbus" connected to the PIIX4 > chipset, but it is not at all obvious what it does. What does dmidecode tell you? What's your kernel version? > The BIOS has a screen for display of battery status, so presumably this > information needs to be read by some app, and it seems that "sensors" is not > doing it. By this point this has *nothing* to do with FVWM, so you will want to look elsewhere. -- Thomas Adam
Re: FVWM: Some items on a wish list
At Wed, 6 Aug 2008 17:32:34 -0500 (CDT) [EMAIL PROTECTED] wrote:
>
>
> Thanks, something else to look into.
>
> Now, however, a problem, just discovered:
>
> The laptop is running, over on the other side of the room, because I have
> been involved in doing some security upgrades on it, while dealing with
> e-mail over here. So I just went over there and ran "sensors" and it says
> there are none. There is something called "smbus" connected to the PIIX4
> chipset, but it is not at all obvious what it does.
>
> The BIOS has a screen for display of battery status, so presumably this
> information needs to be read by some app, and it seems that "sensors" is
> not doing it.
Battery status is handled by either APM or APCI, depending on laptop
vintage and/or BIOS settings. Older laptops used APM and newer ones use
APCI. Modern kernels detect which. If APM, you need apmd and (x)apm to
check battery status, if APCI, the kernel creates some directories under
/proc/acpi that contain text 'files' that contain the state of the power
plug (/proc/acpi/ac_adapter/AC/state) and the batteries
/proc/acpi/battery/*/{info,state}.
The sensors are handled by lm_sensor -- these include stuff like power
supply voltages, CPU temp, and CPU fan speed. "smbus" also includes
reading some proms and stuff -- can be used to identify things like
DIMMS and such like. You can try running sensors-detect (as root) and
see if it finds the sensors. You might need to load some kernel modules
to get this going.
>
> I have tried running KDE on the laptop, and it does then display a battery
> icon. But at this point it is not obvious to me how KDE is getting the
> information out of the BIOS.
See above.
>
> Any ideas what might be going on down at this, more basic level?
>
> Apparently, this seems to be turning into a major engineering project. :/
Someone already has solved it...
>
> Theodore Kilgore
>
>
>
> On Thu, 7 Aug 2008, Jesús Guerrero wrote:
>
> > If what you need are light apps to swallow them into FvwmButtons what I used
> > to use were window maker doackapps, there are quite a lot of them, and they
> > are really nice and simple to use and configure. I guess you already know
> > about them, but just in case :)
> >
> > --
> > Jesús Guerrero <[EMAIL PROTECTED]>
> >
>
>
--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software-- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
[EMAIL PROTECTED] -- Contract Programming: C/C++, Tcl/Tk
Re: FVWM: Some items on a wish list
On Wed, 6 Aug 2008, Thomas Adam wrote: 2008/8/6 <[EMAIL PROTECTED]>: The laptop is running, over on the other side of the room, because I have been involved in doing some security upgrades on it, while dealing with e-mail over here. So I just went over there and ran "sensors" and it says there are none. There is something called "smbus" connected to the PIIX4 chipset, but it is not at all obvious what it does. What does dmidecode tell you? What's your kernel version? dmidecode? It tells me lots of things. Specifically, what should one look for? It does have Handle 0x1600, DMI type 22, 26 bytes Portable Battery Location: Left Module Bay Manufacturer: Panasonic Name: 4460 Design Capacity: 66010 mWh Design Voltage: 14800 mV SBDS Version: 1.0 Maximum Error: 1% SBDS Serial Number: 0378 SBDS Manufacture Date: 2007-06-06 SBDS Chemistry: LION OEM-specific Information: 0x0001 and a similar section about a temperature sensor. But neither of these appear to be actually reporting real-time data. Kernel is 2.6.24.4, locally compiled. I _do_ finally find the information, though: There is a directory /proc/acpi and in it there are relevant subdirectories, one of them named battery and the other named thermal_zone. Now, the subdirectory battery/BAT0 has in it several files, for example "state" which has in it present: yes capacity state: ok charging state: charging present rate:29069 mW remaining capacity: 69190 mWh present voltage: 16755 mV The BIOS has a screen for display of battery status, so presumably this information needs to be read by some app, and it seems that "sensors" is not doing it. By this point this has *nothing* to do with FVWM, so you will want to look elsewhere. Well, at this point it does seem there is some information after all. So the question is how to use it. -- Thomas Adam Theodore Kilgore
Re: FVWM: Some items on a wish list
On Wed, 6 Aug 2008, Robert Heller wrote:
At Wed, 6 Aug 2008 17:32:34 -0500 (CDT) [EMAIL PROTECTED] wrote:
Thanks, something else to look into.
Now, however, a problem, just discovered:
The laptop is running, over on the other side of the room, because I have
been involved in doing some security upgrades on it, while dealing with
e-mail over here. So I just went over there and ran "sensors" and it says
there are none. There is something called "smbus" connected to the PIIX4
chipset, but it is not at all obvious what it does.
The BIOS has a screen for display of battery status, so presumably this
information needs to be read by some app, and it seems that "sensors" is
not doing it.
Battery status is handled by either APM or APCI, depending on laptop
vintage and/or BIOS settings. Older laptops used APM and newer ones use
APCI. Modern kernels detect which. If APM, you need apmd and (x)apm to
check battery status, if APCI, the kernel creates some directories under
/proc/acpi that contain text 'files' that contain the state of the power
plug (/proc/acpi/ac_adapter/AC/state) and the batteries
/proc/acpi/battery/*/{info,state}.
The sensors are handled by lm_sensor -- these include stuff like power
supply voltages, CPU temp, and CPU fan speed.
I know.
"smbus" also includes
reading some proms and stuff -- can be used to identify things like
DIMMS and such like.
Is there, then, a command called "smbus"?
You can try running sensors-detect (as root) and
see if it finds the sensors. You might need to load some kernel modules
to get this going.
I did. Some excerpts from the output:
To continue, we need module `i2c-dev' to be loaded.
Do you want to load `i2c-dev' now? (YES/no): YES
Module loaded successfully.
We are now going to do the I2C/SMBus adapter probings. Some chips may
be double detected; we choose the one with the highest confidence
value in that case.
If you found that the adapter hung after probing a certain address,
you can specify that address to remain unprobed.
Next adapter: SMBus PIIX4 adapter at 0840 (i2c-0)
Do you want to scan it? (YES/no/selectively): YES
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'...No
Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to probe them. This is usually safe though.
Some south bridges, CPUs or memory controllers may also contain
embedded sensors. Do you want to scan for them? (YES/no): YES
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors...No
AMD K8 thermal sensors... No
AMD K10 thermal sensors... No
Intel Core family thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
Sorry, no sensors were detected.
Either your sensors are not supported, or they are connected to an
I2C or SMBus adapter that is not supported. See doc/FAQ,
doc/lm_sensors-FAQ.html or http: et cetera.
OTOH the commanbd i2cdetect gives
[EMAIL PROTECTED]:/usr/src/linux# i2cdetect
Error: No i2c-bus specified!
Syntax: i2cdetect [-y] [-a] [-q|-r] I2CBUS [FIRST LAST]
i2cdetect -F I2CBUS
i2cdetect -l
i2cdetect -V
I2CBUS is an integer
With -a, probe all addresses (NOT RECOMMENDED)
With -q, uses only quick write commands for probing (NOT RECOMMENDED)
With -r, uses only read byte commands for probing (NOT RECOMMENDED)
If provided, FIRST and LAST limit the probing range.
With -l, lists installed busses only
Installed I2C busses:
i2c-0 smbus SMBus PIIX4 adapter at 0840
[EMAIL PROTECTED]:/usr/src/linux#
I have tried running KDE on the laptop, and it does then display a battery
icon. But at this point it is not obvious to me how KDE is getting the
information out of the BIOS.
See above.
Any ideas what might be going on down at this, more basic level?
Apparently, this seems to be turning into a major engineering project. :/
Someone already has solved it...
Good thing, too.
I think the problem is localized now, though. The acpi stuff seems to be
working and reporting information. So the question is now the same as in
my previous reply post: how to use that information and to get it onto an
fvwm button?
Theodore Kilgore
