Disable cookie secure option in vite --host

Describe the problem
Thanks to the localhost exception, cookies can be set in the development environment with ease.

The httpOnly and secure options are true by default (except on http://localhost/, where secure is false)

https://kit.svelte.dev/docs/types#public-types-cookies

However, the exception is not applied if the Vite server is exposed over the network, and is accessed using an IP address.
npx vite dev --host

# VITE v4.4.4  ready in 612 ms

cookies.set('name', 'value');

//  Local:   http://localhost:5173/ ← works
//  Network: http://<IP_ADDRESS>:5173/ ← does not work
//  Network: http://<IP_ADDRESS>:5173/ ← does not work

Describe the proposed solution
Disable the secure option in the cookies.set() API if it is a Vite dev server. (and possibly in the preview server)
Alternatives considered
No response
Importance
nice to have
Additional Information
No response

Current implementation checks for http://localhost

https://github.com/sveltejs/kit/pull/7090

https://github.com/sveltejs/kit/blob/8c4b74cdb9f9bc4de16e7a7cb2dfe38fc9e92db6/packages/kit/src/runtime/server/cookie.js#L33-L38
Why not check for the http:// protocol and the dev value in the $app/environment module?

Whether the dev server is running. This is not guaranteed to correspond to NODE_ENV or MODE. — https://kit.svelte.dev/docs/modules#$app-environment-dev

Would there be security issues with this?

Ran also into this because I'm encapsulating my project in a docker container, so --host is a must.
The barbaric workaround is to edit the cookie.js file before running in dev mode
sed -i "/secure:/c\\\t\tsecure:false" $(find . -name "cookie.js")

and then restore it to its original form afterwards
sed -i "/secure:/c\\\t\tsecure: url.hostname === 'localhost' && url.protocol === 'http:' ? false : true" $(find . -name "cookie.js")

This works if using GNU sed and might need adjusments if running on mac

I've settled on this workaround for the dev environment.
import { sveltekit } from '@sveltejs/kit/vite';
import basicSsl from '@vitejs/plugin-basic-ssl';
import { defineConfig } from 'vitest/config';

export default defineConfig({
  plugins: [
    ...(process.argv.includes('--host') ? [basicSsl()] : []), //
    sveltekit(),
  ],
});

It conditionally loads the @vitejs/plugin-basic-ssl plugin.
pnpm dev

#  VITE v5.0.10  ready in 533 ms
#
#  ➜  Local:   http://localhost:5174/
#  ➜  Network: use --host to expose

pnpm dev --host

#  VITE v5.0.10  ready in 574 ms
#
#  ➜  Local:   https://localhost:5173/
#  ➜  Network: https://<IP_ADDRESS>:5173/
#  ➜  Network: https://<IP_ADDRESS>:5173/
#  ➜  press h + enter to show help

The above workaround does not work in vite preview or npm preview.
Since they run the app in Node.js, all Node.js adapter related restrictions apply as well.

HTTP doesn't give SvelteKit a reliable way to know the URL that is currently being requested. The simplest way to tell SvelteKit where the app is being served is to set the ORIGIN environment variable:

Here is the updated vite.config.ts file.
Note that the isPreview check is broken as of now.

https://github.com/vitejs/vite/issues/15694

import { sveltekit } from '@sveltejs/kit/vite';
import basicSsl from '@vitejs/plugin-basic-ssl';
import { defineConfig } from 'vitest/config';

export default defineConfig(({ command, isPreview }) => {
  const exposed = command === 'serve' && process.argv.includes('--host');

  if (exposed && isPreview) {
    console.error('🔴 In the preview mode, the Node.js server cannot determine the request URL.');
    console.error('🔴 If the CSRF protection is enabled (default) POST form submits will fail.');
  }

  return {
    plugins: [
      //
      ...(exposed && !isPreview ? [basicSsl()] : []),
      sveltekit(),
    ],
  };
});

Vite

https://github.com/vitejs/vite/discussions/8891
https://github.com/vitejs/vite/pull/8986

Is using the dev variable good enough for this? e.g, secure: !dev to only enable secure in production
https://kit.svelte.dev/docs/modules#$app-environment-dev

@eltigerchino It is a viable, shortterm workaround.
import { dev } from '$app/environment';

export const load = ({ cookies }) => {
  cookies.set('name', 'value', { path: '/', secure: !dev });
};

The limitations are:

has to be specified in every cookies.set()
vite preview --host cannot be determined

Should I add vite preview in the issue title and body?

you can have a secure dev server too, so this setting would have to be derived from the url ( secure = url.startsWith('https://')

Updated workaround:

force secure cookie in preview and production (e.g. Node.js adapter build)
follow URL protocol in dev mode (which can be https:, e.g. Vite basic SSL)

import { dev } from '$app/environment';

export const load = ({ cookies, url }) => {
  cookies.set('name', 'value', { path: '/', secure: !dev || url.protocol === 'https:' });
};


Empty response

I open the MagicMirror with npm start dev. When I put startAlexa() in the console, the status indicator switch from red to green. After a few seconds it's schwitched back to red. Now I can read "Error: Empty response. at XMLHttpRequest.xh.onload {alexaRunner.babel.is:618}" in the console. Can anyone help me ?

probably the voice data you sent is empty, that's why you're receiving empty response. please check if your electron app(magic mirror) can access to microphone or not


Question: How can you change the color of UI objects with the CanvasBackplate.mat attached (NearMenue, Buttons etc.)

Describe the issue
I want to experiment a bit with different colors but also want to use given Prefabs like the NearMenue Prefab. Sadly the material including the colors are locked and can't be edited. Unpacking the prefab change nothing. The CanvasBackplate.mat is in the Packages and my new Material is under Assets/Materials
i use MRTK3 pre 12
Feature area
Searching for material gives lot of cool features but I can't try them out because I can't access the material.
Existing doc link
https://learn.microsoft.com/en-us/windows/mixed-reality/mrtk-unity/mrtk2/features/rendering/mrtk-standard-shader?view=mrtkunity-2022-05
Additional context

PS:
https://github.com/MicrosoftDocs/mixed-reality/blob/docs/mrtk-unity/mrtk3-uxcomponents/packages/uxcomponents/mixed-reality-design-language.md
Something with the formatting here seems wrong

Hi @HaiKonofanDesu, the formatting in that link seems messed up because it uses MSDocs-specific formatting. You can see the official docs (formatted) here: https://learn.microsoft.com/en-us/windows/mixed-reality/mrtk-unity/mrtk3-uxcomponents/packages/uxcomponents/mixed-reality-design-language
As for changing colors: we'll recommend using the UI theming system that should be ready by GA. There's an early version of the theming system that's currently set up for the non-canvas UI prefabs, but we're still working on the theming story and it's subject to change by the time GA comes out. I'd hold off on experimenting with colors/style until then, if possible.


llm response truncated for llama2

Hi Simon, the responses from llama2 have been truncated. What is the good way for llm to handle this? see
% llm -m l2c "give me 20 good names for avatars" --system "you are a creator"
Sure, here are 20 creative and unique name suggestions for avatars:

Aurora Sparklefeather
Zephyr Starlight
Nova Frostbite
Luna Nightshade
Astrid Stormbringer
Lyra Moonwhisper
Niamh Fireheart
Zara Wildfire
Calliope Cosmos
Phoebe Cosmicray
Willow Waverider
Echo Nightwalker
Elara Star

I don't see the same issue you are seeing, but I am running into issues where I can't seem to exceed more then ~1500 or 2k tokens. I did notice this tonight while playing around with the ollama library and wanted to pass it along in case it's helpful.
I was comparing values and one that stuck out to me was from the ollama library. see num_ctx here: https://github.com/jmorganca/ollama/blob/main/docs/modelfile.md#valid-parameters-and-values
I can change ollama's max token limit (num_ctx=8192) and it works as expected. This makes me wonder if the wrong value isn't being accepted (or I don't know how to use llm which is quite possible)

Can you provide more details? Is l2c aliases to a llama model accessed via the replicate plugin, or llm-llama-cpp?
I'm guessing the latter, since l2c is the suggested alias here:
https://simonwillison.net/2023/Aug/1/llama-2-mac/
A general tip: try re-running again with  --no-log, to force it to generate a different solution (without this you are stuck getting the truncated response for the same prompt).
As a general observation I have found the 7B model to give quite short or truncated answers. Weirdly when I access it via the replicate plugin I sometimes get responses as short as one letter or word (and I can't seem to replicate this on the playground).
I have had more success with 70B but YMMV

Increasing the -o max_gen_len 4096 worked for me with different models.

Doesn't seem to be an option for me?
~ via 🌙 via 🐍 v3.11.5 took 24s
λ llm models list --options
[...]
LlamaModel: llama-2-7b-chat.ggmlv3.q8_0 (aliases: llama2-chat, l2c)
  verbose: boolean

~ via 🌙 via 🐍 v3.11.5
λ llm "how do i increase the output token count for this llm" -m l2c -o max_gen_len 4096
Error: max_gen_len
  Extra inputs are not permitted


Add JIT-EE interface wrappers to handle exceptions

Added a managed wrapper to catch managed exceptions thrown by the JIT-EE
interface implementation. Added an unmanaged wrapper to re-throw the
exceptions for the compiler.
TBD: Capture message and call stack of the managed exception, and define
a custom unmanaged exception to include these information.

Hi @JohnChen0, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

Could you please remove _skipJitList from Compilation.cs and make sure that everything still works?

cc @kyulee1 @russellhadley It would be nice to push the unmanaged part of this wrapper into the JIT (ie build it as part of the JIT .dll). What do you think?
Among other things, it would make the life easier for llilc - it would not need to depend on the private CoreCLR exception macros and EH implementation details.

@jkotas Pushing the unmanaged part of this wrapper into the JIT makes sense instead of having additional DLL for this purpose. The wrapper layout seems to be auto-generated/flattened from ICorJit data structure. Does it mean we need such auto-generation step (TunkGeneration) integreated inside RyuJit and Llilc for each? Is this wrapper (if integrated inside Jit) only needed for CoreRT where EE is managed?

Does it mean we need such auto-generation step (TunkGeneration) integrated inside RyuJit and Llilc for each?

The step to auto-generate the wrapper is manual right now. I do not think it is worth the effort to make it automatic (to be done as part of every build). Maybe the wrapper can be part of the JIT SDK.

Is this wrapper (if integrated inside Jit) only needed for CoreRT where EE is managed?

Yes. I am thinking that RyuJIT .dll can have two exports: getJit - that does exactly what it does today; and getJit2 - that goes through the wrapper.

@jkotas Is there a specific reason to have the two exports instead of just one that allows the exceptions pass through since we would always need to do that?

The same RyuJIT .dll can be used by either CoreCLR or ilc today. I think it would be really nice to preserve this capability for engineering efficiency (assuming it does not cost too much, also there are different opinions about this across the JIT team).

@kyulee1, I think you could also use this shim to hook up LLILC behind the scenes from corert, based on some env setting.

@jkotas @MichalStrehovsky Could you please take a look?
Updated this PR to resolve known issues. The following changes are present:

When JIT calls into the JIT-EE interface, the calls is wrapper. All managed exceptions are caught by the wrapper, and re-throw as native exceptions.
The call from ILCompiler to JIT is also wrapper. The wrapper catches all native exceptions, and re-throws them as managed exceptions.
The message and call stack from the original managed exception is captured and stored in the unmanaged exception object, and restored in the managed exception thrown by the JIT wrapper.
A new native module (jitinterface.dll or jitinterface.so) is added to contain the native part of the wrappers. Long term, we should consider whether to merge this into JIT.
Removed most, but not all, entries from _skipJitList. A couple of methods still cause errors unrelated to exception handling.

Removed most, but not all, entries from _skipJitList. A couple of methods still cause errors unrelated to exception handling

What kind of errors are these? They should be caught by the toolchain.

They are undefined reference errors. Here are the error messages. Only Hello.dll fails. The other two succeeds.
Input Assembly: /home/john/corert/tests/src/Simple/Hello/bin/Debug/dnxcore50/Hello.dll
/home/john/corert/tests/src/Simple/Hello/obj/Debug/dnxcore50/Hello.obj: In function jmpstub_GetNativeSystemInfo': (.text+0x23975): undefined reference to GetNativeSystemInfo'
/home/john/corert/tests/src/Simple/Hello/obj/Debug/dnxcore50/Hello.obj: In function jmpstub_CreateEventExW': (.text+0x280f1): undefined reference to CreateEventExW'
/home/john/corert/tests/src/Simple/Hello/obj/Debug/dnxcore50/Hello.obj: In function jmpstub_CoGetApartmentType': (.text+0x28a55): undefined reference to CoGetApartmentType'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Compilation of intermediate files failed.

@JohnChen0 You're compiling against the Windows version of CoreLib. You need use the one you built on Linux (or pass /p:TargetsLinux=true to msbuild I think).

We have hit portion of System.CoreLib that was not ported to Unix yet. We should add a stubs for these methods to src\Native\Bootstrap\main.cpp and open issues to get it properly ported.

LGTM otherwise. Thanks!

Updated the PR to address all review feedbacks. _skipJitList is now completely gone.

LGTM module comments

:+1:


Kishlay96 added Readme file

Started Devops  Today.

Can you add folders for each day under your name? Check out example repos in the main README

@Kishlay96 you have not updated for a week, closing the PR , feel free to reopen and add your progress and take help from Anurag!


Laravel 5 Big Problem, Exceptions not shown anymore

I just confirmed after some tests that whenever I add this
        $applicationAspectKernel = ApplicationAspectKernel::getInstance();
        $applicationAspectKernel->init([
            'cacheDir' => storage_path('aop'),
            'debug' => env('APP_DEBUG', false),
            'includePaths' => [
                app_path('Models'),
                app_path('Controllers'),
            ]
        ]);

Then the exceptions thrown in my application don't seem to get caught anymore and I end up staring at a white screen instead of the usual Laravel stack trace for the exception.

I must have had a faulty configuration, seems to work back to normal now. Sorry about that.


JHLite: Spring Boot 3 - remove Zalando

Links:

https://github.com/jhipster/jhipster-lite/issues/3601
https://github.com/jhipster/jhipster-lite/pull/3832

You can use this branch: https://github.com/jhipster/jhipster-lite/tree/spring-boot-3 and submit a pull request against this branch
Zalando should be removed and ExceptionTranslator should be reworked
Then, it should fix the following tests:

ForcedProjectFolderPrefixIntTest
ExceptionTranslatorIT
CucumberTest

I think we should updated the error management to handle internationalized error on the server side (so it can be tested) as described in https://github.com/jhipster/jhipster-lite/issues/2794

Which module should provide the ExceptionTranslator ? Should this not be in a dedicated web-exception-handling module?

@biergit : yes, it should be done in a dedicated module, replacing the current one, Zalando problem


revert(packages): delete dummies packages

Description
Please describe the reason related to the changes:
Type
Please select the type related to the changes:

[ ] bugfix
[ ] build
[ ] continuous delivery (CD)
[ ] continuous integration (CI)
[ ] documentation
[ ] feature
[ ] formatting
[ ] refactoring
[ ] styling
[ ] other (please describe below):

Breaking Change
Does your changes introduce a breaking change?

[ ] no
[ ] yes

Behavior
Please describe the current behavior:
Changes
Please describe the new behavior:
Information (issue, links, logs, etc.)
Please list any other useful information:
Checklist
Please make sure this pull request follow the requirements

[ ] commit guidelines @commitlint/config-conventional
[ ] 100% code coverage
[ ] tests passing

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.2%) to 98.462%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63

Relevant Lines:
63

💛  - Coveralls


KAFKA-16192: Introduce transaction.version and usage of flexible records to coordinators

This change includes adding transaction.version (part of KIP-1022)
New transaction version 1 is introduced to support writing flexible fields in transaction state log messages.
Transaction version 2 is created in anticipation for further KIP-890 changes.
Neither are made production ready. Tests for the new transaction version and new MV are created.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Ack -- I suppose so. I was hoping it would be merged by today 😅

In the meantime I will fix the test failure. Whoops.

Yeehaw time to rebase

I think I also need to fix the case where max version is 0 as well. 🤔

Will look at the apiversions test failures 👍

Given that Kraft version starts at 0, I guess we should have all versions start a zero for consistency. I also noticed one test asserts all features with version zero bootstrap with minimum kraft version.

@jolshan : Thanks for the updated PR. The following test failure seems related to the PR.
[2024-07-23T02:46:53.731Z]
[2024-07-23T02:46:53.731Z] Gradle Test Run :metadata:test > Gradle Test Executor 88 > QuorumFeaturesTest > testDefaultFeatureMap() STARTED
[2024-07-23T02:46:53.731Z] org.apache.kafka.controller.QuorumFeaturesTest.testDefaultFeatureMap() failed, log available in /home/jenkins/jenkins-agent/workspace/Kafka_kafka-pr_PR-16183/metadata/build/reports/testOutput/org.apache.kafka.controller.QuorumFeaturesTest.testDefaultFeatureMap().test.stdout
[2024-07-23T02:46:53.731Z]
[2024-07-23T02:46:53.731Z] Gradle Test Run :metadata:test > Gradle Test Executor 88 > QuorumFeaturesTest > testDefaultFeatureMap() FAILED
[2024-07-23T02:46:53.731Z]     org.opentest4j.AssertionFailedError: expected: <{kraft.version=0, transaction.version=0, metadata.version=1-20}> but was: <{metadata.version=1-20}>
[2024-07-23T02:46:53.731Z]         at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
[2024-07-23T02:46:53.731Z]         at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
[2024-07-23T02:46:53.731Z]         at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
[2024-07-23T02:46:53.731Z]         at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
[2024-07-23T02:46:53.731Z]         at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
[2024-07-23T02:46:53.731Z]         at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
[2024-07-23T02:46:53.731Z]         at org.apache.kafka.controller.QuorumFeaturesTest.testDefaultFeatureMap(QuorumFeaturesTest.java:69)

Some of the gradle task executors failed so I will run again.


Remove hardcoded references to ".2" API in services file

See:
https://github.com/almighty/almighty-ui/blob/master/src/app/work-item/work-item.service.ts

@ldimaggi once we migrate completely from workitems to workitems.2 then the workitems.2 will become workitems, so it's just a matter of time.

@sanbornsen is this done?

Yes, we can close this.


Prism.js breaks menu toggle on IE9-11.

When viewing my Fabricator instance in IE the menu is suppressed and won't toggle. I wasn't seeing any JS console errors.
I've found that downloading the default development version here: http://prismjs.com/download.html and replacing src/assets/fabricator/scripts/prism.js restores functionality.

I believe this is a duplicate of #142 and is fixed by #149.
New release coming soon.

Hey there,
I don't mean to gravedig on this but I can confirm the newest version of Fabricator has this issue in IE11 and the same resolution proposed by @mandalatv still successfully resolves it.


Update vulnerable dependencies - lodash and fullname

Purpose of this pull request?

[ ] Documentation update
[ ] Bug fix
[ ] Enhancement
[x] Other, please explain:

Fix vulnerabilities reported by npm audit.
What changes did you make?
Update vulnerable dependencies - lodash and fullname as reported by npm audit
Is there anything you'd like reviewers to focus on?
Nothing specific

Thanks

@SBoudrias - Thanks for a quick turnaround. :)
Could you also please release a version bump package so that i am able to use it in my project.


Missing CSS - pace-theme-material.css

After installing on:
Ember:
version: 1.13.15
node: 4.2.6
npm: 2.14.10
os: linux x64
Using ENV.pace settings from example.
pace:{
     // addon-specific options to configure theme
     theme: 'material',
     color: 'blue',

....
And starting with:
ember server --proxy http://<IP_ADDRESS>:3000 &
I get this:
Error: Pace theme CSS file was not found: blue/pace-theme-material.css
at Class.module.exports.treeFor (/home/csmith/Development/dali/dali-analytics-ui/node_modules/ember-cli-pace/index.js:80:15)
at /home/csmith/Development/dali/dali-analytics-ui/node_modules/ember-cli/lib/broccoli/ember-app.js:371:20
at Array.map (native)
at EmberApp.addonTreesFor (/home/csmith/Development/dali/dali-analytics-ui/node_modules/ember-cli/lib/broccoli/ember-app.js:369:30)
at EmberApp.styles (/home/csmith/Development/dali/dali-analytics-ui/node_modules/ember-cli/lib/broccoli/ember-app.js:1105:25)
at EmberApp.toArray (/home/csmith/Development/dali/dali-analytics-ui/node_modules/ember-cli/lib/broccoli/ember-app.js:1390:10)
at EmberApp.toTree (/home/csmith/Development/dali/dali-analytics-ui/node_modules/ember-cli/lib/broccoli/ember-app.js:1411:30)
at module.exports (/home/csmith/Development/dali/dali-analytics-ui/ember-cli-build.js:34:14)
at Class.module.exports.Task.extend.setupBroccoliBuilder (/home/csmith/Development/dali/dali-analytics-ui/node_modules/ember-cli/lib/models/builder.js:57:19)
at Class.module.exports.Task.extend.init (/home/csmith/Development/dali/dali-analytics-ui/node_modules/ember-cli/lib/models/builder.js:91:10)
There appears to be no blue/pace-theme-material.css file in the install package
Changed config to:
pace:{
     // addon-specific options to configure theme
     theme: 'big-counter',
     color: 'blue',

and it works.  Sample configuration should be updated.
Thanks

You're right the material theme is not present on pace.js, there's an open PR for adding it: https://github.com/HubSpot/pace/pull/214
I've updated the docs to fix this issue.


Implement assets packaging

Hi!
You write in the instructions that you can also use your tool for repacking. Unfortunately, the repack assets button cannot be clicked. Only the repack sprites can be clicked. Can you please tell me how I can repack the edited files?
bye

Yes, assets repackaging are not yet implemented.
In the meantime, you can store raw assets in root game folder and engine should prefer them over packaged ones.
Or use another tool like agsutils.

Hi!
Okay, thank you for that hint. :-)
bye
Am Montag, 30. Dezember 2024 um 23:35:04 MEZ hat Adam Worgen<EMAIL_ADDRESS>Folgendes geschrieben:

Yes, assets repackaging are not yet implemented.
In the meantime, you can store raw assets in root game folder and engine should prefer them over packaged ones.
Or use another tool like agsutils.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


uri: /manage/api/v1/devices//binding error - looks like a typo?

loud_api_sample_1  | 2022-12-24 04:25:45.613 DEBUG 7 --- [nio-6789-exec-4] c.dji.sample.component.AuthInterceptor   : request uri: /manage/api/v1/devices//binding
cloud_api_sample_1  | 2022-12-24 04:25:45.616 DEBUG 7 --- [nio-6789-exec-4] c.dji.sample.component.AuthInterceptor   : request uri: /error
cloud_api_sample_1  | 2022-12-24 04:25:46.409  INFO 7 --- [ask-scheduler-9] c.d.s.w.s.impl.FlightTaskServiceImpl     : Check the timed jobs of the wayline. null

window.djiBridge.platformGetRemoteControllerSN() This method does not recognize the remote control SN, it is recommended to restart the remote control.


Referencing the default variable without setting it causes an error

Referencing the default variable without setting it causes an error.  For example:
chomp;

generates code that refers to _d without it being initialized.

Fixed in v0.990


[Feature request] Hideable widget bar

Just a thought here, but I see a lot of clock apps now having an option to hide the widgets.
Maybe we could have a library (in modules) that adjusts the widget draw call such that it renders widgets to an offscreen buffer. Swipe-down could then make the widget bar slide out of the top of the screen, and after a few secs it could pop back up.
Having it as a library would mean we could avoid a bunch of code duplication too.

This is an excellent idea, I used a watchface without a widget zone was disappointed that they weren't still running. Great idea!

I wonder if this needs to be a library, or an installable boot code app that "just works" for all clocks?

It's an idea - it's just getting clocks to work with it. Many of them will just assume there's always a widget bar and leave 24px spare all the time.
Also, I guess we want it to only work for clocks, not all apps?

Also, I guess we want it to only work for clocks, not all apps?
I think it is also useful to extend it to apps.
the downside is that the "Swipe-down" command cannot be used (unless overwritten) and I don't know if it could interfere with scrolling through the menus ....
in any case, I think it is good to have a "standard" that manages the visibility of the widgetbar (personally I don't use it and the apps I use / have written don't display the widgetbar in order to have more screen space)

getting clocks to work with it. Many of them will just assume there's always a widget bar and leave 24px spare all the time.

Sure, but just having that empty space for a "cleaner" look would be a nice start, and then we can just convert clocks/apps to properly use appRect when it comes up.

I guess we want it to only work for clocks

the downside is that the "Swipe-down" command cannot be used

Maybe we could split it into two separate options?

Clock widgets: Show/Hide/Swipe
App widgets: Show/Hide/Swipe -> If you choose "Swipe" and it interferes with an app, that's your own fault... (But probably we can make it so that you just won't get the widget bar at all in 90% of problem cases.)

I don't use it and the apps I use / have written don't display the widgetbar

That should be possible by just not installing any widgets: if code is doing something it should go into a boot.js file.
(Not saying it works like that now, just how I'd like things to be)
For non-clock apps, I feel trading the widgetbar for screen space is fine, but for clocks it would be nice if they looked at appRect, and at least can work for users that do want widgets.

Whoops, I was thinking of the Bangle.js 1, totally forgot that setLCDOffset() won't work on the Bangle.js 2.
I've got some working code for Bangle.js 2, but  it has no way to tell apps to repaint the top area after we show and hide the widget bar :-(
// widhide.boot.js

Bangle.loadWidgets = (o => () => {
  o();
  if (Bangle.CLOCK) Bangle.appRect = {
    // apps can use the complete screen now
    x: 0, y: 0,
    w: g.getWidth(), h: g.getHeight(),
    x2: g.getWidth()-1, y2: g.getHeight()-1,
  };
})(Bangle.loadWidgets);

Bangle.drawWidgets = (o => () => {
  if (!Bangle.CLOCK) return o();
  // draw widgets to buffer instead of screen
  if (!Bangle.widgetBuffer) Bangle.widgetBuffer = Graphics.createArrayBuffer(
    g.getWidth(),
    24,
    4,
    {msb: true}
  );
  let _g = g;
  g = Bangle.widgetBuffer;
  o();
  g = _g;
  // draw the buffer at the offset position (0 = completely offscreen, 24 = fully visible)
  g.drawImage(Bangle.widgetBuffer, 0, (Bangle.widgetBuffer.o|0)-24);
})(Bangle.drawWidgets);

Bangle.on("swipe", (_, d) => {
  if (!Bangle.CLOCK || !d) return; // not a clock, or horizontal swipe
  if (!Bangle.widgetBuffer) Bangle.drawWidgets();
  let w = Bangle.widgetBuffer; // we also save 'o'ffset, 'm'ovement and a 't'imeout in the buffer object
  if (w.m*d>0) return; // already moving/moved in this direction
  w.m = 2*d; // movement: same direction as swipe
  if (w.t) clearTimeout(w.t);
  delete w.t;
  function anim() {
    w.o = Math.min(24, w.m+(w.o|0)); // calculate new offset (0 = 24 pixels above screen = hidden)
    g.setClipRect(0, 0, g.getWidth(), 24) // make sure we can paint to the widget area
      .drawImage(w, 0, w.o-24);
    if (w.m>0) { // moving down: sliding into view
      if (w.o<24) {
        w.t=setTimeout(anim, 10);
      } else w.t=setTimeout(() => {
        // auto-hide after 10 seconds
        if (w.o>=24 && w.m>=0) {
          w.m = -2;
          anim();
        }
      }, 10e3);
    } else { // moving up: sliding out of view
      g.clearRect(0, w.o, g.getWidth()-1, w.o-w.m);
      if (w.o>0) w.t=setTimeout(anim, 10);
    }
    g.setClipRect(0, w.o, g.getWidth()-1, g.getHeight()-1); // prevent app from drawing over widgets
  }
  anim();
});

Yes, this is the problem... You can use g.asImage to get a copy of what's on the screen at that moment on Bangle.js 2 so it can be written back, but it does end up being pretty big (784 vars). Then there's what happens if an app tries to draw to the screen.
Something like:
// save
oldg = g;
g = Graphics.createArrayBuffer(176,176,4)
g.drawImage(oldg.asImage());
// restore
oldg.drawImage({width:176,height:176,bpp:4,buffer:g.buffer, palette:new Uint16Array([...])});
g = oldg;

would work (ish) but it's pretty inefficient with memory, and any updates to the clock/app in the meantime would end up undithered.
Also looks like your code doesn't override the widget draw, so widgets like battery that auto-update would still break things.
I think this is one reason to have a library rather than boot code - the app can give the widget hider a callback for redraw, and could also avoid redraws itself when widgets were showing, so things would go a lot more smoothly.
Otherwise I think to do this nicely there'd need to be some kind of firmware mod

there's what happens if an app tries to draw to the screen

your code doesn't override the widget draw, so widgets like battery that auto-update would still break things.

Yeah, I only thought about that later. Overriding draw seems doable, but its starting to get "a bit" hacky...
If we get the widget side of things to work, I figured for app support there are two options:

add a library, so apps can redraw themselves
don't adjust appRect: simply keep the top 24px empty while hiding widgets. You get a cleaner screen, but not more app-space

I'm thinking we might do both: add a library, but if apps don't use it just leave the widgetbar blank?

add a library, but if apps don't use it just leave the widgetbar blank?

Could do, but personally it seems like if you have the space you should use it.
I'm thinking maybe I should just add another 24px (or more) to the top of the offscreen buffer and allow setting the Bangle.js screen offset like we do on Bangle.js 1? In the long run that's probably easier.

add another 24px (or more) to the top of the offscreen buffer

That's probably the way to go, I'm pretty much convinced now this needs firmware support.
I've no idea how much work that is and how badly we'll miss that RAM though, so I guess it's up to you to decide if we should go ahead with it just for hiding widgets...
(To be honest I'm quite happy with always-visible widgets, this just looked like a interesting feature to code.)

I just took a look at adding fw support, but there's something a bit odd going on and I can't figure it out at the moment.
This is actually the code that I'd done before for this:
Bangle.loadWidgets();
Bangle.drawWidgets();

Bangle.widgetAreaGfx = undefined;

function hide() {
  if (Bangle.widgetAreaGfx) {
    g.drawImage(Bangle.widgetAreaGfx,0,0);
    Bangle.widgetAreaGfx = undefined;
  }
  Object.keys(WIDGETS).forEach(wi=>{
    var w = WIDGETS[wi];
    var hide = true;
    if (w.area=="tl") w.area="hl";
    else if (w.area=="tr") w.area="hr";
    else hide = false;
    if (hide) {
      w.olddraw = w.draw;
      w.draw = ()=>{};
    }
  });
}

function show() {
  Bangle.widgetAreaGfx = Graphics.createArrayBuffer(g.getWidth(),24,16);
  Bangle.widgetAreaGfx.drawImage(g.asImage()); // a bit inefficient!
  Object.keys(WIDGETS).forEach(wi=>{
    var w = WIDGETS[wi];
    var hide = true;
    if (w.area=="hl") w.area="tl";
    else if (w.area=="hr") w.area="tr";
    else hide = false;
    if (hide) {
      w.draw = w.olddraw;
      delete w.olddraw;
    }
  });
  Bangle.drawWidgets();
}

hide();
g.clear(1).drawLine(0,0,200,200).drawString("HELLO WORLD");

So you can hide and show widgets and the background is still kept around. BUT if the app tries to draw while the widgets are shown it'll overwrite them.

Just a note on firmware support - while we could do a simple scroll I'm still in two minds about whether there should be to ability to   do something a bit more flexible (like allowing notifications over the middle of the screen) as folks have requested that for alarms/notifications/etc - but I think that could be a minefield

I like the sound of adding the extra 24px to the offscreen buffer, it gives us other ways to show the widgets then too, like shake to show widgets.
It kind of reminds me of how the Pebble used to do some notifications, popping up on the bottom of the screen and pushing the rest of the display up, and dropping back down after a short while.
In fact, if we had an extra 24px at the top of the screen for widgets, and an extra space at the bottom for notifications, that could be quite a neat interface: drag up or down to show extra things in either direction.

I've had a go at converting the code from @gfwilliams and @rigrig above to use the new Bangle.setLCDOverlay. It works quite well, but only for widgets which call Bangle.drawWidgets() to update their display. Any that directly call the widget .draw() function still draws on the main display. Any better ideas other than altering all widgets to alway use Bangle.drawWidgets()?
It also needs clocks that correctly use Bangle.appRect to set their view size.
// widhide.boot.js

Bangle.widgetsShown = false;

Bangle.loadWidgets = (o => () => {
//  console.log('loadWidgets');
  o();
  if (Bangle.CLOCK) Bangle.appRect = {
    // apps can use the complete screen now
    x: 0, y: 0,
    w: g.getWidth(), h: g.getHeight(),
    x2: g.getWidth()-1, y2: g.getHeight()-1,
  };
})(Bangle.loadWidgets);

Bangle.drawWidgets = (o => () => {
  if (!Bangle.CLOCK) return o();
//  console.log('drawWidgets');
  // draw widgets to buffer instead of screen
  if (!Bangle.widgetBuffer) Bangle.widgetBuffer = Graphics.createArrayBuffer(
    g.getWidth(), 24, 8, {msb: true}
  );
  let _g = g;
  g = Bangle.widgetBuffer;
  o();
  g = _g;
  if (Bangle.widgetsShown) Bangle.setLCDOverlay(Bangle.widgetBuffer, 0, 0);
})(Bangle.drawWidgets);

Bangle.on("swipe", (_, d) => {
  if (!Bangle.CLOCK || !d) return; // not a clock, or horizontal swipe
  if (!Bangle.widgetBuffer) Bangle.drawWidgets();

  if (Bangle.widgetBuffer.m*d>0) return; // already moving/moved in this direction
  Bangle.widgetBuffer.m = d; // movement: same direction as swipe

  if (d>0) {
//    console.log('Show widgets');
    Bangle.widgetsShown = true;
  } else {
//    console.log('Hide widgets');
    Bangle.widgetsShown = false;
    Bangle.setLCDOverlay();
  }
  Object.keys(WIDGETS).forEach(wi=>{
    var w = WIDGETS[wi];
    if (Bangle.widgetsShown) {
//      console.log('Enable widget draw', wi);
      if (w.olddraw) {
        w.draw = w.olddraw;
        delete w.olddraw;
      }
    } else {
//      console.log('Disable widget draw', wi);
      w.olddraw = w.draw;
      w.draw = ()=>{};
    }
  });
  if (Bangle.widgetsShown) Bangle.drawWidgets();
});

Any better ideas other than altering all widgets to alway use Bangle.drawWidgets()?

:o yes, don't do that!
Instead of overwriting g in drawWidgets, why not rewrite each draw handler to do it:
Object.keys(WIDGETS).forEach(wi=>{
    var w = WIDGETS[wi];
    w.olddraw = w.draw;
    w.draw = function(){
     let _g = g;
     g = Bangle.widgetBuffer;
     this.olddraw(this);
     g = _g;
     if (Bangle.widgetsShown) Bangle.setLCDOverlay(Bangle.widgetBuffer, 0, 0);
    };
  });

'Why not' is always a good question!

Just because you end up redrawing all widgets all the time, when maybe you only wanted to change one part of one widget (eg to make it flash on and off).

I've changed drawWidgets to always give us a new blank buffer,

Ahh - yes, the original drawWidgets just does a clearRect: https://github.com/espruino/Espruino/blob/master/libs/js/banglejs/Bangle_drawWidgets_Q3.js
Personally I'd allocate the Graphics at the start and just do widgetBuffer.clear(1) in drawWidgets... But this looks great.
Only thing it's missing is slowly moving setLCDOverlay downwards so it does a nice animation ;)

the original drawWidgets just does a clearRect

I hadn't spotted that. Turns out it still does, so I'll need to stop that.

Only thing it's missing is slowly moving setLCDOverlay downwards so it does a nice animation ;)

Yeah, I've had a go, it's harder than it sounds! I had a look at it here: http://forum.espruino.com/conversations/379983
The gist of it is that you can set an image partially off the screen, with a negative position: g.drawImage(img, 0, -10); But that doesn't seem to work with Bangle.setLCDOverlay(img, 0, -10);, I just got nothing appearing on the screen until it hit 0 or positive.

I just got nothing appearing on the screen until it hit 0 or positive.

Ahh, that's a shame. That could well be a firmware issue then :)

As a workaround, you could add another buffer...

I've tweaked the code, now here: https://github.com/sir-indy/BangleApps/tree/widget-hide/apps/widhide
It's not on my apploader at the moment, I've got that on a different branch to play with messages.

That could well be a firmware issue then :)

I think you're right, and I think it's here: https://github.com/espruino/Espruino/blob/5a99fbdafedf5b8a551ac53f2370c76f63be9523/libs/graphics/lcd_memlcd.c#L308-L309
I believe (though could be wrong) that's it's converting the int position that we give it to an unsigned number, so it's not drawing in the correct place. Does that sound likely?

I think you're right, and I think it's here

That sounds like it - thanks! I've just pushed some changes (and tested) and with the latest cutting edge builds you should now be able to display the overlay with negative offsets

Ah ha! With firmware 2v15.29, drawing off screen works! Thank you Gordon!
Updated my repo above with animation code. It works! And looks good!

I've tweaked the code, now here: https://github.com/sir-indy/BangleApps/tree/widget-hide/apps/widhide It's not on my apploader at the moment, I've got that on a different branch to play with messages.

That could well be a firmware issue then :)

I think you're right, and I think it's here: https://github.com/espruino/Espruino/blob/5a99fbdafedf5b8a551ac53f2370c76f63be9523/libs/graphics/lcd_memlcd.c#L308-L309 I believe (though could be wrong) that's it's converting the int position that we give it to an unsigned number, so it's not drawing in the correct place. Does that sound likely?

The animation is pretty cool, I think it would look better if it weren't linear, so here's a modification of this which uses a quadratic.
// widhide.boot.js

Bangle.widgetBuffer = Graphics.createArrayBuffer(g.getWidth(), 24, 8, {msb: true});
Bangle.widgetBuffer.shown = false;
Bangle.widgetBuffer.offset = -24;

Bangle.loadWidgets = (o => () => {
//  console.log('loadWidgets');
  o();
  if (Bangle.CLOCK) {
    Bangle.appRect = {
      // apps can use the complete screen now
      x: 0, y: 0,
      w: g.getWidth(), h: g.getHeight(),
      x2: g.getWidth()-1, y2: g.getHeight()-1,
    };
    Object.keys(WIDGETS).forEach(wi=>{
      var w = WIDGETS[wi];
      w.olddraw = w.draw;
      w.draw = function(){
        if (Bangle.widgetBuffer.shown) {
          let _g = g;
          g = Bangle.widgetBuffer;
          this.olddraw(this);
          g = _g;
          Bangle.setLCDOverlay(Bangle.widgetBuffer, 0, Bangle.widgetBuffer.offset);
        }
      };
    });
  }
})(Bangle.loadWidgets);

Bangle.drawWidgets = (o => () => {
  if (!Bangle.CLOCK) return o();
//  console.log('drawWidgets');
  if (Bangle.widgetBuffer.shown) {
    Bangle.widgetBuffer.clear(1);
    let _g = g;
    g = Bangle.widgetBuffer;
    o();
    g = _g;
    Bangle.setLCDOverlay(Bangle.widgetBuffer, 0, Bangle.widgetBuffer.offset);
  }
})(Bangle.drawWidgets);

Bangle.on("swipe", (_, d) => {
  if (!Bangle.CLOCK || !d) return; // not a clock, or horizontal swipe
  if (!Bangle.widgetBuffer) Bangle.drawWidgets();

  if (d>0 & !Bangle.widgetBuffer.shown) { // show widgets
    if (typeof WIDGETS != 'object') Bangle.loadWidgets();
    Bangle.widgetBuffer.shown = true;
    Bangle.widgetBuffer.offset = -24;
    Bangle.drawWidgets();
  } else if (d<0 & Bangle.widgetBuffer.shown){ // hide widgets
    Bangle.widgetBuffer.shown = false;
    Bangle.widgetBuffer.offset = 0;
  } else {
    return;
  }
  function anim() {
    Bangle.widgetBuffer.offset += d;
    Bangle.widgetBuffer.rOffset = Math.pow(Bangle.widgetBuffer.offset / Math.sqrt(24) + Math.sqrt(24), 2) - 24;
    Bangle.setLCDOverlay(Bangle.widgetBuffer, 0, Bangle.widgetBuffer.rOffset);
    console.log(`${ Bangle.widgetBuffer.offset} -> ${Bangle.widgetBuffer.rOffset}`);
    if (Bangle.widgetBuffer.offset >= 0 || Bangle.widgetBuffer.offset <= -24) {
      clearTimeout(animTimeout);
      return;
    }
    animTimeout = setTimeout(anim, 1);
  }
  var animTimeout = setTimeout(anim, 1);
});

This runs a formula on the offset, as if offset is x, but I think maybe a formula thing could be added to offset to maybe make it faster and neater?

I've just been experimenting with making use of require("widget_utils").swipeOn(); but I'm hitting problems and wondered if they were just due to this feature being a work in progress, or if I should open an issue.
I initially thought it was my code but it looks like the MacWatch2 app does the same thing: when I first try to swipe down the widgets I get a blank bar (no widgets displayed at all), but now (not sure if it's just a timing thing, or because the screen locked/unlocked, or something else) I do see widgets when swiping but both the top and bottom widgets appear at the top with the top widgets drawn on top of the bottom widgets! I'm going to give up on the swipe feature for now but it seems like it would be really useful when it's working.

Interesting - thanks! I was pretty sure this feature works ok - maybe you could file an issue...
But please ensure you list what's installed... It works here with the default widgets so maybe it's an issue with the bottom widget bar?
It could even be because of a broken widget....

Ah, thanks, good point, it was with my widget so that could definitely be broken. I'll investigate more...

I tried with a different bottom widget (the bottom digital clock widget) and didn't see the top and bottom widgets shown on top of each other, which is good, so I guess I'm doing something wrong in the medical alert widget
https://github.com/espruino/BangleApps/tree/master/apps/widmeda
The bottom clock widget didn't show up at all though- is that expected? I like the hideable widget bar idea a lot but I'm also keen to keep the medical alert widget visible on the clock screen. I was wondering if it would be possible to use a system setting to control widget hiding (top/bottom widgets or both on clock/app screens or both) rather than leaving it to apps to code explicitly. Is that technically possible?
I've opened #2474 for the odd blank bar issue - it's just a bit unexpected rather than a big problem.

Ok, thanks - lets move discussion to https://github.com/espruino/BangleApps/issues/2474 then...

Closing as completed - see #2474 / widget_utils


textDecoration only supports textDecorationLine

Hi @giraud
Currently textDecoration (https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration) supports only textDecorationLine (https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration)
I'm not sure how to map a shorthand property that has been used as a single property, and the cleanest solution is to break the textDecoration and bump a version. WDYT?

On vacation until end of august

right, this is totally incorrect. I don't see how we can improve the situation without a breaking change.


Upgrade wasmd to v0.40.0-rc.0 and fix build issues

Work in progress PR: https://github.com/metacraft-labs/nix-blockchain-development/pull/45

Fixed in #45.


Will it work with this computer?

https://www.bestbuy.com/site/acer-nitro-5-15-6-laptop-intel-core-i5-8gb-memory-nvidia-geforce-gtx-1050-ti-256gb-solid-state-drive-black/6204553.p?skuId=6204553

If your computer is VR compatible it will work

Do all games work??

Yes all games work. The issue is that a lot are not playable with one controller and no position tracking

My pc is less powerfull, gtx 660 amd fx 8350, far from vr ready and i can play subnautica and skyrim (limited modding but still beautiful )quite well.  That of course hurts immersion and will get you motion sick easier. Nevertheless i played skyrim and sunnautica for hours and i am still having tons of fun, far more then any flat games. Ethernet adapter + ethernet cable + 300mbit boosts image quality immensly, no artifacts no packetloss


Enhance the calculation of link quality metrics (#175)

This commit adds a new class LinkQualityInfo which stores all relevant information about quality of a link, including average received signal strength (RSS), link margin, and link quality value. The RSS average is obtained using an adaptive exponential moving average filter.
The Neighbor class now includes an instance of LinkQualityInfo. The RSS average is updated from mac.cpp whenever a valid/verified packet is received from the corresponding neighbor. The  mesh_forwarder, mle_router, and mle modules are modified to use the new methods from the newly added class.
This change addresses issue #175.

Thanks for working on this - this is great.  See my inline comments.
Also, I know OpenThread is light on unit testing in general, but @pvanhorn started a new precedent.  Can we add some unit tests for LinkQualityInfo?

In the new commit c6eb92d addressed the PR suggestions.
Also added a unit-test to test/verify the newly added LinkQualityInfo class (the test check the class API, averaging algorithm, link quality calculation, ...).

LGTM 👍


refractor refractor schema::get_predicate_column_ptr

Proposed changes
Issue Number: close #xxx
Problem summary
remove function Schema::get_predicate_column_nullable_ptr
and merge nullable logic into schema::get_predicate_column_ptr
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[x] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[x] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[x] No Need

Does it need to update dependencies:

[ ] Yes
[x] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[x] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 35.27 seconds
load time: 496 seconds
storage size:<PHONE_NUMBER>7 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230118074748_clickbench_pr_82958.html


feat(protocol-designer): Add profile step number and delete tooltip

overview
closes #5515 by adding numbering and tooltip to profile steps

changelog

feat(protocol-designer): Add profile step number and delete tooltip

review requests

[ ] Numbering is correct
[ ] Delete button Tooltip matches design

note: I know we will have to revisit numbering once cycles are a thing
risk assessment
Low. PD tooltip

Oof this is our bad, we should have coordinated with you more.
#5809 conflicts with this, we actually moved around some stuff and ended up deleting ProfileStepRows.js
On the bright side, the css should be the same and it should be a relatively simple patch.
Sorry though, we def stomped on ya here @Kadee80

No worries, I'll hang back and wait for the other PR to land and go from there


toascii - Move Function Call Ordinals Into Attributes

We label each function call node's key with a number. It Would be better to have the number be stored under the node as a regular attribute.
From:
"[34]vkEnumeratePhysicalDevices": {
    "return": "VK_SUCCESS",
    "instance": "0x1",
    "[out]pPhysicalDeviceCount": 2,
    "[out]pPhysicalDevices": [
        "0x3",
        "0x4"
    ]
},
"[35]vkGetPhysicalDeviceProperties": {
    "physicalDevice": "0x3",
...

To:
"vkEnumeratePhysicalDevices": {
    "sequence": 34,
    "return": "VK_SUCCESS",
    "instance": "0x1",
    "[out]pPhysicalDeviceCount": 2,
    "[out]pPhysicalDevices": [
        "0x3",
        "0x4"
    ]
},
"vkGetPhysicalDeviceProperties": {
    "sequence": 35,
    "physicalDevice": "0x3",
...

Where the name "sequence" is open to better suggestions.
Of course, it is confusing to do this if the function has an argument of the same name so the schema might need to be adjusted further, to e.g.:
"vkGetPhysicalDeviceProperties": {
    "sequence": 35,
    "args": {
        "physicalDevice": "0x3",
         ...
    },
    ...

100% agreed.

This was fixed by PR 811: https://github.com/LunarG/gfxreconstruct/pull/811


Allow building specific contracts

Allow building specific contracts by providing paths or contract names. Contracts can be built without declaring them in the configuration file.
Closes #1095

Closing. This meant be to be quick PR. I don't want to waste any more time figuring out why tests fail on CI only nor continue discussions. I might copy-paste this code in a different PR to figure out what breaks the CI.


Remove patch versions from go directives

This helps older versions of go parse these directives
Specifically, our build process for the default trust package locally depends on trust-manager@main, but older releases (the release-0.6 branch) use go 1.20 and won't be able to parse them.
This tangle isn't ideal, but for future versions (i.e. when we can retire the release-0.6 branch and all supported versions use go 1.21) we can move past this and add the patch releases to our go directives again.
Motivation: This test failure for the release-0.6 branch. Specifically:

#15 20.52 go: github.com/cert-manager/trust-manager/cmd/validate-trust-package@main (in github.com/cert-manager/trust-manager@v0.7.0-alpha.2.0.20231024102130-94e8d110291e): go.mod:3: invalid go version '1.21.3': must match format 1.23

/approve
/lgtm


fix null dereferences if TERM is invalid

Hi, this fixes segv on invalid $TERM. Not sure if it's better to have a single caps_initialized for tb_deinit or make it a member in the global struct.

Hi @git-bruh thanks for the PRs. I wasn't subscribed to all activity on this repo so I missed them. Sorry about that. I will check these out shortly.

Thanks! Merged in 11d2080242619ebca99889b9b846b99cbdeef79f and added test case in f33ba01cad58ef8d76e55bf5035c7d2067bca31b.


WIP: Drawer and ModalService

@EisenbergEffect @bigopon @serifine
Here is a draft for the ux-drawer component and a ModalService.
At the moment I have focused the work towards a drawer component, but to be honest it works also as dialog. Basically the drawer can be set at position:

left, right, bottom and top => looks like a drawer
center => looks like a dialog

The ModalService is called as such because the intention is to use the same service across different components that would need to act as modal. This helps with keeping track of zIndex and properly layer components if several modals must be opened in a row. It is currently working only for drawers, but we can add support for other components as they come.
Drawers can be used either inline or with the ModalService. If they are used inline they don't need the service at all. I've set up a few examples in the dev app.
Inline use
<!-- Check out examples and code source for more -->

<ux-drawer if.bind="anyVarFromTheHostingVM">
  <!-- any content here that will be included in the slot -->
  <!-- I recommend using a ux-card as they fit well the purpose of this kind of surface -->
  <!-- BTW: I've set up a few CSS for when cards are used as drawer/dialog markup -->
</ux-drawer>

Service use
import { ModalService } from '@aurelia-ux/drawer';
import { inject } from 'aurelia-framework';
import { Hello } from './hello';

@inject(ModalService)
export class App {
  constructor(private modalService: ModalService) {}

  public openDrawer() {
    const drawer = this.modalService.open({viewModel: Hello, position: 'bottom', theme: {/*... */}});
    drawer.whenClosed().then((result) => {
      if (!result.wasCancelled) {
        console.log('output', result.output);
      }
    })
  }
}

For the ModalService I've tried to stay as close as possible to the current DialogService and DialogController api from ux-dialog plugin (except that the service handles both creating the drawer with open() and the cancel() and ok() apis from the included VM.
The .open() api accepts a viewModel, view or both (+ some more options). It returns a UxDrawer instance with an additional whenClosed() promise similar to current DialogService.
Known limitations
When using the ModalService, there are two limitations compared to the ux-dialog

missing canActivate() lifecycle hook. Because I rely on <compose> to build the VM/V, then I can't can canActivate from the service and then compose do not do that either. If this would be an important feature then we should not rely on <compose> and create the composition from the service itself
again, due to the <compose> usage, the included view cannot have any classes, attributes or event listener on the <template> tag.

This is a first draft that I want to publish here for early feedbacks.
I've setup my current showcase link as a demo of this PR: https://ux.mintello.com
Here is a quick gif to see the result:
Various Positions

Mobile

Go Crazy

Thanks @ben-girardet This is looking nice. I admit to having a lot of fun playing with the demo :)
Unless I missed it, I think we need to add some stuff around accessibility. That's the only thing that jumped out at me in the code. When playing with the demo, I did see some odd behavior when opening overlapping drawers. I didn't dig in to see what was going on though.

Thanks @EisenbergEffect  for your feedbacks.
Accessibility: did you mean keyboard support or did you mean something else ? I pushed a commit with keyboard support now.
Odd behavior: you're right, I've also discovered that if we open one or several "crazy" drawer and then close them... and after that we open an inline drawer => then there will be as many inline drawer elements attached to DOM than we previously opened "crazy" drawers.
I don't exactly know what is going on here. I understand that the issue comes because the crazy drawer attaches the same module again (containing the inline drawer) and it probably means that the inline drawer is somehow not properly detached when the module go away.
Looking forward to get more feedbacks. Especially about these questions:

The way I move the attached element to its host (default to body)
The way the service creates the drawer, with the use of <compose>, a temporary bindingContext for passing the options as bindables and enhance()

@ben-girardet I actually like the way you used compose and enhance together. Very clever and the code seems much cleaner than I remember some of the old dialog code being (though I haven't looked at that in a while).
In terms of accessibility, yes keyboard support, but also there may be some aria attributes we need to add to the backdrop and modal containers.

Updated with component to make it work even more like current ux-dialog plugin.

Added a restoreFocus bindable method to bring back focus to the main view when modal closes. Automatically defaults to lastActiveElement before opening the modal.
Added canDeactivate, detached and deactivate lifecycle support for VM passed on to the drawer/dialog service. Identical API than current ux-dialog plugin
Fixes call to detached on ux-drawer when closing service handled drawer
Added attach-focus-drawer attribute

I've added this paragraph to the PR description:

Known limitations
When using the ModalService, there are two limitations compared to the ux-dialog

missing canActivate() lifecycle hook. Because I rely on <compose> to build the VM/V, then I can't can canActivate from the service and then compose do not do that either. If this would be an important feature then we should not rely on <compose> and create the composition from the service itself
again, due to the <compose> usage, the included view cannot have any classes, attributes or event listener on the <template> tag.

Quick note to say that I think it is valuable to explore how to call the canActivate hook.
It is an important piece in the VM lifecycle. It is the only way to give users a chance to validate if the VM receives the right model to create and handle the modal.

Thanks a lot @bigopon for your first round review.
I left a few comments. I am particularly concerned about the discussion on detached(). From my tests there is something not going quite right when detaching Drawers created by the ModalService.
For the record:
This is the code that insert the drawer:
options.host.appendChild(element);
    let childView = this.templatingEngine.enhance({ element: element, bindingContext: bindingContext });

Now the question is: what's the right way to do the exact opposite (with full respect of Aurelia Lifecycle).
My current approach (could well be wrong):
const controllers = (childView as any).controllers as Controller[];
const drawer: UxDrawer =  controllers[0].viewModel as UxDrawer;

drawer.detached();
const parent = drawer.element.parentNode;
if (!parent) {
  return;
}
parent.removeChild(drawer.element);

@EisenbergEffect  @bigopon
I think I have some good news. I have refactored a little the service in order to add the canActivate() method in the attached VM lifecycle (if any). To be honest I took quite a few parts from the dialog plugin codebase to do so.
This is very useful as a dialog or drawer might not be able to work properly if it doesn't receive the proper params in the activate() method. Therefore being able to check this earlier with the standard Aurelia lifecycle method canActivate() seems a non-negotiable.
The good news that comes with it is that it fixes the previous bug discovered here. So now it seems that anything attached with the service is properly detached and do not interact negatively anymore.
There is however a bad news. And I'm seeking help here. If you try the demo now and open a crazy drawer (meaning that it opens the current view) you will discover that the chips choices don't work anymore. This is very weird as everything else works fine (checkbox, buttons, ....). I wonder where this could come from. Could it be that the custom attributes (ux-choice-container) are not processed correctly with this new composition method ? Any ideas ?
As always: I'm open for any feedbacks

I did a quick inspection of the DOM and the ux-choice attribute is still present, but with wildly different values, so it appears that something is definitely wrong with that attribute. I wouldn't expect to see it in the DOM at all, since these attributes are removed during compilation (unless I'm getting versions confused in my head).

I followed on your findings @EisenbergEffect
The ux-choice-container and ux-choice attributes are still present in the DOM for both the working and non-working attributes. I can't tell if they are supposed to stay in the DOM or not for au1 ?
However there is something wrong in the attributes lifecycle when they are part of the dynamic composition. I could identify that for the working attributes (part of the main page) the attached and detached methods are called. They are not called when the attributes are part of the dynamic composition.
I'm thinking the problem can come from how I set up the compositionContext, especially regarding either the container, childContainer or bindingContext value. At the moment as a container I pass the container value of the childView created by the previous enhance on the drawer. Not sure if this is correct ?
  let childView = this.templatingEngine.enhance({ element: element, bindingContext: bindingContext });

    let slot: ViewSlot;
    const controllers = (childView as any).controllers as Controller[];
    const drawer: UxDrawer =  controllers[0].viewModel as UxDrawer;
    try {
      const view: any = controllers[0].view;
      slot = new ViewSlot(view.slots['__au-default-slot-key__'].anchor, false);
    } catch (_error) {
      this.cancelOpening(drawer);
      throw 'Missing slot in drawer';
    }

    let compositionContext = this.createCompositionContext(childView.container as any, element, bindingContext, {
      viewModel: options.viewModel,
      view: options.view,
      model: options.model
    }, slot);

  private createCompositionContext(
    container: any,
    host: Element,
    bindingContext: ModalBindingContext,
    settings: {model?: any, view?: any, viewModel?: any},
    slot? : ViewSlot
    ): CompositionContext {
    return {
      container,
      bindingContext: settings.viewModel ? null : bindingContext,
      viewResources: null as any,
      model: settings.model,
      view: settings.view,
      viewModel: settings.viewModel,
      viewSlot: slot || new ViewSlot(host, true),
      host
    };
  }

@EisenbergEffect @bigopon
I would greatly appreciate some help to find out what's wrong with the composition in my code. In order to help debugging I added some console.log that you can see in the demo.
Basically I console.log each attached/detached of ux-choice-attribute with an incremental index on each to see when they are properly attaching/detaching or not. Going in and out of the drawer page works fine, also opening an inline drawer, but not with the service using the composition.
I've logged a few steps in the composition process as well.
If you have any ideas for fixing this that would be sooo awesome!!

@bigopon has more recent experience working inside the templating engine and composition pies. @bigopon Any ideas what might be going on here?

@ben-girardet from your demo, it seems attached hasn't been called for the view model of ux-choice-container:

hence why click events are not registered. Another thing I noted during debugging this issue is that in our components, we are using click.delegate. I think for plugin, we should be using click.trigger instead, as any code above the component calling stopPropagation may potentially affect our handler. Also, in terms of encapsulation, .trigger feels better

Thanks @bigopon for your valuable feedbacks. Always good to learn from you!
The composition still fails to properly load the custom attributes :-(
I have created a Dumber Gist and a small git repro for this issue... Maybe easier to spot what's wrong  from one of them..

@ben-girardet thanks for the gist, i'll debug it

@ben-girardet The behavior you saw is because .compose on composition engine only bind and add a view to a view slot, but does not try to call attached() on the controller created. The job of calling attached method is delegated to the view slot. So you only need to call attached() for our view slot and any views added to it will be invoking attached too.
Here's and example: https://gist.dumber.app/?gist=3f3d935b7bc872b8eb59651f8c211620&open=src%2Fapp.ts

Thank you so much @bigopon
This is really helping me!! Looking forward to move forward with this PR.

@EisenbergEffect @bigopon
Here is an important update on the drawer component.

I've renamed the component modal as it can be used for drawers, but also for dialogs or even menu (new, see below)
I've added more of the options found in the current aurelia-dialog plugin such as a lock boolean (when set to false, the modal let the user use the interface in the background)
It is also possible to set overlayDismiss: boolean to decide if the overlay should dismiss the modal or not
and outsideDismiss: boolean to decide if an unlocked modal should be closed when a click is detected outside of itself
the modal offers now an openingCallback() bindable/config that allow the developer to set interact with the modal elements when. This is similar to the position() callback of the aurelia-dialog plugin

New: modal as contextual menu
My vision when starting this drawer component was to create something that works for all kind of situations. I've used the contextual menu situation as a proof of concept. Using the new openingCallback() and the position = 'absolute' in the modal config it was pretty easy to come up with a function to position the modal next to an anchor.
I've now added a positionModalWithAnchor() method in the modal service that do the calculation. Here is the code to open a ViewModel as a menu:
this.modalService.open({
  viewModel: Hello,
  position: 'absolute',
  openingCallback: (contentWrapperElement: HTMLElement, _overlayElement: HTMLElement) => {
    this.modalService.positionModalWithAnchor(
      anchorElement,
      contentWrapperElement,
      {preferedPosition: 'bottom'});
  },
});

I would love to hear what you think about all this. Hopefully this is going in a direction that makes sense to you as much as for me :-/
Demo
As always: https://ux.mintello.com/#/modal (scroll down for the menu demo)

@ben-girardet I haven't reviewed the code, and while playing with the demo, noticed that after opening drawer, menu positioning stops working

@bigopon could you give more details on what doesn't work.
Or could it be that when you tried the menu positioning you didn't have the anchors on the screen and it seemed that the positioning didn't work ?

@bigopon wondering if you still experience the positioning issue ?

I'm getting this issue:

The first modal trigger button couldn't locate the anchor correctly after open the drawer

Hum... are you using Safari @bigopon ? There seem to be something bugging in Safari desktop...

The issue that you experience @bigopon comes from a reference issue with the view-model of the drawer. What is happening is

the "crazy" drawer is set to open the view-model of the drawer page, meaning that it kind of open its own parent (inception)
when doing so, it seems that the composition do not create a new instance of the ViewModel but actually uses the already created and used view-model. If I get it well, the view-model instance is now shared between the modal demo page and the modal drawer opened from the "crazy" button
because anchors are "ref" to the view, they are updated when opening the crazy drawer
when closing the drawer, these "ref" are lost and positioning doesn't work anymore

Now comes my questions:

is this normal that a view-model would be shared for several views ? That should not happen right ?
which would mean that there is something wrong with the composition ? Maybe with the ensureViewModel(). Could it be that we are missing a ChildContainer or something like this ?

@bigopon nothing wrong with composition, only something wrong with my code :-/
Fixed: https://github.com/aurelia/ux/pull/246/commits/0991be48cb3a05e663ec45f2eb19a3a6ca126159
Do you have any comments regarding the current state of this PR ?
If none, this is my plan:

make the positioning method better (to include more cases and calculations, like top-left, top-center, top-right)
create utility to quickly set a modal as either drawer, dialog or menu
I want to try to create only components like <ux-drawer>, <ux-dialog> and <ux-menu> that are child component of <ux-modal>

@bigopon @EisenbergEffect
I've worked on the positioning service. I got inspired by the popper library and in order to avoid dependency I've built something from scratch. I turns out working pretty well. I've already included some uses cases such as:

position anywhere (12 possibilities)
offset with the anchor
margin with the constraint container
flip placement if overflow with constraint container
adjust secondary positioning to stay in contraint container if possible
any constraint container can be chosen (parentElement, other DIV, screen)
return an instance that can be updated to follow the anchor position (test drag in demo)

It can surely be optimized. But first I wanted to try and have a proof of concept. Open for feedbacks.
Commit: https://github.com/aurelia/ux/pull/246/commits/1b65e4d4e94ad7a2dd64a5a8aed21c5ca662607d
Demo: https://ux.mintello.com/#/anchor

@ben-girardet Awesome! Thanks for continuing to keep this moving ahead. I seem to have an issue accessing the demo link. Can you confirm that it's correct and working?

@ben-girardet thanks, very nice work. For review purposes, can you help remove all of the dist files? We normally leave it to build process during the release

@EisenbergEffect ouch sorry server is down. will fix asap. might take another hour :-/
@bigopon sure, my mistake, normally I leave them out of commits. I've removed them

Quick update: I have now finished the ground work for the positioning service and I can use it for positioning modals (not just demo elements).
So I've updated the demo which now use the positioning service on the demo page. Happy to see how it turns out.
https://ux.mintello.com/#/modal
Happy easter everyone !

@ben-girardet very nice. Select modal can also be used as a test subject. And in long term, we would want it that way too

@bigopon that would be fantastic! A good real world test!
Would you be willing to team up with me for this? I feel a little lost in the way the select is architectured.
In order to use the modal the best would be to have a separate VM/V for the options list that should be in the modal. That’s where I need help.
What would be the steps to make that happen?
The only requirement of the VM modal is to parse the params in the activate hook to generate its content. So if we can pass on an array of options we should be able to build the view.
Also the benefit of using a VM/V for this modal is that we could make it configurable so that users could even change the look. Maybe...

@ben-girardet the general theme of <ux-select/> is to mimic native <select/>, as close, as possible. We will be providing a 2nd component, probably named something close to a "combobox" that has:

dropdown - select
text input for filtering
custom template for option item
etc...

For the <ux-select/> itself, it's mainly this line https://github.com/aurelia/ux/blob/fb4118a38b04c99fe2a74678162d77f1752fbd4f/packages/select/src/ux-select.html#L30 at the moment. You can see that wrapper will be set displayed fixed and show/hide accordingly, with some animation. But probably, that's not gonna work properly inside a fixed container. About the container of the option list, there are 2 <div/>s, 1 is to position the list relative to anchor, and to show/hide. Another one, inside that, is to take care of the animation.
I'm not sure about how we want to deal with it eventually: (1) only positioning service - extracted & separated from modal, or (2) use the entire modal. For (2), I'd imagine that it'd be a big change in the code, and I'm not sure yet, as atm, we walk the DOM to retrieve stuff I believe. Maybe need to use container to inject stuff now

Thanks for your explanation. I also hesitate between 1) and 2).

Using only positioning should be pretty easy. As we don’t have « modal » stuff with it we need to handle the « click outside » to dismiss the wrapper. I think it’s already done btw.

Using modal we could provide still a few options to the user such as « lock » or a full screen mode in mobile. As the modal also work inline we can use it to replace the actual wrapper. It would be a bit more work though because then we need to rewrite the open/close/dismiss things.

I've given a quick try for the option 1) It's working so so at the moment.
I feel like I can continue with using only the positioning service but I might need to use the same "trick" than for the modal and move the wrapper as child of the <body> before positioning.
This tend to avoid problems if the select is placed inside a fixed container and has the benefit to not alter the width and height of the ux-select element itself (we need correct width and height for the ux-select as it acts as an anchor).
If you think this is too much, I can also wrap the select part inside a div and then use this div as anchor to have correct width and height. The benefit here is that I don't need to move the <slot> container as a child of body.
Option 2) (using modal) would be cool as it already resolves all these issues and create a consistent feel in the UX lib. But here I face an issue with the <slot>.
If I would use the modal component inline, the main idea is to use it with an if.bind for opening and closing. It's pretty neat because then it doesn't polute the DOM with elements that are not required when modal is closed. But then the <slot> doesn't work because it cannot be placed inside a if.bind.
Did you already faced similar situations with <slot> used behind a if.bind ? Do you have some ideas how to fix this ?
Personally I've already tried something in a component where I placed the <slot> in a fake container (hidden). Then I needed to watch this container and ref all its children so that I could move then at the right place when the if.bind becomes true.
But I feel that this solution is not very stable and would prefer to have something more robust if we go in this direction.

@bigopon I've sticked to the modal positioning service and I'm happy with the result. Took me a bit of time to get my head around this select but in facts it's not so complicated...
Please have a look a the commit and the demo and tell me what you think.
Note: I've disabled the collapse on wheel now that I can easily update the position of the modal on scroll. It gives a nice effect when you scroll and don't have enough space in the bottom => then the list moves towards the top of the select.

@ben-girardet that looks nice, thanks for doing that. I noticed one difference is that the list modal is positioned at the bottom of the select box, while with material design, I believe it's should be at the start? Also, there's one detail it doesn't have yet: the modal should be opened with selected option align well on the select box. If this feels like off topic of this PR too much, we can defer the select improvement until later. As we need more feature in positioning like offset, maybe?

We can change the placement by setting top-start instead of bottom-start when setting the positioning instance.
As for the precise positioning could you picture what you mean? The positioning service already have the offset setting ready so it might me a matter of setting it correctly.

Do you refer to https://material.io/components/menus/ for the specs on select ?
What I understand is that it should have a 0 offset so that the list stick to the select.
Regarding positioning it all depends on screen real estate around the anchor. We have the flipping feature that does a pretty* good job. I didn't find something saying that it should defaults to top. Seems that defaulting to bottom is fine, as long as there is enough space.
* The difference I noted from their examples is that when the modal is displayed on top of the select, it should cover the select instead of being placed right on top. However I don't quite like this behavior as it mask some context of the field. But I'm open to add a setting in the positioning service. That would look like setting a flippingStrategy config to tell if the flip must cover the anchor or not

@ben-girardet thanks for the reference link. From there:

It seems we can start with the exposed menu style, which is more similar to native select. If folks insists, we can go with dropdown menu style. I originally went with this, but I'm not entirely sure about it being the default behavior

For

Do you refer to https://material.io/components/menus/ for the specs on select ?

Yes, I originally based the implementation on some other component libs, thinking that is the default, but clearly not necessary.

@bigopon the way I read this is:

Dropdown when opened by an icon or button (or some actions)
Exposed when linked to a field with the value displayed in it

So for the select we should use exposed scenario. The dropdown will refer to the menu component (I hope we could continue the work you started).

@ben-girardet yes let's go with that. Dropdown style for the <ux-menu/> sounds valid to me as well 👍

I've updated the positioning service with the following
Missing Space Strategy

flip: If not enough space in the desired placement, use the flipped side (default)
ignore: don't care about space, place where desired, even if it overflows the constraint element
over: strict respect of the constraint element, event if the positioned element must go over its anchor
hide: hide the element if not enough space (via a customizable class applied to the element)

Note: this strategy is currently only applied to the main placement. It means if we request a top-start placement, it will be applied to the top but not (yet) the start part.
Demo

support touch devices (even though it doesn't display super well on small screens)

https://ux.mintello.com/#/anchor

I've implemented the ignore strategy for secondary placement. The other ones are not relevant in my opinion.

I ping @EisenbergEffect and @bigopon here because I believe the positioning service is ready for review. I have some questions below, but first, in a nutshell, here is what this service does:

Creates a positioning instance from an anchor and an element
Will position the element close to the anchor according to the chosen options
The element will be correctly positioned on first instance creation and won't be moved on scroll or resize, this is left up to the developer(*)
The instance has a public update() api that re-positioned the element according to the options
Each option is exposed as public on the instance so that developer can change it at any time

(*) The reasons why I chose (for now) not to handle scroll or resize is that I prefer to leave the positioning focused on what it's supposed to achieve. Listening to such events and update automatically could be nice but in order to cover each edge case it could end up being much work.
Positioning Options

placement?: UxModalPlacement: the preferred placement for the element, see below (default: auto)
offsetX?: number: horizontal offset from the anchor in pixels (default: 5)
offsetY?: number: vertical offset from the anchor in pixels (default: 5)
constraintElement?: HTMLElement | Window;: which element should limit the positioning of the element (default: element.parentElement)
constraintMarginX?: number: horizontal margin in pixels towards the constraint before we assume there is not enough space  (default: 5)
constraintMarginY?: number: vertical margin in pixels towards the constraint before we assume there is not enough space  (default: 5)
missingSpaceStrategy?: 'flip' | 'ignore' | 'hide' | 'over': strategy to handle what happen when there is not enough space between the anchor and the constraint element (default: flip)
hiddenClass?: string: CSS class added to the element when it should be hidden (default: ux-positioning--hidden)

UxModalPlacement

auto
auto-start
auto-end
left
left-start
left-end
right
right-start
right-end
top
top-start
top-end
bottom
bottom-start
bottom-end

A few questions for the review

Package: As this service is autonomous, I don't think it should stay in the modal package. I am tempted to create a positioning package inside the learn mono-repo and have this service stand alone. The benefit is that this service could be used without any of the rest of the library if this is what someone wants. Also, it will be useful in other packages, such as the select component and the rest of the modal component is not required.
Naming: I've noticed that Aurelia doesn't have much classes called ....Service but rather ...Engine. Maybe this would be better called UxPositioningEngine
Factory: In order to work well with the DI (because I need to inject TaskQueue), I've created a single class that have a getInstance() public method to create an instance correctly linked to the DI. But I believe there are better patterns as Factory for this kind of things. Do you have any advice to make this better ?

For naming, probably @EisenbergEffect can tell, I'm leaning towards engine as well. We do have DialogService, and this is gonna probably be ModalService as well, but PositioningEngine sounds closer to StyleEngine
For packaging, I'm ok with having a separate package for it, though it's not my call 😁 @EisenbergEffect . Maybe we can invite some people to try it out in their non-Aurelia projects and help spot bugs.
What is the last point about?

Pulling it out into its own package seems fine. Not sure about "engine" or "service" actually. You could just call it "ElementPositioner".

Wow thanks for this great review ! I'll look in detail at each comments.

Thanks again @bigopon for all your valuable comments. I've replied / fixed them.
I was not clear, but the current drawer package is out of date as everything is currently in the modal package. But don't worry, I have applied all your comments directly to the modal package.
From now on, in order to bring a little more clarity on this PR I suggest to create two distinct PRs and close this one as WIP without merging.
1. Positioning PR
With a new positioning package containing only the positioning service.
I tend to prefer the PositioningService or PositioningEngine names which seem to follow a little more the other naming in Aurelia codebase. But of course I leave the last call to @EisenbergEffect
2. Modal PR
With the modal package containing the current implementation of the component and service. I'm planning to finish up a few more things before final review.
Would you agree with this course of action ? If so we could probably merge the positioning PR pretty soon.

@ben-girardet this is looking good, but your new plan sounds better to me. Scrolling perf got degrade d a bit in this big PR :D

@bigopon
Positioning PR ready here: https://github.com/aurelia/ux/pull/254
If it's merged rapidly I will wait on the merge before to set the new Modal PR (to avoid copying the positioning package in the modal branch if possible). If we need time before merge I will copy anyway and work on the other PR.

@bigopon thanks for the merge of #254
Modal PR is now available here: #255
I will close this PR as now it is replaced by the two mentioned above.


input fieds - new letters insert left

How to recreate:

open the setup menu

click on +

click on any imput field

write a word. t.ex. abcde

You see in input field: edcba

I also can delete only 3 letters att the same time with "<-" then i have to click into the imput field again and delete the next


How do I set the cache option for OS disks?

Looks like the OS disk is created with read-only cache. Why not read/write and how can a VMSS be created with read/write OS disk cache?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 0408c294-207a-2b72-7b93-e09121602b75
Version Independent ID: 852cb67b-70c6-b811-3b0a-5d5b84b8a911
Content: az vmss
Content Source: src/azure-cli/azure/cli/command_modules/vm/_help.py
Service: virtual-machine-scale-sets
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

HI @qwordy could you pls have a look?

--os-disk-caching

Storage caching type for the VM OS disk. Default: ReadWrite.
accepted values: None, ReadOnly, ReadWrite

Looks like the default value is ReadWrite.
I create a vmss using the default configuration.
I get
"osDisk": {
          "caching": "ReadWrite",
          "createOption": "FromImage",
          "diskSizeGB": 30,
          "managedDisk": {
            "storageAccountType": "Premium_LRS"
          }
        }

Would you share your command?

Hi @letmaik ?

@letmaik

Sorry, I missed this somehow. I think you're right. Thanks for pointing me to the --os-disk-caching flag.


How to play videos on default

I like this theme so much!
i'd like to make so change for myself.
for me i prefer to have videos playing on default,but i cant find where to change

Which theme are you do you mean? For DH_Dawn, the video player is controlled by the Extra Metadata extension. I believe you can also change the autoplay behavior in the settings for that extension.


semicolon rule false positives with class members with arrow functions

Bug Report

TSLint version: 4.0.2
TypeScript version: 2.1.4
Running TSLint via: cli and grunt-tslint

TypeScript code being linted
/**
 */
export class Rule {

    public FAILURE_STRING_FACTORY = () => {
        return;
    };
}

with tslint.json configuration:
    "semicolon": [true],

Actual behavior
unnecessary semicolon is reported.
Expected behavior
the semicolon after the initializer expression is not unnecessary if you are requiring semi-colons.

see https://github.com/palantir/tslint/issues/1476. This was intentional, and you can get the old behavior with the option ignore-bound-class-methods


ALLUXIO-1588, Add test coverage for WorkerClientHeartbeatExecutor

added test described in ALLUXIO-1588

Can one of the admins verify this patch?


Apps out of ocaml packages

Motivation for this change
this separates ocaml libraries (in ocamlPackages) from applications which happen to be written in ocaml (in all-packages.nix).
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Make sense. Can you update this?

Are there any updates on this pull request, please?


[BUG] Error click folder in Project Explorer

Describe the bug
When you try to click some foler if you don't have all the previous folders collapsed, you will open some folder form the previous main folder.
To Reproduce
Steps to reproduce the behavior:

Go to Project Explorer
Click on a main folder that have the previous main folder collapsed
See error

Expected behavior
Expand the selected folder.
Screenshots

I did a quick fix but now the folder will only open when double clicked


refactor(mocha-timeout): Configure mocha timeout in package.json

Closes #1157

Refactored test script with existing timeouts.
Updated timeout for stryker-webpack-transpiler since the test fails sometimes.

Let me know, if we need to change timeout for other packages

Thanks!


How to custom style

How to custom style ?

same question.

Latest release v0.0.6 allows for button styling: https://github.com/theevann/streamlit-audiorecorder/releases/tag/v0.0.6
The audio-recorder-visualiser is a standalone component that cannot be styled.


Notifications on new followers

It'd be handy if I can get notified whenever someone follows me. Currently the number just keeps going up without any indications who has just followed me.

You can gain followers by "joining" and "leaving" certain(or multiple) clans. The notification might take that into account to avoid spamming.

"leaving" certain(or multiple) clans

Is that even possible? IIRC leaving a clan willl not remove the allies status. You'd have to manually unfollow everyone in the previous clan, and even with that you can't manually make them unfollow you.
Also I think you can only join 1 clan at any instant.

By multiple I meant repeating the process of joining and leaving a clan for the popular clans. I might have misinterpreted your post. My reasoning was that these new followers were from the same clan and that the lack of notification might have been to prevent spamming users with "* followed you" notifications.

Apparently this feature existed for a long time, at least for the first follower. I got this notification on the staging environment while testing.
When someone follows you, you get USER started following you, follow USER back and become allies.. When you follow back, this becomes USER started following you, you are now allies..
This only works for the first user and I don't know if this is a bug or not at the moment. I'll try to fix if it's a bug, but will make sure that allies added automatically from clan doesn't trigger notifications.


Issue: Unable to share videos synced from iCloud

Hello,
I followed the setup guideline. Chat works well, I can also send image file from my app but when I select video files, they don't playing and when I try to send video files, they simply not sending, actually nothing happening except closing photo selector screen.
I tried with iOS real device.

Hello, does this behavior happen for any specific video within the photo library or is the video being selected synced from iCloud?
We weren't able to entirely reproduce the issue in our environment.

Yes, you're right. I tried it from files folder, it works well. But I try from my photo library, it doesn't work because my photo library all synced iCloud.
Before I select the same video from Files, it worked well. After my photos library, it doesn't work.
I attached not working situation's video.
https://user-images.githubusercontent.com/2773578/142983993-3f35f49f-c70c-4330-b925-02c123e795d3.MP4

Thanks for confirming. We'll investigate this issue and roll out an update with the fix.

@Rishabh-Raghunath Thanks!
When I was looking for a in-app support solution, I was very happy to see Zoho Sales IQ providing Flutter package too. But this issue stops us to continue with Zoho. I hope you can provide a fix soon.

Hello @ibrahimdevs, We have rolled out an update which fixes this issue with Release 1.0.1.
Once the package is updated, navigate to the ios directory and run the pod install command to complete the installation.
This issue is now being marked as closed. Please feel free to reopen the same if you experience an issue with sharing media synced from iCloud.
Thanks for bringing this issue to our notice.


Singe word search

FACT-Finder SDK version (see package.xml): 4.1.13
Magento edition and version: <IP_ADDRESS>
PHP version: 5.6
Expected behavior:
Actual behavior:
Steps to reproduce:

i have activated the module "Single word search", but i can't activate this module in Magento.
Is there posibility to use this module in Magento?

Can you explain in details, please? Why do you think that activation of module "Single word search" depends on this FACT-Finder Extension? Do you get any releated errors?

"Single word search" is a FACT-Finder back end preference and works automaticall.


What you see on screen is not what the app thinks it is executing

Issue Type: Bug
After several hours of using Azure Data Studio with some reasonably large stored procedure scripts, it gets confused about what SQL I am trying to execute.
What I see on screen is no longer what it is executing under the hood, like the error messages refer to older versions of the file.
For example I copy a file and start changing it, but if I execute that script then it's not seeing the changes under the hood and executes the original script.
If I close the app and reopen it, it comes good.
It doesn't have to be a large file to see the behaviour, any size file will experience it.
It happens after some time of having the app open, not straightaway.
I'll attach some images where it just happened today.
Image 1 - Bug happening, incorrect error showing when executing this script
Image 2 - After restarting app, was able to run the portion of the script just fine

This issue has been occurring for me for quite a long time, maybe 12 months. I just reopen the app.
Azure Data Studio version: azuredatastudio 1.43.0 (b790d700898b1095d83e62f0de14678a58222520, 2023-04-10T23:14:27.236Z)
OS version: Windows_NT x64 10.0.19045
Restricted Mode: No
Preview Features: Enabled

System Info

Item
Value

CPUs
11th Gen Intel(R) Core(TM) i7-11850H @ 2.50GHz (16 x 2496)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
undefined

Memory (System)
31.73GB (12.66GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (10)

Extension
Author (truncated)
Version

sql-data-inspector
ern
0.6.0

ssmskeymap
kev
1.1.0

admin-pack
Mic
0.0.2

agent
Mic
0.49.0

dacpac
Mic
1.13.0

import
Mic
1.5.4

profiler
Mic
0.12.2

schema-compare
Mic
1.18.0

sql-database-projects
Mic
1.0.1

azdata-sanddance
msr
4.0.1

(1 theme extensions excluded)

Hi @mmcaulay
Can you try the latest insiders build and let us know if that has improved the experience?

Closing as we haven't heard back on the issue, and with recent improvements this issue should be resolved.