Menu
▾
▴
notion-devel — Development discussion about the notion window manager
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(66) |
May
|
Jun
|
Jul
|
Aug
(31) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(12) |
Feb
(35) |
Mar
(11) |
Apr
(16) |
May
(18) |
Jun
|
Jul
(1) |
Aug
(12) |
Sep
(21) |
Oct
(23) |
Nov
(12) |
Dec
|
| 2012 |
Jan
(5) |
Feb
(14) |
Mar
(3) |
Apr
(3) |
May
(6) |
Jun
|
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(3) |
Dec
(12) |
| 2013 |
Jan
(11) |
Feb
(10) |
Mar
(2) |
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(9) |
Dec
(2) |
| 2014 |
Jan
(43) |
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
(1) |
Dec
(5) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(4) |
Nov
|
Dec
|
|
From: Etan R. <de...@un...> - 2011-05-13 11:24:39
|
On Fri, May 13, 2011 at 08:58:20AM +0200, Ole Jørgen Brønner wrote:
> Ah.. so that's what ac stands for :)
Heh.
> I have used system-ac.mk to avoid constant diffs from git/darcs since I need local changes in build configuration.
>
> Maybe there is another way to avoid that problem though? I guess git might have some sort of ignore mechanism for these kinds of things.
Yeah, it occurred to me as I was writing my email that things like this
(and/or distributions wanting to package notion) could use system-ac.mk to
avoid needing to edit system.mk or use env vars.
But I'm not convinced that's a useful enough reason to keep it around.
I'm also open to simply having system.mk include (without failing if it
doesn't exit) a local.mk (or similar) file to allow these sort of
custom definitions.
But this is exactly the sort of thing that caused me to send an email
about this before just making the change.
-Etan
|
|
From: Ole J. B. <ole...@ya...> - 2011-05-13 06:58:30
|
On Fri, 13 May 2011 05:05:01 +0200, Etan Reisner <de...@un...> wrote: > system-inc.mk was added (as far as I can recall and discern from what it > does) added to support the autotool build method for ion (which was a > third-party contribution, never worked all that well, and didn't work for > very long). > > As such system-inc.mk doesn't serve much useful purpose at this point (the > ac/system-ac.mk file that it references hasn't existed, or been creatable, > in ages). Ah.. so that's what ac stands for :) I have used system-ac.mk to avoid constant diffs from git/darcs since I need local changes in build configuration. Maybe there is another way to avoid that problem though? I guess git might have some sort of ignore mechanism for these kinds of things. -- Ole Jørgen Brønner |
|
From: Etan R. <de...@un...> - 2011-05-13 03:05:14
|
system-inc.mk was added (as far as I can recall and discern from what it
does) added to support the autotool build method for ion (which was a
third-party contribution, never worked all that well, and didn't work for
very long).
As such system-inc.mk doesn't serve much useful purpose at this point (the
ac/system-ac.mk file that it references hasn't existed, or been creatable,
in ages).
I'd like to get rid of it. That measns pulling the two include lines into
every Makefile that currently includes system-inc.mk.
Attached is a patch which does that. If this seems acceptable I'll commit
and push it.
I didn't want to make a change this big without checking (the rest of the
build stuff I've done has been comparatively minor).
-Etan
|
|
From: Etan R. <de...@un...> - 2011-05-11 17:26:42
|
On Wed, May 11, 2011 at 02:12:47PM -0300, Silas Silva wrote:
> On Wed, May 11, 2011 at 11:03:34AM -0400, Etan Reisner wrote:
> > Does '#include <sys/featuretest.h>' work?
>
> It works and it is a much better solution, thanks!!!
Ok, good. Now I just need to find out what defines I can use to detect
netbsd.
> Have conditional compilation to differentiate OS/machines is ugly.
> Stickying to ANSI C is much better and it is why Lua is so portable :-)
Yeah, when it is reasonably possible being natively portable is definitely
the best option. But the farther up the stack you get the less that's
really possible (well up to a certain point at least).
-Etan
|
|
From: Silas S. <si...@gm...> - 2011-05-11 17:12:13
|
On Wed, May 11, 2011 at 11:03:34AM -0400, Etan Reisner wrote: > Does '#include <sys/featuretest.h>' work? It works and it is a much better solution, thanks!!! Have conditional compilation to differentiate OS/machines is ugly. Stickying to ANSI C is much better and it is why Lua is so portable :-) Thank you very much. -- Silas Silva |
|
From: Etan R. <de...@un...> - 2011-05-11 15:03:42
|
On Tue, May 10, 2011 at 03:44:19PM -0300, Silas Silva wrote:
> On Tue, May 10, 2011 at 02:27:53PM -0400, Etan Reisner wrote:
> > What problem does that fix exactly?
>
> features.h doesn't exist in NetBSD and maybe in other BSD platforms.
Does '#include <sys/featuretest.h>' work?
-Etan
|
|
From: Silas S. <si...@gm...> - 2011-05-10 18:43:43
|
On Tue, May 10, 2011 at 02:27:53PM -0400, Etan Reisner wrote: > What problem does that fix exactly? features.h doesn't exist in NetBSD and maybe in other BSD platforms. #include <features.h> is really necessary in Linux? I even don't know what functionality it includes... -- Silas Silva |
|
From: Etan R. <de...@un...> - 2011-05-10 18:28:02
|
What problem does that fix exactly?
-Etan
|
|
From: Silas S. <si...@gm...> - 2011-05-10 18:24:46
|
On Fri, May 06, 2011 at 09:02:32PM -0300, Silas Silva wrote: > I've successfully compiled and used notion in NetBSD, with no problems, > but recently I had to make a one-line modification to workaround a > problem... patch is attached. Sorry, here we go with patch _attached_ now!!! :-) This is quick and ugly. There might be a more inteligent way of doing this besides poluting code with #ifdefs... -- Silas Silva |
|
From: Arnout E. <no...@bz...> - 2011-05-08 11:26:44
|
On Fri, May 06, 2011 at 09:02:32PM -0300, Silas Silva wrote: > notion is a great continuation of ion3, and much more democratic :-) > > I'd like to ask you how you deal with portability. Is Linux the main > target? Yes > Is it the only target? No: a while ago we fixed some problems to build have notion build properly on solaris, for example > I've successfully compiled and used notion in NetBSD, with no problems, Cool > but recently I had to make a one-line modification to workaround a > problem... patch is attached. No it isn't :) > So, do you plan to work on portability? Personally, not really, but if you can test things and provide patches I'd be happy to consider them for inclusion. Kind regards, Arnout |
|
From: Etan R. <de...@un...> - 2011-05-07 04:07:10
|
There's no patch attached.
As far as I'm concerned, which only counts a certain amount, any
reasonable changes needed to handle portability are worth it.
Given the needs of notion there really shouldn't be too much that causes
portability headaches.
-Etan
|
|
From: Silas S. <si...@gm...> - 2011-05-07 00:02:04
|
Hi there. notion is a great continuation of ion3, and much more democratic :-) I'd like to ask you how you deal with portability. Is Linux the main target? Is it the only target? I've successfully compiled and used notion in NetBSD, with no problems, but recently I had to make a one-line modification to workaround a problem... patch is attached. So, do you plan to work on portability? Thanks. -- Silas Silva |
|
From: Arnout E. <no...@bz...> - 2011-05-03 22:44:15
|
On Mon, May 02, 2011 at 11:51:12PM +0200, Arnout Engelen wrote:
> We'll have to think about what to do when a screen disappears or merges into
> another due to overlap: what do we want to happen to the children of that
> screen? I'm not too clear on how the saving/loading infrastructure is supposed
> to work, so I can't quite decide whether this would be something useful to
> leverage here.
I'd still like to get feedback on this question
> I tested this by calling mod_xinerama.refresh() wherever RandR reports changes.
> mod_xinerama.update_screen appears to be called with the correct parameters,
> but the screens do not get resized - we'll have to look into how to resize a
> screen.
I fixed (or worked around) this.
If you want to play with this, get:
- the latest notion from git
- the latest mod_xrandr from the git 'expose' branch
(I'll merge this branch into the mod_xrandr trunk unless anyone objects)
- the latest mod_xinerama from the git 'split' branch
Finally, add to your lua configuration:
----
function screenlayoutupdated()
mod_xinerama.refresh()
end
randr_screen_change_notify_hook = ioncore.get_hook('randr_screen_change_notify')
if randr_screen_change_notify_hook ~= nil then
randr_screen_change_notify_hook:add(screenlayoutupdated)
end
----
Regards,
Arnout
> On Sun, Apr 17, 2011 at 08:35:05PM +0200, eb...@dr... wrote:
> > Hi,
> >
> > I did the rewrite of the lua functions. I tried also to make it more
> > readable code. Also ordering of items when running table.foreach()
> > function is not defined (although it was correct), thus I had to use
> > for ... in ipairs(...) at several places for the code to be written the
> > right way.
> >
> > I renamed the previous merge_overlapping_screens algorithm, because
> > it may be used if we find out how to initialise layout of weird
> > WScreens (created from the partially overlapped screens) so that it
> > will be shaped. We need not to investigate here, because there are no
> > users to use this. But it may be sideefect of some further development.
> >
> > On Sun, 17 Apr 2011 12:59:27 +0200
> > eb...@dr... wrote:
> > >
> > > On Sat, 16 Apr 2011 19:16:12 +0200
> > > Arnout Engelen <no...@bz...> wrote:
> > > > I'm not sure - we'd have to make sure the C WScreen is not obscured
> > > > by the A+B one... might be neater to merge them, though both
> > > > behaviors are indeed strange.
> > >
> > > You are right, if you focus 'A+B' WScreen then 'C' WScreen is now
> > > (partially) hidden by the 'A+B'. I'll reimplement the merging
> > > algorithm in the evening (or in next few days).
> > >
> > > I need to think about reimplementation of WScreens and saving and
> > > loading layouts. The current implementation is not good for laptops
> > > that are attached to different screen at work, at home and to no
> > > second screen at all when the user travelling.
> > >
> > > > I checked out your branch and the lua logic crashed on me. I added a
> > > > 'test' lua script to the 'split' branch at sf.net .
> > >
> > > Hmm, that bug was introduced in order stabilising patch. Fixed now and
> > > pushed to my public repository, together with a small patch to accept
> > > any numeric indices in setup_screens (to be consistent with notion).
> > >
> > > > Kind regards,
> > > >
> > > > Arnout
> > >
> > > --
> > > Tomáš 'ebík' Ebenlendr
> > > PF 2011.29184056317
> > >
> >
> >
> > --
> > Tomáš 'ebík' Ebenlendr
> > PF 2011.29273392314
> >
>
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
|
|
From: Arnout E. <no...@bz...> - 2011-05-03 22:15:10
|
Hi, Currently, the WRootWin is a WScreen, which is a WMPlex. WMPlex is documented as: 'a base class for all regions that ``multiplex'' other regions. This means that of the regions managed by the multiplexer, only one can be displayed at a time.' The current multihead approaches, afaics, create multiple WScreen's as WMPlex'ed children of the WRootWin. Those WScreen's *will* be displayed at the same time. One symptom is that I've enabled resizing WScreen's, but the WRootWin (being a WMPlex) will try to resize the WScreen to the size of the WRootWin, which is undesirable in the multihead situation. This leads me to think it's not natural choice to attach the multihead WScreens directly to the WRootWin/WMPlex. What do you think? What could be an alternative approach? Kind regards, Arnout |
|
From: Arnout E. <no...@bz...> - 2011-05-02 21:51:23
|
Hi, I refactored a bit and ported most of the logic to the lua side. Also I think I mostly covered the simple use cases updating the screen layout: moving screens, adding screens or changing the screen layout as long as the number of screens doesn't decrease. We'll have to think about what to do when a screen disappears or merges into another due to overlap: what do we want to happen to the children of that screen? I'm not too clear on how the saving/loading infrastructure is supposed to work, so I can't quite decide whether this would be something useful to leverage here. I tested this by calling mod_xinerama.refresh() wherever RandR reports changes. mod_xinerama.update_screen appears to be called with the correct parameters, but the screens do not get resized - we'll have to look into how to resize a screen. Kind regards, Arnout On Sun, Apr 17, 2011 at 08:35:05PM +0200, eb...@dr... wrote: > Hi, > > I did the rewrite of the lua functions. I tried also to make it more > readable code. Also ordering of items when running table.foreach() > function is not defined (although it was correct), thus I had to use > for ... in ipairs(...) at several places for the code to be written the > right way. > > I renamed the previous merge_overlapping_screens algorithm, because > it may be used if we find out how to initialise layout of weird > WScreens (created from the partially overlapped screens) so that it > will be shaped. We need not to investigate here, because there are no > users to use this. But it may be sideefect of some further development. > > On Sun, 17 Apr 2011 12:59:27 +0200 > eb...@dr... wrote: > > > > On Sat, 16 Apr 2011 19:16:12 +0200 > > Arnout Engelen <no...@bz...> wrote: > > > I'm not sure - we'd have to make sure the C WScreen is not obscured > > > by the A+B one... might be neater to merge them, though both > > > behaviors are indeed strange. > > > > You are right, if you focus 'A+B' WScreen then 'C' WScreen is now > > (partially) hidden by the 'A+B'. I'll reimplement the merging > > algorithm in the evening (or in next few days). > > > > I need to think about reimplementation of WScreens and saving and > > loading layouts. The current implementation is not good for laptops > > that are attached to different screen at work, at home and to no > > second screen at all when the user travelling. > > > > > I checked out your branch and the lua logic crashed on me. I added a > > > 'test' lua script to the 'split' branch at sf.net . > > > > Hmm, that bug was introduced in order stabilising patch. Fixed now and > > pushed to my public repository, together with a small patch to accept > > any numeric indices in setup_screens (to be consistent with notion). > > > > > Kind regards, > > > > > > Arnout > > > > -- > > Tomáš 'ebík' Ebenlendr > > PF 2011.29184056317 > > > > > -- > Tomáš 'ebík' Ebenlendr > PF 2011.29273392314 > |
|
From: ebik <eb...@dr...> - 2011-04-25 09:52:35
|
> > The branches are on standard location: > > http://drak.ucw.cz/~ebik/git/notion > > http://drak.ucw.cz/~ebik/git/libtu > > http://drak.ucw.cz/~ebik/git/libextl > > it seems there's something wrong with the notion repo: > > arnouten@jaga:/tmp$ git clone http://drak.ucw.cz/~ebik/git/notion > Cloning into notion... > fatal: http://drak.ucw.cz/~ebik/git/notion/info/refs not found: did > you run git update-server-info on the server? arnouten@jaga:/tmp$ > > Could you look into that? Hmm, I managed to get fresh empty repository there when I was creating some other repositories. Now it should be fixed. -- Tomáš 'ebík' Ebenlendr PF 2011.31367865297 |
|
From: Arnout E. <no...@bz...> - 2011-04-24 16:46:18
|
On Wed, Apr 13, 2011 at 12:53:57AM +0200, ebik wrote: > We rely on GNUMake anyway, thus I added some Make automagic, that > detects if libtu and/or libextl is copied into properly named > subdirectory of notion, and setups then accordingly (it behaves then > like makefiles in snapshot, i.e., the included libtu and libextl uses > system.mk and others of the parent directory (notion)). The main idea > is to pass a make variable SUBMODULE=1 to subdirectories, and let libtu > and libextl makefiles set TOPDIR to .. when they detect this variable. Sounds reasonable, pushed the changes in libtu and libextl > The second part is autodetection in libs.mk, that uses libtu and > libextl from subdirectories of notion, if they are there. > > I also added autodetection, if there is lua5.1 in pkg-config. If so, > then 'debian' way of lua setup is used, otherwise '/usr/local/...' > paths are used. Sounds good, however... > The branches are on standard location: > http://drak.ucw.cz/~ebik/git/notion > http://drak.ucw.cz/~ebik/git/libtu > http://drak.ucw.cz/~ebik/git/libextl it seems there's something wrong with the notion repo: arnouten@jaga:/tmp$ git clone http://drak.ucw.cz/~ebik/git/notion Cloning into notion... fatal: http://drak.ucw.cz/~ebik/git/notion/info/refs not found: did you run git update-server-info on the server? arnouten@jaga:/tmp$ Could you look into that? Thanks & kind regards, Arnout |
|
From: <eb...@dr...> - 2011-04-17 18:35:11
|
Hi, I did the rewrite of the lua functions. I tried also to make it more readable code. Also ordering of items when running table.foreach() function is not defined (although it was correct), thus I had to use for ... in ipairs(...) at several places for the code to be written the right way. I renamed the previous merge_overlapping_screens algorithm, because it may be used if we find out how to initialise layout of weird WScreens (created from the partially overlapped screens) so that it will be shaped. We need not to investigate here, because there are no users to use this. But it may be sideefect of some further development. On Sun, 17 Apr 2011 12:59:27 +0200 eb...@dr... wrote: > > On Sat, 16 Apr 2011 19:16:12 +0200 > Arnout Engelen <no...@bz...> wrote: > > I'm not sure - we'd have to make sure the C WScreen is not obscured > > by the A+B one... might be neater to merge them, though both > > behaviors are indeed strange. > > You are right, if you focus 'A+B' WScreen then 'C' WScreen is now > (partially) hidden by the 'A+B'. I'll reimplement the merging > algorithm in the evening (or in next few days). > > I need to think about reimplementation of WScreens and saving and > loading layouts. The current implementation is not good for laptops > that are attached to different screen at work, at home and to no > second screen at all when the user travelling. > > > I checked out your branch and the lua logic crashed on me. I added a > > 'test' lua script to the 'split' branch at sf.net . > > Hmm, that bug was introduced in order stabilising patch. Fixed now and > pushed to my public repository, together with a small patch to accept > any numeric indices in setup_screens (to be consistent with notion). > > > Kind regards, > > > > Arnout > > -- > Tomáš 'ebík' Ebenlendr > PF 2011.29184056317 > -- Tomáš 'ebík' Ebenlendr PF 2011.29273392314 |
|
From: <eb...@dr...> - 2011-04-17 10:59:50
|
On Sat, 16 Apr 2011 19:16:12 +0200 Arnout Engelen <no...@bz...> wrote: > I'm not sure - we'd have to make sure the C WScreen is not obscured > by the A+B one... might be neater to merge them, though both > behaviors are indeed strange. You are right, if you focus 'A+B' WScreen then 'C' WScreen is now (partially) hidden by the 'A+B'. I'll reimplement the merging algorithm in the evening (or in next few days). I need to think about reimplementation of WScreens and saving and loading layouts. The current implementation is not good for laptops that are attached to different screen at work, at home and to no second screen at all when the user travelling. > I checked out your branch and the lua logic crashed on me. I added a > 'test' lua script to the 'split' branch at sf.net . Hmm, that bug was introduced in order stabilising patch. Fixed now and pushed to my public repository, together with a small patch to accept any numeric indices in setup_screens (to be consistent with notion). > Kind regards, > > Arnout -- Tomáš 'ebík' Ebenlendr PF 2011.29184056317 |
|
From: Arnout E. <no...@bz...> - 2011-04-16 17:16:25
|
On Sun, Apr 10, 2011 at 09:47:19PM +0200, eb...@dr... wrote: > 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. I'm certainly not opposed to doing this in lua, though I don't have a strong preference between doing it in C and doing it in Lua. Lua has some nice syntax, otoh in C you have direct access to the C API's... both have its advantages ;). > The second objection is, that the algorithm does not merge screen B > to screen A,C in following setup: > (..) You are, of course, entirely right. > 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. I'm not sure - we'd have to make sure the C WScreen is not obscured by the A+B one... might be neater to merge them, though both behaviors are indeed strange. I checked out your branch and the lua logic crashed on me. I added a 'test' lua script to the 'split' branch at sf.net . Kind regards, Arnout > 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 > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Notion-devel mailing list > Not...@li... > https://lists.sourceforge.net/lists/listinfo/notion-devel |
|
From: Arnout E. <no...@bz...> - 2011-04-15 16:52:46
|
On Tue, Apr 12, 2011 at 09:28:51AM -0400, Etan Reisner wrote: > I think renaming to "super" is a pointless idea. Either you know what type > the parent is, in which case typing its name instead of super isn't a big > deal; or you don't, in which case you can't use super anyway since you > can't know what to cast it to. Indeed it is not useful when writing code, but imho it is useful when reading code. > It also doesn't tell you anything useful, since the immediate super > relationship isn't particularly helpful whereas the type of the member > actually is (especially if you are simply passing it to another function > which expects a certain type). > > Consider: > WScreen *scr=current_screen(); > mplex_switch_next(&(scr->mplex)); > versus > WScreen *scr=current_screen(); > mplex_switch_next(&(scr->super)); > > Which one tells you immediately that you've gotten the argument type to > mplex_switch_next right and which one leaves you having to remember and or > guess? In this case, when reading this code, I actually do think the second variation is more readable: you know the code compiles, you can easily guess 'mplex_switch_next' will take an mplex argument, and the 'super' tells you you're calling 'mplex_switch_next' on the screen itself instead of on some mplex property of the screen. > Also consider your given example. In what way is > > 'rw->scr.super.super.win=None;' > superior to > > 'rw->scr.mplex.win.win=None;' > ? > > The super version reads less well (to me), gives me less information, and > at that point I would really want a cast (or cast macro) or something to > hide it (you probably want that in either case really). Again, while I agree '.super.super' does not look very elegant, you *can* see at a glance that 'win' is a property of the screen itself (via superclasses) rather than a property of a property of a property of the screen. The types of the superclasses in the second variation add confusion rather than information imho. I think I would prefer 'normal' casts over glib-style macro-casts, but both of these throw the static typechecking out of the window, which the use of members (named 'super' or otherwise) avoids. Kind regards, Arnout |
|
From: Etan R. <de...@un...> - 2011-04-13 02:48:01
|
I think renaming to "super" is a pointless idea. Either you know what type
the parent is, in which case typing its name instead of super isn't a big
deal; or you don't, in which case you can't use super anyway since you
can't know what to cast it to.
It also doesn't tell you anything useful, since the immediate super
relationship isn't particularly helpful whereas the type of the member
actually is (especially if you are simply passing it to another function
which expects a certain type).
Consider:
WScreen *scr=current_screen();
mplex_switch_next(&(scr->mplex));
versus
WScreen *scr=current_screen();
mplex_switch_next(&(scr->super));
Which one tells you immediately that you've gotten the argument type to
mplex_switch_next right and which one leaves you having to remember and or
guess?
Also consider your given example. In what way is
> 'rw->scr.super.super.win=None;'
superior to
> 'rw->scr.mplex.win.win=None;'
?
The super version reads less well (to me), gives me less information, and
at that point I would really want a cast (or cast macro) or something to
hide it (you probably want that in either case really).
What is the current inconsistency exactly? I think there are actually
valid reasons to use both the specific cast and the &(obj->mem)
indirection.
To my mind the cast is more appropriate for assignment to local variables
for continued use (it says "I know this X is a Y and I intend to use it as
such from now on") whereas the member indirection is useful for examples
like the above (it says "I have an X, which I know is a Y, and you need
just that bit of it").
I'm not certain we need both, mind you. I'd be fine standardizing on the
cast (I wouldn't standardize the other way though). I'd also be fine
adding typecast macros (the way glib does), like what ebik said (though
I'm not sure we can reasonably get runtime tests the way glib sometimes
does).
-Etan
|
|
From: ebik <eb...@dr...> - 2011-04-12 22:54:09
|
We rely on GNUMake anyway, thus I added some Make automagic, that detects if libtu and/or libextl is copied into properly named subdirectory of notion, and setups then accordingly (it behaves then like makefiles in snapshot, i.e., the included libtu and libextl uses system.mk and others of the parent directory (notion)). The main idea is to pass a make variable SUBMODULE=1 to subdirectories, and let libtu and libextl makefiles set TOPDIR to .. when they detect this variable. The second part is autodetection in libs.mk, that uses libtu and libextl from subdirectories of notion, if they are there. I also added autodetection, if there is lua5.1 in pkg-config. If so, then 'debian' way of lua setup is used, otherwise '/usr/local/...' paths are used. The branches are on standard location: http://drak.ucw.cz/~ebik/git/notion http://drak.ucw.cz/~ebik/git/libtu http://drak.ucw.cz/~ebik/git/libextl These patches are more or less needed, if we want to use git-submodule. The second step is to setup the submodules properly, so that they will be automatically checked in 'libtu' and 'libext' subdirectories, when user types: git submodule update --init (after the initial clone, subsequent updates need not the --init option) The nice thing on submodules is, that git knows (i.e., commiter must tell) which versions(comits) of submodules belongs to particular commit of project that includes these submodules. Here is the git documentation: http://book.git-scm.com/5_submodules.html -- Tomáš 'ebík' Ebenlendr PF 2011.27951303272 |
|
From: Arnout E. <no...@bz...> - 2011-04-12 20:25:19
|
Hi! If you just want to build notion from source, not really contribute, you can use the 'source package' in the sf.net releases: https://sourceforge.net/projects/notion/files/snapshots/ (this is linked to from the homepage). It would still be interesting to make it easier for developers, too, of course, git submodules might be interesting to look into. Kind regards, Arnout On Tue, Apr 12, 2011 at 08:16:26AM -0700, James deBoer wrote: > 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. > ------------------------------------------------------------------------------ > Forrester Wave Report - Recovery time is now measured in hours and minutes > not days. Key insights are discussed in the 2010 Forrester Wave Report as > part of an in-depth evaluation of disaster recovery service providers. > Forrester found the best-in-class provider in terms of services and vision. > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > _______________________________________________ > Notion-devel mailing list > Not...@li... > https://lists.sourceforge.net/lists/listinfo/notion-devel |
|
From: <eb...@dr...> - 2011-04-12 18:52:34
|
Maybe we can try 'git submodules', it requires git >= 1.5.3. If I read
manual correctly:
* It requires only one additional command (without arguments) to
checkout sumodules.
* The submodules are bound /at specified commit/ - thus you know
which version (commit) of submodules (libraries) is supposed to
be used with the specified version (commit) of the superproject
(here notion). - When you update the submodule with new version
(commit), you have to commit into superproject: you commit the
information that current version of superproject is supposed to be
compiled with the new version of the submodule.
We should also distinguish the makefiles when used for building from git
repository and from releases. Also we can try to autodetect the LUA by
pkg-config and fallback to the 'standard' setting when there is no
pkg-config.
I will look at all of this in two or three weeks if somebody will not
be faster.
On Tue, 12 Apr 2011 08:16:26 -0700
James deBoer <ja...@hu...> wrote:
> 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.
--
Tomáš 'ebík' Ebenlendr
PF 2011.27906310249
|
