I've been using the react-devtools to detect any unnecessary component updates, however I'm not sure I fully understand how it works.
I can identify the various components that got updated by the added borders indicating that they got updated but I'm not sure what the various colors of those borders mean (I've so far seen cyan and light green colors).
I'm not familiar with this either, but I'll trace through the code! :)
This is the component that renders the "Highlight Updates" toggle. It calls a changeTraceUpdates method in the main Store which sends a message through the "bridge" to activate the TraceUpdatesBackendManager. Poking around that file, we see a couple of classes with names like "presenter" in them; I assume one of these is what actually draws the border. In particular, TraceUpdatesWebNodePresenter looks related because it defines an array of COLORS. It looks like these colors are chosen based on a "hit" attribute, which a quick search suggests is set by TraceUpdatesAbstractNodePresenter– and gets incremented each time an element is "presented".
Reading between the lines then, I assume this means that components that render less frequently will be outlined with "cool" colors (blue) and ones that render more frequently will be outlined with "hot" colors (red).
Related
Let's say a component allows the choice of picking between 20 colors. Should these swatches have labels on them? It seems a little pointless to me since there's no standard for color names besides (probably) meaningless gibberish like #d1ed7e. However, I'm wondering if anybody has an argument for their inclusion.
For color choices on a product selection, say a blouse or shoes, then color names might be important.
And there is a standard for color names. It's in the CSS documentation.
https://www.w3.org/TR/css-color-3/#html4
https://www.w3.org/TR/css-color-3/#svg-color
Those CSS color names might not match a company's name for a color, like "Dusty Sunset", which could be a shirt color or a paint color.
RGB values can also be very useful. What you might think of gibberish, #d1ed7e, might mean a lot to me if I'm a designer or coder.
Visually displaying the color name along with the swatch can also be helpful for some users. You don't necessarily have to "hide" the color name for just screen reader users.
Here's an example from a shoe website.
The current color displays as "Navy" and if I hover with the mouse over the other color, it shows "Tan". Tooltips are not the best way to do this since they're generally not displayed on mobile devices and tooltips often only work with a mouse hover and not keyboard focus, but it gives you an idea of showing color names.
If I'm in a design system and I want to choose a color, I probably want the exact RGB or HSV values so displaying the color code would be helpful.
One of the rules of WCAG says that information shouldn't be conveyed only by their color.
The color of an object, whatever it is, is always an information. It can be more or less important depending on the object and user taste, but it's always a property that the user must know about.
As a consequence of this, definitely, yes, colors have to be labelled in some way, and not left alone without labels.
For sure I want to choose the color, and at worst I don't matter at all and pick one at random. So at worst it anyway never hurts.
It's not because I'm blind that I'm not interested or don't matter at all about colors. For clothing, it stays important. I don't want to wear pink and green together, right ?
I might make a gift to a sighted friend. And what about color blind people ? They will certainly find useful to see "red" and "green" explicitly written, instead of apparently seeing two identical options.
Even normal sighted people are sometimes surprised because the color of what they receive don't match exactly what they saw on the screen. Maybe the brightness wasn't optimal, or he/she ordered during the night, or under artificial light ? I'm pretty sure that a name may help in this case, too.
As explained in the previous answer, the kind of label you should show depends on the kind of users using your site.
However, I don't agree with using CSS names.
For daily life objects sold in a shop, use the same name as it is officially called in your article catalog, it's probably better than using CSS names. If you can stick to quite generic color names, it's probably even better than a possibily brand-specific vocabulary. Example: is "blue marine" or simply "marine" more widely understood than "navy" ? (I'm not native english speaker, so maybe it's a wrong example, but I think you get still the idea).
If I look at all CSS names, really, there are colors I don't know about at all. Jaws has also a quite big list of colors mapped to RGB values, but many don't make much sense either for a lambda user.
For development stuff, RGB code can be very useful, but remember that it doesn't make sense for most people or in other contexts
To wrap up, yes, label your colors, and if possible with names that are widely understood
I need a function that takes two Qt widgets and "links" them such that no matter which one the mouse is hovering over, they both get highlighted with their (standard) hover highlighting (if they have such).
This needs to work with whatever kinds of widgets the caller passes to this function; this function can't require callers to create widget subclasses just to make this work.
Here are some images of what I'm referring to:
Normally, when you hover the cursor over a widget, it gets highlighted as shown in Images 1 and 2. I need an example of how to set things up so that regardless of which widget the mouse is hovering over, they BOTH get highlighted with their standard hover highlighting, as shown in Image 3. Ideally, this function would work generically, only operating on its arguments as QWidgets, regardless of what kind of widgets they actually are (because hover highlighting is a generic Qt behavior, after all).
def link_highlighting(widgetA, widgetB):
... what should go here? ...
This feels like it would involve some pretty dark event hackery, but my event hacking fu is not strong.
Ideas? Suggestions?
I did a bit of research and I see two ways this can be done right now in a generic way.
The first part is detecting the hover action. This should be easy. Just subscribe to the enterEvent and leaveEnvent of both widgets. As long as they are of type QWidget this will work. With that you will be notified when the mouse enter or leaves a widget.
Then the highlighting part. Here you have two options:
You can fake a mouse event on the second widget, basically emulating a second mouse enterEvent. This can be done with qApp.sendEvent(widget, event).
You can change the palette of the second widget. Basically to set the normal palette to the highlighted palette. Here you would use functions like:
palette = widget.getPalette()
palette.setColor(QPalette.Base, widget.palette().color(QPalette.Highlight))
widget.setPalette(palette)
This obviously needs some experimenting. And for now this only works for widget styles that work with paletters. For the ones that work with CSS one would need to basically do the same. Find the bit that applies to highlight and copy it over to the normal state.
Depending on how general your case is, this could be really easy or very hard.
Let me know how this goes.
This has me stumped. I have a view with two child labels as shown here...
Here are the constraints for the entire view:
All of those constraints have a weight of 1000.
The problem is the orange label has it's horizontal ContentHugging set to 1000 whereas the blue label has its horizontal ContentHugging set to 250, which, AFAIT means the orange label should hug its content causing the blue label to expand to fill the area thanks to the constraint between them with a length of zero. Yet I'm seeing the exact opposite. What gives?
Settings for the orange label
Settings for the blue label
So what the heck am I missing?!
Update
After further research, this seems to be either a corrupted NIB file, or an issue with Interface Builder itself. I say this because I created a second NIB with the exact same settings as above, but this time it worked as expected. (I even copied the views themselves from one to the other.)
To be sure, I went through everything view-by-view and compared all values and constraints and it all looked completely identical.
While I could open up the nib itself and compare the raw text to see if there was something odd, since the new one works, I'm considering this as an anomaly, meaning unless someone can point out a mistake made above that I'm still not seeing, I will close this out as such.
I am using aplypy to create an RGB image of the Eagle nebula from three FITS files, representing the red, green and blue components of the image. The FITS files are available here, 673nm being the red, 656nm the green and 502nm the blue.
import aplpy
aplpy.make_rgb_cube(['673nmos.fits','656nmos.fits','502nmos.fits'], 'nmod_cube.fits')
aplpy.make_rgb_image('nmod_cube.fits','nmod.png')
f = aplpy.FITSFigure('../data/nmod_cube_2d.fits')
f.show_rgb('../data/output/nmod.png')
The image should look something like this, but comes out looking like the image below. The blue component is clearly misaligned with the red and green.
make_rgb_cube is supposed to realign the three images in to the same projection based on the WCS information in each FITS header, according to the docs, but it doesn't seem to be working in this case.
Do I need to employ a star matching library to get the alignment accuracy?
There is an error in the WCS coordinates in the header of the Blue FITS file. I have contacted spacetelescope.org to alert them.
Another example from the site, of M17, is created correctly using the aplpy script shown in the question. Blinking through each filter using DS9, as suggested in the comments, confirms the correct alignment.
Use the STScI software TweakReg to align the images and get a good alignment before combining. More information and worked examples can be found on the DrizzlePac website.
TweakReg:
Combining images using astrodrizzle requires that the WCS information in the headers of each input image align to within sub-pixel accuracy. The tweakreg task allows the user to align sets of images to each other and/or to and external astrometric reference frame or image.
It is optimized for use with HST instruments, but can be adapted for other observatories/instruments.
I noticed that every browser renders the border-style: inset; property differently, so I had two questions:
Why do the browsers render it differently? How can there be so many different algorithms for this? Most of all, some browsers look wrong with it!
Since I can't rely on the inset attribute working, I was wondering what the proper "algorithm" is? I typically go 16 lighter on top/left and 16 darker on bottom/right (ie. #666666 is the background, so #767676 is the top/left and #565656 is the bottom/right)
I need to know what to use (generally speaking) because I'm having trouble making my styles inset, and I clearly can't use the inset properly so I have to manually change the colors. Sometimes, however, it just doesn't look right (if it's too dark). There has to be a good algorithm out there for this?
I've looked for web resources on the issue (such as a "what colors your borders need to be to make this look inset!" tool) or anything that could help, and found nothing.
Think of it this way: If someone were making something in a paint program and didn't have an inset effects button, what colors would all four of their borders be, given the main color is _____?
There HAS to be a general algorithm for this that I can't find...
Edit: I want to point back to my example of using a paint program that needed an inset style. Can someone give me an example of what they'd use for this? (Is this part of the question better directs on the designers stack?)
Quote: "1. Why do the browsers render it differently?"
I'm sure each browser does it differently because they think theirs looks best. IE probably does it to look good in Windows. Safari is making theirs consistent with the look of Mac OS. Firefox in keeping with that browser's other elements, etc. (and like stated by thirtydot, it has not been standardized.)
Quote: "2. Since I can't rely on the inset attribute working, I was wondering what the proper 'algorithm' is?"
You could try to reverse engineer it if it's that important. Setup a test page and call it up in a browser. Use an eye-dropper/color-picker utility to pick off the various colors. With enough samples, you should be able to find a pattern for that one browser.
Quote: "There HAS to be a general algorithm for this that I can't find..."
Not if every browser does it differently. Each will have their own algorithm.
EDIT to address OP's follow-up:
Quote: "Edit: I want to point back to my example of using a paint program that needed an inset style. Can someone give me an example of what they'd use for this? (Is this part of the question better directs on the designers stack?)"
You seem to be looking for one specific answer where one does not exist. I cannot give you an example of what I'd use since modern graphics programs (Photoshop) will do this for me and then give me enough options that, when combined, literally provide millions of results; border color, highlight color, shadow color, depth, angle, thickness, profile, etc. Ask 20 people what they think is the "perfect" inset and you'll get 20 different answers (opinions really) and then we're back to the reason it looks different in each browser (see #1 above). So yes, in the context of "programming" questions, this last part of your OP is probably off-topic.
Additional Random Thoughts:
Why is border-style not Standardized? IMHO, I'm thinking this property is simply not used enough to warrant any major effort to Standardize or perhaps there is much disagreement on this in the Standards community. I imagine that all the CSS properties requiring Standardization are prioritized in some fashion (popularity, usefulness?) and this one just didn't yet make the cut or bring everyone together. Personally, I think a property like this is tied too closely to ever-changing trends. i.e. - 10 years ago, we used to see to see lots of tables with very thick "embossed" borders. These days, many designs use few borders or very thin borders, if any. Again, this is only a matter of taste and opinion.
I have an answer to this:
Why do the browsers render it differently? How can there be so many
different algorithms for this? Most of
all, some browsers look wrong with it!
See: http://www.w3.org/TR/CSS21/box.html#border-style-properties
The color of borders drawn for values
of 'groove', 'ridge', 'inset', and
'outset' depends on the element's
border color properties, but UAs may
choose their own algorithm to
calculate the actual colors used. For
instance, if the 'border-color' has
the value 'silver', then a UA could
use a gradient of colors from white to
dark gray to indicate a sloping
border.
That's the reason implementations differ - because it wasn't standardized.
I would say for lighter side add 20% to each of the rgb values, and for the dark side remove 20% from each RGB value..