Menu
▾
▴
notion-devel
|
From: Arnout E. <no...@bz...> - 2011-04-09 09:40:03
|
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 |
|
From: <eb...@dr...> - 2011-04-10 20:00:19
Attachments:
signature.asc
|
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
|
|
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: <eb...@dr...> - 2011-04-17 10:59:50
Attachments:
signature.asc
|
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: <eb...@dr...> - 2011-04-17 18:35:11
Attachments:
signature.asc
|
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: 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: 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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X