notion-devel — Development discussion about the notion window manager

[Notion-devel] [PATCH 1/4] More readable tab width calculation code.

[Tomáš E. <eb...@dr...>]

From: Tomáš Ebenlendr <eb...@uc...>

Only code cosmetics.
---
 ioncore/frame-draw.c |   16 +++++++---------
 1 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/ioncore/frame-draw.c b/ioncore/frame-draw.c
index 7e404c0..086304c 100644
--- a/ioncore/frame-draw.c
+++ b/ioncore/frame-draw.c
@@ -229,10 +229,10 @@ void frame_clear_shape(WFrame *frame)
 
 static void frame_shaped_recalc_bar_size(WFrame *frame, bool complete)
 {
-    int bar_w=0, textw=0, tmaxw=frame->tab_min_w, tmp=0;
+    int bar_w, textw=0, tmaxw=frame->tab_min_w, tmp=0;
     WLListIterTmp itmp;
     WRegion *sub;
-    const char *p;
+    const char *displayname;
     GrBorderWidths bdw;
     char *title;
     uint bdtotal;
@@ -242,6 +242,7 @@ static void frame_shaped_recalc_bar_size(WFrame *frame, bool complete)
         return;
     
     m=FRAME_MCOUNT(frame);
+    bar_w=frame->bar_max_width_q*REGION_GEOM(frame).w;
     
     if(m>0){
         grbrush_get_border_widths(frame->bar_brush, &bdw);
@@ -249,17 +250,16 @@ static void frame_shaped_recalc_bar_size(WFrame *frame, bool complete)
                  +bdw.right+bdw.left);
 
         FRAME_MX_FOR_ALL(sub, frame, itmp){
-            p=region_displayname(sub);
-            if(p==NULL)
+            displayname=region_displayname(sub);
+            if(displayname==NULL)
                 continue;
             
             textw=grbrush_get_text_width(frame->bar_brush,
-                                         p, strlen(p));
+                                         displayname, strlen(displayname));
             if(textw>tmaxw)
                 tmaxw=textw;
         }
 
-        bar_w=frame->bar_max_width_q*REGION_GEOM(frame).w;
         if(bar_w<frame->tab_min_w && 
            REGION_GEOM(frame).w>frame->tab_min_w)
             bar_w=frame->tab_min_w;
@@ -276,9 +276,7 @@ static void frame_shaped_recalc_bar_size(WFrame *frame, bool complete)
             /* Some labels must be truncated */
         }
     }else{
-        bar_w=frame->tab_min_w;
-        if(bar_w>frame->bar_max_width_q*REGION_GEOM(frame).w)
-            bar_w=frame->bar_max_width_q*REGION_GEOM(frame).w;
+        if(bar_w<frame->tab_min_w) bar_w=frame->tab_min_w;
     }
 
     if(complete || frame->bar_w!=bar_w){
-- 
1.7.1

[Notion-devel] [PATCH] Add StringFunPtrMap.

[Tomáš E. <eb...@dr...>]

From: Tomáš Ebenlendr <eb...@uc...>

This patch is already committed in http://drak.ucw.cz/~ebik/git/libtu
This patch is used by my reimplementation of proportional/elastic
tab sizes algorithm.
---------------------------------------------------------------------

Adds map between function pointers and strings. This should allow
named alternative implementation of a function.
---
 map.c |   36 ++++++++++++++++++++++++++++++++++++
 map.h |   27 +++++++++++++++++++++++++++
 2 files changed, 63 insertions(+), 0 deletions(-)

diff --git a/map.c b/map.c
index 7e5f202..98f0dd6 100644
--- a/map.c
+++ b/map.c
@@ -45,3 +45,39 @@ const char *stringintmap_key(const StringIntMap *map, int value,
     return dflt;
     
 }
+
+
+
+int stringfunptrmap_ndx(const StringFunPtrMap *map, const char *str)
+{
+    int i;
+    
+    for(i=0; map[i].string!=NULL; i++){
+        if(strcmp(str, map[i].string)==0)
+            return i;
+    }
+    
+    return -1;
+}
+
+
+FunPtr stringfunptrmap_value(const StringFunPtrMap *map, const char *str, FunPtr dflt)
+{
+    int i=stringfunptrmap_ndx(map, str);
+    return (i==-1 ? dflt : map[i].value); 
+}
+
+
+const char *stringfunptrmap_key(const StringFunPtrMap *map, FunPtr value, 
+                             const char *dflt)
+{
+    int i;
+    
+    for(i=0; map[i].string!=NULL; ++i){
+        if(map[i].value==value){
+            return map[i].string;
+        }
+    }
+    
+    return dflt;
+}
diff --git a/map.h b/map.h
index d66ae74..3a0db39 100644
--- a/map.h
+++ b/map.h
@@ -24,4 +24,31 @@ extern int stringintmap_value(const StringIntMap *map, const char *str,
 extern const char *stringintmap_key(const StringIntMap *map, 
                                     int value, const char *dflt);
 
+
+
+typedef void (*FunPtr)(void);
+
+#define DECLFUNPTRMAP(NAME) \
+typedef struct _String##NAME##Map{\
+    const char *string;\
+    NAME value;\
+} String##NAME##Map
+
+DECLFUNPTRMAP(FunPtr);
+
+#define END_STRINGPTRMAP {NULL, NULL}
+
+/* Return the index of str in map or -1 if not found. */
+extern int stringfunptrmap_ndx(const StringFunPtrMap *map, const char *str);
+extern FunPtr stringfunptrmap_value(const StringFunPtrMap *map, const char *str,
+                              FunPtr dflt);
+extern const char *stringfunptrmap_key(const StringFunPtrMap *map, 
+                                    FunPtr value, const char *dflt);
+
+
+#define STRINGFUNPTRMAP_NDX(MAP,STR) stringfunptrmap_ndx((StringFunPtrMap *)MAP, STR)
+#define STRINGFUNPTRMAP_VALUE(TYPE,MAP,STR,DFLT) (TYPE)stringfunptrmap_value((StringFunPtrMap *)MAP, STR, (FunPtr)DFLT)
+#define STRINGFUNPTRMAP_KEY(MAP,VALUE,DFLT) stringfunptrmap_key((StringFunPtrMap *)MAP, (FunPtr)VALUE, DFLT)
+
+
 #endif /* LIBTU_MAP_H */
-- 
1.7.1

Re: [Notion-devel] git monitoring infrastructure

[kevin g. <kev...@gm...>]

On Fri, Jan 28, 2011 at 5:55 AM, Arnout Engelen <no...@bz...> wrote:
> On Thu, Jan 27, 2011 at 04:37:08PM -0600, kevin granade wrote:
>> On Thu, Jan 27, 2011 at 3:04 PM, Arnout Engelen <no...@bz...> wrote:
>> > It's useful to also check the work done by committers, and I absolutely welcome
>> > you looking into this.
>> >
>> > For now we don't have many reviewers (afaics you're one of the relatively few
>> > people here with the skills required, and you mentioned earlier you don't have
>> > much time for this). Because of this I think it would be unpractical to
>> > require that work done by a committer himself is always first reviewed by a
>> > second reviewer before being committed. It's up to the committer to take
>> > responsibility and first consult the mailinglists before making changes that
>> > might be controversial - hence the post that started this thread ;). Aside
>> > from that commits can of course be reviewed after commiting.
>>
>> 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.
>
> Until that's set up, you can track
> http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=rss or
> https://sourceforge.net/export/rss2_keepsake.php?group_id=314802
>

