notion-general — General discussion about the notion window manager

Re: [Notion-general] xinerama vs dock

[Juri H. <ju...@fa...>]

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

Re: [Notion-general] xinerama vs dock

[Juri H. <ju...@fa...>]

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

Re: [Notion-general] xinerama vs dock

[Juri H. <ju...@fa...>]

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

Re: [Notion-general] xinerama vs dock

[Philipp H. <ph...@ph...>]

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

Re: [Notion-general] xinerama vs dock

[Thomas K. <tk...@gi...>]

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

Re: [Notion-general] xinerama vs dock

[Philipp H. <ph...@ph...>]

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.

Re: [Notion-general] xinerama vs dock

[Thomas K. <tk...@gi...>]

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

Re: [Notion-general] xinerama vs dock

[Thomas K. <tk...@gi...>]

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

Re: [Notion-general] xinerama vs dock

[Philipp H. <ph...@ph...>]

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

Re: [Notion-general] xinerama vs dock

[Thomas K. <tk...@gi...>]

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

Re: [Notion-general] xinerama vs dock

[Philipp H. <ph...@ph...>]

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

Re: [Notion-general] xinerama vs dock

[Thomas K. <tk...@gi...>]

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

[Notion-general] gentoo portage overlay

[Morten G. B. <mor...@gm...>]

Hey all,

First of all I want to thank the devs who brought notION back to an active
project.

Second I have made a overlay for the gentoo portage system

https://github.com/bgm/overlay

Its taking the source directly from git and is supporting xinerama xrandr
and xkbevents via useflags.

I am not on this list, so if you need to get in contact with me, do it
directly

Regards
/Morten

Re: [Notion-general] Problem with mod_sp and keybindings

[Juri H. <ju...@fa...>]

On 04/16/12 at 08:50pm, Philipp Hartwig wrote:
> Hi,
> 
> On Thu, Mar 29, 2012 at 09:12:03PM +0100, Max maria Wacholder wrote:
> > I recently began to use the min_tabs-script that removes tabs in any frame
> > that contains exactly one client. Suddenly, my scratchpad no longer works,
> > whether or not I actually load the min_tabs-script.
> 
> very odd. The only explanation I can think of spontaneously is that the script 
> introduced an unfit geometry for the scratchpad and that this geometry was 
> saved along with the rest of the layout. Try searching for "scratchpad" in 
> your .notion/default-session--0/saved_layout.lua . What geometry information 
> do you see in the corresponding section? You can also try to just temporarily 
> move this file out of the way and then restart Notion.

Hey there!

Try to execute 'ioncore.lookup_region("*scratchws*"):rqclose(true)' in
your lua run dialog. After that press your toggle scratchpad key
combination. That way you won't need to play around with layout
files.

If you have a second screen and scratchpad vanishes, the region might be
"*scratchws*<2>".

I use it as workaround atm. Still can't find out under which
circumstances the scratchpad gets broken.

Regards,
Juri

> 
> 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

Re: [Notion-general] Problem with mod_sp and keybindings

[Philipp H. <ph...@ph...>]

Hi,

On Thu, Mar 29, 2012 at 09:12:03PM +0100, Max maria Wacholder wrote:
> I recently began to use the min_tabs-script that removes tabs in any frame
> that contains exactly one client. Suddenly, my scratchpad no longer works,
> whether or not I actually load the min_tabs-script.

very odd. The only explanation I can think of spontaneously is that the script 
introduced an unfit geometry for the scratchpad and that this geometry was 
saved along with the rest of the layout. Try searching for "scratchpad" in 
your .notion/default-session--0/saved_layout.lua . What geometry information 
do you see in the corresponding section? You can also try to just temporarily 
move this file out of the way and then restart Notion.

Regards,
Philipp

Re: [Notion-general] xinerama vs dock

[Philipp H. <ph...@ph...>]

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

Re: [Notion-general] scratchpad off-center

[Wojciech A. <pen...@gm...>]

