Hi William, In reply to
"I really do not care. I just need to replace ecore_x_init with something that will replace its function for both X and Wayland." Please try to care about the reasons and structure of what exists. Raster was trying to explain why our levels of abstraction are the way they are. If you are asking for an additional layer it would seem very prudent indeed to care about the why's of how we have built this far. As indicated we have application layer APIs such as elm and edje which are abstracted (for the most part - bugs exist) on top of both display (well more if you include OS X etc). If you use them the correct display subsystem should init automatically. It seems like you have run into an issue due to the non-standard way the parent process your app is part of is behaving - maybe we can solve that bug rather than adding a new layer of abstraction? If we truly need a new abstraction can it be articulated as a general use-case rather than a workaround for this particular issue? Thanks, Andy On Thu, 25 May 2017 at 09:02, Carsten Haitzler <[email protected]> wrote: > On Wed, 24 May 2017 23:11:35 -0400 "William L. Thomson Jr." < > [email protected]> > said: > > > On Thu, 25 May 2017 10:16:43 +0900 > > Carsten Haitzler (The Rasterman) <[email protected]> wrote: > > > > > > When invoked via background, not from ENV but arg, its > > > > pe->display=:0.0 > > > > > > i didn't look where you get pe->display but your mail indicated that > > > this is a string that contains the display info... > > > > You see what it contains, 0:0. That is not useful to say X or Wayland. > > it's totally useful for x11. it's 100% useful. it's how you define a local > display in x11. wayland of course works differently in display string > format. > but it's totally useful. > > > > so use that for > > > setting DISPLAY. DISPLAY *SHOULD* have already been set though as > > > this is the normal way for an app to know how to display something. > > > > This is happening via pipes and maybe subshells that do not have access > > to the same environment variables. > > it can be passed along and putenv()'d if that is not the case, but i find > it > unlikely it is the case. you would normally spawn gpg-agent (which is what > i > believe would do the spawning?) underneath your login session which then > would > have the env var. > > > > since whatever environment is executing you is not following these > > > conventions that are more widely supported than a --display > > > argument ... then you have to put this into the environment before > > > efl inits. > > > > Code example? > > i gave you one. my very first reply to "[E-devel] Wrapper for ecore init". > this > exact thread. very very very first thing i said in that reply. > > > > then the env var should be inherited with zero effort on anyone's > > > part. someone has to go to effort to remove the env var to make that > > > not work. as long as "gpg" that spawns the pinentry is spawned from a > > > "display session" where the environment has DISPLAY (and > > > WAYLAND_DISPLAY etc.) set then it inherits this already UNLESS it > > > explicitly decided to nuke that env var. > > > > The environment variables are not present. > > it's nuked them (likely). in fact it explicitly does. gpg-agent.c: main() > > /* Record some of the original environment strings. */ > > it saves DISPLAY. then later in main: > > if (!opt.keep_display) > gnupg_unsetenv ("DISPLAY"); > > so it does nuke it. the reason is so it can provide a client profvided > display > to each pinentry - fair enough. but it can do that by forking then > modifying > DISPLAY env var in the fork then doing the exec() instead of assuming > pinentry > handles specific cmdline args. they chose to do it the argument way > instead and > thus create work. > > > > so it's checking DISPLAY then removing it then executing you and > > > passing it as an arg instead. this smells to me of a whole bunch of > > > extra work that never needed to be done... but either way you're > > > stuck with it unless you patch gpg. you now have to set the env var > > > from the cmdline args as i mentioned. > > > > Set it to what? Guess X or Wayland? Set it via code in pinentry-efl? > > pinentry does not even know about WAYLAND_DISPLAY. it doesn't unset it or > store > or touch it. at least not in 2.1.21 of gpg. it ignores it. so you'll > inherit > whatever gpg-agent inherits from its parent process. > > --display there is a specific x11 display string. that's what it has always > been at any rate. see above. i already gave you the solution in my very > first > reply to this thread. :) > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > > > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
