Make category search non case-sensitive and more user friendly

Received a report from a 2.11 user on our FB page that category search is case-sensitive for her, which means that sometimes she'll type the right category in the search field but nothing will show up.
AFAIK the MW API that we use is inherently case-sensitive, but the upload wizard seems to be able to find a way around that and produces the same category suggestions regardless of case.

Edit: Apart from the case sensitivity, the allcategories API also has a problem of doing a prefix match. This does not give a great UX. We should explore ways to fix this too.

Maybe if we convert everything to lowercase then the server performs a non-case-sensitive search? That's just an hypothesis, I have not tried.

@nicolas-raoul Possible! We'll try it out with a direct query first.

Can I take this issue?

@ankit-kumar-dwivedi please feel free!

@misaochan Is this issue free to be worked upon? if so can i take it?

Hey! Yes sure you should start working on it as I'm not working on it right
now.
On Sun, Jan 12, 2020, 7:21 PM Kshitij Bhardwaj<EMAIL_ADDRESS>wrote:

@misaochan https://github.com/misaochan Is this issue free to be worked
upon? if so can i take it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/commons-app/apps-android-commons/issues/3179?email_source=notifications&email_token=AI7ACH2SIIJZ5DQVUZWKGVDQ5MN6ZA5CNFSM4JBW444KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIW2OWQ#issuecomment-573417306,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI7ACHYZUMAZFWYYVHDK77LQ5MN6ZANCNFSM4JBW444A
.

Thank you:)

I'm re-opening this as I believe there's a problem with how this issue was fixed.
@kbhardwaj123 Can you clarify a doubt that I have regarding your PR #3326? In the description you say:

Tested from the MW api fuzzy search url that the category suggestions would deliver the desired results no matter what case you sent in the api call so to fix the issue api call has been converted to lower case.

Are you sure the API really doesn't care about the case of the category name given to it? I'm doubtful about that for several reasons. Here are a couple:

The logical one: If the API really doesn't care about the case of the search text sent to it, this issue shouldn't exist to begin with. Right? IOW, if the API is returning us all categories that match a search text despite the case in which we send the query, then there's no point in just lower-casing the search text we send to the API. Got my point? But the mere existence of this issue indicates otherwise. Correct me if I'm missing something.
The practical one: I just checked with a couple of API calls and I get different results based on the case of the search text I send to the query. Here are a couple of queries which return different results despite only the case of the search text differing:

https://commons.wikimedia.org/w/api.php?action=query&format=json&formatversion=2&generator=allcategories&gacprefix=covid&gaclimit=25&gacoffset=0
https://commons.wikimedia.org/w/api.php?action=query&format=json&formatversion=2&generator=allcategories&gacprefix=COVID&gaclimit=25&gacoffset=0

In case you're wondering why your test case didn't fail. Here's the catch:

The page title is case-sensitive except the first character.

From Manual:Page title - MediaWiki
I think the quote speaks for itself. I'll share the actual problem w.r.t to the app in the next comment.

@sivaraam while I was working on this I went with what @nicolas-raoul suggested so I made all the category strings being passed to the OkHttpClient are converted to lower case and I wrote new tests regarding that and they worked fine but I guess I must have missed something I will take a look at at again

Ok. Here's the issue with the respect to the app. Now category search doesn't return any categories that have a upper case character in it (other than the first one, of course). See #3582 for proof.
In case the issue is not clear to you from #3582, here's another example.
Here's what I get when I search for categories with "COVID" (mind the case) in the app (version: <IP_ADDRESS>9~a63a358):

Now, consider the linked example query which returns 25 categories which have "COVID" as it's prefix. Here are the categories that the query returns:
Category:COVID-19 guidelines in Brazil
Category:COVID-19 guidelines in Argentina
Category:COVID-19 guidelines in Albania
Category:COVID-19
Category:COVID-19 guidelines by country
Category:COVID-19 guidelines in Czechia
Category:COVID-19 guidelines
Category:COVID-19 guidelines in Denmark
Category:COVID-19 guidelines in Esperanto
Category:COVID-19 Clinical Cohort Research Conference, March 18, 2019, National Medical Center, Republic of Korea
Category:COVID-19 coronavirus
Category:COVID-19 guidelines by language
Category:COVID-19 guidelines in Arabic
Category:COVID-19 guidelines in English
Category:COVID-19 guidelines in Basque
Category:COVID-19 guidelines in China
Category:COVID-19 guidelines in Estonian
Category:COVID-19 guidelines in Bengali
Category:COVID-19 guidelines in Bangladesh
Category:COVID-19 guideline cartoons by Anika Nawar Eeha and Abdullah Al Mamun in Bengali
Category:COVID-19 guidelines in Bengali by Anika Nawar Eeha and Abdullah Al Mamun
Category:COVID-19 guidelines in Catalan
Category:COVID-19 guidelines in East Timor
Category:COVID-19 DIY
Category:COVID-19 guidelines in Breton

As you can see, none of the above categories are shown in the query result. Thus the issue.

@misaochan Given that we've now accidentally reduced the category search space rather than increasing it, you might want to ensure we fix this before releasing the next version.
As it's not clear, I thi

Added to the release list, thanks for the heads up!

Hi @kbhardwaj123 , are you currently still working on this? Please do keep us updated, thanks!

@misaochan sure I'm on will update ASAP

Thanks @kbhardwaj123 ! As we are planning to include this in v2.13, when you submit your PR could you please rebase and submit it on the 2.13-release branch? Thanks!

@misaochan oh thanks for pointing that out

I investigated about the problem and here are my findings.

thanks @sivaraam for such in depth details, you are right the API is indeed case sensitive
We have 2 search options available at our disposal we can search by prefix or we can use the normal search (in between search, is case-insensitive)

So Suppose I want to find the category Temple of Ishtar at Mari by entering temple of ishtar
these are the results using

using generator=allcategories  in the url API result which apparently is for prefix search and is case-sensitive
using generator=search in the url we get API result which is case in-sensitive and that's what we need.

Now on reading the logs i realized that the method searchAll() in CategoriesModel was calling for prefix search and that right there is where the problem is, so i when i fix that by calling both prefix and search API and combining the result we finally get a case insensitive search.
But there's a catch
We are using the beta flavor of the APIs which give the following results

prefix result API Link which doesn't give the required result category (this was expected)
search result API result, now here we expected Temple of Ishtar at Mari right? but it seems like the beta flavor of the API is unable to give the required result

Possible Solution
AFAIK there are two ways

(efficient)Use the production version of the commons api which are capable of delivering case-insensitive results by themselves
Or make multiple API calls to the existing API by manipulating the search string

@misaochan @sivaraam @nicolas-raoul @maskaravivek I need your opinions on my investigation on this to fix it for v2.13 i mean are we going to use the production flavor of the APIs in v2.13

@kbhardwaj123 Thanks for the analysis. I'll look into it and respond share my comments soon. I have a quick doubt about one particular thing:

We are using the beta flavor of the APIs which give the following results

