I am deploying superset for my company and required to change the theme to blue. I have tried to follow the guide from https://debaatobiee.wordpress.com/2019/08/04/customizing-apache-superset-ui-config-theme-changes/ but still unsuccessful.
I have few questions in mind:-
1. Do we need to rebuild superset after amended variable.less?
2. If rebuild is required, if I upgraded to latest version in future, do I required to rebuild it again?
Starting from Superset 1.1.0 it is possible to customize theme via the THEME_OVERRIDES in superset_config.py configuration file.
THEME_OVERRIDES = {
"borderRadius": 4,
"colors": {
"primary": {
"base": 'red'
},
"secondary": {
"base": 'green'
},
"grayscale": {
"base": 'orange'
}
}
}
The default theme values can be found in index.tsx file.
Please note that according to the given GitHub issue the structure of this configuration property is a subject for change and might be modified in the further Superset releases.
You can make use of the docker version once you have made the changes. Use the docker-compose build command to create the new image.
1) Yes, you need to rebuild once you make changes
2) Yes, since you have a custom version, for every upgrade, you have to update the original files with your custom files and rebuild
Related
i'm using Electron for the first time and have a problem.
I used a sample to make an app with Angular and Electron. When I changed a little bit i made a build to test if things are right. Since that i made a lot of new functions and updates. Now when i try to build/package my app, i got the same version i have made at the beginning and not the version i'm seeing when i made npm-run-all -p electron:serve ng:serve what i'm doing wrong?
I have used electron-forge, i have used electron-packager and them both got the same old version builded. And i don't know what to do now.
try with extraMetadata in your package.json :
{
"build": {
...,
"extraMetadata": {
"version": "X.Y.Z"
},
...
}
I would like to edit the make:entity command provided by the MakerBundle in Symfony 4.
Here is an explaination : the command adds the field Id by default in each entity. I would like automatically add other fields. That is why I want to edit the make:entity command.
I can also create a new Bundle that adds a new command like my:make:entity. But if I add a new command, I don't want that make:entity still usable anymore. I have an OpenSource project and I don't want somemone to use the old make:entity command. So, if I can't edit the make:entity command, can I deactivate it ?
Thank you in advance,
Vincent
You can fork the github repository from :
https://github.com/symfony/maker-bundle
and then make any modifications you like, commit and push to your fork.
Then you need to tell composer to use your fork instead of the official repo by adding a "repositories" section to the end of your composer.json file
"repositories": [
{
"type": "vcs",
"url": "https://github.com/[your github]/maker-bundle"
}
],
I hope this helps.
I am trying to make my Ember project build to a directory outside of the project and for future builds I don't want to use command line flags each time.
ember build --output-path=/not-dist will work for me but I want Ember to add the flag automatically.
outputPaths: {
app: {
html: '../presentation/index.cfm',
css: {
'app': '../presentation/assets/ember-presentation-viewer.css'
},
js: '../presentation/assets/ember-presentation-viewer.js'
},
vendor: {
css: '../presentation/assets/vendor.css',
js: '../presentation/assets/vendor.js'
}
}
I have tried this as per the ember-cli documentation but ember-presentation-viewer.css was insisting on getting built in the dist directory with all the additional paths put there.
Is there a way to do this?
Go to package.json. Change scripts/build command:
"scripts": {
"build": "ember build --output-path=/not-dist"
},
From now on, run:
npm run build
You can configure your .ember-cli.js file to specify flags that should always be included in your command line builds (in lower camel case), as per this page in the Ember docs. To change the output directory you'll want to add the following line: "outputPath": "../../example-folder/presentation".
So your final .ember-cli.js should look like this:
{
/*
Ember CLI sends analytics information by default. The data is completely
anonymous, but there are times when you might want to disable this behavior.
Setting `disableAnalytics` to true will prevent any data from being sent.
*/
"disableAnalytics": false,
"outputPath": "../../example-folder/presentation"
}
I'm trying to enable the lossyPNG property in the ember-cli-imagmin addon to create a small file size for my .pngs. My EmberApp in ember-cli-build.js includes imagemin like so:
imagemin: {
interlaced: true,
optimizationLevel: 3,
progressive: true,
lossyPNG: true,
pngquant: {
speed: 1,
quality: 80
}
}
The dependencies object in my package.json includes:
{ ...
"ember-cli-imagemin": "0.4.0",
"imagemin": "3.2.2",
"imagemin-pngquant": "4.2.2",
...
}
However, whenever I run ember build I get the following error:
The Broccoli Plugin: [object Object] failed with:
TypeError: ImageMin.pngquant is not a function
This error points me to this line in broccoli-imagemin. If I set lossyPNG to false in ember-cli-build.js then I receive no error, but my pngs could be optimized further based on the results from pagespeed. What am I missing to be able to use pngquant to further optimize my png images?
broccoli-imagemin, which ember-cli-imagemin depends upon, is the problem. Since it hasn't been updated since Nov 2014, it uses an older version of imagemin, but the package.json specification allows imagemin v3.x. pngquant was removed as a default property in imagemin v3.2.0. So if you force the installation of imagemin v3.1.0 in your package.json it should work.
If you want to use a more recent version of imagemin look at this PR. I'd try to use that branch directly. You can install that branch directly from the repo with:
ember install https://github.com/kanongil/ember-cli-imagemin.git#v5-imagemin
This branch changes how imagemin works. Instead of passing options, it looks like you just pass the plugins that you want to use, and pass their options directly in to them.
var app = new EmberApp({
imagemin: {
plugins: [
require('imagemin-jpegtran')({ progressive: true }),
require('imagemin-pngquant')({speed: 1, quality: 80}),
require('imagemin-svgo')()
]
}
});
I'm allways running into this exception when I try to build my app with the sencha commandline tools. However, other apps seem to work fine. What am I missing?
UPDATE
I figured out it has something to do with the fact that I want my buildPath to be outside of the app directory. My section in the app.json looks like this:
"buildPaths": {
"production": "../deploy/frontenddemo/production",
"testing": "../deploy/frontenddemo/testing",
"package": "../deploy/frontenddemo/package",
"native": "../deploy/frontenddemo/native"
},
If I change it to:
"buildPaths": {
"production": "build/production",
...
},
Everything works as expected. I don't know why. It should be possible to have the builds outside the app directory I guess.
Ok, after a lot of try and error. I found the root cause of this issue.
My app.json looked like this:
"archivePath": "../deploy/frontenddemo/archive/",
"buildPaths": {
"testing": "../deploy/frontenddemo/testing",
"production": "../deploy/frontenddemo/production",
"package": "../deploy/frontenddemo/package",
"native": "../deploy/frontenddemo/native"
},
The problem with this structure is that both archive and builds produce a directory "sencha" outside of the configured path. Meaning they both create ../deploy/frontenddemo/sencha
with different contents. I wonder if that is documented somewhere?
The fix was easy. I just changed the paths to this:
"archivePath": "../deploy/frontenddemo/archive/",
"buildPaths": {
"testing": "../deploy/frontenddemo/builds/testing",
"production": "../deploy/frontenddemo/builds/production",
"package": "../deploy/frontenddemo/builds/package",
"native": "../deploy/frontenddemo/builds/native"
},
I've had previous issues deploying directly to a web server such as MAMP, or even Mac's default web server, in ~/Sites/
Have you tried changing your deployment directory to something other then MAMP, and then manually copy/paste it over?
Also, what exact version of the SDK are you using? 2.1 beta 3 was released a bit ago, as well as a new Sencha Cmd 3.0.0.122 (used to be called Sencha SDK Tools).
Forum Announcement: Sencha Touch 2.1.0 Beta 3 is available