Maui -- How to make the background color transparent? - background

I'm trying to write a program that would be used as an overlay on top of another program. I want the text, buttons, and border to be solid, and the background to be transparent.
<VerticalStackLayout Spacing="25" Padding="30" BackgroundColor="Transparent" IsVisible="True" Opacity="1">
That works for one of the layers, but it appears that there are multiple layers.
Here it mentions changing the ContentPage, which I tried, and it appears not to be working.
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
x:Class="NameSpace.MainPage"
xmlns:local="clr-namespace:NameSpace"
BackgroundColor="Transparent">
I also tried:
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
x:Class="NameSpace.MainPage"
xmlns:local="clr-namespace:NameSpace.Core.Views.CustomControls"
BackgroundColor="Transparent">
I changed the Shell to include a Transparent background color, which didn't help.
<Shell
x:Class="NameSpace.AppShell"
xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
xmlns:local="clr-namespace:NameSpace"
Shell.FlyoutBehavior="Disabled"
BackgroundColor="Transparent">
It appears that nothing changed when changing either the ContentPage or the Shell.
None of those seem to change the background color behind the VerticalStackLayout. Any ideas?

Fully transparent windows aren't currently supported. MAUI runs on WinUI for Windows apps, and WinUI doesn't yet support transparent windows. There are open feature requests for it at:
Proposal: Borderless transparent window background support in apps using WinUI
#1247
In WinUI 3, is it possible to create a transparent Xaml Island overlay on top of parent hwnd? #2956

I know this is old question but maybe can help another you can use hex alpha for colors.
You need to use this alpha codes with color code Alpha + Color, for example #80FFFFFF
• 100% — FF
• 99% — FC
• 98% — FA
• 97% — F7
• 96% — F5
• 95% — F2
• 94% — F0
• 93% — ED
• 92% — EB
• 91% — E8
• 90% — E6
• 89% — E3
• 88% — E0
• 87% — DE
• 86% — DB
• 85% — D9
• 84% — D6
• 83% — D4
• 82% — D1
• 81% — CF
• 80% — CC
• 79% — C9
• 78% — C7
• 77% — C4
• 76% — C2
• 75% — BF
• 74% — BD
• 73% — BA
• 72% — B8
• 71% — B5
• 70% — B3
• 69% — B0
• 68% — AD
• 67% — AB
• 66% — A8
• 65% — A6
• 64% — A3
• 63% — A1
• 62% — 9E
• 61% — 9C
• 60% — 99
• 59% — 96
• 58% — 94
• 57% — 91
• 56% — 8F
• 55% — 8C
• 54% — 8A
• 53% — 87
• 52% — 85
• 51% — 82
• 50% — 80
• 49% — 7D
• 48% — 7A
• 47% — 78
• 46% — 75
• 45% — 73
• 44% — 70
• 43% — 6E
• 42% — 6B
• 41% — 69
• 40% — 66
• 39% — 63
• 38% — 61
• 37% — 5E
• 36% — 5C
• 35% — 59
• 34% — 57
• 33% — 54
• 32% — 52
• 31% — 4F
• 30% — 4D
• 29% — 4A
• 28% — 47
• 27% — 45
• 26% — 42
• 25% — 40
• 24% — 3D
• 23% — 3B
• 22% — 38
• 21% — 36
• 20% — 33
• 19% — 30
• 18% — 2E
• 17% — 2B
• 16% — 29
• 15% — 26
• 14% — 24
• 13% — 21
• 12% — 1F
• 11% — 1C
• 10% — 1A
• 9% — 17
• 8% — 14
• 7% — 12
• 6% — 0F
• 5% — 0D
• 4% — 0A
• 3% — 08
• 2% — 05
• 1% — 03
• 0% — 00

Related

how to capture HID hex button codes for usb gamepad

Hi I have some firmware I want to modify that reads from USB gamepads, I want to edit the firmware for my own gamepad
I assume these hex codes refer to up down left right and buttons on the gamepad, this gamepad is a cheap
nonbranded one detected as a Dragon rise chip in windows
0x11,0x40,0x21,0xC0,0x10,0x40,0x20,0xC0,0x36,0xFF
I need to find the correct set of 10 hex codes for a different Logitech USB gamepad, is there an easy way to find this in windows?
I have tried using hid capture program but the hex dump has lots of sets of hex codes and I don't know how to identify the buttons or directions
You need to get the report descriptor and parse it to understand how button and axis values are represented in the input report. The report descriptor format is documented in the Device Class Definition for HID.
D-pad inputs are almost always represented as a rotational axis. I have a Logitech F310 and it represents the D-pad as a 4-bit value in the lower bits of the 5th byte:
80 7F 80 7F 00 00 00 FF // Holding up
80 7F 80 7F 01 00 00 FF // Holding up + right
80 7F 80 7F 02 00 00 FF // Holding right
80 7F 80 7F 03 00 00 FF // Holding down + right
80 7F 80 7F 04 00 00 FF // Holding down
80 7F 80 7F 05 00 00 FF // Holding down + left
80 7F 80 7F 06 00 00 FF // Holding left
80 7F 80 7F 07 00 00 FF // Holding up + left
80 7F 80 7F 08 00 00 FF // Not holding any direction
Note how the value increases as we move clockwise around the D-pad. There's a special value for the "not holding any direction" state.

Newbie question: Why does this indexing work? [duplicate]