What do you mean by beta flavor of API? Do you mean the API hosted in the beta server (https://commons.wikimedia.beta.wmflabs.org/w/api.php) as opposed to the production server (https://commons.wikimedia.org/w/api.php)?

For category search (and really any testing that does not involve actually uploading), please use the prodDebug flavor of the app. The beta server is unusable for most testing.

@sivaraam yes that's exactly what i meant the API hosted on beta server https://commons.wikimedia.beta.wmflabs.org/w/api.php has server API but it is unable to give the required result where as the production API https://commons.wikimedia.org/w/api.php gives the expected result as shown bu the links in by previous comment.
@nicolas-raoul does prodDebug flavor use https://commons.wikimedia.org/w/api.php APIs ?

@kbhardwaj123 Yes, prod* flavors use the production APIs, for instance https://commons.wikimedia.org/w/api.php . Sorry that our beta servers are not representative of production :'-(

@nicolas-raoul sure then the problem is solved already, I will create the pull request

@sivaraam yes that's exactly what i meant

Thanks for the clarification.

... the API hosted on beta server commons.wikimedia.beta.wmflabs.org/w/api.php has server API but it is unable to give the required result where as the production API commons.wikimedia.org/w/api.php gives the expected result as shown bu the links in by previous comment.

Let me now clarify something. The API hosted in the beta servers and the production servers would not differ in a functional manner. I'm glossing over a little but I believe it's fine for the case in question. You see different results when you use the beta server only because all the categories present that are present in the prod server are not present in the beta server. So, forget the fact that the APIs in the production servers are case-sensitive and the APIs in the beta servers are not, because both of them behave the same way. You can read more about the beta cluster in the following wiki page: Beta Cluster - MediaWiki

@nicolas-raoul sure then the problem is solved already, I will create the pull request

Can you explain how you're going to fix this? I'm asking this to ensure everyone's on the same page. Also, I would suggest you to not rush this. I say this because making the category search case insensitive seems to be a lot complicated than it seems. It's better to know our options and choose the most appropriate one. If we have the release coming up soon soon we can always just revert the changes done in PR #3326 (which we would have to do anyway) and move with the release. We can then make the change after that.

You see different results when you use the beta server only because all the categories present that are present in the prod server are not present in the beta server. So, forget the fact that the APIs in the production servers are case-sensitive and the APIs in the beta servers are not, because both of them behave the same way.

Ok. Here's a proof for the fact that the Beta server behaves just the same way as the production server.
https://commons.wikimedia.beta.wmflabs.org/w/api.php?action=query&format=json&formatversion=2&generator=search&gsrnamespace=14&gsrsearch=testcat&gsrlimit=25&gsroffset=0
This returns the Category:TestCat despite the search term being testcat. So, the beta server's generator=search is case-insensitive too.

Let me now clarify something. The API hosted in the beta servers and the production servers would not differ in a functional manner. I'm glossing over a little but I believe it's fine for the case in question. You see different results when you use the beta server only because all the categories present that are present in the prod server are not present in the beta server. So, forget the fact that the APIs in the production servers are case-sensitive and the APIs in the beta servers are not, because both of them behave the same way. You can read more about the beta cluster in the following wiki page: Beta Cluster - MediaWiki

@sivaraam initially what i meant was that since beta servers don't have all the categories ( the working of both APIs is same that was clear from their documentation) this is what i wanted to show:
Suppose i want category Temple of Ishtar at Mari by typing temple of ishtar only
If the prodDebug APIs are used they give what one expects:

with generator = allcategories result it doesn't give the required category because it has prefix only search

with generator = search result gives the required category due to it's case insensitivity

But the beta servers have a problem which is that they contain the category Temple of Ishtar at Mari using generator=allcategories see here but The generator=search is incapable of returning the category when provide it with temple of ishtar see here
Comprehensively the results displayed by the beta server's case sensitive API (generator=allcategories) is delivering a category which the case-insensitive API is not able to return and **no such problem is there in the prodDebug APIs

How i intend to solve this is that the searchAll method is the one at fault here, it only calls the prefixSearch API for searching categories so we we make a call using generator=search and combine both prefix and normal search results our problem would be solved.
And yes we need to use the prodDebug APIs because of the point i just mentioned above.

@sivaraam yes i agree that the beta ones are case insensitive but they don't seem to return Category: Temple of Ishtar at Mari (using generator=search) while the case insensitive beta API (generator=allcategories) return the category see result

So i implemented the solution and with the beta server's APIs and this is how it looks with screenshots
using category suggested by @sivaraam Category:TestCat

Now with Category:Temple of Ishtar at Mari (here i am showing that it exists on beta server):

But from the following screenshot it is visible that generator=search doesn't return that which leaves this category as case sensitive

And as soon as i change the flavor of the APIs to prodDebug all these problems dissappear

@kbhardwaj123 Thanks for your explanations. I see your problem now.

But from the following screenshot it is visible that generator=search doesn't return that which leaves this category as case sensitive

It's prudent to explore more before coming to conclusions. AFAIK, you can't just make some categories case sensitive and others case insensitive. It doesn't even make any sense, does it? Anyways, I'll try to clarify what's going on here. Here's the description of the search API from API:Search - MediaWiki [emphasis mine]:

GET request to search for a title or text in a wiki.

Just assume the search API does not search for the titles for now, I'll come back to the why such an assumption? later. Note that the search API looks for the text in the wiki pages. So, any query you send to generator=search looks for the search text in the contents of the wiki page (the category pages are the wiki pages, in our case). So, the results you get in the beta and production server depend not just on the presence of the categories it also are based on what content is present in the category pages. Let's take your case of the "Category:Temple of Ishtar at Mari".

Category:Temple of Ishtar at Mari - Wikimedia Commons
This is the category page in the production server. As you can see the category page has content such as info boxes which has your search text "temple of Ishtar". This could have been the reason for that category to be included in the your API query to the production server: query link.
Also, the fact that the search API searches the content is very clear from the results of the above query which include categories such as Category:Astarte (goddess), Category:Passing lion Babylon (Louvre, AO21118)

Category:Temple of Ishtar at Mari - Wikimedia Commons BETA
This is the category page in the beta server. Don't get tricked on seeing the 'Media in category "Temple of Ishtar at Mari"' and presume it's text present in that category page. It's a standard section shown for all category pages showcasing the pictures that belong to that category. The category page itself doesn't exist yet. So, no wonder the search query you sent to the beta cluster didn't return this category as a result: query link.

I'm not very sure about how/why a page is included in the result as the algorithm seems to be more involved. Relevant quote from the "Additional notes" section in API:Search page page:

Depending on which search backend is in use, how srsearch is interpreted may vary. On Wikimedia wikis which use CirrusSearch, see Help:CirrusSearch for information about the search syntax.

Coming to the why assume search API doesn't search the title part. Try the following query:
https://commons.wikimedia.org/w/api.php?action=query&format=json&formatversion=2&generator=search&gsrnamespace=14&gsrsearch=temple of ishtar&gsrlimit=25&gsroffset=0&gsrwhat=title
I've just added gsrwhat=title to the query which tells it to search just the title. As you can see it would clearly say: "title" search is disabled.. Thus my assumption. See also: https://stackoverflow.com/q/14337219/5614968
I hope I've clarified your confusion about beta server not returning the results you expect, now. Let me know if I have not.
To conclude, the search API does more than what's needed (a category title search) and particularly doesn't seem to be searching the title at all. I don't think that would be a good choice. So, as I mentioned earlier we'll have to explore the proper way to achieve a case insensitive search. Here are a couple of related API pages:

API:All search modules - MediaWiki
API:Search and discovery - MediaWiki

Also, I believe we could ask the wikitech-l mailing list about this.

@sivaraam Thanks for such a comprehensive explanation :).
I agree with you that search generator could be an overkill as you pointed out that searching temple of ishtar returns some completely unrelated categories as they contain that term in their wiki text body. So what i am thinking is that in the question on stackoverflow which you mentioned one person gave a workaround of using intitle as:
srsearch=intitle:temple%20of%20ishtar
could solve our issue and return only those categories with the required search term.
Kindly give your opinions on this

@sivaraam i tried it and it returns exactly what we want, checkout the following link:
https://commons.wikimedia.org/w/api.php?action=query&format=json&formatversion=2&generator=search&gsrnamespace=14&gsrsearch=intitle:temple of ishtar&gsrlimit=25&gsroffset=0

The search URL above looks better than what we currently have indeed, but still not perfect, I think Commons has a better one for us.
Users will type and should see results appear as they type.
For instance, let's say I take a picture of a supermarket in Tokyo. I start typing "supermarkets in to"

https://commons.wikimedia.org/w/api.php?action=query&format=json&formatversion=2&generator=search&gsrnamespace=14&gsrsearch=intitle:supermarkets in t&gsrlimit=25&gsroffset=0 does not return https://commons.wikimedia.org/wiki/Category:Supermarkets_in_Tokyo
On the opposite, https://commons.wikimedia.org/wiki/Category:Supermarkets_in_Tokyo is found by the search box at the upper-right of https://commons.wikimedia.org/wiki/Main_Page :

How about using the API that sits behind that website search box? Is there any reason why it is not good enough?

If the category search should be restricted to title (of it's wiki) only

In a word: yes. It's best to keep the search title only to ensure that the results are predictable. Searching the text in the category pages is not a good idea as it might contain

I need opinions on: If the category search should be restricted to title (of it's wiki) only

In a word: yes. It's best to keep the search title only to ensure that the results are predictable and straightforward. Also, it's out of scope for this issue which is about making category search case insensitive. We can discuss enhancing the category search separately and focus on just making the category title search case insensitive for now.

How about using the API that sits behind that website search box?

Good idea. We would have to find how it works.

Is there any reason why it is not good enough?

I think we can answer this only after knowing how that works :)

@sivaraam @nicolas-raoul so i will make it title only search and create a separate issue for improving our category search functionality in favour of something similar to that of website search

so i will make it title only search ...

If you think of using intitle: part of search API then here's a problem I noticed with that. It only seems to be returning category pages for which a category page exists (just as expected). Examples:

https://commons.m.wikimedia.beta.wmflabs.org/w/api.php?action=query&format=json&formatversion=2&generator=search&gsrnamespace=14&gsrsearch=intitle:temple of ishtar&gsrlimit=25&gsroffset=0
This query doesn't retMari](https://commons.wikimedia.beta.wmflabs.org/wiki/Category:Temple_of_Ishtar_at_Mari) which is a valid category in the beta server that should be returned.

https://commons.wikimedia.org/w/api.php?action=query&format=json&formatversion=2&generator=search&gsrnamespace=14&gsrsearch=intitle:rose factory&gsrlimit=25&gsroffset=0
This doesn't return the Category:"Rose" factory which is a valid category in the production server that should be returned. An incomprehensive list of such categories could be found at Special:WantedCategories.

This might not be a problem if we use the results of the generator=search API as a supplement the results supplement to the results from the allcategories API (which does not have such a problem). But I just wonder if there is a better way to properly achieve this case insensitive category title search. That's why I was suggesting that we ask the wikitech-l mailing list. We could get a reliable answer of how to go about doing this.

@sivaraam sure in that case I agree that we should ask on the mail list, I will hold my PR on this issue

Any luck with the mailing list? We are holding 2.13 for this at the moment. :)

Any luck with the mailing list?

Apologies. I never got around to sending the e-mail to the mailing list. Got hung up with other things. I'll try to send it by tomorrow if no one else beats me to it :)

We are holding 2.13 for this at the moment. :)

You don't have to hold it anymore ;). I've create #3636 that reverts the changes done in the PR #3326. You merge that and move on with the release. We can handle the case insensitivity in the next release :)

@sivaraam i agree this would be our best option for now and i am really keen to see what mailing list would suggest regarding this issue :)

I did some searching and phabricator and came to know that case insensitive category title search is a long standing feature request that is yet to be addressed [ref 1] [ref 2]. The linked comment is a nice TL;DR of the status quo.
It seems we really can't use generator=search API for the reason outlined in the comment I referred to previously and another comment in the same ticket which I'm quoting here:

Is it not possible to use the article search engine with (invisible) category: prefix instead ?

Wouldn't that search for pages in the category namespace, rather than actual categories? Some categories don't have associated pages, and you can create pages in the category namespace for non-existent categories.

That's right. To add to that here's another reason for why search API is not a proper fit. There's something called hidden categories in Mediawiki (the wiki engine behind Commons). My understanding of them is that these hidden categories aren't meant to be added by users directly. An example of such a hidden category in Commons is Category:Uses of Wikidata Infobox - Wikimedia Commons. There's a way to identify such hidden categories using the allcategories API while the search API doesn't have such an option. [side note: we should think about filtering away hidden categories before showing category suggestions. That's for another issue though :)]
Despite all this, I sent an e-mail to the mailing list just to confirm if my understanding is correct.
To conclude, it seems we really can't provide a case-insensitive category title search for now :(
What we could do is to mention about our category title search use case to the following phabricator ticket to clarify that category search is not as "niche" a feature as they think it is.
https://phabricator.wikimedia.org/T187342
That might help us get an API that we can use soon.

@sivaraam thanks for such elaborate insights :). I have a doubt regarding the linked comment which you mentioned, it says:

