[rcore] Window Mode Overhaul

Issue Description

I think we should think about a new clean window mode setup for raylib building on top of whats already there.
For instance both fullscreen & borderless fullscreen set/clear certain config flags to work properly but they do not restore them to the values set by the user when exiting (borderless fullscreen).
The user can set this certain flags without checking of current window mode allows this.
Does losing & regaining focus work in all window modes?
Do minimize & maximize restore previous window state. Like going minimize from fullscreen should restore fullscreen when clearing minimize ? And then exiting fullscreen should restore window before fullscreen ? Should they do that in all cases?
How to handle dpi scale ?
What does Screen Size & Render Size represent exactly.

If any statements or assumptions on my side are wrong please correct them. Any ideas are welcome to make to window handling in raylib simple, easy, and consistent.
Related Issues

[ ] https://github.com/raysan5/raylib/issues/4145
[ ] https://github.com/raysan5/raylib/issues/4146
[ ] https://github.com/raysan5/raylib/issues/3972#issuecomment-2215478818
[ ] https://github.com/raysan5/raylib/issues/4140
[ ] https://github.com/raysan5/raylib/issues/3929

@raysan5  @SuperUserNameMan @JeffM2501 Please add any ideas, suggestions, etc ;)

Ok, I'm a little confused because i don't know in which issue/thread/conversation to begin, so i'm randomly picking this one.
I think i need to clarify some logic first. (at least to myself), and see if we all agree.

if the application requires HDPI support, then, it means the application is meant to work in windowed mode so the user can keep using other desktop applications at the same time. HDPI mode should be compatible with this methods :

MaximizeWindow() and MinimizeWindow()
ToggleBorderlessWindowed() which is like a "no distraction mode".
etc.

On the other hand, making FLAG_WINDOW_HIGHDPI compatible with TogglFullscreen() is irrelevant, since there is no reason for a desktop application to switch to a fullscreen hardware display mode.

if the application requires real hardware fullscreen mode using ToggleFullscreen(), it means it is meant to be a fullscreen game with an optional windowed mode.
In consequence :

making ToggleFullscreen() compatible with FLAG_WINDOW_HIGHDPI is irrelevant.
InitWindow( w , h , "game" ) must use a standard fullscreen resolution.
InitWindow( randomW , randomH , "non standard resolution" ); is irrelevant and nonsensical.

Problem : if the resolution provided in InitWindow( w , h , "game" ) is not supported by the hardware, glfw will try to find another one that will best fit the content. We have no control over this arbitrary choice, so we might end up with a cropped content.
However, once we ToggledFullscreen(), it is up to our game code to check the new screen/render resolution, and to adapt the rendering to it.

To recapitulate : (i hope no reader is colorblind)

purpose of our program :
make a desktop app
make a video-game

enabling FLAG_WINDOW_HIGHDPI
:green_circle:  relevant
:red_circle: irrelevant

enabling FLAG_WINDOW_RESIZABLE
:green_circle: relevant
:orange_circle:  relevant only in windowed mode ?

using  ToggleFullscreen()
:red_circle: irrelevant
:green_circle: relevant

using ToggleBorderlessWindowed()
:green_circle: relevant
:green_circle: relevant

using MaximizeWindow(), etc
:green_circle: relevant
:orange_circle:  relevant only in windowed mode ?

InitWindow( w ,  h , "random resolution" )
:green_circle: relevant
:red_circle: irrelevant

InitWindow( w ,  h , "standard resolution" )
:red_circle: irrelevant
:green_circle: relevant

So, my point is that if take relevant and irrelevant use-case scenario, we could simplify our expectation from current implementation, and identify what is a real issues that need fixes, and a wrong issues that need the user to clarify the purpose of their project and their expectation.
What do you think ?

Why would ToggleFullscreen() not be relevant for a desktop app?

Why would ToggleFullscreen() not be relevant for a desktop app?

From a logical perspective, it's because the desktop app is meant to work in the desktop, with other desktop apps.
When a desktop app needs to use the maximum available screen space, it is either maximized, or set to a maximized borderless window (like a "no distraction mode").
On the other hand, ToggleFullscreen() is meant to have an exclusive access to the display, and might change the display resolution mode to an hardware resolution supported by both the graphics card and the display.
If you write a 3D editor, or a "3D model poser", or a "chiptune editor", or whatever app, you don't need an exclusive access to the display. Miximized window or "no distraction mode" (ToggleBorderlessWindowed()) are more relevant and should suffice.
Also, from a technical point of view, if your desktop is in HDPI mode, you'd probably want the UI and the text of your app to be rescaled accordingly to the DPI.
To do so :

either you do it by code using GetWindowScaleDPI() to rescale your text and UI accordingly ;
either you enable FLAG_WINDOW_HIGHDPI which will rescale the window's size and its content automatically ;

The problem is that using FLAG_WINDOW_HIGHDPI with ToggleFullscreen() leads to issues and over-complications.

Note that if FLAG_WINDOW_HIGHDPI is enabled, ToggleFullscreen() could detect it and fallback to ToggleBorderlessWindowed()

For instance both fullscreen & borderless fullscreen set/clear certain config flags to work properly but they do not restore them to the values set by the user when exiting (borderless fullscreen).
The user can set this certain flags without checking of current window mode allows this.

There is still this issue for ToggleBorderlessFullscreen(). Borderless fullscreen sets the topmost flag and clears the decorated flag. What should happen when the user sets any of those 2 flags while in borderless fullscreen.

Should it be ignored?
Should it be set an applied whenever borderless fullscreen is exited?
Or should it exit borderless fullscreen and set the flags.

Also should the resizable flag be cleared automatically when ToggleFullscreen() is called and then restored to previous value when fullscreen is exited?
As for now all these flags are linked in some way regarding window handling:

resizable
decorated
top most
maximzed
minimized
hidden

We could seperate those flags into window modes and supported flags.

Window Mode
Supported Window Flags

Windowed
Resizable, Decorated, Topmost?, Focused?

Maximized
None

Minimized
None

Hidden
None

BorderlessFullscreen
None

Fullscreen
None

Random Idea?
Raylib could put its own system on top hiding the current way of having config flags and window modes mixed?
Example:

ToggleFullscreen(int width, int height) -> cancels borderless fullscreen/minimized/maximized, stores prev window mode and applies it again
ToggleBorderlessFullscreen() -> cancels fullscreen/minimized/maximized, stores prev window mode and applies it again
SetWindowed(int width, int height, bool resizable) -> cancels fullscreen / borderless fullscreen/ minimized/maximized
SetMinimized(bool minimized) -> cancels fullscreen / borderless fullscreen, stores prev window mode and applies it again
SetMaximized(bool maximized) -> cancels fullscreen / borderless fullscreen, stores prev window mode and applies it again

I have no idea if that makes sense or is usable 😅

Why is it important to init the window with a standard resolution instead of some arbitrary resolution when making a game ?

IMO, with current implementation, it is better, because you increase your chances to actually get a standard full screen resolution when toggling to exclusive full screen mode.
If i ask 800x800, i get 800x600 SVGA.
if i ask 512x512, i get 640x480 VGA.
If i ask 640x480 or 800x600 or 1024x768 or 1280x720, i get what i want because it they are tandard hardware reso that are commonly supported by most hardware.

Why does the above not matter for an application that does not use ToggleFullscreen()?

Because the display hardware resolution will remains unchanged. It will remains the desktop resolution.
You only want your InitWindow() default size to fit into current desktop resolution.

How can I init the window properly without knowing the monitor the game launches on yet ? Is the list of connected monitors and their information available before calling InitWindow()?

I haven't found any function that allows this in current Raylib API.
https://www.raylib.com/cheatsheet/cheatsheet.html

Here the closest resolution is picked on initialization from the supported resolutions from GLFW.
We could first check if there are supported resolutions with the same aspect ratio and find the closest resolution with matching aspect ratio. Only if there are no supported resolutions with the same aspect ratio we fall back to just finding the closest resolution.

If we request a hardware resolution that has a width or height greater than our content resolution, we would have to rescale the content to fit without changing its aspect ratio, to center it, and to add black rectangles on the empty sides.
It might also mean that Raylib would have to render to a texture instead of rendering directly to the window's surface, unless there are some glfw function that allows rescaling the content surface ....
Also, all of this could be done "manually" in the application code side by rendering to a texture.

Should ToggleFullscreen() give the most freedom and let the user handle everything or should it also scale somehow with dpi? Because either the window size is set to the monitor size before ToggleFullscreen or ToggleFullscreen(int width, int height) needs 2 parameters for the resolution the user wants for the fullscreen?

3 parameters : w , h and refreshRate
Like you mentioned somewhere before, we'd need a function that allow enumerating the list of supported hardware resolution and refresh rates so we could let the end-user choose in which hardware resolution they want to run the program.

Note that if FLAG_WINDOW_HIGHDPI is enabled, we could make ToggleFullscreen() detect it and fallback to ToggleBorderlessWindowed()
I don´t think this is a good idea? Again raylib would do something under the hood that is hard to understand.

Anyway there is no point in activating HIGHDPI if the app is intended to run in exclusive fulllscreen mode.
If we want HDPI, we're making a desktop application, and we don't need an exclusive fullscreen mode.
So, i think that if the programmer want both HDPI and fullscreen, they actually need maximized borderless window.

There is also the solution to this entire problem of opening the system up and let the user implement the window handling for themselves? At least as an option? Because this might also be a case where it is impossible to meet all the needs of everyone using raylib.

With a function that would allow to enumerate supported hardware resolution, this could be a greater step forward already.
Also, I think ToggleBorderlessWindowed() definitively needs to be fixed, because it does not restore the borders of the window on my Linux ... :-/

@SuperUserNameMan

From a logical perspective, it's because a desktop app is meant to work in the desktop, with other desktop apps.