Ah!  Thanks for that pointer.  I'll take advantage of it.

> You can also join the #notion IRC channel on irc.freenode.net, commits are
> announced and often discussed there.
>
>> (I'm actually thinking of myself here)
>
> Feel free!
>
>
> Kind regards,
>
> Arnout
>

Re: [Notion-devel] elastic/proportional tab sizes: removal.

[Ole J. B. <ole...@ya...>]

>> The remaining difference is discutable. Either it removes unnecessary code
>> or it is a regression. The difference is below.
>Yes - it doesn't seem harmful to have a fall-back scenario in case
> stringintmap_key returns NULL, so unless we get any new information it seems
> to make sense to keep that code.
>

That fixes the issue of the sp sometimes being impossible to resize after a reboot. It's not a perfect fix, but was easy to do compared to providing a string value for every size policy combination.

http://lists.berlios.de/pipermail/ion-general/2009-December/001775.html


- Ole Jørgen Brønner

[Notion-devel] git monitoring infrastructure

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

On Thu, Jan 27, 2011 at 04:37:08PM -0600, kevin granade wrote:
> On Thu, Jan 27, 2011 at 3:04 PM, Arnout Engelen <no...@bz...> wrote:
> > It's useful to also check the work done by committers, and I absolutely welcome
> > you looking into this.
> >
> > For now we don't have many reviewers (afaics you're one of the relatively few
> > people here with the skills required, and you mentioned earlier you don't have
> > much time for this). Because of this I think it would be unpractical to
> > require that work done by a committer himself is always first reviewed by a
> > second reviewer before being committed. It's up to the committer to take
> > responsibility and first consult the mailinglists before making changes that
> > might be controversial - hence the post that started this thread ;). Aside
> > from that commits can of course be reviewed after commiting.
> 
> 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. 

Until that's set up, you can track 
http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=rss or
https://sourceforge.net/export/rss2_keepsake.php?group_id=314802 

You can also join the #notion IRC channel on irc.freenode.net, commits are
announced and often discussed there.

> (I'm actually thinking of myself here) 

Feel free!


Kind regards,

Arnout

Re: [Notion-devel] Atomic commits! Review patches!

[kevin g. <kev...@gm...>]

On Thu, Jan 27, 2011 at 3:04 PM, Arnout Engelen <no...@bz...> wrote:
> On Thu, Jan 27, 2011 at 07:33:47PM +0100, eb...@dr... wrote:
>> I inspected your commit,
>
> That'd be the one at http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=8cabc6558530b6eaf126f0d57c92a719a7284b83
>
>> it was hard to find the fix.
>>
>> Your commit shoud be split in two commits:
>>   first one - code purifying (indenting, variable renames etc.)
>>   second one - the actual fix
>> This way it would be clear what you did.
>
> Agreed entirely.
>
>> I like ion3(plus) because of every line of code was critically
>> considered by Tuomo. Now we have no Tuomo, thus we should review the
>> patches. And not blindly apply them.
>
> Agreed. All committers should review any patches before applying them, and
> discuss on the mailinglist in case of doubts.
>
> It's useful to also check the work done by committers, and I absolutely welcome
> you looking into this.
>
> For now we don't have many reviewers (afaics you're one of the relatively few
> people here with the skills required, and you mentioned earlier you don't have
> much time for this). Because of this I think it would be unpractical to
> require that work done by a committer himself is always first reviewed by a
> second reviewer before being committed. It's up to the committer to take
> responsibility and first consult the mailinglists before making changes that
> might be controversial - hence the post that started this thread ;). Aside
> from that commits can of course be reviewed after commiting.

