notion-devel — Development discussion about the notion window manager

[Notion-devel] Making it easier to develop notion

[James d. <ja...@hu...>]

First off, hello!

I discovered this project after upgrading to Ubuntu maverick and finding
that ion3 had been dropped from the repository.  I'm excited to see
development continue in a friendly environment.  Thank you!  I have notion
up and running on my maverick system.

However, my experience with compiling and installing notion was painful -- I
needed to checkout 3 different git repositories which somehow depended on
each other (I ended up creating a few symlinks).  I needed to edit Makefile
by hand and finally I needed to create ~/.notion manually.

I would like to fix that process.  Making it easier to get started will
encourage more developers to join the project.

The goal would be to get notion to a point where building and running notion
from source is easy. e.g:

   1. checkout sources (e.g. git clone)
   2. build (e.g. make or maybe `./configure && make`)
   3. run (e.g. `./notion`)

Thoughts?  Comments?

- James.

Re: [Notion-devel] Object inheritance

[<eb...@dr...>]

I like the .super idea for calling immediate ancestor. What is the
situation about other ion3 clones? Because mass renaming would harden
any porting of patches between ion3 clones (if there are any). I'm
not decided between (b) and (c). Maybe (c) is the most readable.

We may also consider to provide macros (with (runtime) checks in
future), similar to how objects are done in glib. This will be the
(a) solution, but wrapped into macros. With the option to implement
the checks later.


On Sat, 9 Apr 2011 17:15:25 +0200
Arnout Engelen <no...@bz...> wrote:
> Hi,
> 
> I think the way inheritence and upcasting are done in Notion is a bit 
> inconsistent and confusing, and would like to propose a change.
> 
> Classes in notion's OO are declared like this:
> 
> DECLCLASS(WScreen){
>     WMPlex mplex;
>     int id;
>     ...
> }
> 
> Basically this introduces a 'WScreen' type, and the first element of
> the struct holding its data is the supertype, in this case 'WMPlex'.
> 
> In code, whenever you have a WScreen* and need a WMPlex, we use
> either casts:
> 
>   mplex_map((WMPlex*)scr);
>   ((WWindow *)(rw->scr))->win=None;
> 
> or look at the first field:
> 
>   mplex_map(&scr->mplex);
>   rw->scr.mplex.win.win=None;
> 
> There are advantages and disadvantages to both calling conventions:
> the former variation has the advantage that it is usually fairly
> short, and it's immediately clear that the called function operates
> on a WMPlex/WWindow. It has the disadvantage that you have to use a
> typecast, which the compiler cannot verify is correct.
> 
> The latter variation has the advantage that it's type-safe. The
> disadvantage is that it is not immediately clear whether scr 'is an
> mplex' or 'has an mplex'. The second example makes this extra clear:
> the mplex 'is a' win which 'has a' win.
> 
> To mitigate the latter, I think it'd be neat to adopt the convention
> to always call the first field 'super'. This will lead to:
> 
>   mplex_map(&scr->super);
>   rw->scr.super.super.win=None;
> 
> The way I look at it now, we should pick one of the following
> conventions:
> 
> (a) always use typecasts, never use the first field of the struct
> explicitly (b) always use the first field of the struct
> (c) use the first field of the struct if we need the direct parent,
> use a typecast when you need to go higher up the hierarchy.
> 
> in cases 'b' and 'c', we should decide whether to rename the first
> field to 'super'.
> 
> What would you guys prefer? 
> 
> I'm still undecided - imho either of those choices is better than the
> current inconsistency though ;)
> 
> 
> Kind regards,
> 
> Arnout


-- 
                                 Tomáš 'ebík' Ebenlendr
                                 PF 2011.27372038305

Re: [Notion-devel] Multihead: mod_xinerama and 'mirrored' multihead

[<eb...@dr...>]

Hi,

I have two (small) objections:

First, it is not in Lua. This is not so bad for users, but it is bad for
further developing, as further patches may want to improve this branch,
and I consider this branch 'dead', because we want this in Lua.

