On 05/25/2017 09:50 PM, Carsten Haitzler wrote:
On Thu, 25 May 2017 10:42:29 -0400 "William L. Thomson Jr." <[email protected]>
said:
On Thu, 25 May 2017 08:41:38 +0000
Andrew Williams <[email protected]> wrote:
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.
It is not practical for every problem encountered to learn why the
world is as it is now.
then stop going on with your mails and take the very first advice given if you
don't care why. follow it and don't keep discussing the issue. if you want a
discussion then that's fine but don't actually continue with the discussion and
say "i don't care (what you have to say)".
To which I reply ... +1 old man
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.
I am not as interested in EFL development as I am EFL application
development. Issues with application development does not mean I need
to understand how EFL was designed per se. Just what I need to know to
accomplish a given task.
Simple requests can be denied without the need for detailed explanation.
you did keep digging for another solution even though one was presented
already... what do you expect when you start digging deeper? you'll get more
details!
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?
Abstraction or not, function/code exists in one that does not the
other. Which either such code should be removed entirely. Or a layer
made for abstraction for both.
It is basically saying this code exists, but do not use it. Ecore X
code exists say for grabbing. But does not for Wayland, so do not use?
Why is it there then? Should it be deprecated, legacy etc?
i gave you the very simple solution to set the env var with the string you
already had parsed (well pinentry parsed it for you and stuffed it into a
struct) and putenv() that. the very first thing i advised was to do that. you
keep trying to look for other ways of doing it.
so if you keep on wanting to dig for other ways you'll end up being given more
information as to why such an api doesn't exist or is not portable etc. (it
doesn't need to exist actually because you can set env vars).
Not something I care to discuss. But if EFL devs say to EFL app devs
that all apps must work in Wayland, X, etc the same. Then EFL app devs
need the tools for such.
we do have the tools. gpg/(gpg-agent) specifically mess with how this normally
works (99.9999% of the time). they explicitly remove the information from the
environment that tells us how to display. they move it to a cmdline argument
which means it creates work for you since the information is no longer in its
normal location (an env var). you can do that work, just do it as i originally
described. we don't need to provide any new tools. everything you need is
there. it's the gpg guys that have forced you to learn about setting env vars
that you would not need to know otherwise (if they set them before launching
pinentry) and things would "just work".
i could explain why env vars are the "right way" but given your current
responses to help and information, i suspect you'll imply i should shut up by
saying "i don't care", so just take the first advice given unless you are
willing to have a discussion and learn something as a result. or do whatever
you want. it's your code.
------------------------------------------------------------------------------
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