Perhaps patches should go to the mailing list regardless so that
potential reviewers (I'm actually thinking of myself here)  can look
them over as time is available.  Ideally they would get acked before
being committed, but there is value in late reviews as well.  Also it
provides a resource where potential developers can become familiar
with project norms and issues.

Kevin Granade

>
>> This includes all user contributed patches that were not part of ion3plus
>> (including my patch for proportional tabs).
>
> Yes - I wrongfully assumed the git repo set up by gwash contained only code
> already vetted by Tuomo, no additional patches. I should have been more picky
> there, sorry about that.
>
>
> Kind regards,
>
> Arnout
>
>> On Sat, 22 Jan 2011 16:30:24 +0100
>> Arnout Engelen <no...@bz...> wrote:
>> > Hi,
>> >
>> > As some of you might have noticed, notion git is starting to get into
>> > shape and i've been fixing some bugs here and there.
>> >
>> > >From feedback from existing Ion users, the 'elastic/proportional'
>> > >tab size
>> > functionality that was merged into Notion from
>> > http://github.com/gwash/ion-3plus is not appreciated by everyone. I
>> > don't care for it much myself either, and the code is not very neat
>> > (actually one of the things I fixed was an endless loop in this code,
>> > causing notion to crash and fill up a CPU).
>> >
>> > We should at least make this behavior optional - would anyone be
>> > against just reverting it entirely?
>> >
>> >
>> > Kind regards,
>> >
>> > Arnout
>> >
>> > ------------------------------------------------------------------------------
>> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> > Finally, a world-class log management solution at an even better
>> > price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer
>> > expires February 28th, so secure your free ArcSight Logger TODAY!
>> > http://p.sf.net/sfu/arcsight-sfd2d
>> > _______________________________________________
>> > Notion-devel mailing list
>> > Not...@li...
>> > https://lists.sourceforge.net/lists/listinfo/notion-devel
>> >
>>
>>
>> --
>>                                  Tomáš 'ebík' Ebenlendr
>>                                  PF 2011.07332182268
>>
>
>
>
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> Notion-devel mailing list
>> Not...@li...
>> https://lists.sourceforge.net/lists/listinfo/notion-devel
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
>

Re: [Notion-devel] elastic/proportional tab sizes: removal.

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

On Thu, Jan 27, 2011 at 09:44:13PM +0100, eb...@dr... wrote:
> Okay reverting patches can be found here:
> http://drak.ucw.cz/~ebik/git/notion
> see commit log below.

Thanks! I looked over the commits and tested them. All seems OK, so I pushed 
them to sf.net git.

> If I will have time I will create new version of the proportional tabs code.
> At least more configurable and with nicer algorithm.

OK

> I also re-commited one fix and one default found in the reverted patch.

Yes, looks good.

> The remaining difference is discutable. Either it removes unnecessary code
> or it is a regression. The difference is below.

Yes - it doesn't seem harmful to have a fall-back scenario in case 
stringintmap_key returns NULL, so unless we get any new information it seems 
to make sense to keep that code.


Kind regards,

Arnout

> ============ not applied fix ===========
> diff --git a/etc/look.lua b/etc/look.lua
> new file mode 100644
> index 0000000..2484e42
> --- /dev/null
> +++ b/etc/look.lua
> @@ -0,0 +1 @@
> +dopath('look_newviolet')
> diff --git a/ioncore/sizepolicy.c b/ioncore/sizepolicy.c
> index ce77edb..8c42327 100644
> --- a/ioncore/sizepolicy.c
> +++ b/ioncore/sizepolicy.c
> @@ -360,10 +360,5 @@ bool string2sizepolicy(const char *szplcy, WSizePolicy *value)
>  
>  const char *sizepolicy2string(WSizePolicy szplcy)
>  {
> -    const char* str=stringintmap_key(szplcy_specs, szplcy, NULL);
> -    if(str==NULL){
> -        /* fall back on policy without modifiers if full name not found */
> -        str=stringintmap_key(szplcy_specs, szplcy&0xff, NULL);
> -    }
> -    return str;
> +    return stringintmap_key(szplcy_specs, szplcy, NULL);
>  }
> 
> =======================================
> 
> 
> Here is commit log of changes I made.
> The 'Add default style' change is also based on the reverted patches.
> 
> ============= commit log ==============
> commit 7f09147bb8689b745dfec7aaac33eb1655d44a0d
> Author: Tomáš Ebenlendr <eb...@uc...>
> Date:   Thu Jan 27 21:33:03 2011 +0100
> 
>     Add default style.
> 
> commit 4e896d7897131c1c10c8211d8dcf3cff3aa567d7
> Author: Tomáš Ebenlendr <eb...@uc...>
> Date:   Thu Jan 27 21:03:08 2011 +0100
> 
>     Fix str_len() in the case of multibyte encoding.
>     
>     str_len() fix based on reverted commit 951f7ac - changes found in
>     http://github.com/gwash/ion-3plus
> 
> commit d8196fff51d4d2a14646239e211ff1cd788c9883
> Author: Tomáš Ebenlendr <eb...@uc...>
> Date:   Thu Jan 27 20:00:12 2011 +0100
> 
>     Revert of 951f7acb - because of ugly code.
>     
>     Commit 951f7acb with name:
>     "Merge some changes found in http://github.com/gwash/ion-3plus"
>     contains my (eb...@uc...) patch to elastic/proportional tab sizes,
>     which was proof of concept and was not intended to get into
>     mainline.
> 
> commit 7e3df042741bb89eb26b2a0bcf4aa7a68436045e
> Author: Tomáš Ebenlendr <eb...@uc...>
> Date:   Thu Jan 27 19:52:59 2011 +0100
> 
>     Reverting commit 8cabc655, to revert 951f7acb
>     
>     Reverting commit 8cabc655 (fix of miscalculations of tab sizes) to
>     be able to revert commit 951f7acb, which was a blind apply of
>     changes from http://github.com/gwash/ion3-plus without any review.
>     
>     Second reason is that 8cabc655 should be split in two commits.
> 
> 
> -- 
>                                  Tomáš 'ebík' Ebenlendr
>                                  PF 2011.07367757484
> 



> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel

Re: [Notion-devel] Atomic commits! Review patches!

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

On Thu, Jan 27, 2011 at 07:33:47PM +0100, eb...@dr... wrote:
> I inspected your commit, 

That'd be the one at http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=8cabc6558530b6eaf126f0d57c92a719a7284b83

> it was hard to find the fix.
>
> Your commit shoud be split in two commits:
>   first one - code purifying (indenting, variable renames etc.)
>   second one - the actual fix
> This way it would be clear what you did.

Agreed entirely. 

> I like ion3(plus) because of every line of code was critically
> considered by Tuomo. Now we have no Tuomo, thus we should review the
> patches. And not blindly apply them. 

Agreed. All committers should review any patches before applying them, and 
discuss on the mailinglist in case of doubts.

It's useful to also check the work done by committers, and I absolutely welcome
you looking into this. 

For now we don't have many reviewers (afaics you're one of the relatively few 
people here with the skills required, and you mentioned earlier you don't have
much time for this). Because of this I think it would be unpractical to 
require that work done by a committer himself is always first reviewed by a 
second reviewer before being committed. It's up to the committer to take 
responsibility and first consult the mailinglists before making changes that
might be controversial - hence the post that started this thread ;). Aside 
from that commits can of course be reviewed after commiting.