The second objection is, that the algorithm does not merge screen B
to screen A,C in following setup:
+--------+      +---------+
| A  +---+------+---+  B  |
|    |   |      |   |     |
+----+---+  C   +---+-----+
     +--------------+
It first puts into the result screens 'A' and 'B', and then it decides
that it merges 'C' with 'A'. This behavior is rather unexpectable
for the user.

I split the query and setup part, to be callable from lua. Although
the setup part has to be called in cfg_xinerama.lua, otherwise is
called setup with default (merge overlapping) behavior. I reimplemented
the merge of overlapping screens in Lua, so that it merges all screens
that overlap and it does not merge screens that do not overlap:
+------+ +---+
| A    | | C |
|      | +---+
|    +-+----+
+----+-+ B  |
     +------+
Here 'C' is considered after merging 'A' with 'B', my algorithm does
not merge it, yours do.
Both setups are strange, but user should get expectable behavior.

My version is in branch 'split' at
http://drak.ucw.cz/~ebik/git/mod_xinerama
It is poorly documented now. I have not explored how external modules
can and should be documented.

The user can call
ioncore.set_paths("some_string_derived_from_the_geometry_of_screens"),
to have his 'saved_layout.lua' saved in different directory, based on
what he do in cfg_xinerama.lua. This lets the user to have layouts
saved for different screen configurations. Doint this has a caveat
now: notion does not remember locations of windows when screen setup
is changed an notion restarted to different screen layout.



On Sat, 9 Apr 2011 11:39:52 +0200
Arnout Engelen <no...@bz...> wrote:
> Hi,
> 
> mod_xinerama currently did not support 'mirrored mode' multihead
> (xrandr --same-as) correctly: it created 2 WScreens (1 for each
> monitor, even when both monitors took up exactly the same space on
> the virtual display).
> 
> Apart from being generally inelegant and wrong, it also caused some
> trouble when an embedded dock would be assigned to the invisible
> WScreen etc.
> 
> I created a patch for mod_xinerama that will merge any overlapping
> Xinerama screens into 1 notion WScreen, solving this problem. I
> committed it to an 'overlap' branch, and would be interested to get
> your reviews before merging it to master.
> 
> Git:
> http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/mod_xinerama;a=shortlog;h=refs/heads/overlap
> Issuetracker:
> https://sourceforge.net/tracker/index.php?func=detail&aid=3262747&group_id=314802&atid=1324528#
> 
> 
> Kind regards,
> 
> Arnout

-- 
                                 Tomáš 'ebík' Ebenlendr
                                 PF 2011.27366273465

[Notion-devel] Object inheritance

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

Hi,

I think the way inheritence and upcasting are done in Notion is a bit 
inconsistent and confusing, and would like to propose a change.

Classes in notion's OO are declared like this:

DECLCLASS(WScreen){
    WMPlex mplex;
    int id;
    ...
}

Basically this introduces a 'WScreen' type, and the first element of the 
struct holding its data is the supertype, in this case 'WMPlex'.

In code, whenever you have a WScreen* and need a WMPlex, we use either casts:

  mplex_map((WMPlex*)scr);
  ((WWindow *)(rw->scr))->win=None;

or look at the first field:

  mplex_map(&scr->mplex);
  rw->scr.mplex.win.win=None;

There are advantages and disadvantages to both calling conventions: the former
variation has the advantage that it is usually fairly short, and it's 
immediately clear that the called function operates on a WMPlex/WWindow. It 
has the disadvantage that you have to use a typecast, which the compiler 
cannot verify is correct.

The latter variation has the advantage that it's type-safe. The disadvantage is
that it is not immediately clear whether scr 'is an mplex' or 'has an mplex'. 
The second example makes this extra clear: the mplex 'is a' win which 'has a' 
win.

To mitigate the latter, I think it'd be neat to adopt the convention to always
call the first field 'super'. This will lead to:

  mplex_map(&scr->super);
  rw->scr.super.super.win=None;

The way I look at it now, we should pick one of the following conventions:

