Re: [E-devel] Using ecore_x

[Marc M. <mar...@m4...>]

Hey, first thanks for your answer.

* Carsten Haitzler (ra...@ra...) wrote:
> On Tue, 20 May 2003 09:45:45 +0200 Marc Menem <mar...@m4...>

> > > second window create? create where? ecore_x actually has no calls to
> > > set up event "selection" masks on windows. it's done for u when u
> > > "manage" a window but nothing to set it up - so u'll never even be
> > > getting the event unless you're a wm and have called the "manage"
> > > call on the root window.
> > 
> > I need all the windows connected to the X server. As I understand
> > ecore will only give me create events for _my_ windows, unless I
> > claim that I am a window manager. Is there a way to do this or can
> > there be only one wm ? -- I'm not sure to understand why it worked
> > wirh the old ecore and not with the new one.
> 
> ecore doesn't provide a way of doing this - no :( the calls could be
> added in a few lines of code - but you need to identify exactly what
> it is you want to do first.
> 

I am not sure myself of what i need...


> aaaah. well first you yes - need to listen for createnotify. then
> you need to add that window id to your list of windowid's to
> watch. add some more event masks on that window to say you want to
> listen for structute & visibility notifies on that window. if you
> get an destroynotify event for that window - remove it form your
> list. if you get a mapnotify event you now know it has been shown
> somewhere and is visible. this is the point where you know the app
> has successfully started. enstrom uses this trick :) 

What is enstrom ?

now the problem
> comes in mapping a window id to what process owns it... thats the
> trick. if e17 itself launched it u'll get extra window properties
> set before it is mapped that contain its process id and more. if
> not.. you're in for a tough time :)
> 

Yes, right, that's how it works. But I am not using e17.

I am using a bit of code doing the trick. No real need to identify the
process Id, just reading into the properties of the windows to get its
names. 

Maybe I can send you the modified iconbar using the old ecore if you
like to have a look. the code's still crappy - most comments are in
french, but it is able to keep a list of managed windows, update
what's going on, and search for the window id of a particular app. I
though that switching to ecore_x would just mean change the
callbacks...


> so basically ecore_x doesn't provide the api calls u need to
> 1. "sniff" on the root window for creates etc. 2. snif a particular
> window id waiting for it to be mapped, moved, resized, destroyed
> etc. theses are the 2 calls you really want. i can add them if this
> is what you are actually trying to do. ecore_x is a never ending
> development effort with calls for whatever people need there doing
> the right thin with x protocol to achieve the aim of the function
> call.
> 

Well, if you point me to the right way to do it, I could try. But
right now, Ecore's structure's not very clear to me - I don't know
where to look. I really need help with ecore_x if i am going to use
it. I though that since it is aimed at being the core of a window
manager i would get the functions need.


> > I noticed evas doesn't set the override bit on it's windows, so i'm
> > getting them to. Is there an another way to determine I don't need
> > them ?
> 
> of course evas doesnt. override bypasses the wm. :) just ignore them
> when you get the events. :)
> 

Of course i'm just ignoring them, but why would the WM care about all
the windows created when an icon is pulsating ? Shouldn't there be a
way to precent this, since the window is quickly destroyed ?



Marc

--
ICQ: 59775877
Jabber: mar...@ja...