> This includes all user contributed patches that were not part of ion3plus 
> (including my patch for proportional tabs). 

Yes - I wrongfully assumed the git repo set up by gwash contained only code 
already vetted by Tuomo, no additional patches. I should have been more picky 
there, sorry about that.


Kind regards,

Arnout

> On Sat, 22 Jan 2011 16:30:24 +0100
> Arnout Engelen <no...@bz...> wrote:
> > Hi,
> > 
> > As some of you might have noticed, notion git is starting to get into
> > shape and i've been fixing some bugs here and there.
> > 
> > >From feedback from existing Ion users, the 'elastic/proportional'
> > >tab size
> > functionality that was merged into Notion from 
> > http://github.com/gwash/ion-3plus is not appreciated by everyone. I
> > don't care for it much myself either, and the code is not very neat
> > (actually one of the things I fixed was an endless loop in this code,
> > causing notion to crash and fill up a CPU).
> > 
> > We should at least make this behavior optional - would anyone be
> > against just reverting it entirely?
> > 
> > 
> > Kind regards,
> > 
> > Arnout
> > 
> > ------------------------------------------------------------------------------
> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > Finally, a world-class log management solution at an even better
> > price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer
> > expires February 28th, so secure your free ArcSight Logger TODAY! 
> > http://p.sf.net/sfu/arcsight-sfd2d
> > _______________________________________________
> > Notion-devel mailing list
> > Not...@li...
> > https://lists.sourceforge.net/lists/listinfo/notion-devel
> > 
> 
> 
> -- 
>                                  Tomáš 'ebík' Ebenlendr
>                                  PF 2011.07332182268
> 



> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel

Re: [Notion-devel] elastic/proportional tab sizes: removal?

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

Okay reverting patches can be found here:
http://drak.ucw.cz/~ebik/git/notion
see commit log below.

If I will have time I will create new version of the proportional tabs code.
At least more configurable and with nicer algorithm.


I also re-commited one fix and one default found in the reverted patch.

The remaining difference is discutable. Either it removes unnecessary code
or it is a regression. The difference is below.


============ not applied fix ===========
diff --git a/etc/look.lua b/etc/look.lua
new file mode 100644
index 0000000..2484e42
--- /dev/null
+++ b/etc/look.lua
@@ -0,0 +1 @@
+dopath('look_newviolet')
diff --git a/ioncore/sizepolicy.c b/ioncore/sizepolicy.c
index ce77edb..8c42327 100644
--- a/ioncore/sizepolicy.c
+++ b/ioncore/sizepolicy.c
@@ -360,10 +360,5 @@ bool string2sizepolicy(const char *szplcy, WSizePolicy *value)
 
 const char *sizepolicy2string(WSizePolicy szplcy)
 {
-    const char* str=stringintmap_key(szplcy_specs, szplcy, NULL);
-    if(str==NULL){
-        /* fall back on policy without modifiers if full name not found */
-        str=stringintmap_key(szplcy_specs, szplcy&0xff, NULL);
-    }
-    return str;
+    return stringintmap_key(szplcy_specs, szplcy, NULL);
 }

=======================================


Here is commit log of changes I made.
The 'Add default style' change is also based on the reverted patches.

============= commit log ==============
commit 7f09147bb8689b745dfec7aaac33eb1655d44a0d
Author: Tomáš Ebenlendr <eb...@uc...>
Date:   Thu Jan 27 21:33:03 2011 +0100

    Add default style.

commit 4e896d7897131c1c10c8211d8dcf3cff3aa567d7
Author: Tomáš Ebenlendr <eb...@uc...>
Date:   Thu Jan 27 21:03:08 2011 +0100

    Fix str_len() in the case of multibyte encoding.
    
    str_len() fix based on reverted commit 951f7ac - changes found in
    http://github.com/gwash/ion-3plus

commit d8196fff51d4d2a14646239e211ff1cd788c9883
Author: Tomáš Ebenlendr <eb...@uc...>
Date:   Thu Jan 27 20:00:12 2011 +0100

    Revert of 951f7acb - because of ugly code.
    
    Commit 951f7acb with name:
    "Merge some changes found in http://github.com/gwash/ion-3plus"
    contains my (eb...@uc...) patch to elastic/proportional tab sizes,
    which was proof of concept and was not intended to get into
    mainline.

commit 7e3df042741bb89eb26b2a0bcf4aa7a68436045e
Author: Tomáš Ebenlendr <eb...@uc...>
Date:   Thu Jan 27 19:52:59 2011 +0100

    Reverting commit 8cabc655, to revert 951f7acb
    
    Reverting commit 8cabc655 (fix of miscalculations of tab sizes) to
    be able to revert commit 951f7acb, which was a blind apply of
    changes from http://github.com/gwash/ion3-plus without any review.
    
    Second reason is that 8cabc655 should be split in two commits.


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

[Notion-devel] Atomic commits! Review patches!

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

I inspected your commit, it was hard to find the fix.
Your commit shoud be split in two commits:
  first one - code purifying (indenting, variable renames etc.)
  second one - the actual fix
This way it would be clear what you did.

I like ion3(plus) because of every line of code was critically
considered by Tuomo. Now we have no Tuomo, thus we should review the
patches. And not blindly apply them. This includes all user contributed
patches that were not part of ion3plus (including my patch for
proportional tabs). Otherwise we end with unmaintainable code.

On Sat, 22 Jan 2011 16:30:24 +0100
Arnout Engelen <no...@bz...> wrote:
> Hi,
> 
> As some of you might have noticed, notion git is starting to get into
> shape and i've been fixing some bugs here and there.
> 
> >From feedback from existing Ion users, the 'elastic/proportional'
> >tab size
> functionality that was merged into Notion from 
> http://github.com/gwash/ion-3plus is not appreciated by everyone. I
> don't care for it much myself either, and the code is not very neat
> (actually one of the things I fixed was an endless loop in this code,
> causing notion to crash and fill up a CPU).
> 
> We should at least make this behavior optional - would anyone be
> against just reverting it entirely?
> 
> 
> Kind regards,
> 
> Arnout
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer
> expires February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
> 


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

