Menu
▾
▴
notion-general
|
From: Thomas K. <tk...@gi...> - 2012-01-07 00:08:04
|
Hi!
I've just started packaging notion for pkgsrc and evaluating it for my use.
I like that it works fine with WindowMaker dock apps and is a bit more
intuitive to use than other tiling window managers.
I have one issue with mplayer though. I'm using two screens, and when
I press 'f' in mplayer, it gets centered over both screens, i.e. half
is on one screen, half on the other (the size is correct for one
screen, not for two).
Weirdly, youtube flash fullscreen works fine for me, it uses one
complete screen (replacing dock and title bar).
I thought that perhaps the xinerama extension might help, so I added
dopath("mod_xinerama") to ~/.notion/cfg_notion.lua. The result was
that I lost my dock apps and the status bar; it's now displayed on
neither of the two screens (it was on the left monitor before).
Please advise how to get better fullscreen support for mplayer, or how
I can get the dock back with mod_xinerama.
One other question: Do I understand correctly: since notion doesn't
use the ion name, does it fall under a plain GNU LGPL v2.1?
Thanks,
Thomas
|
|
From: Arnout E. <no...@bz...> - 2012-01-07 14:14:58
|
On Sat, Jan 07, 2012 at 01:07:54AM +0100, Thomas Klausner wrote:
> I've just started packaging notion for pkgsrc and evaluating it for my use.
>
> I like that it works fine with WindowMaker dock apps and is a bit more
> intuitive to use than other tiling window managers.
Great!
> I have one issue with mplayer though. I'm using two screens, and when
> I press 'f' in mplayer, it gets centered over both screens, i.e. half
> is on one screen, half on the other (the size is correct for one
> screen, not for two).
>
> Weirdly, youtube flash fullscreen works fine for me, it uses one
> complete screen (replacing dock and title bar).
Strange
> I thought that perhaps the xinerama extension might help
If you're using 2 screens that's probably useful to you anyway
> so I added
> dopath("mod_xinerama") to ~/.notion/cfg_notion.lua. The result was
> that I lost my dock apps and the status bar; it's now displayed on
> neither of the two screens (it was on the left monitor before).
>
> Please advise how to get better fullscreen support for mplayer, or how
> I can get the dock back with mod_xinerama.
You need to load mod_dock and mod_statusbare after loading mod_xinerama.
(this is unfortunate. until we find a way to make this work whatever order
you choose, latest notion git gives you a warning when you load them in the
'wrong' order)
Does fullscreening mplayer work when mod_xinerama is loaded?
> One other question: Do I understand correctly: since notion doesn't
> use the ion name, does it fall under a plain GNU LGPL v2.1?
Unfortunately, this is only almost true.
Indeed, basically the 'strange' clauses in the Ion license only apply "If the
name Ion(tm) or other names that can be associated with the Ion project are
used to distribute this software".
Even though these 'conditional' clauses don't apply in our case, it does make
our license non-LGPL (because they might apply to people redistributing Notion
under another name, like 'Ion').
Kind regards,
Arnout
|
|
From: Philipp H. <ph...@ph...> - 2012-04-18 22:33:38
|
Hi Thomas,
On Wed, Apr 18, 2012 at 11:26:21PM +0200, Thomas Klausner wrote:
> Yes, this improves the situation. Thank you!
good to hear!
> One difference: The dock apps are on top in full screen mode for
> geeqie and firefox flash plugin, but not on top of mplayer full
> screen.
>
> General xinerama complaint remains ;)
> I still don't know why the dock icons do not reduce the size of the
> other windows (like without xinerama) -- they even are on the top of
> the edit bar you get with F3 or F4.
I've never used mod_dock, in fact I do not even know what it does, so I'm
afraid I can't help you here, sorry.
> Also, the status bar doesn't appear.
>
> Here's the diff for the config I use to the default:
> --- /usr/pkg/etc/notion/cfg_notion.lua 2012-04-18 22:58:23.000000000 +0200
> +++ .notion/cfg_notion.lua 2012-01-15 18:17:36.000000000 +0100
> @@ -75,12 +75,12 @@
>
> -- Load some modules. Bindings and other configuration specific to modules
> -- are in the files cfg_modulename.lua.
> ---dopath("mod_query")
> ---dopath("mod_menu")
> ---dopath("mod_tiling")
> ---dopath("mod_statusbar")
> ---dopath("mod_dock")
> ---dopath("mod_sp")
> +dopath("mod_xinerama")
> +dopath("mod_query")
> +dopath("mod_menu")
> +dopath("mod_tiling")
> +dopath("mod_statusbar")
> +dopath("mod_dock")
>
> In case you're wondering about mod_sp, if I leave that in I get:
> Notion startup error log:
> >> /usr/pkg/lib/notion/mod/mod_sp.so: The module is already loaded.
> >> Unable to find 'mod_sp.so' on search path.
> >> Stack trace:
> 0 [C]: in 'load_module'
> 1 stdin:1
> [Skipping unnamed C functions.]
> 4 [C]: in 'dopath'
> 5 /home/wiz/.notion/cfg_notion.lua:84
> [Skipping unnamed C functions.]
Wild guess: The diff indicates that the line
dopath("cfg_defaults")
in your cfg_notion.lua is commented IN, right?
What does your cfg_defaults.lua contain? Maybe an additional dopath("mod_sp")?
This would explain the "The module is already loaded." message.
Also does it contain a dopath("mod_statusbar")? This would explain why the
statusbar is missing: Unfortunately dopath("mod_statusbar") needs to be
executed AFTER dopath("mod_xinerama"). I guess that in your case it is
executed twice, once indirectly by dopath("cfg_defaults") and then again by
the direct dopath("mod_statusbar"), but only the first time seems to count.
Please try commenting OUT all dopaths other than dopath("cfg_defaults") in
your cfg_notion.lua and modify cfg_defaults.lua instead, while making sure
that dopath("mod_xinerama") occurs before dopath("mod_statusbar"). (In fact in
the case of cfg_defaults.lua we print a warning if the order is wrong, but
apparently not if the dopaths are done in cfg_notion.lua. :/)
Does this help?
Best,
Philipp
|
|
From: Juri H. <ju...@fa...> - 2012-04-19 19:20:00
|
On 04/19/12 at 09:14pm, Juri Hamburg wrote:
Ugh, sorry, copied some crap over :)
I ment that:
defbindings("WScreen", {
bdoc("Go to next/previous screen on multihead setup."),
kpress(META.."Shift+comma", "prev_wrap()"),
kpress(META.."Shift+period", "next_wrap()"),
})
>
> How about this?
>
> defbindings("WScreen", {
> bdoc("Move current workspace left/right."),
> kpress(META.."Shift+comma", "WScreen.dec_index(_, _sub)", "_sub:non-nil"),
> kpress(META.."Shift+period", "WScreen.inc_index(_, _sub)", "_sub:non-nil"),
> })
>
>
> On 04/19/12 at 07:01pm, Philipp Hartwig wrote:
> > If you only have two screens you can also do something completely trivial like
> > kpress(META.."Tab", "ioncore.goto_nth_screen(1-WScreen.id(_))"),
> > in the WScreen section. Or if one has N screens, one could do
> > kpress(META.."Tab", "ioncore.goto_nth_screen((WScreen.id(_)+1)%N)"),
> >
> > Or one writes a small function which saves WScreen.id(_), calls
> > ioncore.goto_next_screen, compares the return value to the saved value and
> > switches to the 0-th screen if the value hasn't changed. There's really an
> > infinite number of possibilities using only Lua. :) Certainly one can also
> > determine the N above dynamically.
> >
> > But the main point is that you find some way of doing this that suits your use
> > case. :)
> >
> > Regards,
> > Philipp
> >
> > ------------------------------------------------------------------------------
> > For Developers, A Lot Can Happen In A Second.
> > Boundary is the first to Know...and Tell You.
> > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> > http://p.sf.net/sfu/Boundary-d2dvs2
> > _______________________________________________
> > Notion-general mailing list
> > Not...@li...
> > https://lists.sourceforge.net/lists/listinfo/notion-general
>
> --
> Juri Hamburg
> GnuPG Key-ID: 0x67206E72
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Notion-general mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-general
--
Juri Hamburg
GnuPG Key-ID: 0x67206E72
|
|
From: Thomas K. <tk...@gi...> - 2012-01-07 15:15:22
|
On Sat, Jan 07, 2012 at 03:14:48PM +0100, Arnout Engelen wrote: > You need to load mod_dock and mod_statusbare after loading mod_xinerama. > > (this is unfortunate. until we find a way to make this work whatever order > you choose, latest notion git gives you a warning when you load them in the > 'wrong' order) > > Does fullscreening mplayer work when mod_xinerama is loaded? Yes, it does very nice fullscreen now. When I load statusbar and dock after xinerama, I do get the wmdockapps back, but not the statusbar. Also, the statusbar was on the left monitor and on the right hand side of it were the dock apps (also on the left monitor). Now, the dock apps are on the left hand side of the right monitor and overlay the F3 (start apps) bar, which is annoying because I can't see what I type. Before, the F3-entry field was above the dock apps. When I just switched back to default config (no xinerama), the status+dockapps went over both screens; after ALT-K S it's now like before. I must have changed something during the xinerama tests. I'm a bit confused about key bindings. Before loading mod_xinerama, I had one thing (sorry, what's the proper term?) on each monitor, which I filled with an xterm each, and I could ALT-Tab between them. If I started another app, e.g. firefox, it was added to one of the two things and ALT-K N/P switched between the windows on one monitor. When loading mod_xinerama, each monitor started with two things, or a split thing, I don't know how to tell the difference, and neither ALT-Tab nor ALT-K N/P allow me to switch between them. When I start a firefox, I can ALT-K N/P to it though. I'm missing something, but what, and why the change just because of mod_xinerama? Cheers, Thomas |
|
From: Thomas K. <tk...@gi...> - 2012-04-18 23:13:01
|
On Thu, Apr 19, 2012 at 12:33:30AM +0200, Philipp Hartwig wrote:
> Wild guess: The diff indicates that the line
>
> dopath("cfg_defaults")
>
> in your cfg_notion.lua is commented IN, right?
Yes, I didn't change that part. When I added xinerama, I just looked
where it was commented out and enabled it there and then shuffled
lines around.
> What does your cfg_defaults.lua contain? Maybe an additional dopath("mod_sp")?
> This would explain the "The module is already loaded." message.
Yes.
> Also does it contain a dopath("mod_statusbar")? This would explain why the
> statusbar is missing: Unfortunately dopath("mod_statusbar") needs to be
> executed AFTER dopath("mod_xinerama"). I guess that in your case it is
> executed twice, once indirectly by dopath("cfg_defaults") and then again by
> the direct dopath("mod_statusbar"), but only the first time seems to count.
Also correct.
> Please try commenting OUT all dopaths other than dopath("cfg_defaults") in
> your cfg_notion.lua and modify cfg_defaults.lua instead, while making sure
> that dopath("mod_xinerama") occurs before dopath("mod_statusbar"). (In fact in
> the case of cfg_defaults.lua we print a warning if the order is wrong, but
> apparently not if the dopaths are done in cfg_notion.lua. :/)
>
> Does this help?
I've removed my .notion/cfg_notion.lua (so it falls back to the stock
one) and copied cfg_defaults.lua into .notion, adding the xinerama
line, and now everything works nicely.
Thank you very much! firefox flash plugin, mplayer, and geeqie all
have a useful fullscreen mode now.
One minor thing: From non-xinerama I'm used to ALT-Tab switching
between my monitors (basically, I had a big screen split vertically in
two). Is there a way to reconfigure keys so I don't need to teach my
fingers ALT-SHIFT-, and ALT-SHIFT-. and can continue using ALT-Tab
instead?
Thank you very much for your help,
Thomas
|
|
From: Juri H. <ju...@fa...> - 2012-04-19 19:24:46
|
On 04/19/12 at 09:19pm, Juri Hamburg wrote:
> On 04/19/12 at 09:14pm, Juri Hamburg wrote:
>
>
> Ugh, sorry, copied some crap over :)
>
> I ment that:
Jeez... and the functions.
function next_wrap()
scr = ioncore.goto_next_screen()
if obj_is(scr, "WRootWin") then
ioncore.goto_nth_screen(0)
end
end
function prev_wrap()
scr = ioncore.goto_prev_screen()
if obj_is(scr, "WRootWin") then
ioncore.goto_nth_screen(-1)
end
end
>
> defbindings("WScreen", {
> bdoc("Go to next/previous screen on multihead setup."),
> kpress(META.."Shift+comma", "prev_wrap()"),
> kpress(META.."Shift+period", "next_wrap()"),
> })
>
> >
> > How about this?
> >
> > defbindings("WScreen", {
> > bdoc("Move current workspace left/right."),
> > kpress(META.."Shift+comma", "WScreen.dec_index(_, _sub)", "_sub:non-nil"),
> > kpress(META.."Shift+period", "WScreen.inc_index(_, _sub)", "_sub:non-nil"),
> > })
> >
> >
> > On 04/19/12 at 07:01pm, Philipp Hartwig wrote:
> > > If you only have two screens you can also do something completely trivial like
> > > kpress(META.."Tab", "ioncore.goto_nth_screen(1-WScreen.id(_))"),
> > > in the WScreen section. Or if one has N screens, one could do
> > > kpress(META.."Tab", "ioncore.goto_nth_screen((WScreen.id(_)+1)%N)"),
> > >
> > > Or one writes a small function which saves WScreen.id(_), calls
> > > ioncore.goto_next_screen, compares the return value to the saved value and
> > > switches to the 0-th screen if the value hasn't changed. There's really an
> > > infinite number of possibilities using only Lua. :) Certainly one can also
> > > determine the N above dynamically.
> > >
> > > But the main point is that you find some way of doing this that suits your use
> > > case. :)
> > >
> > > Regards,
> > > Philipp
> > >
> > > ------------------------------------------------------------------------------
> > > For Developers, A Lot Can Happen In A Second.
> > > Boundary is the first to Know...and Tell You.
> > > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> > > http://p.sf.net/sfu/Boundary-d2dvs2
> > > _______________________________________________
> > > Notion-general mailing list
> > > Not...@li...
> > > https://lists.sourceforge.net/lists/listinfo/notion-general
> >
> > --
> > Juri Hamburg
> > GnuPG Key-ID: 0x67206E72
>
>
>
> > ------------------------------------------------------------------------------
> > For Developers, A Lot Can Happen In A Second.
> > Boundary is the first to Know...and Tell You.
> > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> > http://p.sf.net/sfu/Boundary-d2dvs2
>
> > _______________________________________________
> > Notion-general mailing list
> > Not...@li...
> > https://lists.sourceforge.net/lists/listinfo/notion-general
>
>
> --
> Juri Hamburg
> GnuPG Key-ID: 0x67206E72
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Notion-general mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-general
--
Juri Hamburg
GnuPG Key-ID: 0x67206E72
|
|
From: Arnout E. <no...@bz...> - 2012-01-08 23:11:31
|
On Sat, Jan 07, 2012 at 04:15:12PM +0100, Thomas Klausner wrote: > On Sat, Jan 07, 2012 at 03:14:48PM +0100, Arnout Engelen wrote: > > You need to load mod_dock and mod_statusbare after loading mod_xinerama. > > > > (this is unfortunate. until we find a way to make this work whatever order > > you choose, latest notion git gives you a warning when you load them in the > > 'wrong' order) > > > > Does fullscreening mplayer work when mod_xinerama is loaded? > > Yes, it does very nice fullscreen now. > When I load statusbar and dock after xinerama, I do get the wmdockapps back, but not the statusbar. > Also, the statusbar was on the left monitor and on the right hand side of it were the dock apps (also on the left monitor). > Now, the dock apps are on the left hand side of the right monitor and overlay the F3 (start apps) bar, which is annoying because I can't see what I type. > Before, the F3-entry field was above the dock apps. Hmm, I'd need to look into this further. (might have something to do with floating vs embedded docks, we need to document all that better because I keep getting confused myself too :) ) > When I just switched back to default config (no xinerama), the status+dockapps went over both screens; after ALT-K S it's now like before. I must have changed something during the xinerama tests. > > I'm a bit confused about key bindings. > Before loading mod_xinerama, I had one thing (sorry, what's the proper > term?) on each monitor, which I filled with an xterm each, and I could > ALT-Tab between them. I think you mean 'frame' by 'thing' - perhaps review the manpage or the 'tour' ( https://sourceforge.net/apps/mediawiki/notion/index.php?title=Tour ) > If I started another app, e.g. firefox, it was added to one of the two > things and ALT-K N/P switched between the windows on one monitor. > > When loading mod_xinerama, each monitor started with two things, or a split > thing, I don't know how to tell the difference, and neither ALT-Tab nor > ALT-K N/P allow me to switch between them. I'm sorry, but do you mean you cannot switch between the 2 empty frames on one monitor, or that you cannot switch from a frame on one monitor to a frame on another monitor? Without mod_xinerama you have 1 big workspace which you can split into frames. With mod_xinerama, you have 2 workspaces (1 for each monitor), which you can also split into frames. One big difference between 1 big workspace with 2 frames and 2 workspaces with 1 frame each, is that you can resize the frames in the former case but you cannot resize the workspaces in the latter case. I hope I'm making any sense :). Kind regards, Arnout |
|
From: Philipp H. <ph...@ph...> - 2012-04-19 13:02:17
|
On Thu, Apr 19, 2012 at 01:12:51AM +0200, Thomas Klausner wrote: > I've removed my .notion/cfg_notion.lua (so it falls back to the stock > one) and copied cfg_defaults.lua into .notion, adding the xinerama > line, and now everything works nicely. Great. Maybe we should change the default cfg_notion.lua and remove all the dopaths other than the one to cfg_default.lua, while mentioning in a comment that this is the file to modify if one wants change which modules are loaded. > One minor thing: From non-xinerama I'm used to ALT-Tab switching between > my monitors (basically, I had a big screen split vertically in two). Is > there a way to reconfigure keys so I don't need to teach my fingers > ALT-SHIFT-, and ALT-SHIFT-. and can continue using ALT-Tab instead? Sounds like the xinerama_switcher script from the scripts collection[1] (also shipped with Notion in the contrib/scripts folder) does what you want. I haven't tried it though. Cheers, Philipp http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/contrib;a=blob_plain;f=index_git.html;hb=HEAD |
|
From: Philipp H. <ph...@ph...> - 2012-04-20 20:51:19
|
Hi Juri, thanks for the suggestion, they've worked well. But in fact we have changed a lot of the Xinerama logic today and now everything should just work out of the box: - Wrapping should work by default without any Lua helpers. - Fullscreen works because the patch has landed. - It is not important anymore whether mod_xinerama is loaded before or after mod_statusbar. - The internal logic was fixed in that we do no longer have an WMPlex that manages multiple screens, which contradicts the definition of an WMPlex. - As a result screens can now be resized. - And probably a lot more. This should greatly improve the overall Xinerama experience, please give it a try. Cheers, Philipp |
|
From: Thomas K. <tk...@gi...> - 2012-04-23 21:40:26
|
Hi Philipp! > But in fact we have changed a lot of the Xinerama logic today and now > everything should just work out of the box: > > - Wrapping should work by default without any Lua helpers. > - Fullscreen works because the patch has landed. > - It is not important anymore whether mod_xinerama is loaded before or after > mod_statusbar. > - The internal logic was fixed in that we do no longer have an WMPlex that > manages multiple screens, which contradicts the definition of an WMPlex. > - As a result screens can now be resized. > - And probably a lot more. > > This should greatly improve the overall Xinerama experience, please give it a > try. The features I tried work better now. Thank you! Thomas |
|
From: Thomas K. <tk...@gi...> - 2012-01-15 17:17:05
|
On Mon, Jan 09, 2012 at 12:11:21AM +0100, Arnout Engelen wrote: > > When I load statusbar and dock after xinerama, I do get the wmdockapps back, but not the statusbar. > > Also, the statusbar was on the left monitor and on the right hand side of it were the dock apps (also on the left monitor). > > Now, the dock apps are on the left hand side of the right monitor and overlay the F3 (start apps) bar, which is annoying because I can't see what I type. > > Before, the F3-entry field was above the dock apps. > > Hmm, I'd need to look into this further. (might have something to do with floating vs > embedded docks, we need to document all that better because I keep getting confused > myself too :) ) Please do that. It's what keeping me from switching to xinerama. I found out part of the issue in the meantime -- it seems the right monitor is workspace-set 1 and the left one is workspace-set 2. xrandr --output DVI-0 --mode 1920x1200 --left-of DVI-1 I probably should just switch the signals around to solve this. That explains why the wmdockapps are on the right screen now, but why are the wmdockapps not reducing the size of the windows? And where is the statusbar? > I think you mean 'frame' by 'thing' - perhaps review the manpage or the 'tour' > ( https://sourceforge.net/apps/mediawiki/notion/index.php?title=Tour ) With default setup, there seems to be one workspace on both screens. F9 creates another workspace, and I can switch with ALT-, or ALT- between them (or ALT-1/2/...). With ALT-Tab I can switch around the frames on one monitor. The URL you cite says: "When you have a multiple-monitor setup, you should be using mod_xinerama, which makes sure there's a set of workspaces on each monitor, instead of one set of workspaces spanning all monitors." So now I had to learn ALT-Shift-, and ALT-Shift-1 to switch between the monitor sets of workspaces. I'm not sure I get the point of having multiple sets of workspaces, one per monitor. How are people using this? One other issue: mplayer full screen now takes one full monitor, not split over two like without xinerama. However, geeqie fullscreen doesn't work. It did the same without xinerama like mplayer, but now it doesn't show its fullscreen window. I think geeqie full screen works like this: usually, the picture is on the right hand side. When you press f, a separate screenfilling window is added with the picture, but the original menu window stays (without the picture) -- you can alt-tab out of full screen to it. However, I only get the menu window, not the fullscreen picture one. Cheers, Thomas |
|
From: Thomas K. <tk...@gi...> - 2012-04-19 13:34:26
|
On Thu, Apr 19, 2012 at 03:02:07PM +0200, Philipp Hartwig wrote:
> Great. Maybe we should change the default cfg_notion.lua and remove all the
> dopaths other than the one to cfg_default.lua, while mentioning in a comment
> that this is the file to modify if one wants change which modules are loaded.
Please do that.
> Sounds like the xinerama_switcher script from the scripts collection[1] (also
> shipped with Notion in the contrib/scripts folder) does what you want. I
> haven't tried it though.
Hm, doesn't look like it, or I don't know how to use it.
I trued something else in my .notion/cfg_defaults.lua:
defbindings("WFrame", {
bdoc("Go to next screen on multihead setup."),
kpress(META.."Tab", "ioncore.goto_next_screen()"),
})
(also with WScreen instead of WFrame) but it didn't work. What did I do wrong there?
Thanks,
Thomas
|
|
From: Thomas K. <tk...@gi...> - 2012-04-19 13:39:36
|
On Thu, Apr 19, 2012 at 03:34:16PM +0200, Thomas Klausner wrote:
> I tried something else in my .notion/cfg_defaults.lua:
>
> defbindings("WFrame", {
> bdoc("Go to next screen on multihead setup."),
> kpress(META.."Tab", "ioncore.goto_next_screen()"),
> })
>
> (also with WScreen instead of WFrame) but it didn't work. What did I do wrong there?
Actually, it does work, but only once -- it doesn't cycle around.
So ALT-Tab from screen one goes to screen two, but on screen two it does nothing.
Is there a function that cycles or a way to write it?
Thomas
|
|
From: <eb...@dr...> - 2012-01-15 19:52:09
Attachments:
signature.asc
|
> One other issue: mplayer full screen now takes one full monitor, not
> split over two like without xinerama. However, geeqie fullscreen
> doesn't work. It did the same without xinerama like mplayer, but now
> it doesn't show its fullscreen window. I think geeqie full screen
> works like this: usually, the picture is on the right hand side. When
> you press f, a separate screenfilling window is added with the
> picture, but the original menu window stays (without the picture) --
> you can alt-tab out of full screen to it. However, I only get the
> menu window, not the fullscreen picture one.
>
> Cheers,
> Thomas
I think that it depends on application to which 'window' (global root
or monitor root) it attaches its fullscreen mode. If you press META +
"Return", then WGroup.set_fullscreen() is launched. This function
either leaves fullscreen from the windowmanager point of view or it
enters the fullscreen mode back. This function always attaches window
to a monitor root. Maybe we can include similar function in
mod_xinerama, that always attaches a window to global root, so users
can choose to which root the fullscreen will be attached, as both ways
make sense.
--
Tomáš 'ebík' Ebenlendr
PF 2012.0405822455
|
|
From: Philipp H. <ph...@ph...> - 2012-04-19 13:54:06
|
On Thu, Apr 19, 2012 at 03:34:17PM +0200, Thomas Klausner wrote:
> Hm, doesn't look like it, or I don't know how to use it.
Hm, yeah, looks like it can't do wrapping.
> I trued something else in my .notion/cfg_defaults.lua:
>
> defbindings("WFrame", {
> bdoc("Go to next screen on multihead setup."),
> kpress(META.."Tab", "ioncore.goto_next_screen()"),
> })
>
> (also with WScreen instead of WFrame) but it didn't work. What did I do wrong there?
Meta-Tab is used for switching between frames by default and is defined in
cfg_tiling. This file is usually loaded after cfg_notioncore so that it will
overwrite your binding. If you don't care about switching between frames, you
can remove the corresponding line in cfg_tiling and then it should work if
you replace WFrame by WScreen in the quote above (actually it's easiest if you
just change the existing binding for ioncore.goto_next_screen() in the
existing WScreen section in cfg_notioncore).
Okay, now I've just read your second mail. What happens with the default
bindings, i.e. if you press Mod-Shift-. twice in a row? If that doesn't work
either then a little bit of Lua foo might be necessary. I don't have second
screen available at the moment so I can't look into this.
|
|
From: <eb...@dr...> - 2012-01-15 19:52:57
Attachments:
signature.asc
|
>
> I found out part of the issue in the meantime -- it seems the right
> monitor is workspace-set 1 and the left one is workspace-set 2.
> xrandr --output DVI-0 --mode 1920x1200 --left-of DVI-1 I probably
> should just switch the signals around to solve this.
>
Maybe you can try this, to set DVI-1 to be the first monitor.
xrandr --output DVI-1 --primary
--
Tomáš 'ebík' Ebenlendr
PF 2012.04057427646
|
|
From: Thomas K. <tk...@gi...> - 2012-01-15 22:40:58
|
On Sun, Jan 15, 2012 at 08:26:57PM +0100, eb...@dr... wrote: > > > > I found out part of the issue in the meantime -- it seems the right > > monitor is workspace-set 1 and the left one is workspace-set 2. > > xrandr --output DVI-0 --mode 1920x1200 --left-of DVI-1 I probably > > should just switch the signals around to solve this. > > > > Maybe you can try this, to set DVI-1 to be the first monitor. > > xrandr --output DVI-1 --primary Yes, this works! (I want DVI-0 to be the primary, but that's a simple change) Thank you! Thomas |
|
From: Thomas K. <tk...@gi...> - 2012-01-15 22:44:43
|
On Sun, Jan 15, 2012 at 08:51:56PM +0100, eb...@dr... wrote: > > One other issue: mplayer full screen now takes one full monitor, not > > split over two like without xinerama. However, geeqie fullscreen > > doesn't work. It did the same without xinerama like mplayer, but now > > it doesn't show its fullscreen window. I think geeqie full screen > > works like this: usually, the picture is on the right hand side. When > > you press f, a separate screenfilling window is added with the > > picture, but the original menu window stays (without the picture) -- > > you can alt-tab out of full screen to it. However, I only get the > > menu window, not the fullscreen picture one. > > I think that it depends on application to which 'window' (global root > or monitor root) it attaches its fullscreen mode. If you press META + > "Return", then WGroup.set_fullscreen() is launched. This function > either leaves fullscreen from the windowmanager point of view or it > enters the fullscreen mode back. This function always attaches window > to a monitor root. Maybe we can include similar function in > mod_xinerama, that always attaches a window to global root, so users > can choose to which root the fullscreen will be attached, as both ways > make sense. I tried out META+Return, as you suggest. The first time I press that, I get another tabbed window containing the picture (which should be full-screen). The second time I press that, I get the full-screen window in full-screen, yay :) The third time is like the first and so on. What can I do to make this happen automatically for geeqie without having to press META+Return twice? (Btw, the dock apps are on top of the fullscreen window) Thomas |
|
From: Thomas K. <tk...@gi...> - 2012-04-19 15:58:49
Attachments:
patch-ioncore_screen.c
|
On Thu, Apr 19, 2012 at 03:53:55PM +0200, Philipp Hartwig wrote: > Okay, now I've just read your second mail. What happens with the default > bindings, i.e. if you press Mod-Shift-. twice in a row? If that doesn't work > either then a little bit of Lua foo might be necessary. I don't have second > screen available at the moment so I can't look into this. Doesn't work either. I've come up with the attached patch which makes going forward cycle around. I don't know how to get the number of screens, so I didn't change the codepath for going backwards. Perhaps it helps someone else :) Thomas |
|
From: Philipp H. <ph...@ph...> - 2012-04-16 16:15:34
Attachments:
use_screen_2.diff
|
Hi, On Sun, Jan 15, 2012 at 11:44:36PM +0100, Thomas Klausner wrote: > On Sun, Jan 15, 2012 at 08:51:56PM +0100, eb...@dr... wrote: > > > One other issue: mplayer full screen now takes one full monitor, not > > > split over two like without xinerama. However, geeqie fullscreen > > > doesn't work. It did the same without xinerama like mplayer, but now > > > it doesn't show its fullscreen window. I think geeqie full screen > > > works like this: usually, the picture is on the right hand side. When > > > you press f, a separate screenfilling window is added with the > > > picture, but the original menu window stays (without the picture) -- > > > you can alt-tab out of full screen to it. However, I only get the > > > menu window, not the fullscreen picture one. > > > > I think that it depends on application to which 'window' (global root > > or monitor root) it attaches its fullscreen mode. If you press META + > > "Return", then WGroup.set_fullscreen() is launched. This function > > either leaves fullscreen from the windowmanager point of view or it > > enters the fullscreen mode back. This function always attaches window > > to a monitor root. Maybe we can include similar function in > > mod_xinerama, that always attaches a window to global root, so users > > can choose to which root the fullscreen will be attached, as both ways > > make sense. > > I tried out META+Return, as you suggest. > The first time I press that, I get another tabbed window containing the > picture (which should be full-screen). > The second time I press that, I get the full-screen window in full-screen, > yay :) > The third time is like the first and so on. > What can I do to make this happen automatically for geeqie without having to > press META+Return twice? I haven't tried geeqie, but this sounds exactly like the behavior Flash fullscreen shows when mod_xinerama is enabled. This should be fixed by the patch I've sent to notion-devel yesterday. I've attached it again for your convenience. Could you test if that fixes geeqie for you? Regards, Philipp |
|
From: Philipp H. <ph...@ph...> - 2012-04-19 17:01:29
|
If you only have two screens you can also do something completely trivial like kpress(META.."Tab", "ioncore.goto_nth_screen(1-WScreen.id(_))"), in the WScreen section. Or if one has N screens, one could do kpress(META.."Tab", "ioncore.goto_nth_screen((WScreen.id(_)+1)%N)"), Or one writes a small function which saves WScreen.id(_), calls ioncore.goto_next_screen, compares the return value to the saved value and switches to the 0-th screen if the value hasn't changed. There's really an infinite number of possibilities using only Lua. :) Certainly one can also determine the N above dynamically. But the main point is that you find some way of doing this that suits your use case. :) Regards, Philipp |
|
From: Thomas K. <tk...@gi...> - 2012-04-18 21:26:32
|
Hi Philipp!
On Mon, Apr 16, 2012 at 06:15:22PM +0200, Philipp Hartwig wrote:
> On Sun, Jan 15, 2012 at 11:44:36PM +0100, Thomas Klausner wrote:
> > On Sun, Jan 15, 2012 at 08:51:56PM +0100, eb...@dr... wrote:
> > > > One other issue: mplayer full screen now takes one full monitor, not
> > > > split over two like without xinerama. However, geeqie fullscreen
> > > > doesn't work. It did the same without xinerama like mplayer, but now
> > > > it doesn't show its fullscreen window. I think geeqie full screen
> > > > works like this: usually, the picture is on the right hand side. When
> > > > you press f, a separate screenfilling window is added with the
> > > > picture, but the original menu window stays (without the picture) --
> > > > you can alt-tab out of full screen to it. However, I only get the
> > > > menu window, not the fullscreen picture one.
> > >
> > > I think that it depends on application to which 'window' (global root
> > > or monitor root) it attaches its fullscreen mode. If you press META +
> > > "Return", then WGroup.set_fullscreen() is launched. This function
> > > either leaves fullscreen from the windowmanager point of view or it
> > > enters the fullscreen mode back. This function always attaches window
> > > to a monitor root. Maybe we can include similar function in
> > > mod_xinerama, that always attaches a window to global root, so users
> > > can choose to which root the fullscreen will be attached, as both ways
> > > make sense.
> >
> > I tried out META+Return, as you suggest.
> > The first time I press that, I get another tabbed window containing the
> > picture (which should be full-screen).
> > The second time I press that, I get the full-screen window in full-screen,
> > yay :)
> > The third time is like the first and so on.
> > What can I do to make this happen automatically for geeqie without having to
> > press META+Return twice?
>
> I haven't tried geeqie, but this sounds exactly like the behavior Flash
> fullscreen shows when mod_xinerama is enabled. This should be fixed by the
> patch I've sent to notion-devel yesterday. I've attached it again for your
> convenience. Could you test if that fixes geeqie for you?
Yes, this improves the situation. Thank you!
One difference: The dock apps are on top in full screen mode for
geeqie and firefox flash plugin, but not on top of mplayer full
screen.
General xinerama complaint remains ;)
I still don't know why the dock icons do not reduce the size of the
other windows (like without xinerama) -- they even are on the top of
the edit bar you get with F3 or F4. Also, the status bar doesn't
appear.
Here's the diff for the config I use to the default:
--- /usr/pkg/etc/notion/cfg_notion.lua 2012-04-18 22:58:23.000000000 +0200
+++ .notion/cfg_notion.lua 2012-01-15 18:17:36.000000000 +0100
@@ -75,12 +75,12 @@
-- Load some modules. Bindings and other configuration specific to modules
-- are in the files cfg_modulename.lua.
---dopath("mod_query")
---dopath("mod_menu")
---dopath("mod_tiling")
---dopath("mod_statusbar")
---dopath("mod_dock")
---dopath("mod_sp")
+dopath("mod_xinerama")
+dopath("mod_query")
+dopath("mod_menu")
+dopath("mod_tiling")
+dopath("mod_statusbar")
+dopath("mod_dock")
In case you're wondering about mod_sp, if I leave that in I get:
Notion startup error log:
>> /usr/pkg/lib/notion/mod/mod_sp.so: The module is already loaded.
>> Unable to find 'mod_sp.so' on search path.
>> Stack trace:
0 [C]: in 'load_module'
1 stdin:1
[Skipping unnamed C functions.]
4 [C]: in 'dopath'
5 /home/wiz/.notion/cfg_notion.lua:84
[Skipping unnamed C functions.]
Cheers,
Thomas
|
|
From: Juri H. <ju...@fa...> - 2012-04-19 19:15:08
|
How about this?
defbindings("WScreen", {
bdoc("Move current workspace left/right."),
kpress(META.."Shift+comma", "WScreen.dec_index(_, _sub)", "_sub:non-nil"),
kpress(META.."Shift+period", "WScreen.inc_index(_, _sub)", "_sub:non-nil"),
})
On 04/19/12 at 07:01pm, Philipp Hartwig wrote:
> If you only have two screens you can also do something completely trivial like
> kpress(META.."Tab", "ioncore.goto_nth_screen(1-WScreen.id(_))"),
> in the WScreen section. Or if one has N screens, one could do
> kpress(META.."Tab", "ioncore.goto_nth_screen((WScreen.id(_)+1)%N)"),
>
> Or one writes a small function which saves WScreen.id(_), calls
> ioncore.goto_next_screen, compares the return value to the saved value and
> switches to the 0-th screen if the value hasn't changed. There's really an
> infinite number of possibilities using only Lua. :) Certainly one can also
> determine the N above dynamically.
>
> But the main point is that you find some way of doing this that suits your use
> case. :)
>
> Regards,
> Philipp
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Notion-general mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-general
--
Juri Hamburg
GnuPG Key-ID: 0x67206E72
|
×
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