I think "meant" is too strong here.  I play AAA Desktop applications, and some of them take the full screen, others offer different configurations, but usually not windowed in the way you mean it.  I have one graphical application that I have to use "reduced" in order to shrink the vertical enough so that the OS pop-up task bar does not interfere with it.  Other than that, I fill my screen with it.
@SoloByte
I find your approach very welcome.  The one thing that bothers me is saying that the InitWindow parameters have anything to do with resolution.  I think we get confused with resolution and the term is misused around computer monitors and desktop applications.  DPI is more helpful except it still doesn't account for viewing distance and the physical size of the monitor surface. so much.  I think the InitWindow request parameters are in pixels and it is probably the case that the numbers chosen there (and in positioning text and specifying text height) assume what platforms have as default DPI unless the application some means to know otherwise and adjust parameters accordingly.
PS: Some of the effects being noticed have to do with monitors having built-in scaling provisions for particular dimensions (in pixels).  Graphical drivers may rely on that.  You can usually see what's available in various situations where the different frame sizes (in pixels) are shown as options.  The best cinematic-quality game software tends to exploit that.  There may also be accessibility considerations here, but I have no idea how that is handled in quality software.

@SuperUserNameMan

From a logical perspective, it's because a desktop app is meant to work in the desktop, with other desktop apps.

I think "meant" is too strong here.  I play AAA Desktop applications, and some of them take the full screen, others offer different configurations, but usually not windowed in the way you mean it.  I have one graphical application that I have to use "reduced" in order to shrink the vertical enough so that the OS pop-up task bar does not interfere with it.  Other than that, I fill my screen with it.

@SoloByte
I find your approach very welcome.  The one thing that bothers me is saying that the InitWindow parameters have anything to do with resolution.  I think we get confused with resolution and the term is misused around computer monitors and desktop applications.  DPI is more helpful except it still doesn't account for viewing distance and the physical size of the monitor surface. so much.  I think the InitWindow request parameters are in pixels and it is probably the case that the numbers chosen there (and in positioning text and specifying text height) assume what platforms have as default DPI unless the application some means to know otherwise and adjust parameters accordingly.
PS: Some of the effects being noticed have to do with monitors having built-in scaling provisions for particular dimensions (in pixels).  Graphical drivers may rely on that.  You can usually see what's available in various situations where the different frame sizes (in pixels) are shown as options.  The best cinematic-quality game software tends to exploit that.  There may also be accessibility considerations here, but I have no idea how that is handled in quality software.

Also, I think ToggleBorderlessWindowed() definitively needs to be fixed, because it does not restore the borders of the window on my Linux ... :-/

ToggleBorderlessFullscreen & Toggle Fullscreen have to be definitely fixed.
Another issue with borderless fullscreen is on macOS it keeps the top task bar visible, meaning right now the only difference between borderless fullscreen and a maximized window on macOS is that borderless fullscreen uses the undecorated flag.

I find your approach very welcome. The one thing that bothers me is saying that the InitWindow parameters have anything to do with resolution. I think we get confused with resolution and the term is misused around computer monitors and desktop applications.

Thank you :) I will keep that in mind 👍

A little side note InitWindow() could have parameters for each config flag that can only be set before InitWindow() is called.
Currently those 4 flags have to be set before InitWindow():

Interlaced
Transparent
HighDPI
MSAA 4x

If they can only be set with the InitWindow() function and no longer with setting config flags or Set/ClearWindowState it would be much less confusing.
I can open a seperate issue for this as well if it is considered a good idea ;)

@SoloByte
I don't believe it's possible to set MSAA 4x after the window has been created.

I don't believe it's possible to set MSAA 4x after the window has been created.

Yes it has to be set before InitWindow like I said above ;) My idea is to have init window set them internally before initializing the window.

I think you'd better call that InitWIndowX().
Then there's a matter of explaining this to users of the raylib API.  That is, how do they determine how to set it.
In particular, how does one create a distributable desktop program that determine the proper situation on a given computer at run-time and also when monitors are adjusted or switched?
I think some clear use cases and what to do with them need to be considered.

I think you'd better call that InitWIndowX().
Then there's a matter of explaining this to users of the raylib API. That is, how do they determine how to set it.
I think some clear use cases and what to do with them need to be considered.

Absolutely. It could also be done differently. For me personally it was always confusing which flags actually have to be set before init window. Once I knew it I would forget it again in a couple of months and had to figure it out again ;)

In particular, how does one create a distributable desktop program that determine the proper situation on a given computer at run-time and also when monitors are adjusted or switched?

Those 4 flags I mentioned can´t be changed after InitWindow() was called, right? Can I call CloseWindow() and InitWindow() again whenever I need to change any of those 4 flags? Or do I have to restart the application to change the high dpi flag when a monitor was changed for instance?

My goal would be to clean up the config flags a bit with the window mode overhaul if possible.
For me there a 3 possible ways that I would like regarding window handling in raylib:

Raylib takes care of it and takes the responsibility that it works (means it has to work consistently across all platforms)
The system behind is more opened up to the user and the user is responsible for window handling
Combination of 1 & 2 where built in window handling can be used for prototyping, learning, etc. but it is also possible to do it yourself

I agree that the names of the functions themselves are relatively imprecise. But that's what we have to deal with for the sake of backward compatibility.
And that's also why I interpreted the intention of the functions according to their current source code implementations in the main GLFW platform backend.
ToggleFulllscreen() source code intentionally asks GLFW to change the hardware resolution of the display : it could be considered as an "hardware level fullscreen".
On the other hand, ToggleBorderlessWindowed() source code intentionally asks GLFW to resizes the window without decoration so it covers the whole desktop surface without changing the hardware resolution of the display : it could be considered as a "software level fullscreen".
Beyond that, there a consequences to take into consideration.
For example :

toggling "hardware level fullscreen" could be relatively slow and might cause unexpected problems on the end-user hardware ;
there are also issues between "hardware level fullscreen" and FLAG_WINDOW_HIGHDPI that make them incompatible. So you can't have them both, and anyway, using them together is irrelevant.

So, with current Raylib GLFW backend implementation, i think the programmer needs to be aware that they might not be able to use all features altogether, and that some are better suited for certain type of project, etc.
Of course, it is absolutely possible to rewrite the window management system of Raylib to make an universal solution that would just work out of the box without surprise, and without prior knowledge of what happens under the hood.
But that might be a large rework that might lead to backward incompatibilities.
I don't know how long it would take to be ready, but I personally don't want to wait or spend too much energy and time into it.
So, in the meantime, i'd personally rather try to fix or warkaround current bugs and issues.

@paulmelis I wonder about the nomenclature also.  Earlier today I opened one of the older AAA games I have (Assassins Creed Origins) and checked its options for Window Mode:  They are "Full Screen," "Windowed," and "Borderless."  There are few variations on this. I have seen "Full Screen (Windowed)" on occasion.  None of these are explained.  I always just go for Full Screen.  I suppose my point is that this is at the end-user level, and I can change those settings even with the game running but paused, although I usually go to such options just after start-up, as when I have installed a new monitor.

If i had to extend current Raylib API without breaking backward compatibility, I'd add these functions that could simplify the life of beginners and prototypers :
// Open a resizable window with a content surface of a fixed dimension
// that is rescaled and centered with black borders if required
void InitWindowWithFixedContentSize( int windowWidth , int windowHeight, int contentWidth, int contentHeight );

// Change the monitor resolution and display the window's content
// upscaled and centered with black borders if required
bool ToggleFullscreeenExclusiveMode( int monitor, int width, int height, int refreshRate );

// Like above, except that the resolution of the monitor is kept unchanged
bool ToggleFullscreeenDesktopMode( int monitor );

// And to work with ToggleFullsceenExclusiveMode() :
int GetMonitorSupportedResolutionsCount( int monitor );
Resolution GetMonitorSupportedResolution( int monitor, int resolutionIndex );

On the other hand, ToggleBorderlessWindowed() source code intentionally asks GLFW to resizes the window without decoration so it covers the whole desktop surface without changing the hardware resolution of the display : it could be considered as a "software level fullscreen".

For me this call does something slightly different: the window doesn't end up covering the full desktop, but leaves the MATE menu bar at the top uncovered. I need to set the window position to (0,0) after the call to get full desktop coverage:
if (IsKeyPressed(KEY_F))
{
            ToggleBorderlessWindowed();
            if (IsWindowState(FLAG_BORDERLESS_WINDOWED_MODE))
                SetWindowPosition(0, 0);

            printf("Screen size now %d x %d\n", GetScreenWidth(), GetScreenHeight());
            printf("IsWindowState(FLAG_BORDERLESS_WINDOWED_MODE) %d\n", IsWindowState(FLAG_BORDERLESS_WINDOWED_MODE));
}

However, when ToggleBorderlessWindowed() is then called a second time the window does not get back it decoration. The reported values are also not consistent:

@paulmelis : yes, i have similar issue too #4149 on my LinuxMint + MATE, except that the first call covers the whole desktop including the menu bar at the bottom on mine.
There is something fishy i could not identify clearly.

@paulmelis : yes, i have similar issue too #4149 on my LinuxMint + MATE, except that the first call covers the whole desktop including the menu bar at the bottom on mine.
There is something fishy i could not identify clearly.

Ah, good catch, interesting comments on GLFW in that issue

For me this call does something slightly different: the window doesn't end up covering the full desktop, but leaves the MATE menu bar at the top uncovered.

It does the same on macOS. It leaves the top bar uncovered.

I need to set the window position to (0,0) after the call to get full desktop coverage

I will test that on macOS and see what it does.

// Change the monitor resolution and display the window's content
// upscaled and centered with black borders if required
bool ActivateFullscreenExclusiveMode( int monitor, int width, int height, int refreshRate );

It should move the window to the specified monitor if the window is currently on a different monitor. How should the refresh rate be handled regarding vsync? Should/Does RestoreWindowedMode() also restore the refreshRate?

// Like above, except that the resolution of the monitor is kept unchanged
bool ActivateFullscreenDesktopMode( int monitor );

This function therefore sets the window size to the size of the specified monitor? (If a different resolution is required ActivateFullscreenExclusiveMode() can be used.) Currently this does not happen why I always have to set the window size to the monitor size if I want a fullscreen that does not change hardware resolution. The fullscreen also activates much faster this way.
It should also move the window to the specified monitor if the window is currently on a different monitor.

The bool return value tells you if the request was successfull?

It should move the window to the specified monitor if the window is currently on a different monitor. How should the refresh rate be handled regarding vsync? Should/Does RestoreWindowedMode() also restore the refreshRate?

Well, i'm not sure where you see a problem, because in my mind, when FLAG_VSYNC_HINT is enabled, it is up to GLFW and to the GPU to handle that.
From the programmer perspective, only the interaction of vsync with void SetTargetFPS(int fps); should matter.
Regarding RestoreWindowedMode(), i guess ActivateFullscreenExclusiveMode() would have to save current display mode before changing it, and RestoreWindowedMode() could just restore them.

