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