Our regular search feature (aka "prefix index"), used for the main search field and used for the input field when creating an article link, is case-insensitive in most cases

The "prefix index" which is being reffered here is it the allcategory API's prefix search, if so then how is it case-insensitive in most cases, i am a little confused by this

You don't have to hold it anymore ;). I've create #3636 that reverts the changes done in the PR #3326.

Awesome, thank you!

@sivaraam thanks for such elaborate insights :). I have a doubt regarding the linked comment which you mentioned, it says:

Our regular search feature (aka "prefix index"), used for the main search field and used for the input field when creating an article link, is case-insensitive in most cases

I would quote that fully to as it makes sense only when it is complete. Here it is for the sake of discussion:

Our regular search feature (aka "prefix index"), used for the main search field and used for the input field when creating an article link, is case-insensitive in most cases. On Wikimedia wikis this comes from CirrusSearch. On other wikis (and on WMF until recently) this was provided by the TitleKey extension. The search feature has a namespace filter as well. Which would allow us to do case-insensitive search of page titles in the Category namespace.

Read that fully before reading further.

The "prefix index" which is being reffered here is it the allcategory API's prefix search, if so then how is it case-insensitive in most cases, i am a little confused by this

I'm reasonably confident that the comment either refers to the [API:Prefixsearch - MediaWiki](https://www.mediawiki.org/wiki/API:Prefixsearch) API or someother API. It definitely is not referring to the allcategoriesAPI as it mentions a namespace filter which theallcategories` doesn't have (and doens't have any need for).
Hope that clarifies your doubt.

Despite all this, I sent an e-mail to the mailing list just to confirm if my understanding is correct.

And here's our confirmation of my observation:
https://lists.wikimedia.org/pipermail/wikitech-l/2020-April/093295.html

Re-opening as this issue seems to have been closed by mistake.

@sivaraam  This has been fixed via #3913. Does that not fix the issue for you?

#3913 brings back the old case-sensitive behaviour. This issue is about making category search case-insensitive which is still an open question, to my understanding.

To continue the discussion from #5712, the only idea I could think of to improve our category search such that it behaves in a case-insensitive and fuzzy way is to possibly consider augmenting the results of the allcategories API with that of the API that the Special:UploadWizard uses (I suppose it is API:Opensearch as per @mnalis's finding.
This has the caveat that we would be starting to get hidden categories in our result again as API:opensearch does not know about hidden categories. Is that a fine trade off?

Sounds like a negative tradeoff to me. 🤔

Yeah. That's kind of the problem. We don't have an API as far as I know that gives us the best of both worlds, AFAIK 🙁
I'll be more than glad to be proved wrong.

@mnalis Does https://commons.wikimedia.org/wiki/Special:UploadWizard give you the best of both worlds, or not? If yes we should investigate further their API calls and processing. :-)

(@nicolas-raoul notice: unfortunately I have my hands full this week, but I'll try to read up and make a comparison table of current app API vs Special:UploadWizard with examples and make some suggestion next week)

Sorry it took some time, in the end I found it worth writing a script to generate it... Some notes:
Text "no" or "match" means whether it matched the "Expected Result" in that API call for "Search Term". Its HREF is API call itself, and if you hover over "match" it will show what string(s) it actually matched. :heavy_check_mark:  means that is what we want, and a :x: that we didn't want that match (note that those differ from "no/matched", for e.g. hidden or redirected categories where we don't want to find a match)
Number "90" in titles means I've increased search space (from default 10/30 matches, otherwise the results do not show how good the API is at matching, but also how many other results is returns)
TL;DR: the more green checkboxes API has, the better it is.
commons-app code seems to contain 4 different APIs, although I don't know which ones are used? Those are labeled app1, app2, app3, app4.
Results coming in next post real soon now. Let me know if I should add/remove search terms or APIs from the list to make it more readable.

What is additionally interesting about it (perhaps because of " chars in the name?) it is only matched by app2 (allcategories) and no other search methods, even when exact string with correct case is supplied.
So I've now also added simpler Category:Nature of Skole Raion test case.
In next message is new version (make category name clickable with hover-over tooltip about the use case, removed app3/app4, updated test cases).

 Are their results simply merged when user searches for category of their picture, or something else?
It would seem to me that each of the 3 APIs have their own distinct advantages.
The best results for the end user would be merging all three outputs (while removing duplicates), were it not for that skips hidden column. Obviously unions does not work well with exclusions... I might have some ideas, but would like your explanation about current usage of app1 vs. app2 above.

@sivaraam can you give insight when is app1 (generator=search) being used,

From my reading of the code, the app1 is used for category suggestions that show up in "Step 3" of the upload step. Specifically, that API is used for suggesting categories based on the caption entered by the user.

and when app2 (generator=allcategories)?

This is the one that we use when a user types in text to search for categories in "Step 3" of the upload step. That's why the search behaves case-sensitively and only returns when the exact prefix is searched for.

Are their results simply merged when user searches for category of their picture, or something else?

Nope. The results aren't merged now. They are used for different cases as my answer above should've hopefully clarified.

The best results for the end user would be merging all three outputs (while removing duplicates), were it not for that skips hidden column. Obviously unions does not work well with exclusions...

You're spot on. Actually, we don't even need to merge the three outputs. If we observe closely, just combining the results of app1 and app2 would address the troubles we have. The only thing stopping us from doing a union of those API results is the "skips hidden" part that you mention.

I might have some ideas, but would like your explanation about current usage of app1 vs. app2 above.

I hope my explanation gave you an idea. I'm all ears on your ideas 🙂

I hope my explanation gave you an idea. I'm all ears on your ideas 🙂

Thanks @sivaraam indeed it has been quite informative! Here is my idea:

when the user types a text to search for a category in "Step 3" of the upload, we first invoke app2 as we do now, giving user the list without hidden categories. However, if the user scrolls down to the end of that list, we immediately show a loading spinner animation, and then do an automatic request to fetch app1 results, which we then append (after removing duplicates) to the end of the existing list and return control to the user to select category.

That way, users who had found a match in original app2 results and selected it, would have the same workflow as now. However, if they scroll down to the bottom of the list (in most cases because they didn't find what they were looking for) they would get the missing results. The additional benefit is that we don't double the load the on APIs, instead of doing additional query only when it is needed.

slight alternative to that idea is to have manual button Load more... at the end of the original app2 list, which would do the additional app1 fetch when pressed, instead of doing that automatically as suggested above. But I think the users would get quite bored if they needed to do click that too often, so perhaps version above is more user friendly. Small benefit of fully manual button  would be that it would produce even less load on the APIs (e.g. in the cases user scrolled to the bottom but did not want to find more results) and save user's bandwidth if it is not needed.

of course, if the user does load more categories via that second step app1 API call, it will (sometimes) contain some hidden categories. That does not sound like a big problem to me so I think it can be ignored, especially as it only happens on hopefully much smaller subset of searches (after all, that is what every user using Special:UploadWizard is exposed to!), and after the user has run out of options; but if we do think it is a big deal, it can be dealt with in two with:

having a hardcoded lists of popular groups of hidden categories to skip (e.g. Photographs taken on..., Requested moves... etc.) and removing them from the list before showing it to the user
after user selects the category, check if it is a hidden one, and if so, warn the user / refuse the category (and possibly add it to the "ignore list" above to reduce problem in the future)
But as noted, I do not think such extra complexities would be needed, but I'd be interested to know what @nicolas-raoul and others think (especially if they have found hidden categories to be quite a hindrance before in older app version or Special:UploadWizard webpage)

another suggestion I have (which I perhaps should open separate issue for, although it is tightly related to how category search/selection work; but it can be implemented independently), is after the user does select a category, we should do some API lookup (I haven't yet looked up which one, but I assume it exists) to check whether:

category has been moved/renamed. If so, we should select that destination category instead automatically.
we might also check if category has zero members (or maybe even zero files -- e.g. if it has only subcategories), and warn the user if that is the case so they might go back and choose other category.
That would reduce issues with users selecting misspelled or otherwise discouraged categories

So what do you people think?

* when the user types a text to search for a category in "Step 3" of the upload, we first invoke `app2` as we do now, giving user the list without hidden categories. However, if the user **scrolls down to the end** of that list, we immediately show a loading spinner animation, and then do an **automatic request to fetch `app1` results**, which we then **append** (after removing duplicates) to the end of the existing list and return control to the user to select category.

That sounds like a good idea that would help us get to a situation better than the status quo. But I'm skeptical of appending the app1 results after the whole app2 results are shown. This might be unhelpful if user only has entered few characters in the search box. May be we could go fancy and show two scrollable lists each containing results of the two APIs so that things are better distinguished ? I don't how bad a UX that may be 🤔
If two scrollablel iists sound bad, we should think if there's a better strategy to append results from app2 and app1? Like showing 15 results from app2 then appending 15 results from app1 and so on.

* slight **alternative to that idea is to have manual button** `Load more...` at the end of the original `app2` list, which would do the additional `app1` fetch when pressed, instead of doing that automatically as suggested above. But I think the users would get quite bored if they needed to do click that too often, so perhaps version above is more user friendly.

Yeah. I too agree that automatically loading might be better UX.

Small benefit of fully manual button  would be that it would produce even less load on the APIs (e.g. in the cases user scrolled to the bottom but did not want to find more results) and save user's bandwidth if it is not needed.

This is indeed a good point. We could consider implementing the "Load more" button as an enhancement for users who have the "Limited connection" mode enabled.

  * having a hardcoded lists of popular groups of hidden categories to skip (e.g. `Photographs taken on...`, `Requested moves...` etc.) and removing them from the list before showing it to the user
  * after user selects the category, check if it is a hidden one, and if so, warn the user / refuse the category (and possibly add it to the "ignore list" above to reduce problem in the future)

These are good ideas that could help improve the UX 👍🏼

* another suggestion I have (which I perhaps should open separate issue for, although it is tightly related to how category search/selection work; but it can be implemented independently), is **after the user does select a category**, we should do some API lookup (I haven't yet looked up which one, but I assume it exists) to check whether:

  * category has been moved/renamed. If so, we should select that destination category instead automatically.
  * we might also check if category has zero members (or maybe even zero files -- e.g. if it has only subcategories), and warn the user if that is the case so they might go back and choose other category.
    That would reduce issues with users selecting misspelled or otherwise discouraged categories

Yeah. This is a good suggestion but let us discuss it in a separate issue as you mention. 👍🏼

That sounds like a good idea that would help us get to a situation better than the status quo. But I'm skeptical of appending the app1 results after the whole app2 results are shown. This might be unhelpful if user only has entered few characters in the search box.

In what way do you think it would be unhelpful? Could you elaborate?
I don't seem to see the problem - if user has only entered few characters in the search box they will usually get maximum results (25?) from app2 anyway. I suppose they will then either continue typing more (e.g. if they were just too slow in typing and didn't actually want list of results yet), or they will browse that list until they find a match (in which case problem is solved!), or they will reach the end of the list with no match found -- and if they reach end of list, we'd fetch additional results from app1 too as specified.
My idea was to try to use only app2 as much as possible as it preserves user experience (i.e. we won't have an inrush of "previously I had those results and now I have different ones!"), and while it has smaller result set, it also has less "false positives" -- by using app2 as a primary source we avoid hidden categories and other confusing and unwanted results that app1 might return, so we should only fall back to app1 if user was unable to find their category in app2.

May be we could go fancy and show two scrollable lists each containing results of the two APIs so that things are better distinguished ? I don't how bad a UX that may be 🤔

Uh, it seems quite bad :sweat_smile: - even on desktop, but especially on small mobile screen where screen estate is at premium.
Displaying both lists at once, or mixing them 15+15, would also emphasize two problems:

we'd basically double API load (and data usage) overnight (instead of just slightly increasing it in cases when user didn't find their category in the first try).
issues with unfiltered hidden categories would be much more visible and annoying as they would happen always (instead of just when we fallback to app1 because no match was found).

(Sure we can try to hardcode list of popular hidden categories as an additional help as suggested earlier, but we likely won't be 100% successful in removing all of them, so they'll still remain an issue)

We could consider implementing the "Load more" button as an enhancement for users who have the "Limited connection" mode enabled.

Good idea, we could (and there are also other bandwidth-saving opportunities, like not requesting thumbnails downloading when in "Limited connection" mode, or caching results for same string searches etc). But I think we better try to first do simple variant which solves the core problem of this issue (user not finding categories they want); and only when we have that working, we can then suggest additional improvements.

Yeah. This is a good suggestion but let us discuss it in a separate issue as you mention

OK, moved that suggestion to #5751

Huge thanks @mnalis for this table, very interesting and some cells surprised me. I am sure the table will be key to a better category search implementation.

when the user types a text to search for a category in "Step 3" of the upload, we first invoke app2 as we do now, giving user the list without hidden categories. However, if the user scrolls down to the end of that list, we immediately show a loading spinner animation, and then do an automatic request to fetch app1 results, which we then append (after removing duplicates) to the end of the existing list and return control to the user to select category.

This sounds like a good idea to me. I suggest alternating between app2 and app1 if the user scrolls further and further down.
Removing hidden categories from app1 results (maybe using a hardcoded list then checking each remaining category individually via another API call) can be left as a future enhancement.

In what way do you think it would be unhelpful? Could you elaborate?

Sorry for the confusion. I was misassuming that the current UX actually permits infinite scrolling and loads the categories up until the API results are exhausted. Seems like that's not the case. We only load up to 25 results as you mention.

My idea was to try to use only app2 as much as possible as it preserves user experience (i.e. we won't have an inrush of "previously I had those results and now I have different ones!"), and while it has smaller result set, it also has less "false positives" -- by using app2 as a primary source we avoid hidden categories and other confusing and unwanted results that app1 might return, so we should only fall back to app1 if user was unable to find their category in app2.

Yeah. I like this idea. This would be a great improvement to the current situation 👍🏼

May be we could go fancy and show two scrollable lists each containing results of the two APIs so that things are better distinguished ? I don't how bad a UX that may be 🤔

Uh, it seems quite bad 😅 - even on desktop, but especially on small mobile screen where screen estate is at premium.

Yeah. Let's just drop that as a bad idea 🙂

Displaying both lists at once, or mixing them 15+15, would also emphasize two problems:

we'd basically double API load (and data usage) overnight (instead of just slightly increasing it in cases when user didn't find their category in the first try).
issues with unfiltered hidden categories would be much more visible and annoying as they would happen always (instead of just when we fallback to app1 because no match was found).

Makes sense.

Good idea, we could (and there are also other bandwidth-saving opportunities, like not requesting thumbnails downloading when in "Limited connection" mode, or caching results for same string searches etc). But I think we better try to first do simple variant which solves the core problem of this issue (user not finding categories they want); and only when we have that working, we can then suggest additional improvements.

Yeah. That's true. We could first do the alternating requests to app2 and app1 as that seems to be a mutually agreed solution that would help improve the current situation well 👍🏼

Yeah. That's true. We could first do the alternating requests to app2 and app1 as that seems to be a mutually agreed solution that would help improve the current situation well 👍🏼

Sounds good to me @sivaraam !
Now if only someone good with Kotlin and commons app codebase would volunteer to implement it!    :wink:

In the current version (5.1.0~707997) the search for categories ignores upper and lower case at the beginning. This is very nice. For categories with several words, however, capitalization is mandatory from the second word onwards. (not so nice).
https://commons.wikimedia.org/wiki/File:20241228_xl_1507-Upper-lower_case_of_category_names.jpg


add optional parameter 'aws_token' to unload function

Description & motivation
Allow compatibility with session token for use with temporary access credentials.
Checklist

[x] I have verified that these changes work locally
[x] I have updated the README.md (if applicable)
[ ] I have added tests & descriptions to my models (and macros if applicable)

👍

@clrcrl if there's anything else I can do or provide please let me know


Conditionally apply extra_args if config not found

Issues

[X] I have checked existing issues and there are no existing ones with the same request.

Feature description
I want to apply extra_args only if config for prettier doesn't exist.
Help
No
Implementation help
No response

Configure the source per-project. Anyways, this sounds like an xy problem, so please provide more background context to your issues in the future.


Trouble installing

I have installed Jupyter Litchi with pip install jupyter_litchi. However, I am running into issues within Jupyter Lab where it tells me that the "list models from http://localhost:11434/api/tags filed. Please check the settings or explorer console if you are the developer."

hello,
thx for you told this problem. At default, litchi connect to ollama in local.  Or you can set an online service like OpenAI. The connect settings in Jupyter lab settings panel. You can find litchi settings in the page


Visitors counts increaments move it to the left end corner of webpage

#2613
Related Issue
[Cite any related issue(s) this pull request addresses. If none, simply state “None”]
Fixes:  #2613
Description
Aligned the visitor count at the end of the page.

Type of PR

[ ] Bug fix
[X] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
Checklist:

[X] I have made this change from my own.
[X] I have taken help from some online resources.
[X] My code follows the style guidelines of this project.
[X] I have performed a self-review of my own code.
[X] I have commented my code, particularly in hard-to-understand areas.
[X] I have made corresponding changes to the documentation.
[X] My changes generate no new warnings.
[X] I have tested the changes thoroughly before submitting this pull request.
[X] I have provided relevant issue numbers and screenshots after making the changes.

@huamanraj please review the PR


Type declaration issue when no semicolon

TS and JS Grammar Extension version:  0.4 / latest
Code
As you can see in attached screenshots :
program is not colored when type declaration misses the semicolon at end.
I always code without semicolons, and it's valid TypeScript.

what version of TS and JS Grammar Extension are you using?

can you also share a code sample we can copy/past?

I'm using the last one from the Marketplace, I updated it today.
A sample code:
const sayHello = () => console.log('Hello')

type SomeType = {
      a: number,
      b: string
}

sayHello()

sayHello() won't be highlighted.
Add a semicolon after type declaration and it will be.

There is no easy way to fix this. If we try to fix this we would have issues like #166, #206
Because there is no way to distinguish if the new line would continue the type or not we have a rule that only stops the type declaration context on semicolon or start of the new declaration statement.

Could the end of the type declaration not be defined by the first [^&|] instead of ;?
I mean semicolons are really something I don't use anymore (and that I don't like) and I don't believe to be the only one in this case. (Standard linter gets rid of them)
And coding without having syntax highlighting is not something very pleasant neither.

Could the end of the type declaration not be defined by the first  [^&|]  instead of  ; ?
That does not work for scenario like

type A = B
 | C

Note that this is because grammar can only lookup one line at a time The is no way to see if there is | on new line or not.

@sheetalkamat you can't just close an issue because it is too much work. The highlighting is incorrect. Instead, the grammar tool should be able to observe current, previous and next line to be able to compute properly (follow a type from A-to-Z) ? Could we re-open this issue ?

@pirix-gh this isn't about "too much work", it's about the fundamental design limitations of TextMate grammars (which we neither created nor control). We can't force a square peg into a round hole.
If you think we're mistaken about how the grammar works and can identify a fix, we'd welcome a PR, but our analysis of the situation is that this isn't possible to fix in a tmLanguage colorizer.

Ok, but since this is not fixed, the issue should stay open, while waiting for someone to come up with a PR :)

As project maintainers, we decide what constitutes an "open" issue. The definition we've chosen is that issues are open if there is identifiable work to do in this project. Since the work is in the framework that consumes this definition, there's nothing we can do about it here, so the issue is closed.

This is fixed by 74f669d if type declaration follows empty line. Not having empty line will be limitation and cant be fixed.

This is fixed by 74f669d if type declaration follows empty line. Not having empty line will be limitation and cant be fixed.


Added variables for extra options for nodes and edges.

These are variables to adjust the graph parameters.
I hope the code is fine, I'm not very skillful in Lisp.

This is awesome, thank you for the implementation and the PR.


fix: syntax error in async generator function

This PR fixes syntax error in async generator function.

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.51 :tada:

Comparison is base (68780dd) 61.66% compared to head (94c3cfa) 62.17%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##           master      #11      +/-   ##
==========================================
+ Coverage   61.66%   62.17%   +0.51%
==========================================
  Files           1        1
  Lines        2937     2937
  Branches      966      966
==========================================
+ Hits         1811     1826      +15
+ Misses       1119     1104      -15
  Partials        7        7

Impacted Files
Coverage Δ

src/index.ts
62.17% <100.00%> (+0.51%)
:arrow_up:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Upgrade Field Group

see https://github.com/jhu-idc/idc-isle-dc/issues/71
Module is up to date, has a deprecation on a core JS library that is removed in D9. This issue denotes that in the D9 compatibility issue a dependency on a new module was added. Not sure if iDC takes advantage of this behavior or not which may require this additional module being added and enabled.

Done as of https://github.com/jhu-idc/idc-isle-dc/commit/d216a2d1fa117028fa62396e5f649fa000b74f93


Fix Arm issue for rancher

We tested Rancher on the Arm server (HUAWEI) of a Chinese customer and found that there was a problem with our rke-tools and its built-in confd could not run. However, this problem cannot be reproduced on the AWS Arm instance.
We need to release a new version of confd and make a PR to rke-tools to address this issue.

ping @cjellick

We are about to sign a contract with a customer GEOVIS/Kongtian Institute. The server chips they use are Huawei arm processor Kunpeng and PHYTIUM FT-2000, but currently confd components cannot be used normally in these two environments. Hope to support it as soon as possible

Thanks for the PR @niusmallnan! Pulled in related arm changes, switch to go modules and fixing our build stuff in this PR together https://github.com/rancher/confd/pull/3.
Can be tested with confd v0.16.2, rke-tools v0.1.69 for k8s versions in Rancher v2.4.13-rc3 mentioned here.

Thanks for the PR @niusmallnan! Pulled in related arm changes, switch to go modules and fixing our build stuff in this PR together https://github.com/rancher/confd/pull/3.
Can be tested with confd v0.16.2, rke-tools v0.1.69 for k8s versions in Rancher v2.4.13-rc3 mentioned here.

confd v0.16.2 cannot run on my Huawei Kunpeng arm server.
I tried to build from source and it works fine. It seems that there is a problem with the officially released version.
# go 1.16 | Windows10
SET CGO_ENABLED=0
SET GOOS=linux
SET GOARCH=arm64
go build

I found that the file of arm and arm64 is the same. It should be caused by mistakenly building arm64 as arm.
# sha256sum.txt
e08a185763f1fd8a15e55937553669af72ab7dcc8eb3117704551032e5eae6e6  bin/confd-v0.16.2-linux-arm
e08a185763f1fd8a15e55937553669af72ab7dcc8eb3117704551032e5eae6e6  bin/confd-v0.16.2-linux-arm64

Hope to fix it asap.


Fix issue for timeout not getting resolved, for promise values

Fix issue for timeout property not getting resolved, for promise values

Closing as the code in this repository is generated from the source in https://github.com/angular/angular.js.


Text Flickering

I've created a map for Gmod and your addon works perfectly fine before I pack any custom content into my map using VIDE. Once the map has custom content packed inside I encounter a bug where text flickers and disappears at random angles/distances and locations around the map. I'm completely stumped as to what could be causing this and any help would be gladly appreciated. I've recorded an example of the issue which seems to happen on two different maps that I've created, both have custom content packed: https://media.giphy.com/media/RicihyoDoa4Zvgo1YW/giphy.gif

Thanks for the report!
This is definitely an interesting one. It kinda looks like a form of z-fighting? Does the issue persist if you move the screens away from the wall slightly?
I'm honestly not familiar whatsoever with VIDE, so there's probably not going to be a whole lot I can do here, but I'd be interested to know if you find anything else.

Thanks for the report!
This is definitely an interesting one. It kinda looks like a form of z-fighting? Does the issue persist if you move the screens away from the wall slightly?
I'm honestly not familiar whatsoever with VIDE, so there's probably not going to be a whole lot I can do here, but I'd be interested to know if you find anything else.

Moving the textscreens away doesn't seem to help the issue, unfortunately. I'm going to keep investigating and perhaps try an alternate tool and seeing if the problem persists. But honestly I have no clue as to what could be causing it

I'm going to go ahead and close this issue. I don't think it's something I have much control over. If you have any more information, feel free to update this, or create a new issue.


Public activity streams

Followed up. Back to @nicolaasmatthijs

Changes Unknown when pulling 6e2be4ca74e11782bcd550fb733d304877585cad on simong:public-activity-streams into ** on oaeproject:master**.

Looks good. Merged


[CT-2824] Update unit tests so that when run individually we don't get args errors

The unit tests have been updated piecemeal to have something like:
from dbt.flags import set_from_args
from argparse import Namespace

set_from_args(Namespace(WARN_ERROR=False), None)

Come up with a common mechanism for updating the tests and ensure that all of the unit tests can be run individually.

As a first stab, lets consolidate how we do this in tests/unit by creating a base test class or util method. Then we can reevaluate whether there are alternative / preferred mechanisms for setting args in unit tests.

Let's re-evaluate the need for this once https://github.com/dbt-labs/dbt-core/issues/8627 is closed

We've added the set_args thing to all of the unit tests that need it, so closing this.


bug: rerender the view when using infinity scroll

Affected Packages

[ ] @yeger/eslint-config
[X] @yeger/vue-masonry-wall
[ ] @yeger/vue2-masonry-wall
[ ] vecti

Description
I use it in the Nuxt 3 app. When I load more data, it rerenders the view and jumps to the top of the page.
The scroll container is the window (default).
Reproduction
I use Pinia, and new data is fetching when we reach the end of the page.
res.data.results.forEach(image => {       if(image.generated_image) {         images.value = [...images.value, image]       }     })
This is how I push new items to the array
Additional context
No response
Preferences

[ ] I want to be assigned to and work on this issue myself

I'm almost certain that the issue is caused by your image components having a height of 0 during their initial rendering.
You'll have to set their aspect ratio or find other measures to give them an initial height.

Yes, you are right. I put the aspect ratio using style binding, and then it worked. Thanks a lot

    <MasonryWall :items="works" :ssr-columns="3" :max-columns="3" :column-width="128" :gap="20" >
      <template #default="{ item}" >

					</div》
       </template>
    </MasonryWall>

.infinite-scroll-container {
height: 800px;
overflow-x: auto;
overflow-y: auto;
}
Hello, I have encountered the same problem and I have set the aspect ratio, but it still doesn't work. Is there a problem with the code? Please give me more guidance, thank you!

  <MasonryWall :items="works" :ssr-columns="3" :max-columns="3" :column-width="128" :gap="20" >
    <template #default="{ item}" >

     </template>
  </MasonryWall>

.infinite-scroll-container { height: 800px; overflow-x: auto; overflow-y: auto; }
Hello, I have encountered the same problem(after loaded more data, it rerenders the view and jumps to the top of the page.) and I have set the aspect ratio, but it still doesn't work. Is there a problem with the code? Please give me more guidance, thank you!

No aspect ratio is being set in this example.


Container caches bounds which leads to incorrect behavior when masking

I have a Container with many children to which I am applying a sprite mask.
Upon resizing events (where I modify the children in the container as well as the sprite mask source texture)... the rendered container with the mask clips improperly after scaling up.
Digging into the PIXI code the problem is that the Container class caches its bounds to _currentBounds. This is never invalidated even after modifying the children in it. This leads to the Container thinking it has smaller bounds... and resulting in the blit being clipped.
A work-around for me was to manually invalidate the _currentBounds field of the Container on resize events.
I think ideally the cached _currentBounds should somehow get auto-invalidated.
Working with v3.0.10 here.

This is never invalidated even after modifying the children in it.

Its invalidated on next updateTransform()

fixed in v4 👍


Unable to change collapse's bg color

Great work doing daisyui!.
I'm unable to  change the background color of collapse component:

It is still with  white background, even customizing it in my css file using Tailwind's @apply directive:

@eandresvera The style for a focused collapse is a little bit complex because it has to:

apply for both types of collapse (using a checkbox / using HTML element focus)
apply for both title section and the content section
consider the collapse-open an collapse-close utility classes

I will make this color change on the next version: https://play.tailwindcss.com/1i7sNDMt4H
So it will adapt to any background color.
Does this work for you?

@saadeghi that works perfectly!.
Thank you for the fast reply and your work doing daisyui!

@eandresvera The color changes are applied for latest version 1.6.1


Switch auto turn off and resume music

Would be great for the switch to automatically turn off after the announcement is given and music resume. Right now the switch just stays on forever.

This plugin needs to use the Sonos Audio Clip set of commands instead of replacing the currently playing audio with the announcement. This will make for an immensely better user experience, as well as auto-synchronizing the announcements on multiple players, and making this issue nonexistent because it ducks the music during the announcement and brings it back up, just like a normal PA system. I've ben on the hunt for a plugin/node http etc that uses this new set of commands but haven't found one yet, hopefully this can be the one! :)

This plugin needs to use the Sonos Audio Clip set of commands instead of replacing the currently playing audio with the announcement. This will make for an immensely better user experience, as well as auto-synchronizing the announcements on multiple players, and making this issue nonexistent because it ducks the music during the announcement and brings it back up, just like a normal PA system. I've ben on the hunt for a plugin/node http etc that uses this new set of commands but haven't found one yet, hopefully this can be the one! :)