The bool return value tells you if the request was successfull?

Yes, i think  it is particularly relevant with ActivateFullscreenExclusiveMode() in case a lazy programmer provided an unsupported resolution.

For me this call does something slightly different: the window doesn't end up covering the full desktop, but leaves the MATE menu bar at the top uncovered. I need to set the window position to (0,0) after the call to get full desktop coverage:

Does not work on macOS. If I set window position to (0,0) after the call the window moves further up into the corner of the monitor but it is now covered by the top bar.

If I implement my own borderless fullscreen by setting maximize & undecorated flags and then setting the window postion to (0,0) it just moves to window in the corner below the top bar.

It also means that currently you can not implement BorderlessFullscreen on your own and you rely on the ToggleBorderlessFullscreen() function.

Regarding RestoreWindowedMode(), i guess ActivateFullscreenExclusiveMode() would have to save current display mode before changing it, and RestoreWindowedMode() could just restore them.

I think this point is very important because currently exiting fullscreen does not properly restore window mode. bool ActivateFullscreenDesktopMode( int monitor ); should also do that.

Well, i'm not sure where you see a problem, because in my mind, when FLAG_VSYNC_HINT is enabled, it is up to GLFW and to the GPU to handle that.

Yes, I see it the same way. I am asking because currently (at least for me) vsync and fullscreen mode do not work well together. (choppy framerate that is lower than it should be)
The refresh rate parameter:

sets the frame rate with void SetTargetFPS(int fps); regardless of the vsync flag within raylib
if vsync is disable the specified refresh rate becomes the target fps
if vsync is enabled gpu / GLFW handle refresh rate

I am just trying to be overly clear so we don´t end up talking about different things were one side asumes something that the other side does not :)

edit : despite the lazy programmer might not even check the boolean ...

But it is still important because the current implementation does not tell you anything 😉

I think this point is very important because currently exiting fullscreen does not properly restore window mode. bool ActivateFullscreenDesktopMode( int monitor ); should also do that.

