--xclass switch actually changes WM_CLASS property, but openbox uses
_OB_APP_CLASS for matching. This property is created together to the original.
Probably roxterm's --xclass switch, changes WM_CLASS after window mapping,
making _OB_APP_CLASS useless. This behaviour seems to be non-compliant with
icccm spec http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5
Is it possible change switch behaviour?
It sets the class shortly after gtk_window_new, before doing anything else to
the window like showing it, so it should be right. There was a possibility it
was trying to change the setting after mapping when restoring a session, which
I've just fixed, but are you having the problem all the time, not just after
restoring a session? I don't know why.
from http://developer.gnome.org/gtk/2.24/GtkWindow.html#gtk-window-set-
wmclass
Don't use this function. It sets the X Window System "class" and "name" hints
for a window. According to the ICCCM, you should always set these to the same
value for all windows in an application, and GTK+ sets them to that value by
default, so calling this function is sort of pointless. However, you may want
to call gtk_window_set_role() on each window in your application, for the
benefit of the session manager. Setting the role allows the window manager to
restore window positions when loading a saved session.
probably you should drop --xclass and --xname, and add just --xrole, it works
with xfce4-terminal under openbox.
Other request: could you add real transparency? It should just need this
snippet inside window creation
screen = gtk_window_get_screen (GTK_WINDOW (window));
colormap = gdk_screen_get_rgba_colormap (screen);
if (colormap != NULL)
gtk_widget_set_colormap (GTK_WIDGET (window), colormap);
as you can see it check composition presence, otherwise does nothing.
Thanks a lot for your code and your willingness :)
Some people specifically asked to be able to set class and name. See <https:/
/sourceforge.net/projects/roxterm/forums/forum/422638/topic/3285853> and <http
s://sourceforge.net/tracker/index.php?func=detail&aid=3016553&group_id=124080&
atid=698431>. But in view of your problem I think it would
be better to make them apply globally instead of to each window and add a role
option.
I don't understand your request for real transparency. There is an option for
true translucence with compositing in the Background section of profiles. It
works for me with compiz and xfwm4. Did you miss it or is it not working for
you, or not doing quite what you want? The feature is supported by vte and
AFAICT it also "automagically" applies to its parent GtkNotebook's tabs, but
not to the menu bar.
Sorry for erroneous request on transparency. I made a little confusion
customizing, it works perfectly also with cairo-compmgr. :)
I think --role should be sufficient for anyone:class and name identify the
program, eventual customized role value identify the use you wanna make of one
particular instance of the program itself.
WM should match class/name to apply properties to all the instances of a
program, while match role for single instance. I think it should fits
everyone's needs (at least for icccm WMs) and make roxterm icccm compliant.
Obviously it's your choice :D
I'm familiarizing with your software, it's really great! Adding --role option
will make it perfect, and make it completely substitute xfce4-terminal from my
system. I need that to launch a totally invisible terminal sticky on my
desktop (at least, a kind of...)
Sorry again, I know i'm really boring you. :-)
I found the problem with transparency. Probably roxterm doesn't listen for
composition message. So, while I start automatically at boot compositor and a
roxterm instance, the second one is completed before compositor, and doesn't
detect the alpha channel managment. If you your program could implement this
feature, I could avoid settings sleep and other things like that. http://tron
che.com/gui/x/icccm/sec-2.html#s-2.8
P.S.:
I know that cairo-compmgr doesn't respect that spec, but I adapted a similar
patch from xcompmgr and on my system cairo-compmgr is compliant.
I have to admit that this is an area I don't know much about. But I think if I
responded to the "composited-changed" signal from GdkScreen that would do the
trick?
I'm totally ignorant in this things. :-/
I've seen that roxterm has strange behaviour to composite state change, based
on the moment in which its windows is created: if i launch roxterm when
composite is on, then it react in such a way to next state changes, if I
launch it when composite is off it behaves in another way.
In my total ignorance, I think you're on the right way with composite-changed
signal. I post an interesting snippet taken from xfce4-terminal, that manage
correctly composite switching, hoping it helps
static void
terminal_screen_realize (GtkWidget *widget)
{
GdkScreen *screen;
(*GTK_WIDGET_CLASS (terminal_screen_parent_class)->realize) (widget);
/* make sure the TerminalWidget is realized as well */
if (!GTK_WIDGET_REALIZED (TERMINAL_SCREEN (widget)->terminal))
gtk_widget_realize (TERMINAL_SCREEN (widget)->terminal);
/* connect to the "composited-changed" signal */
screen = gtk_widget_get_screen (widget);
g_signal_connect_swapped (G_OBJECT (screen), "composited-changed", G_CALLBACK (terminal_screen_update_background), widget);
}
static void
terminal_screen_unrealize (GtkWidget *widget)
{
GdkScreen *screen;
/* disconnect the "composited-changed" handler */
screen = gtk_widget_get_screen (widget);
g_signal_handlers_disconnect_by_func (G_OBJECT (screen), terminal_screen_update_background, widget);
(*GTK_WIDGET_CLASS (terminal_screen_parent_class)->unrealize) (widget);
}
Thanks again for your time
Please can you test roxterm from git. I've changed the class/name/role options
as discussed and added a signal handler for "composited-changed". Now if I
start roxterm without compositing and turn compositing on it switches between
showing the backdrop and true translucency, which presumably it wouldn't have
been able to do before.
I was already trying that, but...
*** No rule to make target `roxterm.1.es.xml.in', needed by `roxterm.1.es.xml'. Stop.
I guess you don't have po4a installed and I need to fix the Makefile* so it
will work without it, bypassing the translations. In the meantime would you
mind installing po4a so you can build roxterm?
po4a-0.41-1 is present on my system.
I can only think that the build system hasn't recognised that po4a is
installed. Did you by any chance try to build without po4a first, then install
po4a but didn't run configure again? Otherwise is po4a-translate in $PATH and
did configure find it (check HAVE_PO4A in config.log)?
You might be wondering why the ENABLE_PO4A conditional in Makefile.am
apparently isn't helping, but it's there to allow building from a release
tarball without po4a. The tarballs contain some files generated by po4a that
aren't in the git repository so building without po4a isn't an option for git.
configure:17741: checking for po4a-translate
configure:17769: result: no
....
HAVE_PO4A='no'
:-/
but
locate po4a-translate
/usr/bin/vendor_perl/po4a-translate
and
echo $PATH
...
/usr/bin/vendor_perl:
...
I just tried to recompile exactly as yesterday, but now there's a different
error
/home/javier/dati/abs/roxterm-git/src/roxterm-build/install-sh: ./Help/lib/roxterm_logo.png does not exist. make[2]: *** [install-data-local] Error 1 make[2]: Leaving directory `/home/javier/dati/abs/roxterm-git/src/roxterm-build' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/home/javier/dati/abs/roxterm-git/src/roxterm-build' make: *** [install-recursive] Error 1
Are the permissions correct on po4a-translate? What if you link it to a more
conventional place like /usr/local/bin?
Re logo.png: Do you have imagemagick and librsvg installed?
po4a is now fixed, If I don't mind, after a perl script installation an update
of some vars procedure is required, and a reboot probably did the trick. I
will investigate later...
Now the problem is with the logo: yes I have those package installed, but in
you git tree there's no roxterm_logo.png inside Help/lib
while is present into tar of last stable release instead.
The top-level Makefile creates roxterm_logo.png from roxterm.svg:
LOGO_PNG = $(top_srcdir)/Help/lib/roxterm_logo.png ... $(LOGO_PNG): roxterm.svg convert -background '#0000' roxterm.svg -geometry 64x64 $(LOGO_PNG)
Where can I find info useful for debug this malfunction?
Ok, I already make you lose too much time. I copied roxterm_logo.png and
logo_text.png form tarball to right building directories and tested it.
--role works perfectly! both WM_WINDOW_ROLE(STRING) both
_OB_APP_ROLE(UTF8_STRING) are correctly set.
--xclass and --xname have the same previous behaviour. But I don't care, I
keep thinking that those two options souldn't exist at all.
composition is correctly recognized in any condition, and composite switching
works well too.
I'm really sorry I've not been able to help you to solve building problem.
Thanks again for your time and your patience. :-)
Part of the new code to keep class and name consistent wasn't working properly
so I've changed it. It seems to be OK for me now, but I don't know whether it
will fix the problem you've been having in conjunction with openbox.
I just tried last commit. --xclass and --xname have the same behaviour, but I
think it's normal, cause the new variables were added by openbox devs on
purpose to avoid non-compliant apps to change properties after window mapping.
I don't care, I need just --role switch (and I think everybody needs just
that, however everybody is free to choice :-) )
Everytime I launch roxterm I get this warning
(roxterm:6001): WARNING : Failed to connect to session manager:
SESSION_MANAGER environment variable not defined
I don't mind If I got that with stable release also. I don't use any display
manager and launch X automatically at boot through inittab, this method
actually doesn't use /bin/login and doesn't register a session, so I think
this warning has nothing to do with your program.
Log in to post a comment.