(a) always use typecasts, never use the first field of the struct explicitly
(b) always use the first field of the struct
(c) use the first field of the struct if we need the direct parent, use a 
  typecast when you need to go higher up the hierarchy.

in cases 'b' and 'c', we should decide whether to rename the first field to 
'super'.

What would you guys prefer? 

I'm still undecided - imho either of those choices is better than the current 
inconsistency though ;)


Kind regards,

Arnout

Re: [Notion-devel] Multihead expectations

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

Hi,

Thanks to some research by Tomas in https://sourceforge.net/tracker/?func=detail&aid=3262753&group_id=314802&atid=1324528
I found out about the 'primary' concept in RandR 1.3.

This seems to be a useful concept to piggyback on: the 'primary' screen 
should always hold the same WScreen. This gives the user some control over 
whether to swap WScreens: if he wants the WScreen to move to another monitor,
he can simply make that other monitor 'primary'.

This has the added advantage that the information which screen is 'primary' 
is also exposed through the Xinerama interface. To allow some graceful 
degredation, we should try and use the Xinerama API as much as possible for
the multihead code: RandR will continue to expose its information through this
interface.


Arnout

On Fri, Apr 01, 2011 at 01:01:13AM +0200, Arnout Engelen wrote:
> On Fri, Apr 01, 2011 at 12:12:13AM +0200, Javier Rojas wrote:
> > On Thu, Mar 31, 2011 at 11:27:37PM +0200, Arnout Engelen wrote:
> > > - When WScreen 1 is on monitor A and WScreen 2 is on monitor B, and the
> > >   relative locations are changed (monitor A moves from being left of monitor B
> > >   to being right of monitor B), what should happen?
> > > 
> > > The latter is not an obvious choice, I think it would make sense to keep 
> > > WScreen 1 on monitor A and WScreen 2 on monitor B. This way it's really just
> > > the relative locations that change and not the contents of the windows. As an
> > > additional plus, the WScreens don't have to be resized as long as the monitors
> > > don't switch resolutions.
> > 
> > Thw WScreens should be swapped. Otherwise the relative location change
> > would go unnoticed by the user (who either caused that change on purpose
> > and expects the screens to swap
> 
> It would not go unnoticed: the mouse pointer would be moved from monitor A to 
> monitor B by moving it off the other edge of monitor A.
> 
> I think you change the relative locations of screens when their physical 
> relative locations change. In that case it does make sense to keep windows 
> that were on physical screen A on physical screen A.
> 
> > or got that screen swap unvoluntarily and should be notified), 
> 
> Does that ever happen in reality?
> 
> > and stuff like mappings to change screen would get its semantics reversed.
> 
> I'm not sure what you mean here?
> 
> 
> Arnout
> 
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself; 
> WebMatrix provides all the features you need to develop and 
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel

[Notion-devel] Multihead: mod_xinerama and 'mirrored' multihead

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

Hi,

mod_xinerama currently did not support 'mirrored mode' multihead (xrandr 
--same-as) correctly: it created 2 WScreens (1 for each monitor, even when
both monitors took up exactly the same space on the virtual display).

Apart from being generally inelegant and wrong, it also caused some trouble
when an embedded dock would be assigned to the invisible WScreen etc.

I created a patch for mod_xinerama that will merge any overlapping Xinerama
screens into 1 notion WScreen, solving this problem. I committed it to an
'overlap' branch, and would be interested to get your reviews before merging
it to master.

Git: http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/mod_xinerama;a=shortlog;h=refs/heads/overlap
Issuetracker: https://sourceforge.net/tracker/index.php?func=detail&aid=3262747&group_id=314802&atid=1324528#


Kind regards,

Arnout

Re: [Notion-devel] Multihead expectations

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