Maybe that would depend on how this fullscreen desktop mode would be implemented.
Obviously, we could not replicate what is currently done in ToggleBorderlessWidowed() since it leads to many unexpected issues regarding the menu-bar on Linux and Macos.
So, instead of trying to maximize an oversized and undecorated window, we could ask GLFW to do an hardware fullscreen of the same resolution and refresh rate that is currently active on the monitor.
This way, there would be no change at the hardware level, and this would be equivalent to what ToggleBorderlessWindowed() tries to do.
I quickly tested that approach yesterday. But I only tested with the main monitor, so i don't know if the desktop remain visible on secondary monitors, or if it is turned off (like back in the old time ways).
Also, the problem with this approach is that it seems to be incompatible with FLAG_WINDOW_HIGHDPI. (i say "seems" because i haven't fully read the GLFW documentation and might have missed details that could solve this issue)

sets the frame rate with void SetTargetFPS(int fps); regardless of the vsync flag within raylib

This one function is to set the frequency of the main loop by software (if i understood correctly).
The user might want to set it to very low frequency for various reasons, like debugging purpose, or special effects, or to change the frequency of the program.

if vsync is disable the specified refresh rate becomes the target fps

Not safe, since SetTargetFPS() could be set at arbitrary values as mentioned above.

if vsync is enabled gpu / GLFW handle refresh rate

In that case, the programmer might want to SetTargetFPS( 0 ); so the freq of the main loop does not interfere with the effect of vsync.

Note : there is also this compilation option to take into account : SUPPORT_CUSTOM_FRAME_CONTROL

So, instead of trying to maximize an oversized and undecorated window, we could ask GLFW to do an hardware fullscreen of the same resolution and refresh rate that is currently active on the monitor.
This way, there would be no change at the hardware level, and this would be equivalent to what ToggleBorderlessWindowed() tries to do.

This is actually exactly what the glfw docs say about how to achieve borderless fullscreen.

So we can simply use this for borderless fullscreen

and the same function where the user can specify position, size, refresh rate for "normal" fullscreen.

I just have tested this with glfw directly and implemented a borderless fullscreen with glfwSetWindowMonitor and it works perfect. It was just quick & dirty and only 1 monitor and I did not check anything else but the borderless fullscreen window covered the entire screen instantly and it restored the window correctly when exiting.
Beware it is c# again :)
if (currentWindowMode == WindowMode.Windowed)
{

//save current window pos & size
    glfw.GetWindowPos(window, out screenPositioX, out screenPositionY);
    glfw.GetWindowSize(window, out screenWidth, out screenHeight);

//get current monitor resolution
    var monitor = glfw.GetPrimaryMonitor();
    var videoMode = GetMonitorResolution(glfw, monitor);
    glfw.SetWindowMonitor(window, glfw.GetPrimaryMonitor(), 0, 0, videoMode->Width, videoMode->Height, videoMode->RefreshRate);

    currentWindowMode = WindowMode.BorderlessFullscreen;
}
else if (currentWindowMode == WindowMode.BorderlessFullscreen)
{
    glfw.SetWindowMonitor(window, null, screenPositioX, screenPositionY, screenWidth, screenHeight, 60);
    currentWindowMode = WindowMode.Windowed;
}

You have no mercy for my delicate eyes .....
I confirm it also work like a charm on my Linux system.
Tested with dual screen.
// Toggle borderless windowed mode
void ToggleBorderlessWindowed(void)
{
    // Leave fullscreen before attempting to set borderless windowed mode and get screen position from it
    bool wasOnFullscreen = false;
    if (CORE.Window.fullscreen)
    {
        CORE.Window.previousPosition = CORE.Window.position;
        ToggleFullscreen();
        wasOnFullscreen = true;
    }

    const int monitor = GetCurrentMonitor();
    int monitorCount;
    GLFWmonitor **monitors = glfwGetMonitors(&monitorCount);

    if ((monitor >= 0) && (monitor < monitorCount))
    {
        const GLFWvidmode *mode = glfwGetVideoMode(monitors[monitor]);

        if (mode)
        {
            if (!IsWindowState(FLAG_BORDERLESS_WINDOWED_MODE))
            {
                // Store screen position and size
                // NOTE: If it was on fullscreen, screen position was already stored, so skip setting it here
                if (!wasOnFullscreen) glfwGetWindowPos(platform.handle, &CORE.Window.previousPosition.x, &CORE.Window.previousPosition.y);
                CORE.Window.previousScreen = CORE.Window.screen;

                // Get monitor position and size
                int monitorPosX = 0;
                int monitorPosY = 0;
                glfwGetMonitorPos(monitors[monitor], &monitorPosX, &monitorPosY);

                glfwSetWindowMonitor(platform.handle, monitors[monitor], monitorPosX, monitorPosY, mode->width, mode->height, mode->refreshRate);

                // Refocus window
                glfwFocusWindow(platform.handle);

                CORE.Window.flags |= FLAG_BORDERLESS_WINDOWED_MODE;
            }
            else
            {
                // Return previous screen size and position
                int prevPosX = CORE.Window.previousPosition.x ;
                int prevPosY = CORE.Window.previousPosition.y ;
                int prevWidth = CORE.Window.previousScreen.width ;
                int prevHeight = CORE.Window.previousScreen.height ;
                glfwSetWindowMonitor(platform.handle, NULL, prevPosX , prevPosY, prevWidth, prevHeight, mode->refreshRate);

                // Refocus window
                glfwFocusWindow(platform.handle);

                CORE.Window.flags &= ~FLAG_BORDERLESS_WINDOWED_MODE;
            }
        }
        else TRACELOG(LOG_WARNING, "GLFW: Failed to find video mode for selected monitor");
    }
    else TRACELOG(LOG_WARNING, "GLFW: Failed to find selected monitor");
}

Ok, back again (false alarm, i pressed the wrong key in my test example)
I confirm it works like a charm on my Linux system with dual screen.
Here is the new candidate :
// Toggle borderless windowed mode
void ToggleBorderlessWindowed(void)
{
    // Leave fullscreen before attempting to set borderless windowed mode and get screen position from it
    bool wasOnFullscreen = false;
    if (CORE.Window.fullscreen)
    {
        CORE.Window.previousPosition = CORE.Window.position;
        ToggleFullscreen();
        wasOnFullscreen = true;
    }

    const int monitor = GetCurrentMonitor();
    int monitorCount;
    GLFWmonitor **monitors = glfwGetMonitors(&monitorCount);

    if ((monitor >= 0) && (monitor < monitorCount))
    {
        const GLFWvidmode *mode = glfwGetVideoMode(monitors[monitor]);

        if (mode)
        {
            if (!IsWindowState(FLAG_BORDERLESS_WINDOWED_MODE))
            {
                // Store screen position and size
                // NOTE: If it was on fullscreen, screen position was already stored, so skip setting it here
                if (!wasOnFullscreen) glfwGetWindowPos(platform.handle, &CORE.Window.previousPosition.x, &CORE.Window.previousPosition.y);
                CORE.Window.previousScreen = CORE.Window.screen;

                // Get monitor position and size
                int monitorPosX = 0;
                int monitorPosY = 0;
                glfwGetMonitorPos(monitors[monitor], &monitorPosX, &monitorPosY);

                glfwSetWindowMonitor(platform.handle, monitors[monitor], monitorPosX, monitorPosY, mode->width, mode->height, mode->refreshRate);

                // Refocus window
                glfwFocusWindow(platform.handle);

                CORE.Window.flags |= FLAG_BORDERLESS_WINDOWED_MODE;
            }
            else
            {
                // Return previous screen size and position
                int prevPosX = CORE.Window.previousPosition.x ;
                int prevPosY = CORE.Window.previousPosition.y ;
                int prevWidth = CORE.Window.previousScreen.width ;
                int prevHeight = CORE.Window.previousScreen.height ;
                glfwSetWindowMonitor(platform.handle, NULL, prevPosX , prevPosY, prevWidth, prevHeight, mode->refreshRate);

                // Refocus window
                glfwFocusWindow(platform.handle);

                CORE.Window.flags &= ~FLAG_BORDERLESS_WINDOWED_MODE;
            }
        }
        else TRACELOG(LOG_WARNING, "GLFW: Failed to find video mode for selected monitor");
    }
    else TRACELOG(LOG_WARNING, "GLFW: Failed to find selected monitor");
}

oh, this candidate needs to save and restore the refreshRate ...

@SuperUserNameMan
We could now fix the ToggleFullscreen() function to actually store the prev window size as well and restore the window on exiting fullscreen like you did. ToggleFullscreen could be exact same function as borderless fullscreen but it uses the current screen size instead of videoMode->width/height.
If fullscreen stores prev screen size as well you would could change this here as well.

// Store screen position and size
// NOTE: If it was on fullscreen, screen position was already stored, so skip setting it here
if (!wasOnFullscreen)
{
glfwGetWindowPos(platform.handle, &CORE.Window.previousPosition.x, &CORE.Window.previousPosition.y);
CORE.Window.previousScreen = CORE.Window.screen;
}

New functions for proper fullscreen
I just hacked them together real quick ^^
void RestoreWindowWindowed()
{
    if(CORE.Window.fullscreen || CORE.Window.borderlessFullscreen)
    {
        // Return previous screen size and position
        int prevPosX = CORE.Window.previousPosition.x ;
        int prevPosY = CORE.Window.previousPosition.y ;
        int prevWidth = CORE.Window.previousScreen.width ;
        int prevHeight = CORE.Window.previousScreen.height ;
        glfwSetWindowMonitor(platform.handle, NULL, prevPosX , prevPosY, prevWidth, prevHeight, GLFW_DONT_CARE);

        // Let's not wait for GLFW to call WindowSizeCallback to update these values :
        CORE.Window.screen.width = prevWidth ;
        CORE.Window.screen.height = prevHeight ;

        // Refocus window
        glfwFocusWindow(platform.handle);

        CORE.Window.flags &= ~FLAG_FULLSCREEN_MODE;
    }
    else TRACELOG(LOG_WARNING, "GLFW: Fullscreen or Borderless Fullscreen are not active.");

}
void SetWindowFullscreen(int monitor, int x, int y, int w, int h, int refreshRate)
{
    if(CORE.Window.fullscreen)
    {
        TRACELOG(LOG_WARNING, "GLFW: Fullscreen already enabled");
        return;
    }

    // Leave borderless fullscreen before attempting to set fullscreen mode and get screen position from it
    bool wasOnBorderlessFullscreen = false;
    if (CORE.Window.borderlessFullscreen)
    {
        CORE.Window.previousPosition = CORE.Window.position; // is this necessary? because previous position should be correct from enabled borderless fullscreen
        ToggleBorderlessWindowed(); //Could also use -> RestoreWindowedWindow()
        wasOnBorderlessFullscreen = true;
    }

    int monitorCount;
    GLFWmonitor **monitors = glfwGetMonitors(&monitorCount);

    if ((monitor >= 0) && (monitor < monitorCount))
    {
        // Store screen position and size
        // NOTE: If it was on borderless fullscreen, screen position & size was already stored, so skip setting it here
        if (!wasOnBorderlessFullscreen){
            glfwGetWindowPos(platform.handle, &CORE.Window.previousPosition.x, &CORE.Window.previousPosition.y);
            CORE.Window.previousScreen = CORE.Window.screen;
        }

        glfwSetWindowMonitor(platform.handle, monitors[monitor], x, y, w, h, refreshRate);

        // Let's not wait for GLFW to call WindowSizeCallback to update these values :
        CORE.Window.screen.width = w ;
        CORE.Window.screen.height = h ;

        // Refocus window
        glfwFocusWindow(platform.handle);

        CORE.Window.flags |= FLAG_FULLSCREEN_MODE;

    }
    else TRACELOG(LOG_WARNING, "GLFW: Failed to find selected monitor");
}

    bool wasOnFullscreen = false;
    if (CORE.Window.fullscreen)
    {
        CORE.Window.previousPosition = CORE.Window.position;
        ToggleFullscreen();
        wasOnFullscreen = true;
    }

CORE.Window.previousPosition = CORE.Window.position;

This line should also no longer be necessary when toggle fullscreen properly saves previous position/size.

Ok, let's talk about fixing ToggleFullscreen() into your other related issue #4145 so we keep this one about improving Raylib API.

in case you're interested, i've found an old and unused SetDimensionsFromMonitor()
https://github.com/raysan5/raylib/blob/74680748b9abe05ceda5d412b61ff99addf72807/src/platforms/rcore_desktop_glfw.c#L1224

I have added this to the related issues.

Please, excuse my lack of response on these issues, it's quite overwhelming and I need some time to read through them.
In any case, many thanks to all of you for reviewing windowing system and fullscreen.

@raysan5 : note that some of my statements here might be outdated by the pending and WIP PR #4151


[1.5.x]Removing unnecessary ' from modified type, variable name after escaping special characters

Purpose

Fix # https://github.com/wso2-enterprise/internal-support-ballerina/issues/360

Automation tests

Unit tests - Added

Code coverage information

Integration tests

Details about the test cases and coverage

Security checks

Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines? yes/no
Ran FindSecurityBugs plugin and verified report? yes/no
Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? yes/no

Samples

Provide high-level details about the samples related to this feature

Related PRs

List any other related PRs

Migrations (if applicable)

Describe migration steps and platforms on which migration has been tested

Test environment

List all JDK versions, operating systems, databases, and browser/versions on which this feature/fix was tested

Learning

Describe the research phase and any blog posts, patterns, libraries, or add-ons you used to solve the problem.

@lnash94 Do we have diagnostics tests to verify that we'll not have compilation issues after removing the quote in all these cases?

We haven't added diagnostic test improvements to branches 1.5.x, 1.6.x, and 1.7.x. We have only included these improvements in the master branch. Therefore, I have added unit tests as usual to these branches and enabled diagnostic tests for the master branch. Are we planning to backport these test improvements (https://github.com/ballerina-platform/openapi-tools/pull/1418) to the 1.5.x, 1.6.x, and 1.7.x branches?

@lnash94 Do we have diagnostics tests to verify that we'll not have compilation issues after removing the quote in all these cases?

We haven't added diagnostic test improvements to branches 1.5.x, 1.6.x, and 1.7.x. We have only included these improvements in the master branch. Therefore, I have added unit tests as usual to these branches and enabled diagnostic tests for the master branch. Are we planning to backport these test improvements (#1418) to the 1.5.x, 1.6.x, and 1.7.x branches?

The issue is, unit tests we've added here won't cover any compilation issues which can be introduced with these changes. anyway lets proceed with the unit tests for now as we can backport the service diagnostics tests as a separate effort anyway


AutoRotate module dosn't rotate an image

Hello @JimBobSquarePants
Please correct me if I'm wrong.
If I set in the processing.config the value for preserveExifMetaData to true then AutoRotate won't work according to your code (see below)?
https://github.com/JimBobSquarePants/ImageProcessor/blob/c36a37d250432a6e93bc4b1a04410ddc2e193c02/src/ImageProcessor/Processors/AutoRotate.cs#L73
The value for preserveExifMetaData reverts.
So, I need to set this value to false to make it work, am I right?

Autorotate applies the correct rotation that represents EXIF instruction that is not preserved when metadata is not stored.


Remove QUIC version hint

Fixes #2171

Codecov Report

Merging #2173 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2173      +/-   ##
==========================================
+ Coverage    86.5%   86.51%   +0.01%
==========================================
  Files         104      104
  Lines        7487     7480       -7
==========================================
- Hits         6476     6471       -5
+ Misses        750      748       -2
  Partials      261      261

Impacted Files
Coverage Δ

internal/protocol/version.go
100% <ø> (+4%)
:arrow_up:

http3/server.go
65.16% <100%> (-0.77%)
:arrow_down:

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 3ea7ad1...f110af9. Read the comment docs.


Audio

3 sounds:
movement / advance
loss
capture (6 values convey 1 to 36)

a chord that symboliize each step

figure out crackle; also find less ambiguous sound for lost piece (eg. buzzer)


Licensing

The notebooks in the old juliaopt-notebooks repo had the Creative Commons Attribution-ShareAlike 4.0 International License. Do we need to look into licensing for these tutorials as well?
@mlubin @juan-pablo-vielma

Yes. It's important to have a valid license on the tutorials. The MIT license is valid for documentation but is designed for code more than for text. That said, MIT seems reasonable.


chmod all sub files and folders in temp directory

Replaces #6461. Thanks to @sriram-dev to all the work, I only merged master to resolve a conflict.
Fixes #5059.
/cc @zaggino @ingorichter

looks good, merged


what to do around frequent false positives (might be a case of me needing to learn to triage better with nix)

vulnix thinks my drv is uses jetbrains hub when the drv holds https://github.com/tektoncd/hub
This is also the case for other dependencies collected by gomod2nix
λ vulnix ./result
22 derivations with active advisories

------------------------------------------------------------------------
bash-4.4-p23

/nix/store/ay54nhnk1md3ygj8s877d6n3721l2dyz-bash-4.4-p23.drv
CVE                                                CVSSv3
https://nvd.nist.gov/vuln/detail/CVE-2019-18276    7.8

# ...

------------------------------------------------------------------------
hub-0ae1afc

/nix/store/ni50vpsf4kclcbd8d6flk127nh8mx8pb-hub-0ae1afc.drv
CVE                                                CVSSv3
https://nvd.nist.gov/vuln/detail/CVE-2021-36209    9.8
https://nvd.nist.gov/vuln/detail/CVE-2020-11691    7.5
https://nvd.nist.gov/vuln/detail/CVE-2021-31901    7.5
https://nvd.nist.gov/vuln/detail/CVE-2019-12847    7.2
https://nvd.nist.gov/vuln/detail/CVE-2021-25759    6.5
https://nvd.nist.gov/vuln/detail/CVE-2021-37540    6.5
https://nvd.nist.gov/vuln/detail/CVE-2021-25757    6.1
https://nvd.nist.gov/vuln/detail/CVE-2021-37541    6.1
https://nvd.nist.gov/vuln/detail/CVE-2019-14955    5.3
https://nvd.nist.gov/vuln/detail/CVE-2019-18360    5.3
https://nvd.nist.gov/vuln/detail/CVE-2021-25760    5.3

# ...

------------------------------------------------------------------------
util-linux-2.36.2

/nix/store/2c9ab725kccddpjlxb5r8s1hxzbrjdqq-util-linux-2.36.2.drv
CVE                                                CVSSv3
https://nvd.nist.gov/vuln/detail/CVE-2021-37600    5.5

λ nix why-depends /nix/store/xkfmhy8za4jhlzk0iav0mm52wd2s4lji-vendor-env.drv /nix/store/ni50vpsf4kclcbd8d6flk127nh8mx8pb-hub-0ae1afc.drv
└───github.com/tektoncd/hub/api -> /nix/store/3qa9ymxypdd5xv0jvxk4f4b9d83mv0py-hub-0ae1afc/api
    → /nix/store/3qa9ymxypdd5xv0jvxk4f4b9d83mv0py-hub-0ae1afc
/nix/store/gmsm2cwync8nsnpqnwq6sg3nwfrqfwjl-vendor-env

λ ls -l /nix/store/gmsm2cwync8nsnpqnwq6sg3nwfrqfwjl-vendor-env/github.com/tektoncd/hub
lrwxrwxrwx root root 59 B Thu Jan  1 01:00:01 1970  api ⇒ /nix/store/3qa9ymxypdd5xv0jvxk4f4b9d83mv0py-hub-0ae1afc/api

Is there anything vulnix can do or should gomod2nix just change the drv names? or both?

I also a buildGoModule based build
vulnix thinks it uses a vulnerable w3m during build but I can't find it
λ vulnix ./result
16 derivations with active advisories

------------------------------------------------------------------------
bash-4.4-p23

/nix/store/ay54nhnk1md3ygj8s877d6n3721l2dyz-bash-4.4-p23.drv
CVE                                                CVSSv3
https://nvd.nist.gov/vuln/detail/CVE-2019-18276    7.8

------------------------------------------------------------------------
binutils-2.35.1

/nix/store/z4sfszir1p0077xw55bki07yjshymcs9-binutils-2.35.1.drv
CVE                                                CVSSv3
https://nvd.nist.gov/vuln/detail/CVE-2021-20294    7.8
https://nvd.nist.gov/vuln/detail/CVE-2021-3487     6.5
https://nvd.nist.gov/vuln/detail/CVE-2021-20284    5.5

# ...

------------------------------------------------------------------------
w3m-0.5.3+git20190105

/nix/store/h0j15nrdh0y9yng5ylg3qm1427j9ky1y-w3m-0.5.3+git20190105.drv
CVE                                                CVSSv3
https://nvd.nist.gov/vuln/detail/CVE-2016-9422     8.8
# ...
https://nvd.nist.gov/vuln/detail/CVE-2016-9633     6.5

λ nix why-depends ./result /nix/store/h0j15nrdh0y9yng5ylg3qm1427j9ky1y-w3m-0.5.3+git20190105.drv
this path will be fetched (0.73 MiB download, 1.69 MiB unpacked):
  /nix/store/hvq53cdwdbmkd26y5qh0lgwgzy3sbqfi-w3m-0.5.3+git20190105
'/nix/store/ly9bhnp0lmc7n76ks0vgarildp49pwy9-tkn-utils-0.0.1' does not depend on '/nix/store/hvq53cdwdbmkd26y5qh0lgwgzy3sbqfi-w3m-0.5.3+git20190105'

# done a manual search too
nix show-derivation ./result -r | bat -l json

I am indeed encountering similar issues with, e.g. shellcheck being mistaken for the shellcheck unofficial extension for VS Code.


Glerror 1282 after view matrix is set.

running glerror on 3Drendering.py kivy example right after the projection or model matrix shows error 1282, spent ages trying to track this down in my code :p
the changes i made are in this gist https://gist.github.com/olymk2/49db889c94488bed5019
def gl_error(self, text = '', kill=True):
err = glGetError()
if not err:
return
while err:
print '## GL ## = ' + text + 'OPENGL Error Code = ', err
err = glGetError()

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

using opengl debugging i can see use_shader is being cleared which is likely causing the issue,
('GL glUseProgram( program = ', 0, ', )')
('GL glUniformMatrix4fv( location = ', 2, ', count = ', 1, ', transpose = ', 0, ', value*=', "'0x7fffc12106e0'", ', )')
OpenGL Error 1282 / 502

I have been looking into this it looks like when you use schedule an update interval it calls your update method but does not make the shader active before trying to set any uniforms on the current program.
still not sure on a fix


Preview directly the final website

Is your feature request related to a problem? Please describe.
The default preview is usually very different from the actual website, making it hard to visualize the final result. While it is possible to customize it, it basically requires me to code my website twice, once for the actual website and one for the preview. Moreover, I don't think it is possible to actually extract the content from other .md files, for instance to print a menu or a list previewing other pages.
Describe the solution you'd like

Of course, I understand this is impossible to get easily for some framework like hugo without relying on WASM. But for js CMS based on react/vuejs/svelte, it might be possible to have a better solution. For instance TinaCms provides a react hook that can be used while building the website that will pick the new content when executed from the preview tab.
https://tina.io/docs/features/data-fetching/
https://tina.io/docs/contextual-editing/overview/
Describe alternatives you've considered

Manualy coding a new style for the prev, see drawbacks in first section.
Additional context

See also https://github.com/decaporg/decap-cms/discussions/7178

You can add an npm script that copies your stylesheet over to your public folder and use CMS.registerPreviewStyle('path/to/stylesheet.css') to register the styles for the preview.

Thanks, but what about more involved things involving other things, like the menu of the website for instance (that depends on other pages), or, say that I want to create a component that link to other pages while printing there main image and a short description of the page etc… seems like it's hard to print correctly.


Instead of storing redundant data in SQL for lookup, use ULib.ucl

Instead of storing redundant data in SQL for lookup you should use ULib.ucl.  This table contains all data that is needed, it is indexed by steamid and contains the group and username. For EX (from PrintTable(ULib.ucl) and anonymised);
STEAM_0:0:00000000:
                                allow:
                                deny:
                                group   =       admin
                                name    =       myusername

This would work fine, but would make WUMA dependent on ULib.


Create 000-01-02-Anjalydav.md

created a branch, created a file and made a commit, and opened a pull request

created a branch, created a file and made a commit, and opened a pull request


Improved Documentation and Examples

I have a basic example provided, but there are much more advanced ways of using this that could help someone get started. If someone has a small standalone app that turns an HX711 into a fully functional scale interface, that would be a great addition to the repo.
The ReadMe could also be improved to include more info about the HX711 itself.

Closing as the latest improvements are adequate


quark-engine: 23.2.1 -> 23.4.1

Changelog: https://github.com/quark-engine/quark-engine/releases/tag/v23.4.1
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 230405 run on x86_64-linux 1

2 packages built:

quark-engine
quark-engine.dist


Set a fixed height for pane?

How do I make a pane have a fixed height say 300px

If you read the readme:
https://github.com/roman-rr/cupertino-pane#breakpoints
You can for example disable the bottom and the top breakpoint and give the middle one the height you need

Thank you @EinfachHans, all right! Can also make free mode or disable lowerThanBottom to better effect of fixed position.
@ejirocodes  And if you want to set height for presented pane you can try .moveToHeight() method.

If you read the readme:
https://github.com/roman-rr/cupertino-pane#breakpoints
You can for example disable the bottom and the top breakpoint and give the middle one the height you need

Got it. Thanks man


[firebase_messaging] _TypeError (type 'List' is not a subtype of type 'List')

Description
flutter version: 1.22.4
firebase_messaging version: 8.0.0-dev.11
I get the following error:
_TypeError (type 'List<dynamic>' is not a subtype of type 'List<String>')
The exception is caught in remote_notification.dart while calling:
return RemoteNotification(
      title: map['title'],
      titleLocArgs: map['titleLocArgs'] ?? [],
      titleLocKey: map['titleLocKey'],
      body: map['body'],
      bodyLocArgs: map['bodyLocArgs'] ?? [],
      bodyLocKey: map['bodyLocKey'],
      android: _android,
      apple: _apple,
    );

The exception is thrown by titleLocArgs and bodyLocArgs. These are defined as List<String>.
Seems like these lists are truly List<String>s but somehow Dart cannot cast them and they appear as List<dynamic> therefore I get the error mentioned above. When I place a breakpoint in the constructor and check the type this way:
map['titleLocArgs'] is List<String> I get false.
The interesting part is I created a map in DartPad which is structured the same way and it says the expression is true.
Any ideas why this happens? Dart version is 2.10.4 both for Flutter and DartPad.

@csbence10
Can you provide a minimal complete reproducible code sample that shows the issue ?
Thanks.

@darshankawar
Of course. Open Postman and compose the following API request:
Method: POST
URL: https://fcm.googleapis.com/fcm/send
Headers:

Content-Type: application/json
Authorization: key=<your_server_key>  <- found in the Firebase Console - Project settings - Cloud messaging menu

Body:
{
	"to" : "<your_fcm_token>",
	"collapse_key" : "whatever_you_prefer",
        "notification": {
                "body" : "Body",
		"title": "Title",
                "android": {},
                "title_loc_args": [""],
                "body_loc_args": [""]
    },
	"data" : {
        "click_action": "FLUTTER_NOTIFICATION_CLICK"
	}
}

Then click send. If the you get a success = 1 in the response, everything is fine.
Your app should be in the background and when you get the notification pull down the "notification center" or whatever it's called on Android and click on the notification. Your app comes back to the foreground and you get the error message I mentioned in my original post.
I hope that helps reproduce the issue. If not tell me and I'll help.
Cheers.

@csbence10 Thanks for the details. I was able to replicate the error and get:
_TypeError (type 'List<dynamic>' is not a subtype of type 'List<String>')
The titleLocArgs and bodyLocArgs are indeed declared as List<String> in RemoteNotification.dart inside firebase_messaging_platform_interface : https://github.com/FirebaseExtended/flutterfire/blob/master/packages/firebase_messaging/firebase_messaging_platform_interface/lib/src/remote_notification.dart
final List<String> titleLocArgs;
final List<String> bodyLocArgs;

flutter doctor -v

[✓] Flutter (Channel stable, 1.22.4, on Mac OS X 10.15.4 19E2269 darwin-x64,
    locale en-IN)
    • Flutter version 1.22.4 at /Users/dhs/documents/Fluttersdk/flutter
    • Framework revision 1aafb3a8b9 (4 weeks ago), 2020-11-13 09:59:28 -0800
    • Engine revision 2c956a31c0
    • Dart version 2.10.4

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
    • Android SDK at /Users/dhs/Library/Android/sdk
    • Platform android-30, build-tools 30.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.0.1, Build version 12A7300
    • CocoaPods version 1.9.3

[✓] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 46.0.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6222593)

