Request builders should be more rusty

Currently the client builders are not very rust-y and they also enforce parameters at compile time. The latter is more cosmetic, but makes things less verbose. The latter leads to odd compilation errors that will likely frustrate the type of user consuming this crate (most likely an application developer).
A concrete example of making this more rusty.
Current:
cosmos_client
    .query_documents()
    .with_query(&Query::new(&query))
    .with_query_cross_partition(true)
    .with_parallelize_cross_partition_query(true)
    .execute()
    .await

Suggested:
cosmos_client
    .query_documents()
    .query_cross_partition()
    .parallelize_cross_partition_query()
    .execute(Query::new(&query))
    .await

The suggested idea sets options using their names and then the execute or finalize method would take the actual thing the request is acting on, be it a query or a document.
Also, I know there is a certain architectural purity and "coolness" by having the compiler catch missing parameters. However, in my experience using this, it just leads to really weird errors that are a bit hard to figure out, especially if you are just trying to do something simple like getting a document or a blob. I suggest that we move to runtime vs compile time checks here as they will allow us to expose more specific error messages to the developer while also simplifying the builder structs and implementations.
Please note, this is not just in the cosmos crate. This pattern exists in several places and I think it should be updated everywhere

Before I implement this, I thought I'd try it out on one of the request builders and see how it looks. I did this on the CreateCollectionBuilder which is probably the most complicated builder:
The call site
Before

After

Error message when forgetting a required field
Before
Note this is at compile time

After
This is at runtime.

Docs
Before

After

My Thoughts
I think it's clear that making these changes is worth it even if we give up a bit of compile time safety. The runtime checks will be triggered early in the dev loop and should be easy for the user to know exactly how to fix the issue (especially if we give better error messages than I did here).

Before I implement this, I thought I'd try it out on one of the request builders and see how it looks. I did this on the CreateCollectionBuilder which is probably the most complicated builder:
The call site
Before

After

Error message when forgetting a required field
Before
Note this is at compile time

After
This is at runtime.

Docs
Before

After

My Thoughts
I think it's clear that making these changes is worth it even if we give up a bit of compile time safety. The runtime checks will be triggered early in the dev loop and should be easy for the user to know exactly how to fix the issue (especially if we give better error messages than I did here).

I think we are looking for a solution for the wrong problem.
The problem here is that the types are not self-explanatory: No and Yes do not help identify the issue (they would be useless even as runtime errors).
We should try to use more clear phantom types. For example instead of
CreateCollectionBuilder<Yes, No, No>

we can have
CreateCollectionBuilder<Ok, MissingIndexingPolicy, MissingOffer>

This way the error is clear (MissingIndexingPolicy is as clear as any runtime error) and we do not lose the compile time checks.

I think we are looking for a solution for the wrong problem.
The problem here is that the types are not self-explanatory: No and Yes do not help identify the issue (they would be useless even as runtime errors).
We should try to use more clear phantom types. For example instead of
CreateCollectionBuilder<Yes, No, No>

we can have
CreateCollectionBuilder<Ok, MissingIndexingPolicy, MissingOffer>

This way the error is clear (MissingIndexingPolicy is as clear as any runtime error) and we do not lose the compile time checks.

I still don't think that would help. The error would still be:
No method for $VERY_SCARY_TYPE

I still don't think that would help. The error would still be:
No method for $VERY_SCARY_TYPE

It also doesn't eliminate the problem discussed in #130. Most client libraries I've used in Rust and other languages don't have compile time checks. This also leads to way clearer documentation IMO, which is a huge win either way

It also doesn't eliminate the problem discussed in #130. Most client libraries I've used in Rust and other languages don't have compile time checks. This also leads to way clearer documentation IMO, which is a huge win either way

I still don't think that would help. The error would still be:
No method for $VERY_SCARY_TYPE

True. At that point the user will look at the documentation and find out that, if they receive MissingIndexingPolicy it means they are missing the Indexing Policy.
The alternative is to force the user to get a runtime error (which can be complex/unlikely depending of the code), look at the error, interpret it and finally understand they are missing an IndexingPolicy.
If they miss it - maybe just because they do not treat  the errors in a rigorous way - they end up shipping invalid code. And I mean really invalid code, that is code that will never work. That would be a defeat of an SDK which literally stands to avoid that.
We should ask ourselves: it's better to ship potentially invalid code that compiles or have to face errors right away - as ugly as they are? As I understand the Rust community, they prefer safety first (otherwise they would use C# or JavaScript) and they are used to complex types.
I think we are missing two important things right now:

Replace No with a proper description.
Document clearly what the phantom types are and why they might happen.

@thomastaylor312 makes a valid point in #130, carrying around half composed builders is painful. But that's been already addressed in #119 anyway.

I still don't think that would help. The error would still be:
No method for $VERY_SCARY_TYPE

True. At that point the user will look at the documentation and find out that, if they receive MissingIndexingPolicy it means they are missing the Indexing Policy.
The alternative is to force the user to get a runtime error (which can be complex/unlikely depending of the code), look at the error, interpret it and finally understand they are missing an IndexingPolicy.
If they miss it - maybe just because they do not treat  the errors in a rigorous way - they end up shipping invalid code. And I mean really invalid code, that is code that will never work. That would be a defeat of an SDK which literally stands to avoid that.
We should ask ourselves: it's better to ship potentially invalid code that compiles or have to face errors right away - as ugly as they are? As I understand the Rust community, they prefer safety first (otherwise they would use C# or JavaScript) and they are used to complex types.
I think we are missing two important things right now:

Replace No with a proper description.
Document clearly what the phantom types are and why they might happen.

@thomastaylor312 makes a valid point in #130, carrying around half composed builders is painful. But that's been already addressed in #119 anyway.

maybe just because they do not treat the errors in a rigorous way

I understand the concern around safety, but Rust essentially forces you to handle errors by at least unwrapping them or explicitly ignoring them, so an error will be seen, even if it isn't rigorously handled. Looking at common builder patterns in things like reqwest, hyper, and std::command::Command, we don't see validation until build/finalize is called and people safely use those all the time. I haven't personally seen (which doesn't mean it can't exist somewhere) anything mainstream that uses the style of builder as we currently have. As things currently stand there is a lot of ceremony for very little benefit IMO, particularly when trying to do the simple/common operations like fetching a document or blob. Making every single thing compile time checked for me lands squarely on the dogmatic side of things rather than pragmatic.
Another option here if we are truly worried about compile time checks is to take a page from rustoto and have the idea of input and output, where the input structs will have required fields and everything else behind an Option. I don't think bespoke implementations for different sets of phantom data is developer or user friendly

maybe just because they do not treat the errors in a rigorous way

I understand the concern around safety, but Rust essentially forces you to handle errors by at least unwrapping them or explicitly ignoring them, so an error will be seen, even if it isn't rigorously handled. Looking at common builder patterns in things like reqwest, hyper, and std::command::Command, we don't see validation until build/finalize is called and people safely use those all the time. I haven't personally seen (which doesn't mean it can't exist somewhere) anything mainstream that uses the style of builder as we currently have. As things currently stand there is a lot of ceremony for very little benefit IMO, particularly when trying to do the simple/common operations like fetching a document or blob. Making every single thing compile time checked for me lands squarely on the dogmatic side of things rather than pragmatic.
Another option here if we are truly worried about compile time checks is to take a page from rustoto and have the idea of input and output, where the input structs will have required fields and everything else behind an Option. I don't think bespoke implementations for different sets of phantom data is developer or user friendly

The alternative is to force the user to get a runtime error (which can be complex/unlikely depending of the code)

I'm all for compile time checks that can prevent subtly wrong code from being introduced but the errors we're discussing here are not subtle. There is no way to use these builders in subtly wrong ways. The user will either correctly use them or receive a panic anytime they run the code - with a very clear error message of what is wrong. This has nothing to do with what names we use for the generic parameters. This is a criticism of the mechanism itself.
I believe our goal should be that when the user uses this API incorrectly, they are able to understand what is wrong quickly and know exactly what they need to do to fix their incorrect use. Having a compile time error will let the user know something is wrong more quickly, but that advantage is lost when it comes to having the user understand what they need to do to fix the error.
That fact, combined with the fact that the documentation is way more clear when the machinery for these compile time checks is removed, makes it clear to me that we should drop the compile time checks.
Again, I think having the ability to protect misusage at compile time is a great tool to have in our toolbox. I'm sure there will be times where we'll want to use it, but I don't think that this is one of those times.

The alternative is to force the user to get a runtime error (which can be complex/unlikely depending of the code)

I'm all for compile time checks that can prevent subtly wrong code from being introduced but the errors we're discussing here are not subtle. There is no way to use these builders in subtly wrong ways. The user will either correctly use them or receive a panic anytime they run the code - with a very clear error message of what is wrong. This has nothing to do with what names we use for the generic parameters. This is a criticism of the mechanism itself.
I believe our goal should be that when the user uses this API incorrectly, they are able to understand what is wrong quickly and know exactly what they need to do to fix their incorrect use. Having a compile time error will let the user know something is wrong more quickly, but that advantage is lost when it comes to having the user understand what they need to do to fix the error.
That fact, combined with the fact that the documentation is way more clear when the machinery for these compile time checks is removed, makes it clear to me that we should drop the compile time checks.
Again, I think having the ability to protect misusage at compile time is a great tool to have in our toolbox. I'm sure there will be times where we'll want to use it, but I don't think that this is one of those times.

You made all valid points.
But what about going for a third way? We can switch back to the constructor pattern (like @rylev suggested some time ago).
Instead of:
client
  .create_collection()
  .with_offer(offer)
  .with_collection_name(collection_name)
  .with_partition_key(partition_key)
  .with_indexing_policy(indexing_policy)
  .execute().await?;

