Dear Cartsten,

An excellent tutorial on the internals of e and the approach e uses to
handle multiple screens. It really explains a lot about the structure
and processes. I didn't realize that the ibar is simply walking memory
to generate the changes to desktop applications.

I'll have to try Tasks to see if that meets my desires of seeing all
running apps. My current config is two screens, left 1600x900 and right
1280x1024.  So the top's are aligned and the ibar is on the right
screen in the space which would be below the space of the left screen.
I consider it the monitoring space of what is happening with the
system, while everything above the 900 line is working space for
applications.  It satisfies me as a working layout.

There is one e intuitive smartness which bothered me at first.  If
I mouse grab an application on the right screen and move to the right
the result is it moves to the next virtual screen 1:1, moved to the
left it moves to the left screen 0:0.  Without the Pager I didn't know
that I just moved the application to the next virtual desktop and
thought I lost it, because the application on the left screen was still
visible. But to move the application back to virtual 1:0 you have to
use the right mouse button menu and can't mouse grab and move back 1:0.
Just an odd quirk of smartness that I was surprised operated the way it
did if each screen is fully independent. 

Hope you have a happy new year.  Cheers, BrianA_MN

------------------------------------------------------------------------------------------------------------------
On Mon, 30 Dec 2019 13:11:09 +0000
Carsten Haitzler <ras...@rasterman.com> wrote:

