On 08/29/2016 02:37 PM, Carsten Haitzler (The Rasterman) wrote: > On Sat, 27 Aug 2016 23:28:53 +0000 Andrew Williams <a...@andywilliams.me> > said: > >> After chatting on IRC I think there is another approach. >> The underlying principle is that we have 2 different viewpoints - that >> which elm is FDo compliant - and that which it should be seperate. > > yup. i'm on the "elm has its own theme mechanics and thus this also applies to > icons. it applies to wallpapers in e, and everything else" but there are > peolpe > who want elm to mimic their gtk/qt etc. apps and use those icons. so thus the > option to turn fdo theme use on or off at the elm level. > >> If the elm icon theme were able to hint at which FDo theme it is >> complatible with (if any) as mentioned earlier then we could do this: > > i dislike these things. it breaks the principle of themes being self-contained > data bundles that just work without any data outside of them. > >> *) remove E's "icon theme for enlightenment" checkbox - we should always >> assume you are configuring E > > yes. i agree.
Here I slightly disagree, if E/Elm are using the option to take icons from the elm theme rather then the FDO them should we disable the list? or should it just set the FDO theme for gtk/Qt (Doing this saves having to install a different application to set it) See my other mail. > >> *) update the "icon theme for applications" checkbox to also apply to efl >> apps > > actually i would go for something simpler... just a single checkbox "apply to > e/efl apps too". icon theme is selected and apply, ie to everything and all > apps. including e. e/efl can go off on their own and use icons from their > themes (as long as they exist- fall back to configured fdo theme if not > found). > if you dont like the theme + icons that match together, then that checkbox > will > turn on the "look in fdo first". > > isnt this simplest? is there really a need to configure e separately from > elm/rest of efl here with icons? I don't think we do either, e is a elm app and should just follow its settings you can't pick a different icon theme for gnome and gtk or kde and Qt (you can't even pick a different icon theme for gtk and Qt I don't believe). > >> *) when the user selects an FDo icon theme we iterate through all the elm >> themes to see if any declare a match - and if so and the "icon theme for >> applications" is set then we tell elm to use it's theme instead of the FDo >> one. > > why do this? so complex? select icon theme... have a checkbox "apply to e/efl > too". perhaps clicking/selecting any icon theme will set that checkbox to true > assuming the user wants to see the effects immediately everywhere, e/fl > included. they can then uncheck that if they don't like it. :) > > isn't this simplest? less code, fewer controls in the ui. Again see my proposal. > >> In this manner anyone wanting GTK or ELM specific icons could still run >> their own configuration tool (elm_config will not know how to do the lookup >> to affect other (i.e. GTK) apps when chosing a theme that happens to be >> marked as matching an FDO theme. >> >> Of course that relies on the appropriate theme being installed as well, >> which can be checked for. >> >> I think this accomplishes all the requirements with the addition of not >> being any more complex for the user. I'm not really so sure we should have >> seperate checkboxes for ELM and "GTK" as the non-elm applies to all other >> apps, being an FDo spec that we are trying to comply with. Going with the >> existing "icon theme for applications" to apply to all toolkits seems to >> make sense. >> >> Would this work? >> Andrew >> >> On Sat, 27 Aug 2016 at 18:11 Davide Andreoli <d...@gurumeditation.it> wrote: >> >>> 2016-08-27 17:52 GMT+02:00 Davide Andreoli <d...@gurumeditation.it>: >>> >>>> 2016-08-27 17:23 GMT+02:00 Andrew Williams <a...@andywilliams.me>: >>>> >>>>> I think the complexity is that Enlightenment looks at this all the other >>>>> way around. >>>>> I.e. Choose your theme - and do you want it to apply to apps as well? >>>>> I'm tempted to go in and remove all the complexity and have it be just >>>>> that >>>>> (I.e. Ignore elm vs gtk as seperate values) then it would make more >>> sense >>>>> for elm to try and say what gtk theme matches. But at the moment (in E) >>>>> the >>>>> user could have specified that this is not the chosen behaviour but elm >>>>> won't know that. >>>>> >>>>> My aim in all of this is to provide a consistent experience but maybe >>>>> others prefer the config options approach? >>>>> >>>> >>>> I don't want/need a consistent experience (between ELM and GTK). I just >>>> want >>>> gtk to looks beautiful with it's Mint-X icons and elm to look beautiful >>>> (and be fast) >>>> with the icons embedded in theme. I don't neither use a gtk theme that >>>> match the >>>> elm one, on my system gtk apps are light and elm are dark, I like this >>>> separation. >>>> >>>> Please make a system that permit this type of configuration. Don't forget >>>> the >>>> fundamental E principle: let the user choose ! >>>> >>> >>> After some more thinking about the E config dialog I ended up that >>> list+checks >>> are the wrong choice, if we want to give the user the "power to choose" we >>> need >>> 3 independent lists, so that user can choose the icons for ELM, the icons >>> for GTK >>> and the icons for E itself. This could be made with 2 new tabs, so that we >>> end up >>> with 3 tabs for icons: "ELM icons", "GTK icons", "E icons". >>> ...or maybe on a single page with just 3 combobox. >>> >>> >>>> >>>> >>>>> >>>>> Andrew -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