On Fri, Apr 01, 2011 at 12:12:13AM +0200, Javier Rojas wrote:
> On Thu, Mar 31, 2011 at 11:27:37PM +0200, Arnout Engelen wrote:
> > - When WScreen 1 is on monitor A and WScreen 2 is on monitor B, and the
> >   relative locations are changed (monitor A moves from being left of monitor B
> >   to being right of monitor B), what should happen?
> > 
> > The latter is not an obvious choice, I think it would make sense to keep 
> > WScreen 1 on monitor A and WScreen 2 on monitor B. This way it's really just
> > the relative locations that change and not the contents of the windows. As an
> > additional plus, the WScreens don't have to be resized as long as the monitors
> > don't switch resolutions.
> 
> Thw WScreens should be swapped. Otherwise the relative location change
> would go unnoticed by the user (who either caused that change on purpose
> and expects the screens to swap

It would not go unnoticed: the mouse pointer would be moved from monitor A to 
monitor B by moving it off the other edge of monitor A.

I think you change the relative locations of screens when their physical 
relative locations change. In that case it does make sense to keep windows 
that were on physical screen A on physical screen A.

> or got that screen swap unvoluntarily and should be notified), 

Does that ever happen in reality?

> and stuff like mappings to change screen would get its semantics reversed.

I'm not sure what you mean here?


Arnout

Re: [Notion-devel] Multihead expectations

[Javier R. <jer...@de...>]

On Thu, Mar 31, 2011 at 11:27:37PM +0200, Arnout Engelen wrote:
> Hi,
> 
> How would we expect multihead to work?
> 
> - When WScreen 1 is on monitor A and WScreen 2 is on monitor B, and the
>   relative locations are changed (monitor A moves from being left of monitor B
>   to being right of monitor B), what should happen?
> 
> The latter is not an obvious choice, I think it would make sense to keep 
> WScreen 1 on monitor A and WScreen 2 on monitor B. This way it's really just
> the relative locations that change and not the contents of the windows. As an
> additional plus, the WScreens don't have to be resized as long as the monitors
> don't switch resolutions.

Thw WScreens should be swapped. Otherwise the relative location change
would go unnoticed by the user (who either caused that change on purpose
and expects the screens to swap, or got that screen swap unvoluntarily
and should be notified), and stuff like mappings to change screen would
get its semantics reversed.

> What do you think?

^^^^

:D

-- 
Javier Rojas

[Notion-devel] Multihead expectations

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

Hi,

How would we expect multihead to work?

A proposal as a starting point:

- When multiple monitors are found, one WScreen is created for each 
  non-'mirrored' monitor.

- When 2 monitors are acting in 'mirrored' mode (i.e. showing the same 
  contents), 1 WScreen is created to cater to them both. When they have
  different resolutions, the WScreen is as high as the highest monitor and
  as wide as the widest monitor.

- When WScreen 1 is on monitor A and WScreen 2 is on monitor B, and the
  relative locations are changed (monitor A moves from being left of monitor B
  to being right of monitor B), what should happen?

The latter is not an obvious choice, I think it would make sense to keep 
WScreen 1 on monitor A and WScreen 2 on monitor B. This way it's really just
the relative locations that change and not the contents of the windows. As an
additional plus, the WScreens don't have to be resized as long as the monitors
don't switch resolutions.

What do you think?


Kind regards,

Arnout

Re: [Notion-devel] sf.net: default support mechanism, forums?

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

I agree. I disabled the forums functionality for now. We could re-open 'Open 
discussion' to allow end-user support in the future, but right now the 
mailinglists should suffice.


Kind regards,

Arnout

On Thu, Mar 31, 2011 at 03:10:38PM -0400, Etan Reisner wrote:
> Apologies for the rather delayed response.
> 
> Personally I hate forums. I especially hate SF's forums.
> 
> Even if a forum is desirable I certainly think having three is going to be
> overkill for a project like notion.
> 
>     -Etan

Re: [Notion-devel] sf.net: default support mechanism, forums?

[Etan R. <de...@un...>]

Apologies for the rather delayed response.

Personally I hate forums. I especially hate SF's forums.

Even if a forum is desirable I certainly think having three is going to be
overkill for a project like notion.

    -Etan

Re: [Notion-devel] Releasing source snapshots

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

Hi,

Unless anyone objects, I think I can make myself 'release technician' on 
sf.net and put up a source tarball release myself.


Arnout