We could end up with:
client
  .create_collection(
    offer,
    collection_name,
    partition_key,
    indexing_policy)
  .execute().await?;

The type will be CreateRequestBuilder (eventually with lifetimes for borrows but that's it).

2
No runtime errors.
The constructor guarantees proper initialization.

3
Very autocompletion friendly.

4
Leads to clear documentation.
The user will read immediately the mandatory fields as soon as they look at the create_collection function.

5
Much less code in request builders.
All the with_xxxx mandatory function will be removed saving potentially a lot of code.

Downsides

N
Downside
Desc

1
Much less readable.
It is not a goal for our SDK so I think we can live with it.

What do you think? I think this can be the best of both worlds.

You made all valid points.
But what about going for a third way? We can switch back to the constructor pattern (like @rylev suggested some time ago).
Instead of:
client
  .create_collection()
  .with_offer(offer)
  .with_collection_name(collection_name)
  .with_partition_key(partition_key)
  .with_indexing_policy(indexing_policy)
  .execute().await?;

We could end up with:
client
  .create_collection(
    offer,
    collection_name,
    partition_key,
    indexing_policy)
  .execute().await?;

The type will be CreateRequestBuilder (eventually with lifetimes for borrows but that's it).

2
No runtime errors.
The constructor guarantees proper initialization.

3
Very autocompletion friendly.

4
Leads to clear documentation.
The user will read immediately the mandatory fields as soon as they look at the create_collection function.

5
Much less code in request builders.
All the with_xxxx mandatory function will be removed saving potentially a lot of code.

Downsides

N
Downside
Desc

1
Much less readable.
It is not a goal for our SDK so I think we can live with it.

What do you think? I think this can be the best of both worlds.

Wouldn't some of the constructors get a little large? If we do go this route, I think the Input/Output structure in rustoto that I mentioned before might be a better pattern

Wouldn't some of the constructors get a little large? If we do go this route, I think the Input/Output structure in rustoto that I mentioned before might be a better pattern

We are only proposing doing this for the required parameters right? The optional ones would still be specified through builder methods?
If so, in cosmos the largest number of required parameters is 4 which is certainly doable though I’d be a bit worried about other crates having some with more than 4.

We are only proposing doing this for the required parameters right? The optional ones would still be specified through builder methods?
If so, in cosmos the largest number of required parameters is 4 which is certainly doable though I’d be a bit worried about other crates having some with more than 4.

We are only proposing doing this for the required parameters right? The optional ones would still be specified through builder methods?

Yes only for the required params, the optional will remain as they are: there is no risk of partial construction there and they do not change the type definition. Also, the macro makes them very easy to work with.

If so, in cosmos the largest number of required parameters is 4 which is certainly doable though I’d be a bit worried about other crates having some with more than 4.

The storage crate rewrite (#119) was done to avoid just that (and it works very well). Right now the constructors take at most two parameters (which I think is acceptable) while the majority just require zero or one. This way I was able to remove all the generics while keeping the API clean.
For example this call goes from:
let _response = client
    .put_block_blob()
    .with_container_name(&container)
    .with_blob_name(&blob)
    .with_body(&buf)
    .finalize()
    .await?;

to
let _response = blob.put_block_blob(&buf).execute().await?;

That's because blob contains both the client and the "blob name". It's an enriched client (or maybe in rusty terms we shoud call it composited client). Incidentally, it's the same thing @thomastaylor312 was doing by creating a struct that held both client and blob name.

We are only proposing doing this for the required parameters right? The optional ones would still be specified through builder methods?

Yes only for the required params, the optional will remain as they are: there is no risk of partial construction there and they do not change the type definition. Also, the macro makes them very easy to work with.

If so, in cosmos the largest number of required parameters is 4 which is certainly doable though I’d be a bit worried about other crates having some with more than 4.

The storage crate rewrite (#119) was done to avoid just that (and it works very well). Right now the constructors take at most two parameters (which I think is acceptable) while the majority just require zero or one. This way I was able to remove all the generics while keeping the API clean.
For example this call goes from:
let _response = client
    .put_block_blob()
    .with_container_name(&container)
    .with_blob_name(&blob)
    .with_body(&buf)
    .finalize()
    .await?;

to
let _response = blob.put_block_blob(&buf).execute().await?;

That's because blob contains both the client and the "blob name". It's an enriched client (or maybe in rusty terms we shoud call it composited client). Incidentally, it's the same thing @thomastaylor312 was doing by creating a struct that held both client and blob name.

I think I like this! Did this change also clean up the docs to make them more coherent?

I think I like this! Did this change also clean up the docs to make them more coherent?

You made all valid points.
But what about going for a third way? We can switch back to the constructor pattern (like @rylev suggested some time ago).
Instead of:
client
  .create_collection()
  .with_offer(offer)
  .with_collection_name(collection_name)
  .with_partition_key(partition_key)
  .with_indexing_policy(indexing_policy)
  .execute().await?;

We could end up with:
client
  .create_collection(
    offer,
    collection_name,
    partition_key,
    indexing_policy)
  .execute().await?;

	The type will be CreateRequestBuilder (eventually with lifetimes for borrows but that's it).
2	No runtime errors.	The constructor guarantees proper initialization.
3	Very autocompletion friendly.
4	Leads to clear documentation.	The user will read immediately the mandatory fields as soon as they look at the create_collection function.
5	Much less code in request builders.	All the with_xxxx mandatory function will be removed saving potentially a lot of code.
Downsides
N	Downside	Desc
1	Much less readable.	It is not a goal for our SDK so I think we can live with it.
What do you think? I think this can be the best of both worlds.

Hi 👋🏻 Just my two cents here.
I've found that .map works really well for this sort of thing (and looks pretty sweet, too).

You made all valid points.
But what about going for a third way? We can switch back to the constructor pattern (like @rylev suggested some time ago).
Instead of:
client
  .create_collection()
  .with_offer(offer)
  .with_collection_name(collection_name)
  .with_partition_key(partition_key)
  .with_indexing_policy(indexing_policy)
  .execute().await?;

We could end up with:
client
  .create_collection(
    offer,
    collection_name,
    partition_key,
    indexing_policy)
  .execute().await?;

	The type will be CreateRequestBuilder (eventually with lifetimes for borrows but that's it).
2	No runtime errors.	The constructor guarantees proper initialization.
3	Very autocompletion friendly.
4	Leads to clear documentation.	The user will read immediately the mandatory fields as soon as they look at the create_collection function.
5	Much less code in request builders.	All the with_xxxx mandatory function will be removed saving potentially a lot of code.
Downsides
N	Downside	Desc
1	Much less readable.	It is not a goal for our SDK so I think we can live with it.
What do you think? I think this can be the best of both worlds.

Hi 👋🏻 Just my two cents here.
I've found that .map works really well for this sort of thing (and looks pretty sweet, too).

I think we've found a pretty good compromise with #147. Closing this. If there's more work to do, we can open up new issues for it.

I think we've found a pretty good compromise with #147. Closing this. If there's more work to do, we can open up new issues for it.


Implement CR edit & monitoring using improved controller support

Blocked on controller issue: https://github.com/fusor/mig-controller/issues/401
Using this issue as a placeholder to capture our desire to improve our ability to make changes to CRs and subsequently monitor the resulting conditions based on that specific change. I think the conversation has largely settled on the controller supporting an observedGeneration field that would enable clients to determine which conditions are the result of a particular generation. This continues to be an ongoing discussion, and we'll update these issues as the approach becomes clearer, and therefore the required UI work items to take advantage of it.

Closing as a dupe in favor of #790


0.9 and tags

Is there anything in the works for 0.9 or are you looking for pull requests?

Bump.  We are also wondering about compatibility with 0.9 once it's released.  Not sure if we should try to refactor this gem ourselves or if someone smarter is already working on it.

we are having issue with 0.9 and the ruby client so any updates to support 0.9 will be nice.

Same here.

+1

+1

:+1:

@toddboom and/or @pauldix for now a branch would be enough, so people can start working on it :) #86

+1

:+1:

We haven't started work on it, but we'd happily accept PRs! Still putting all our focus on the core DB, then docs, then libraries (in that order) :)

But to start working on it wouldn't you first create an branch or you want us to commit potential breaking changes to the master ?

gem versioning should take care of that. Besides, 0.8 is deprecated
anyway.  Basically, create a branch, do the work, issue a PR, and we should
be good to go.
On Tue, Jun 16, 2015 at 7:57 PM, Dejan Golja<EMAIL_ADDRESS>wrote:

But to start working on it wouldn't you first create an branch or you want
us to commit potential breaking changes to the master ?
—
Reply to this email directly or view it on GitHub
https://github.com/influxdb/influxdb-ruby/issues/77#issuecomment-112606189
.

If someone have done this? Currently I'm working on it, you will watch the branch here, after I finish it, I'll send a PR.

@jsvisa I'm working on this also, and am planning to have something released later today. Also, be aware of #88 which has some significant refactoring. i'm going to try to get that in place today.
I also released v0.1.9 over the weekend, which will be the final release supporting InfluxDB v0.8.x. The v0.2.0 release will not be backwards compatible.

@toddboom :+1: look forward to it

:+1:

I also started working on it (my fork). Client seems to be working properly (administration methods, querying, writing data using new api). @toddboom please let me know, if it might be any use. Also - I started working on it on friday, before the release of 0.1.9 and those changes have not been merged, however I'm willing to do it.

Can this be closed since #92 was merged ?

@mcastilho yes - thanks!


[RFC] Improve Linked Relationship Handling

Problem Statement
Inclusion of a relationship in a payload is determined by its presence in the data. This is problematic for relationships with large numbers of members.
Proposal

Introduce a shorthand for always including a given relationship as a link: :link. See Examples below.
Make the implicit explicit by introducing an option for a relationship tuple: :optional. This option is merely to indicate the current behaviour is desired. A deprecation warning will be raised should a relationship handling option not be present.

Examples
The following would use the current behaviour and would result in a deprecation warning.
def relationships() do
  [author: AuthorView]
end

# Deprecation:

"relationship `author` for `mytype` is defined without an explicit handling option. To maintain current behaviour please define as: `author: {AuthorView, :optional}`"

Whereas this would not:
def relationships() do
  [
    dealerships: {DealershipView, :optional}
  ]
end

The following is an example of the new behaviour:
def relationships() do
  [
    author: {AuthorView, :link}, # NEW! link is always included
    books: {BookView, :include}, # CURRENT BEHAVIOUR
    payments: {PaymentView, :optional} # CURRENT BEHAVIOUR
  ]
end

Open Questions

[ ] Dynamically determining whether or not to include a relationship is currently not handled. Is this desirable?

I see.  Great explanation.  So w/ lots of relationships, the user has a few options:

Pagination
No pagination w/ include && w/o preload - which sounds like the case you are talking about??

Is this somewhat of a specialized case?  Perhaps this should simply be the fallback without any extra annotation in the view layer?

Perhaps this should simply be the fallback without any extra annotation in the view layer

A concern I have with this is that it'd be a breaking change necessitating a major release. This isn't necessarily a problem, but it doesn't really offer us an ergonomic way to build towards it (e.g. introduce deprecations or safe upgrade path).
Maybe the solution is to take a sneak peak at another RFC I wanted to open. Another problem with relationships/0 is that the only way to filter out relationships is by the presence or absence of the data. We may want to include or exclude relationships for user roles (e.g. admins or customer service reps may have more access). Introducing relationships/2 that accepts data and conn. We could always deprecate relationships/0 and introduce fully new behaviour for ONLY this implementation.

A concern I have with this is that it'd be a breaking change necessitating a major release.

One reason why I thought we could by default include was b/c it seems the paradigm was to include unless remove_links is set to false. Initially, I thought this would be a minor bump.  What would be breaking?
Also, how does one get the included resource (override?) when the view specifies :link?  Or is that not possible?

@snewcomer I think you're onto something here. OK, here's a summary of my thoughts right now:

:include means that we embed the relationship by default IF the data has been loaded
by default we always have a relationship link — this is net new behaviour
an unsolved problem, then, is how to include, or exclude, relationships for a given current user

I'm going to close this proposal and submit a brand new one to introduce relationships/2 — something that would offer us a clean upgrade path.

... the paradigm was to include unless remove_links is set to false...

Isn't remove_links only for the top-level :links object, and not a given relationship link? I.E...
{
 "id": 123,
  "type": "book",
  "data": {
    // etc.
  },
  "relationships": {
    "author": {
      "self": "http://example.com/books/123/relationships/author"  // NOT THIS
    },
  "links": {
    "self": "http://example.com/books/123" // BUT THIS
  }
}

@jherdman I'll wait for your new proposal!
Looks** like the test is looking at various levels.


Tuple invalid if missing optional elements

Summary
Code is better than words :smile:
Code occurring the bug
import typia from "typia";

is<[foo?: true]>([]) // false | should be true

I know this is a weird part of typescript, but the use case is for function parameters:
function fun(foo?: true) {}
is<Parameters<typeof fun>>([])

Oh my god, what that type is?

Found how to. Maybe updated at Sunday

@JakubSmahovsky Upgrade to<EMAIL_ADDRESS>then works fine.
Thanks for retporting.


Update documentation to explicitly say page blobs are not supported

Updating documentation for issue https://github.com/Azure/azure-storage-fuse/issues/1350

@akashdubey-ms

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

PR review team sent Teams msg to author today

@akashdubey-ms, @tamram,
Can you review this old PR and determine whether it needs to be closed or merged?

@OCDolan - Thanks for your contribution.
#sign-off

#sign-off

Due to the upcoming Build conference, all merging and publishing is on hold until the morning of 5/21.
This PR is ready for merge on 5/21.
#label: "event-triaged-to-10AM"
#label: "missed-content-complete"


[BUGFIX]Allow user to be invited to multiple admins' workspaces

Notion card
NA
Summary

A user can be invited to different admins' workspaces.
Preview

Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to
not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?

Checklist:

[x] I have manually tested all workflows
[x] I have performed a self-review of my own code
[ ] I have added automated tests for my code

@rohitjoshixyz Can we merge this as suggested by @apoorv-mishra ?

Okay go ahead @supriya3105


Can't set GTK/icon theme using gsettings under any circumstances

Hyprland Version
Hyprland, built from branch main at commit 3a1f30519bb3ae265fc4f9cc720513217e928fdb dirty (compositor: fix offset in auto arrangeMonitors). Tag: v0.28.0-92-g3a1f3051
Bug or Regression?
Bug
Description
Before anyone says anything, YES, I DID read the FAQ and the link inside it.  I'd be so happy if I were able to use something normal like nwg-look, but that only changes files the Sway wiki specifically says that the Wayland GDK backend completely ignores.
You also might ask "why don't you use the GTK_THEME envvar?" I am. But that only changes the GTK theme. You can't change anything else like icon themes or cursors with environment variables.
 And it does not work at all. I can't switch to any GTK/icon theme at all, not even the high contrast ones. It's as if it sees nothing else except Adwaita.
Combining all the time I've spent on this off and on ever since I switched to Hyprland around the beginning of July, I think I spent at least 4 hours just on GTK theming alone. I'm going crazy already. Please help.
How to reproduce
See attached video.

I try applying stuff with gsettings
I show it's useless, as Adwaita is still applied in both GTK and icon theme sections
I try applying stuff with gsettings, now having open two terminals where I use the 'monitor' function to actively show changes made
I show that I have installed the themes using my package manager
I show that the theme files are present inside the filesystem

Crash reports, logs, images, videos
https://github.com/hyprwm/Hyprland/assets/53472302/e529de50-e30f-441e-97f7-7a3291cc7fdd

I'd love to help you but I have no clue what is wrong.
At any rate, theming is completely separate from hyprland so it's not an issue here.
You can join the discord server and ask around for help there.
IIRC for my icons I just edited the config files manually by hand. Ignore the sway wiki, go with the files on the arch wiki.

IIRC for my icons I just edited the config files manually by hand.
What config files? $XDG_CONFIG_HOME/gtk-*?

Ignore the sway wiki, go with the files on the arch wiki.
You mean this?

You mean this?

yah

Tried that. Didn't work either. It's the files nwg-look modifies, but I've tried manually modifying them as well

I might have somewhat related issue, in my case, the gtk theme switch is not instant, I need to restart all gtk apps to apply the new theme, is it supposed to work like this? I didn't find any other theming issues here on github, only this one, so I'm thinking it's something on my side maybe 🤔

Completely unrelated. At least you can set a theme. And, yes, I'd expect I'd have to reopen a program to set a new theme


unknown type name 'grpc_auth_context'

I get an error when trying to compile grpc release-0_10_0:
[...]
[C]       Compiling src/core/httpcli/httpcli.c
In file included from ./src/core/httpcli/httpcli_security_connector.h:37:0,
                 from src/core/httpcli/httpcli.c:43:
./src/core/security/security_connector.h:80:3: error: unknown type name ‘grpc_auth_context’
   grpc_auth_context *auth_context; /* Populated after the peer is checked. */
   ^
./src/core/security/security_connector.h:220:1: error: unknown type name ‘grpc_auth_context’
 grpc_auth_context *tsi_ssl_peer_to_auth_context(const tsi_peer *peer);
 ^
Makefile:2847: recipe for target 'objs/opt/src/core/httpcli/httpcli.o' failed
make[1]: *** [objs/opt/src/core/httpcli/httpcli.o] Error 1

That's interesting. 0.10.0 compiles fine on our test environments and locally. But I can see what the problem might be.
What's your compiler / environment ?

Thanks for the quick reply!
 ~> lsb_release -a
LSB Version:	[...]
Distributor ID:	Ubuntu
Description:	Ubuntu 15.04
Release:	15.04
Codename:	vivid
~> gcc --version
gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2

Okay now that's really odd, this is basically a very standard installation you have. And I just tried with a docker image of ubuntu:15.04, and I was able to compile the release-0_10_0 tag in there. So I'm not really sure what's going on.

If this is an upgrade, you may not have done a 'make clean' before
compiling the new 0.10 version... Could that be the issue here?
On Wed, Jul 15, 2015 at 1:39 PM, Nicolas Noble<EMAIL_ADDRESS>wrote:

Okay now that's really odd, this is basically a very standard installation
you have. And I just tried with a docker image of ubuntu:15.04, and I was
able to compile the release-0_10_0 tag in there. So I'm not really sure
what's going on.
—
Reply to this email directly or view it on GitHub
https://github.com/grpc/grpc/issues/2461#issuecomment-121740332.

Crap, I've realized it just this very instant! It is an upgrade and I did not purge the previous destination directory, so it must have picked up headers from the 0_9 install. Sorry! Solved!


UI breaks in several ways with latest Firefox on Mac

See screenshots below

@jguittard I think I fixed these UI issues in the PR that I'm working on. I'll send it in a couple of hours.

Awesome @ezimuel!
Did you get the dropdown for source code work on Chrome ?

Le 15 avr. 2015 à 15:40, Enrico Zimuel<EMAIL_ADDRESS>a écrit :
@jguittard https://github.com/jguittard I think I fixed these UI issues in the PR that I'm working on. I'll send it in a couple of hours.
—
Reply to this email directly or view it on GitHub https://github.com/zfcampus/zf-apigility-admin-ui/issues/28#issuecomment-93405051.

@jguittard yes, I also solved the issue for the source code reported in PR #18.

Solved in #29


[BUG] Can't use your radar

Describe the bug
I can't use the radar
To Reproduce
when I press the F5 key or type / radar_remote or / radar no radar appears.
Expected behaviour
I would like to use the function 'radar'
Screenshots
https://ibb.co/PCfdGKK
Desktop (please complete the following information):

FiveM Last version
FiveM server Qbus Framework Last version
Radar version [e.g. 1.3.0]

Additional context
I have no error message whatsoever in game or on my server console.
FYI: i used also /reset_radar_data
When I stoped and restarted i have this message (Screenshot)

Try resetting your GTA V key bindings.

+1 - getting an issue where pressing the keybind freezes the game as if something is open in front of it. Tried resetting radar data, clearing cache, and binding it to a different key but no joy. Latest version of both the plugin and fivem

Hi,
Sorry but after I reset my hotkey settings the script still doesn't work and I still have the message in my console.
And I tried to change the option in your config.lua.
For example:
-- Remote control key
remote_control = "f5",
to
-- Remote control key
remote_control = "o",
Screenshots
https://ibb.co/PCfdGKK
Thank you for you help.

+1 - getting an issue where pressing the keybind freezes the game as if something is open in front of it. Tried resetting radar data, clearing cache, and binding it to a different key but no joy. Latest version of both the plugin and fivem

Have you tried downloading a new FiveM.exe into a folder on your desktop, and then tried running that and seeing if it works? You could also try taking your clientside cache folder out, and give that a go.

Hi,
Sorry but after I reset my hotkey settings the script still doesn't work and I still have the message in my console.
And I tried to change the option in your config.lua.
For example:
-- Remote control key
remote_control = "f5",
to
-- Remote control key
remote_control = "o",
Screenshots
https://ibb.co/PCfdGKK
Thank you for you help.

Changing the default keys in the configuration file only works for players who have never had their key binds generated. You'd need t change yours in the FiveM section of GTA's key bindings menu.
Those messages in your console are normal.

Hi,
thank you for your reply. but in fact I am using the latest version of FiveM and I have nothing (Radar option) in the FiveM section of the GTA hotkey menu.

Hi,
thank you for your reply. but in fact I am using the latest version of FiveM and I have nothing (Radar option) in the FiveM section of the GTA hotkey menu.

Just out of curiosity, are you using the radar version that comes with Sonoran CAD?

hello, i only use your latest version. I deleted my cache on my server and on my client and also reinstalled the latest version of FiveM.

hello, i only use your latest version. I deleted my cache on my server and on my client and also reinstalled the latest version of FiveM.

I'm a bit stumped then. Try this:
Open Windows Explorer and navigate to C:\Users<username>\AppData\Roaming\CitizenFX and open the file named fivem.cfg with a program like Notepad++. Once open, delete all of the lines that start with rbind wk_wars2x, for example, all of mine are:
rbind wk_wars2x KEYBOARD L "radar_key_lock"
rbind wk_wars2x KEYBOARD NUMPAD5 "radar_bk_ant"
rbind wk_wars2x KEYBOARD NUMPAD6 "radar_bk_cam"
rbind wk_wars2x KEYBOARD NUMPAD8 "radar_fr_ant"
rbind wk_wars2x KEYBOARD NUMPAD9 "radar_fr_cam"
rbind wk_wars2x KEYBOARD F5 "radar_remote"

Yeah, I've tried this, still doesn't work - deleted cache, rebinded keys, the whole heap. Nothing :(

Also just tried a full delete and reinstall - still nothing

I opened the console:

Not sure if this helps

I opened the console:

Not sure if this helps

What is the name of the resource in your resource folder?


Question about the code

Hi, very interesting about your paper! I am also trying to find a better solution for contrastive learning on regression! I have a question about the code related to the label. Line 480-481 in video.py, what is the difference between the outcome and outcome_cls in criterion_cntrst? Is outcome the true label in the dataset? But how to get "outcome_cls" in other regression tasks?
Thanks in advanced!

Hi,
Sorry for the late reply.
outcome_cls corresponds to the value of ECDF(y) * N  (i.e. \phi(y) * N in the paper). It is then normalized by 2/N when calculating the AdaCon loss function in L543 of rnet2dp1.py
outcome_cls  is calculated in L123 of echo.py. We calculate a discrete version of ECDF but it does not affect the results since the window is very small.

Hi,
Sorry for the late reply.
outcome_cls corresponds to the value of ECDF(y) * N (i.e. \phi(y) * N in the paper). It is then normalized by 2/N when calculating the AdaCon loss function in L543 of rnet2dp1.py
outcome_cls is calculated in L123 of echo.py. We calculate a discrete version of ECDF but it does not affect the results since the window is very small.
Let me know if you have anymore questions

Hi, thanks for your reply!
So ECDF(yi) * N is the number of samples whose labels are lower or equal to yi? And N is the total number of training samples?

So ECDF(yi) * N is the number of samples whose labels are lower or equal to yi? And N is the total number of training samples?
Yes, that is correct. The normalization of 2/N was done separately in the loss function because of experimentation at the time. I may amend the code some point later so it is less confusing.


in IE8,  tilt not work!

it work well in chrome , but not work in IE8 (win7)

IE 8 does not fully support the SVG standard, so this plugin will not work with it.  You will need IE 9 or better.


19.1.402 VSIX Error after Installation

Hi,
after Installation 19.1.402 the Xpand.VSIX is not correct. The Menu is there (see Screenshot) but no Menuitem works with the displayed Errormessage.
Maybe you can see something i the LogFile.

ActivityLog.zip

Xpand.VSIX.zip
try this one and let me know if it works for vs2017 please

eXpand.lab release 19.1.402.1 includes commit that relate to this task:

VSIX dependecies missing for VS2017 #454

Please test if it addresses the problem. If you use nuget add our LAB NugetServer as a nuget package source in VS.
Thanks a lot for your contribution.

Hi,
The installation does not work in my side.
Downloading Sources from https://github.com/eXpandFramework/eXpand.lab/releases/download/19.1.402.1/Xpand-Source-19.1.402.1.zip into C:\Users\isata\Documents\eXpandFramework
iex : Exception lors de l'appel de « DownloadFile » avec « 2 » argument(s) : « Le serveur distant a retourné une erreur : (404) Introuvable. »
Au caractère Ligne:1 : 50

... cess -Force;iex "$(([System.Net.WebClient]::new()).DownloadString('ht ...

            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : NotSpecified: (:) [Invoke-Expression], MethodInvocationException
FullyQualifiedErrorId : WebException,Microsoft.PowerShell.Commands.InvokeExpressionCommand

BR
ISA

according the the links in lab realeases  it must be
: https://github.com/eXpandFramework/eXpand.lab/archive/19.1.402.1.zip
Am I right ?

Xpand.VSIX.zip
try this one and let me know if it works for vs2017 please

Thanx.
It works for 2017.

eXpand.lab release 19.1.402.3 includes commit that relate to this task:

VSIX dependecies missing for VS2017 #454

Please test if it addresses the problem. If you use nuget add our LAB NugetServer as a nuget package source in VS.
Thanks a lot for your contribution.

Closing issue for age. Feel free to reopen it at any time.
.Thank you for your contribution.


add netaddr to teams docker

Status
Ready
Related Issues
related: https://github.com/demisto/etc/issues/22439
Description
Adding netaddr to the teams docker (used by export indicators and EDL integrations) in order to create ip range support

Build is failing. Try updating the base docker image to the latest available

Docker Image Ready - Dev
Docker automatic build at CircleCI has deployed your docker image: devdemisto/teams:<IP_ADDRESS>10
It is available now on docker hub at: https://hub.docker.com/r/devdemisto/teams/tags
Get started by pulling the image:
docker pull devdemisto/teams:<IP_ADDRESS>10

Docker Metadata

Image Size: 53.24 MB

Image ID: sha256:f37db62689780d52cfe237af3050618b1c992bbf818442bfdf76cd281af4da0f

Created: 2020-03-09T08:15:51.317183186Z

Arch: linux/amd64

Command: ["python3"]

Environment:

PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG=C.UTF-8
GPG_KEY=0D96DF4D4110E5C43FBFB17F2D347EA6AA65421D
PYTHON_VERSION=3.7.5
PYTHON_PIP_VERSION=19.3.1
PYTHON_GET_PIP_URL=https://github.com/pypa/get-pip/raw/ffe826207a010164265d9cc807978e3604d18ca0/get-pip.py
PYTHON_GET_PIP_SHA256=b86f36cc4345ae87bfd4f10ef6b2dbfa7a872fbff70608a1e43944d283fd0eee

Labels:

org.opencontainers.image.authors:Demisto<EMAIL_ADDRESS>org.opencontainers.image.revision:f44a93a2c0dc488be7eb34d0117e1add4d9534f5
org.opencontainers.image.version:<IP_ADDRESS>10

Docker Image Ready - Production
Docker automatic build at CircleCI has deployed your docker image: demisto/teams:<IP_ADDRESS>11
It is available now on docker hub at: https://hub.docker.com/r/demisto/teams/tags
Get started by pulling the image:
docker pull demisto/teams:<IP_ADDRESS>11

Docker Metadata

Image Size: 53.24 MB

Image ID: sha256:afe56ffb8f8a92c8b6e2c62d217dc65b2eb4f58b2af880de18586399c72ca6ed

Created: 2020-03-09T09:12:43.170776742Z

Arch: linux/amd64

Command: ["python3"]

Environment:

PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG=C.UTF-8
GPG_KEY=0D96DF4D4110E5C43FBFB17F2D347EA6AA65421D
PYTHON_VERSION=3.7.5
PYTHON_PIP_VERSION=19.3.1
PYTHON_GET_PIP_URL=https://github.com/pypa/get-pip/raw/ffe826207a010164265d9cc807978e3604d18ca0/get-pip.py
PYTHON_GET_PIP_SHA256=b86f36cc4345ae87bfd4f10ef6b2dbfa7a872fbff70608a1e43944d283fd0eee

Labels:

org.opencontainers.image.authors:Demisto<EMAIL_ADDRESS>org.opencontainers.image.revision:161b38d07e23476d5e61b39a6e1e8fdc6d320cfe
org.opencontainers.image.version:<IP_ADDRESS>11


mj-social-element src attribute doesn't work

<mj-social-element> src attribute doesn't work.
Reproduction Steps:
Check out this demo: https://mjml.io/try-it-live/ByClvhn2f
I also tested on local which has the same issue.
I used JavaScript API on local.
index.js
const mjml2html = require('mjml'),
      fs = require('fs'),
      path = require('path');

function run () {
  fs.readFile('index.mjml', {encoding: 'utf-8'}, (err, data) => {
    if (err) { return console.log(err); }
    let htmlOutput = mjml2html(data, {
      minify: true
      // beautify: true
    });
    // console.log(htmlOutput)
    fs.writeFile('index.html', htmlOutput.html, err => {
      if (err) { return console.log(err); }
      console.log('index.html saved');
    });
  });
}

run();

And do node .
Expected behavior:
Expect MJML uses my customized images.
Observed behavior:
But it uses the default images.
MJML version:
v4.0.3
Npm: v5.6.0
Node: v8.11.1
Email clients the bug is seen on:
All

Hi,
This is because you're using the name attribute that doesn't allow any override. Just remove them, apply your bakcground color and you're good cf : https://mjml.io/try-it-live/SJXucnh2G

I see, thanks


Update access-resources.md

AddedPrerequisites for Azure AD Connect to related articles

@JohanFreelancer9 Please copy review

Issue#https://github.com/MicrosoftDocs/microsoft-365-docs/issues/4504

@scotvidican Please help us in merging the PR. Thanks.


Is it possible to add URL Types into the project.yml for deeplinking?

These url types are part of the info plist. If you have an actual Info.plist file in the target, using the editor in xcode will make the necessary diff to that file. Looks like the key is called CFBundleURLTypes

If you're using an auto generated info plist through Xcode, you can add the relevant build settings prefixed with INFOPLIST_KEY_ like INFOPLIST_KEY_CFBundleURLTypes
If you're using XcodeGen to generate the Info.plist, you can add the relevant key to the info.properties on the target https://github.com/yonaskolb/XcodeGen/blob/master/Docs/ProjectSpec.md#plist

I hope that's enough information to go off

@yonaskolb the INFOPLIST_KEY_ idea is not working for me, Xcode 15.2, XcodeGen 2.38.0, the values are added to the build settings instead.
Here is an example of my implementation:
    application:
      type: application
      platform: iOS
      deploymentTarget: '15.0'
      settings:
        base:
          ASSETCATALOG_COMPILER_APPICON_NAME: AppIcon
          OTHER_LDFLAGS: $(inherited) -ObjC
          INFOPLIST_FILE: $(PRODUCT_NAME)-Info.plist
          INFOPLIST_KEY_CFBundleURLTypes:
            - INFOPLIST_KEY_CFBundleTypeRole: Viewer
              INFOPLIST_KEY_CFBundleURLName: "Custom scheme"
              INFOPLIST_KEY_CFBundleURLSchemes:
                - "com.custom-scheme.demo"

Unless I am doing something wrong way....?

It seems CFBundleURLTypes isn't supported by the INFOPLIST_KEY_ build setting method, perhaps as it's a dictionary as opposed to a string value. You'll have to add it to your info plist then

Unless you generate your Info.plist via the yaml file directly. There one can add the keys without that prefix. I moved the whole Info.plist generation to xodegen and it is perfectly fine now. Thanks @yonaskolb !

Closing this for now


[Enhancement]: Table row's delete button placement and UI

Description:
Currently, the table row's delete button is plainly visible on the UI. We can improve the interface by adding a container that displays the number of selected rows along with the delete button. Please checkout the screenshots below. 👇
Screenshot:
Before
https://github.com/Agenta-AI/agenta/assets/87828904/f52d2343-9f83-4322-aa4d-feeb38cc5e34
After
https://github.com/Agenta-AI/agenta/assets/87828904/1b7aae46-5766-4bea-ba09-ffc3f6d6300e

Thanks @ashrafchowdury . I agree with the idea and adding consistency to the design. However I am not very much convinced with the solution. I think having a visible box there with the text and delete button does not look good. I'd look into how other UIs have resolved this issue and use their design

Thank you for the suggestion, @mmabrouk. Alternatively, we could consider adding the 'delete' button within the table. What are your thoughts on this?
Screenshot:
Without any selection

With selection

I am going to close this for now. We will reopen it in a couple of week when we redesign the interface.


Add SAI to REST, DOCUMENT, and GrahpQL APIS, as applicable

C2-539: Add SAI queries to Document APIs
C2-536: Add SAI queries to REST

Added statement about SAI in Document API (it's automatic).


Integrate Remote ImGui

Hey,
Not really an issue but have you tried to add the remote imgui stuff in unreal ?

Yes, I used it in my last company, and I do have somewhere an old quick version that I did long time ago. I believe that at some point it was mentioned as a possible feature but I had to remove it because I could not find enough time and I did not want to give false hopes.
It might come at some point, but I won't promise anything right now. It is however likely that I will want to add it, as in my current work we use a vanilla version of this plugin and I sort of miss Remote ImGui. So stay tuned... but be patient :)
I will however explore alternatives before moving forward as I think that Remote ImGui is not under active development anymore and I did have some problems when using it in Unreal.

Is there any update on this? Would be really a useful addition.

Unfortunately no, not at this time.

Hi. I am the author of the library netImgui and was thinking of adding Unreal support next. When looking for current Dear ImGui Unreal integration, I came accros this plugin. I was wondering if you'd be interested for me to add support through your plugin, rather than creating my own.

Sure, yes! That would be nice. We can perhaps sync efforts. Although I must warn you that I'm doing things very slowly recently and hardly can find enough time. I was thinking about integrating ImGui Remote and possibly other remote plugins as well but never did it. As a result, there is something that I believe may be partially helpful but you might find it annoying at first ;) The whole input state. The idea is that I can collect input and then switch between UE and remote. I did that in my previous studio but never in this plugin. It worked quite OK and I was able to use the Unreal and remote inputs at the same time - not literally but in the same session, basically whatever windows had a focus was used for input.
What platforms are supported? Can it work on consoles? How you compile it with UE? With the ImGui Remote, I was not able to compile it as part of the UE plugin, and as a result, I had to use a statically linked library.

Hi. I have previous experience as a graphisc programmer on UE3/4 and  believe I should be able to add it myself.
I currently support Window/XBox/Android/Linux out of the box for the client code, but it was designed to be really easy to add to any platform. Only requires implementing 4-5 short functions to open, close, send, receive, listen data with sockets (can see it in NetImgui_NetworkWin32.cpp). I was thinking of implementing these functions using UE4 network code, so it then works on all platform they support. I am just not sure plugin have this level of access to core UE code. The code should be added alongside your code, so they are both compiled together.
For the inputs, The entire control is shifted to netImgui once connected, then resume  local input when disconnected. I re-use the same ImGui context, but can also be started in a new context, leaving the origal intact.

EDIT: I look at the netImgui and it looks really good. It is nicely done.

Merci! :)

I checked the SampleDualUI and I will have a few questions and notes. Forgive me if I'm missing something but I only looked briefly:

There are lots of options, which always is nice.
I noticed some context switching and restorations inside of the NetImgui API. This plugin also does a lot of contexts switching to support PIE. Will that not cause collisions?
Later I will also need to add an option to create other contexts for regular non-debug widgets. But those contexts will not be remotely controlled, so that should be fine as your example also has a local context.
In your example, I see separate blocks with NewFrame -> Content -> EndFrame flow. One for the remote and one for the local context. This plugin sets the context for the whole frame and then collects debug content from different game objects. And the flow is more less like this: NewFrame (for every context) -> Next UE Frame-> switching between contexts at the start of each world update -> EndFrame and copy render data (for every world context).
For dedicated servers and VR, this is obviously not a consideration, but is it possible to have input from the client and server used interchangeably? I'm asking because in my previous project where I used a remote connection, my preferred workflow was to connect from a browser that was running in the same desktop and then switching between that and using ImGui from the game, whatever was more convenient at the moment. The game used the remote input whenever available (which was the case when the mouse cursor was inside of the browser) or own input otherwise.

Not too much though, wanted this to be easy to add to any codebase using Dear ImGui, with almost no changes. :)

This will requires to be careful of the approach taken. netImgui can be used 2 ways.
(A) Use current context without switching.
(B) Use its own context, leaving the original context intact
Now, we could either try to tie netImgui to only 1 context or let netImgui use its own context, not affecting any of your context. Maybe this should be as simple as possible, I don't foresee a lot of use for netImgui while in the editor multi-window environement, it's more for a game launched on console/cellphone.

Yes, to do that, I do 2(B), which means I 'cloned' the active context on connection, and continue using only the copy.

This should be fine, we can have only 1 of the 'world' tied to netImgui, and everything else works the same.

Dual input is currently not supported, it would require some consideration on how to handle. It could be a toggle to tell netImgui where to take input from, locally or remotely. Had not considered this usercase, since I was thinking of gaming console where it's obvious you'd want the input from the server.

I don't foresee a lot of use for netImgui while in the editor multi-window environement, it's more for a game launched on console/cellphone.

Well, you might be surprised ;) In my last project, where I had a more dirty but in some respect a more complete integration, I (like a few other colleagues) used remote connection it in my main workflow even though for the most part I was using PIE and we didn't have a dedicated server. In-game debug was very useful for recording and remote for most of the regular development. We used keyboard shortcuts to switch to which PIE remote should be bound and looked at the remote flag to figure out what input use. It was a great workflow, despite a bit hackish implementation, but I never found enough time/strength to clean and add this here - partially because at home I have only one screen and no dedicated server, what took the personal incentive out. But the remote capabilities will be very nice, even if only for servers or VR. I'm also starting to use this plugin in a project that has a dedicated server, so I will surely be thankful.
Ad 2. I'm not going to lie. I am not fully sure how that works in netImgui. From my side, I would imagine that those contexts that are for debugging could be safely tied to the netImgui. It makes perfect sense in my opinion. Some people use ImGui for non-debugging, in which case most likely it should be not tied to remote context, but we can always use a switch to control that feature. Later I want to refactor the plugin in a way that there is a clearer separation between ImGui for debugging and for other applications. One of the reasons is that I made/make some effort to isolate my debugging widget and input from the game as much as possible but this is undesirable for some applications. After that it will be clearer, what should be tied and what not.
Ad 2b. How that works? Is it possible to bind netImGui to context and unbind on demand? Could it be possible to select which PIE is bound? Assuming that it will be allowed in the editor, of course, because as I understand this is not necessarily on the cards. I see that you can connect multiple clients at the same time, does that mean that I could connect multiple PIE clients? Because that seems very powerful.
Ad 5. I understand the goals and why the design. It seems well-thought and as great as the Remote ImGui was netImui seems cleaner. Paradoxically, a bit hackish nature of the Remote ImGui made it easy for us to bend it - I don't know why but somehow you feel more excused in that situation ;) It would be nice to have that capability but this is my selfish thinking and please don't take that as pushing for a feature - especially if it would undermine other goals. And especially that netImgui have other great features.
In any case, some people feel that this plugin is overwhelming, so I'm happy to explain what and why at any time. As you probably noticed, I do looong responses, which means they can take some time.

(2) Ah, so you are thinking of using Dear ImGui for final product, gamer facing UI? Interesting. Right now, when not activating the 'cloning' feature, I just use the current context almost normally. On connection, I override the 'input' configuration settings, binding the standard Windows virtual keys ( CmdInput::eVirtualKeys ) instead, so input works the same on all client platform. Toggling which UE context we are using with netImgui is possible, but I will have to add a functionality. Make explicit the input override/restore so we can go from one to the other. Not a problem.
(2b) There is the option to clone the imgui context on connection (if requested) and then just use this copy. This leave the local context untouched and free to do whatever every frame. Not sure we need this for this case, unless you'd like to continue rendering some different Dear ImGui content in the UE window.
(5) It would not be too much trouble to support multi connections per editor. I already have all of the client data tracking encapsulated in 1 class, thinking that at some point people might want to do that :) If you look at the code in netImgui_Api.cpp, you'll see that every api call start by taking the global object gpClientInfo as the 'active' client. To support multiple client, I just need to figure out how to let user specify which one is active instead. This would be required if we want to support multiple remote clients from the same program. netImgui server only display one at a time though, you'd have to toggle between them, so not sure if this is desirable but it's definitly do-able.
(5+) I never used remoteImgui, let me know if there were some features you felt were usefull and that I could add.
I just got Unreal compiled and running on my PC, with you plugin. I will slowly look at having a basic Dear ImGui displayed in a game window, and see from there what I can do. I'll probably try a very basic approach first, then we can see about how to seal with multi-windows/context setup. I hope plugin have access to UE network socket class, that way I know it'll automatically work on every platform.

Ad 2. I don't, but some people do. I think that somebody mentioned about doing some sort of visualisation and using ImGui for UI - I suppose because it is very good for data. And somebody else wanted to use that for editor widgets (thread is still opened I think)... but to be fair we had the same idea in my last company :) This plugin wasn't designed with that in mind, but I'm thinking about improving that a bit.
The toggle could happen in this plugin. Actually, it is happening and it has to happen because every world has its own debug context which needs to be set at the beginning of the world update. So it will not be a problem unless netImgui would somehow need to own the global context pointer. Context proxy is the wrapper for the ImGui context, and the context manager is monitoring creation and switching. I think that hooking the netImgui to proxy should make things easier. In general, I tried to keep ImGui specific stuff in the proxy, manager and one class for handling the demo. The rest is mostly UE related stuff, making sure that it works with hot-reload etc. The plugin tries to be invisible for the game, so it adds an option to register for events and register own textures but other than that game should use the plain ImGui. Delegates are merely an option to call debug code and should not be an issue. The texture manager probably will need an extension to support texture upload... although I would say that this is hardly critical. In my last company, I never handled that part and nobody complained... meaning that nobody felt a need to use that.
Ad 5. Yeah, it is not necessary to support multiple clients. And what you mentioned later, one connection with an interchangeable active context is perfectly fine. In fact, this is what I used to do with Remote ImGui.
Ad 5+. I don't remember it exactly, but I don't think that there were many features that I would really need. In the end, it is pretty minimalistic. The one thing that I felt was useful I already mentioned, which would be a possibility to switch between inputs. Remote ImGui was designed differently, though. The game was the server and the client was connecting from the browser. This probably made it easy to switch input and control canvas size to match whatever game needs as it was already in the same place.

First hackish test done, and we have a communications.

This only send the content of Context 0 and still use the Windows networking code. I'll spend some time this weekend to make a UE4 netImgui plugin that UnrealImgui plugin can use. I have a good amount of experience of low level Unreal graphcis programming, but not so much with the higher level / plugin things. So I have to figure things out as I go.
I figure that I'll create a netImgui plugin with the needed functionalities and basic integration in UnrealImgui, and afterward, I can let you figure out the details how how to expose things in your plugin (like connections settings and such).

Nice. And whatever you feel makes more sense. And sure, I will be happy to help finalising it. Not sure how much or little plugin experience you have, but if anything ask and if I know I will surely share. I have some experience although it has its limits :)
You have a choice between making a separate plugin, adding a separate module or building it with the same module - whatever is more convenient. Separate plugin might be easier to isolate, if that is preferred.
Now, I don't fully remember but I think that when use a separate plugin approach, you will need to specify a dependency in the ImGui.uplugin file. My problem with those files is that settings cannot be express dynamically, like based on the engine version or "If found that directory or plugin then enable that and that". For instance, I have this problem with the module type. 4.24 or 4.25 depreciated the "Developer" module type and introduced "DeveloperTool", I would like to switch between them depending on the engine version but this is not possible. So I opted for the old name, since it is still supported. But you get a warning what some people already raised.

I have a prototype working that you can take a look at (it's the source code that goes under "ImGui\Source"). I had to make a few small changes to netImgui and it's all good.
For the moment, everything is compiled inside your plugin, until I figure out what I want to do with the netImgui code. I can make a pull request after that. The changes to your plugin (not too many) can be found when searching NETIMGUI_ENABLED. You need to run the netImgui server and add 2 client config on localhost port 8889 and 8890.
I basically copied your sample  to create my test scene. Because the plugin relies on World::Tick() for refreshing, Editor ImGui is only updated when in PIE and with a low refresh rate. The game works fine though. I was wondering if ImGui refresh could rely on something else instead, to update more frequently in editor?
ImGui.zip

Yes, I see it working :)
About the refresh rate. Do you mean the reduced refresh rate when leaving the editor to debug remotely? Because there is a parameter for that: "Less CPU when in Background". We used to recommend to turn it off when using Remote ImGui. I used to keep it off in my work and only got reminded now when I tested your plugin. I'd put that in the readme and I think it is a fair requirement for what you get. The plugin relies on world tick, so all game object can send their data from their tick functions. If it wasn't synced, I think it would not work correctly.
I never made any proper examples project but I showed an exemplary class AImGuiDebugOrderTest in this thread there's any example to start with this? It is a bit outdated but it shows the main point. Debug from AImGuiDebugOrderTest::ImGuiTick() and AImGuiDebugOrderTest::ImGuiMultiContextTick() would always work (because delegates could be called accordingly) but I'm pretty sure that the debug from AImGuiDebugOrderTest::Tick(float) wouldn't. Another reason why I have the debug synced with the world tick is that I used to rely on that when recording behaviour of our systems depending on physics or animation. There was always this one to one parity.
Finally, the one thing I would be a little cautious about or maybe reluctant, is this:
PCHUsage = PCHUsageMode.NoPCHs;

I think that there is a way around this but first the problems:
One thing is that it breaks the compatibility with anything older than 4.22. Yes, it is old enough but I remember some people fixing issues to have the plugin working with a few versions back to whatever was supported. My current company uses 4.22 so we are on the edge. Another thing is that I'm not sure how that works when compiling it as the engine plugin as they recommend using PCHUsageMode.UseExplicitOrSharedPCHs to work correctly with IWUY.
To avoid modifying ImGui files, I put them in the separate directory ThirdPart/ImGuiLibrary, and then in the plugin's private directory, I added ImGuiImplementation.h and .cpp. This may be not the most elegant but it allows adding all the necessary includes wrappers, etc. without touching the original files. In my opinion, this also makes easier upgrading as it isolates ImGui source. And as a bonus, ImGui credits and license get good visibility. And when the Unreal changes its requirements, the implementation file is one to edit. Additionally, you can use NETIMGUI_ENABLED to completely wipe out that part if it is disabled. On the downside, you need to manually include all necessary cpps but this is something I can live with that.

About the refresh rate. ... for that in the Editor Preferences -> General - Performance: "Less CPU".

That was it, good to know. We could also turn that off automatically when connecting, or offer a toggle option directly in the
netImgui menu options (alongside the Context switch).

The plugin relies on the world tick

At my previous company, we had integreated ImGui as part of the update loop (directly in engine code) and we were updating it per View, not per World. In any case, there seem to be 1 problem to fix, when I switch active Context from 'Editor' to 'PIE', netImgui stops refreshing (when not running PIE, makes sens). Will have to force a NewFrame/EndFrame if world is disabled, when drawing the MainMenu bar for context switch.

Finally, the one thing that I would be a little cautious about or maybe reluctant, is this: PCHUsage = PCHUsageMode.NoPCHs;

Good to know, I did that change quickly so things work, without worrying of side effect at this point. I'll probably move my plugin to work like ImGui. When I first started, I didn't understand what was going on with the Imgui module :) It was a separate compile entry, but there was no source files! When trying the same thing with netImgui, shockingly, it was missing symbols. I don't like having to manually include each file, but I like even less having to edit the sources files, so I might skip plugin approach and duplicate your Dear ImGui source code approach.

At my previous company, we had integreated ImGui as part of the update loop (directly in engine code)
I see. Don't think it is possible from plugin though.

and we were updating it per View, not per World.
Yeah, that can work. Did it work with the debugging code from Tick functions? It was a goal of mine to allow that and I would think that ImGui and game frames need to be in sync for that to work.

there seem to be 1 problem to fix
I'm not sure if I fully understood the problem here (I'll try to look at this when looking at the pull request) but yes, updating frame for otherwise inactive contexts should not be a problem. The manager needs some cleanup anyway, so it can be handled. I can also look at this. On a side note, I'm not sure whether the editor context is really needed. I've added that because without having some default instance that could be used in absence of other contexts, there was always somebody trying to call ImGui API in some weird places or states and than coming and asking why is he getting a crash ;) So I just added that as a backup to guarantee that there is always some context to draw to. I don't fully remember whether this is needed for something else as it did evolve over time a bit and it was a while ago.