Re: [Notion-devel] XRandR-based multihead support

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

On Sun, Jan 23, 2011 at 05:18:40PM +0100, Arnout Engelen wrote:
> I took a stab at porting mod_xinerama to RandR. 
> 
> The first very rough prototype is at https://github.com/raboof/mod_xrandr-3. 

Remember you will need a recent git clone of notion for this to work: previous
versions[1] did not correctly pass RandR requests on to the plugin.

Build instructions, as usual, are at:

  https://sourceforge.net/apps/mediawiki/notion/index.php?title=Development

 
Kind regards,

Arnout

[1] before http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=78b4f18e2382cd4ad6d1f1a297a24c2dd2d274c9

[Notion-devel] XRandR-based multihead support

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

Hi,

With mod_xinerama, you can have a dual-head setup with 1 WScreen on each 
monitor.

This is very nice, but has a couple of disadvantages:
- xinerama is marked deprecated and generally out-of-fashion
- changes in layout (adding/removing monitors, changing order) require notion
  to be restarted. Not as bad as it sounds because the client windows stay 
  alive, but still.

I took a stab at porting mod_xinerama to XRandR. 

The first very rough prototype is at https://github.com/raboof/mod_xrandr-3. 
It already supports the current mod_xinerama functionality, but I'm running
into trouble when dynamically changing the screen order.

Suppose you have 2 monitors with different resolutions, one left of the other.
Notion starts up and shows 2 correctly-sized WScreens. Now you run
'xrandr --output one --right-of other', and the 2 monitors switch places.
Because the positions of the 2 WScreens relative to the abstract Screen have
not changed, the bigger WScreen is now shown on the smaller monitor and 
vice-versa.

I tried to reposition the WScreens like this (existingscreen is the WScreen, 
fp.g is the new desired geometry):

    REGION_GEOM(existingscreen)=fp.g;
    mplex_managed_geom((WMPlex*)existingscreen, &(fp.g));
    mplex_do_fit_managed((WMPlex*)existingscreen, &fp);

This however does not appear to have any effect. Does anyone have any idea 
how to approach this?


Kind regards,

Arnout

Re: [Notion-devel] elastic/proportional tab sizes: removal?

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

Hmm, I think I'm to blame. The patch was proof of concept, i.e. ugly
code, written in a lack of time. I have never got to "clean" it. It was
not mentioned to /integrate/ into stable version, but to review and
eventualy rewrite. To be precise, I submited it in this email, where
is also documented the behavior of the tabs:
http://www.mail-archive.com/ion...@li.../msg03125.html

(Sending for second time. First time I used email which is not in list).

On Sat, 22 Jan 2011 16:30:24 +0100
Arnout Engelen <no...@bz...> wrote:

> Hi,
> 
> As some of you might have noticed, notion git is starting to get into
> shape and i've been fixing some bugs here and there.
> 
> >From feedback from existing Ion users, the 'elastic/proportional'
> >tab size
> functionality that was merged into Notion from 
> http://github.com/gwash/ion-3plus is not appreciated by everyone. I
> don't care for it much myself either, and the code is not very neat
> (actually one of the things I fixed was an endless loop in this code,
> causing notion to crash and fill up a CPU).
> 
> We should at least make this behavior optional - would anyone be
> against just reverting it entirely?
> 
> 
> Kind regards,
> 
> Arnout
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer
> expires February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
> 


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

[Notion-devel] elastic/proportional tab sizes: removal?

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

Hi,

As some of you might have noticed, notion git is starting to get into shape 
and i've been fixing some bugs here and there.

>From feedback from existing Ion users, the 'elastic/proportional' tab size
functionality that was merged into Notion from 
http://github.com/gwash/ion-3plus is not appreciated by everyone. I don't care
for it much myself either, and the code is not very neat (actually one of the 
things I fixed was an endless loop in this code, causing notion to crash and
fill up a CPU).

We should at least make this behavior optional - would anyone be against just 
reverting it entirely?


Kind regards,

Arnout

[Notion-devel] Announcing the first sf.net git push

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

Hello fellow-Notioners,

Today I pushed Notion, libtu and libextl to the sf.net git repositories.

What is in the repositories is a fully functional window manager, with 'Ion'
renamed to 'Notion' in the important places, but still using 'ion' for some 
directory names and lua objects.

So next up are:

> 3. Devs create personal clones/branches 
> 4. Hacking (+renaming) session
> 5. Approved changes get into master/official branch
> 6. Repeat 4 & 5

Everyone is invited to clone Notion, try it out, submit bug reports and feature
requests - and of course propose patches. Authors who want their patch to make 
it into the master branch must agree to publish it under both the LGPL and the
Notion License. 

Uncontroversial improvements can be committed by those who have commit access.
Bigger/more controversial changes can first be staged in branches and discussed
on this list.

Patches and commits can be discussed on this list - after discussion, commits 
can be improved or (in extreme cases) reverted.


Kind regards and Happy Hacking,

Arnout

On Thu, Aug 26, 2010 at 09:50:59PM +0200, M Rawash wrote:
> On Thu, 2010-08-26 at 19:04 +0200, Arnout Engelen wrote:
> > On Wed, Aug 25, 2010 at 10:55:07PM +0200, Arnout Engelen wrote:
> > > It's up at http://arnout.engelen.eu/files/dev/notion/notion.git 
> > 
> > I now brought it up-to-date with a few additional changes from ion3plus 
> > as found in M Rawash's git repository over at github.
> 
> great job, thanks!
> 
> > Next step is starting to rename things from ion to notion, in a way that is
> > as backwards-compatible as possible.
> > 
> > A couple of things come to mind:
> > 
> > directory names: let's simply rename these: a simple 'ln -s' will bring the
> >   old names back if someone would like to build a plugin not yet adapted for 
> >   notion
> > 
> > file names: let's simply rename these: simple enough to fix.
> > 
> > internal C object/function names: let's simply rename these
> > 
> > exported names: let's rename these, but keep them available under the old name
> > for compatibility reasons, too. Perhaps add some 'deprecated' GCC marker if
> > possible.
> > 
> > lua object names: let's rename these, but keep aliases to them under the old
> > names, so existing configuration scripts will work (mostly?) unchanged.
> > 
> > What do you think?
> 
> +1 on all accounts, but here's how/when i suggest we should do it:
> 
> 1. Meet Tuomo's conditions (to make notion installable from the get go;
> i'm willing to do this myself if none wants to)
> 2. Push the result to the official git
> 3. Devs create personal clones/branches 
> 4. Hacking (+renaming) session
> 5. Approved changes get into master/official branch
> 6. Repeat 4 & 5
> 
> 0. Allthewhile, we work on improving the website+wiki
> 
> Comments?
> 
> 
> regards,
> M Rawash
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users 
> worldwide. Take advantage of special opportunities to increase revenue and 
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel

