The signature for lua_sethook has changed in Lua 5.3 and no longer returns a value. Since lua_sethook is now a void, libextl no longer compiles.

Recently, I have been running notion with a jemalloc compiled with strict settings. One of the things that does is to overwrite buffers that have been free()d with 0x5a, so later accesses will not work.
I got at least three different core dumps. I've fixed one of them (#70).
One other core dump happened when I clicked on the tabs to switch windows, usually after one to ten switches.
I've now lost motivation, because I couldn't get notion to run for more than a minute in that setting.
Please do a review and make sure that data is not used after free(). Thanks.

Frames have a minimal size that depends on the windows inside of the frame - even those that are not currently visible. Presumably the windows announce a minimum size and we honor that request.

I think we should ignore the minimum sizes announced by the windows, and give the users the flexibility to make the frames as small as they like.

Hi, I have tried several different compton configurations. I have a Lenovo laptop with Intel integrated graphics. When running compton and switching to an empty workspace, I get something like this:
https://d.va-online.moe/476PKkOM.mp4

As you can see the title bar says "empty frame" yet there are clearly two windows there. You can't interact with them, as they're still "images" from another workspace.

Additionally, running flameshot a screenshot utility and then cancelling the capture will update the screen

From the manual:

This hook is not called in protected mode and can be used for arbitrary placement policies (deciding in which workspace a new WClientWin should go). In this case, you can call

reg:attach(cwin)

where reg is the region where the window should go, and cwin is the first argument of the function added to the hook.

But attaching the cwin this way to a frame at least doesn't create a WGroupCW.

Next attempt is frame:attach_new{type="WGroupCW"}, but that just returns nil without creating a new group.

It seems to me that there's no way to do this properly from lua.

NB: Haven't tried it, but I suspect clientwin attach on a WGroupWS creates a frame and groupcw automatically?

fchmod on sockets is a linuxsism. A similar effect can be reached on stream sockets by calling plain chmod() on the file path after bind(), but before listen(). See the patch below, which still uses fchmod(), but ignores the EINVAL error on BSDs.
Also remove SOCK_MAX, which is hardcoding a OS-specific limit. sizeof() does a better job here.

Christopher

From 98d3a98ffef86eab5a37234077983898a27e98f0 Mon Sep 17 00:00:00 2001
From: Christopher Zimmermann <[email protected]>
Date: Mon, 18 Apr 2016 13:10:53 +0200
Subject: [PATCH] fix unix domain socket on *BSD

---
 mod_notionflux/mod_notionflux.c        | 16 ++++++++++------
 mod_notionflux/notionflux.h            |  1 -
 mod_notionflux/notionflux/notionflux.c |  2 +-
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git mod_notionflux/mod_notionflux.c mod_notionflux/mod_notionflux.c
index c055c44..fab11e9 100644
--- mod_notionflux/mod_notionflux.c
+++ mod_notionflux/mod_notionflux.c
@@ -215,7 +215,7 @@ static bool start_listening()
         return FALSE;
     }

-    if(strlen(listenfile)>SOCK_MAX){
+    if(strlen(listenfile)>sizeof(addr.sun_path)){
         warn("Too long socket path");
         goto err;
     }
@@ -225,8 +225,9 @@ static bool start_listening()
         goto errwarn;

     if(fchmod(listenfd, S_IRUSR|S_IWUSR)<0)
-        goto errwarn;
-    
+        if(errno != EINVAL) /* fchmod() on socket is a linuxism. */
+       goto errwarn;
+
     addr.sun_family=AF_UNIX;
     strcpy(addr.sun_path, listenfile);

@@ -238,11 +239,14 @@ static bool start_listening()
             goto errwarn;
     }