On Sat, Feb 19, 2011 at 04:55:40PM +0100, Arnout Engelen wrote:
> I fixed up the predist.sh script which creates an all-in-one source package
> for notion including libextl and libtu. Run it as './predist.sh -snapshot' to
> create a snapshot package.
> 
> It might be nice to publish a source snapshot to the sf.net 'files' section.
> Looks like only mrawash, timandahaf and fr31g31st can do that, though.
> 
> Next step, apart from ongoing development and bugfixing, would be to add the
> scripts collection to the repo's, and make sure our releases come with good
> default settings, kludges and plugins enabled. This should ensure pleasant
> out-of-the-box behavior for new users.
> 
> 
> Arnout
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel

Re: [Notion-devel] Overriding a dialog's location/size when mapped

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

On Sat, Mar 05, 2011 at 01:47:41AM +0100, Arnout Engelen wrote:
> On Sat, Feb 19, 2011 at 04:41:28AM +0100, Arnout Engelen wrote:
> > Some applications show dialogs that are incorrectly placed - they might even 
> > position them off-screen.
> 
> immediately after mapping the dialog, it would be moved again with a 
> XConfigureRequestEvent. This XConfigureRequestEvent changes the window 
> location (flags CWX and CWY) but not the dimensions (flags CWWidth and 
> CWHeight).
> 
> check_normal_cfgrq() in ioncore/clientwin.c interprets this as the new x/y
> coordinates being 'hard' and the current height/width being 'weak' suggestions.
> 
> In this particular case, because the x coordinate is too high, moving the 
> dialog off-screen, and the width was considered 'weak', the width got reduced 
> to '0'.
> 
> I'd say we should take into account the dimensions even when only the location
> is being specified. 

After some discussion on IRC we decided it would be good to, apart from taking
into account the width and height to prevent the dialog from getting 
'squashed', to ignore the value entirely when it is out-of-bounds.

http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=0cd1e04960312d5c1c1a28efe5bc9f3453e33de2


Kind regards,

Arnout

> 
> diff --git a/ioncore/clientwin.c b/ioncore/clientwin.c
> index 9ec1b68..27bd85e 100644
> --- a/ioncore/clientwin.c
> +++ b/ioncore/clientwin.c
> @@ -1231,10 +1231,12 @@ static bool check_normal_cfgrq(WClientWin *cwin, XConfigureRequestEvent *ev)
>          if(ev->value_mask&CWX){
>              rq.geom.x=ev->x+gdx;
>              rq.flags&=~REGION_RQGEOM_WEAK_X;
> +            rq.flags&=~REGION_RQGEOM_WEAK_W;
>          }
>          if(ev->value_mask&CWY){
>              rq.geom.y=ev->y+gdy;
>              rq.flags&=~REGION_RQGEOM_WEAK_Y;
> +            rq.flags&=~REGION_RQGEOM_WEAK_H;
>          }
> 
>          region_rqgeom((WRegion*)cwin, &rq, NULL);
> 
> 
> This seems to make sense and indeed it fixes the problems I previously 
> encountered with applications misplacing their dialogs. I haven't noticed any 
> negative side-effects yet.
> 
> I'd appreciate it if anyone could comment/review/test ;).
> 
> 
> Kind regards,
> 
> Arnout
> 
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel

Re: [Notion-devel] Releasing source snapshots

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

On Sat, Feb 19, 2011 at 04:55:40PM +0100, Arnout Engelen wrote:
> It might be nice to publish a source snapshot to the sf.net 'files' section.
> Looks like only mrawash, timandahaf and fr31g31st can do that, though.

Ping! :). Any thoughts?


Arnout

Re: [Notion-devel] LaTeX source of Notion docs

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

On Thu, Mar 03, 2011 at 01:08:27PM +0100, Arnout Engelen wrote:
> I guess we should have a commithook or somesuch somewhere that regenerates
> and uploads the docs when they're updated, and the documents should contain
> a 'get the latest version of this document here'-link to the site and git 
> repo.

Done: the docs are now regenerated and uploaded daily, and I added a short
fragment pointing to the site and git repo.


