OK - solved the style issue - I wasnt looking wide enough and a colleagues code had polluted the styles in a mod to the main menu - so at leas the checkboxes are back and I've learned how to force scope for CSS - another layer of contract UI mods have to adhere to.
On Friday, 22 May 2020 10:28:58 UTC+10, Rob Atkinson wrote: > > > > On Friday, 22 May 2020 05:29:20 UTC+10, Richard Cyganiak wrote: >> >> >> >> > On 21 May 2020, at 07:00, Rob Atkinson <[email protected]> wrote: >> > >> > tested this on a colleagues machine using the exact same version and >> build of TBC, and the search works fine out of the box. I created a fresh >> repo and reran the same configuration script and it still fails. >> >> Sounds like the search problem is related to the configuration script >> then? >> >> unlikely to be directly causing it as the same script is used in all > three cases, and one case finds content and the other two dont - but I > expect there is some critical piece of metadata missing, and some local > config - like the selection of icon choices - that affects the UI behaviour > - so its narrowing down what it may be then identify the mechanisms to > enforce a necessary configuratin. > > >> > The UI is different too - i have a gear icon and a broken CSS and he >> has a series of icons in the tab. (both using chrome). >> >> In the page header there is a button with three vertical dots. It opens a >> menu that has a checkbox for “Display Edit Actions as Icons”. Sounds like >> your colleague has that checked and you have it unchecked. >> > > OK - thats cool - I hadnt discovered that (it would make sense that this > would be available as some clue on the gear icon itself - such as a hover > - or maybe a last option in the drop down to say "show settings as icons" - > too many places to look > >> >> I've looked through the EDG stylesheets for 6.3.2 and didn't find >> anything that looked like the style rule you reported. That means it could >> be a rule generated dynamically by some JS code. I'll ask colleagues about >> that possibility. >> >> It could be a local customisation in your workspace. Does your workspace >> include any .ui.ttlx files that do anything with ui:Script, ui:Style or >> ui:override, ui:headIncudes? Sorry for making such allegations. It's >> difficult to investigate these things. >> > No worries- fair enough! No - (I have overriden this in a custom SWP > _beacuse the style was broken_ and I needed to access the checkbox. I did a > brute force text search and the only style that looked like this is > > .chosen-container-single.chosen-container-single-nosearch .chosen-search { > position: absolute; > left: -9999px; > } > > in TopBraid/SWA/assets.www/lib/chosen/chosen.css > > Looking at the styles in chrome dev tools - it doesnt claim this style > came from any particular CSS element - so I think this means it was > injected programmatically by some JS - and my guess is that is what the > "chosen" CSS is doing. > > certairnly I've never touched these styles - only custom CSS is for > customised logos and icons. > > > > >> Richard > > -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9419c0ca-eb2b-4c67-9c18-562728f30994%40googlegroups.com.