-    if(bind(listenfd, (struct sockaddr*) &addr,
-            strlen(addr.sun_path)+sizeof(addr.sun_family))<0){
+    if(bind(listenfd, (struct sockaddr*) &addr, sizeof(addr))){
         goto errwarn;
     }
-    
+
+    /* chmod() after bind(), but before listen() is still early enough. */
+    if(chmod(listenfile, S_IRUSR|S_IWUSR)<0)
+   goto errwarn;
+
     if(listen(listenfd, MAX_SERVED)<0)
         goto errwarn;

diff --git mod_notionflux/notionflux.h mod_notionflux/notionflux.h
index 11cd783..f07c7aa 100644
--- mod_notionflux/notionflux.h
+++ mod_notionflux/notionflux.h
@@ -16,6 +16,5 @@
 #define MAX_SERVED 8
 #define CHUNK 1024
 #define MAX_DATA (1024*4)
-#define SOCK_MAX (108-1)

 #endif
diff --git mod_notionflux/notionflux/notionflux.c mod_notionflux/notionflux/notionflux.c
index 793882a..7fd0893 100644
--- mod_notionflux/notionflux/notionflux.c
+++ mod_notionflux/notionflux/notionflux.c
@@ -199,7 +199,7 @@ int main(int argc, char *argv[])
     if(sockname==NULL)
         die("No socket.");

-    if(strlen(sockname)>SOCK_MAX)
+    if(strlen(sockname)>sizeof(serv.sun_path))
         die("Socket name too long.");

     sock=socket(AF_UNIX, SOCK_STREAM, 0);
-- 
2.7.4

This happens when the current frame is too narrow (small width) and you press F9 to popup new workspace query. It tries to unsqueeze so everything can be read but it fails.
It probably happens with any other query, but create workspace has a long text by default so it's easier to see.

/usr/local/bin/notion: Unable to reparent.
/usr/local/bin/notion: Stack trace:
0 [C]: in 'unsqueeze'
1 mod_query.lua:80: in 'query'
2 mod_query.lua:545: in 'query_workspace'
3 [string "mod_query.query_workspace(_)"]:1
  [Skipping unnamed C functions.]

Since #84 it seems our lgpl/notion4 branch is reproducible, but it would be good to make sure we notice when this breaks.

I have a customer 'look' that was made for master.

On the lgpl branch, inactive tabs have a black background instead of my configured background color.

There seems to be a bug in the code that decides whether a window is a dockapp or not. The problem occurs when using stalonetray in the WMaker dockapp-mode. When this occurs, stalonetray creates two windows. One is a hint window, and one is the actual dock tray window. Notion only detects the actual dock tray window as a dockapp.

Unfortunately, this causes the following kludge to have very odd behavior:

defwinprop{
    is_dockapp = true,
    class = "stalonetray",
    statusbar = "systray"
}

In particular, notion displays a blank window for the hint window. If this hint window is unmapped, then the dock disappears. A work-around is to set the statusbar property based on the class alone:

defwinprop{
    class = "stalonetray",
    statusbar = "systray"
}

This isn't a serious problem, and might not even be notion's fault, but I spent almost a full day tracking down the problem, so it would be nice if anyone didn't get bitten by a similar problem.

Ends with:

[depend] while making notionconf.dvi: file contents does not seem to settle

For now removing dvi and ps from 'all'

Is it possible to configure polybar to work with Notion? I've done some research and can't seem to find anything

On 32784ef things looked fine

But with the following commit (313f408) I lost text.

When I diff the two I get

--- 32784ef8/system-autodetect.mk	2017-10-16 23:07:04.200584545 +0200
+++ 313f4086/system-autodetect.mk	2017-10-16 23:03:55.117604136 +0200
@@ -112,6 +112,9 @@
     X11_INCLUDES += `pkg-config xft --cflags`
     X11_LIBS += `pkg-config xft --libs`
     DEFINES += -DHAVE_X11_XFT
+    DEFINES += -DHAVE_X11_BMF
+else
+    DEFINES += -DHAVE_X11_BMF
 endif

And I can see from the build log that both flags are enabled
x86_64-pc-linux-gnu-gcc [...] -DHAVE_X11_XFT -DHAVE_X11_BMF [...]

I can supply more info if needed. just let me know.

I just filed a chromium bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=617139, but that problem only occurs when notion is running.

The issue in chromium is, when one initiates a drag & drop on a web-page, something goes wrong and the expected "dragover" events do not happen. "dragstart" event does happen, but after that, it's silence.

Here's a jsfiddle that shows the issue: http://jsfiddle.net/G9mJw/20/

When you drag the red square over the dotted rectangle, the text above the rectangle should count dragover events. If notion is not running, this works, if notion is running, no dragover events are captured.

On every platform I've used this window manager I've had terrible performance changing window size, with the opaque_resize option on.

Specifically, using the mouse resize the window lags behind where I'm dragging (and sometimes other glitches occur, like windows going black temporarily), and there is the same lagging with the keyboard controls.

With or without compositor this happens. This does not happen on other WMs for me (such as awesome and plasma), on any of the machines I've tried this on.

^{And as a side-note, since I'm always complaining in here, I do actually love this WM and I use it wherever I can.}

I'm attempting to use contrib/statusbar_wsname.lua on notion-3-2017050501 but I'm getting an error. I added the script in cfg_notion.lua

...
dopath("contrib/statusbar_wsname")
dopath("cfg_defaults")
...

The files are located in my local .notion dir.

Then I added %wsname to the status bar template

template="%wsname [ %date || load: %load ] %filler%systray%systray_doc"

Any ideas what could cause this error?

Notion startup error log:
>> Errors starting ion-statusd:
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Unable to find 'statusd_wsname.lc' or 'statusd_wsname.lua' on search path...
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/etc/user/john/.notion/lib/statusd_wsname.lc'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/etc/user/john/.notion/lib/statusd_wsname.lua'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/etc/user/john/.notion/statusd_wsname.lc'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/etc/user/john/.notion/statusd_wsname.lua'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/lc/statusd_wsname.lc'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/lc/statusd_wsname.lua'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/share/notion/statusd_wsname.lc'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/share/notion/statusd_wsname.lua'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/etc/notion/statusd_wsname.lc'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/etc/notion/statusd_wsname.lua'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/mod/statusd_wsname.lc'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/mod/statusd_wsname.lua'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/statusd_wsname.lc'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: '/nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/statusd_wsname.lua'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: 'statusd_wsname.lc'
   /nix/store/i0pc6fbxmlv8xjanylzi1jw8b1290pyg-notion-3-2017050501/lib/notion/bin/ion-statusd: Tried: 'statusd_wsname.lua'

I'm working on adding icons to tabs and when adding styling support I noticed that show_icon = true in a defstyle wasn't retrievable using grbrush_get_extra.

Digging I see that the code initializing the brush extra table ends up calling extl_stack_get(st, -1, 'a', FALSE, NULL, &v) (thorugh extl_table_iter_do). Ie. get the stack value as a ExtlAny. But extl_stack_get is missing a case when the actual stack type is LUA_TBOOLEAN.

It's simple enough to fix:

    case LUA_TBOOLEAN:
        if(type!='b' && type!='a')
            return FALSE;

        b=lua_toboolean(st, pos);

        if(type=='b'){
            if(valret)
                *((bool*)valret)=b;
        }else if(type=='a'){
            if(valret){
                ((ExtlAny*)valret)->type='b';
                ((ExtlAny*)valret)->value.b=b;
            }
        }
        return TRUE;

I assume this case simply was forgotten (or maybe ExtlAny didn't support boolean at some point). Correct if there's an actual reason for the omission.

If I complete the icon branch and it's accepted, the fix will be included there. Otherwise the bug's at least exposed here :)

td;dr: Notion is currently released under the "Ion License", which is the LGPL with a slight (trademark-ish) amendment. For this to happen we would have to re-implement some features that are currently only available under the Ion License and for which the original author is not inclined to allow distribution under the plain LGPL.

Background

Notion is a fork of Ion, created when the original Ion maintainer retired the project.

Before 2007, Ion was licensed under the LGPL. In 2007, a "Name policy" was added, which introduced some additional restrictions when releasing the code under a name that is associated with the Ion project. It is unclear whether this should be read as an integral part of the license, or as a trademark provision. Even though Notion is clearly not associated with the original Ion project, so the restrictions from the name policy do not apply to Notion, it makes it unclear whether Notion is strictly spoken "non-free".

In 2010, the original author abandoned the Ion project, and Notion was created. It has been a long-standing wish for the Notion project to move back to the plain LGPL. Unfortunately reaching out to the original author to relicense his contributions since 2007 was not succesful. All contributions to Notion since 2010, however, have been explicitly dual-licensed under the Ion license and the LGPL.

Approach

We would like to achieve a version of Notion that removes the confusion of the "name policy" and is clearly licensed under the plain LGPL. For this we can use all code prior to 2007 and after the forking of Notion, but not any code that has been introduced between those 2 points.

At the same time, however, we want to allow contributions to the 'master' branch, and be able to pull those contributions into the LGPL

To achieve that, we have introduced an 'lgpl' branch to Notion, which is intended to contain only LGPL code. To achieve this, we have taken the code up to the license change, and then did a "merge" of the non-LGPL git tree with the "ours" merge strategy. This exotic merge strategy (not to be confused with the "ours" merge strategy option) disregards all code from the non-LGPL branch, but does add them to the git history of the branch. This means from that point on, we can merge from master into lgpl without 'leaking' non-LGPL code into the LGPL branch. This still involves careful manual work, and is a work-in-progress I have been working on. I would like to do the merging myself, but testing this branch and proposing fixes (while being careful not to violate any copyrights by copying code that is only available under the Ion license) would be very helpful.

List of features to be backported.

A possibly-outdated list of features to be reimplemented can be found at https://sourceforge.net/p/notion/lgpl-regressions/search/?q=%21status%3Awont-fix+%26%26+%21status%3Aclosed . Once the lgpl branch is up-to-date with master again we should verify them and if valid move them to the GitHub issue tracker.

I have two problems with the new "display dialogs as float" feature:

• the option "window_dialog_float=false," in etc/cfg_notion.lua does not seem to deactivate dialogs as float.
• when a dialog is opened through a window in the scratchpad, the dialog window appears under the scratchpad.

I use the compositor compton, with arguments compton --vsync opengl-swc. This compositor works fine with e.g. awesomewm.

When hovering over items that produce a tooltip, the tooltip will flash a few times before appearing properly, and the whole screen can flash white or black as well before the tooltip appears properly. The tooltips have a transparent background when they appear.

Additionally, floating transparent windows that can be dragged around don't display correctly, they appear transparent on a black background, rather than transparent over the other windows in the background.

For all I know notion does not support compositors, in which case I'd ask for support. Compositors are used for fancy effects and can get you better performance. I personally use a compositor to prevent screen tearing in programs such as Firefox, which I think is quite an important practical matter.

Might be just a matter of adding 5.3 to the list at build/lua-detect.mk, or it might not 😄

Missing atom. Notion not running?: Resource temporarily unavailable

Perhaps the atom was renamed at one side but not the other?

http://notion.sourceforge.net should redirect to https://notionwm.net

I normally run notion with my laptop in a dock that is connected to two external monitors. When I disconnect my laptop from the dock and use the built-in laptop monitor, Notion is smart enough to put all my workspaces onto the single screen. When I have two screens, though, I usually use Mod1+1..0 to switch between workspaces. When the screens are merged, Mod1+1...0 is mapped to the workspaces from one of the screens. The workspaces from the other screen is still accessible, for instance via Mod1+>, Mod1+<, or Mod1+K K, but it makes them much more difficult to access.

Is it possible to merge the workspaces of each screen? For instance, if I had window A in workspace 1 on screen 1, and window B in workspace 1 on screen 2, when I switch to one screen I'd like to have window A and B in workspace 1.

To begin with, I should point out that this is not for the latest git notion, but the latest package in arch linux, which is tagged Version : 20170201-1, although I've looked over all the commits between then and now, and nothing could conceivably be a fix for this.

After installing the aforementioned notion package & with no ~/.notion or an empty ~/.notion, notion starts up just fine. However, if I copy one of the cfg_X.lua files from /etc/notion to ~/.notion without modifying it at all, notion starts in what I call "emergency mode." There's no layout, and it shows an xmessage about how it's defining a few emergency bindings because it can't read one or more of the main keymaps. Values of X are definitely 'notion' and possibly 'notioncore' and 'defaults'.

Interestingly enough, copying the system look.lua to ~/.notion works just fine, and replacing the default contents with e.g. dopath('look_greenlight') works as expected: notion starts with a green theme.

I always used to (i.e. in ubuntu) copy one or two of the config files to ~/.notion (like it says you're supposed to in the comments) and modify them, and notion would fall back to the system config files for the other ones it couldn't find in ~/.notion. But it appears that in the arch version, it will fail to find other files if one or more is present in ~/.notion.

I suspect this may be a bug w/r/t how arch builds the package, but without some help on some notion internals I've long since forgotten, there's no way I can fix this myself. In particular, which directories notion/dopath attempts to check, and under what circumstances it wouldn't fall back.

The arch config is here: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/notion

It sets ETCDIR to /etc/notion (which I think is the default anyway), and I see (i think) that being added to the search path. I note that it sets lua to 5.3 during build and 5.2 during install, but i suspect that makes no difference (assuming the problem isn't that lua 5.3 doesn't work properly in the first place).

Can anyone shed any light on this?

PS: sending the link to arch maintainers too

Example application that misbehaves: https://github.com/VUE/VUE/releases/download/3.3.0/VUE.jar

java -jar VUE.jar and place the main window in a rightmost split. Right click or use the menu. The result is not good:

AWT use a dedicated x-window for its menus. It is positioned relative to the root window even though notion reparent it under the WGroupCW window.

I've tried various combinations of wmname and _JAVA_AWT_WM_NONREPARENTING to no avail :(

The closest I've come to a fix is to use a clientwin_do_manage_alt hook taking complete control over the placement of these windows, (Instance: sun-awt-X11-XWindowPeer) manually converting the absolute coordinates to relative. This works for the context menu, but not the menubar menu.

I assume this is a problem for other notion users too, but eg. https://github.com/raboof/notion/blob/master/etc/cfg_kludges.lua#L65 indicates that some awt java apps at least partially works? If someone can confirm/deny the problem I'd be thankful.

Possibly related commit: 0cd1e04

Hello.

A long time ago ion3 works well with X11 compositing. So, I've fixed it with
neg-serg/notion/commit/6d77ac848099f344f80bededb436c13d2cb8c743l
and a couple of scripts.

But anyway there are a problem with argb support in Notion. For example urxvt -depth 32 -bg rgba:0000/0000/0000/eeee or st with transparency patch doesn't work well.
I think that the problem is in virtual root handling, which prevent to get root pixmap correctly.
Patches are not so terrible, for example look at http://st.suckless.org/patches/st-git-20151129-argbbg.diff

You need a compton reproduce this issue.

Maybe you know how to fix this or implement a patch which forcibly set "virtual root" pixmap?

It's great that this is useable with a mouse, I've seen the ability to drag windows between frames;

has anyone tried to extend the mouse support to allow creating splits - e.g. by dropping a window in the left/top/upper/lower region of a frame, create a new split there, or drop nearer the centre(or directly on the titlebar) to add to the existing frame; show the action with a rectangular highlight + icon. Similar to the behaviour of the internal tilling managers in IDEs like visual studio or eclipse.

Whenever I've tried a tiler I always go back to floating because its' hard to remember the keybindings... but I use emacs with a tiled layout and 'wind move' hotkeys. Perhaps some popup menu when you hold 'super' could assist

Ref: #19 comment

example: http://ui-grid.info/docs/#/tutorial/103_filtering, scroll down and try to select a gender from the select control in the gender header of the table.

It seems like the mouse coordinates used are offset vertically from the real coordinates. The select list is:

<empty>
male
female
unknown
...

Clicking on unknown causes female to be selected, clicking female causes male to be selected and so on.

• It works as expected in fullscreen (no tabbar).
• The bug only happens in firefox using notion (tested with i3 and xmonad).
• The bug does not affect the fully native select widget: https://jsfiddle.net/7jp2y4oo/

I spent a few minutes attempting to understand how the UI-grid (or is it a native angular widget?) works, but didn't easily find the interesting parts.

Notion sometimes produces stack traces when reporting errors:

>> bad argument #-1 to '?' (table expected, got thread)
>> bad argument #-1 to '?' (table expected, got function)
>> Stack trace:
   0 [C]: in 'do_defbindings'
   1 ioncore_bindings.lua:206: in 'defbindings'
   2 /usr/local/etc/notion/cfg_notioncore.lua:22
     [Skipping unnamed C functions.]
   5 [C]: in 'dopath'
   6 /home/aengelen/.notion/cfg_defaults.lua:5
     [Skipping unnamed C functions.]
   9 [C]: in 'dopath'
   10 /home/aengelen/.notion/cfg_notion.lua:69
     [Skipping unnamed C functions.]

While super useful, this only shows the LUA part of the trace. It would be very useful to also show the C side of the trace (e.g. though https://www.gnu.org/software/libc/manual/html_node/Backtraces.html)

Hi,
I took a look at the updated Gentoo package and wrote a patch [1] to use pkg-config for all library flags.
It would be nice to have on installations with awkward library location in general, i.e. Gentoo/Prefix.
Thanks
[1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-wm/notion/files/notion-3_p2015061300-pkg-config.patch?view=markup

A useful advantage of Open Source software is the fact that it is possible to check the sources for unwanted code.

When software is distributed in binary form, it does not go without saying that the distributed binary indeed corresponds to the sources. An elegant way to increase confidence that the build/distribution pipeline has not been compromised is to independently build the application on different machines, and check that the resulting binaries match. This does require that we make sure there are no 'accidental' non-determinisms in our build process. This is what we mean by making the build 'reproducible'.

'Officially', Notion is only distributed in source form, side-stepping this issue entirely. If you like to create binary packages for Notion, however, we warmly recommend you build them in a 'reproducible' way. It is entirely possible that this requires improvements to the Notion build setup, and we welcome any contributions that help make it more reproducible.

A useful resource around this topic is https://reproducible-builds.org

Subtasks:

• exports.c generation is not deterministic
• Test with reprotest

With really high-resolution displays becoming fairly common, sometimes apps natively paint themselves very small relative to the desktop's real-estate, and the ability to zoom the desktop on-the-fly would solve alot of tricky usability scenarios that result.

After building without xft installed, I get:

2018-11-20 18:10:48 INFO  /notion/../ioncore.c:613: ioncore_startup: Starting Notion
>> /usr/local/lib/notion/mod/de.so: /usr/local/lib/notion/mod/de.so: undefined symbol: XftColorFree
>> Unable to find 'de.so' on search path.
>> Stack trace:
   0 [C]: in 'select_engine'
   1 /home/aengelen/.notion/look.lua:6
     [Skipping unnamed C functions.]
>> No drawing engines loaded, trying "de".
>> /usr/local/lib/notion/mod/de.so: /usr/local/lib/notion/mod/de.so: undefined symbol: XftColorFree
>> Unable to find 'de.so' on search path.
>> [190] X_GrabKey (33) 0x128: BadAccess (attempt to access private resource denied)

Apparently some call is not correctly guarded with HAVE_X11_XFT?

I would like to see the time and system tray in my screen always apart from the window tabs, so I am using status-bar by swallowing the dock (stalonetray).

My layout is something like:

<Tab Bar>
Normal Area
<Status Bar | System Tray>

However having a tab-bar and status-bar occupies a lot of real estate, so can I instead:

1. Make the status-bar to swallow the tab-bar?

<Status Bar | Tab Bar | System Tray>
Normal Area

or

2. Hide the status-bar using a key binding similar to dock in floating mode:

defbindings("WScreen", {
    bdoc("Toggle floating dock."),
    kpress(META.."D", "mod_dock.set_floating_shown_on(_, 'toggle')"),
}) 

I should mention at the outset that I use notion as my WM, in case that's relevant to what's going on here.

I was trying to do some notion development. Previously, I had a notion xephyr setup working, and I thought as a first step I would contribute one of these so it would stay in the repo (and I wouldn't lose it).

I made 2 scripts, one to run xephyr and one to run notion. The xephyr script is little more than Xephyr $display -noreset -br -ac. With that running, I can run DISPLAY=$display i3 without trouble. However, when I attempt to run e.g.

DISPLAY=$display $notion_exe \
    -display $display \
    -noerrorlog \
    -searchdir $root/de \
    -searchdir $root/ioncore \
    -searchdir $root/mod_query \
    -searchdir $root/mod_menu \
    -searchdir $root/mod_tiling \
    -searchdir $root/mod_statusbar \
    -searchdir $root/mod_sp \
    -searchdir $root/mod_notionflux \
    -searchdir $root/mod_xrandr \
    -searchdir $root/mod_xinerama \
    -searchdir $root/utils \
    -searchdir $root/contrib/scripts \
    -session dev

First of all, it doesn't quite start up properly. So when I go to kill it and try monkeying around with the configuration again, it restarts my current xserver. This makes trying to figure out why it isn't working properly very annoying.

So basically, is this a bug in notion? Is there a preferred way to run a nested notion for development purposes?

I have 3 monitors attached to my laptop: the internal screen, one to the left of it and one to the right.

When I keep firefox on the rightmost or center screen, some subwindows like context menus or other popup menus (e.g. built-in dropdowns or input suggestions on previously filled forms but not ones which are implemented in javascript, I assume because they're not handled directly by GTK) appear at the correct position, but on the leftmost screen.

If I keep firefox on the leftmost screen, the popup works as expected.

It also doesn't happen with thunderbird or other GTK2 or GTK3 software, but affects all versions of firefox I've used on this machine up until 57.

Any ideas? Can anyone confirm this issue as being notion specific and not a firefox bug?

You can switch tabs with Mod1+K 1 through Mod1+K 9. When you press 'Mod1+K', it would be convenient if there was some visual indication of which tab corresponds to which number.

(this feature is already present on master, but only available under the Ion license)

When I try to run Notion as my window manager under KDE Plasma (with the default configuration), notion crashes on startup.

I get the error message

>> [702] X_GrabKey (33) 0x23e: BadAccess (attempt to access private resource denied)

but I don't know if this is related.

Backtrace attached

gdb.txt

(thanks to Sergej Pupykin on the notion-devel list)

Name=Notion
Comment=This session logs you into Notion
Exec=/usr/bin/notion
TryExec=/usr/bin/notion
Icon=
Type=XSession

May be it should be placed into contrib/ or installed into
/usr/share/xsessions/ during make install.

See also:
https://wiki.archlinux.org/index.php/Notion

Hello,

it looks like @AMDmi3 does not support the FreeBSD port for notion anymore.
I found a port (his?) and updated it to the latest notion version.

[ link removed ]

Feel free to link the website to it.

Best Regards,
Stefan

EDIT: AMDmi3 has renamed the repository. The notion port is now here:
https://github.com/AMDmi3/freebsd-ports-wip/tree/master/x11-wm/notion

Recently I started having a problem where the right-click menu in Firefox (version 55 and up) shows up on the wrong screen when using notion, but this doesn't happen when using fluxbox or qtile. It also only happens when firefox is on one screen, but not if it is on the other.

Gentoo system, using either the version of notion in portage (quite old, 2015061300) or directly compiling what is in git (as of 26 Sept 2017, anyway). It doesn't seem to matter if I'm using mod_xinerama and mod_xrandr, or just mod_xrandr. I have two monitors, DisplayPort-0 and DVI-I-0, with DVI-I-0 to the left of DisplayPort-0. Using arandr, it seems that DisplayPort-0 is the primary screen. Putting firefox on DisplayPort-0, the right-click menu ends up on DVI-I-0 to the left. Putting firefox on DVI-I-0, the right-click menu shows up on the DVI-I-0, exactly where one would expect it to show up.

I'm not sure if this is a notion bug, an underlying Xorg bug, or intended behavior that I need to work around. Help? I can't imagine that I've provided enough information to figure out what's going on, but I'm happy to provide feedback if you can give me an idea where to start.

Thanks, and thank you for keeping a very useful WM alive!

This seems like perfectly fine lua code at least on 5.2.

ldd suggests notion is loading liblua5.2.so.0 though.

For example the file menu and the class search results.

Might be a matter of adding some winprops configuration.

It would be nice if notion supported WM_FULLSCREEN_MONITORS. I use VMWare Workstation under notion, and it gives the same error as reported here (for awesomewm):

https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1254

They seem to be empty, let's track down who creates them an avoid that.

This issue mostly consists of adding a corresponding change to polybar, but I wanted to ask:

If I inspect xprop -root on different workspaces, I get different values for:

_ION_WORKSPACE(STRING) = "WGroupWS<1>"

(mostly the number is different).

Since I don't have a multihead setup to test with at the moment, how does this behave on a second screen? How do I rename a workspace? Will it stay _ION_WORKSPACE or will it change to _NOTION_WORKSPACE at some point, like e.g. _NOTION_MOD_NOTIONFLUX_SOCKET?

During development you might get errors like:

/usr/local/lib/notion/mod/mod_dock.so: Module version mismatch: expected '3-2019050101-544-gb8eeb757+20190514-2226', found '3-2019050101-544-g7e9ebc87'. Refusing to use.

when doing a make install without make clean.

This is overly strict. The version check should (at least) ignore everything after the +, and perhaps even only warn (and not refuse to load).