notion-devel — Development discussion about the notion window manager

Re: [Notion-devel] [Notion-general] Notion 4

[Dima K. <no...@di...>]

Arnout Engelen <ar...@bz...> writes:

> On Sun, Oct 6, 2019 at 6:05 AM Dima Kogan <no...@di...> wrote:
>> I still see some look-related issues that aren't fixed with any based_on invocation I
>> tried:
>>
>> 1. In my look the empty-pane color used to be black, but now it's gray.
>>    Empty panes come up when I create a new workspace with
>>    ioncore.create_ws(_). This is also the filler color used to cover
>>    empty space if a window doesn't completely fill a tab. Do you know
>>    what style thing controls this?
>>
>> 2. I think the margin between the top of the tab bar and the top of the
>>    screen has increased by a few pixels. Do you know what controls this?
>>
>> 3. Menus that pop up with mod_menu are now using a different font. For
>>    instance, the main menu: mod_menu.menu(_, _sub, 'mainmenu',
>>    {big=true}). Do you know where this font is set? It also looks weird
>>    on my machine, and I suspect my box doesn't actually HAVE this font.
>>    So there could also be a packaging issue I need to look at. Any way
>>    to tell what font it's trying to use?
>
> Could you share the custom look you're using here? Are you using an
> external compositor?

Sure. No external anything; everything is vanilla. The look is attached.
It's a very-lightly hacked look_ios.lua. I don't remember exactly what I
was going for when I settled on this; it was a very long time ago.

Re: [Notion-devel] [Notion-general] Notion 4

[Dima K. <no...@di...>]

Hi. Notes inline.


> On Mon, Sep 30, 2019 at 6:17 AM Dima Kogan <no...@di...> wrote:
>
>> After installing the new package on my box, I could run notion, but it
>> started up in some odd state where the look was different, and most (but
>> not all) of my bindings didn't work anymore. No error messages.

I debugged this. Not related to the update, it turns out. Never mind!



Arnout Engelen <no...@bz...> writes:

> I changed the style loading code to auto-detect 'based_on' based on prefix.
> The PR is at https://github.com/raboof/notion/pull/197 . Could you have a look
> if that does the trick for you?

I just tested it. Better. Previously (the latest notion from a few days
ago) I needed to do this in my look to make things look mostly as before:

  de.defstyle("frame-tiled", {
      based_on = "frame",
      spacing = 0,
  })

  de.defstyle("frame-tiled-alt", {
      based_on = "frame",
      spacing = 0,
  })

  de.defstyle("tab-frame-tiled", {
      based_on = "tab",
      spacing = 0,
  })

With that update (auto-detecting 'based_on' from the prefix), I can omit
the based_on stuff, and get similar results. I still see some
look-related issues that aren't fixed with any based_on invocation I
tried:

1. In my look the empty-pane color used to be black, but now it's gray.
   Empty panes come up when I create a new workspace with
   ioncore.create_ws(_). This is also the filler color used to cover
   empty space if a window doesn't completely fill a tab. Do you know
   what style thing controls this?

2. I think the margin between the top of the tab bar and the top of the
   screen has increased by a few pixels. Do you know what controls this?

3. Menus that pop up with mod_menu are now using a different font. For
   instance, the main menu: mod_menu.menu(_, _sub, 'mainmenu',
   {big=true}). Do you know where this font is set? It also looks weird
   on my machine, and I suspect my box doesn't actually HAVE this font.
   So there could also be a packaging issue I need to look at. Any way
   to tell what font it's trying to use?

Thanks!

Re: [Notion-devel] [Notion-general] Notion 4

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

