Re: No focus on map hint



On Friday 14 of March 2003 08:00, John Harper wrote:
> Rob Adams writes:
> |_STATE properties can be changed once the window is mapped.  But your
>
> yes, I meant that since it doesn't make sense to be able to change the
> "focus on map" property, maybe it shouldn't be in _STATE
>
> |point is well-taken.  It doesn't work however to put it into types,
> |since you'd want to be able to set this hint regardless of type, and the
> |way the type hint works exactly one type is selected as the type to use.
> |
> |So we're left with either putting it into _STATE or creating a new
> |top-level hint.  Which do you think would be better?
>
> I would prefer a separate property:
>
>     _NET_WM_MAP_TIMESTAMP CARDINAL/32
>
>     Read by the window manager when the window is mapped. If the
>     property is set to a non-zero value TIME, the application is
>     declaring that the window was mapped due to a user action at server
>     timestamp TIME. If set to a zero value the window was mapped for
>     some other reason (i.e. not caused by the user directly)
>
> but for this to be implemented fully it would require toolkit support,
> and probably also a standardized environment variable so that
> application launchers could pass initial timestamps to applications.

 I like this, and I'm in favour of this.

 And in fact, I think it could help me to solve a little problem related to 
startup notification. In case you don't know, KDE has a feature that tries to 
avoid stealing focus, e.g. imagine you are typing in kwrite, then you decide 
to visit some www site, so you start Konqueror, and while waiting for 
Konqueror to start up, you keep typing in kwrite. Newly started Konqueror 
won't get focus and therefore won't interrupt the typing.

 The current implementation is basically just a hack, so I'd prefer this 
cleaner solution. The environment variable needed for it could be simply 
handled together with startup notification, so that wouldn't be a problem.

(Thinking of it, _MAP_ in the name is slightly misleading, but I don't have 
any better idea).

On Friday 14 of March 2003 08:20, Rob Adams wrote:
> On Thu, 2003-03-13 at 23:19, John Harper wrote:
> > Rob Adams writes:
> > |That seems considerably more cumbersome in implementation than is
> > |necessary to acheive the semantics we're after here.
> >
> > I don't think so. At minimum (wm's only handle the == 0 case) it's
> > simpler than your original proposal, and it leaves open the possibility
> > that things might work better in the future.
>
> Mostly it's cumbersome on the toolkit side.

(Would you mind replying after quoted text?).

 I don't think it would be that difficult. Just remembering the last timestamp 
of mouseclick or keypress event, using that for normal cases, and explictly 
having to set the timestamp to zero for specific cases should IMHO do the job 
sufficiently.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]