This question already has an answer here:
Why does .loc have inclusive behavior for slices?
(1 answer)
Closed 3 years ago.
I am trying to extract just the verisicolor petal length entries in the iris dataset of scikit learn. This corresponds to rows 50 to 99. I have always been told that python indexing excludes the final entry, i.e. 1:10 is all the numbers from 1 to 9.
So, why is it that the following command includes row 99? Is this inclusive indexing (where the final value is included) just a pandas thing with loc? My code is below and it works, but I dont' know why, my intuition would have been to set the index in loc to [50:100]
from sklearn import datasets
import pandas as pd
import numpy as np
iris = datasets.load_iris() #load iris
iris_df=pd.DataFrame(data= np.c_[iris['data'], iris['target']],
columns= iris['feature_names'] + ['target']) #convert iris to dataframe
versicolor_petal_length=iris_df.loc[50:99,['petal length (cm)']] #extract rows 50-99 of petal length (cm) column
print(versicolor_petal_length)
The output includes row 99,
petal length (cm)
50 4.7
51 4.5
52 4.9
53 4.0
54 4.6
55 4.5
56 4.7
57 3.3
58 4.6
59 3.9
60 3.5
61 4.2
62 4.0
63 4.7
64 3.6
65 4.4
66 4.5
67 4.1
68 4.5
69 3.9
70 4.8
71 4.0
72 4.9
73 4.7
74 4.3
75 4.4
76 4.8
77 5.0
78 4.5
79 3.5
80 3.8
81 3.7
82 3.9
83 5.1
84 4.5
85 4.5
86 4.7
87 4.4
88 4.1
89 4.0
90 4.4
91 4.6
92 4.0
93 3.3
94 4.2
95 4.2
96 4.2
97 4.3
98 3.0
99 4.1
Given this, can someone explain to me when indexing is will include the last element and when indexing will exclude it? I am having some trouble with this.
Thanks
I believe you're thinking of np.arange which belongs to the Numpy library (excludes last index as seen here) whereas df.loc is from the Pandas library and is all inclusive w.r.t indexing as seen in examples here
EDIT to add: you might also be thinking of how for loops work in python regarding the range functionality. When it comes to indexing and playing with new libraries it never hurts to double check some documentation :)
if you have any further questions feel free to ask
what you are experiencing here is a DataFrame.loc[] property.
As mentioned in the documentation as a warning and i quote:
Warning : Note that contrary to usual python slices, both the start and the stop are included
Here is a link with an example provided from the pandas docs:
https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.loc.html

How would you plot a pandas series of floats which really stand for a categorical variable?

I am learning Pandas exploring a Google Play installs dataset on kaggle:
https://www.kaggle.com/lava18/google-play-store-apps
One of the columns is "Installs" and I have converted the values from the original Object type to Float to perform basic descriptive statistics but when I look at the content:
0.000000e+00 15
1.000000e+00 67
5.000000e+00 82
1.000000e+01 386
5.000000e+01 205
1.000000e+02 719
5.000000e+02 330
1.000000e+03 907
5.000000e+03 477
1.000000e+04 1054
5.000000e+04 479
1.000000e+05 1169
5.000000e+05 539
1.000000e+06 1579
5.000000e+06 752
1.000000e+07 1252
5.000000e+07 289
1.000000e+08 409
5.000000e+08 72
1.000000e+09 58
Name: Installs, dtype: int64
It is clear that Google does not give an exact number but rather a "bin".
Plotting it with this basic command:
apps['Installs'].plot.bar()
yields an almost unintelligible image.
Suggestions for a more readable presentation?
Suggestions to graphically show the different distribution of a subset of the data (e.g. only the "Medical" app category data)?
Thank you very much.

iOS, LaunchImage Apple Watch size and name

I using xcode 6.2 beta for creating app for apple watch.
I want add 2 LunchImage for Apple Watch 38 mm and Apple Watch 42 mm.
when i Adding the Images , xcode give me the error for name of LaunchImage or error for size 449 x 449 or 136 x 170.
i want the exact name and size for LaunchImage Apple Watch 38 mm and 42 mm
The icons have a circular mask automatically applied to them. You will need icons with diameter 29, 80, and 172 pixels for 38 mm and diameter 36, 88, and 196 for 42 mm.
So create images 29x29, 80x80, 172x172, etc.
See https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/WatchHumanInterfaceGuidelines/IconandImageSizes.html#//apple_ref/doc/uid/TP40014992-CH16-SW1

x86 binary bloat - 32-bit offsets when 8-bits would do

I'm using clang+LLVM 2.9 to compile various workloads for x86 with the -Os option. Small binary size is important and I must use static linking. All binaries are 32-bit.
I notice that many instructions use addressing modes with 32-bit displacements when only 8 bits are actually used. For example:
89 84 24 d4 00 00 00 mov %eax,0xd4(%esp)
Why didn't the compiler/assembler choose the compact 8-bit displacement?
89 44 24 d4 mov %eax,0xd4(%esp)
In fact, these wasted addressing bytes are over 2% of my entire binary!
I looked at LLVM's link time optimization and tried --emit-llvm, but it didn't mention or help this issue.
Is there some link-time optimization that can use knowledge of the actual displacements to choose the smaller instruction form?
Thanks for any help!
In x86, offsets are signed. This allows you to access data on both sides of the base address. Therefore, the range of an 8 bit offset is -128 to 127. Your instruction is referencing data 212 bytes forward (the value 0xD4 in decimal). If it had been encoded using an 8 bit offset, it would be -44 in decimal, which is not what you wanted.