On 2003/03/12 16:31, Tuomo Valkonen <[EMAIL PROTECTED]> wrote: > The programs that are "incorrectly" placed probably specify a position > in wm size hints. Ion places the window in the frame under those > coordinates. There used to be a CF_PLACEMENT_GEOM option that had
I didn't check that, but wouldn't this also mean that Emacs and rxvt would be placed in the wrong frame in single-headed mode? Worked perfectly in single-headed mode for me. Or did you mean viewports, not frames? > This isn't a bug either, but a feature :). Ion doesn't check for > EnterNotify events while the pointer is grabbed for other reasons. > I might add some kludge to do so in this case, though. I understand.. this bug doesn't annoy me, because I don't use the mouse to drag windows in most cases. In fact, when I read about the new feature that allowed me to switch workspaces, my first thought was "There might be this bug", I tried it out, and I happened to be right ;) > I am not such a big fan of C++. About the only usable things in the > language (or should I say "awful kludge on top of C") are the very [...] I don't like the standard C++ library either. But in my opinion, your ion code is much more an awful kludge on top of C ;) I'm only talking about the syntax, which is OK in C++, but looks strange in your code. > It shouldn't be too hard to convert all the class stuff to C++, but > there would then be the memory overhead of a unused c++ library (I You are not required to link the C++ library if you don't use it. No overhead here. > stick to nice c functions instaed of the c++ crap) and in some aspects > the the dynamic function code in Ion is more convenient: no need to > specify all the functions in one place. Also, IIRC (it's been a long That's a good point against C++.. reminds me somehow of reflection in Java. But I'm not sure yet if this is really required, I havn't read the ion code completely yet. > of an inheriting class and then the parent. But I really need to process > "watches" first with a almost fully working object (watches are used to > keep track of objects that could be destroyed without a pointer holder > otherwise knowing of it). Would it be possible to overload delete to do > this? Overloading "delete" would be another questionable hack.. What you need doesn't seem to be possible with standard C++ destructors. Processing watches is IMHO not the job of a destructor - maybe a method "on_destroy" (or some other name) processes watches, and before you delete an object, call this method. Just one idea, and yes it's also a hack which obfuscates the code a little. max