What about using the https://github.com/jishi/node-sonos-http-api plugin? it works really well

Your welcome to make a PR to update this.

Unfortunately that node Sonos repository hasn't been maintained/updated in a while, and that also is not using the audio clip commands for announcements, so it replaces the currently playing audio every time and does not restore it when finished.


Allow multi-line text for buttons

Currently, the buttons only display text in one line, which results in truncation if the text is long.
This fix should allow longer button texts to be formatted better.

Thanks!


Danger, I think I found a vulnerability

Hi , it seems that the cypress configuration for middleware defaults to true
https://github.com/shakacode/cypress-on-rails/blob/master/lib/cypress_on_rails/configuration.rb#L10
I've added the configuration on the initializer but the railitie runs first, so the setting is always true !. This is a serious vulnerability.
The Railtie has to initialize the configuration on after_initializer , instead initializer this way will hook the user's configuration
module CypressOnRails
 class Railtie < Rails::Railtie
   config.after_initialize do |app|
     if CypressOnRails.configuration.use_middleware?
         app.middleware.use Middleware
       end
    end
  end

awesome, think you can create PR out of your suggestion please?

This is a serious issue...


Add japanese language support

This adds the japanese language translation support.
Changes

Adds japanese string resources (.resx)
Adds flag image
Adds japanese flag button to the demo app

