I want to know what disabling CSSOM View Scroll Coordinates flag in chrome://flags does and how can i replicate this behavior using code in my ReactJS app.
Additional information :
It seems after Chrome 85 update, ag-grid RTL support breaks and the grid is not able to scroll the content and sometimes the cells becomes white, i had to dig very deep into the past questions and try a lot of far fetched solutions to find what i have.
I found out that disabling CSSOM View Scroll Coordinates in chrome://flags will fix the bug!~ but the problem is i don't want to force my users and teach them to do this just so my app works, so i thought what ever disabling CSSOM View Scroll Coordinates does, maybe i can replicate it using css code or some other code
I have already reported this issue in ag-grid's git-hub but i'm still waiting for them to offer a solution in the mean time if i can get this to work only using code, it would be great as i have a lot of users which are not able to use my app just because of this simple bug ..
Thank you.
When using the OculusGO or the OculusQuest when you hyperlink from one virtual environment (VE) to another the Oculus Browser (and it also appears Firefox Reality last I checked) time-out. You go to the next scene; but are kicked out of VR which is undesirable.
Curious if anyone else has ran into this issue and if they were able to get around it, or perhaps have any ideas on how to get through it.
At this time it appears an issue in the WebVR implementation of events to control VR mode; but maybe there is a creative solution :)
I made a PR a little while ago ( https://github.com/aframevr/aframe/issues/4081 ) that did seem to work “most times” but there are some bizarre timing issues happening here (last I checked Mozilla Reality had the same behaviour).
Notes:
- It appears that there is a time-out happening that kicks the user out of something takes too long to load.
- I was under the impression that webVR will load things in asynchronously; so I am unsure how this time-outs. Perhaps I need more understanding here.
You can see a glitch here I created that highlights the problem by moving between a "light" and "heavy" scene: https://glitch.com/~portal-test-af-1
I also made a PR here that attempted to fix the problem ( https://github.com/aframevr/aframe/pull/4107 ); but, I assume due to some updates on Oculus's end, this "hack" no longer works.
This is a bug and should be fixed here: https://github.com/aframevr/aframe/pull/4199
The thing is I tried using https://baskren.github.io/Forms9Patch/ but I feel like I don't fully grasp it.
Don't get me wrong, the tool is great it does stretch the 9patch images. It's just that I can't get the buttons to look properly based of Google brand guidelines.
https://developers.google.com/identity/branding-guidelines
The way it should look
And this here are the drawables I am using :
https://developers.google.com/identity/images/signin-assets.zip.
Here are the results of different button tries and dimensions
This is the code that got me the closest to the button I want
<f9p:Button Text = "Sign in with xxhdpi"
TextColor="White"
FontSize="14"
FontFamily="sans-serif-medium"
WidthRequest="60"
>
<f9p:Button.BackgroundImage>
<f9p:Image Source="{local:ImageMultiResource TestingApp.Resources.Images.btn_google_signin_dark_normal_xxhdpi}"/>
</f9p:Button.BackgroundImage>
</f9p:Button>
I tried using a grid with image and button as well but it didn't work out.
It would be awesome if someone would point me in a proper direction.
I've actually done this before. Here is a general outline of what I did:
Put your multi-platform icon files into your .NetStandard project as Embedded Resources. This means that I found all of the various resolutions provided by Google (_xxhdpi, _xhdpi, _hdpi, _mdpi, etc) and then renamed them to the following:
icon#¾x.png
icon.png
icon#1½x.png
icon#2x.png
icon#3x.png
icon#4x.png
And then put them in to the Resources/Google folder in my project (FormsFirebase.Ui). So, for example, the EmbeddedResourceId for the first file, in the above list, is FormsFirebase.Ui.Resources.Google.icon#¾x.png.
As you will see in a moment, renaming these files, as shown above, will allow Forms9Patch.Button to pick the right image for the right screen resolution (so it will look great) - freeing you from having to manage this. Likewise, putting them in the .NetStandard project means they are available for all platforms - freeing you up from having to figure this out multiple times!
In your Forms9Patch.Button, refer to the above icon image in a resolution independent fashion. This can be done a couple of ways. One of the more verbose ways is:
var myButton = new Forms9Patch.Button
{
Text = "Sign in with xxhdpi",
TextColor=Color.White,
FontSize=14,
FontFamily="sans-serif",
WidthRequest=60,
IconImage = new Forms9Patch.Image
{
Source = Forms9Patch.ImageSource.FromMultiResource("FormsFirebase.Ui.Resources.Google.icon", GetType().Assembly),
Padding = 1,
},
Spacing = 4,
TintIcon = false,
BackgroundColor = Color.FromRGB(81,134,236)
};
A couple of things to Note:
First, I set TintIcon to false in order to not tint the icon to the same color as the TextColor. Also, I set IconImage, not BackgroundImage. This is to be sure the image is a peer to the text, rather than in a layer below it.
Also note that I am able to set the padding of the IconImage as well as the Forms9Patch.Button.Padding and the Forms9Patch.Button.Spacing (the distance between the IconImage and the Text or HtmlText, depending on if HasTightSpacing has been set to true).
Instead of using multiple .png files (for each screen resolution), if you have .svg version of your image available, you can use that instead. Much less work!
Another thing you might be interested in: Just as Forms9Patch handles images in a platform independent fashion (by putting them in a cross platform project as Embedded Resources), it can do the same thing with Fonts. This means you can put a font file (.ttf or .otf) into your cross platform project and use its EmbeddedResourceId as the value for FontFamily. And this behavior can be extended to Xamarin.Forms elements by use of the Forms9Patch.EmbeddedResourceFontEffect.
Now for a bit of proselytization (please forgive me if this does not apply to you): I see that you used XAML for your sample code. Notice I didn't in my response. If you are new to .Net and/or Xamarin.Forms, I would highly recommend not using XAML. Don't get me wrong, XAML is great - it's just not for beginners. Why? There's just too many things going on under the covers that, as a beginner, will trip you up and slow you down. Rather, I would recommend you write all of your UI in C# so you can learn to manage your properties and learn how binding really works. Once you have mastered making very efficient layouts with the best "context appropriate" use of binding, then you're ready for XAML. For me, the real test was being able to make very a complex cell layout in a large list in a ListView smoothly scroll on a low-end Android phone. After that experience, I was able to take advantage of all the benefits of developing in XAML (and there are many) without worrying about being shackled by my novice mistakes.
I'm trying to implement a screen dimmer using QT4 and I wanted some advice before I get cracking instead of going into this blindly.
I want to create a top-level window that has no frame. I was thinking of making the background black and messing with the opacity so that it will dim the screen out after the system is idle for a given period of time.
The problem with this is that if this window is always on top, how can I pass click events to the window underneath it? I'm not the least bit familiar with the windows API (the solution only has to work under windows), but I'm guessing that's a good place to start. Can anyone point me to some useful classes/functions or suggest another way of doing this via QT?
If anyone's interested in the solution I came up with and the windows API functions I used, you can check out my blog posting here: http://sarcastichacker.com/getnextwindowandgetforegroundwindow
I will be updating the source and making another related posting on the same blog within the next couple of days.
If I have a decent size asp.net page open in Source view, and hold down the Up key or Down key to scroll through it, it will periodically get "stuck". It will stop on a line for a few microseconds, and you can see the screen flash, like it's trying to catch up with what it's trying to do behind the scenes. In my two-monitor setup, I'm working in monitor 2, and you can see the icons on the desktop on monitor 1 flash. It's annoying because I invariable overstep lines and have to move back and forth, constantly correcting for the lag. Any idea what it's doing as I cursor through the code? Anything I can turn off to stop this from happening? (Slowing down my key repeat rate is not an option.)
It's possibly the property pane - this was a big issue in VS2005, and VS2005SP1 not only added a feature to turn this off, but turned it off by default, however it looks like they've removed the option to turn it off in VS2008.
Scott Guthrie had a post on HTML Source Editing Performance in VS2005 SP1.
Closing the property pane may well solve the issue if you don't really use it all that much.