We could also turn that off automatically when connecting
Not sure how to do it, but yes that could be an option.

Thanks for that pull request. If you don't mind I'll take a look and take it for a test run later today or tomorrow if today proves impossible. But of course it will be merged. Is the default "squash and merge" fine? Any other questions will continue in that request thread.

Yeah, that can work. Did it work with the debugging code from Tick functions? It was a goal of mine to allow that and I would think that ImGui and game frames need to be in sync for that to work.

The ImGui drawing were only allowed from callback functions, so no Tick :) I should have been possible though, by always having a Context open for draw instead of our Begin -> Callback -> End setup.

I'm not sure if I fully understood the problem here

I already fixed that problem before creating the pull request. The things left are in the description of the pull.

Is the default "squash and merge" fine? Any other questions will continue in that request thread.

Good and good. I am not well verse in Git, beyond using it mostly like I use Perforce, so feel free to take the approach you want for the merge. It's only 2 submits (main submit + fix) so, I think it's better to squash like you mentionned.

Current integration thanks to @sammyfreg is in the net_imgui branch. It will be merged into master but anybody interested can give it already a test.

Hey :D Do you plan with net_imgui to also support dedicated servers?

Hey :D Do you plan with net_imgui to also support dedicated servers?

What do you mean by 'dedicated server' ? NetImgui was designed to have Dear ImGui run in your code (in this case, under Unreal) with the Server application running on your PC, controling and displaying the UI locally.

