We use jupyterhub cluster and without any noticeable change on our side, the notebook cells' height turned huge and static (attached a picture)
Tried to fix the issue looking at - How do I increase the cell width of the Jupyter/ipython notebook in my browser?
Managed to decrease the cells size but it's still static.
Any suggestion what has might caused the change? And how to fix this?
This is how our cells look today -
Potential fixes
My suggestion to uninstall your extensions one-by-one until the problem goes away may honestly be the fastest way to get a fix. If have a reasonably recent version of Jupyter you can list all of your installed extensions with:
jupyter nbextension list
You would then start by uninstalling any extension that relates to theme and/or styling of the notebook. It's possible that list will miss some things (eg an improperly installed extension, or issues with your own config files). The next step (after getting rid of at least all suspicious extensions) would be to go through all of the user-space data and config files that Jupyter sets up in the background. You can get the paths to all directories containing such files by running:
jupyter --paths
Small note, you can probably ignore all files in the runtime dir, these probably aren't the problem.
If a mass uninstall of your extensions makes you squeamish, another option would be to debug the CSS of a live notebook and figure out exactly where the styling of the code cells is getting screwed up.
Detailed instructions for debugging the CSS
The following instructions are for Chrome, but if you're using another browser you should be able to figure out an equivalent:
start up a notebook
right click on a code cell and select "Inspect"
this will bring up a view of the DOM node hierarchy and highlight the node representing the code cell (or some at least some part of it) that you just right clicked on
on the right side of the screen will be a window with a bunch of tabs at the top. Select "Computed", which contains the style that is actually displayed in the browser, as computed from the sum of the effects of all CSS selectors
in particular, pay careful attention to the width and height properties of the computed style. Walk up and/or down the DOM hierarchy until you find a node with a suspicious looking width or height
If a value is greyed out, that means that it's being set in a parent node
start with a suspicious looking value, then go up the hierarchy until the values seem normal again
on one side of that transition point, you should have the top-most node in your hierarchy with bad values. If you examine the "Computed" tab, you should be able to see exactly which files are setting the bad values
The identity of the files screwing up your notebook styling is the payoff here. Examining those files should help you a great deal in uncovering the real problem.
Related
I've just installed Ride editor on my Mac and I'm new to this. My python version is 3.9.4 on BigSur 11.4 and I'm using the dark mode theme.
I have trouble with the colors because I can barely see anything, only when something is selected. I've tried to change colors in the preferences but no luck.
I can't see the names of my files only when they are selected.
My project structure
I can't even write simple text case because I can't see what I am typing because of that yellow background and characters are white. Only after enter or when it is selected you can see what is in the field.
Test case fields
I can't make dictionary nor the list variables. I can only define them and add them values directly in the script because that window with the fields on the left is to small and I can't stretch it.
Dictionary Variables
If someone has facing the same thing or has an idea or solution at least for part of it would be great because I am out of the ideas. Thanks.
If you installed latest development from master (you probably did, so you can use with Python 3.9), you have options to change colors (and save and restore), from Tools->Preferences->General and for the Grid, Editor and Run tabs.
It would be nice to have those color settings files shared with the community. Please go to the project page and create an issue with those settings, or communicate on our Slack.
The website of PageSpeed Insight is the only place, where i get CLS issue in both of field and lab data.
Any other Lighthouse instance (by WPT, as API or by DevTools) displays CLS issue only in field data, not in the lab.
How can i diagnose correctly, which elements are causing CLS? Example.
PS: My question has the following cause: analyzing other websites i usually have under devtools → performance red diamonds layout shift, which, if clicked, display in tab Summary some data about this layout shift. Like on the screenshot:
But on the example site i get CLS diagnosted, but not displayed.
The synthetic (lab) tests only load the page (they do not interact with it), whereas field data is until page unload.
Immediately I can see one Layout shift is when you open either of the drop down menus, your scroll bars disappear (due to adding the class .overlayed) and the whole page shifts around. Synthetic tests do not open the menu so will never capture it, however this shouldn't actually contribute to CLS as it requires interaction to open (just something to fix).
The other thing I noticed is the bottom right corner icons cause a layout shift when you scroll and they collapse / open (the floating icons). This is likely to be the cause of CLS as it isn't via direct interaction. Scrolling does not count as user interaction when it comes to CLS.
My guess is that this is the one that gets found by synthetic tests sometimes and not others.
Finding Layout Shifts
In order to find layout shifts you can open developer tools, go to rendering panel (you may need to open it with "more tools") and click "Layout Shift Regions" so it is selected.
Now use the site and you will get a blue box around anything that shifts.
Or you could use performance traces
The other way is to run a performance trace in the performance tab and then just use the site. Once you are done complete the trace and it will tell you if a layout shift occurred and what item caused it.
Tracking them in the field
In order to capture layout shifts in the field yourself you should use something like Google Web Vitals library along with click / mouse position tracking etc and pipe it to your own backend or Google Analytics for analysis.
This lets you find issues with the page a lot more quickly and easily using Real User Metrics (RUM) data in real-time.
Is it possible to customize the looks of GitAhead to resemble TortoiseHg workbench?
I'm not asking for fonts or colors but for the position and display size of elements.
branch selection + sort and filtering in one line full width at the top
history log to be full width at the top under branch selection and filtering line
commit details to be under with split screen (left for file list, right commit message and file changes)
output log leave where it is (at the bottom)
If yes but only by modifying its source code on github https://github.com/gitahead/gitahead then I would appreciate some guidance
The design is hard coded. Any docks are used to change the look.
I tried to implement a mode to fullscreen the diffs or the commit list. Maybe you are interested in it
https://github.com/gitahead/gitahead/pull/408
At the moment the author is quite busy and is not able to have a look at all these changes.
I came across this thread a few days ago looking to get rid of the stark white background in the DevTools window. One thing led to another and I started in on adding rules for many more elements using the base CSS file (chrome-devtools://devtools/devTools.css) as a guide.
The file being modified can be found in the following locations:
Mac: ~/Library/Application Support/Google/Chrome/Default/User StyleSheets/Custom.css
PC: C:UsersYourUsernameAppDataLocalGoogleChromeUser DataDefaultUser StyleSheetsCustom.css
Ubuntu (Chromium): ~/.config/chromium/Default/User StyleSheets/Custom.css
Midway through, I started running into a problem when modifying rules with very common selectors. The first two I ran into were #main and #toolbar. When adding rules for the more common selectors, if a web page is also using these same selectors (ie. google search), then the rules are applying to those pages or sites as well.
I understand why this is happening. My question is...
Is there a way to only target the DevTools window in Chrome via this Custom.css file without affecting any other domain?
I've tried using the #moz-document domain () and #moz-document url-prefix ()declarations but can't figure it out...
I'm too far in to give up now, so I'm hoping someone can assist.
Here is a screenshot of my progress so far:
Ok, so after digging around, I noticed I actually missed the notice right smack dab at the top of the original article page:
Since publishing this article the Chrome Team have added a unique ID
to the container of the Chrome Dev Tools. The ID is #-webkit-web-inspector(Trac Reference)
So, the fix to my above post is to add body#-webkit-web-inspector to all of your selectors and it works perfect, thus only targeting chromes DevTools window. Also, very important... to those wanting to create a more complete theme, it’s HIGHLY RECOMMENDED to do it via "inspecting the inspector". More info on how to do this can be found here: How do you inspect the web inspector in chrome?
See screenshot below of "inspecting the inspector":
I want to preface this question by admitting that I'm still very much a novice, to Xcode 4 and to development in general. But I find I learn the most when I've made mistakes and been able to discover ways to correct my errors.
So I was mucking about in Xcode, following an example in the book I've been studying, in this case trying to determine why the keyboard wouldn't hide when I touched outside a text field. In the process of experimentation, I tried adding an Outlet to the top level View of a View Controller, dragging into the Header file to automagically create it. I knew almost at once this wasn't what I wanted, and I deleted the reference in Interface Builder, and the code it had added to the other files.
And when I did run the program, it threw an exception. Being new to this, I didn't think to check the log files, and when I couldn't work out what the error was, I restored an earlier version of the project from Time Machine, and tried again -- same result. I restored an even earlier version and tried again -- and got the same error!
When I finally did have the good sense to look at the log file, I noticed the reference to the name of the Outlet I had added, but removed! But these were older versions of the code, before I'd even made that change.
I made a thorough search of the code, and my NIB file, looking for any reference to the deleted Outlet. I couldn't find anything.
I eventually replaced the NIB file with a version from the tutorial from the book I was following (it was identical, and easier than rebuilding it from the bottom up), and all was well, everything ran just fine. But now I'm left wondering -- what could I have done to make this error so persistent, across different versions of the file? I'm already kinda uncertain about the way Xcode 4 will automagically add code under certain circumstances (that's probably more dangerous than useful for the novice), and I wonder if this is a bug in Xcode 4, or if I inadvertently tripped over a useful feature.
Xcode loves to play tricks on you. I've several times gotten an XIB mysteriously hosed up to the point where I had to delete it and start over. No matter what I'd do to the XIB some elements wouldn't display correctly (or at all).
In a recent case I had an XIB with a label with the text "Start date:". I changed that label text to "Treatment date:", but it still kept coming out "Start date:". I opened the XIB as text and scanned for "Start date:" and it wasn't there. So I tried dragging the label off to one side. Then it displayed the correct words. Dragged the label back to the correct place -- back to "Start date:". I finally deleted the label and recreated it and then the text came out correctly.