Testing
I checked these controls.

[x] MessageBox button text
[x] ColorPicker button text
[x] TimeBar interval text
[x] Pagination jump button text
[x] Clock AM/PM

awesome work! can you provide language for hc demo too? 😄

awesome work! can you provide language for hc demo too? 😄

hmm... already done!

awesome work! can you provide language for hc demo too? 😄

hmm... already done!

no, all in english.

awesome work! can you provide language for hc demo too? 😄

hmm... already done!

no, all in english.

ok now I'm working on it, please wait a still :runner:

Demo-app translation done!


Allow openseadragon 5

Thanks for a wonderful package!

Thanks for doing this. We probably also need a new minor version number, updated build, and a new release, right?

Definitely -- I've updated the version, regenerated package-lock.json and ran npm run build. Happy to make any further modifications. Thanks again!

Thanks for doing this!


Vuetify 0.13

Design Upgrade

Codecov Report

Merging #4 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master     #4   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          10     10
  Lines         292    292
=====================================
  Hits          292    292

Impacted Files
Coverage Δ

assets/api/main.js
100% <ø> (ø)
:arrow_up:

nuxt.config.js
100% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c89e6d4...ad42816. Read the comment docs.


Whole Qualitative Results of comparisons on NH-Haze ，Dense-Haze, O-haze and I-haze testing set