What do you mean by 'dedicated server' ? NetImgui was designed to have Dear ImGui run in your code (in this case, under Unreal) with the Server application running on your PC, controling and displaying the UI locally.

I mean that right now you need slate to have ImGui running. What I am talking about is having ImGui working for Unreals Dedicated servers e.g. for a commandline exe (no rendering) for multiplayer games. this way you could also show data on the server without the need of using the Gameplaydebugger to send this data to the clients.

I mean that right now you need slate to have ImGui running. What I am talking about is having ImGui working for Unreals Dedicated servers e.g. for a commandline exe (no rendering) for multiplayer games. this way you could also show data on the server without the need of using the Gameplaydebugger to send this data to the clients.

Ah, I understand.
After integrating NetImgui to this excellent UnrealImgui plugin, I created a new standalone one : UnrealNetImgui. It's a barebone Dear ImGui implementation without local rendering. I will be updating the plugin in the upcoming weeks, after a big Server refactor, but it should still be working.

Ah, I understand.
After integrating NetImgui to this excellent UnrealImgui plugin, I created a new standalone one : UnrealNetImgui. It's a barebone Dear ImGui implementation without local rendering. I will be updating the plugin in the upcoming weeks, after a big Server refactor, but it should still be working.

Nice, I'll have a look, thx!

