this will need further work. i want to try and trim this down as much
as i can and make it easy to read/follow and see mistakes (thus the
aligning or afgs in many places)
so i get a new service of type WIRELESS_SERVICE_TYPE_NONE that's going
to suck when accessing arrays by type like wireless does like
array[cs->type] ... so check type value and if its invalid kill off
the cs as we can't do much useful with it. this fixes an actual segv e
gets if you restart the connamn daemon while e runs.
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.
some apps (e.g., wine) do not trigger any event when changing this property,
and they use the property in order to simulate window fade in/out
ref T5370
when grabbing e.g., the top center of a gadget, it feels better to just
have that resize perform vertical adjustments instead of also allowing
horizontal changes
It appears that config.geom.x and config.geom.y specify the corner of
an output in global space, but ecore_drm2_output_mode_set's x and y
are offsets into the framebuffer for the corner of the display.
Just pass 0, 0 and everything will be ok.
this module is not loaded by any other (dependency) nor is it loadable
via the gui - no module/desktop there thus will be hidden... so it's
useless/unused... thus remove it as its not usable by users.
now their build fiels are super easy to maintan. we should expand this
kind of ptterning aross the e build and then expand it to handle new
patters where needed like custom binaries (setuid or not), etc etc.
so we';re missing installing desktop files. edj icon files, wizard
data files in the wrong place, and much more. this also cleans up the
module meson build of pretty much all modules and make their build
files cimple and consistent so it's far easier to re-use things from
one module to the next. we should aim for simplicity, consistency
between as much as possible so we can refactor and turn into maybe
functions later. imho that starts with consistency though. until i can
see all the common patterns clearly, i don't want to write functions
yet. it's easier to see if all the files are consistently using the
same vars and formatting etc. etc. etc.
but either way the installation needs fixing so it installs all files
in the right places with the right permissions etc. etc. etc.
this doesn't fix all module build files bt all the ones i found that
were broken installs and they use what i think is a cleaner/simpler
template, BUT there is far too much copy & pastage here... far too
much.i need to find a cleaner way to automate this.