On Mon, 30 Dec 2019 10:22:21 -0600 Brian <bvamund...@yahoo.com> said:
> 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. all the modules and gadgets work this way. this is one reason e can consume so little memory and still have a lot of features - we don't make these things separate processes and windows. it's just a little more data structures and work for e to do "patched in" by loading the module that then has e itself run code from that module to do the setup of this extra functionality. > 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. try it and see. > 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. I am not sure what you describe. the window itself, the miniature of the window in the pager? dragging it from virtual desktop to virtual desktop in the pager? .... ? > 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 > > > > > > > > > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
