Closed lots0logs closed 8 years ago
@sbalneav That's a good idea, I like it. Though my reasoning for this was to make the antergos logo on the default theme easily changeable (to ease cross-distro packaging) so we dont really want an "icon", make sense? In any case your idea is still a good method of achieving the result I was aiming for. Perhaps we could add the icons directory and also add branding image or something like that. Thoughts?
Yeah, I just kind of threw "icons dir" in there as an example. So long as the name's standardized, you could literally return anything using this general method.
I am somewhat thinking perhaps rather than return it under the "lightdm" object (which, depending on the names we pick, might have the possibility of conflicting with a lightdm api name in the future), we create a new object to return these sort of variable names under. Maybe something like "distro"?
Then we could have (potentially) a bunch of "distro specific" variables returned:
distro.branding_image distro.iconsdir distro.background_images distro.etcetcetc.
All of which are simply a AC_SUBST in the configure.ac.
If you like the object name "distro", I could look at coding that up tomorrow.
Okay..hmm..how about we go with branding as the object. Then we can have:
branding.logo
branding.icons_dir
branding.bg_images
branding.bg_thumbs
...
branding sounds fine to me, I'll code it up.
https://github.com/sbalneav/lightdm-webkit2-greeter/commit/0bf360f179f66fe83227885e8e2604fc11d3bfcf
Done.
Define what you want in configure.ac, Create a simple "string_or_null" callback, just add callback to the "branding_values" struct. easy-peasy-lemon-squeezy
Cool, I'll pull those in now. Though I'm now wondering if this would be better in the config file so that the user can modify the values without recompiling the package. What do you think @sbalneav ?
Well, that will require a slightly different tack, but may be more flexible in the long term. Try this:
In the config file, we have a branding section:
[branding] key1 = value1 key2 = value2
Keys can be anything.
Instead of static string values, the branding object simply contains one method:
branding.get_key("keyname")
which will, of course, return the associated value. All we have to do on greeter start-up is just scan the config file, and build a linked list of structures of { char key; char value }. Then the method will simply scan the list, and if it finds the keyname, return the value. This way, distro packagers or theme builders can put any darned thing they want under the [branding] heading, and it will simply be available to them. Sound workable, @lots0logs ?
@sbalneav Yeah, that sounds good to me. I tried to do it last night but, since I am not very well versed in C, I got stuck trying to figure out how to create a GVariant
dict of the config file keys and values to pass from the UI to the Web Process :grimacing: I will push what I have so you can take a look at it...
@lots0logs have a look at: https://github.com/sbalneav/lightdm-webkit2-greeter/commit/20f11900a2877922893d97149be0ed5c31ebd4df
'branding' has been replaced with 'config', and 3 methods are added: get_str, get_num, and get_bool
So, if you add (in the config file):
[branding] logo-image = /usr/share/images/anteragoslogo.jpg
and then in a greeter, say:
config.get_str("branding", "logo-image");
you'll get the result back as expected.
Have a look at this:
https://github.com/sbalneav/lightdm-webkit2-greeter/commit/0be42d27d440ec7848cb16db986943c6f704d39d
This adds a callback that basically directly returns a configure.ac variable under the lightdm object. If you wanted a variable to directly return a "distro icon", you could simply define it in configure.ac and return it in this way.