Thanks Philipp. Moving sessions didn't help, but resizing did. I feel stupid, I guess I should just RTFM. But somehow - and I've been using notion (prev. ion3) since 2009 - I never knew I could resize/move the scratchpad ;/

Thanks again
regards
wojtek


On  nie 15.04.2012 10:40, Philipp Hartwig wrote:
> Hi,
> 
> > after some turbulent recent debian update (I am on Testing), my notion
> > started to behave oddly. I upgraded to 20120409 snapshot, but to no
> > avail. The problem is that the scratchpad is displayed in bottom-right, not
> > in the center of the screen. Any ideas why that may occur? I am currently
> > digging into sources of mod_sp (like par.geom.y=(fp->g.h-par.geom.h)/2;)
> > seems to be describing the position, but the reason has got to be external,
> > no code has changed.  So, what am I missing?
> 
> it seems unlikely that this was caused by upgrading Debian (I'm also running a 
> fully upgraded testing). Are you aware that the geometry of the scratchpad is 
> saved with the rest of the layout? What happens if you temporarily move 
> .notion/default-session--0/saved_layout.lua out of the way and restart Notion? 
> What happens if you move the scratchpad back to the center (this can be done 
> using the move/resize bindings) and then save the layout?
> 
> Regards,
> Philipp

-- 
Pentahedron - A polyhedron having five faces. Because there are two pentahedral graphs, there are two convex pentahedra, namely the square pyramid and the triangular prism. The triangular prism is the unique convex pentahedra having unit edge lengths.

