I am working in an environment with multiple servers and would like to share my .jupyter configuration amongst the servers such that I don't have to keep them in sync manually. This can be achieved easily by setting the JUPYTER_CONFIG_DIR environment variable to a shared location.
However, I would like to use different CSS style sheets for each server such that it is obvious which one I am working on. For example, on the first server, I would like to have a red background:
#notebook { background: red; }
and on the second, I would like to have a blue background.
#notebook { background: blue; }
I thought I might be able to achieve this by appending different paths to the extra_static_paths depending on the hostname of the jupyter server. However, the HTML of the notebook looks for custom/custom.css and the files indicated by extra_static_paths are served from static/... such that I cannot replace the custom css file in this manner.
Is there a better approach?
I think that can be achieved with profiles, but the documentation is scarce on the topic.
EDIT: I was wrong. According to this question the profiles are gone since jupyter 4.x, so unless you want to go into managing shared directories and files through bash scripting, it seems the following is the only solution.
While technically a workaround, this might be preferable: use the Stylish browser extension. I use it to quickly1 swap between the notebook's default white theme and a darker one.
How Stylish works
Basically it injects custom CSS in the pages that are matched by a rule at the top of a theme. You can write your own CSS theme or download one from their website. For a jupyter example, I am using this one. It matches on the following rules:
url-prefix("http://localhost:8888/"),
url-prefix("http://127.0.0.1:8888/"),
url-prefix("http://localhost:8889/"),
url-prefix("http://localhost:8890/")
What you can do is duplicate this theme and have each one of them match on a single port, which corresponds to the server where you want it applied. Then you can start your servers with the --port=xxxx option.
1 -- You can change the notebook's theme by placing a custom CSS file somewhere in the jupyter's config directory, but if you want to change it on the fly you have to replace that file every time. With stylish, the change is 1 click away.
Related
I want to edit the style of multiple applications inside my workspace with the less amout of effort. What I mean by "edit the style" is font size, background color, position, etc.
My idea was creating a CSS file at "Static Workspace Files" with the classes I want and applying them to the apex items needed. Applying this in a region for instance:
*.font16{
font-size: 16px;
}
The problem is: modal pages can't find the file, which is not a problem in nomral pages. I'm using the path '#WORKSPACE_IMAGES#styles.css' in the page "CSS > File URLs" setting.
I'm not sure if this is the right approach, maybe I should edit Themes or Templates, but since I'm pretty new to Apex I chose CSS for familiarity.
Application Express v20.1
That's what Static Workspace Files are meant for, files that can be used by multiple applications in the same workspace.
The easiest approach for this is to create a CSS, like what you've done.
You don't need to inlcude the file in every single page, which would become a maintenance nightmare eventually.
You can simply include the file at the application level:
In Share Components, go in the User Interface Attributes and include the file under Cascading Style Sheets.
I usually have one global.css file (as a static workspace file) for anything common to all my apps and one app.css per application (as a static application file) for things specific to the current application.
Note that application exports will contain the static application files, but they will not contain the static workspace files. You will need to export/import them yourself.
Did you try Theme Roller? Run the page, it is down in developer's toolbar.
I've built a library that will be used by several Angular applications (multiple teams and no monorepo). This library includes a scss-theme. This theme uses two SVG-files. However, I can't get it to work. The path is always incorrect.
My theme scss:
.test::before {
content: url('/test.svg');
}
I've written a Schematic that can be used by the library consumers to store the images inside a subdirectory of the assets folder of the application (e.g. src/assets/test-path). The Schematic does work as expected.
It does work when I add the following style inside the client's scss:
#import "test-company/test-lib/theme";
.a-client-test::before {
// This is just an example and assumes that the test image is located at this path.
background-image: url('../../assets/test-path/test.svg');
}
But as soon as I remove the line above (that actually uses the image from the assets folder and is not required at all). The path won't work anymore.
I've tested the following paths inside the library: ./test.svg, ~/test.svg, /test.svg. Only the latter does work but only with additional styles like the one above (that wouldn't be used) on app side. That's something I want to avoid as maybe we provide 50 icons on the library-side and it would be tedious to add these classes only to use the assets.
Some additional information:
I've added node_modules to the predecessor options in angular.json.
All other styles are working correctly. Only the image doesn't work.
I know that I can use ccsUrl: "inline" option inside the ng-package.json. However, I think this option only works (as far as I know) on styles that are used by components. But I actually copy the theme styles over after the build process. Additionally, the number of icons that are used inline shouldn't be too big, otherwise, the bundle size will increase and is therefore not an option for me.
I also don't know what is best practice for a scenario like that. I just couldn't figure out a proper way so far. But I assume writing a Schematic that copies over files is also not the best approach. Maybe there is a better way (e.g. a way to reference assets from the library but keep in mind I have the styles inside my library and the path is, therefore, complicated to figure out for all modules).
Just to make it clear again: My library has a scss file that uses an image. That image path is clear at the built time but doesn't work when used by an app. I can copy over the images, but that only helps when those images are used by the app somewhere in the styles. Then the path /image.svg works. The image as well as the scss that makes use of it are provided by my application.
Thanks for your help!
When starting a new project it is always the question which tools, frameworks and libraries to use. I often included the Eric Meyer CSS Reset, but this time I will switch to Normalize.css. I understand it as a customisable starting point rather than a library. I suggest to include the normalize.css file and overwrite specific parts of it. But i am not really sure, if this is the correct way. It would be hard to update the normalize.css file than. It seems Normalize.css is not sure either.
From the documentation at github.com
Normalize.css is a customisable CSS file that […]
README.md, Line 3
It is recommended that you include the normalize.css file as untouched library code.
README.md, Line 21
What would you suggest?
I am guessing this will get closed as it is a question open for debate. However, I would still like to add something to the discussion.
As normalize.css (or any reset css file that I know of) is distributed as a plugin package file, there should be no fault in altering it to your needs. It can be compared to the search for the right break-points for media queries. The truth is, there is no one-way street to follow, it's a delta: every one has to adapt to their project. This also means every developer has to write project specific code. One project might need the first breakpoint to be at 480 px, whereas another project doesn't take mobile devices into account any way, but it does provide very high-resolution displays. Every project is unique, and your code should reflect that.
That being said, exceptions can be made. Libraries, plugins and particular snippets can be used over and over again without any modification. In the case of libraries and plugins, there is some freedom in use per project by means of arguments passed to call to the library or function. For instance, when using jQuery, I will not always write the same code in my scripts file, of course not. That's because a library is only a means to an end, and not a stand-alone package that provides functionality in itself. A plugin (in the wide context) such as, for instance, Modernizr, is another beast all together.(1) The question then arises, what is a CSS reset in this respect? Most will say it's a plugin, and I agree. But should plugins be edited?
I think they can.
Take for example Wordpress plugins. Loads of topics are to be found on the internet concerned this discussion: should they be edited or not. Many peeps advise against it. I don't, and never will. For the simple blogger that wants to add functionality to his or her blog, a plugin in itself should suffice. But we, as web developers, might want more options (or less, to optimise the experience or speed). As long as the dev in question takes updates into account, altering a plugin has no consequence. Why should it?
The same goes for a CSS reset. As I said before, every project has (a) specific stylesheet(s), often one overwriting values in the other. But what good have you on a rule such as this:
/* normalize.css */
h1 {
font-size: 2em;
margin: 0.67em 0;
}
which you then overwrite by your own rules:
/* your-stylesheet.css */
h1 {
font-size: 1.8em;
margin: 0 0 0.8em;
line-height: 1.24;
}
This is ridiculous, doesn't it seem so? I would then advise to edit normalize.css.
However...
Everything I have written down so far (quite a lot, I admit) considers a single project. But what if you often build your own websites, or if you have many sub-sites to a main site and so on? And how should you organise your workspace (directory structure in this case) accordingly?
In the case of sub-sites (for instance websites or projects running on a sub-domain which use the same ftp source but that use a different styling guide) I would advise to use the unaltered normalizer. By doing so, every project has to be modified by rules that have been defined in normalize.css but it keeps you from having duplicate (yet different! for you have edited them per project) normalize.css files spread across your ftp server. Your folder structure would then look like this
- root
-- /index.html
-- /css
--- /normalize.css
-- /project-name-1/
--- /index.html
--- /css
---- /style.css
-- /project-name-2/
--- /index.html
--- /css
---- /style.css
-- /project-name-3/
--- /index.html
--- /css
---- /style.css
This means that index.html in the root shares the same reset (normalize.css, un-edited) as all the (sub-)projects.
To summarise: in an individual project that stands completely alone I'd edit the normalize file and simply see it as a base file to get started with. It's a good guideline, but some things just don't fit a project's needs (for example the heading declaration I mentioned earlier). I myself SCSS-ified and edited normalize.css to fit my needs, and use that as a base file for all my websites. Just keep one copy of it somewhere, and when you get a new project: copy it, edit it, and use it.
1: I am aware that not everyone would agree with me on this distinction. It is based on DOM manipulation: jQuery, for instance, allows functionality, i.e. the possibility to execute functions. You cannot call jQuery which would then trigger an action or manipulation. The basic function of Modernizr, for example, is different. When called, it executes functions and checks functionality of the browser (and adds classes to the DOM).
I decided to use Normalize.css and Reset.css to write my own defaults.
I don't think it's necessary to customize Normalize besides the default font-family, font-size, line-height and some other optional things.
I created Initialize.css, a collection of best practices like normalize and made it configurable with SASS (scss) (there is a css version as well). In this case, you could use normalize and set you own default font-familty, font-size and line-height and if you need some margins to elements like paragraphs and headings. You don't start with CSS overwrites, and that's awesome! :-)
http://jeroenoomsnl.github.io/initialize-css/
As we know, all menus and settings in Chrome are managing by CSS files and javascripts.
Is it possible to edit this CSS files or/and JS to manage menus/settings etc.?
For example chrome://settings/options_bundle.js or chrome://resources/css/button.css
Is it possible to change these files in some way?
There are two ways for doing it.
First way is simple, but slow:
Download sources (it will be Chromium, not Chrome) (http://git.chromium.org/gitweb/?p=chromium/src.git)
edit some file (ex. http://git.chromium.org/gitweb/?p=chromium/src.git;a=blob;f=chrome/browser/resources/options/browser_options.js;h=548a6068d4007f25427caf70b04c26575dafbc3d;hb=HEAD)
compile packed_resources and packed_extra_resources targets, place newly created resources.pak and chrome.pak files in the appropriate place.
Another way is some kind of a cheat:
find resources.pak file in the install dir. All of resources, that Chrome uses are placed in this file. It is like an archive without compression.
Edit this file. But the length of your changes must remain exactly the same as the length of original text. For example:
Before:
{
color: red;
}
(length: 15)
After:
{color: green;}
(length: 15)
You can overcome this limitation by deeper understanding of pak file format (which is described well https://code.google.com/p/grit-i18n/source/browse/trunk/grit/format/data_pack.py?r=79)
My work has recently deployed Sharepoint and I'm currently trying to get to grips with it.
I'd like to be able to completely customise the way my blog looks but I have no idea where to start. I had a look through Microsoft's developer site and it does look like they have a lot of stuff there but it all seems to be pitched at a much higher level than I'm at.
I'd consider myself pretty experienced with CSS and web development, does any of this translate into sharepoint? Can I make a new CSS file and upload a bunch of images into a store and change the look of my 'site' that way, or is it a lot more complicated?
I realise this is a little vague, but I'd really appreciate some pointers to a "getting started with making sharepoint not look sucky" guide or an example of the sort of thing I can actually hope to achieve. Hopefully my question isn't too high-level.
Thanks
Use SharePoint Themes, their installation is tricky at first but once you get a good development environment you'll be able to test modifications in the traditional "save css file, press F5".
Themes have these pros:
Do not need sharepoint designer
Do not need to change masterpages and deal with (un)ghosting (the sum of all fears)
Can be applied to one subsite and have other subsites with different themes (see gl-applytheme in google for mass application of themes thru many subsites)
and these cons:
You have no access to HTML changes, for that you need masterpage love (I dont think thats a con, its a limitation that usually exists in different scenarios and also makes you improve your css skills so much in the css-zen-garden way)
Themes once applied, go to the server memory -- meaning that if you change your theme folder you need to recycle the application pool, apply a different theme and apply your theme back to see that one pixel border you forgot to put in the footer. But for that specific problem I have a solution below:
After you do your "theme setup" you'll be able to only work with CSS and images and be free to overwrite any class in SharePoint using your favorite Developer Toolbar/Firebug addon to find what you want to change.
In the folder c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\THEMES create a folder named THEMEDEV
Inside the new folder, create a file called theme.css and another called THEMEDEV.INF
Inside the .INF file, paste this:
[info]
title=THEMEDEV
codepage=65001
version=3.00
format=3.00
readonly=true
refcount=0
[titles]
1033=THEMEDEV
now open the c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\1033 folder (1033 is your language code, thats the default for english installations)
edit the SPTHEMES.XML file
below <SPThemes ...> insert:
<Templates>
<TemplateID>THEMEDEV</TemplateID>
<DisplayName>Development Theme</DisplayName>
<Description>Development Theme.</Description>
<Thumbnail>images/thnone.gif</Thumbnail>
<Preview>images/thnone.gif</Preview>
</Templates>
now edit your theme.css file, add an import to your favorite CSS development folder:
#import url('file:///C:/SharepointThemes/Theme1/theme.css');
Save everything, open your sharepoint: Site Actions => Site Settings => Look and Feel => Site theme => choose your Development Theme and hit Apply
If everything worked, you can now edit your C:\SharepointThemes\Theme1\theme.css in your favorite editor, save it with something like
* { color: red !important }
and see the changes on your site.
Something also important when developing themes: do not create folders to store, say, your images, use everything in the same folder and in the code itself use a relative fashion, like background: url('image.png')
ps1: Only you can see changes you are making to your sharepoint site due to the file://c:/ folder, if you need more people to see the changes during development, setup a network path that they all have access, the rest is the same.
ps2: Keep in mind this is a development environment, to make your theme a live theme you need to create another one to store all the content used to change your site's visuals.
The process is similar to the one creating the THEMEDEV one, just put a pretty and consistent name across all configurations (Folder name, .INF name, .INF contents, SPThemes.xml node contents), paste all your images in the Theme's folder and replace the theme.css file with your content.
Edit1: Reading your comment above, now you have a "editing + uploading to FTP" type of setup :) this works for MOSS and WSS by the way (even if you don't know the difference). For more info on customizing sharepoint, I made a post yesterday about more options:
Sharepoint: How to remove default core.css reference?
I like to always use this post as a starting point for SP branding: http://erikswenson.blogspot.com/2008/10/functional-sharepoint-branding-style.html
It depends on whether you're talking about a WSS 3.0 site or a MOSS site. WSS 3.0 sites can be customized using themes. Customizing MOSS sites is a little trickier, although you can add a SINGLE custom CSS style sheet via Central Admin - in this case, your custom files, images, etc., would be deployed as a Feature.
The best explanation of how this works that I have come across is the six part series on the cleverworkarounds.com site.