Arnout

Re: [Notion-devel] Overriding a dialog's location/size when mapped

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

On Sat, Feb 19, 2011 at 04:41:28AM +0100, Arnout Engelen wrote:
> Some applications show dialogs that are incorrectly placed - they might even 
> position them off-screen.
> 
> To move around transient popups, modifying the 'attrs' (for example at 
> ioncore/clientwin.c:543) will affect where the window shows up.
> 
> For 'non-transient dialogs', however, this does not appear to affect the 
> window location 

I was somewhat off-the-mark here: changing the 'attrs' for these popups does 
effect them.

In this particular case, however, immediately after mapping the dialog, it 
would be moved again with a XConfigureRequestEvent. This XConfigureRequestEvent
changes the window location (flags CWX and CWY) but not the dimensions
(flags CWWidth and CWHeight).

check_normal_cfgrq() in ioncore/clientwin.c interprets this as the new x/y
coordinates being 'hard' and the current height/width being 'weak' suggestions.

In this particular case, because the x coordinate is too high, moving the 
dialog off-screen, and the width was considered 'weak', the width got reduced 
to '0'.

I'd say we should take into account the dimensions even when only the location
is being specified. The following patch does that:

diff --git a/ioncore/clientwin.c b/ioncore/clientwin.c
index 9ec1b68..27bd85e 100644
--- a/ioncore/clientwin.c
+++ b/ioncore/clientwin.c
@@ -1231,10 +1231,12 @@ static bool check_normal_cfgrq(WClientWin *cwin, XConfigureRequestEvent *ev)
         if(ev->value_mask&CWX){
             rq.geom.x=ev->x+gdx;
             rq.flags&=~REGION_RQGEOM_WEAK_X;
+            rq.flags&=~REGION_RQGEOM_WEAK_W;
         }
         if(ev->value_mask&CWY){
             rq.geom.y=ev->y+gdy;
             rq.flags&=~REGION_RQGEOM_WEAK_Y;
+            rq.flags&=~REGION_RQGEOM_WEAK_H;
         }

         region_rqgeom((WRegion*)cwin, &rq, NULL);


This seems to make sense and indeed it fixes the problems I previously 
encountered with applications misplacing their dialogs. I haven't noticed any 
negative side-effects yet.

I'd appreciate it if anyone could comment/review/test ;).


Kind regards,

Arnout

Re: [Notion-devel] LaTeX source of Notion docs

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

On Thu, Mar 03, 2011 at 11:50:34AM +0100, Holger Weiß wrote:
> I'm looking for the LaTeX source and/or a PDF version of "Configuring
> and extending Notion with Lua".  I searched the Git repository, the
> SourceForge site, and the list archives, but I cannot seem to find it.
> Is it available somewhere?

Certainly: the tex sources are in their own sf.net git repo at 
http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion-doc;a=tree

I guess we should have a commithook or somesuch somewhere that regenerates
and uploads the docs when they're updated, and the documents should contain
a 'get the latest version of this document here'-link to the site and git 
repo.


Kind regards,

Arnotu 

[Notion-devel] sf.net: default support mechanism, forums?

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

Hi,

I've set the 'Preferred Support Mechanism' for Notion to 'Mailing List: 
notion-general'. 

Given the limited activity so far, does it really make sense to have both 
mailing lists and forums? Perhaps we should remove the forums - or at least 
have 1 instead of 3 of them.

What do you think?


Kind regards,

Arnout

[Notion-devel] Releasing source snapshots

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

Hi,

I fixed up the predist.sh script which creates an all-in-one source package
for notion including libextl and libtu. Run it as './predist.sh -snapshot' to
create a snapshot package.

It might be nice to publish a source snapshot to the sf.net 'files' section.
Looks like only mrawash, timandahaf and fr31g31st can do that, though.

Next step, apart from ongoing development and bugfixing, would be to add the
scripts collection to the repo's, and make sure our releases come with good
default settings, kludges and plugins enabled. This should ensure pleasant
out-of-the-box behavior for new users.


Arnout