> On Sat, 28 Dec 2019 11:40:22 -0600 Brian via enlightenment-users
> <enlightenment-users@lists.sourceforge.net> said:
> 
> > Resending so it posts to the user list. 
> > Also wanted to add one more question.
> > If gadgets can be added to the desktop directly, what happens
> > differently with the shelf?  It is added settings, like position,
> > reserved space so apps can't cover, etc?
> 
> 2 different folders (conceptually) with different stacking (one
> within a shelf thing that hugs an edge or corner of the screen, one
> just below everything just above the background). the shelf is linear
> layout with items sized to shelf size in one dimension but allowed to
> expand in the other. desktop is "place them where you like freely in
> 2d". a shelf is far easier to have it adapt to changing content (e.g.
> tasks which grows and shrinks based on number of task buttons in it,
> or ibar when it adds or removes icons etc.), where with a 2d layout
> that is essentially impossible to do sanely and intelligently, thus
> it's left up tot he user to arrange things manually.
> 
> > Cheers, BrianA
> > ------------------------------------------------------------------------------------------------------------------
> > On Sat, 28 Dec 2019 11:34:32 -0600
> > Brian <bvamund...@yahoo.com> wrote:
> > 
> > > On Sat, 28 Dec 2019 16:30:44 +0000
> > > Carsten Haitzler <ras...@rasterman.com> wrote:
> > > 
> > > > On Fri, 27 Dec 2019 09:23:52 -0600 Brian <bvamund...@yahoo.com>
> > > > said: 
> > > > > Sorry, I've reloaded "E" and can now use proper terms. 
> > > > > Is there a reason the Pager doesn't show the windows open for
> > > > > both screens on the ibar?    
> > > > 
> > > > Because the pager displays the virtual desktops for a given
> > > > screen. each screen has its own virtual desktop set. think of
> > > > it as 2 parent directories with N child dirs (one per desktop)
> > > > and windows inside these. that's why - it's structured this way
> > > > in e.
> > > > 
> > > > There isn't a pager on the ibar. there is a shelf. shelves can
> > > > contain many gadgets. pager is one. ibar is another gadget...
> > > > ibar itself is concerned with launching apps. it happens to be
> > > > able to list (on mouseover of an icon) any windows associated
> > > > with that desktop file that ibar is showing to launch things.
> > > > it has no filtering to filter this list down in any way. same
> > > > for the extra icons it adds for windows as they appear - if
> > > > they match a desktop file somewhere it adds them on the right
> > > > to indicate that app was launched. again - no filtering per
> > > > desktop or screen.  
> > > 
> > > Sorry for my not using the proper terms again based on logic
> > > structure (parent/child is a great example). I now understand
> > > that shelves are screen specific and owned by that screen. That
> > > modules need to be loaded before a gadget will function and
> > > gadgets are added to shelves or desktops.  It seems that once a
> > > gadget is added to a shelf or desktop it can't be moved to
> > > another screen area?
> 
> technically - yes. it's an object in the canvas, but in practice, no
> as the gadget data struct is a child object of the gadget container
> which is child of the shelf. it's owned by the parent and the parent
> controls the lifecycle of the child.
> 
> > > Now help me understand something.  Since the ibar is able to 
> > > run a script for the launchers, which monitors the apps
> > > (regardless of which virtual desktop and screen) and then either
> > > add the app
> 
> it doesn't run any script at all. the c code in ibar uses other e
> infra to watch data structures that represent an executed process
> that link the source of the execution and this structure via various
> means. when windows appear they have properties and there is a bunch
> of code in e that can match back these properties to the information
> in this execution structure thus linking back that window to that
> specific execution action. it's all just code lurking in e that also
> is used to figure out what icon to display in the top-left corner of
> a window for example.
> 
> <aside>
> there are good reasons why i keep harping on about things being more
> efficient when it's all in a single process. things like ibar
> piggyback off code and work already done by e itself for the drawing
> of the border/titlebar and really just hook into it and listen to
> that. it isn't another process where you'd need to come up with some
> kind of ipc to call across from one process to another (and deal with
> all the stalling and context switching, encoding and decoding of data
> as opposed to simply jumping to a function address and walking the
> same data structure in memory that is already there). module/gadgets
> don't even have their own threads. they are pieces of code that hook
> in and "insert". they run as part of the wm and when they are loaded
> their init functions are called where these can set up a bunch of
> stuff. (shutdown functions on unload too). this setup tells existing
> infra to "go register this structure in this list, go create this
> window or this object etc." and thus essentially are as if you
> patched the code of e in a runtime "organized" way. thus they only
> consume the resources that they create in addition to what is already
> there in the core. They are about as efficient as if the feature were
> to be coded in directly, but are loadable and unloadable at runtime.
> anyone can extend e this way with a module (if you are willing to
> write C code). </aside>
> 
> > > to the ibar, ibox, or display a small blue dot to the lower right
> > > corner for the launched app (and a miniature icon of the apps
> > > screen, if the mouse hoovers over the app launcher), why can't
> > > that same
> 
> yes. as above. ibar hooks in linking something it executed when you
> clicked on that icon to a window that exists somewhere and an
> "execution structure" e maintains for everything e may happen to
> launch via it's exec subsystem. e watches the child processes and
> knows when they exit etc. too. ... if this fails it makes guesses
> based on naming of things too. there's a bunch of heuristics there to
> do this.
> 
> > > script logic be deployed for the Pager to show both screens and
> > > miniature icons of the apps on each virtual desktop and screen? 
> > > For example when I use the mouse wheel to show running apps it
> > > will show from both screens and all virtual desktops.  
> 
> it can be. i am choosing not to do it because the pager shows the set
> of virtual desktops for the screen it's on. e specifically divides
> the screens into separately controlled things. the pager decides what
> to show based on the screen it's on. it makes things really simple
> when you do things like plug or unplug a screen. plug a laptop into
> an external monitor and up it comes as it was last configured. if you
> had a shelf with a pager there then the shelf will show the contents
> of the virtual desktops on that screen, unplug the screen and the
> screen along with its pager all go away. no need to add manual config
> to tell a pager to show a specific screen and deal with when that
> screen comes and goes, you don't have to worry about the pager on
> another screen growing or shrinking, and pagers are generally rather
> large thus if they grow to 2x or 3x their size to show 2 or 3 screens
> of content... it's going to create a lot of hassle in trying to lay
> them all out with other content. i need to then start adding config
> to enable or disable this and i have to test that too. i have to deal
> with the situation where content doesn't fit. i have to add more ways
> to indicate which screen is which in the pager (remember screens may
> be disjoint and of different sizes and aspect ratios etc.)... all in
> all it adds a whole bunch of complexity that needs to not bitrot, be
> tested for what is an incredibly small number of users who ever may
> want that.
> 
> in fact i'm going to go on a binge of removing features in e. e has
> far too many. i am not going to willingly add more features unless i
> see them as being widely used and useful or totally necessary, or
> easily tested. there are so many features that have already
> bitrotted. it's time to lean them down.
> 
> but wait... "when i sue the mouse wheel"... the pager doesnt do
> anything with the mouse wheel... are you talking about the actual
> pager or mixing up names? the pager is what displays a grid of NxM
> miniature previews of your virtual desktops with the windows in them.
> there is the old pager_plain which like above... i plan to remove.
> it's a complete parallel implementation of the pager without
> miniature previews from a time before e was a compositor...
> 
> > > Alternatively is there a way that pager of screen 0 can be added
> > > to the screen 1?   I tried to add the pager to the desktop and
> > > move it from 0 to 1.  After moving to screen 1 it takes on the
> > > screen one virtual desktops and drops the screen 0 desktops.
> > > What I'm trying to achieve is being able to see what apps maybe
> > > running on each virtual desktop and screen in a thumbnail.  I
> > > realize that the middle mouse wheel click on any desktop will
> > > show me ALL running apps and whether they are open or minimized
> > > (presence of x) but I like the visual glance over having to use
> > > the mouse wheel.
> 
> explained above. since screens can come and go what do you do with a
> screen that was plugged or unplugged? when you close your laptop lid
> that screen is "unplugged" and so the external screen (if you have
> one) becomes the only screen ... 
> 
> tried using tasks? ibar shows all running apps as icons as i
> explained...
> 
> > > > > Is it because the ibar is also screen specific?  For example I
> > > > > prefer the ibar on the right screen and the default ibar
> > > > > starts on the left, so I setup a Default #2 on the right
> > > > > screen and then delete the Default #1 ibar.   
> > > > 
> > > > ibar lives in the shelf... i think we need to get our names
> > > > right otherwise i don't know what you're talking about... :)
> > > > shelves ARE screen specific. gadgets in a shelf can find out
> > > > what screen they are on (and from that find out what virtual
> > > > desktops exist for that screen and which is currently visible
> > > > etc.).  
> > > 
> > > Thanks I get it now, again sorry for using wrong terms. Thus the
> > > reason I have to build a separate shelf for the right screen and
> > > eliminate the left screen shelf for my preference of where I
> > > launch and see app states.
> > > 
> > > >   
> > > > > Or have I missed something during initial setup that will
> > > > > allow the system to treat both screens as a single unit, thus
> > > > > allowing the Pager will display app windows of both screens?  
> > > > 
> > > > e does not treat screens as a single unit. it expressly is
> > > > designed to treat each screen separately. that is why it can
> > > > switch virtual desktops on a screen by screen basis. this is
> > > > reflected in core data structures. for almost everyone this is
> > > > logical as each screen is a separate physical display unit and
> > > > thus a physical entity etc. etc. and thus each having its own
> > > > state etc. is what makes sense. :) 
> > > 
> > > Cheers and Happy New Year.
> > > > > Pax tecum, absit iniuria;
> > > > > Brian Amundsen, 763-786-5699
> > > > > ------------------------------------------------------------------------------------------------------------------
> > > > > On Fri, 27 Dec 2019 10:27:04 +0000
> > > > > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> > > > >   
> > > > > > On Thu, 26 Dec 2019 09:52:59 -0600 Brian via
> > > > > > enlightenment-users
> > > > > > <enlightenment-users@lists.sourceforge.net> said: 
> > > > > > > Is there any chance that Enlightenment will ever go back
> > > > > > > to supporting two screens with the ibar reflecting the
> > > > > > > programs open on both screens? It's one of the reasons
> > > > > > > I'm not using "E". I like to see what is open on all
> > > > > > > screens and all virtual desktops, something that FVWM
> > > > > > > does with ease.  Iif "E" was able to do that one function
> > > > > > > I'd consider switching.    
> > > > > > 
> > > > > > Ibar shows everything that is open on all screens and all
> > > > > > desktops... that is the only option it has (and has ever
> > > > > > had). It doesn't have an option to limit what it shows to
> > > > > > only what is on the same screen as ibar (or on the current
> > > > > > desktop on that screen).
> > > > > >   
> > > > > > > Merry Christmas 
> > > > > > > Brian Amundsen
> > > > > > > _______________________________________________
> > > > > > > enlightenment-users mailing list
> > > > > > > enlightenment-users@lists.sourceforge.net
> > > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> > > > > > >     
> > > > > >   
> > > > >   
> > > > 
> > > 
> > _______________________________________________
> > enlightenment-users mailing list
> > enlightenment-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> > 
> 
> 







_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Reply via email to