I hope you can give me the link of whole visual results

I have just uploaded them to: https://github.com/tranleanh/edn-gtm/tree/main/outputs
Good luck,
LA Tran


Update snapshot to false for RKE cluster.yml example

The snapshot: true refers to the legacy recurring snapshot syntax (pre RKE v0.2.0)

https://rancher.com/docs/rke/latest/en/etcd-snapshots/recurring-snapshots/

I've made this change to the versioned docs https://github.com/rancher/docs/commit/f427dada8df1545950b2794682eb6dc12f525fce


Container Runtime Options

What would you like to be added:
Today, Gardener has a hard requirement to Docker, but there are a couple of more container runtimes out there, e.g. cri-o or gvisor. We should investigate what is necessary to make the container runtime pluggable, and to allow end-users to configure which runtime shall be used on shoot level.
Why is this needed:
End-users are interested in using other container runtimes than Docker.

Would love to help here

Seems to me that the biggest value would be to make Gardner-managed clusters use Containerd to launch pods by default. Both gVisor and Kata Containers support integrating into Kubernetes using Containerd shims.
Since the latest Docker CE packages come with Containerd, and CoreOS has Containerd preinstalled, the change would mainly require adding the relevant kubelet parameters (--container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock). On CoreOS images the correct socket would be /var/run/docker/libcontainerd/docker-containerd.sock
Once kubernetes is configured to use Containerd, actually adding additional runtimes like gvisor or kata containers would require adding the relevant binaries to the nodes (e.g. by providing a torcx package for CoreOS), configuring containerd correctly, and adding a RuntimeClass object into the Kubernetes control plane.

Gardener is not working only with CoreOS, it also has support for Ubuntu and SUSE-JEOS. New operating systems might be added in the future, too. A clean contract from the Gardener is required w.r.t. container runtime, so that new operating systems controllers will be implemented without any change in the gardner code.
At the moment, the OS can be configured per worker pool, because of potential issues(missing support for container runtime X in OS Y) maybe the container runtime should be configurable per worker pool, WDYT?

Configuration per worker pool is probably the most flexible solution, but probably kinda difficult to manage from a user perspective if there is no default in the cloudprofile.
Regarding container runtime, i would also prefer to add containerd as a second option for the start.

Configuration per worker pool is probably the most flexible solution, but probably kinda difficult to manage from a user perspective if there is no default in the cloudprofile.

OS type and version is optional in the shoot manifest, too. If the OS is omitted in the shoot manifest, it is defaulted to the first one available in the respective cloud profile.
https://github.com/gardener/gardener/blob/59a79859b4a6a5428239e5be728716b7ff24b6ca/pkg/apis/core/v1alpha1/types_shoot.go#L804-L805
So, I think that similar approach can be used for the container runtime - have a default in the cloud profile and make it optional in the shoot manifest.
I am only afraid whether all supported OSes will support all container runtimes, so some validation checks might be required, e.g. worker pool with OS X supports container runtime Y and Z, but not W. A compatibility matrix might be added to the machine image definitions in the cloud profile as constraints.
https://github.com/gardener/gardener/blob/59a79859b4a6a5428239e5be728716b7ff24b6ca/pkg/apis/core/v1alpha1/types_cloudprofile.go#L85-L91

Agreed, so we need to have:

a default container runtime per CloudProfile, which is available across all possible MachineImages / OSses
A set of possible/compatible ContainerRuntimes per MachineImage, which will default to that given in the CloudProfile if ommited.

I think this is a little more subtle. The first question is whether Kubernetes is configured to use the Docker API to configure containers, or the CRI API to configure containers. The current default is to use the Docker API, I think we should change that to use the CRI API, by moving the default Kubernetes configuration to use Containerd. This should be done across all worker-nodes, regardless of OS type.
The advantage of using Containerd is that it is already installed on all of the supported images - it's actually part of the Docker distribution - so it's simply a matter of changing the Kubelet configuration.
Once Kubernetes has been configured to use the CRI API to configure containers, it becomes possible to make additional changes - adding additional runtime options like GVisor, Kata Containers, and so on - simply by changing the Containerd configuration file and adding a Runtime definition to Kubernetes. This should be a secondary addition to the work done here. Adding these extensions should indeed be done as suggested here - on a worker-group basis.

Sounds all very reasonable:

using the containerd shim
make it configurable per worker pool
similar defaulting behaviour as we have already for OS
describe which runtimes are allowed per OS, when we have gaps (maybe RHEL and Docker is already such a gap that may force us to do that, because that combination is officially supported)

In addition, we would get of course another/fourth output qualification dimension (IaaS, K8s Version, OS and Version, and now Runtime and Version?). cc @dguendisch @schrodit @OlegLoewen

An additional test dimension, uh, I mean if that feature makes sense (and it sounds like), then we'll have to add that dimension. Maybe we can optimize a bit by not creating test shoots with all that dimensions multiplied but combine dimensions into single shoots by using multiple worker pools instead, let's see...

@dguendisch @vlerenc
For us (FaaS) this feature would definitely make sense. To my understanding Kata containers can only be used, where nested virtualization is possible (not on ordinary EC2 instances), but gvisor would be very interesting.

@nimrodoron and colleagues have filed GEP10 (#1735) and started to implement it as of #1971
The implementation happens in three phases (summary of GEP10, see more details there):

Allow using containerd as CRI for worker pools (requires containerd >= 1.3), see #1971
Extend Gardener's extensions.gardener.cloud API with a new ContainerRuntime resource that is created as part of the shoot reconciliation flow - similar to all our other extension resources.
Develop extension controllers that act on this ContainerRuntime resource for gvisor and others, see e.g. https://github.com/gardener/gardener-extension-runtime-gvisor


Fix double-invocation of plugin

Sometimes plugin/ files can be called twice:

This should make it okay to do so.

TIL, thanks! :)
PRs should normally go through testing but with how small that one is it should be alright. I'll probably just merge master back into testing later so no worries


Display username/email address in menu

Display logged in username/email address in the menu.

When a user logs in, or registers, store the username/email address in AsyncStorage
If the username/email address is in AsyncStorage, display it in the menu
Delete the username/email address from AsyncStorage when the user logs out, or deletes their data

@MikeD-ZOE Is there a mock up for this?

@selvach @julienlavigne @MikeD-ZOE Is there a design mock up for how to display the username and email in the menu?


Improve config file documentation

Want to contribute to DeepPavlov? Please read the contributing guideline first.
What problem are we trying to solve?:
It is quite difficult to understand the config file when you want to build your own.

How can we solve it?:
Add more documentation.

Are there other issues that block this solution?:

hey @polodealvarado!  Can I work on this?

hey @polodealvarado! Can I work on this?

Sure, no problem.

Hi @polodealvarado!
Pease check the following page in DeepPavlov's documentation: https://docs.deeppavlov.ai/en/master/intro/configuration.html


Limit authority time delay to global constant set by system contract (45 days default)

Test case "delay_tests/max_transaction_delay_execute" has passed with:
  8 assertions out of 8 passed


AttGAN code

AttGAN code has been released recently. https://github.com/LynnHo/AttGAN-Tensorflow

Thanks. I will update it.


New PR for Unused CSS

