On 28/11/17 14:54, Jean-Philippe André wrote: > On Tue, Nov 28, 2017 at 1:04 PM, Simon Lees <[email protected]> wrote: > >> >> >> On 28/11/17 13:45, Jean-Philippe André wrote: >>> Hello all, >>> >>> >>> I have some terrible news to announce here. >>> >>> >>> In order to alter the behavior and fix oddities in the theme (eg. "left" >>> part for the upper side of a panes widget), add the necessary new >> features >>> (eg. "background" swallows and color classes), and remove unwanted things >>> (ActionSlider, anyone? ^^), we need to branch off the theme for EO >> widgets >>> into a separate category. Eventually this should become the only default >>> theme for EFL 2.0 and could be a separate EDJ file soon. >>> >>> Here are some of the points we're trying to address with this new theme: >>> >>> - simpler naming for groups (eg. "efl/button" for the base group for the >>> default style of a button). This should have benefits both for >> performance >>> (shorter strings, less memory stress) and readability >>> >>> - use color classes / text classes / size classes everywhere possible >> (also >>> with simple names and inheritance, if we manage to find a proper solution >>> in edje) >>> >>> - add "background" swallow in most widgets that could have a nice custom >>> background (eg. a button, frame, etc...). See also 3c47a4f9f9ef77 (can >> and >>> should be improved further). >>> >>> - more consistent part names, they should match 1:1 with the part names >> in >>> EO files. There are exceptions were "virtual" parts are used in EO (i.e. >>> the part is not a real object) or if those parts are sub objects manually >>> managed by the widget. Real parts should be marked as "required: 1" in >> EDC. >>> >>> - more consistent signal names, including a clear definition of "action" >>> and "state" changes. >>> >>> >>> The downsides to this tough decision are quite obvious: >>> >>> - More theme work to do for custom themes (unless you only care about EO >> or >>> only about legacy) >>> >>> - Less testing of the new theme (same as when introducing new classes) >>> >>> - It's a crazy amount of work to make sure everything is consistent and >>> complete. >>> >>> >>> I'll be merging a patch introducing this new theme very shortly. See >> D5473. >>> >>> >>> I really wish there was a better solution but we couldn't find another >> way >>> that doesn't break the existing theme API (which would be totally >>> unacceptable). >>> >>> >>> Best regards, >>> >> >> Before you merge this patch can you make sure elementary_test is capable >> of testing all the parts of "Legacy" and "EO" themes, otherwise as theme >> authors we are not able to test and create these theme parts properly. >> >> I know that if the theme gets pushed first elm test will get forgotten :-) > > > Yes indeed. > The legacy theme won't be touched, that's the whole idea. So in theory > there shouldn't be new bugs. In theory ;-) > > As for the EO theme, it does indeed require extensive testing in > elementary_test. New widgets should get a new theme (copy & paste from the > legacy one, then adapt to make a clean API). > This is also why I've added the distinction in elm_test between legacy and > EO. > > I'll try and make sure proper test cases are added. >
The problem is less breaking themes that already exist but testing new themes i'm creating with the legacy api -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