Nice, I'll have a look, thx!

I haven't tried it in a 'Dedicated Server', let me know if there's some issue. It might not correctly detect the end of a frame.

I haven't tried it in a 'Dedicated Server', let me know if there's some issue. It might not correctly detect the end of a frame.

Alright, will do that, but most likely won't have time for that today :( maybe tomorrow

Alright, will do that, but most likely won't have time for that today :( maybe tomorrow

XD I took a code snipped from your repo, basically FNetImguiModule::StartupModule where you build the fonts etc. add this there where this plugin loads the textures and by disabling code that requires Slate, if we are on a dedicated server and changing GFrameNumber to GFrameCounter it works xD

XD I took a code snipped from your repo, basically FNetImguiModule::StartupModule where you build the fonts etc. add this there where this plugin loads the textures and by disabling code that requires Slate, if we are on a dedicated server and changing GFrameNumber to GFrameCounter it works xD

Nice!
If you have some questions / problems, you can open a ticket in the UnrealNetImgui Github project.

Nice!
If you have some questions / problems, you can open a ticket in the UnrealNetImgui Github project.

I recently updated NetImgui / UnrealNetImgui and was planning to do the same to this plugin next. I was wondering if you'd like me to also bring in Dear ImGui 1.80 in the netimgui branch?

