Menu
▾
▴
notion-general
|
From: David G. <dg...@co...> - 2011-10-20 12:15:10
Attachments:
signature.asc
|
I would like to use Notion with Gnome. (Don't laugh, okay?) (And right now this is all in floating mode.) Currently, it *works*, but Notion doesn't appear to understand panels, and they're appearing as ordinary windows. Is there any way to persuade notion to handle docked windows in a more, ah, traditional way? While I can force them into frames manually, it'd be very much easier (and more user friendly) to have it all Just Work, and then have notion manage the space between the panels. I have tried mod_dock, but it doesn't appear to do what I want. I've observed this with both Gnome panels and gkrellm in docked mode. (Incidentally, notion is also not honouring gkrellm's request for no window manager decoration.) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ "I have always wished for my computer to be as easy to use as my │ telephone; my wish has come true because I can no longer figure out │ how to use my telephone." --- Bjarne Stroustrup |
|
From: Arnout E. <no...@bz...> - 2011-10-20 12:49:53
|
On Thu, Oct 20, 2011 at 01:14:49PM +0100, David Given wrote: > I would like to use Notion with Gnome. (Don't laugh, okay?) (And right > now this is all in floating mode.) How do you create a floating workspace? This appears to have become an undocumented feature. I think we should document it :). > Currently, it *works*, but Notion doesn't appear to understand panels, and > they're appearing as ordinary windows. I'm using gnome-panel, too (just 1 though). > Is there any way to persuade notion to handle docked windows in a more, > ah, traditional way? While I can force them into frames manually, it'd > be very much easier (and more user friendly) to have it all Just Work, > and then have notion manage the space between the panels. I have tried > mod_dock, but it doesn't appear to do what I want. For me, in a normal tiled workspace, loading mod_dock causes gnome-panel to open as a proper 'panel' instead of as a normal window. I did have to set the dock mode to 'embedded' to prevent the panel from overlapping normal frames. Also, I have to load mod_dock after mod_xinerama. I'm not sure how this works in floating workspaces. (gkrellm in mode also 'kinda sorta' works, but not really usably imho) > I've observed this with both Gnome panels and gkrellm in docked mode. > (Incidentally, notion is also not honouring gkrellm's request for no > window manager decoration.) For a tiling workspace, i think it makes sense to ignore this request. For a floating one, it'd make sense to honour it indeed. Could you submit a feature request for this? Kind regards, Arnout |
|
From: David G. <dg...@co...> - 2011-10-20 14:45:41
Attachments:
signature.asc
|
Arnout Engelen wrote:
> On Thu, Oct 20, 2011 at 01:14:49PM +0100, David Given wrote:
>> I would like to use Notion with Gnome. (Don't laugh, okay?) (And right
>> now this is all in floating mode.)
>
> How do you create a floating workspace? This appears to have become an
> undocumented feature. I think we should document it :).
Er... I think I just closed all frames and it Just Happened. I know it's
possible, I did it back in the Before Time, but haven't done it
recently. (Currently I have a bunch of defwinprop { float = true } to
float windows over the frames.)
Anyway, slight background: what I want to do is to configure Notion to
be, by default, a floating window manager, and then add frames for
specific windows only. There's too much stuff these days that doesn't
get on well with frames. The amount of time I've spent trying to figure
out why my wireless wasn't working, because the 'Enter Wireless Key'
dialogue had appeared squashed into the tiny frame containing
stalonetray and I hadn't seen it, isn't funny.
[...]
> For me, in a normal tiled workspace, loading mod_dock causes gnome-panel
> to open as a proper 'panel' instead of as a normal window.
This is with Gnome 3 in fallback mode, which creates panels top and
bottom (and then I have gkrellm off to the right). I did spend some time
fiddling with mod_dock but there's no documentation for that either. I
think I did manage to get it to swallow a panel once but it then
expanded to fill 2/3 of the screen...
[...]
> For a tiling workspace, i think it makes sense to ignore this request. For a
> floating one, it'd make sense to honour it indeed. Could you submit a feature
> request for this?
Where's good? (I'm also wondering whether the defwinprop stuff is
flexible enough to support this without needing any core changes.)
Also: nautilus tried to claim the root window and I ended up with a
gigantic floating window. A floating workspace is about the only time
when a root window is relevant in Notion, so I'm not surprised it's not
supported. Would this be easy to change?
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup
|
|
From: Arnout E. <no...@bz...> - 2011-10-20 16:01:53
|
On Thu, Oct 20, 2011 at 03:45:20PM +0100, David Given wrote: > Arnout Engelen wrote: > > On Thu, Oct 20, 2011 at 01:14:49PM +0100, David Given wrote: > >> I would like to use Notion with Gnome. (Don't laugh, okay?) (And right > >> now this is all in floating mode.) > > > > How do you create a floating workspace? This appears to have become an > > undocumented feature. I think we should document it :). > > Er... I think I just closed all frames and it Just Happened. I know it's > possible, I did it back in the Before Time, but haven't done it > recently. In the old days F9 asked for the workspace type. Since some time before http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=3d38954deab0146e60f7f30ff44f0684b77c7500 you could use the context command new-empty-workspace instead. That appears to have disappeared, too, though. Not sure what the proper way is now. Anyone? > (Currently I have a bunch of defwinprop { float = true } to > float windows over the frames.) You don't need that when you're using a WFloatWS though do you? > Anyway, slight background: what I want to do is to configure Notion to > be, by default, a floating window manager, and then add frames for > specific windows only. Interesting > There's too much stuff these days that doesn't > get on well with frames. The amount of time I've spent trying to figure > out why my wireless wasn't working, because the 'Enter Wireless Key' > dialogue had appeared squashed into the tiny frame containing > stalonetray and I hadn't seen it, isn't funny. Ouch... > [...] > > For me, in a normal tiled workspace, loading mod_dock causes gnome-panel > > to open as a proper 'panel' instead of as a normal window. > > This is with Gnome 3 in fallback mode, which creates panels top and > bottom (and then I have gkrellm off to the right). Ah ok. Right now I'm using the gnome2 gnome-panel configured to use only a bottom panel. I'm not sure mod_dock supports having panels on multiple sides of the screen. Anyone? > I did spend some time fiddling with mod_dock but there's no documentation > for that either. I think I did manage to get it to swallow a panel once but > it then expanded to fill 2/3 of the screen... Hmm not sure. I notice mod_dock doesn't always work when I just restart Notion, I have to restart gnome-panel itself, too. > [...] > > For a tiling workspace, i think it makes sense to ignore this request. For a > > floating one, it'd make sense to honour it indeed. Could you submit a > > feature request for this? > > Where's good? The sf.net trackers, https://sourceforge.net/tracker/?group_id=314802 > (I'm also wondering whether the defwinprop stuff is flexible enough to > support this without needing any core changes.) I'm not sure. > Also: nautilus tried to claim the root window and I ended up with a > gigantic floating window. A floating workspace is about the only time > when a root window is relevant in Notion, so I'm not surprised it's not > supported. Would this be easy to change? It looks like Nautilus doesn't actually change the root window, but instead creates a window with _NET_WM_WINDOW_TYPE set to _NET_WM_WINDOW_TYPE_DESKTOP. Sounds like we could make Notion honour that on floating workspaces, but not sure how hard that would be. Also one for the feature requests I suppose :). Kind regards, Arnout |
|
From: David G. <dg...@co...> - 2011-10-20 19:44:57
Attachments:
signature.asc
|
On 20/10/11 17:01, Arnout Engelen wrote: [...] > In the old days F9 asked for the workspace type. Since some time before > http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=3d38954deab0146e60f7f30ff44f0684b77c7500 > you could use the context command new-empty-workspace instead. > That appears to have disappeared, too, though. Not sure what the proper way > is now. Anyone? I'm running the most recent snapshot, and F9 asks for the workspace type. I have, however, found Tiling->Untile and Context->New Tiling which convert to and from floating mode respectively. [...] > You don't need that when you're using a WFloatWS though do you? What I really want is a tiled workspace, over which windows appear floating by default (unless the user has previously specified a rule, or manually drops a window into a frame). Looking at the way defwinprops work, it appears as though the first defwinprop that matches is used; that is, settings don't stack. I was rather hoping I could just put: defwinprop { floating = true } ...at the top of my config file and so have all windows floating by default, but that doesn't work. OTOH it doesn't look like it would be hard to modify ioncore.getwinprop() to stack settings. I don't know what horrible side effects this might have. [...] > I'm not sure mod_dock supports having panels on multiple sides of the screen. > Anyone? Is it possible to create multiple docks? >> I did spend some time fiddling with mod_dock but there's no documentation >> for that either. I think I did manage to get it to swallow a panel once but >> it then expanded to fill 2/3 of the screen... > > Hmm not sure. I notice mod_dock doesn't always work when I just restart Notion, > I have to restart gnome-panel itself, too. I found out why this happened: the dock swallowed the top-bar (which is one screen wide), then the gkrellm (which is 2/3 of a screen high), then the bottom-bar (which is one screen wide). So the dock ended up being about two screens wide and 2/3 of a screen high, with only the top-bar visible. [...] > The sf.net trackers, https://sourceforge.net/tracker/?group_id=314802 Okay, I've done that here. https://sourceforge.net/tracker/?func=detail&aid=3426524&group_id=314802&atid=1324531 I've labelled it 'EMWH compliance' because, hey, I can dream... >> (I'm also wondering whether the defwinprop stuff is flexible enough to >> support this without needing any core changes.) > > I'm not sure. It's not --- it can only match on class, role and instance. A more sophisticated matching engine would certainly be possible, but given all this is Lua, maybe something like: defwinprop { predicate = function(w) return w._NET_WINDOW_TYPE == "_NET_WM_WINDOW_TYPE_DOCK" end, floating = true -- or something } ...would be possible? Again, not hard --- code in clientwin_get_ident() to export the properties, and changing ioncore.getwinprop() --- but I just don't know enough about the Notion innards to know if it's a good idea or not. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "Under communism, man exploits man. Under capitalism, it's just the │ opposite." --- John Kenneth Galbrith |
|
From: David G. <dg...@co...> - 2011-10-20 21:05:50
Attachments:
signature.asc
|
On 20/10/11 20:44, David Given wrote:
[...]
> defwinprop {
> predicate = function(w)
> return w._NET_WINDOW_TYPE == "_NET_WM_WINDOW_TYPE_DOCK"
> end,
>
> floating = true -- or something
> }
Turns out 'predicate' is already supported, and it's called 'match':
defwinprop {
match = function(properties, window, windowattrs)
return windowattrs.class == "mywindowclass"
end,
floating = true
}
winprops are ordered for each {class, role, instance} tuple, but the
tuples themselves are unordered.
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "Under communism, man exploits man. Under capitalism, it's just the
│ opposite." --- John Kenneth Galbrith
|
|
From: Arnout E. <no...@bz...> - 2011-10-20 21:31:23
|
On Thu, Oct 20, 2011 at 08:44:49PM +0100, David Given wrote: > F9 asks for the workspace type. Right: choosing the 'empty' workspace layout gets you a floating ws. > I have, however, found Tiling->Untile and Context->New Tiling which convert > to and from floating mode respectively. OK > What I really want is a tiled workspace, over which windows appear > floating by default (unless the user has previously specified a rule, or > manually drops a window into a frame). Aha, yes. > Looking at the way defwinprops work, it appears as though the first > defwinprop that matches is used; that is, settings don't stack. Indeed they don't stack. I updated the 'Winprops' section of the notionconf document to better describe the matching algorithm - see http://notion.sourceforge.net/notionconf/node4.html#SECTION00450000000000000000 Documentation improvement suggestions/patches are certainly welcome :). > >> I did spend some time fiddling with mod_dock but there's no documentation > >> for that either. I think I did manage to get it to swallow a panel once > >> but it then expanded to fill 2/3 of the screen... > > I found out why this happened: the dock swallowed the top-bar (which is > one screen wide), then the gkrellm (which is 2/3 of a screen high), then > the bottom-bar (which is one screen wide). So the dock ended up being > about two screens wide and 2/3 of a screen high, with only the top-bar > visible. Jep, that sounds entirely plausible. > [...] > > The sf.net trackers, https://sourceforge.net/tracker/?group_id=314802 > > Okay, I've done that here. > > https://sourceforge.net/tracker/?func=detail&aid=3426524&group_id=314802&atid=1324531 > > I've labelled it 'EMWH compliance' because, hey, I can dream... I share your dream :). Might be good to have a seperate issue per feature though, so we can keep discussions somewhat focussed. > >> (I'm also wondering whether the defwinprop stuff is flexible enough to > >> support this without needing any core changes.) > > > > I'm not sure. > > It's not --- it can only match on class, role and instance. > > A more sophisticated matching engine would certainly be possible, but > given all this is Lua, maybe something like: > > defwinprop { > predicate = function(w) > return w._NET_WINDOW_TYPE == "_NET_WM_WINDOW_TYPE_DOCK" > end, > > floating = true -- or something > } > > ...would be possible? In fact, specifying a custom predicate is already possible, it was just not documented :(. You can override the 'match' function, for example like this: defwinprop { class = "Npviewer.bin", match = function(prop, cwin, id) return is_fullscreen(cwin) end, switchto = false, flash_fullscreen = true, } To read client window properties from lua, use ioncore.x_get_window_property (http://notion.sourceforge.net/notionconf/node7.html#fn:ioncore.x_get_window_property) and check out the atom-related functions. To get your desired behavior of having all windows float by default, I'm not sure I know of an elegant way to do that right now. Indeed having all matching winprops 'stack' their options seems like a neat idea, but it might have quite a bit of impace - we should carefully consider it. Kind regards, Arnout |
|
From: David G. <dg...@co...> - 2011-10-20 22:52:09
Attachments:
signature.asc
patch.gz
|
On 20/10/11 22:31, Arnout Engelen wrote: [...] > To read client window properties from lua, use ioncore.x_get_window_property > (http://notion.sourceforge.net/notionconf/node7.html#fn:ioncore.x_get_window_property) > and check out the atom-related functions. Documentation! Thanks very much for the link --- I'd totally failed to find that before. > To get your desired behavior of having all windows float by default, I'm not > sure I know of an elegant way to do that right now. Indeed having all matching > winprops 'stack' their options seems like a neat idea, but it might have quite > a bit of impace - we should carefully consider it. In fact, I've just changed ioncore_winprop.lua to support this. It now matches against all the defwinprop statements, in order, and accumulates settings from each one. I have this: defwinprop { float = true } defwinprop { class = "Google-chrome", float = false } ...and it actually *works* --- windows all float by default, except Chrome, which gets tiled. Of course, the stock Notion only has two defwinprop statements by default, neither of which are active on my system, so it's hardly a good test. But the patch is enclosed... -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "Under communism, man exploits man. Under capitalism, it's just the │ opposite." --- John Kenneth Galbrith |
|
From: Arnout E. <no...@bz...> - 2011-10-20 23:44:20
|
On Thu, Oct 20, 2011 at 11:52:00PM +0100, David Given wrote: > On 20/10/11 22:31, Arnout Engelen wrote: > [...] > > To read client window properties from lua, use ioncore.x_get_window_property > > (http://notion.sourceforge.net/notionconf/node7.html#fn:ioncore.x_get_window_property) > > and check out the atom-related functions. > > Documentation! Thanks very much for the link --- I'd totally failed to > find that before. Not sure how to make it more prominent - did you search for it at all? where? > > To get your desired behavior of having all windows float by default, I'm not > > sure I know of an elegant way to do that right now. Indeed having all matching > > winprops 'stack' their options seems like a neat idea, but it might have quite > > a bit of impace - we should carefully consider it. > > In fact, I've just changed ioncore_winprop.lua to support this. It now > matches against all the defwinprop statements, in order, and accumulates > settings from each one. > > ...and it actually *works* --- windows all float by default, except > Chrome, which gets tiled. > > Of course, the stock Notion only has two defwinprop statements by > default, neither of which are active on my system, so it's hardly a good > test. But the patch is enclosed... Yes, this would indeed merge the winprops - thanks for diving in. Still, we should carefully consider a couple things: - Language power: I think we have established that this approach allows us to neatly express some configurations that we couldn't express with the old semantics. Can we also think of configurations that could be expressed in the old semantics but not in the new ones? Can we do anything about those? - When defining more and more rules, does the configuration remain readable (and thus maintainable)? Will unexpected side-effects lead to confusion? - Can we think of a way to introduce this without breaking the carefully- constructed winprop configurations of our current users (and all ion3 users)? Kind regards, Arnout |
|
From: David G. <dg...@co...> - 2011-10-21 21:38:04
Attachments:
signature.asc
patch.gz
|
On 21/10/11 11:34, David Given wrote: [...] > Possibly rather than try to change the defwinprop behaviour, it would be > better to do this via new behaviour? New patch enclosed --- much simpler, doesn't change existing behaviour, and more flexible. Use it like this: tweakwinprop( function(prop, cwin, id) if (prop.float == nil) then prop.float = true end end) How does that sound? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "Under communism, man exploits man. Under capitalism, it's just the │ opposite." --- John Kenneth Galbrith |
|
From: Arnout E. <no...@bz...> - 2011-10-21 23:11:36
|
On Fri, Oct 21, 2011 at 10:38:00PM +0100, David Given wrote: > On 21/10/11 11:34, David Given wrote: > [...] > > Possibly rather than try to change the defwinprop behaviour, it would be > > better to do this via new behaviour? > > New patch enclosed --- much simpler, doesn't change existing behaviour, > and more flexible. Use it like this: > > tweakwinprop( > function(prop, cwin, id) > if (prop.float == nil) then > prop.float = true > end > end) > > How does that sound? Seems quite short and sweet. 'Define a tweak' is a bit too terse for the documentation imho - you should at least explain what a 'tweak' is/does. Is 'tweak' a good name? Does anyone else have a chance to look at the proposed change? Is this a reasonable approach? Arnout |
|
From: David G. <dg...@co...> - 2011-10-22 10:20:50
Attachments:
signature.asc
|
On 22/10/11 00:11, Arnout Engelen wrote: > Seems quite short and sweet. 'Define a tweak' is a bit too terse for the > documentation imho - you should at least explain what a 'tweak' is/does. Is > 'tweak' a good name? I haven't done any documentation yet (it it built from those --DOC comments, or does it live anywhere else?). And I'm not sold on the name. defwinproptweak? Something else? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "Under communism, man exploits man. Under capitalism, it's just the │ opposite." --- John Kenneth Galbrith |
|
From: David G. <dg...@co...> - 2011-10-21 10:34:50
Attachments:
signature.asc
|
Arnout Engelen wrote: [...] > Not sure how to make it more prominent - did you search for it at all? where? All my fault; I was looking at the Documentation section on the website, but originally skipped that link because it said *advanced* configuration; I assumed it was all about writing extensions, which I wasn't doing at the time. [...] > - Can we think of a way to introduce this without breaking the carefully- > constructed winprop configurations of our current users (and all ion3 > users)? Absolutely --- we don't want to break anything. Possibly rather than try to change the defwinprop behaviour, it would be better to do this via new behaviour? Maybe something as simple as: add_winprop_hook( function(prop, cwin, id) -- make all windows float unless specified otherwise if not prop.float then prop.float = true end end ) These then get run (in order) after ioncore.getwinprop() has scanned the defwinprop list. This should satisfy Principle of Least Surprise while at the same time being more flexible. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ "I have always wished for my computer to be as easy to use as my │ telephone; my wish has come true because I can no longer figure out │ how to use my telephone." --- Bjarne Stroustrup |
×
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