This PR fixes #896
This is the new PR for this PR https://github.com/meshery/meshery.io/pull/1880
Description
have added a script by which, now user don't have to change the file name in any file he/she just have to update the file name in the terminal.
I have added an unused component name-btn so after running this in the terminal, it will automatically delete all the unnecessary  css component that is not in used. If you want to check any other file just change blog.scss  to file you wanted to check  anything-you-want.scss and it will done its work.
Run this in terminal
node check-unused-css.js blog.scss
This will be prompted in terminal after execution of the script
Success: The file 'blog.scss' was processed successfully. The output has been saved to './output/blog.scss' NOTE: ALL THE UNUSED CSS IS REMOVED FROM THE UPDATED FILE
Before running the script, i added an name-btn unused component in website

It is removed after execution of code

Note : The updated file will be saved in the output directory.
Notes for Reviewers
I found that many of the unused css styles are the ones that are used by pressing or hovering component like a button it has many styles like hovering OR on pressing different styles is used. so its style will be unused until the component is not in used.
Signed commits

[ ] Yes, I signed my commits.

@THEBOSS0369, Thank you for your contribution!
Let's discuss this during the website call on Monday at 5:30 PM IST (7:00 AM CT).
Please consider adding it as an agenda item to the meeting minutes || meeting link.

@THEBOSS0369, Thank you for your contribution!
Let's discuss this during the website call on Monday at 5:30 PM IST (7:00 AM CT).
Please consider adding it as an agenda item to the meeting minutes || meeting link.

Hey @Ashparshp ! This PR has already been discussed. Sudhanhu asked me to either revert back the unnecessary changes from the previous PR and i wasn't able to revert back so i created a new One! Also the Previous Pr for this has been asked to reviewed from reviewers.

@THEBOSS0369 extraneous commits

@sudhanshutech @vishalvivekm ! Can you take a look?


App closes after asking for permissions

When using the Permissions feature , the app closes right after the permissions dialog is shown no Exception on Logcat.

Ensure you're not calling finish() in the onDonePressed method, unless you're launching the intro from your main activity. Refer to the readme or wiki for an example of how to launch the intro once from the main activity.
In theory, you want to call finish() onDonePressed because you want the activity to close. However, if you don't have an underlying activity that launched the activity, finish() will exit to the home screen.
Ensure that the intro is not your launcher activity, rather, your main activity is, and launches the intro from it.

It seems that because there isn't a crash report, the app isn't crashing, but rather finishing in an improper way. Does it say " has stopped"? Or does it just close to the home screen?

It just closes to Home screen, I have my IntroActivity as the launcher activity and I launch my MainActivity if it is not the first start and I'm calling finish in the onDonePressed method after launching the MainActivity.

I did it that way because when I pressed back the app showed the MainActivity which was not optimal. I'll try the other way to see if that solves the issue

I tried it the other way and i closed to the home screen as well

@ivanmestre glad you got it working :)
One thing to note about the intro closing when pressing the back button, I'm going to open an issue for this so that I'll remember to add support for disabling the back button. That way, if you want to, you could define whether or not the back button makes the intro close.

At the end the problem was that I had the IntroActivity with noHistory=true in the Manifest, that is what was making the app close

I've just encountered this myself: trying to suppress history causes issues. Might be useful to put in the readme so others know this could break things.

Thank you @ivanmestre -- I also encountered this only on Android 6.0.1, however 7.0 seemed to work as I'd expect.
Issue was due to AppIntro activity being launched from my MainActivity with the FLAG_ACTIVITY_NO_HISTORY flag when I created the intent. Removing this, and also adding call to finish() on the AppIntro onDonePress() callback appears to have resolved it.
Just for reference for others who may stumble on this issue when requesting permissions from the app intro -- this is the final changes I made to handle the launch of the AppIntro activity from MainActivity and then launching the MainActivity after the AppIntro activity has finished.
MainActivity.java
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        ...

        // check if this is the first run, launch the introduction activity
        if (isFirstRun()) {
            startActivity(new Intent(MainActivity.this, AppIntro.class));
            finish();
            return;
        }

        ...
    }

AppIntro.java
    @Override
    public void onDonePressed(Fragment currentFragment) {
        super.onDonePressed(currentFragment);

        // first run of the app is complete
        setFirstRun(true);

        // finish the introduction activity
        finish();

        // launch the main activity again
        startActivity(MainActivity.createIntent(AppIntro.this));
    }


copytext is not always getting valid data (or something)

Here’s a zip file with two copies of copy.xlsx – one functioning, one broken:
http://dbeli.us/165fF

For some reason, openpyxl is swapping the contents of the two sheets for the bad one.

So, I wrote a test case for this using @dannydb's sample files, but not it's working fine for me. I can no longer replicate the issue locally with either file. I have no idea wtf is happening.

The contents of these two files are actually quite dramatically different. I'm not sure what to make of it...


Sorting Systems in World

When adding a System to World, it's appended
to the end, and then a quicksort algorithm is used
to sort it according to System.Priority().
Fixes #105.

LGTM


Adding Abhinav T B

Fixes #
Proposed Changes

@abhinavsri360 I have added things according to the guidelines, what are the things i should add or remove

@abhinav-TB
Do not include package-lock.json and one.jpg in the PR.

@abhinav-TB
The changed file tab still shows 4 files. Please look into it.

@abhinavsri360  the other files are just duplicate images that I deleted

deleting this one a creating a fresh pr


isaac_ros_object_detection node doesn't install parameters file

This line installs the launch file but does not install the parameters file.
https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_object_detection/blob/237774a6a2fea4d72f0608b300a5d5149fc1ee07/isaac_ros_detectnet/CMakeLists.txt#L83
So a user has to use symlink build to launch the node or to copy the file himself.
ament_auto_package(INSTALL_TO_SHARE launch params)
solves the issue

This is a great catch. Thanks for the fix! This didn't make it into DP1.1 but we'll consider this for a hotfix.

Fixed in an update. Thanks again!


on folder name change, onDidChangeWorkspaceFolders will be fired but it doesn't indicate workspace name has changed.

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.91.0
OS Version: windows

Steps to Reproduce:

subscribe to vscode.workspace.onDidChangeWorkspaceFolders
create multiroot workspace something like

{
	"folders": [
		{
			"path": "root1",
			"name": "test_1"
		},
		{
			"path": "root2",
			"name": "test_2"
		}
	],
	"settings": { }
}

change test_1 to test1

Expected Behavior:
vscode.workspace.onDidChangeWorkspaceFolders is fired with some indication that name is changed.
Actual Behavior:
vscode.workspace.onDidChangeWorkspaceFolders is fired but there is no indication on name has changed.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Solve gin test config tracking

Motivation
So, we consolidated our configuration for our gin tests in a single file. However, the problem is that if we want to keep that file in github it won't be ignored by version control (i.e. gitignore) and therefore we still have local changes to the config file being marked as untracked by git and just plain annoying. Reading around a bit most folks suggest that this problem can be avoiding by having setup create a local copy of a master file that then can be modified by the user -us- without messing with version control.

@h-mayorquin I don't understand, what's the issue and how is this any different? In a typical PR workflow when running full tests, you'd branch off of main, update that file locally if needed, then simply don't call git add gin_test_config_local.json explicitly and it won't be included in the commit history.

@h-mayorquin I don't understand, what's the issue and how is this any different? In a typical PR workflow when running full tests, you'd branch off of main, update that file locally if needed, then simply don't call git add gin_test_config_local.json explicitly and it won't be included in the commit history.

Right now, the file gin_test_config.json is in version control. This is mainly so I can reference it on our github page as a reference and so that is downloaded automatically. However, this also implies that when I do local changes to gin_test_config.json the file is marked as modified in git because the file its been tracked.
Introducing a local copy that is not in version control gin_test_config_local.json but it is created at package installation guarantees that the master file gin_test_config.json remains a canonical version not intendend to be modified and designates gin_test_config_local.json as the local file intended to be modified.

Ahh, I see now. Even if it's in .gitignore, editing it will still show up under git status, it simply won't get added by a wildcard grab. But adding a new file under a .gitignore specification will prevent it from showing up at all with git status. Hmm...
However, doing this will require updating the developer documentation (right now, in the readme) to inform people to update only their local copy and not the main one, which gets a bit confusing. Maybe store the global config alongside setup, with the 'local' version being alongide the tests (where the current config is on main)?

@h-mayorquin Good to go?


Add implementation and tests for softplus op

@Honry PTAL, thanks.

Thanks for reviewing, merge it.


Fix CS in tests/Server

https://github.com/webonyx/graphql-php/issues/284

@vladar pls restart travis jobs ;)

nvm, just succeeded


Add additional option to get credentials

Hello!

Vote on this issue by adding a 👍 reaction
If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details
Currently there are 3 ways to get credentials to the provider.
set via environment variable
A config file setting
passed as a value while creating a provider.
The first requires an action by users when they checkout the repo.  The second two would require checking in a token to a source repository which is a big no-no.
The users token is already stored in the credentials.json (located in .pulumi/credentials.json in Unix) It would be nice if a 4th option was added to read the credentials from the credentials.json.
Affected area/feature

This seems like a reasonable ask to me. The main blocker I see is defining the contract between the pulumi CLI and the pulumi service provider so we can guarantee that this will work as the pulumi CLI is updated. I've filed https://github.com/pulumi/pulumi/issues/9679 to discuss this.


formatting problem within the SOS Report  form section

The SOS section of the form on  website is facing formatting issues. The input fields for different labels, such as "Name," "Address," and others, do not have consistent sizes, which affects the overall appearance and usability of the form. Additionally, the label text is not properly aligned with the form elements.
Steps to Reproduce:

Navigate to the SOS section of the website.
Observe the formatting of the form elements.

Expected Behavior:
The form elements (input fields, text areas, etc.) should have consistent sizes, and the label text should be properly aligned above the form elements for a more organized and user-friendly layout.
It should look like

Currently  it look a like:

Proposed Solution:
To resolve this issue, we need to apply consistent styling to the form elements in the SOS section to ensure they have the same width and that the label text is properly aligned above them.

