I have a sets of users that I need to create themes for. Depending on the user's account association I want to load different themes. For example if John Doe logs in I need to load up greenteam.scss. However, if Doug Smith logs in he should see blueteam.scss.
Those files are basically color and font settings used by other elements. greenteam may have $header-bg: green; and blueteam would have $header-bg: blue;.
My initial thought is to have a structure like this: /src/scss/client/_client-xxx.scss that says the background colors, font colors, etc variables set in the application. So, after login the system is told the person logged in is part of "greenteam" and /src/scss/client/_client-greenteam.scss is loaded to compile the colors and other settings together. This way I can just drop the new client theme in the directory and boom, new theme!
The number of "teams" is going to grow exponentially. I have no idea how many I'll ever have at any given point. This is why the "just change the body class" is worrisome as that will get very big and hard to manage.
It's also possible I don't have a good grasp on how angular builds itself out on the web as a user calls the pages/styles. It appears, at a glance, when deployed on the server angular compiles the scss down to css in the header and not loaded "on the fly". If that's the case it seems I'd have to load all the possible client css options and just show what matches (the body class route).
The user won't have control over their theme directly or be able to change it, the theme will be customized manually by a developer.
I would have suggested to change the body class, but, if you really want to apply css at runtime, you could try to:
compile the scss to css
insert it in the dom at runtime depending on the user
Check this topic which tells how to add a style at runtime, you could get the text content of the stylesheet from a database:
https://stackoverflow.com/a/524717/10899694
Is there a way to style google chrome default pdf view? I'm trying to change the gray background color to white also make the scroller little bigger for mobile devices if possible.
I tried to target it on css with no luck
// pdf viewer custom style
iframe {
html {
body {
background-color: #ffffff !important;
}
#zoom-toolbar {
display: none !important;
}
#zoom-buttons {
display: none !important;
}
}
}
It looks like it's creating shadow document on the html but I couldn't find any way to target it
There is no way to directly style the Chrome default PDF viewer (PDFium). Because the plugin displays and controls content outside the scope of the current page's DOM, it can only be modified by the plugin. As indicated here it is impossible to make modifications to this sort of plugin controlled content unless the plugin also adds a content script that allows the page to pass messages to the plugin; the plugin must additionally be programmed to respond to messages and appropriately update the content. In other words the PDF viewer uses a separate DOM to the page which is not directly accessible. Instead you need to access an implemented API.
In this discussion Mike West (Google/Chromium dev) states, in answer to a question on DOM accessibility in Chrome's PDF viewer:
The functionality available in the PDF viewer is (intentionally) fairly limited ... The APIs you're having trouble finding simply don't exist.
Basic API functions are some of those specified by Adobe in their Parameters for Opening PDF Files and are accessed through the URL (eg http://example.org/doc.pdf#page=3&pagemode=thumbs. They are, as indicated above, quite limited, allowing the user to go directly to a page, set zoom factor, show thumbnails etc. Accessing an expanded API through content script messages can potentially be done if you know the available JavaScript messages. A complete list of available JS message names can be determined from the relevant PDFium source here from which it can be seen that advanced styling of the viewer, such as changing colours, isn't possible. (This question gives an example of how to implement the API). Certainly there is no access to PDFium's DOM.
This API is deliberately left undocumented; it may change with additions or removals at any time. Thus, while it's possible that in the future there will be an API to let you style some aspects of the viewer, it's very unlikely that any would go so far as to change the background colour or modify a CSS shadow. And, as stated above, without an API you can't modify content controlled by a plugin when you don't have access to its DOM.
You may, instead, wish to try PDF.js. It is an open source JavaScript library that renders PDF files using HTML5 Canvas. It is also Firefox's default PDF viewer and is quite capable.
Implementing it as a web app is beyond the scope of this question, but there are many helpful tutorials available. And as you, the developer, will have access to all constituent files, you will certainly be able to style the PDF.js viewer as much as you wish.
Just paste this into your browser console.
var cover = document.createElement("div");
let css = `
position: fixed;
pointer-events: none;
top: 0;
left: 0;
width: 100vw;
height: 100vh;
background-color: #3aa757;
mix-blend-mode: multiply;
z-index: 1;
`
cover.setAttribute("style", css);
document.body.appendChild(cover);
Update: Recent versions of Chrome seem to have moved the PDF viewer resources out of resources.pak and into the browser binary itself. It should still be possible to download the Chromium source, edit the files described below, and then recompile, but that's much more painful than simply hacking resources.pak. Thanks, Google.
As a matter of fact, there is a way, but we've got to get our hands dirty, and the process must be repeated every time we update Chrome. Still, to me, the effort is well worth it. I like to change the PDF viewer's background to white, so that when I activate the color-inverting Deluminate extension at night, I get a nice solid black background. It's so much easier on my eyes compared to the default background, which, when inverted, is blindingly bright.
The Chrome source tree contains thousands of HTML, JS, and CSS files that control the behavior and appearance of many parts of the browser, including the PDF viewer. When Chrome is built, these "resources" are bundled together into a single file, resources.pak, which the browser unpacks into memory during startup. What we need to do is unpack resources.pak on disk, edit the files that style the PDF viewer, and then repack the bundle.
The first thing we need is a tool that can unpack resources.pak. The only one that I know of is ChromePAK-V5. It's written in Go, so we need that to build it. We also need to install a build-time dependency called go-bindata. Here's how I went about it:
cd ~/code/chrome
go get -u github.com/jteeuwen/go-bindata/...
git clone https://github.com/shuax/ChromePAK-V5.git
cd ChromePAK-V5
~/go/bin/go-bindata -nomemcopy -o assets.go assets
go build
cd ..
Now that we've got the binary ChromePAK-V5/ChromePAK-V5, we can use it to unpack resources.pak. In my case, running Chromium on Linux, the file is located at /usr/lib/chromium/resources.pak, but it might be somewhere else for you. Once you've found it, copy it, make a backup, and unpack it:
cd ~/code/chrome
cp /usr/lib/chromium/resources.pak .
cp resources.pak resources.pak.bak
ChromePAK-V5/ChromePAK-V5 -c=unpack -f=resources.pak
At this point, the files we need will be located somewhere in the resources directory. Now, in the original Chrome source tree, these files all had sensible paths, such as chrome/browser/resources/pdf/pdf_viewer.js. Unfortunately, these original paths are not recorded in the resources.pak file. ChromePAK-V5 tries to be clever by using a table that maps the SHA1 hashes of resources files to their original paths, but over time, files change, along with their hashes, and ChromePAK-V5 can no longer recognize them. If a file is unrecognized, ChromePAK-V5 will unpack it to, e.g., resources/unknown/12345. And, in general, these numbers change from one Chrome release to the next. So, to find the files that we need to edit, we basically need to grep for "fingerprints" that identify them. Let's get started.
The background color of the PDF viewer is controlled by the file which, in the Chrome source tree, is named chrome/browser/resources/pdf/pdf_viewer.js. To find the file, grep inside resources/unknown for the string PDFViewer.BACKGROUND_COLOR. In my case, the file was unpacked at unknown/10282. Open this file, and change the line (at/near the end of the file) that sets PDFViewer.BACKGROUND_COLOR. I changed it to 0xFFFFFFFF, i.e., white (which becomes black under Deluminate).
Going further, we can also restyle the PDF viewer's toolbar. By default, the toolbar is dark, so it becomes obnoxiously bright under Deluminate. To fix that, we need to find chrome/browser/resources/pdf/elements/viewer-pdf-toolbar.html. I found it at unknown/10307 by grepping for shadow-elevation-2dp. What I did was to go to the #toolbar block and add filter: invert(100%);. Voila, no more blinding toolbar at night.
Finally, if we really want to go all the way, we can get rid of the brief "flash" of the original background color that occurs when loading a PDF. This color is controlled by chrome/browser/resources/pdf/index.css, which I found at unknown/10304 by grepping for viewer-page-indicator {. I changed the background-color property of body to white (i.e. black under Deluminate).
The hard part is now over. The final step is to repack the resources and overwrite the system resources.pak:
ChromePAK-V5/ChromePAK-V5 -c=repack -f=resources.json
sudo cp resources.pak /usr/lib/chromium # or wherever yours should go
Now restart the browser and enjoy!
A codeless approach is to install a tampermonkey plugin.
https://greasyfork.org/en/scripts/437073-pdf-background-color-controller
This is very useful if you are reading a pdf via a browser and just want to change the background color.
In Alfresco Share the Search page is implemented with Aikau.
I'm interested in the more general question, is it possible to Debug Aikau widgets?
I have founds some links on this matter, but they talk more about logging and not actual javascript debugging:
http://docs.alfresco.com/5.1/tasks/dev-extensions-share-tutorials-debugging.html
https://github.com/Alfresco/Aikau/blob/master/tutorial/chapters/Tutorial4.md
Suppose I have the following Aikau widget alfresco/search/AlfSearchResult and the following method inside it:
/**
* This function is called to create a
* [SearchResultPropertyLink]{#link module:alfresco/renderers/SearchResultPropertyLink} widget
* to render the displayName of the result. It can be overridden to replace the default widget
* with a reconfigured version.
*
* #instance
*/
createDisplayNameRenderer: function alfresco_search_AlfSearchResult__createDisplayNameRenderer() {
// jshint nonew:false
var config = {
id: this.id + "_DISPLAY_NAME",
currentItem: this.currentItem,
pubSubScope: this.pubSubScope,
propertyToRender: "displayName",
renderSize: "large",
newTabOnMiddleOrCtrlClick: this.newTabOnMiddleOrCtrlClick,
defaultNavigationTarget: this.navigationTarget
};
if (this.navigationTarget)
{
config.navigationTarget = this.navigationTarget;
}
new SearchResultPropertyLink(config, this.nameNode);
}
Is there any way I could insert a breakpoint and stop execution at the line where this.currentItem is used in order for me to evaluate it's properties?
Yes, there are several ways in which you can debug Aikau... the first thing to do is to make sure that you're running with "client-debug" mode enabled (either in Share or in your custom Aikau client).
For example, in Share you'd want to update the /WEB-INF/classes/alfresco/share-config.xml file to change:
<config>
<flags>
<client-debug>false</client-debug>
...to be...
<config>
<flags>
<client-debug>true</client-debug>
You'll need to restart Share for the changes to take effect. You'll see then that you have a "Debug Menu" item in the main header menu bar. If you open this you can enable logging by toggling "Debug Logging" and "Show All Logs" to be true.
This will result in logging output appearing in your browser developer tools console. You can also fine tune the logging output to only show errors or warning and to provide a RegEx expression to match certain logging output.
With client debug enabled the JavaScript source being loaded by the browser will be uncompressed. This will make it easier for you to add break points.
Because Surf aggregates all of the required module source code into a single resource (for performance and caching reasons) you will want to find the Aikau source file - the easiest way to do this is to use "CTRL-P" (in Chrome) to open a resource and type "surf" into the box that appears - this will always find the Aikau source code first.
Firebug for Firefox handles finding across resources better, so you can just used "CTRL-F" and then paste in the line you want to break on.
You can add breakpoints in this resource as you normally would and the browser will break on them.
As well as setting break points you can also use the DebugLog widget. This can be toggled from the "Debug Menu" and shows all the publications and subscriptions that are being made.
It is also possible to directly include and configure the alfresco/services/LoggingService and the alfresco/logging/DebugLog widgets in your page as you are developing. We take this approach for all our unit test pages. This can be a handy approach during development and they can be removed when you're finished developing.
This presentation although quite old, also contains some useful debugging tips (see slide 56 onwards).
Im developing a site and I would like the page to refresh when a change is detected to a CSS file. I used to be able to do this easily with the following bookmarks, but now none of them work on Chrome.
http://david.dojotoolkit.org/recss.html
http://calvincorreli.com/2006/02/13/re-recss/
http://www.paulirish.com/2008/how-to-iterate-quickly-when-debugging-css/
I cant change the HTML of the site im working on so I cant use the livereload app. Ideally I would keep using Chrome but I would switch to another browser if necessary.
You have two ways:
Edit css file and use livereload to reload it automatically in Chrome
Change your CSS in Chrome and save it (without IDE using).
About livereload(it works not for css only).
Use livereload. You need download Livereload 2 and add javascript file to your page or use Chrome extension.
This script is meant to be included into the web pages you want to monitor, like this:
<script src="http://localhost:35729/livereload.js"></script>
LiveReload 2 server listens on port 35729 and serves livereload.js over HTTP (besides speaking the web socket protocol on the same port).
A slightly smarter way is to use the host name of the current page, assuming that it is being served from the same computer. This approach enables LiveReload when viewing the web page from other devices on the network:
<script>document.write('<script src="http://'
+ location.host.split(':')[0]
+ ':35729/livereload.js"></'
+ 'script>')</script>
However, location.host is empty for file: URLs, so we need to account for that:
<script>document.write('<script src="http://'
+ (location.host || 'localhost').split(':')[0]
+ ':35729/livereload.js"></'
+ 'script>')</script>
LiveReload.js finds a script tag that includes .../livereload.js and uses it to determine the hostname/port to connect to. It also understands some options from the query string: host, port, snipver, mindelay and maxdelay.
From GitHub
About changing CSS in Chrome devtools.
Just take a minuit and watch a demo from Paul Irish
Maybe it can fit your needs, since I don't know what editor you use there is two nice ones with embed live editing, are: Brackets IO (free) and JetBrains WebStorm. If you dont ever want to change editors, like Pinal said, Livereload it's a good one, but sometimes its litte bug to make it, but it's a good choice!
You can use Code Kit https://incident57.com/codekit/ and get the free trial and use it for 10 days or you can buy it for $29, I think its totally worth it. You can use Fire.app also http://fireapp.kkbox.com/. Tincr is also a nice app you can use and I think this one is free http://tin.cr/. Hope this helps!
Do you see any errors in chrome console? all 3 bookmarklets work fine for me on chrome 35.0.1916.153.
The change might come from your sites server, e.g some servers block requests with additional parameters. In that case you'll need to modify bookmarklet to not add it.
I would like to be able to change the colors of a few items, and add a <hr/> to the bottom of the default page. Looking to distinguish between DEV / QA / PROD environments with subtle color changes. I guess I am looking for the master/default index.html/jsp page or the main CSS file.
According to SAP, these objects are wrapped within a jar file, inaccessible to clients. So, there's your answer to that one.