Re: [Notion-devel] Preparing the first git push

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

On 09/23/10 at 08:38pm, Arnout Engelen wrote:
> On Fri, Sep 03, 2010 at 10:32:54PM +0200, Arnout Engelen wrote:
> > Installation instructions now at:
> > 
> >   https://sourceforge.net/apps/mediawiki/notion/index.php?title=Development
> > 
> > On Thu, Aug 26, 2010 at 09:50:59PM +0200, M Rawash wrote:
> > > On Thu, 2010-08-26 at 19:04 +0200, Arnout Engelen wrote:
> > > > What do you think?
> > > 
> > > +1 on all accounts, but here's how/when i suggest we should do it:
> > > 
> > > 1. Meet Tuomo's conditions (to make notion installable from the get go;
> > > i'm willing to do this myself if none wants to)
> > 
> > I think the current repo http://arnout.engelen.eu/files/dev/notion/notion.git
> > should meet his conditions.
> > 
> > > 2. Push the result to the official git
> > 
> > I'd say we can do this, but could you please verify first?
> 
> Do you agree we can push this to sf.net git now?
> 
> 
> Arnout

I do agree. 

> 
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel

-- 

Re: [Notion-devel] Preparing the first git push

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

On Fri, Sep 03, 2010 at 10:32:54PM +0200, Arnout Engelen wrote:
> Installation instructions now at:
> 
>   https://sourceforge.net/apps/mediawiki/notion/index.php?title=Development
> 
> On Thu, Aug 26, 2010 at 09:50:59PM +0200, M Rawash wrote:
> > On Thu, 2010-08-26 at 19:04 +0200, Arnout Engelen wrote:
> > > What do you think?
> > 
> > +1 on all accounts, but here's how/when i suggest we should do it:
> > 
> > 1. Meet Tuomo's conditions (to make notion installable from the get go;
> > i'm willing to do this myself if none wants to)
> 
> I think the current repo http://arnout.engelen.eu/files/dev/notion/notion.git
> should meet his conditions.
> 
> > 2. Push the result to the official git
> 
> I'd say we can do this, but could you please verify first?

Do you agree we can push this to sf.net git now?


Arnout

Re: [Notion-devel] A git repo with ion/notion sources

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

On Fri, Sep 03, 2010 at 05:02:30PM -0500, kevin granade wrote:
> Personally I don't want to contribute to anything non-free, even if it is 
> dual-licensed with a free license.

Of course, the ION license is not *that* non-free - it might actually even be 
DFSG-free, for example. All the nasty stuff only applies when you distribute 
the softare under the name 'Ion'. But let's not get into the 'my license is 
free-er than yours' discussion too much ;).

> There is a stakeholder you are skipping: 

Obviously - I was just talking about 'stakeholders' that might have a *legal* 
objection to what we're doing

> users, and more specifically distributions.  
> My primary concern as a user is that the software is
> available on whatever distribution I'm using at the moment (I don't
> always have time to build from source), and having the license
> situation be weird potentially interferes with distribution uptake.

Though that's a valid concern, on the other hand there's plenty of proprietary
software pretty conveniently available for most distro's, and we can probably 
do even better.

> > I think giving both the 'picking up where ion changed licenses' fork and the
> > 'picking up where ion3 left off' fork 'notion' *might* be confusing.
> >
> > Perhaps the distinction could be made by having a 'notion1' (the LGPL fork)
> > and a 'notion2' (the ION-licensed fork), though I always found this kind of
> > thing mighty confusing in Jack ;).
> 
> Speaking solely for myself, my intent with the "pre-license change"
> fork of ion is to bring it up to par with the other fork just to clear
> up the license issue, and then see where things go from there.

This is a good idea. My fear is/was that it will not materialize. There's a 
lot of talk (and yes, I'm partly guilty of that too :) ), but only a few people
have actually moved the project forward since it was abandoned in september 
2009. 

Forking the latest version (and taking the weird license for granted) will 
provide an upgrade path for existing ion3 users that is as painless as 
possible, with the least amount of effort required - and even this is taking
longer than I had hoped.

> Hopefully it won't last long enough for real confusion to set in.
> Good luck to all of us,

Indeed :)


Arnout

Re: [Notion-devel] A git repo with ion/notion sources

[kevin g. <kev...@gm...>]

On Fri, Sep 3, 2010 at 4:07 PM, Arnout Engelen <no...@bz...> wrote:
> On Fri, Aug 27, 2010 at 12:04:32AM +0300, Nedko Arnaudov wrote:
>> I personally think it is not worth to try to grow notion in a tainted
>> soil. Even if FSF replies that it is safe to use the latest codebase
>> after name change, it has yet to be proven in a court. And even then the
>> law depends on country.
>
> I don't have many fears: afaics, there are 3 groups of stakeholders here, and
> we're safe from all of them if we stick to our plan of dual-licensing all
> contributions under both the LGPL and the ION license:
>
> - Tuomo: we can honour his license without much problems - all the 'funky'
>  terms and conditions only apply when the product is presented under the
>  'Ion' name, which we don't.

The only thing that really bothers me about Tuomo getting annoyed and
doing bad things to the project (and if you ever read this Tuomo, I
don't expect you in particular to do anything, it's just that I don't
trust anyone) is the trademark on the ion name.  I don't know how it
works in his jurisdiction, but my reading of case law in the US is
pretty clear about embedding a trademarked word in a product name.
But that is the case with all of the proposed options since everyone
seems to like the notion name so much.

