| Howto |
Howto make your icons available for IceWM
IceWM can use different types of pictures as icons. Default for now is usage of XPM files (some kind of pixmap).
That's in case IceWM is compiled with libXpm support. It can also be compiled with libpng, then it can use PNG images.
Default XPM sizes are 16x16 and 32x32 pixels. You can very simply create them in e.g. GIMP. Then you need to
give them a proper name "iconname_16x16.xpm" and "iconname_32x32.xpm".
Then copy this new icon into directory you are using for IceWM icons.
In icewm <= 1.2.2 it is usually /usr/X11R6/lib/X11/icewm/icons
in higher version this is /usr/share/icewm/icons .
You can also copy them to your ~/.icewm/icons
If you want to add more directories to be searched for icons change or add line into your preferences:
IconPath="[directory1] : [directory2]"
Then, to put icons in menu you need to modify
~/.icewm/menu
prog "Full Application Name" "iconname" what_to_start -options
For toolbar modify
~/.icewm/toolbar
prog "Full Application Name" "iconname" what_to_start -options
If you want icons to appear in window frame and ALSO in taskbar you need to modify
~/.icewm/winoptions
AppClassName.icon: iconname
Usage of winoptions is more complicated. See IceWM documentation and FAQ. For basic understanding - you need to use
xprop | grep CLASS utilities to find window CLASS.
|
| FAQ |
-
Question:
An application has two windows, the main window and the odcklet. I'd
like to set options (via winoptions) for the docklet and for the main
window. The problem is, both parts of WM_CLASS are the same for both
windows; only WM_NAME and WINDOW_ROLE are different (in case of
WM_NAME the only difference is letter case).
Is this possible? (Without hacking on IceWM, I mean)
Answer:
Not for role. See the IceWM docs, chapter 12, Window Options. The
entry would be 'Class.Name.Option: value'. It is also valid to cover
all the same name only with 'Name.Option: value' or all the same class
with 'Class.Option: value'. Role is not included as far as the docs are
concerned, though I've not personally confirmed that.
In my case, with xterm, I wanted to ditch the title/control bar and
prevent the app from being closed. Getting rid of the control bar
effectively prevents closing by virtue of removing the buttons and
control menu.
---begin---
XTerm.dTitleBar: 0
XTerm.fClose: 0
XTerm.dClose: 0
XTerm.dSysMenu: 0
---end---
This example uses just the class XTerm. It would also be valid to use
'XTerm.xterm.dTitleBar: 0'. You can launch xterm with an option that
changes the name, 'xterm -name (name)'. So I could get specific with
one thing with 'xterm -name admin -e printconf', allowing me to control
that specific window with 'XTerm.admin.dTitleBar: 0'. Other apps may or
may not allow similar renaming.
In your case use both the dTitleBar to get rid of the title/control bar
and dSysMenu if you don't want them to have the menu (File, Edge,
View...). Set to 0 to remove the items (class.name.dTitleBar: 0).
-
Question:
I'm going to write a program to set window options with easy-to-use GUI,
and I have few questions about it.
1. Is there any other program for this purpose.
2. I found that documentation does not include all availible options.
Where can I find list of all options?
3. Xprop returns something like this:
WM_CLASS(STRING) = "xterm", "XTerm"
Which name is better to use? Or maybe both of them? Is there any
difference?
Answer:
> 2. I found that documentation does not include all availible options.
> Where can I find list of all options?
The main winoptions file for IceWM, usually
/usr/X11R6/lib/X11/icewm/winoptions.
> 3. Xprop returns something like this:
> WM_CLASS(STRING) = "xterm", "XTerm"
This is the name and class identifier. If you start xterm with 'xterm
-name othername' xprop would report '"othername", "XTerm"'.
> Which name is better to use? Or maybe both of them? Is there any
> difference?
Note that the winoptions doc page has the full entry reversed, showing
"window_class.window_name.option: argument" whereas it should show
"window_name.window_class.option: arugment". This means
'XTerm.xterm.option: argument' will not work, but
'xterm.XTerm.option: argument' will work.
The window_class typically, as far as I know, goes with the binary being
run. xterm's class is XTerm. Run xprop on other windowed programs to see
their class names.
The window_name is more of an environment setting within the program, and
may be set by available options or by the routines within the program
itself. xterm's '-name name' option is an example of how to set the
variable.
Here's the scenarios intended:
You have several different classes/programs under the same window_name.
This would allow you to control the behavior of all the programs under the
same window_name, even if they have different window_class entries. So a
'window_name.option: arguement' like 'chip.fClose: 1' would cover all of
the following:
"chip", "XTerm"
"chip", "Xvi"
"chip", "SomeOtherClass"
BUT NOT
"xterm", "XTerm"
Next, you have one binary that runs several different names but only one
window_class. So a 'window_class.option: argument' like
'XTerm.fClose: 1' would cover all of the following:
"xterm", "XTerm"
"pbadmin", "XTerm"
"foo", "XTerm"
BUT NOT
"foo", "Xvi"
Last, and most specifically, is 'window_name.window_class.option:
argument'. So 'xterm.XTerm.fClose: 1' only would cover:
"xterm", "XTerm"
BUT NOT
"pbadmin", "XTerm"
or
"foo", "XTerm"
|