[✓] VS Code (version 1.51.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.16.0

[✓] Connected device (3 available)
    • SM A260G (mobile)                   • 5200763ebcfa861f
      • android-arm • Android 8.1.0 (API 27)
    • sdk gphone x86 arm (mobile)         • emulator-5554
      • android-x86 • Android 11 (API 30) (emulator)
    • iPhone SE (2nd generation) (mobile) • 6C85835D-FBFD-4AB3-8DE8-B4FAD35E5367
      • ios         • com.apple.CoreSimulator.SimRuntime.iOS-14-0 (simulator)

• No issues found!

Hmm, these might need changing to:
titleLocArgs: List<String>.from(map['titleLocArgs']) ?? [],

I guess the type from native is coming through as dynamic.

@csbence10 I've just pushed a PR for this, however my local setup is complaining about running tests which I'm looking into (some local Dart thing). That fix should solve it (I think..) however I want to get a proper test in place.
I think you can pull locally via
  firebase_messaging_platform_interface:
    git:
      url: https://github.com/FirebaseExtended/flutterfire
      path: packages/firebase_messaging/firebase_messaging_platform_interface
      ref: 20a8a33276d07d7d0386fc59e773d257b46b3c71

@Ehesp, thank you!
Works fine!

I have the same issue when receiving a background notification. Then the app crashes. How can I include your fix to my project?
The following...
  firebase_messaging: "^8.0.0-dev.11"     firebase_messaging_platform_interface:     git:       url: https://github.com/FirebaseExtended/flutterfire       path: packages/firebase_messaging/firebase_messaging_platform_interface       ref: 20a8a33276d07d7d0386fc59e773d257b46b3c71
..gives me the error: Because firebase_messaging 8.0.0-dev.11 depends on firebase_messaging_platform_interface ^1.0.0-dev.7 and no versions of firebase_messaging match >8.0.0-dev.11 <9.0.0, firebase_messaging ^8.0.0-dev.11 requires firebase_messaging_platform_interface from hosted.

Hi 👋
I have a similar issue when I use..  ```
String token = await messaging.getToken(
vapidKey: "BGpdLRs......",
);
..I got :
`I/flutter (12122): type '_InternalLinkedHashMap<dynamic, dynamic>' is not a subtype of type 'String' in type cast`

@drosa88
I had the same problem. I found a workaround:
dependencies:
<your_dependencies_here>
firebase_messaging: 8.0.0-dev.11

dependency_overrides:
  firebase_messaging_platform_interface:
    git:
      url: https://github.com/FirebaseExtended/flutterfire
      path: packages/firebase_messaging/firebase_messaging_platform_interface
      ref: 20a8a33276d07d7d0386fc59e773d257b46b3c71

However, I don't know whether this is the proper way or not. Also, I deleted the pubspec.lock file and the
<your_path_to_flutter>/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_messaging_platform_interface-1.0.0-dev.7  just to be sure.

@drosa88
I had the same problem. I found a workaround:

dependencies:

<your_dependencies_here>

firebase_messaging: 8.0.0-dev.11

dependency_overrides:

  firebase_messaging_platform_interface:

    git:

      url: https://github.com/FirebaseExtended/flutterfire

      path: packages/firebase_messaging/firebase_messaging_platform_interface

      ref: 20a8a33276d07d7d0386fc59e773d257b46b3c71

However, I don't know whether this is the proper way or not. Also, I deleted the pubspec.lock file and the
<your_path_to_flutter>/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_messaging_platform_interface-1.0.0-dev.7  just to be sure.

Thank you! 👍

The trick is to use the fix version firebase_messaging: 8.0.0-dev.14 without the ^.
In my case it automatically updated the dev version to 8.0.0-dev.15 (which has obviously a bug in it) because of the ^.
After removing it and running pub get it worked as expected.
Can't wait for the next stable version, which apparently will be 9 instead of 8.
Hope that helps :)

The trick is to use the fix version

The trick is to use the fix version firebase_messaging: 8.0.0-dev.14 without the ^.
In my case it automatically updated the dev version to 8.0.0-dev.15 (which has obviously a bug in it) because of the ^.
After removing it and running pub get it worked as expected.
Can't wait for the next stable version, which apparently will be 9 instead of 8.
Hope that helps :)

Sry to disappoint you: It worked once for me for some reason and then it stopped working even with version 8.0.0-dev.14..

Fun Fact: This problem only exists on a physical iPhone. On the Simulator it works fine.

Closing as this was fixed in https://github.com/FirebaseExtended/flutterfire/pull/4382 by @Ehesp a while back.


Localize 'Cancel' button

Hello. Control buttons (ok and cancel) stay the same even if I pick some localization.
Environment

Tech
Version

material-ui-pickers
1.0.0-rc.14

material-ui
1.5.1

React
16.4.2

Browser
every

Peer library
date-fns 2.0.0-alpha.16

Screenshot from your site

My app:

Do you think we need to bundle and provide all translations for all locales? You must do it by yourself

Pass custom label for ok and cancel

Do you think we need to bundle and provide all translations for all locales? You must do it by yourself
I did not mean for all localizations but for existing. But ok, I will pass by myself. Thanks.

How did I pass the text to the cancelLabel ? It's a ReactNode property ?

Yes it is react node

clearLabel={React.createElement('span', null, 'Limpar')}
cancelLabel={React.createElement('span', null, 'Cancelar')}


Techdebt: MyPy Moto-API

Codecov Report

Merging #5663 (8548b6c) into master (b0b9439) will increase coverage by 0.00%.
The diff coverage is 97.87%.

@@           Coverage Diff           @@
##           master    #5663   +/-   ##
=======================================
  Coverage   96.20%   96.20%
=======================================
  Files         743      743
  Lines       72742    72747    +5
=======================================
+ Hits        69979    69984    +5
  Misses       2763     2763

Flag
Coverage Δ

servertests
36.88% <82.97%> (+<0.01%)
:arrow_up:

unittests
96.14% <97.87%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

moto/moto_api/_internal/recorder/models.py
92.30% <92.85%> (ø)

moto/moto_api/_internal/managed_state_model.py
100.00% <100.00%> (ø)

moto/moto_api/_internal/models.py
100.00% <100.00%> (ø)

moto/moto_api/_internal/recorder/responses.py
100.00% <100.00%> (ø)

moto/moto_api/_internal/responses.py
90.14% <100.00%> (+0.28%)
:arrow_up:

moto/moto_api/_internal/state_manager.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Pod Install has LICENSE warning

Describe the bug
I am getting a warning when running pod install, related to the CocoaPod attached to this package:
[!] Unable to read the license file 'LICENSE' for the spec 'SwiftAudioEx (0.13.2)'

This shows four times at the very end of the Pod install.

To Reproduce
run pod install
Environment
react-native - 0.65.1
react-native-track-player - 2.0.3
Xcode - 12.4
CocoaPods - 1.10.1

I've got same problem

Same.

Same, v2.1.0

Same here, and impossible to build the app after this error

I have same error

This is just a warning and does not affect the pod install process. This does not cause build errors.
We'll still aim to fix it in a later release though.

how to fix it
thanks

@nguyenductoan1995 looks like this is a different bug. looks like you're using Xcode 13. Make sure you're on the latest version of react-native-track-player where we a

dded support for Xcode 13.
i can't pod install in lastest version

@nguyenductoan1995 you have to set your minimum deployment target to iOS 11. instead of 10. in the Podfile too.
Take a look at the CHANGELOG here: https://github.com/DoubleSymmetry/react-native-track-player/blob/main/CHANGELOG.md#210-160921

thank you so much, it resloved

Thanks @burdisal are you able to create a PR to fix this?
Cheers


Determine the feasibility of compiling Indy SDK for x86

AFJ depends on the Indy SDK to communicate with ledgers. This SDK compiles for Arm architecture but not x86 architecture. It would be good to have it compile for both so that it can run on iOS simulators to speed up development and testing.

May be related to https://github.com/rust-lang/rust/issues/81632

We are expecting this will be addressed by the new indy vdr/shared libraries


Exclude teammates' Builds

Describe your changes

Solve negative number UI problem
Add a checkbox to use/ignore teammates loadouts
Still needs Translation

Issue or discord link
Fix: #1548

Testing/validation

Checklist before requesting a review (leave this PR as draft if any part of this list is not done.)

[ ] I have commented my code in hard-to understand areas.
[ ] I have made corresponding changes to README or wiki.
[ ] For front-end changes, I have updated the corresponding English translations.
[ ] I have run yarn run mini-ci locally to validate format and lint.
[ ] If I have added a new library or app, I have updated the deployment scripts to ignore changes as needed

NOOOOO, wait


net: lwm2m: Handle empty URI

On some content-types, it might be impossible to
send strings with size of zero.
Therefore empty URI should also allow cases
where strlen() is zero.

After a bit more investigating, it looks like I broke this in 95cef5f3ab69d3afe93d7fc2498dd509f9847ec0
Apparently half a year is not enough to find all corner cases for string handling.


[AutoPR-sdkreleaseplannertest]SDK Release Planner Test PR

Create to sync https://github.com/Azure/azure-rest-api-specs/pull/21720

/azp run java - sdkreleaseplannertest - ci

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-sdkreleaseplannertest

/azp run java - sdkreleaseplannertest - ci

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-sdkreleaseplannertest


[Idea 💡] Use "environment-url" output of the "create-environment" action in workflows

Currently we use a custom output configured in the create-build-environment job in different workflows of this repository for the domain name of the just in time build environment that we combine with other variables to generate the environment URL with use in other actions (like Import solution as unmanaged to build env).
It would be definitely better to use the environment-url output provided in the create-environment action.

Issue in standby while waiting for an answer on the following issue: microsoft/powerplatform-actions - [create-environment] "environment-url" output "masked"

The issue with url in outputs now seems resolved.
We will be able to work on this issue.

First tests already done on the workspace initialization workflow.


'ft2build.h' file not found creating a build

Doing:
$ git clone https://github.com/HipByte/motion-game.git
$ cd motion-game.git
$ rake build:ios
In file included from 2d/CCFontFreeType.cpp:26:
./2d/CCFontFreeType.h:34:10: fatal error: 'ft2build.h' file not found
#include <ft2build.h>
         ^
1 error generated.
rake aborted!

brew install freetype
Warning: freetype-2.6.3 already installed
Same issue, any idea? and thanks!

You don't need to install freetype.
Instead, you need to run "rake build:setup" following README

@Watson1978 Thank you so much, it works perfectly creating the build locally. :+1:


routing: inbound fees send support

Implements send support for inbound routing fees. The receiver side is implemented in #6703 and this PR is based off of that.
Implementation details

The channel_update extra opaque data isn't validated before it was stored in the database. This means that everywhere we read this data, a tlv error might be encountered. In this PR, this case is handled in a mostly defensive way, skipping over the channel policy.

Based on #6703. Review first commits there.
Support for inbound fees in BuildRoute is explored in #7060.

Removed exit hop inbound fees. Previous code saved in https://github.com/lightningnetwork/lnd/compare/master...bottlepay:lnd:inbound-fees-send-support-exit-hop

What would be needed to get his PR out of draft?

I think it is pretty complete as is. Definitely good enough to be moved out of draft, so I did.

Would you keep the current penalization scheme for failures? It seems like with inbound discounts, the channel partner would also need to be blamed more, as they can offset outbound fees of their peer, where a payment attempt wouldn't have happened otherwise with high outbound fees only.

Afaik when the node with a high inbound discount is not delivering, it is penalized as part of a pair of nodes. Do you think that is insufficient?

I think it would be safer for people to experiment with if negative fees were scoped out so that no net negative possibility was allowed - lower bound on a fee would be zero basically, this kind of thing could also be added in the proto comments or somewhere to tell people how to play with it

One thing to keep in mind is that there are two definitions of the 'total fee':

Node total fee: the sum of inbound and outbound fee charged by a routing node.
Channel total fee: the outbound fee charged at the sending end of a channel plus the inbound fee charged at the receiving end of that same channel.

For example in the example below, channel total fee is -2 (negative) but node total fee is 1 (positive).
[A] out: 5 ---> in: -7 [B] out: 8 --->
In #6703, a protection is implemented so that nodes only forward when node total fee is non-negative.
Pathfinding however is a channel-based search. Each round the route is extended with another channel based on the channel total fee. Negative channel total fees are already treated as being zero, to prevent nodes from making themselves infinitely attractive by means of a deeply negative fee.
When a best route has been found however, as second pass is going to redo the fees and take advantage of any negative fees that might have been rounded up to zero during search.

Afaik when the node with a high inbound discount is not delivering, it is penalized as part of a pair of nodes. Do you think that is insufficient?

Right, but it wouldn't have an effect on the inbound fee node's reputation as only the outgoing pairs count for that (there would be only incoming info in the scenario here), if I understand correctly. An alternative would be to also fail the reverse direction should (outbound fee + inbound fee) < threshold, in case of a temporary channel failure. The threshold could be dependent on the outbound fee, perhaps half of it?

One thing to keep in mind is that there are two definitions of the 'total fee'

Great point, thanks for the clarification, I was aware that there are two ways to compute a fee, but not 100% aware that the pathfinder uses the total channel fee as opposed to route construction where the node total fee is used.

I think it would be safer for people to experiment with if negative fees were scoped out so that no net negative possibility was allowed - lower bound on a fee would be zero basically, this kind of thing could also be added in the proto comments or somewhere to tell people how to play with it

Just wanted to recap, so it makes sense to limit the node total fees to zero as a safety measure on the forwarding side, which is already the case in the other PR. On the sender side here, only the total channel fees are limited to zero, because a way to deal with negative fees is not obvious (and nodes shouldn't be able to make them too attractive).
This can lead to routes that exhibit negative node total fees if the inbound discounts are not capped as mentioned, which leads to routing failures. The sender doesn't know whether the router allows negative fees, so the sender would be more successful if it always constructs routes with non-negative total node fees. On the other hand, a sender can upgrade any time (and there are different implementations) and once they figure out how they want to exploit negative fees they could opt into that if routers allow for it. This looks like routers would need to signal that they allow negative fees, which then could be used in route construction to decide on whether node total fees should be capped or not?

Afaik when the node with a high inbound discount is not delivering, it is penalized as part of a pair of nodes. Do you think that is insufficient?

Right, but it wouldn't have an effect on the inbound fee node's reputation as only the outgoing pairs count for that (there would be only incoming info in the scenario here), if I understand correctly. An alternative would be to also fail the reverse direction should (outbound fee + inbound fee) < threshold, in case of a temporary channel failure. The threshold could be dependent on the outbound fee, perhaps half of it?

In the scenario that we are talking about, the node with the high inbound discount is malicious. But a malicious node is - also without inbound fees - able to direct a penalty to either its incoming or outgoing side depending on the type of failure that it returns.
I don't fully understand what you mean by reverse direction and how a threshold comes into play. I think there is a case to be made for stronger penalization, but that this case is pre-existing. In fact, when building the current penalization scheme, there also was a variant with undirected pair penalties.

Just wanted to recap, so it makes sense to limit the node total fees to zero as a safety measure on the forwarding side, which is already the case in the other PR. On the sender side here, only the total channel fees are limited to zero, because a way to deal with negative fees is not obvious (and nodes shouldn't be able to make them too attractive).
This can lead to routes that exhibit negative node total fees if the inbound discounts are not capped as mentioned, which leads to routing failures. The sender doesn't know whether the router allows negative fees, so the sender would be more successful if it always constructs routes with non-negative total node fees. On the other hand, a sender can upgrade any time (and there are different implementations) and once they figure out how they want to exploit negative fees they could opt into that if routers allow for it. This looks like routers would need to signal that they allow negative fees, which then could be used in route construction to decide on whether node total fees should be capped or not?

I think it is worth going back to the starting point with this. The cap in the other PR was added to prevent routing node operators from accidentally losing money on forwards because of misconfiguration. It is implemented as part of the forwarding logic, but it could also have been part of the policy update logic. Or even just been enforced externally by node mgmt tools.
In the context of this PR, we are discussing adding even more protection for node operators so that in the case that they made a configuration error, they will not only not lose money, but also that senders are adapting to their configuration error by increasing the fee. With this, there is no reason for routing nodes to worry about those config errors anymore. And indeed, if a routing node operator does want a truly negative fee, they'd need to signal.
Zooming out, it feels that all of this is going into the direction of a complex solution for a simple problem. If you are concerned about the footgun, I think it is better to go back to #6703 and fix the update policy logic so that there can never be a combination of in and out channel that makes for a negative total fee.

In the scenario that we are talking about, the node with the high inbound discount is malicious. But a malicious node is - also without inbound fees - able to direct a penalty to either its incoming or outgoing side depending on the type of failure that it returns.
I don't fully understand what you mean by reverse direction and how a threshold comes into play. I think there is a case to be made for stronger penalization, but that this case is pre-existing. In fact, when building the current penalization scheme, there also was a variant with undirected pair penalties.

Sorry, I should have been clearer, I was thinking about scenario https://github.com/lightningnetwork/lnd/pull/6703#issuecomment-1797918626. The channel A-B is depleted, A charges high fees to disable the channel, B discounts the channel for whatever reason and this leads the total channel fee to be small. Without inbound fees, the channel would not see any traffic, but with the inbound fees, B is able to attract traffic. The failing pair is attributed to the node pair A->B (because A fails back due to missing liquidity), which influences A's node reputation because it's outgoing from A, but not B's node reputation (if I understand the code correctly). I wonder if we could additionally attribute a failure to B->A in order to worsen B's reputation as well, because it was the culprit of the failure. The question is when to do this, it should probably depend on the relative sizes of the inbound and outbound fees.

I think it is worth going back to the starting point with this. The cap in the other PR was added to prevent routing node operators from accidentally losing money on forwards because of misconfiguration. It is implemented as part of the forwarding logic, but it could also have been part of the policy update logic. Or even just been enforced externally by node mgmt tools.

So there are two options, the first is that the forwarder doesn't allow forwarding of negative fees. If they want to support negative fees in the future, they would need to signal it via a node feature bit such that senders can exploit it. Without this signaling it makes sense to disable negative fee route construction here, because otherwise there is a possibility that routes get rejected (the motivation was not to protect routing nodes). The second option is to enable negative fees from the start, but it needs the crosschecks you mentioned, but this would enable negative fees already.

Zooming out, it feels that all of this is going into the direction of a complex solution for a simple problem. If you are concerned about the footgun, I think it is better to go back to https://github.com/lightningnetwork/lnd/pull/6703 and fix the update policy logic so that there can never be a combination of in and out channel that makes for a negative total fee. Something like https://github.com/lightningnetwork/lnd/commit/43cfd243cd6b7079dc2f1c9ae2088350911cda55

Not sure which way is best. Default channel open fees would also need to be taken care of, right? It feels like it is safer to have an explicit check in the switch than relying on the policy state, but it's also great to have negative fees available from the start.

Sorry, I should have been clearer, I was thinking about scenario #6703 (comment). The channel A-B is depleted, A charges high fees to disable the channel, B discounts the channel for whatever reason and this leads the total channel fee to be small. Without inbound fees, the channel would not see any traffic, but with the inbound fees, B is able to attract traffic. The failing pair is attributed to the node pair A->B (because A fails back due to missing liquidity), which influences A's node reputation because it's outgoing from A, but not B's node reputation (if I understand the code correctly). I wonder if we could additionally attribute a failure to B->A in order to worsen B's reputation as well, because it was the culprit of the failure. The question is when to do this, it should probably depend on the relative sizes of the inbound and outbound fees.

Ah, you are talking about node probability specifically, where pair results are extrapolated to a global node probability? Because the pair penalty on its own is probably not a problem as A might not want to do business with B anyway?
Btw, why would A charge high fees to disable a channel instead of actually disabling it? With high fees, there is still the risk of someone using it and penalizing.

Not sure which way is best. Default channel open fees would also need to be taken care of, right? It feels like it is safer to have an explicit check in the switch than relying on the policy state, but it's also great to have negative fees available from the start.

Hmm good point. Those default fees make things complicated again. Let's go for disabling negative fees all the way then indeed. I've tacked on a commit that also updates pathfinding to put a floor on node total fee during search.

Ah, you are talking about node probability specifically, where pair results are extrapolated to a global node probability? Because the pair penalty on its own is probably not a problem as A might not want to do business with B anyway?

Right, I was thinking about the node probability, which effectively is used as a kind of reputation or deterrence against misbehavior. Do you mean that there's no disadvantage for A if the B->A pair is failed as well?

Btw, why would A charge high fees to disable a channel instead of actually disabling it? With high fees, there is still the risk of someone using it and penalizing.

I see this rather as a continuous process, because ramping up the fee rate goes in hand with increased traffic and whether there's liquidity left, leftovers can still be used at a higher rate, if there's high demand for it, but statistically the channel should get discouraged. Disabling the channel also is a binary process, so one would have to define a fraction at which a channel gets disabled. Also, disabling is often used as a heuristic to judge if some node signals that their channel partner is down.

With this new addition, maybe your first point is also addressed? The node total fee is now always non-negative in pathfinding, so any kind of mega discount needs to be matched with an equally big outbound fee. That reduces the extent to which a node can make itself attractive to what they can already do today with zero fees?

Route reliability is increased with this :+1:, but I need to check if there are other consequences.

Do you mean that there's no disadvantage for A if the B->A pair is failed as well?

No, that wasn't what I meant. Just that penalizing A->B (ignoring the node reputation for now) affects A in that they will have less traffic going to B, but they probably don't care if B is a bad node.
Penalizing B->A will affect A as well for that specific link, and indeed, you could argue that it doesn't matter because B is malicious.

I see this rather as a continuous process, because ramping up the fee rate goes in hand with increased traffic and whether there's liquidity left, leftovers can still be used at a higher rate, if there's high demand for it, but statistically the channel should get discouraged. Disabling the channel also is a binary process, so one would have to define a fraction at which a channel gets disabled. Also, disabling is often used as a heuristic to judge if some node signals that their channel partner is down.

But if there is still liquidity left, why wouldn't A want senders to use it? If B makes it more attractive and more likely for A to earn that high fee, I don't really see the downside. I think there is a speculative component here in how the dynamics will work out exactly. I do not oppose a bidirectional penalty, but I wouldn't want to make a change that affects every existing channel too as part of this PR.

With this new addition, maybe your first point is also addressed? The node total fee is now always non-negative in pathfinding, so any kind of mega discount needs to be matched with an equally big outbound fee. That reduces the extent to which a node can make itself attractive to what they can already do today with zero fees?

Route reliability is increased with this 👍, but I need to check if there are other consequences. Also, do we want to already define a flag for nodes to signal to support negative fees?

I don't see the need to define the flag if we don't use it yet. And may never do.

@bitromortac: review reminder
@joostjager, remember to re-request review from reviewers when ready

Added an evaluatory commit that shows channel-based pathfinding to avoid any recognized or unknown side effects of negative inbound fees.

@joostjager, remember to re-request review from reviewers when ready

@joostjager, remember to re-request review from reviewers when ready

@joostjager, remember to re-request review from reviewers when ready

@joostjager, remember to re-request review from reviewers when ready

@joostjager, remember to re-request review from reviewers when ready

Rebased

@joostjager, remember to re-request review from reviewers when ready

@joostjager, remember to re-request review from reviewers when ready

@joostjager, remember to re-request review from reviewers when ready

@joostjager, remember to re-request review from reviewers when ready

@joostjager, remember to re-request review from reviewers when ready

@joostjager, remember to re-request review from reviewers when ready

@joostjager, remember to re-request review from reviewers when ready

@joostjager, remember to re-request review from reviewers when ready

Needs rebase + conflicts addressed.

Will be possible to set the default inbound fees on lnd.conf? I can't see any modifications related to this new feature and merged PR in the sample-lnd.conf available on the repo, and any related with this: https://github.com/lightningnetwork/lnd/blob/master/sample-lnd.conf#L626-L633

@twofaktor that makes a lot of sense, I've made a tracking issue for your request here: https://github.com/lightningnetwork/lnd/issues/8610. Thanks!


feat: add topic message type

What is the purpose of the change
add message type when topic create or change
add transaction message send
#5538 - issue reported for examine Topic Config Query not returning message.type in query result.
Brief changelog
1。in topic page , when create or change topic ，add message type
2. in topic page ,when send message test , add transaction message producer to send message
Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

nice

@lizhanhui please review this, this is very useful feacher.


Missing Japanese Language Support

Describe the bug
The TUI views are completely broken if the text for labels etc. are in Japanese. It's still possible to use the controls (such as buttons), so this "only" affects the rendering in the terminal. To be clear: In my development environment, Japanese characters are still displayed correctly in the console. Its the border drawing and view alignment that's broken (under these specific circumstances).
To Reproduce
To display Japanese characters in the terminal on a machine using a English culture, I added these lines to my PowerShell profile:
chcp 932 | Out-Null
$PSDefaultParameterValues['*:Encoding'] = 'utf8'

I use Windows Terminal and Microsoft's Cascadia Mono font which supports rendering Japanese characters.
Expected behavior
I didn't really expect this to work seeing how tricky Japanese font faces can be in a terminal-based environment, so this would be a nice-to-have feature and a heads-up for everyone looking to write a TUI with Japanese localization support.
Screenshots
Login view with slight modifications from the reactive sample code and Japanese text.

Desktop (please complete the following information):

OS: Windows
Version: 10.0.19044

Additional context
As mentioned previously, the code to reproduce this error can be obtained by replacing the label content with Japanese text using the the ReactiveUI demo project. This problem potentially also affects all other major Asian Languages (CJK), would be interesting to know if something similar also happens with other difficult languages such as Arabic or Hebrew.

Wow thanks a bunch, guess I grew a little to dependent on Windows Terminal that it didn't cross my mind to try a different terminal emulator. Hope your PR goes through!

This might also be interesting to other Japanese developers:
The output looks good in Developer PowerShell for VS 2022 if you add
public static void ChangeCulture()
{
    Thread.CurrentThread.CurrentUICulture = new CultureInfo(Configuration.Language);
    Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(Configuration.Language);

    // You only need this line in .NET Core; install System.Text.CodePages from the Nuget Manager
    Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);

    Console.OutputEncoding = Configuration.Language switch
    {
        Language.Japanese => Encoding.GetEncoding(932),
        _ => Encoding.Default
    };
}

For Windows Terminal, I also added
public static void Main(string[] args)
{
    if (args.Length > 0 && args.Contains("-usc"))
    {
        Application.UseSystemConsole = true;
    }

    // etc.

I got this idea from the demo.cs file here. Now we only have to wait for your PR and this should solve the issue with Windows Terminal as well.

Fixed with #1664


Update mapsize to standard size.

resolution will need to be adjusted to fit new aspect ratio as well.

Done! c177982


Mirror GitHub advisory data into a github.com namespace

Mirror GitHub advisories to a github.com namespace similar to what we are doing for NVD data.  Not every GitHub advisory corresponds to a CVE, but if it does it should be easy enough to map it to the correct GSD entry using the alias field.  If there is no CVE for it maybe create a GSD candidate for it?  Or just leave that part as a later enhancement

This is significantly simplified by the new repo: https://github.com/github/advisory-database

https://github.com/ossf/osv-schema/blob/main/tools/ghsa/convert_ghsa.py#L65


Update to newest version of Swagger UI to support Password Flow

Since https://github.com/domaindrivendev/Swashbuckle/issues/202 is closed and is not receiving any responses from @domaindrivendev, I'm trying to draw attention to this by opening a new issue.
Password Flow support has landed in swagger-ui Master: https://github.com/swagger-api/swagger-ui/pull/2397
Please update Swashbuckle to make use of the newest version of swagger-ui.

Pull request #974 could be of interest for this issue. This essentially updates Swagger UI to 2.2.10, which has the new password flow functionality. I too am eager for this to be supported in Swashbuckle.
Though, I am not sure to what extend Swashbuckle itself would need some tinkering in order for password flow to function properly. This, as Swashbuckle provides config settings for the grant type which should be used in Swagger UI.

We're also interested in the password flow.
P.S. thank you guys for your work implementing so cool tool!

I have just compiled the latest commit of master and I verified that OAuth2 password flow works correctly. Does anyone know when the new version of the NuGet package will be released?
The parameters of EnableOAuth2Support method are useless since the new version of Swagger UI does not use those configurations any more (at least for the password flow).

It seem that the owner is busy with other projects...
But there is a call out for maintainers, see: #1053

@heldersepu I saw the call for maintainers and I would like to be helpful. However, at the moment, I do not have enough insights on the inner workings of the library and the overall design to be of any real help.

I am very interested to this update.

I am very interested too. Authorization works great. But after there is no authorization header in requests to api. Is this will be solved after upgrade?

All we need is a new version of the NuGet package...
Anyone in a rush I will recommend the solution from VenomAV: https://github.com/domaindrivendev/Swashbuckle/issues/986#issuecomment-299022132

I've been working on my fork, I updated to the latest Swagger-UI (3.x), here is how it looks on one of my projects:
http://turoapi.azurewebsites.net/swagger/ui/index
If you have time I could use your help testing it, you can get my version from MyGet:
https://www.myget.org/gallery/swashbuckle

SB v5.6.0 ships with swagger-ui 2.2.10 and is now available on Nuget. I believe this resolves the issue. @pdusen - please let me know if this isn't the case. Thanks

@domaindrivendev It seems like the way authorization settings are configured in Swagger UI have been changed. This means that the corresponding EnableOAuth2Support method is no longer working, like @VenomAV already mentioned.
So this isn't a clear-cut 'upgrade Swagger-UI and everything is fixed'-solution, unfortunately. It does seem that there isn't too much needed to make Swashbuckle work with those new settings, though.

@UnrealKazu if possible can you elaborate on the changes required to make Swashbuckle work with the new settings so it's a little more turnkey for the rest of us?


JSON API Serializer assumes included relationships are always dasherized

We have an API that uses underscores to separate multi-word model names (e.g. blog_post instead of blog-post) in its responses like so:
{
  data: {
  }
}

It also wants the the ?include= query param to use the same format for relationship names (e.g. GET /comments/1?include=blog_post).

(accidentally submitted this while editing...updating now)

Looks like you learned a lot more about Mirage than you bargained for ;)
Thanks so much for the help dude!!