On Wed, Oct 2, 2019 at 6:58 PM Dima Kogan <no...@di...> wrote:
> Arnout Engelen <no...@bz...> writes:
> > On Mon, Sep 30, 2019 at 6:17 AM Dima Kogan <no...@di...> wrote:
> >> The title bars
> >> should be yellow, but in the new notion they're coming up black.
> >
> > Perhaps you need to add the 'based_on' fields as documented in the
> > migration notes?
>
> I debugged this. I needed to do two things:
>
> 1. Add a base to the "tab" style, so that it now looks like this:
>
>     de.defstyle("tab", {
>         based_on = "*",
>         ....
>
> 2. Remove the "tab-frame-tiled" style, or add a base to it. I had this:
>
>     de.defstyle("tab-frame-tiled", {
>         spacing = 0,
>     })
>
>
>   Removing this entirely, or adding
>
>     based_on = "tab"
>
>   gave me the yellow window tabs back. based_on="*" doesn't do it.

Aha. Without looking at the code, it seems ion auto-detected the parent
by looking at the name of the style.

> Is there any way to make this fail in a friendlier way? Could we somehow
> detect that something isn't right, and to throw an error message, at the
> very least?

Hmm, I don't really see how we could detect this, but...

> Or maybe consider reverting the inheritance change?

Unfortunately, the based_on field was removed during the "Ion License" days,
so we cannot just 'revert' this (without re-introducing non-LGPL code). Instead,
I changed the style loading code to auto-detect 'based_on' based on prefix.
The PR is at https://github.com/raboof/notion/pull/197 . Could you have a look
if that does the trick for you?

> I suspect that a large number of users are using configurations that
> haven't been touched or thought-about for many years; and it'd be nice
> if stuff kept working.

Yeah - I think we can afford to change some defaults since it's a new major
version, but indeed we shouldn't create arbitrary barriers.


Kind regards,

Arnout

Re: [Notion-devel] [Notion-general] Notion 4

[Dima K. <no...@di...>]

Arnout Engelen <no...@bz...> writes:

> On Mon, Sep 30, 2019 at 6:17 AM Dima Kogan <no...@di...> wrote:
>
>> After installing the new package on my box, I could run notion, but it
>> started up in some odd state where the look was different, and most (but
>> not all) of my bindings didn't work anymore. No error messages.
>
> That's weird.

Let me poke at this later...


>> As a test I then moved ~/.notion/default-session--0 and restarted
>> notion. It came up with the correct keybindings this time, but the look
>> was still broken. It is apparently loading the correct .lua file
>> defining the look, but it doesn't work anymore.
>> Can somebody please see why it's loading incorrectly? The title bars
>> should be yellow, but in the new notion they're coming up black.
>
> Perhaps you need to add the 'based_on' fields as documented in the
> migration notes?

I debugged this. I needed to do two things:

1. Add a base to the "tab" style, so that it now looks like this:

    de.defstyle("tab", {
        based_on = "*",
        ....

2. Remove the "tab-frame-tiled" style, or add a base to it. I had this:

    de.defstyle("tab-frame-tiled", {
        spacing = 0,
    })


  Removing this entirely, or adding

    based_on = "tab"

  gave me the yellow window tabs back. based_on="*" doesn't do it.


Is there any way to make this fail in a friendlier way? Could we somehow
detect that something isn't right, and to throw an error message, at the
very least? Or maybe consider reverting the inheritance change? I
suspect that a large number of users are using configurations that
haven't been touched or thought-about for many years; and it'd be nice
if stuff kept working.

Thanks!

Re: [Notion-devel] [Notion-general] Notion 4

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

On Mon, Sep 30, 2019 at 6:17 AM Dima Kogan <no...@di...> wrote:
> I just pushed packages targeting Debian/buster (the current stable) into
> Debian/experimental. They should now be percolating through the system,

Thanks!!

> Broadly, this seems to work. Some notes:
>
> In the debianization I have to tell the build to use the CPPFLAGS from
> the environment in addition to the CFLAGS from the environment. Can we
> update the notion build system to do that instead?

Sure! What changes did you make? Could you share the patch (or even PR)?

> I'm still building the notion-dev package, as we have for a very long
> time. The notion build system doesn't install any .h files, so the
> debianization is doing that. Is this thing useful? Any idea if it works?
> Any idea how to test it?

I suspect its purpose was to allow building 3rd-party modules. I think
that's pretty rare, and anyone building a 3rd-party module would probably
be able to just download the notion sources themselves, so I think it
is probably fine to drop this package.

> The older notion package contained these files, which are no longer
> being installed by the build system. Is this correct?
>
>     /usr/share/locale/de/LC_MESSAGES/notion.mo
>     /usr/share/locale/fr/LC_MESSAGES/notion.mo
>     /usr/share/man/cs/man1/notion.1.gz
>     /usr/share/man/fi/man1/notion.1.gz
>     /usr/share/notion/welcome.cs.txt
>     /usr/share/notion/welcome.fi.txt

This is correct: these were introduced or substantially changed under
the Ion License.

> After installing the new package on my box, I could run notion, but it
> started up in some odd state where the look was different, and most (but
> not all) of my bindings didn't work anymore. No error messages.

That's weird.

> I'm not sure if it reverted to the default bindings or not; it didn't tell me.

Reverting to the 'old' bindings requires manual configuration, so that
is probably not it.

> I tried to hit META+/ (window key and the / key) since the migration page
> suggests this shows me the current bindings, but this did nothing. What
> is it supposed to do?

It is supposed to generate a keybindings documentation like
https://notionwm.net/notion4keys.html , except from your current
configuration, to a random directory in /tmp looking something like
"/tmp/notion.nZd2e/" and then open a browser to view it (with
run-mailcap).

This may not work if you have customized ioncore_misc.lua
or your keybindings in ~/.notion ? Any errors in Notion's output?

> As a test I then moved ~/.notion/default-session--0 and restarted
> notion. It came up with the correct keybindings this time, but the look
> was still broken. It is apparently loading the correct .lua file
> defining the look, but it doesn't work anymore.
> Can somebody please see why it's loading incorrectly? The title bars
> should be yellow, but in the new notion they're coming up black.

Perhaps you need to add the 'based_on' fields as documented in the
migration notes?


Kind regards,

Arnout

Re: [Notion-devel] [Notion-general] Notion 4

[Dima K. <no...@di...>]

Hi.

I just pushed packages targeting Debian/buster (the current stable) into
Debian/experimental. They should now be percolating through the system,
and should become installable on Monday. To build your own copy of the
packages you can do something like this:

  /tmp$ gbp clone https://salsa.debian.org/debian/notion.git

  /tmp$ cd notion

  /tmp/notion$ dpkg-buildpackage -us -uc -b

Broadly, this seems to work. Some notes:

In the debianization I have to tell the build to use the CPPFLAGS from
the environment in addition to the CFLAGS from the environment. Can we
update the notion build system to do that instead?

I'm still building the notion-dev package, as we have for a very long
time. The notion build system doesn't install any .h files, so the
debianization is doing that. Is this thing useful? Any idea if it works?
Any idea how to test it?

The older notion package contained these files, which are no longer
being installed by the build system. Is this correct?

    /usr/share/locale/de/LC_MESSAGES/notion.mo
    /usr/share/locale/fr/LC_MESSAGES/notion.mo
    /usr/share/man/cs/man1/notion.1.gz
    /usr/share/man/fi/man1/notion.1.gz
    /usr/share/notion/welcome.cs.txt
    /usr/share/notion/welcome.fi.txt

After installing the new package on my box, I could run notion, but it
started up in some odd state where the look was different, and most (but
not all) of my bindings didn't work anymore. No error messages. I'm not
sure if it reverted to the default bindings or not; it didn't tell me. I
tried to hit META+/ (window key and the / key) since the migration page
suggests this shows me the current bindings, but this did nothing. What
is it supposed to do?

As a test I then moved ~/.notion/default-session--0 and restarted
notion. It came up with the correct keybindings this time, but the look
was still broken. It is apparently loading the correct .lua file
defining the look, but it doesn't work anymore. This is the look I've
been using for close to 10 years now, so it really should continue to
work. Or it should complain in an obvious way. I'm attaching the look.
Can somebody please see why it's loading incorrectly? The title bars
should be yellow, but in the new notion they're coming up black.

Thanks for all the work!

Re: [Notion-devel] [Notion-general] Notion 4

[Dima K. <no...@di...>]

Oh wow. Thanks so much for doing that! I'll get some Debian packages
ready for testing in the near future, and play with it then.

Thanks!

Re: [Notion-devel] [Notion-general] Notion 4

[Dima K. <no...@di...>]

Oh wow. Thanks so much for doing that! I'll get some Debian packages
ready for testing in the near future, and play with it then.

Thanks!

[Notion-devel] Notion 4

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

Hello,

There are some cool new developments in Notion! We are planning to
release 'Notion 4' now, which has a couple of bigger,
non-backwards-compatible changes.

We have finally managed to drop all of the code that was released
under the Ion license, which was a modified LGPL license. This mean we
will be able to release Notion 4 under the regular LGPL again. It also
means there might be some features that are now missing or bugs that
might re-appear. I think we've covered all the major ones, but do
report it when you find any further regressions.

The other most noticeable change in Notion 4 is a new default set of
keybindings. You can find a schematic at
https://notionwm.net/notion4keys.html . It is possible to switch back
to the Notion 3 keybindings.

Also, mod_statusbar is now no longer enabled by default, but instead
mod_dock is.

You can find a further overview of changes
https://notionwm.net/migration.html . A more detailed overview can be
found at https://github.com/raboof/notion/releases/tag/untagged-cc2e2e2c941f2b361883

Of course I realize the choice of window manager is a highly personal
one, so even if much of the Notion 3 behaviour can be achieved in
Notion 4 as well, not everyone will have a desire to switch. It is
entirely fine to stay on Notion 3 if you prefer.

We have also been updating some infrastructure:
* The code now lives on github, https://github.com/raboof/notion (and
https://github.com/raboof/notion-doc for the docs)
* For discussions around specific features or topics, feel free to use
the GitHub 'Issues'
* We have our own domain at https://notionwm.net/
* Our IRC chat is still #notion on irc.freenode.net

Before we actually release Notion 4, I would warmly welcome you to
check out the code from github and give it a try, taking into account
the migration guide. It would be lovely to get your feedback, either
here or in the form of github issues.


Kind regards,

Arnout

[Notion-devel] animated gif wallpaper

[Wojciech A. <ani...@da...>]

Hi Notion-users,
(it seems I got unsubscribed by some accident, so here's a little post do
test my re-subscribed address.)

So: How would you go about using an animated gif
wallpaper in a floating/empty workspace in Notion? I normally use xsetbg
for wallpapers, but it obviously lacks that functionality.

(I don't necessarily say animated wallpaper is a good idea - on the contrary.
 But it seems a time-worthy  challenge).

Wojtek

-- 
  /^..^\      Wojciech (Wojtek) ANISZEWSKI   ►   Post-doctoral Researcher   
 ( (••) )     [Fr:  vôitek anichévsky]       ►   Sorbonne University       
 (|)_._(|)~   [Eng: voyteck aanishevsky]     ►   Institut ∂'Alembert
  GPG key   ► Web [English]  https://tinyurl.com/y73t4xsg [old! 2015]
ID:AC66485E ►     [Polish ]  https://tinyurl.com/yckark7n [old! 2014]

Re: [Notion-devel] Notion with XFT support

[M. R. <mr...@gm...>]

Looks good here. Converted my main theme.

Rawash

On Wed, Aug 16, 2017 at 2:37 PM, Campbell Barton <ide...@gm...>
wrote:

> Hi, if people like to quickly test, heres a modified theme that uses
> xft (Cantarell font).
>
> https://bitbucket.org/snippets/ideasman42/KA4bR8
>
> On Wed, Aug 16, 2017 at 5:31 AM, Arnout Engelen <no...@bz...> wrote:
> > Hello all,
> >
> > I just merged a contribution by Campbell Barton (ideasman42) adding XFT
> > support to Notion.
> >
> > This is an option that can be disabled at compile time.
> >
> > Unlike previous XFT patches for Notion, even if it is enabled at compile
> > time, as long as you don't use "xft:"-prefixed fonts in your
> configuration
> > all you existing themes should be unaffected and rendered through the
> > non-XFT code path. There should be no surprise anti-aliasing or other
> > functional changes.
> >
> > I'd really like some more people to test this before we roll a release -
> > with display resolutions rising XFT support is a significant feature, and
> > there have been a couple of other nice improvements since the last
> release.
> >
> >
> > Kind regards,
> >
> > Arnout
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Notion-devel mailing list
> > Not...@li...
> > https://lists.sourceforge.net/lists/listinfo/notion-devel
> >
>
>
>
> --
> - Campbell
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
>

Re: [Notion-devel] Notion with XFT support

[Campbell B. <ide...@gm...>]

Hi, if people like to quickly test, heres a modified theme that uses
xft (Cantarell font).

https://bitbucket.org/snippets/ideasman42/KA4bR8

On Wed, Aug 16, 2017 at 5:31 AM, Arnout Engelen <no...@bz...> wrote:
> Hello all,
>
> I just merged a contribution by Campbell Barton (ideasman42) adding XFT
> support to Notion.
>
> This is an option that can be disabled at compile time.
>
> Unlike previous XFT patches for Notion, even if it is enabled at compile
> time, as long as you don't use "xft:"-prefixed fonts in your configuration
> all you existing themes should be unaffected and rendered through the
> non-XFT code path. There should be no surprise anti-aliasing or other
> functional changes.
>
> I'd really like some more people to test this before we roll a release -
> with display resolutions rising XFT support is a significant feature, and
> there have been a couple of other nice improvements since the last release.
>
>
> Kind regards,
>
> Arnout
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
>



-- 
- Campbell

[Notion-devel] Notion with XFT support

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

Hello all,

I just merged a contribution by Campbell Barton (ideasman42) adding XFT
support to Notion.

This is an option that can be disabled at compile time.

Unlike previous XFT patches for Notion, even if it is enabled at compile
time, as long as you don't use "xft:"-prefixed fonts in your configuration
all you existing themes should be unaffected and rendered through the
non-XFT code path. There should be no surprise anti-aliasing or other
functional changes.

I'd really like some more people to test this before we roll a release -
with display resolutions rising XFT support is a significant feature, and
there have been a couple of other nice improvements since the last release.


Kind regards,

Arnout

Re: [Notion-devel] notorious problem building git snapshot

[Wojciech A. <ani...@da...>]

Allright. I guess problem solved so you might want to prevent it from publication on the lists if needed.
Anyhow, goes like this: 'make clean' does not remove previously compiled *.lc precomiled lua chunks from
the build. Thereby we get a mix of lua versions provided that  the user has changed lua version between
notion compilations. It suffices to manually clean *.lc files.

I suggest Makefile be adjusted for that.
Best regards
w

On Mon, Jun 20, 2016 at 06:16:41PM +0200, Wojciech Aniszewski wrote:
> I'm trying to build the 514d7b693408317215603e8e557dad5c05d087a7 commit of notion.
> I have reported the same behaviour in Oct 2015, I believe, however I keep getting
> problems concerning LUA version.
> So far, the make is succesfull, so is make install, but then notion starts with errors
> concerning version mismatch in precompiled chunk:
> 
> >> /usr/local/lib/notion/lc/ioncore_menudb.lc: version mismatch in precompiled chunk
> >> Unable to find 'ioncore_menudb.lc' or 'ioncore_menudb.lua' on search path...
> 
> [followed by 50 lines citing various locations of search]
> 
> I'm lost: readme says I can specify my LUA_VERSION when making, I have lua 5.1, 5.2 and 5.3 coexisting. Apparently one can't just dump 5.1 and 5.2 in Debian, as multiple programs depend on 5.1 at the moment. 
> 
> I have a liblua-dev package only for 5.2, as it seems 5.2.4 is currently used runtime:
> 
> $ lua-v
>   Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> 
> So I guess my simple question is, how on earth does one compile it so that:
> 1. there is no lua version conflict
> 2. menu is bult
> 
> thank you.
> WA
> 
> -- 
> Wojtek Aniszewski
> [Fr:  vôitek anichévsky]
> [Eng: voyteck aanishevsky]
> www: http://www.coria.fr/spip.php?auteur1606
>  /^..^\      ,-------------------------------------,
> ( (••) ) ►►►►| My public GPG key ID: AC66485E      |
> (|)_._(|)~   | please use email encryption!        |
>              `-------------------------------------"

-- 
Wojtek Aniszewski
[Fr:  vôitek anichévsky]
[Eng: voyteck aanishevsky]
www: http://www.coria.fr/spip.php?auteur1606
 /^..^\      ,-------------------------------------,
( (••) ) ►►►►| My public GPG key ID: AC66485E      |
(|)_._(|)~   | please use email encryption!        |
             `-------------------------------------"

[Notion-devel] notorious problem building git snapshot

[Wojciech A. <ani...@da...>]

I'm trying to build the 514d7b693408317215603e8e557dad5c05d087a7 commit of notion.
I have reported the same behaviour in Oct 2015, I believe, however I keep getting
problems concerning LUA version.
So far, the make is succesfull, so is make install, but then notion starts with errors
concerning version mismatch in precompiled chunk:

>> /usr/local/lib/notion/lc/ioncore_menudb.lc: version mismatch in precompiled chunk
>> Unable to find 'ioncore_menudb.lc' or 'ioncore_menudb.lua' on search path...

[followed by 50 lines citing various locations of search]

I'm lost: readme says I can specify my LUA_VERSION when making, I have lua 5.1, 5.2 and 5.3 coexisting. Apparently one can't just dump 5.1 and 5.2 in Debian, as multiple programs depend on 5.1 at the moment. 

I have a liblua-dev package only for 5.2, as it seems 5.2.4 is currently used runtime:

$ lua-v
  Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio

So I guess my simple question is, how on earth does one compile it so that:
1. there is no lua version conflict
2. menu is bult

thank you.
WA

-- 
Wojtek Aniszewski
[Fr:  vôitek anichévsky]
[Eng: voyteck aanishevsky]
www: http://www.coria.fr/spip.php?auteur1606
 /^..^\      ,-------------------------------------,
( (••) ) ►►►►| My public GPG key ID: AC66485E      |
(|)_._(|)~   | please use email encryption!        |
             `-------------------------------------"

Re: [Notion-devel] Add .desktop file for display managers

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

Hello Sergej,

That would be really useful.

I have very limited time to devote to Notion right now - I've added the
suggestion to https://github.com/raboof/notion/issues/11 so we won't lose
track.


Kind regards,

Arnout

On Tue, Aug 11, 2015 at 1:42 PM, Sergej Pupykin <ml...@se...> wrote:

>
> Could you please add attached file into git repo?
>
> 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
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
>
>

[Notion-devel] Add .desktop file for display managers

[Sergej P. <ml...@se...>]

Could you please add attached file into git repo?

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

Re: [Notion-devel] Build error

[Campbell B. <ide...@gm...>]

Ah thanks. I was still on git://git.code.sf.net/p/notion/notion

On Thu, Jul 2, 2015 at 7:34 PM, Arnout Engelen <ar...@bz...> wrote:
> Hi,
>
> Thanks - this should already been fixed in the github master, right?
> (https://github.com/raboof/notion/commit/bf2903a13b6ecd05fb3583ec1fd59d7faa6dd51f)
>
>
> Kind regards,
>
> Arnout
>
> On Thu, Jul 2, 2015 at 11:11 AM, Campbell Barton <ide...@gm...>
> wrote:
>>
>> I'm currently getting a build error, (returning a void as an int)
>>
>> This fixes,
>>
>> http://hastebin.com/imapuromoy.diff
>>
>> I checked and these functions return value was never used anyway.
>>
>> --
>> - Campbell
>>
>>
>> ------------------------------------------------------------------------------
>> Don't Limit Your Business. Reach for the Cloud.
>> GigeNET's Cloud Solutions provide you with the tools and support that
>> you need to offload your IT needs and focus on growing your business.
>> Configured For All Businesses. Start Your Cloud Today.
>> https://www.gigenetcloud.com/
>> _______________________________________________
>> Notion-devel mailing list
>> Not...@li...
>> https://lists.sourceforge.net/lists/listinfo/notion-devel
>
>



-- 
- Campbell

[Notion-devel] Build error

[Campbell B. <ide...@gm...>]

I'm currently getting a build error, (returning a void as an int)

This fixes,

http://hastebin.com/imapuromoy.diff

I checked and these functions return value was never used anyway.

-- 
- Campbell

[Notion-devel] programmatically move & resize scratch window

[Daniel R. <dra...@gm...>]

I frequently switch between using notion on my laptop and using it on the
laptop & 2 extra monitors. There's separate scratch windows for each
monitor, which I like to resize to my taste. The problem is that when I
switch back to just laptop (turn off the montitors), the 2 extra scratch
windows get killed, so that next time I switch back to using the two
monitors, I have to resize the scratch windows again.

I could look into session preservation stuff, but it seems like the easiest
thing would just be to run the resize code programmatically. If it was
possible to have a lua function which said 'move the specified window 10
units to the right' or something, I could make what I want happen.

Unfortunately, this either isn't possible, or I don't know how it works.
The resize-mode functions appear to be bound to being in resize mode in a
way i don't quite understand. I suppose my lua script could enter resize
mode, call the appropriate function, and then exit. Haven't tried this &
don't know if it would work (this is where I left it when I ran out of
time).

If there are existing solutions for doing this (programmatic moving),
Please let me know. I've looked a few places (scripts, the codebase, etc)
but I can't find anything obvious.

Daniel

Re: [Notion-devel] feature request/dev help: "rebasing" queries

[Daniel R. <dra...@gm...>]

Arnout:

Thanks. I knew some of that stuff, but was definitely mystified by
ioncore.clientwin_i, so this is definitely useful.

Since you've foolishly offered to help me, I'll teach you a lesson by
continuing to pester you for more information: I also need to know about
how/where the completion window (WEdln?) does "if the user enters a key in
set S, do something special (e.g. readline stuff), otherwise add it to the
string." I'm guessing the words "bindmap" and "mod_query_wedln_bindmap" are
relevant, but having some trouble finding relevant code sections. Any
pointers you can give me would be greatly appreciated.

Alt approach is interesting, but I basically don't know X programming at
all. I'm not sure if this is a problem. I looked at:

http://standards.freedesktop.org/wm-spec/1.3/ar01s04.html

and it looks like it might be easy enough (just need to figure out how to
send that message; hopefully multiple screen/workspace issues don't
complicate it).

Even so, it'd be nice to be able to use the alt program via the same notion
query interface a la ion-completefile*, so the other question still comes
up. Otherwise I end up messing around with gtk libraries, fielding "Why
doesn't notion handle the rebasing-completion window properly on my
machine?" questions, etc. I'm spending too much of my workday writing you
this email as it is.

*Is that accurate given what query_exec does? I don't entirely understand
that either?

Thanks,
Daniel

PS: I started using the wm back in ion3, and I remember the drama. I notice
that "ion" is still all over the codebase. Are you not worried that Tuomo
will find out where you live? I respect him a lot, but he seems
temperamental.


On Wed, Apr 29, 2015 at 2:14 PM, Arnout Engelen <no...@bz...> wrote:

> Hello Daniel,
>
> Thanks for your interest!
>
> As for navigating the notion codebase, "grep -r "META..\"A" ." would show
> you that this key is generally bound to "mod_query.query_attachclient".
> "grep -r query_attachclient ." would reveal this is implemented in
> mod_query/mod_query.lua.
>
> Diving in there, you'll see the completor is created based on
> mod_query.complete_clientwin, which looks at the names of the elements in
> the collection of client windows (as iterated through by
> ioncore.clientwin_i)
>
> You could look into implementing support for 'rebased queries' there.
>
> An alternative approach might be to add support for _NET_MOVERESIZE_WINDOW
> and write a separate (not necessarily notion-specific) utility to query for
> a window and request it to be moved to the current frame.
>
> Kind regards,
>
> Arnout
>
> On Tue, Apr 28, 2015 at 8:12 PM, Daniel Radetsky <dra...@gm...>
> wrote:
>
>> I started using notion again (awesomewm is awesome, but not awesome
>> enough), and became interested again in impementing a feature I've wanted
>> in notion and other incremental searches for a long time, which I call
>> "rebasing queries." An incremental search query is "rebased" when the input
>> is cleared, but the set of incremental results is retained. The user may
>> now input more chars, searching among remaining results.
>>
>> Ideally would work something like this: I have shit tons of windows open,
>> I want to attach a the chrome window with gmail. I enter `M-a chro` and
>> completion window shows only browser windows. I now enter `M-a` again,
>> which rebases the attach-query (since one is in progress), and then `gmai`
>> and now only the gmail window is selected.
>>
>> I'd implement it myself, but I don't know the notion codebase or lua very
>> well. I might be able to manage it if a more experienced notion developer
>> could give me some pointers. For example, I don't understand how the query
>> set is populated and modified in the first place (I think it's done in the
>> C code, but not even sure about that).
>>
>> Peace Homies,
>> --Daniel
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Notion-devel mailing list
>> Not...@li...
>> https://lists.sourceforge.net/lists/listinfo/notion-devel
>>
>>
>

Re: [Notion-devel] feature request/dev help: "rebasing" queries

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

Hello Daniel,

Thanks for your interest!

As for navigating the notion codebase, "grep -r "META..\"A" ." would show
you that this key is generally bound to "mod_query.query_attachclient".
"grep -r query_attachclient ." would reveal this is implemented in
mod_query/mod_query.lua.

Diving in there, you'll see the completor is created based on
mod_query.complete_clientwin, which looks at the names of the elements in
the collection of client windows (as iterated through by
ioncore.clientwin_i)

You could look into implementing support for 'rebased queries' there.

An alternative approach might be to add support for _NET_MOVERESIZE_WINDOW
and write a separate (not necessarily notion-specific) utility to query for
a window and request it to be moved to the current frame.

Kind regards,

Arnout

On Tue, Apr 28, 2015 at 8:12 PM, Daniel Radetsky <dra...@gm...>
wrote:

> I started using notion again (awesomewm is awesome, but not awesome
> enough), and became interested again in impementing a feature I've wanted
> in notion and other incremental searches for a long time, which I call
> "rebasing queries." An incremental search query is "rebased" when the input
> is cleared, but the set of incremental results is retained. The user may
> now input more chars, searching among remaining results.
>
> Ideally would work something like this: I have shit tons of windows open,
> I want to attach a the chrome window with gmail. I enter `M-a chro` and
> completion window shows only browser windows. I now enter `M-a` again,
> which rebases the attach-query (since one is in progress), and then `gmai`
> and now only the gmail window is selected.
>
> I'd implement it myself, but I don't know the notion codebase or lua very
> well. I might be able to manage it if a more experienced notion developer
> could give me some pointers. For example, I don't understand how the query
> set is populated and modified in the first place (I think it's done in the
> C code, but not even sure about that).
>
> Peace Homies,
> --Daniel
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
>
>

[Notion-devel] feature request/dev help: "rebasing" queries

[Daniel R. <dra...@gm...>]

I started using notion again (awesomewm is awesome, but not awesome
enough), and became interested again in impementing a feature I've wanted
in notion and other incremental searches for a long time, which I call
"rebasing queries." An incremental search query is "rebased" when the input
is cleared, but the set of incremental results is retained. The user may
now input more chars, searching among remaining results.

Ideally would work something like this: I have shit tons of windows open, I
want to attach a the chrome window with gmail. I enter `M-a chro` and
completion window shows only browser windows. I now enter `M-a` again,
which rebases the attach-query (since one is in progress), and then `gmai`
and now only the gmail window is selected.

I'd implement it myself, but I don't know the notion codebase or lua very
well. I might be able to manage it if a more experienced notion developer
could give me some pointers. For example, I don't understand how the query
set is populated and modified in the first place (I think it's done in the
C code, but not even sure about that).

Peace Homies,
--Daniel

Re: [Notion-devel] Some bindmaps were empty, loading ioncore_efbb

[Josef 'J. S. <je...@jo...>]

On Wed, Dec 17, 2014 at 10:04:59AM +0100, Arnout Engelen wrote:
> On Tue, Dec 16, 2014 at 10:38 PM, Josef 'Jeff' Sipek <je...@jo...>
> wrote:
> >
> > > I really want to avoid adding more compile-time switches, things
> > > are too complicated to my taste already.
> > >
> > > a) dropping support for lua5.1
> > > b) not support lua5.2 unless it was compiled with LUA_COMPAT_ALL
> >
> > It does look like Lua 5.1 is getting a bit old, while
> > Lua 5.2 is three years old.  (It looks like 5.3 will be released in the
> > near
> > future.) http://www.lua.org/versions.html
> >
> > Hrm, I'm thinking more about this and I wonder of option (c)
> > makes the most sense given that 5.1 won't be viable forever:
> >
> > c) like (b) but start thinking about the future direction
> >
> 
> When 5.3 comes out we should update notion to work with that, and when
> necessary that could be a good moment to drop support for 5.1.

Fair enough.

> > Then there are of course more radical options:
> >
> > d) replace the existing build system with something more standard
> >    (autotools, or cmake)
>
> I'm not sure how those would help in this case.

You said you didn't want to add another compile time option.  With either
autotools or cmake you can make the "configure" step of the build
auto-detect which version of lua you have and whether or not you have 5.1
compat features available.

> I personally dislike autotools (esp. with all the different incompatible
> versions out there). cmake seems pretty nice, I'd really like to see if
> that could be applied to notion.

Agreed on both points.  FWIW, once upon a time, I tried to cmake-ify notion.
Sadly, I ran out of time then and then never got back to it.  Here's the
latest change I have.  Maybe you'll find it useful. :)

http://repo.or.cz/w/notion/jeffpc.git/commit/4187ec60d46d6a8a62c1abd7202a6a9bc263a7c0

Jeff.

-- 
Linux, n.:
  Generous programmers from around the world all join forces to help
  you shoot yourself in the foot for free. 

Re: [Notion-devel] Some bindmaps were empty, loading ioncore_efbb

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

On Tue, Dec 16, 2014 at 10:38 PM, Josef 'Jeff' Sipek <je...@jo...>
wrote:
>
> > I really want to avoid adding more compile-time switches, things
> > are too complicated to my taste already.
> >
> > a) dropping support for lua5.1
> > b) not support lua5.2 unless it was compiled with LUA_COMPAT_ALL
>
> It does look like Lua 5.1 is getting a bit old, while
> Lua 5.2 is three years old.  (It looks like 5.3 will be released in the
> near
> future.) http://www.lua.org/versions.html
>
> Hrm, I'm thinking more about this and I wonder of option (c)
> makes the most sense given that 5.1 won't be viable forever:
>
> c) like (b) but start thinking about the future direction
>

When 5.3 comes out we should update notion to work with that, and when
necessary that could be a good moment to drop support for 5.1.


> Then there are of course more radical options:
>
> d) replace the existing build system with something more standard
>    (autotools, or cmake)
>
>
I'm not sure how those would help in this case.

I personally dislike autotools (esp. with all the different incompatible
versions
out there). cmake seems pretty nice, I'd really like to see if that could be
applied to notion.


Kind regards,

Arnout