Menu
▾
▴
notion-devel
|
From: Ranousse <ran...@gm...> - 2012-02-26 22:43:17
|
I did the following.
1) Split the current workspace in 2.
2) In the first part of the workspace launch with F3
xpdf DemandePDF.pdf -remote some_remote_name
3) Now go to the second part and launch still with F3
xpdf -reload -remote some_remote_name -raise
(which mean reload the xpdf window of the other part)
The tabline of xpdf window become red as with urgency hints.
For me it's a little annoying since I use these method to reload my pdf
windows when using latex. As Ion3 did not use to do that, I wonder if
it's normal or if there's a bug somewhere. (it could be normal if notion
consider a wider range of messages for urgency).
I also noticed that sometimes, the curent tabline of the current window
become red after doing <ctrl-l, type url, enter> in opera browser. It
seems a little strange since in this case I'm on the current window, and
there's no reason to have the red urgency tab. I also managed to lose
the keyboard because of this (but did not manage to reproduce it a
second time). This seems a little less normal ;-)
|
|
From: Philipp H. <ph...@ph...> - 2012-02-26 23:02:53
|
Hi, > I did the following. > 1) Split the current workspace in 2. > 2) In the first part of the workspace launch with F3 > xpdf DemandePDF.pdf -remote some_remote_name > 3) Now go to the second part and launch still with F3 > xpdf -reload -remote some_remote_name -raise > (which mean reload the xpdf window of the other part) > > The tabline of xpdf window become red as with urgency hints. > For me it's a little annoying since I use these method to reload my pdf > windows when using latex. As Ion3 did not use to do that, I wonder if > it's normal or if there's a bug somewhere. (it could be normal if notion > consider a wider range of messages for urgency). I think this is intended behavior. If I understand it correctly xpdf sends a message to the window manager indicating that it requires attention and we indicate this by the red title bar. If I remember correctly at one point our behavior was worse and we even changed focus to the window requiring attention, but fortunately that got reverted. In the beginning I also found the red title very distracting, but I've gotten used to it and it's not annoying me anymore. > I also noticed that sometimes, the curent tabline of the current window > become red after doing <ctrl-l, type url, enter> in opera browser. It > seems a little strange since in this case I'm on the current window, and > there's no reason to have the red urgency tab. I also managed to lose > the keyboard because of this (but did not manage to reproduce it a > second time). This seems a little less normal ;-) I don't have Opera installed so I can't comment on that. |
|
From: Ranousse <ran...@gm...> - 2012-02-27 09:30:57
|
> If I remember correctly at one point our behavior was worse and we > even changed focus to the window requiring attention, but fortunately > that got reverted. Is there still something like that in the current code ? I had defined a "kludge" so that xterm -class a_particular_class opens in a particular scratchpad (script named_scratchpads). This used to produce (only) the urgency hint in Ion3. Now with Notion it also opens the corresponding scratchpad (which in my case is not what I want). |
|
From: Philipp H. <ph...@ph...> - 2012-02-27 20:05:15
|
> Is there still something like that in the current code ? > I had defined a "kludge" so that xterm -class a_particular_class opens > in a particular scratchpad (script named_scratchpads). > This used to produce (only) the urgency hint in Ion3. Now with Notion it > also opens the corresponding scratchpad (which in my case is not what I > want). [1] introduced awareness for client requests to be raised. Unfortunately between [1] and [2] there is the big problem that if you switch to another workspace before performing your step 3), Notion will switch back to the workspace xpdf is on, which is really annoying (that's the bad behavior I had mentioned in my first message). That's why the behavior introduced in [1] was relaxed to the behavior in [2], which instead introduced the red title bar you observe. With [2] any switching should be gone so I don't think this explains your problem. [1] http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=519a5fdccf5ab27e55436d11098b8631fd3f1218 [2] http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=35951ebac0f78fa8cad16bb23f0c4f49ae486453 |
|
From: Ranousse <ran...@gm...> - 2012-02-29 20:53:26
|
On Mon, Feb 27, 2012 at 09:05, Philipp Hartwig wrote: > > Is there still something like that in the current code ? > > I had defined a "kludge" so that xterm -class a_particular_class opens > > in a particular scratchpad (script named_scratchpads). > > This used to produce (only) the urgency hint in Ion3. Now with Notion it > > also opens the corresponding scratchpad (which in my case is not what I > > want). > > [1] introduced awareness for client requests to be raised. Unfortunately > between [1] and [2] there is the big problem that if you switch to another > workspace before performing your step 3), Notion will switch back to the > workspace xpdf is on, which is really annoying (that's the bad behavior I had > mentioned in my first message). That's why the behavior introduced in [1] was > relaxed to the behavior in [2], which instead introduced the red title bar you > observe. With [2] any switching should be gone so I don't think this explains > your problem. > > [1] http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=519a5fdccf5ab27e55436d11098b8631fd3f1218 > [2] http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=35951ebac0f78fa8cad16bb23f0c4f49ae486453 Ok. I did other checks and my problems with scratchpads seem to have gone. Moreover my problem of red tab with xpdf is solved too. It was definely not due to a notion bug but ... to my command. The only thing I had to do is removing the -raise option. Thanks for the answers. |
|
From: Ranousse <ran...@gm...> - 2012-03-07 08:51:22
|
By the way is there a way to disable these hints for a particular
window. Most of the time it works well for me now, but I still have
problems with opera windows (due to a bug in opera it seems).
So I would like something like
defwinprop {
class = "Opera",
instance = "opera",
-- something = no (something beeing raise, or hint, or ...)
}
Is it possible?
I don't know if *something* could be ignore_net_active_window (I tried
it but as it does not seem to work, I guess it's not the purpose of this
option).
|
|
From: Philipp H. <ph...@ph...> - 2012-03-11 10:09:54
Attachments:
activity.diff
|
On Wed, Mar 07, 2012 at 09:51:04AM +0100, Ranousse wrote:
> By the way is there a way to disable these hints for a particular
> window. Most of the time it works well for me now, but I still have
> problems with opera windows (due to a bug in opera it seems).
>
> So I would like something like
> defwinprop {
> class = "Opera",
> instance = "opera",
> -- something = no (something beeing raise, or hint, or ...)
> }
>
> Is it possible?
I don't think it is currently possible, but I've attached a small patch. After
applying it try setting
dont_honor_activity_request = true,
Regards,
Philipp
|
|
From: Ranousse <ran...@gm...> - 2012-03-11 12:17:35
|
> > By the way is there a way to disable these hints for a particular
> > window. Most of the time it works well for me now, but I still have
> > problems with opera windows (due to a bug in opera it seems).
> >
> > So I would like something like
> > defwinprop {
> > class = "Opera",
> > instance = "opera",
> > -- something = no (something beeing raise, or hint, or ...)
> > }
> >
> > Is it possible?
> I don't think it is currently possible, but I've attached a small patch. After
> applying it try setting
> dont_honor_activity_request = true,
Thank you, the patch seems to work fine.
However I've noticed a small problem. I don't think it's in the patch
since I already had similar problems before.
Still with opera. It's very possible that opera does things it should
not here but maybe it's interesting to understand.
I start opera without any tab opened. Then I press ctrl-l causing opera
to open a small transient windows (like the find window in xpdf).
Without the patch I could see that the main opera window becomes red due
to a raise signal and sometimes I lose the keyboard (no active window
underlined, the keyboard seems not to work, moving the mouse solves the
problem). With the patch, of course I don't have the red hint but I
still lose the keyboard (maybe more often but not sure yet).
If the problem is just due to opera that don't respect standards maybe
there's nothing to fix. However if there's a problem when a transient
window asks to raise a window, it could be more serious.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X