>
> - Contributors: by asking contributors to contribute their code dual-licensed
>  under the ION license and the LGPL, they can't object to their code being
>  incorporated in a product released under either of those.

But they might not want to contribute to a codebase that is under the
ION license.  Personally I don't want to contribute to anything
non-free, even if it is dual-licensed with a free license.

>
> - The FSF: There is some fear the FSF, as the copyright holder for the LGPL,
>  could object to us the ION license being a 'modified' LGPL license. The FSF
>  can confirm whether they think this is a problem for them - unlikely imho.
>

There is a stakeholder you are skipping, users, and more specifically
distributions.  My primary concern as a user is that the software is
available on whatever distribution I'm using at the moment (I don't
always have time to build from source), and having the license
situation be weird potentially interferes with distribution uptake.

>> I do understand that there are people who think otherwise. So I propose
>> to let the evolution do its job by allowing both codebases to exist.
>
> Agreed.

Haha, like either group has a choice :)
Although I think I do understand your intent, which is that there is
no need to argue about it.

>
>> If newer source snapshots are commited over the commit
>> 9d93ba723a3acf0a14be347a75dada8df972e97a, and are are dual licensed,
>> then they could even be backported to the pristine land.
>
> Also, as we're asking our contributors to dual-license their contributions
> under LGPL and ION license, you can cherry-pick those contributions you lika
> (and do not depend on ION-licensed constructs).

Even if they do depend on ION-licensed constructs, we should be able
to work around that in most cases, the contribution itself will be
LGPL, and therefore we can modify it as we see fit to work with our
codebase.

>
>> In this codebase, the ion name can be kept because it is pure LGPL but
>> still I think it is a good idea to change the name. I like the notion
>> name and probably it could be possible to have two codebases associated
>> with same project.

The trademark on the ion name is also an issue regardless of the
license, and I think changing to notion is at least slightly better
than sticking with ion.

>
> I think giving both the 'picking up where ion changed licenses' fork and the
> 'picking up where ion3 left off' fork 'notion' *might* be confusing.
>
> Perhaps the distinction could be made by having a 'notion1' (the LGPL fork)
> and a 'notion2' (the ION-licensed fork), though I always found this kind of
> thing mighty confusing in Jack ;).

Speaking solely for myself, my intent with the "pre-license change"
fork of ion is to bring it up to par with the other fork just to clear
up the license issue, and then see where things go from there.
Hopefully it won't last long enough for real confusion to set in.

Good luck to all of us,
Kevin

>
>
> Arnout
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
>

Re: [Notion-devel] A git repo with ion/notion sources

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

On Fri, Aug 27, 2010 at 12:04:32AM +0300, Nedko Arnaudov wrote:
> I personally think it is not worth to try to grow notion in a tainted
> soil. Even if FSF replies that it is safe to use the latest codebase
> after name change, it has yet to be proven in a court. And even then the
> law depends on country.

I don't have many fears: afaics, there are 3 groups of stakeholders here, and
we're safe from all of them if we stick to our plan of dual-licensing all 
contributions under both the LGPL and the ION license:

- Tuomo: we can honour his license without much problems - all the 'funky' 
  terms and conditions only apply when the product is presented under the
  'Ion' name, which we don't.

- Contributors: by asking contributors to contribute their code dual-licensed
  under the ION license and the LGPL, they can't object to their code being 
  incorporated in a product released under either of those.

- The FSF: There is some fear the FSF, as the copyright holder for the LGPL,
  could object to us the ION license being a 'modified' LGPL license. The FSF
  can confirm whether they think this is a problem for them - unlikely imho.

> I do understand that there are people who think otherwise. So I propose
> to let the evolution do its job by allowing both codebases to exist.

Agreed.

> If newer source snapshots are commited over the commit
> 9d93ba723a3acf0a14be347a75dada8df972e97a, and are are dual licensed,
> then they could even be backported to the pristine land.

Also, as we're asking our contributors to dual-license their contributions
under LGPL and ION license, you can cherry-pick those contributions you lika
(and do not depend on ION-licensed constructs).

> In this codebase, the ion name can be kept because it is pure LGPL but
> still I think it is a good idea to change the name. I like the notion
> name and probably it could be possible to have two codebases associated
> with same project.

I think giving both the 'picking up where ion changed licenses' fork and the
'picking up where ion3 left off' fork 'notion' *might* be confusing.

Perhaps the distinction could be made by having a 'notion1' (the LGPL fork) 
and a 'notion2' (the ION-licensed fork), though I always found this kind of 
thing mighty confusing in Jack ;).


Arnout

Re: [Notion-devel] Preparing the first git push (was: Re: Using an LGPL license extended with additional terms)

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

> > On Wed, Aug 25, 2010 at 10:55:07PM +0200, Arnout Engelen wrote:
> > > It's up at http://arnout.engelen.eu/files/dev/notion/notion.git 

I had to make some fixes to libtu to be able to build notion. Also, I made the
neccessary changes for Notion not to interfere with an existing ion 
installation (too much), and not misrepresent itself as 'Ion' (too much).

Installation instructions now at:

  https://sourceforge.net/apps/mediawiki/notion/index.php?title=Development

On Thu, Aug 26, 2010 at 09:50:59PM +0200, M Rawash wrote:
> On Thu, 2010-08-26 at 19:04 +0200, Arnout Engelen wrote:
> > Next step is starting to rename things from ion to notion, in a way that is
> > as backwards-compatible as possible.
> > 
> > A couple of things come to mind:
> > (...)
> > 
> > What do you think?
> 
> +1 on all accounts, but here's how/when i suggest we should do it:
> 
> 1. Meet Tuomo's conditions (to make notion installable from the get go;
> i'm willing to do this myself if none wants to)

I think the current repo http://arnout.engelen.eu/files/dev/notion/notion.git
should meet his conditions.

> 2. Push the result to the official git

I'd say we can do this, but could you please verify first?

> 3. Devs create personal clones/branches 
> 4. Hacking (+renaming) session
> 5. Approved changes get into master/official branch
> 6. Repeat 4 & 5

Let's!


Arnout

Re: [Notion-devel] A git repo with ion/notion sources