I recently updated NetImgui / UnrealNetImgui and was planning to do the same to this plugin next. I was wondering if you'd like me to also bring in Dear ImGui 1.80 in the netimgui branch?

@sammyfreg Do you have any plans to upgrade this branch to NetImgui 1.5? I tried to compile the NetImgui 1.5 Server but I can’t connect to the editor, I need change source code to support 32-bit vertex indices.

I'll try to take a look this weekend. Shouldn't be too hard.
On Wed., Jul. 14, 2021, 14:13 Eragon-Brisingr @.***>
wrote:

@sammyfreg https://github.com/sammyfreg Do you have any plans to
upgrade this branch to NetImgui 1.5? I tried to compile the NetImgui 1.5
Server but I can’t connect to the editor, I need change source code to
support 32-bit vertex indices.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/segross/UnrealImGui/issues/28#issuecomment-879596591,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AESBPY6UPGMTUF7MWTCNJ2LTXUMFZANCNFSM4MICRHDQ
.

I'll try to take a look this weekend. Shouldn't be too hard.
…
On Wed., Jul. 14, 2021, 14:13 Eragon-Brisingr @.***> wrote: @sammyfreg https://github.com/sammyfreg Do you have any plans to upgrade this branch to NetImgui 1.5? I tried to compile the NetImgui 1.5 Server but I can’t connect to the editor, I need change source code to support 32-bit vertex indices. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AESBPY6UPGMTUF7MWTCNJ2LTXUMFZANCNFSM4MICRHDQ .