[Notion-devel] Overriding a dialog's location/size when mapped

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

Hi,

Some applications show dialogs that are incorrectly placed - they might even 
position them off-screen.

To move around transient popups, modifying the 'attrs' (for example at 
ioncore/clientwin.c:543) will affect where the window shows up.

For 'non-transient dialogs', however, this does not appear to affect the 
window location - I hope I'm getting the terminology right here: I mean a 
dialog without its own titlebar whose location is constrained to be in its 
parents' frame (but which can be moved freely within the frame). 

An example program exhibiting the problem is attached - run it with 
'java MisplacedDialogContainer2' (java 1.6). The popup is shown too far to 
the right and/or too far to the bottom when the container frame is not in the 
top-left frame of the screen.

What would be the proper way to influence where this dialog is placed when 
mapped?


Kind regards,

Arnout

Re: [Notion-devel] Lazily resizing

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

On Sun, Feb 13, 2011 at 11:16:08PM +0100, Arnout Engelen wrote:
> I gave it a shot, patch attached. The winprop is called 'lazy_resize', so for
> example:
> 
> defwinprop{
>         class = "VirtualBox",
>         lazy_resize = true
> }
> 
> Because the client windows may not be a direct child of the mplex (at least
> it looks like there's usually a WGroupCW in between), it seemed like a 
> reasonable idea to move that logic to clientwin_fitrep instead.
> 
> To seperate resizing and reparenting a bit more neatly, I moved the
> 
>   REGION_GEOM(cwin)=geom
> 
> assignment to happen after reparenting instead of before.
> 
> This seems to work beautifully here - but I'd be glad if you guys could test
> and review the changes a bit. 

Patches committed (and documented).


Arnout

Re: [Notion-devel] git monitoring infrastructure

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

On Fri, Jan 28, 2011 at 12:55:18PM +0100, Arnout Engelen wrote:
> On Thu, Jan 27, 2011 at 04:37:08PM -0600, kevin granade wrote:
> > Perhaps patches should go to the mailing list regardless so that potential 
> > reviewers can look them over as time is available. 
> 
> A (seperate) 'notion-commits' mailinglists would be nice. 

It's now all set up:

  https://lists.sourceforge.net/lists/listinfo/notion-commits


Kind regards,

Arnout

Re: [Notion-devel] [PATCH] Document frame_propor_tab_min_w.

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

Pushed, thanks!

On Fri, Feb 18, 2011 at 01:36:46AM +0100, eb...@dr... wrote:
> I rewrited history in my repository, thus there is only the corrected
> patch. This is principially the same as if I did another branch with
> corrected patch. Thus if somebody already checked out branch
> master of my notion-doc repository, then he has to delete it. And
> checkout again.
> 
> I append the new patch here, there have been enough mails because of
> few lines of documentation.
> 
> diff --git a/de.tex b/de.tex
> index bdc6d5f..634c550 100644
> --- a/de.tex
> +++ b/de.tex
> @@ -404,12 +404,18 @@ engine configuration file.
>          long as no other tab has to be truncated in the case of the 
>          \codestr{proportional} or \codestr{elastic} algorithm. Also
> minimum size of a tab in shaped frame (for all algorithms). \\
> -\code{floatframe_tab_min_w} & Minimum tab width in pixels for
> -        the shaped style, given that this number times number of tabs
> -        doesn't exceed frame width. \\
> +\code{floatframe_tab_min_w} & Alias for \code{frame_tab_min_w}.
> +       This is an old name of the variable from times when the only
> algorithm
> +       was \codestr{equal}. \\
> +\code{frame_propor_tab_min_w} & Absolute minimum size of an elastic or
> +       proportional tab, \codestr{elastic} and \codestr{proportional}
> +        algorithms truncate other tabs rather than shortening a short
> +       tab below this size. \\
>  \code{floatframe_bar_max_w_q} & Maximum tab-bar width quotient of
>         frame width for the shaped styles. A number in the 
> -       interval $(0, 1]$.
> +       interval $(0, 1]$. This quotient is maintained even if
> +       the tabs have to be smaller than \code{frame_tab_min_w}
> +       or \code{frame_propor_tab_min_w} to fit.
>  \end{tabularx}
> 
> On Fri, 18 Feb 2011 01:11:46 +0100
> Arnout Engelen <no...@bz...> wrote:
> > On Fri, Feb 18, 2011 at 12:09:47AM +0100, Tomáš Ebenlendr wrote:
> > > +	interval $(0, 1]$. This quotient is maintained even if
> > > +	the tabs has to be smaller than \code{frame_tab_min_w}
> > > +	or \code{frame_propor_tab_min_w} to fit.
> > 
> > I guess this should be 'the tabs have to be smaller than'.
> > 
> > If you fix this can I pull this addition as one complete 'fixed'
> > commit into the notion repo? Or is this tricky to do in git?
> > 
> > 
> > Arnout
> > 
> 
> 
> -- 
>                                  Tomáš 'ebík' Ebenlendr
>                                  PF 2011.13167687722
> 

Re: [Notion-devel] [PATCH] Document frame_propor_tab_min_w.

[<eb...@dr...>]

I rewrited history in my repository, thus there is only the corrected
patch. This is principially the same as if I did another branch with
corrected patch. Thus if somebody already checked out branch
master of my notion-doc repository, then he has to delete it. And
checkout again.

I append the new patch here, there have been enough mails because of
few lines of documentation.

diff --git a/de.tex b/de.tex
index bdc6d5f..634c550 100644
--- a/de.tex
+++ b/de.tex
@@ -404,12 +404,18 @@ engine configuration file.
         long as no other tab has to be truncated in the case of the 
         \codestr{proportional} or \codestr{elastic} algorithm. Also
minimum size of a tab in shaped frame (for all algorithms). \\
-\code{floatframe_tab_min_w} & Minimum tab width in pixels for
-        the shaped style, given that this number times number of tabs
-        doesn't exceed frame width. \\
+\code{floatframe_tab_min_w} & Alias for \code{frame_tab_min_w}.
+       This is an old name of the variable from times when the only
algorithm
+       was \codestr{equal}. \\
+\code{frame_propor_tab_min_w} & Absolute minimum size of an elastic or
+       proportional tab, \codestr{elastic} and \codestr{proportional}
+        algorithms truncate other tabs rather than shortening a short
+       tab below this size. \\
 \code{floatframe_bar_max_w_q} & Maximum tab-bar width quotient of
        frame width for the shaped styles. A number in the 
-       interval $(0, 1]$.
+       interval $(0, 1]$. This quotient is maintained even if
+       the tabs have to be smaller than \code{frame_tab_min_w}
+       or \code{frame_propor_tab_min_w} to fit.
 \end{tabularx}

On Fri, 18 Feb 2011 01:11:46 +0100
Arnout Engelen <no...@bz...> wrote:
> On Fri, Feb 18, 2011 at 12:09:47AM +0100, Tomáš Ebenlendr wrote:
> > +	interval $(0, 1]$. This quotient is maintained even if
> > +	the tabs has to be smaller than \code{frame_tab_min_w}
> > +	or \code{frame_propor_tab_min_w} to fit.
> 
> I guess this should be 'the tabs have to be smaller than'.
> 
> If you fix this can I pull this addition as one complete 'fixed'
> commit into the notion repo? Or is this tricky to do in git?
> 
> 
> Arnout
> 


-- 
                                 Tomáš 'ebík' Ebenlendr
                                 PF 2011.13167687722

Re: [Notion-devel] [PATCH] Document frame_propor_tab_min_w.

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

On Fri, Feb 18, 2011 at 12:09:47AM +0100, Tomáš Ebenlendr wrote:
> +	interval $(0, 1]$. This quotient is maintained even if
> +	the tabs has to be smaller than \code{frame_tab_min_w}
> +	or \code{frame_propor_tab_min_w} to fit.

I guess this should be 'the tabs have to be smaller than'.

If you fix this can I pull this addition as one complete 'fixed' commit into 
the notion repo? Or is this tricky to do in git?


Arnout