On Thu, 22 Jun 2017 00:05:45 -0400 "William L. Thomson Jr." <wlt...@o-sinc.com> said:
> On Thu, 22 Jun 2017 11:56:50 +0900 > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > you keep going on about "what do users do". use whatever display > > manager you like. we install xsession desktop files so it'll be > > listed in the available sessions along with everything else... we > > dont have to do anything more to be user friendly at all. > > Yes in a way, but have to rely on login managers designed for other > desktops. Not a bad thing some may have them installed already but can > have other issues. or use the various ones not designed for any desktop (lightdm, slim, xdm ... and many others) :) i don't see that it matters if the de is designed for the desktop or not. it works (or should) and it's what you already have installed and is user friendly to just clicky-pointy at the session to you (ok xdm doesnt support that... but others do). :) > Like in my case SDDM prevented E from turning off the backlight and the > cursor stayed visible when the display was turned off/screen saver. I > thought it was a bug in E, but it was something with SDDM. When I start > E under entrance, that problem goes away, every time. smells like a bug in sddm. > I would have gone off filing an E bug to something that has nothing to > do with E. All because of what I used to start E, something intended > mostly for another desktop/project. Not to mention the GTK/Qt vs EFL. > > Should E be responsible for bugs that occur when started under SDDM? no. then use another that doesn't have the bug. > > in this > > thread we talked about what we should do in future for a wayland > > world where we'd recycle e as the login manager. yoz already said > > that that is in fact his plan and that means the entrance code and > > project itself is "dead". > > Yes so its strange the reaction I got a first. Surprise, surprise, > entrance is not dead. The topic of this entirely thread. Its alive! :) > It is dead to you all, but I will revive it till there is another, and > maybe beyond such. > > I am logged in now via entrance as I do on my desktop :) > > > > Yes I have been following the thread. If E is the log in manager, > > > how do you log into other stuff if needed? > > > > i explained that already. > > I missed that. I get the future log in manager using E would allow > log in to others. I was meaning more in your case, where you log > straight into E from systemd service/startx. i also explained that. i never log in as anyone but me. i am the sole user of my desktop. i never switch the login session - ever. if e has an issue and cant start - i go off to a text console and fix it (the very rare occasions i have to do this i'm very unhappy and often just revert any commit i found that broke e). > Seems like a basic systemd service file that invokes startx or > something to that effect. Its semi moot to me, as I do not use systemd. > Just something that could be provided/installed for users to use. > > > that's exactly how e started... if others find it nice and like it - > > great. if not... doesn't matter too much. > > Good to know. I am more of the mindset that it matters that others find > and use it, maybe leading to further development, etc. Growing things. and that's great! it takes all types. not everyone has the same outlook. if i did it totally just for users - e would be a dead project long ago. because i have done it primarily for me, such stubbornness pays off and keeps it going and alive even through the hard times. there are pluses and minuses to both approaches. > > so i'v explained that all this "just use systemd user session" etc. > > stuff is what we devs do. we're not telling users to go do this. use > > whatever login manager u like. > > I got the basic concept long ago, more asking to show the code, > technical details of how. Or better yet, add such systemd to efl, so > its installed by default, and users can use that. someone already pointed to the arch wiki on this... i believe... :) > Then there is a way now for users to start E via systemd from X or > Wayland if they choose. Or they can use some DM. > > > i don't use it. bu5hm4n does not want it to be part of e and wants it > > separate. that rules it out for me and for any future login manager > > based on e (not entrance). that's his choice. > > I never got that impression. SDDM is separate of KDE, but has been that is exactly what he's said to me directly on irc. he wants it completely separate from efl (spawny) from memory (and you then have to go install special greeters for it that are separate and may or may not use fl or something else). i dislike the idea of depending on just a simple external "spawner" as peolpe complain bitterly about dependencies already. spawny will not be packaged in any distros at this point, so shipping your own spawning logic is what makes sense. if he doesn't want spawny to integrate/ship with e or as part of it... guess what? e will have to replicate it itself. > adopted as the official/default DM for KDE, in place of KDM, > discontinued. Not sure why being another project should matter. > > My impression seems his solution is being overlooked and discussion and > effort put into something else rather than using his work. i have known about it long before you knew about it... and unless the above situation changes... i don't think its viable. reasons given above. i am not saying it's bad code at all or passing judgement on it other than "it would add an external dependency that is entirely not common and that would annoy people severely to have to go build it in addition to efl and e and so on". we merged efl from about 15 libs/projects to 1 and 99% of people have been elated and happy with the move. having e split up EFFECTIVELY by relying on core features like login manager with external "totally uncommon"separate projects is bad for usability. i'm totally happy to adopt spawny into the e tree and make it part of e if marcel is happy with it too. > As for me, I would be more encouraged to package spawny and anna, and > likely others for other distros. If it was the adopted/official DM for > E. While remaining its own outside project . as discussed... i'd want to have e and e's dm tightly integrated. having them be loosely related projects does not make that fun or easy and integration is harder. hes e should be able to spawn any De but if the De is e it'd be extra slick™. > > not interested because of all the reasons given. doing a custom gui > > means eventually having to write al the multi-screen handling code > > and power management and what not over again. re-using e and all of > > its support and infra makes far more sense. > > Maybe for logging into E, but not so much for logging into other stuff. no - this was totally irrespective of the De you log into. see the previous mails. it's features you want while you are not yet logged in. close laptop lid while at login screen and it suspends properly. screen dims appropriately and blanks while not logged in (and can be configured by the admin with some clicky pointy buttons in the ui). they should be able to manually shut down, reboot, suspend, hibernate etc. from the login screen. it should be able to be configured to handle multi screen setups as the user desires (have 3 screens? middle screen gets login box, other screens just show images). maybe show clock, calendar, system temperature and other status things while on login screen that e is also doing (re-use the same gadgets). this is totally unrelated to the desktop you then later log into. it could be gnome, kde, sway or anything else. > I get what your saying. Though I would think much of that type of code > to be in say EFL via Elemenary for re-use. E, Entrance, Spawny/Anna, > etc. Plus X handles some of the power management, maybe different for > Wayland. My display goes to sleep with entrance running. here it just doesn't make sense to put these into efl as it would also clearly define the ui, menus and other stuff... it makes more sense to just roll it into e so if you install you ALSO get a login manager for free at the same time you can use. the recycling of config dialgos makes it immensely usable then as to configure your DM - just log out and clikc that "settings" button - it asks for root passwd and if authed correctly, pops up the same settings panels you see in desktop e... (we need to re-arrange these panels in e eventually anyway). > > if you want usable, use whatever login manager your distro uses 99% > > of distros have a default one they come with. only a few don't. we > > have no "works everywhere" replacement at this point. > > Distros that ship a single desktop likely have a single DM. Not so sure > about ones that provide options. Though I assume if one installed say every distro 9escept arch and debian) i have used provides various dm's .. but one is installed by default but you can always install one of several others - apt-get/pacman/whatever install it and set it up to run instead of the current one. > KDE or Gnome without specifying anything else on most distros, They > would likely get the DM for that given desktop GDM/SDDM. That may vary > from distro to distro. > > For reasons stated with my experience with SDDM and E. It likely is > best to use say a QT based DM for a QT based Desktop. A GTK one for a > GTK based Desktop. A EFL one for a EFL based desktop. Prevents conflicts > from each or odd bugs/issues like my backlight/cursor issue via SDDM. your issues dont seem to stemp from qt or gtk - but from more deep stuff like maybe a process that hangs about (client) connected to that is setting up stuff and fighting with e over dpms etc. settings. most likely. > -- > William L. Thomson Jr. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