That's great, Thank you for this amazing NetImgui!

Pull request #53 as been created with the update

Pull request #53 as been created with the update

Nice! Thank you~

Hello, thanks so much for these plugins!
FYI Anyone who'd like to connect multiple clients, just modify this to add a custom port by commandline:
else if (FApp::IsGame())
{
uint32 CustomPort;
if (FParse::Value(FCommandLine::Get(), TEXT("imguiport"), CustomPort))
{
return CustomPort;
}
return NETIMGUI_LISTENPORT_GAME;
}
And start your game with -imguiport 8895 or something, then configure the server for a second game on that port :)

Quick question, hopefully devs are still active. I have the net_imgui branch integrated into our project, and it works perfectly with the out of the box netImguiServer.exe, but when I try compiling and making one from the https://github.com/sammyfreg/netImgui repo itself, I'm not getting connections. I copied the imgui.ini and netImgui.cfg files into the same directory as the newly generated NetImguiServer.exe but still had no luck. Any ideas on what could be going on? How did you generate the original netImguiServer.exe?

This should be easy to fix. The newer server is not compatible with he older client code. You will need to replace the client code in your branch.

Copy the client code in the package you downloaded, to UnrealImgui\Source\ThirdParty\NetImguiLibrary\Client.
Make a small change to UnrealImgui\Source\ImGui\Private\ThirdPartyBuildNetImgui.cpp (adding/removing a space is enough) so that the new code is detected properly and recompiled.
There might be a few API function differences that you need to fix, but nothing major

Note: The ImUnrealCommand code might also be a bit older (not needed for NetImgui update).

