Something seems seriously wrong...
Hi,
I haven't looked at this before, I guess I've been sloppy (or I didn't
care about gnome at the time)... but getting this kind of warning got
me intrigued:
/home/levitte/bzrwrk/ctwm/bzr/trunk/events.c:2200:32: warning: comparison
with string literal results in unspecified behavior [-Waddress]
/home/levitte/bzrwrk/ctwm/bzr/trunk/events.c:2207:32: warning: comparison
between pointer and integer
if(Event.xclient.message_type == XA_WIN_STATE) {
And even better:
In file included from /home/levitte/bzrwrk/ctwm/bzr/trunk/menus.c:100:0:
/home/levitte/bzrwrk/ctwm/bzr/trunk/menus.c: In function ‘Squeeze’:
/home/levitte/bzrwrk/ctwm/bzr/trunk/gnomewindefs.h:8:36: warning: passing
argument 3 of ‘XGetWindowProperty’ makes integer from pointer without a cast
#define XA_WIN_STATE _WIN_STATE
^
/home/levitte/bzrwrk/ctwm/bzr/trunk/menus.c:4575:42: note: in expansion of
macro ‘XA_WIN_STATE’
if(XGetWindowProperty(dpy, tmp_win-w, XA_WIN_STATE, 0L, 32, False,
^
In file included from /home/levitte/bzrwrk/ctwm/bzr/trunk/ctwm.h:71:0,
from /home/levitte/bzrwrk/ctwm/bzr/trunk/menus.c:83:
/usr/include/X11/Xlib.h:2676:12: note: expected ‘Atom’ but argument is of
type ‘char *’
extern int XGetWindowProperty(
^
Having a closer look, I can't quite understand how the macros
XA_WIN_STATE etc are useful... It does seem like, in this example,
_XA_WIN_STATE (initialised in gnome.c) should be used instead...
I do have a fleeting memory that the Gnome stuff was said to be half
baked way back when... maybe it's time to clean it up a bit...
--
Richard Levitte rich...@levitte.org
http://richard.levitte.org/
Life is a tremendous celebration - and I'm invited!
-- from a friend's blog, translated from Swedish
Re: Something seems seriously wrong...
On 19/07/15 11:27, Matthew D. Fuller wrote: On Sun, Jul 19, 2015 at 11:18:32AM +0200 I heard the voice of Richard Levitte, and lo! it spake thus: Having a closer look, I can't quite understand how the macros XA_WIN_STATE etc are useful... It does seem like, in this example, _XA_WIN_STATE (initialised in gnome.c) should be used instead... I do have a fleeting memory that the Gnome stuff was said to be half baked way back when... maybe it's time to clean it up a bit... Yeah, that looks pretty wacked out. Sounds like a not unreasonable quick fix. Better probably would be just to convert it over to the autogen atoms stuff Olaf added a while back for EWMH and the main ctwm atoms; simplifies a lot of manual code. I have had the impression that the Gnome stuff was for Gnome 1.x and it's not been supported since RedHat 8, so if I'm right, shouldn't that code be removed? -- //Aho
Re: Something seems seriously wrong...
On Sun 19 Jul 2015 at 11:42:13 +0200, J.O. Aho wrote: I have had the impression that the Gnome stuff was for Gnome 1.x and it's not been supported since RedHat 8, so if I'm right, shouldn't that code be removed? That was my impression. As far as I know the Extended Window Manager Hints were designed to completely replace the Gnome stuff and everybody who implemented that now implements EWMH. That's why I disabled the Gnome stuff when I implemented EWMH. //Aho -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpbntkG0CbUs.pgp Description: PGP signature
Re: Something seems seriously wrong...
On 19/07/15 12:01, Matthew D. Fuller wrote: On Sun, Jul 19, 2015 at 11:47:01AM +0200 I heard the voice of Rhialto, and lo! it spake thus: On Sun 19 Jul 2015 at 11:42:13 +0200, J.O. Aho wrote: I have had the impression that the Gnome stuff was for Gnome 1.x and it's not been supported since RedHat 8, so if I'm right, shouldn't that code be removed? That was my impression. As far as I know the Extended Window Manager Hints were designed to completely replace the Gnome stuff and everybody who implemented that now implements EWMH. That's why I disabled the Gnome stuff when I implemented EWMH. Accords with my understanding (though of course, a lot of that comes from you, so that's cheating ;). I certainly would expect anything new or even not-particularly-new to be talking EWMH instead of GNOME1 (or not having a use for neither). My only concern would be really old stuff that's not updated. I have a suspicion, for instance, that Gnome 1.x also means GTK 1.x. There are probably still a few old programs in that category that people might use here and there. I've never bothered investigating to find out for sure, so maybe I'm just dreaming that. Wouldn't those people be used to compile their programs themselves and be able to use a patch file? I haven't seen much of gtk+1 and gnome1 around since the release of RedHat 9 and that is a few years ago. Of course, ctwm-2015 is caring a lot less about speculatively supporting Really Old Stuff than ctwm-2000 did, and that's OK. But this seems like a fairly cheap thing to have around. It's not entirely uninvasive; there's a fair amount of #ifdef GNOME floating around, but it's not as twistedly intertwined as the VMS stuff was. And we be eat that expense whether it's enabled or not, as long as it's still around. How do you test that those Gnome1 things still works? What happens if people enables the Gnome support just for they think it will do something in Gnome3 and suddenly there could be a potential security vulnerability as the code hasn't really been tested. There seems like there have been toughts of enabling the Gnome support in ctwm for Gentoo, at least there is the following comment in the ebuild: # TODO: Add GNOME support This has been hanging around since 3.8a, but could be just for the ebuild ain't properly mainteined anymore. -- //Aho
Re: Something seems seriously wrong...
On Sun, Jul 19, 2015 at 12:23:06PM +0200 I heard the voice of J.O. Aho, and lo! it spake thus: Wouldn't those people be used to compile their programs themselves and be able to use a patch file? That would be a patch file along the lines of rewrite entire app into newer API ;) What happens if people enables the Gnome support just for they think it will do something in Gnome3 and suddenly there could be a potential security vulnerability as the code hasn't really been tested. Well, it's probably about as carefully security audited as the rest of the codebase. Which, OK, as reassurance goes... It IS documented in the README and the cmake output as being GNOME 1 related. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