[kevin g. <kev...@gm...>]

+1 for this approach (not that it matters, since you've already made
the git repo)

While this approach does mean duplicated effort, I think it has
promise just via its "just do it" attitude.  If we can make this
branch reach feature/stability parity with the other branch, then this
one will have the best of both worlds, especially since we should be
able to backport any changes made to the other branch to this one.  I
think the first order of business is to determine what exactly is
required to make this branch reach feature parity with the "bad
license" branch so we have a solid goal (in addition to the rename,
which should definitely happen due to the trademark issue).

I'm planning on cloning the repository and trying to come to grips
with what we need for feature parity tonight.

Kevin Granade

On Fri, Aug 27, 2010 at 9:14 AM, Joshua Tolley <egg...@gm...> wrote:
> On Fri, Aug 27, 2010 at 12:04:32AM +0300, Nedko Arnaudov wrote:
>> I personally think it is not worth to try to grow notion in a tainted
>> soil. Even if FSF replies that it is safe to use the latest codebase
>> after name change, it has yet to be proven in a court. And even then the
>> law depends on country.
>
> Can I register my bystander's support of at least exploring this option? I am
> unlikely ever to become an active ion/notion developer, and perhaps that
> changes the weight of my vote, but put me in the "interested user" category as
> one who over the years has tried without success to find an ion alternative.
> My particular concern, in fact, is not the licensing specifically, but is
> rather knowing that the project will remain active and easily available in
> common BSD or Linux distributions. An unfamiliar license makes both of those
> more difficult.
>
> That said, I don't honestly have any idea what differences there are between
> the latest code and this version, so I have no idea how much of a regression
> is involved if the project chooses this earlier codebase. Nor do I know how
> likely it is that, as the community begins modifying this earlier codebase,
> they would avoid adding code "tainted" by later ion versions. But those
> problems (and probably others I haven't thought of) need to be part of the
> discussion.
>
> --
> Joshua Tolley / eggyknap
> End Point Corporation
> http://www.endpoint.com
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkx3yCkACgkQRiRfCGf1UMM0QACgsL9g5iOPhpCp7lvsSzF5Znuf
> uPEAnAtD2Yt1z2mW65rkBD68h12tkhcS
> =fkS/
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
>
>

Re: [Notion-devel] A git repo with ion/notion sources

[Joshua T. <egg...@gm...>]

On Fri, Aug 27, 2010 at 12:04:32AM +0300, Nedko Arnaudov wrote:
> I personally think it is not worth to try to grow notion in a tainted
> soil. Even if FSF replies that it is safe to use the latest codebase
> after name change, it has yet to be proven in a court. And even then the
> law depends on country.

Can I register my bystander's support of at least exploring this option? I am
unlikely ever to become an active ion/notion developer, and perhaps that
changes the weight of my vote, but put me in the "interested user" category as
one who over the years has tried without success to find an ion alternative.
My particular concern, in fact, is not the licensing specifically, but is
rather knowing that the project will remain active and easily available in
common BSD or Linux distributions. An unfamiliar license makes both of those
more difficult.

That said, I don't honestly have any idea what differences there are between
the latest code and this version, so I have no idea how much of a regression
is involved if the project chooses this earlier codebase. Nor do I know how
likely it is that, as the community begins modifying this earlier codebase,
they would avoid adding code "tainted" by later ion versions. But those
problems (and probably others I haven't thought of) need to be part of the
discussion.

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

[Notion-devel] A git repo with ion/notion sources

[Nedko A. <ne...@ar...>]

Hi,

I've imported into git the last ion3 tarball that was digitally signed
by Tuomo Valkonen and had unmodified license. The signature and original
tarball are in the first commit, the second commit contains the sources
only.

I personally think it is not worth to try to grow notion in a tainted
soil. Even if FSF replies that it is safe to use the latest codebase
after name change, it has yet to be proven in a court. And even then the
law depends on country.

I do understand that there are people who think otherwise. So I propose
to let the evolution do its job by allowing both codebases to exist.

If newer source snapshots are commited over the commit
9d93ba723a3acf0a14be347a75dada8df972e97a, and are are dual licensed,
then they could even be backported to the pristine land.

In this codebase, the ion name can be kept because it is pure LGPL but
still I think it is a good idea to change the name. I like the notion
name and probably it could be possible to have two codebases associated
with same project.

The cgit view of the repo:

http://nedko.arnaudov.name/git/cgit.cgi/ion/

The clone url:

http://nedko.arnaudov.name/git/ion.git

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

Re: [Notion-devel] Preparing the first git push (was: Re: Using an LGPL license extended with additional terms)

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

On Thu, 2010-08-26 at 19:04 +0200, Arnout Engelen wrote:
> On Wed, Aug 25, 2010 at 10:55:07PM +0200, Arnout Engelen wrote:
> > It's up at http://arnout.engelen.eu/files/dev/notion/notion.git 
> 
> I now brought it up-to-date with a few additional changes from ion3plus 
> as found in M Rawash's git repository over at github.

great job, thanks!

> Next step is starting to rename things from ion to notion, in a way that is
> as backwards-compatible as possible.
> 
> A couple of things come to mind:
> 
> directory names: let's simply rename these: a simple 'ln -s' will bring the
>   old names back if someone would like to build a plugin not yet adapted for 
>   notion
> 
> file names: let's simply rename these: simple enough to fix.
> 
> internal C object/function names: let's simply rename these
> 
> exported names: let's rename these, but keep them available under the old name
> for compatibility reasons, too. Perhaps add some 'deprecated' GCC marker if
> possible.
> 
> lua object names: let's rename these, but keep aliases to them under the old
> names, so existing configuration scripts will work (mostly?) unchanged.
> 
> What do you think?

+1 on all accounts, but here's how/when i suggest we should do it:

1. Meet Tuomo's conditions (to make notion installable from the get go;
i'm willing to do this myself if none wants to)
2. Push the result to the official git
3. Devs create personal clones/branches 
4. Hacking (+renaming) session
5. Approved changes get into master/official branch
6. Repeat 4 & 5

0. Allthewhile, we work on improving the website+wiki

Comments?


regards,
M Rawash