This is the code to have a GUI for the unreal console commands
You can get the latest version from https://github.com/sammyfreg/UnrealNetImgui.
The 2 files that need replacing are in UnrealImgui\Source\ThirdParty\ImUnrealConsole\Private

@sammyfreg @segross I know you'll have regular day jobs and regular things to do but as a community member I value what you have done here with UnrealImgui and NetImgui.
Now I come bearing some ideas, which kind of goes against what ya'll have done thus far.
I my previous company IMGUI used to render in the web and I would connect to a port and the web would render the game's UI.
This was far easier than having a standalone app and allowed me to look at debug data regardless of platform. I just need the IP and a browser.
I already made changes to @segross 's UnrealImgui app to allow this to work and it works as a proof of concept but I have some remaining issues to figure out.
https://github.com/Eragon-Brisingr/ImGui_WS
Does exactly this and I have ported that code using unreal websockets and layered it into Sebastian's system.


Update comments on post_gen_project and models.py

ruff . no longer works, Ruff recommends that you use ruff check .. For models.py, I switched the from nautobot.extras.utils import extras_features to use the public nautobot.apps imports instead.

ChatOps cookie has its own post-gen file, would you please update that as well?
And check if models.py needs changing in ssot/chatops templates too.

ChatOps cookie has its own post-gen file, would you please update that as well?
And check if models.py needs changing in ssot/chatops templates too.

None of them were exactly the same. 😄

ChatOps cookie has its own post-gen file, would you please update that as well?
And check if models.py needs changing in ssot/chatops templates too.

The spot post-get and the models.py from both slot/chatops are symlinks to the Nautobot-app. I did update the post-get for champs though.


can someone please explain what's the meaning of waypoint.below

 onEnter({previousPosition, currentPosition}){
if(previousPosition === Waypoint.below){
 this.setState({
 isInView : true
 });
 }
}`
I have this code and I'm trying to understand...
previousPosition === Waypoint.below
this part. When I log it to the console, it just prints 'below' any explanations, please? Thanks

When the waypoint is below the visible portion of the page and you scroll down so that the waypoint is now visible, then onEnter will be called with previousPosition === ’below’. Waypoint.below is a constant you can use in order to avoid using the string ”below”.


chore(update): missing bug_report and feature request template

Need?

Important according to OSS guidelines.
Help maintainer to differentiate a bug feature, feature(already included in the project)

Hey Maintainer!
I want to work on creating an effective template for bug and feature requests.
Please assign me the task. (For GGSOC'21)

@Uyadav207 Go for it.

@gauravdas014 Thanks

hello
i'm taking part in gssoc 2021. And i would like work on this issue, will you please assign this to me?

hello
i'm taking part in gssoc 2021. And i would like work on this issue, will you please assign this to me?

@amritakesh This is no more an issue now... The required PR has been already merged... Please try out some other issue... to contribute on.


Fixed login page for mobile screen

Adujsted the padding and margin to have a uniform look in full as well as Mobile screen.

@Utsavladia mention the issue number which you are resolving.

sure,
Added issue no: #509


Cached credentials are not checked when in legacy mode

After following kube config the conversion script I have updated kubeconfig:
user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - get-token
      - --environment
      - AzurePublicCloud
      - --server-id
      - xxx
      - --client-id
      - xxx
      - --tenant-id
      - xxx
      - --legacy
      command: kubelogin
      env: null

After running a kubectl command and confirming my identity I have credentials stored in ~/.kube/cache/kubelogin/azure.json.
When I tried to run another kubectl command and it asked me to confirm my identity again.
I tried to not use --legacy and authenticate again and I got from k8s api server (obviously non-legacy type of credentials is not accepted):
error: You must be logged in to the server (the server has asked for the client to provide credentials)

When I tried to switch back to --legacy and still got the same error message.
The error disappeared when I cleared the cache and reauthenticated but I was back to having to authenticate every kubectl execution.

thanks for reporting!


Device prompt clarification

Hi,
Just looking for clarification on this paragraph:
"On Azure AD registered Windows devices sign in to the device is considered a prompt. For example, if you have configured the Sign in frequency to 24 hours for Office apps, users on Azure AD registered Windows devices will satisfy the Sign in frequency policy by signing in to the device and will be not prompted again when opening Office apps."
If users are locking devices each night, rather than logging out, does Azure AD see the unlock event as a sign in?

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

ID: 9561a367-20d8-62e9-57e5-694bab4c0878
Version Independent ID: a7c757e0-052b-fc42-70c5-030081baa573
Content: Configure authentication session management with Azure Active Directory conditional access
Content Source: articles/active-directory/conditional-access/howto-conditional-access-session-lifetime.md
Service: active-directory
Sub-service: conditional-access
GitHub Login: @MicrosoftGuyJFlo
Microsoft Alias: joflore

@frobnitzz Thank you for your query. We will investigate and update this thread.

@frobnitzz If you configure the frequency to 24 hours then they will be prompted for signing in again only if they are inactive for 24 hours or more.
So if the users lock the device for more than 24 hours then they will be prompted for signing in again.

@frobnitzz We have not heard from you in a while.We will now proceed to close this thread. If you have further questions, please tag me in the comments and I will gladly continue the conversation.


Scan subcommands into a given package or based on an Interface.

I've been using picocli for a while and it's great!
Today, I'm faced with the problem of building a package of command/subcommands, which could be extended with subcommands (even in separated jars). This is a use case where having to list all the possible subcommands explicitly isn't very practical, it would be much better if I could tell @Command to pick all subcommands by scanning a package, and/or considering implementations of a given interface.
At the moment, something similar could be done by combining picocli with either Spring's IoC, or the good old SPI API. In either case, having this feature implemented directly in picocli would make things easier.

Hi @marco-brandizi, glad you like picocli!
About your proposal that picocli should provide a classpath scanning feature to auto-discover commands, I am not sure I understand how you envision this to work.
A picocli command hierarchy is a tree structure with a single top-level command at the root. Scanning the classpath would result in finding multiple commands, without details on where these commands should be connected into the tree. They may be subcommands of the root command, or sub-subcommands or sub-sub-subcommands etc.
Somewhere, there needs to be information provided on how to connect a command into the hierarchy.
In picocli, building a command hierarchy can be done statically via the annotations api: @Command(subcommands = {A.class, B.class}), or dynamically via the programmatic API with CommandLine.addSubcommand.
May I suggest that you create the classpath-scanning logic for your application, and use picocli's programmatic API to create the command hierarchy?
Once you have it working for your application we may be in a better position to discuss the pros/cons trade-offs of pulling this logic into the library.
What do you think?

Hi @remkop, thanks for the answer. Do you mean that, if I declare subcommand=Root.class, the command will have Root and all its descendants as subcommands? Would this include descendants in jars other that the one where Root (and the embedding command) is? That is, does the existing mechanism support extensions?
If yes, it already has what I was thinking about, else, I was thinking of telling the main command the packages (eg, com.foo.cli.*) where to to look for subcommand classes (ie, classes annotated with @Command), possibly with the addition of a super-class or super-interface filter.
Spring works this way.
The main reason for doing this, apart from saving from writing a few annotations, is the possibility to add subcommands to an existing package without having to change the latter (ie, open/closed principle).

Do you mean that, if I declare subcommand=Root.class, the command will have Root and all its descendants as subcommands?

No, sorry if I caused any confusion.  Only the specified class or classes in @Command(subcommands = {A.class, B.class}) class X would be subcommands of X.

Would this include descendants in jars other that the one where Root (and the embedding command) is?

When using the @Command(subcommands = A.class) API, picocli may need to create an instance of A, so A needs to be on the classpath. Java does not care whether A lives in another jar, as long as it is on the classpath.

That is, does the existing mechanism support extensions?

I am guessing picocli currently does not do what you have in mind. :-)
To clarify:

If all the subcommands for your command are known in advance, then you can use the annotations API.

If the subcommands are not all known in advance, and your application is discovering them dynamically in some way, then you can use the programmatic API with CommandLine.addSubcommand to construct the command hierarchy.

How your application discovers subcommands is completely up to you. Classpath scanning, config files, downloading from another server, the possibilities are endless. There is no limit other than your imagination! :-)
My suggestion is that you build, in your application, the logic for discovering commands. You can use classpath scanning for the @Command annotation, or design some other mechanism. (I have other commitments and I will not be able to help you with this.)
Once you have this working we will have a lot more concrete knowledge and we will be in a better position to discuss the pros/cons trade-offs of pulling this logic into the library.

Thanks, very useful clarifications! For the moment, it's likely I'll go with manual annotations.
For a future improvement, I'm thinking of integrating Spring (to scan all the subcommands from a package and/or root interface specification) and programmatic subcommand addition, after they're discovered.
If and when I develop this, I'll write an independent/reusable component, that could be considered as a picocli extension (likely, I'll initially put in in my own toolbox library :-)). Possibly, I'll let you know!

Sounds like a plan! 👍
Enjoy!

Closing this ticket for now. Feel free to reopen or open another one at any time.


aysnc serialization, compatible with futures-rs

Using #42 as a starting point, adds serialize::read_message_async() and serialize::write_message_async(). These functions return a value that represents the in-progress I/O operation and can be driven to completion through the poll() method.
Adds an optional dependency on futures-rs and implements futures::Future for the new in-progress I/O operations.
Modifies the existing serialize::read_message() and serialize::write_message() functions to use the new hand-rolled state machines under the hood. This appears to have negligible effect on performance.

I've moved the new async functions into their own module, serialize_async, and I've reverted to using the existing serialize implementation in the blocking case.

I've decided that this code belongs in its own crate. Hence: https://github.com/dwrensha/capnp-futures-rs