new feature - polkit auth agent support partly in core (need to have
the pam setuid root auth tool respond via dbus) and partly a module
(the agent dbus protocol handling and setup as well as auth gui). this
took me a while even with all the docs to work out how polkit works...
it was really fussy and its data structs are an extra pain in the butt
to craft with eldbus, but i managed it. not everything is supported
but the core basics are there and this can be built on.
right now the gui is really basic, but does the job.
Summary:
bluez4 support is now basically dead. nothing ships it anymore. bluez5
is a new api that is rather different so new code. also a new gui with
more complete features etc.
not everything is done as i'd like. need:
1. many more icons for device types (60-70 maybe?)
2. a few specific custom icons for some action buttons (like
pair/unpair)
3. icons for group headers
4. gadget status - the gagdte itself displays zero status. it's a
button to display a popup. that's all.
Reviewers: zmike!
Subscribers: devilhorns, cedric
Tags: #enlightenment-git
Differential Revision: https://phab.enlightenment.org/D6148
there are a few systems out there that are checking the .so files that
are linked dynamically into a created shared library. This leads to a
problem, since the .so files often also carries unresolved symbols,
which are resolved by other dynamic linked .so files. However, to ship
arround those picky systems, we are not reacting to unresolved symbols
at all for now. The error will rise at runtime and come up in a nice
little dialog instead.
this fixes build on bsd
this makes modules with a binary helper simpler to build using the
parent module build harness as much as possible. i probably could
simplify this down to a single binary only and it is either setuid or
not... define the deps and flags ... it could be a bit simpler. not
much. i also removed the if's in the build for battery and ifdefs in
src handle it instead (imho simpler to maintain in src). sysinfo still
uses the if's there.
config that is only needed fro modules only needs to be don in the
modules subdir meson.build... i tried doing what modules do but output
files cant have paths.
a reason for doing that is that you can just pack together targets into
a array and pass them to our helper, and the helper will just handle
them, so even module with eldbus codegen etc is now supported.
This also means that we are just passing the src object directly into
the shared_module call, which means the user of our helper can just pack
everything he needs into the src var and the helper does not need to
know about it.
now mdoule build files that fllow one pattern (the most common by far)
all JUSt list their souce files and nothing else. this really cuts
down on build size/complexity.
there are other patterns too (no icons at all) that i'll do next, then
we're down into "weird" land where i'll have to think of some more
interesting ways to deal with this.