(Eric W. Weisstein. "Pentahedron." From MathWorld--A Wolfram Web Resource. http://mathworld.wolfram.com/Pentahedron.html)

Re: [Notion-general] scratchpad off-center

[Philipp H. <ph...@ph...>]

Hi,

> after some turbulent recent debian update (I am on Testing), my notion
> started to behave oddly. I upgraded to 20120409 snapshot, but to no
> avail. The problem is that the scratchpad is displayed in bottom-right, not
> in the center of the screen. Any ideas why that may occur? I am currently
> digging into sources of mod_sp (like par.geom.y=(fp->g.h-par.geom.h)/2;)
> seems to be describing the position, but the reason has got to be external,
> no code has changed.  So, what am I missing?

it seems unlikely that this was caused by upgrading Debian (I'm also running a 
fully upgraded testing). Are you aware that the geometry of the scratchpad is 
saved with the rest of the layout? What happens if you temporarily move 
.notion/default-session--0/saved_layout.lua out of the way and restart Notion? 
What happens if you move the scratchpad back to the center (this can be done 
using the move/resize bindings) and then save the layout?

Regards,
Philipp

[Notion-general] scratchpad off-center

[Wojtek A. <pen...@gm...>]

Hi there.

 after some turbulent recent debian update (I am on Testing), my notion
started to behave oddly. I upgraded to 20120409 snapshot, but to no
avail. The problem is that the scratchpad is displayed in bottom-right,
not in the center of the screen. Any ideas why that may occur? I am
currently digging into sources of mod_sp (like
par.geom.y=(fp->g.h-par.geom.h)/2;) seems to be describing the position,
but the reason has got to be external, no code has changed.
So, what am I missing?


regards
wojtek

-- 
Pentahedron - A polyhedron having five faces. Because there are two
pentahedral graphs, there are two convex pentahedra, namely the square
pyramid and the triangular prism. The triangular prism is the unique
convex pentahedra having unit edge lengths.

(Eric W. Weisstein. "Pentahedron." From MathWorld--A Wolfram Web
Resource. http://mathworld.wolfram.com/Pentahedron.html)

Re: [Notion-general] Horizontal/vertical maximization

[Philipp H. <ph...@ph...>]

I've opened a ticket[1] for this and posted the patch I've come up with. A
non-fullsized statusbar gave me a headache but I think I've found my way
around it now. Any testing and feedback would be greatly appreciated.

Regards,
Philipp

[1] http://sourceforge.net/tracker/?func=detail&aid=3514271&group_id=314802&atid=1324528

Re: [Notion-general] Quickly jumping to specific windows

[Arnout E. <no...@bz...>]

On Fri, Jan 13, 2012 at 10:38:14PM +0100, Philipp Hartwig wrote:
> On Fri, Jan 13, 2012 at 09:36:59PM +0100, Arnout Engelen wrote:
> > Yeah. I like how i3 has a screencast showing its capabilities, which is really
> > nice (though that has its downsides too: harder to create, harder to maintain,
> > and I'm confident nobody will want to listen to my awful accent :).
> 
> The overall i3 documentation is excellent. Just looking at the user's guide 
> makes one feel right at home before even running it for the first time. We 
> should think about expanding our Tour as well, the gap between the Tour and 
> "Configuring and extending Notion with Lua" is way too big.

Hi all,

Philipp has rewritten/improved most of the Tour, it is much more gentle now.

I think we should give him write access to our wiki. Any objections?


Kind regards,

Arnout

[Notion-general] Problem with mod_sp and keybindings

[Max m. W. <dra...@ya...>]

Hi,

I recently began to use the min_tabs-script that removes tabs in any frame that contains exactly one client. Suddenly, my scratchpad no longer works, whether or not I actually load the min_tabs-script.

There is a default keybinding in /usr/local/etc/notion/cfg_sp.lua:

defbindings("WScreen", {
    bdoc("Toggle scratchpad."),
    kpress(META.."space", "mod_sp.set_shown_on(_, 'toggle')"),
    
-- [ some comments ]


})


I verified that the file is being loaded by introducing an error deliberately, which caused notion to raise an error dialog. I also copied the binding to my ~/.notion/cfg_keybindings.lua and tried different key combinations, such as
META.."x", to make sure that the binding itself isn't at fault. Further, using the lua console I can create a scratchpad by typing

mod_sp.set_shown_on(_,'toggle')

but this creates a scratchpad in the current mplex, which then grabs the focus, and if I then try to toggle the scratchpad away again, another scratchpad is opened within the existing scratchpad. This looks funny, but is not what I want.

Also, within a MPlex context, scratchpad creation works on a per-mplex-basis (but then causes the problem I described above with the recursive scratchpad creation):

 defbindings("WMPlex", {
         bdoc("Toggle scratchpad."),
         kpress(META.."x", "mod_sp.set_shown_on(_, 'toggle')"),                                                                                                                                                                                                                                                         
  -- this works
                


Can anyone give me a hint as to what is going on or how I can diagnose the error?



Regards,
Drachenfutter

Re: [Notion-general] "Delete" key bindings

[Ranousse <ran...@gm...>]

> > So here's my question: is there a way to remove some keys or
> > should I continue to use the old method for this?
 
> Does something like kpress("F3", nil) achieve what you want?


Yes it does! Thank you very much.

Re: [Notion-general] "Delete" key bindings

[Philipp H. <ph...@ph...>]

On Sat, Feb 25, 2012 at 04:33:28PM +0100, Ranousse wrote:
> So here's my question: is there a way to remove some keys or
> should I continue to use the old method for this?

Does something like kpress("F3", nil) achieve what you want?

Regards,
Philipp

[Notion-general] Horizontal/vertical maximization

[Philipp H. <ph...@ph...>]

Hi all,

I've never been really happy with the way vertical/horizontal maximization 
works in in Notion. The most annoying behavior for me is the following.
Start with a workspace with two horizontal splits:

-------
|1|2|3|
-------

Focus frame 3 and toggle horizontal maximization twice. I would expect the 
layout to be restored, but instead one gets the following result with frame 1 
shrunk to zero width:

-------
| 2 |3|
-------

I've spent some time understanding this and I've come up with a different 
approach which will always restore the layout as expected. I'm currently 
testing these changes.

My question is whether there are other things that annoy you about the current 
behavior of vertical/horizontal maximization. I would then try to address them 
while I'm at it.

Regards,
Philipp