Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • Blama
    replied
    This change also fixed this issue in v11.1p_2017-09-12.

    Leave a comment:


  • Blama
    replied
    Originally posted by davidj6 View Post
    I concur with writing just .css overrides to modify a skin rather than copying and modifying the existing skin_styles.css file. On upgrades where new styles have been added by Isomorphic you still get those rather than missing styles. It is usually easy to see them and add overrides only if needed.
    Yes, this would work of course as well for 99% of the changes. But I like it better not to let the users run into this.

    Best regards
    Blama

    Leave a comment:


  • Blama
    replied
    I'll have a look at resizeFonts(). This would mean looking at the debug-modules code and create a method accordingly, correct?
    If this is something you are creating anyway, I'll wait, though, as my manual replacement is complete/almost complete now. I'd benefit then if I'm going to use new features I'm not using now (e.g. charts) so will look into this, then.

    Regarding the CSS modifications: I do as you suggest in the QSG. Your file as base, my modifications at the bottom.
    But as I'm not only adding new stuff, but overwriting most of the time, I need to make sure that my overwrite-selector-list still matches the new one. So there is some kind of manual work included, although it wasn't much for Simplicity the last year. Tahoe is more of a "moving target", though.

    Best regards
    Blama

    Leave a comment:


  • davidj6
    replied
    I concur with writing just .css overrides to modify a skin rather than copying and modifying the existing skin_styles.css file. On upgrades where new styles have been added by Isomorphic you still get those rather than missing styles. It is usually easy to see them and add overrides only if needed.

    Leave a comment:


  • Isomorphic
    replied
    Just a note that you might find it simpler to make runtime modifications of the style sheets ala our resizeFonts() method. This approach could be used to change a given color that we use consistently to some other color.

    Further, since styles "cascade" and later definitions override earlier ones, you shouldn't have to maintain your CSS modifications as a complicated merge, it should be either another file or a series of overrides at the end of skin_styles.css.

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    I'm not sure how you enable this, but if it something like "CSS variables in all browsers, also IE", then this would definitely help and also make management-presentations easier for potential new customers of yours.
    If it is possible to also select a color scheme in the Showcase, this would be great and again make it easier for developers creating POCs to convince management.

    An enhancement to this could also be easy font replacement, which would be valuable for me as well.

    Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    Yes, these are some of the behaviors we're aiming toward - not releasing the SASS scripts, specifically, but easier configuration of the color scheme as a whole.

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    my skin changes are at least 80% copying all css rules that define colors and fonts and overwrite the font and color definition there.
    For Simplicity this is 1000 LOC overwrites with 200 LOC "real" changes / own stuff.
    It's also tedious copy&paste and rechecks/manual WinMerge comparison after a nightly update that does touch the skin_styles.css, because I need to make sure that if the selectors change (which is seldom!) I also change them in my overwrites.

    That is why you are asked from time to time for the internal SASS files, IMHO.

    If it were possible to define colors 1-10 ("main color", "main color pastel 1", "main color pastel 2", "table background 1-4") and fonts 1-10 (named after their main use like "Window header", "ListGrid content", ...), this would enable me to get rid of the overwrites.

    Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    Do you have an image of what you're after? We can ensure the classes are there to do it.

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    Originally posted by Isomorphic View Post
    we've been doing some work on the skin system to better enable new color schemes
    If that means that it will be possible to give a main color and some light/pastel derived colors for e.g. the datePicker-calendar in the future, this is great!

    Thank you & Best regards
    Blama

    Leave a comment:


  • Blama
    replied
    OK, thanks. Not urgent for me.

    Leave a comment:


  • Isomorphic
    replied
    Apologies for the delay - we've been doing some work on the skin system to better enable new color schemes - we'll get to this one shortly and update here when it's fixed.

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    this still looks the same in v11.1p_2017-08-27.

    Best regards
    Blama

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    thanks, yes, those do look way better.

    Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    hmm - it looks like we missed something when porting this fix from 12.0 - we'll fix it today.

    You can see what it should now look like by hitting the 12.0 version of that link you included.

    Leave a comment:

Working...
X