Please assign it to me.


Custom Typeahead

sub-header & footer

show suggestions when empty

http://element.eleme.io/#/en-US/component/input#autocomplete

show history when empty, show autocomplete when typed

Is there any idea?

sub-header & footer

I can make the item slot bigger, which allow user to take full control of dropdown content.

show suggestions when empty. show history when empty

How to achieve these?

suggestions when empty: another prop for user?
history: localstorage? cookie? indexdb?

show autocomplete when typed.

Sry, I don't understand this. The Typeahead is doing autocomplete now. what's your point?

suggestions when empty: another prop for user?
Yes.

history: localstorage? cookie? indexdb?

show autocomplete when typed.

I mean combine local history & remote suggestions
when empty -> show local data
when typed -> show remote data

I mean combine local history & remote suggestions

I can't get your point. If you still want this you can make a PR for it. I'm going to close this one. Thanks.


Mac option key

What should I do for the "option" key in Mac?
I tried "alt", but it doesn't work

I checked the 'keydown' event,
for example,
Option(alt) + A
It turns Alt and å
Option(alt) + S
It turns Alt and ß
Is there any way to fix?

I don't test all Mac keys. I will check this out and fix.

I guess it's going to be difficult. See http://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboards.html.

+1 for this one

On Macs, at least those with a non-US keyboard, using alt/option in keyboard shortcuts doesn't work, because Alt combinations are used to type non-ASCII characters.
In general, keyboard shortcuts using Alt only should be avoided on Mac, while shortcuts using Ctrl only should be avoided on Windows – since most combinations are in use there.
So the solution is to have shortcuts using different modifier keys on different systems. If you go to e.g. Wikipedia you will notice that the keyboard shortcuts change depending on your system. To go to recent changes, I can press Ctrl+Option+R on Mac, while on Windows it's Alt+R.
I'm not sure if this is easy to set up with vue-shortkey though.

@danmichaelo Any updates on this?
I can confirm that using opt as a hotkey modifier works in react-hotkeys so there must be a way. In my react app I was using Opt+1, Opt+2, etc. as a shortcut for switching tabs in my tab component. I would like to do the same in Vue. I would happily use Cmd+1 if it weren't already being used by chrome to switch its website tabs, opt is the next easiest key to reach.
Just FYI here's Apple's official dev docs on keyboard shortcuts: https://developer.apple.com/design/human-interface-guidelines/macos/user-interaction/keyboard/

I needed Control key and Meta key shortcuts but couldn't get the Meta key to work on Linux or MacOS so I removed this package (sorry, I use it elsewhere, promise!) and did the following:
addShortkeyListener() {
            this.shortkeyListener = window.addEventListener('keydown', (e) => {
                const isModiferActive = () => e.getModifierState('Control')
                    || e.getModifierState('Meta')
                    || e.getModifierState('OS')
                    || e.getModifierState('Win');

                if (e.keyCode === 74 && isModiferActive()) {
                    e.preventDefault();
                    e.stopPropagation();
                    this.handleShortkey();
                }
            });
        },

Don't forget to destroy this event listener in your components beforeDestroy hook!


[PAY-1829] Card Selection With Newly Created Payment Sheet Cards

📲 What
This PR address the selection logic of picking a card after it has been added via the new payment sheet.
🤔 Why
User should see newly added card for project with/without backing pre-selected. User should also be able to pick between pre-existing cards and newly created ones. (Both with the payment sheet and no).
🛠 How
...will explain after completed coding pr...
👀 See
Trello, screenshots, external resources?
Before 🐛
..coming..
After 🦋
..coming..
✅ Acceptance criteria
With ios_payment_sheet ON

[ ] User is able to add a new card through payment sheet, select it (or any pre-existing card) within the pledge page only for the .pledge context

With ios_payment_sheet OFF

[ ] User is able to add a new card through add new card screen, select it (or any pre-existing card) within the pledge page only for the .pledge context

⏰ TODO

[ ] Allow manual selection of new payment sheet
[ ] Pass through data into the pledge cta context so its' prepared for the createBacking mutation.

@scottkicks Hey Scott, just getting the hang of adding you to new PR's -- no need to review it or anything, feel free to post questions/comments if you want.

          1 Warning

:warning:
Big PR

  Generated by :no_entry_sign: Danger


[scroll] zigwiwi

When window's vertical overflow is a few pixel the header height switch between two mode.

This will be fixed when we will use tween state component

@Tommass  is it still an issue?

to test...

:+1:

@pierbrisson this issue is now concidered critical

@pierbrisson the current quick fix is to put
[data-focus='layout'] {
	min-height: calc(100vh + 6px);
}

in your stylesheets.

can we get a more stable fix to this issue please.
Cheers


Integrate with Google Analytics

[ ] Setup reporting view in google analytics
[ ] Update webapp to use https://github.com/MatteoGabriele/vue-gtag

Here is an example of integration shared by @subdavis

https://github.com/microbiomedata/nmdc-server/blob/7760e3890bea4f85854e27171e1c6f1472419c39/web/src/main.ts#L22-L26

Setup reporting view in google analytics

For future reference, see https://www.directom.com/google-analytics-subdomain-tracking/
Step 1:  Update "Referral Exclusion List"

Got to https://analytics.google.com

Click on Admin (bottom left)

Then update Referral Exclusion List

Account (Slicer Analytics)
  -> Property (Slicer.org / UA-97117718-1)
    -> Tracking Info
      -> Referral Exclusion List
        -> Add sub-domain (e.g extensions.slicer.org)

Step 2: Creating a new reporting view

Create View

Account (Slicer Analytics)
  -> Property (Slicer.org / UA-97117718-1)
    -> Create View

      Website
      Reporting View Name: extensions.slicer.org
      Reporting Time Zone: (GMT-04:00) New York Time

Step 3: Add filter to reporting view

Add Filter

Account (Slicer Analytics)
  -> Property (Slicer.org / UA-97117718-1)
    -> extensions.slicer.org
      -> Filters
        -> Add filter
            Filter Name:    Include Hostname: extensions.slicer.org
            Filter Type:    Custom / Include
            Filter Field:   Hostname
            Filter pattern: extensions\.slicer\.org


[feature] Support for Ko builder

Can use the PoC I created https://github.com/laurentsimon/slsa-github-generator-ko
It should not be too difficult.

sidenote: think about https://github.com/slsa-framework/slsa-github-generator/issues/684 when building this builder


nsqd: enforce minimum msg size when reading from the diskqueue

See bitly/nsq#598
This does not yet enforce a maximum message size. This can be added with a diskqueue API change to take either a *context or a maxBytesPerMessage argument.

nice work on this @twmb - thanks for adding all those comments to the tests!


Update Message.java

Modify getBodyContentAsString method and make method getBodyContent public

@weihongbin1 Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@weihongbin1 Thank you for signing the Contributor License Agreement!


[DEV-3473] add new amlList cols

Release Checklist
Pre-Release

[ ] Check migrations

No database related infos (sqldb-xxx)
Impact on GS (new/removed columns)

[ ] Check for linter errors (in PR)
[ ] Test basic user operations (on DFX services)

Login/logout
Buy/sell payment request
KYC page

Post-Release

Test basic user operations
Monitor application insights log

[ ] add migration


Open webui with default browser if it's supported

If default browser is supported, webui should prefer it to respect user preferences, get fastest loading time (the browser will already be in RAM).
You can get the browser path from HKEY_CLASSES_ROOT\htmlfile\shell\open\command for Windows
Source: https://superuser.com/a/1111131
Also you can check the default browser with BROWSER environment variable in Linux.
Source: https://askubuntu.com/a/16626

WebUI should use a web browser's order based on which is best for UX (User Experience). Some browsers are terrible in app mode, while others are good. Please see this list for more information.
WebUI v2.2.0 is not complete yet, but the user can use webui_show_browser() to choose the web browser to be used.

Increasing the time is solving the issue however waiting the user for awhile (30 second or more) is not good option. Starting new process of the already working browser is not best option however it can solve the issue.

We can increase it to 30 seconds for now, but that does not mean every time the user starts the program, he should wait 30 seconds. But it means WebUI waits until the browser starts for a maximum of 30 seconds.
Additionally, we can add what you suggested because it makes more sense. For example, if the default browser is Edge, why should WebUI use Chrome?! It should use Edge, as it's probably already running, which makes WebUI apps start faster.
You are totally right. We will implement your suggestion 👍

you can use this fonction for change the time
webui_set_timeout
https://github.com/alifcommunity/webui/blob/527d000b45fadf5fa5f81682a9816573abbc3e1b/src/webui.c#L719

True, but increasing the default one is better, so WebUI apps will run fine in slow environments (Slow Old PCs, Slow Virtual Machines).
https://github.com/alifcommunity/webui/blob/527d000b45fadf5fa5f81682a9816573abbc3e1b/src/webui_core.h#L28
I already implemented the Win32 version of your suggestion of finding the running web browser. I got good results. Your idea was excellent!, I'm working on the Linux version now...

True, but increasing the default one is better, so WebUI apps will run fine in slow environments (Slow Old PCs, Slow Virtual Machines).
https://github.com/alifcommunity/webui/blob/527d000b45fadf5fa5f81682a9816573abbc3e1b/src/webui_core.h#L28
I already implemented the Win32 version of your suggestion of finding the running web browser. I got good results. Your idea was excellent!, I'm working on the Linux version now...

webui_set_timeout() is an additional option for the programmer to modify WEBUI_DEF_TIMEOUT.

https://github.com/alifcommunity/webui/commit/3a0cd4968f7c39d0204c5bb8ab6bd9aaef806343

Windows & Linux implementation is done.
Still need macOS implementation to be done.

Already been implemented for Windows, Linux and macOS in WebUI v2.3.0.
https://github.com/webui-dev/webui/blob/e955ee22282cf43f56fd278503cfbae2dfda8c42/src/webui.c#L3515