Add helper for formatting long warning messages by otekraden · Pull Request #2563 · beeware/briefcase

otekraden · 2025-11-14T22:47:25Z

Fixes Add helper for formatting long warning messages #2559

I solved Issue #2559 by creation the function "format_message_to_asterisk_box", that formatting message to asterisk box representation.

It takes this args:
message (str): The message to format.
title (str, optional): The title of the box. Defaults to None.
width (int, optional): The width of the box. Defaults to 80.
border_char (str, optional): The character to use for the border.
Defaults to "*".
padding (int, optional): The number of spaces to pad the border.
Defaults to 2.

Also I added tests for it. Function it seems working good.

But I was not sure in what file to put function.
Now its location and tests by this paths:
src/briefcase/utils.py
tests/test_utils.py

It is my very first attempt of contribution. Please don beat me hard)

I am waiting for your feedback.

PR Checklist:

All new features have been tested
All new features have been documented
I have read the CONTRIBUTING.md file
I will abide by the code of conduct

…/utils.py

freakboy3742

Thanks for the contribution! The broad strokes of this look like it's on the right track - but there's a few details to sort out. Some of them I've flagged inline; but there are a couple of bigger picture items.

Firstly, this is currently failing CI because of a town crier check; see our contribution guide for details on what that means.

Secondly - we try to avoid generic "utils" modules. In this case, the code is a very specific addition to console handling - so it should be part of the console module. Given that this will always be used in the context of a console.warning(), it would make sense to me for this to be a standalone method on Console - something like console.warning_banner(title, body, width=80). It may help to keep the "formatting" part of the code separate so that console._banner() returns a string, which is then output by console.warning_banner() (and provides an opportunity for error_banner() if we ever need it).

freakboy3742 · 2025-11-16T23:48:30Z

+            Defaults to 2.
+
+    Returns:
+        str: The formatted message.


We use the Sphinx docstring format; check any other source file for examples of use.

Got it!
I applied this format.

freakboy3742 · 2025-11-16T23:58:09Z

+        lines.append(border_line)
+
+    # split the message into paragraphs
+    paragraphs = message.split("\n")


We should probably use textwrap.dedent() here as a convenience as well.

Sorry, but in my current understanding of the logic of my function, I don't see how to use the textwrap.dedent() method. Could you please show me how to integrate it?

What I'm suggesting is that being able to call:

console.warning_banner( "Some banner title" """\ This is the content that I want to display. It is long but I don't want to have to manually word wrap\n \n But manual line breaks should be preserved. """ )

We could do this by requiring the user to wrap the """ string in textwrap.dedent()... or we could do that automatically on every usage.

otekraden · 2025-11-18T04:25:34Z

@freakboy3742
Thank you for your feedback.
As expected, it turned out to be not so easy.
I've seen that the CI process crashes into an error, but I haven't figured out how to fix it yet.
I will take all your comments into account and finalize this pull request in the near future.

…sole primitives section. Tests relocated to Console tests folder.

otekraden · 2025-12-02T20:53:57Z

I have attempted to make all the necessary changes based on the instructions above.
The function has been transformed into a static method "warning_banner" in the Console primitives section.
Tests have been relocated to the Console tests folder.
Currently, CI towncrier works fine, but there seems to be an issue deeper in the app building process.

otekraden · 2025-12-03T11:56:22Z

I rewrote Console method from static to instance method.

freakboy3742

Thanks for those cleanups. The CI failure you saw was unrelated - we had some disk space issues in our CI configuration. We've fixed those now, and I've re-run the affected tests, and they're passing now.

I've left a couple more review comments; the only other suggestion is that it could use a couple more tests.

In particular, this is a situation where parameterized tests would be helpful. There's a general pattern of a set of input. Then a need to test how that input renders at different widths - widths that are longer than the text, the same width as the text, less than the width of the text, and so on.

Lastly, it would be useful to actually use this API somewhere. It doesn't need to update every usage of banner-like output, but if you pick a module (like the Android integrations), and replace every warning banner with the equivalent usage of this utility, we can see that it will work in practice.

freakboy3742 · 2025-12-04T02:20:01Z

+        :param message: The message to format inside the box.
+        :type message: str
+        :param title: The title of the box. If provided, appears centered at the top.
+        :type title: str, optional
+        :param width: The total width of the box in characters. Defaults to 80.
+        :type width: int, optional
+        :param border_char: Character to use for the box border. Defaults to "*".
+        :type border_char: str, optional
+        :param padding: Number of spaces between the border and text content. Defaults
+            to 2.
+        :type padding: int, optional
+        :return: The formatted message enclosed in a bordered box.
+        :rtype: str


Apologies for the miscommunication here; but we don't need the type documentation - because they are (or should be) in the type annotations for the method itself.

Suggested change

:param message: The message to format inside the box.

:type message: str

:param title: The title of the box. If provided, appears centered at the top.

:type title: str, optional

:param width: The total width of the box in characters. Defaults to 80.

:type width: int, optional

:param border_char: Character to use for the box border. Defaults to "*".

:type border_char: str, optional

:param padding: Number of spaces between the border and text content. Defaults

to 2.

:type padding: int, optional

:return: The formatted message enclosed in a bordered box.

:rtype: str

:param message: The message to format inside the box.

:param title: The title of the box. If provided, appears centered at the top.

:param width: The total width of the box in characters. Defaults to 80.

:param border_char: Character to use for the box border. Defaults to "*".

:param padding: Number of spaces between the border and text content. Defaults

to 2.

:return: The formatted message enclosed in a bordered box.

freakboy3742 · 2025-12-04T02:21:00Z

+        width=80,
+        border_char="*",
+        padding=2,


Missing type annotations:

Suggested change

width=80,

border_char="*",

padding=2,

width: int = 80,

border_char: str = "*",

padding: int = 2,

freakboy3742 · 2025-12-04T02:22:15Z

+            # Wrap the title to lines to fit the width of the box
+            wrapped_title_lines = textwrap.wrap(
+                title.strip(),
+                width=width - (padding * 2) - 4,


I'm not sure there's a use case for configurable padding here - 1 space of padding in the title will always be the default.

freakboy3742 · 2025-12-04T02:46:38Z

+        lines.append(border_line)
+
+    # split the message into paragraphs
+    paragraphs = message.split("\n")


What I'm suggesting is that being able to call:

console.warning_banner( "Some banner title" """\ This is the content that I want to display. It is long but I don't want to have to manually word wrap\n \n But manual line breaks should be preserved. """ )

We could do this by requiring the user to wrap the """ string in textwrap.dedent()... or we could do that automatically on every usage.

Padding arg removed: it will be always 1.

…, returns empty string.

…s also mod.

otekraden · 2025-12-23T23:08:19Z

I have made the following changes:

added the ability to enter a message and title as a multiline or single line. At the same time, it is possible to manually split texts into paragraphs using "\\n";
did parametric tests;
corrected docstring and arg types.

kattni · 2025-12-27T00:13:36Z

@otekraden Hello! Thank you for submitting the requested changes. As you can see, the CI is failing. We maintain 100% code coverage in testing. The current CI issue appears to be related to the PR now being less-than 100% coverage. You can click on the failure to see exactly where the issue is. Please get this PR passing before we review it again. If you have questions or need help, please post here. Thanks!

otekraden · 2026-01-22T21:07:42Z

@kattni @freakboy3742
Hello! I need your help with tests coverage.
I tried everything but string 324 in console.py not covered((

I will be grateful for any hint.

freakboy3742

This is looking good! A few review comments inline.

Regarding the coverage failure - the error is telling you that a specific line of code isn't being exercised by the test suite. The fix is to add a test case that will exercise that line of code - in this case, the case of a message that isn't a string.

That said - as noted by my review comments, that line of code probably isn't needed, because we can assume the method is being used by a "reasonable person" who is working with Briefcase. It doesn't necessarily need to be robust enough to handle any random input from an end user.

The last suggestion - at present, this PR adds a new feature, and does a good job testing; however, it would be good to see a few examples of the API being used in practice. You don't need to update every banner in the codebase - but if you pick one module (say, the Android SDK integrations in src/briefcase/integrations/android_sdk.py) and replace all banners with usage of this API, you can prove that the API is "fit for purpose".

freakboy3742 · 2026-01-22T22:32:10Z

+
+
+@pytest.mark.parametrize(
+    ("test_name", "message", "title", "width", "expected"),


There's no need to include a descriptive test name - your test doesn't use it anyway:

Suggested change

("test_name", "message", "title", "width", "expected"),

("message", "title", "width", "expected"),

If you do want to provide a test identifier, use pytest.param() to define each group of test data; the ID in that case should be something short (like "test-1" or "empty-message-title") that can be used to run a specific test. This isn't required, but it can be a nice convenience.

freakboy3742 · 2026-01-22T22:34:40Z

+            80,
+            """\
+********************************************************************************
+**                                                                            **


This extra blank link in the title is a little odd. It wouldn't match any existing uses of warning banners.

freakboy3742 · 2026-01-22T22:36:07Z

+    # # Debug output if needed
+    # print('\n\n' + test_name)
+    # print("Generated:")
+    # print(msg)
+    # print("Expected:")
+    # print(expected)
+


There's no need to retain this debug code.

Suggested change

# # Debug output if needed

# print('\n\n' + test_name)

# print("Generated:")

# print(msg)

# print("Expected:")

# print(expected)

freakboy3742 · 2026-01-22T22:40:20Z

+        if not any((message, title)) or not isinstance(width, int):
+            return ""
+
+        def dedent_and_split(text):


Rather than defining this as an inline function, it should be a private method on the base Console class (i.e. , _dedent_and_split().

I'd also suggest that we can add an extra affordance around the handling of input strings. As written, I think this requires that the input string has a trailing \ on the first line (i.e., warning_banner(f"""\. That's the sort of detail that will be consistently forgotten in practice. Since the effect of the \ is to suppress the newline on the first character, it might be worth adding a text.strip('\n') so that any leading or trailing newlines are removed from the input string, ensuring that we're in complete control of the spacing around the message in the box.

freakboy3742 · 2026-01-22T22:42:21Z

+        if not any((message, title)) or not isinstance(width, int):
+            return ""


Wouldn't it make more sense to raise an error if the arguments aren't the right type?

It's also worth asking if any error handling needed at all. This isn't a public API - it's an internal utility; we don't have to be rock solid in the API we expose, because we're in control of how the method is used.

freakboy3742 · 2026-01-22T22:43:03Z

+            if not isinstance(title, str):
+                return ""


If we're doing error handling, we should be raising an error, not failing silently.

But again - is any error handling needed?

freakboy3742 · 2026-01-22T22:43:26Z

+            if not isinstance(message, str):
+                return ""


As above - is this error handling needed; and if it is, shouldn't it be error handling?

…le class

freakboy3742 · 2026-02-03T00:38:08Z

I've completed all the requested code edits. My apologies for the delay — I was occupied at my primary job.

No problem at all - we're grateful for any time you can volunteer.

While implementing the changes, I encountered an issue with "tox": I couldn't reach 100% test coverage. I discovered that running the "tox p" command after making edits allows the coverage to be recalculated correctly.

I'm not sure I understand what you're describing here - you'll need to provide some more details here. The current test suite isn't reporting any coverage problems.

I tried to use created feature in the Android SDK integrations, but tests falling in errors((

This is to be expected. You've made changes that alter the output of the Android SDK by switching to the new banner API; the tests that are failing are reporting that the output of some commands has changed. Once you've confirmed that the changes are expected, you'll need to update the tests to reflect the new output.

…removed from args.

…; test mod according this change.

otekraden · 2026-02-04T23:55:53Z

@freakboy3742
I switched Android SDK to use new "warning_banner" method.

freakboy3742

Ok - so this is why we wanted to see some examples of usage - there's clearly something not right here. See my comment inline about what this should look like from the perspective of the user.

freakboy3742 · 2026-02-08T13:20:00Z

+                tools.console.warning_banner(
+                    title="""
+    WARNING: ANDROID_HOME and ANDROID_SDK_ROOT are inconsistent
+""",
+                    message=f"""
    The ANDROID_HOME and ANDROID_SDK_ROOT environment variables are set
-    to different paths:
-
-        ANDROID_HOME:     {android_home}
-        ANDROID_SDK_ROOT: {android_sdk_root}
-
+    to different paths:\\n\\n
+        ANDROID_HOME:     {android_home}\\n
+        ANDROID_SDK_ROOT: {android_sdk_root}\\n\\n
    Briefcase will ignore ANDROID_SDK_ROOT and only use the path
-    specified by ANDROID_HOME.
+    specified by ANDROID_HOME.\\n\\n

    You should update your environment configuration to either not set
    ANDROID_SDK_ROOT, or set both environment variables to the same
    path.
-
-*************************************************************************
-"""
+""",


The title being expressed as a triple string over three lines is... very odd; and the need for large numbers of \\n characters in the input for dialogs clearly indicates that the implementation isn't right. There may be places where a manual \n is required, but they should be the extreme exception, not the rule.

At the very least, a blank line in the input should be interpreted as a blank line in the output, without any need for special handling. My immediate impression is that the simple "replace '\n' with ' '" isn't right; we should only be replacing a newlines where the next character isn't a newline or whitespace. That would preserve both the "layout" blank lines that are common at present, as well as the ANDROID_HOME indented example here.

Also - if the indentation isn't being preserved in output, then we can simplify and remove it from the input as well. Part of the reason of introducing this wizard is so that we can put the message "in context", rather than needing to have it in code the way we want it to be displayed.

… output; relative indentation kept tests modified

otekraden · 2026-04-01T02:34:54Z

@freakboy3742 Hello! I am making another attempt to complete work on this task.
I took into account all the above comments and made adjustments to the message generation logic.
Now the method calls look much better without using special characters like "\n".

freakboy3742

Thanks for those updates; however, based on the changes you've made here, I think we've still got a miscommunication here about the purpose of this feature.

The reason that we want to introduce a general purpose banner that allows us to put error messages into code without needing to have them "left aligned" in the code.

A few months ago, I gave you the following example of usage:

        console.warning_banner(
            "Some banner title"
            """\
                This is the content that I want to display. It is long
                but I don't want to have to manually word wrap\n
                \n
                But manual line breaks should be preserved.
            """
        )

(It's probably arguable whether the \n chars in that example are needed - in that context, the newlines aren't ambiguous)

This is an example of the sort of usage we want to see - a banner that will be displayed to the user with 80 character line widths, but doesn't need to be rendered in the code with 80 character line widths.

In this PR, in your sample usage, you haven't modified any of the actual content for the Android SDK messages. That turns your warning_banner() method into a very large and complex wrapper for putting '*'*80 around the top and bottom of a message. The rest of the logic for de-indenting and reflowing content essentially isn't being used at all.

What I'm expecting to see here is examples of usage that actually make use of the new capability that has been added here. I've updated one example to show the sort of change that I'm talking about; the same sort of update should be applied to every message.

I'm expecting that this will likely reveal other possible bugs and usage issues - which is why I've asked for a practical example of usage. It's not enough to just build an API - we need to demonstrate that it will actually be useful in practice for the purpose it is intended.

One more detail: this PR is currently raising an error when documentation is built; this is because the docs contain a stale URL reference. This has been fixed in main; if you merge the main branch into this code, that problem will be resolved.

freakboy3742 · 2026-04-01T07:02:25Z

+                    tools.console.warning_banner(
+                        "WARNING: Using Android SDK from ANDROID_SDK_ROOT",


This usage should be something like:

Suggested change

tools.console.warning_banner(

"WARNING: Using Android SDK from ANDROID_SDK_ROOT",

tools.console.warning_banner(

title="Using Android SDK from ANDROID_SDK_ROOT",

message=f"""\

Briefcase is using the Android SDK specified by the

ANDROID_SDK_ROOT environment variable.

Android has deprecated ANDROID_SDK_ROOT in favor of

the ANDROID_HOME environment variable.

Update your environment configuration to set

ANDROID_HOME instead of ANDROID_SDK_ROOT to ensure

future compatibility.

"""

)

Note that if we're including "WARNING: " in every message, we can hard code that text.

Added indentation for all warning messages to follow code structure. Removed "WARNING: " prefixes from titles.

…sts mod

otekraden · 2026-04-01T10:10:08Z

I've fixed the method calls in "android_sdk".
I'm sorry that I didn't immediately show the correct calls with code alignment.
I was worried about the big length of the lines, so I shifted the texts to the left.

In addition, I encoded the "WARNING:" prefix of the headers.

I really hope that now my solution looks like what you require.

freakboy3742

Ok - the text is now indented correctly in the source - but did you actually try it?

I did the following:

export ANDROID_HOME=something
export ANDROID_SDK_ROOT=somethingelse
briefcase create android

The values of the two environment variables don't matter - just that they are different, and not a valid SDK. If you do this, you get the following:

So... the text in the warning banners isn't being reflowed to 80 characters. The tests cases show that it can reflow... but in practice, it isn't. This is why I asked for examples of usage.

…c of splitting input text to paragraphs. Description of "console.warning_banner" was changed. Tests in "test_warning_banner" modified.

otekraden · 2026-04-03T20:27:29Z

+        To separate text into paragraphs you can use:
+        - blank line;
+        - relative indentation.
+        Lines with zero relative indentation will be merged to upper paragraph.


I rewrote the logic of splitting the text into paragraphs.

The width of each paragraph is equal to the specified border width minus the relative indentation.

otekraden · 2026-04-03T20:35:31Z

@freakboy3742 The result of the method is now as follows:

Paragraphs take up the full width of the box minus relative indentation.

freakboy3742

Thanks for those updates. I've pushed some updates to simplify the implementation and remove some safety checks that aren't needed, and slightly tweak the presentation for some content (e.g, adding padding around the message content, and preserving indented lines, as they're an indicator of shell literal content).

This will be a big improvement for future developers - thanks!

freakboy3742 · 2026-04-14T03:56:36Z

+        # If message and title are both empty rase ValueError
+        if not any((message, title)):
+            raise ValueError("Message or title must be provided")
+        # If width is not an integer, raise TypeError
+        if not isinstance(width, int):
+            raise TypeError("Width must be an integer")


There's no need to do this sort of error checking. It's an internal tool; we can rely on developers to use it correctly.

freakboy3742 · 2026-04-14T03:57:06Z

+        """
+
+        # character to use for the box border
+        border_char = "*"


Unless we're going to need to change this, it's a lot clearer to just use * where it's needed.

freakboy3742 · 2026-04-14T03:59:19Z

+            if not isinstance(title, str):
+                raise TypeError("Title must be a string")


Again - we can rely on developers to use this right.

freakboy3742 · 2026-04-14T04:00:42Z

+        # create lines array with opening line of the box
+        lines_array = [border_line]
+
+        # if title exists, format title in the box


Be wary of using excessive comments - they end up being more confusing than helpful.

freakboy3742 · 2026-04-14T04:04:00Z

+        # create paragraphs from lines
+        paragraphs = []


This is an area where comments would have been helpful - because "paragraphs" isn't a list of paragraphs - it's a list of lists, where each element is a line, and the "rel_indent" value.

However, this entire logic can be a lot simpler.

freakboy3742 · 2026-04-14T04:04:22Z

+        # Add a warning prefix for title
+        if is_title:
+            text = f"WARNING: {text.strip()}"


This is the wrong place to add WARNING - add it as part of the input not the wrapping mechanism.

freakboy3742 · 2026-04-14T04:05:36Z

@@ -0,0 +1 @@
+``Warning_banner`` method added to ``Console`` class.


This is markdown, not RST (i.e., use single quotes).

freakboy3742 · 2026-04-14T04:11:16Z

+
+
+@pytest.mark.parametrize(
+    ("message", "title", "width", "expected"),


Given the function takes "title" then "message", it makes sense to preserve that ordering in tests.

freakboy3742 · 2026-04-14T04:21:15Z

+********************************************************************************
+""",
+        ),
+        # Custom width (60) with title and message


This test case isn't really testing anything new - it's "just another width". Test cases should always be exercising something new.

Otekraden added 2 commits November 15, 2025 00:23

Function format_message_to_asterisk_box created in file src/briefcase…

d345b65

…/utils.py

Tests for format_message_to_asterisk_box created in file test_utils.py

072fcc0

otekraden marked this pull request as draft November 15, 2025 00:56

freakboy3742 requested changes Nov 17, 2025

View reviewed changes

Otekraden added 2 commits December 2, 2025 22:52

Function transformed to Console static method "warning_banner" in Con…

748b6d0

…sole primitives section. Tests relocated to Console tests folder.

File 2563 added to changes

ebee442

otekraden marked this pull request as ready for review December 2, 2025 20:07

otekraden marked this pull request as draft December 2, 2025 20:08

beeware#2563 change note filename corrected

b8c9b3a

otekraden requested a review from freakboy3742 December 2, 2025 20:42

otekraden marked this pull request as ready for review December 2, 2025 20:56

Console method warning_banner made as instance method, not static.

8e13003

freakboy3742 requested changes Dec 4, 2025

View reviewed changes

Otekraden added 4 commits December 23, 2025 22:04

Types corrected: removed from sphinx docs and added to method args.

907659c

Padding arg removed: it will be always 1.

Tests rewrote parametrized. In method if both message and title empty…

f91e1e9

…, returns empty string.

Add option to input title/message as multiline or single string. Test…

d5501f8

…s also mod.

Invalid inputs tests add

ca633ab

freakboy3742 requested changes Jan 22, 2026

View reviewed changes

Otekraden added 6 commits February 2, 2026 21:49

Correction for 100% coverage

7c08a27

"test_name" arg removed from tests

649045f

Corrections to test made

cb27cb8

Added raising errors on invalid inputs

dffbddf

Add "strip('\n')" to ensure leading/trailing newlines are deleted

951553f

"dedent_and_split" func remade to private satatic method of the Conso…

f6def9c

…le class

otekraden marked this pull request as draft February 4, 2026 18:47

otekraden force-pushed the format_boxed_message branch from dcdb43c to f6def9c Compare February 4, 2026 18:48

Otekraden added 4 commits February 4, 2026 22:03

"Title" made to be the first arg before "message" arg; "border_char" …

caee9ce

…removed from args.

Console "warning_banner" method mod to send output as console warning…

bdd47d0

…; test mod according this change.

Warning_banner on 207 line used

8cc849a

Warning banner is used in Android SDK module

e2946b7

otekraden marked this pull request as ready for review February 5, 2026 19:18

freakboy3742 requested changes Feb 8, 2026

View reviewed changes

This was referenced Feb 11, 2026

Add helper for formatting long warning messages #2559

Open

Reusable helper for formatting boxed console messages #2696

Closed

Otekraden added 2 commits April 1, 2026 05:05

warning_banner method rewrote: use new lines in code as paragraphs in…

9149cd7

… output; relative indentation kept tests modified

Calls of warning_banner method are modified in android_sdk

6d9b1e4

freakboy3742 requested changes Apr 1, 2026

View reviewed changes

Otekraden added 4 commits April 1, 2026 11:49

: Calls of warning_banner method are modified in android_sdk

9971a29

Added indentation for all warning messages to follow code structure. Removed "WARNING: " prefixes from titles.

in console.warning_banner "WARNING: " prefix hardcoded for titles; te…

218d5dd

…sts mod

Merge remote-tracking branch 'upstream/main' into format_boxed_message

41e46d2

Test "Message and title lengths equal to box width" corrected

0a28606

freakboy3742 requested changes Apr 1, 2026

View reviewed changes

Static method "console._dedent_and_wrap" was totaly rewrote: new logi…

dbec752

…c of splitting input text to paragraphs. Description of "console.warning_banner" was changed. Tests in "test_warning_banner" modified.

otekraden commented Apr 3, 2026

View reviewed changes

Otekraden and others added 2 commits April 3, 2026 23:41

Change "2563.misc.md" mod

7827408

Cleanups following review.

7fbe8ac

freakboy3742 approved these changes Apr 14, 2026

View reviewed changes

freakboy3742 merged commit 57c047e into beeware:main Apr 14, 2026
118 of 119 checks passed

otekraden mentioned this pull request Apr 14, 2026

Apply new method "console.warning_banner" #2798

Closed

17 tasks



		@pytest.mark.parametrize(
		("test_name", "message", "title", "width", "expected"),

	("test_name", "message", "title", "width", "expected"),
	("message", "title", "width", "expected"),

		if not any((message, title)) or not isinstance(width, int):
		return ""

		tools.console.warning_banner(
		"WARNING: Using Android SDK from ANDROID_SDK_ROOT",

-                    tools.console.warning_banner(
-                        "WARNING: Using Android SDK from ANDROID_SDK_ROOT",
+                    tools.console.warning_banner(
+                        title="Using Android SDK from ANDROID_SDK_ROOT",
+                        message=f"""\
+                            Briefcase is using the Android SDK specified by the
+                            ANDROID_SDK_ROOT environment variable.
+                            Android has deprecated ANDROID_SDK_ROOT in favor of
+                            the ANDROID_HOME environment variable.
+                            Update your environment configuration to set
+                            ANDROID_HOME instead of ANDROID_SDK_ROOT to ensure
+                            future compatibility.
+                        """
+                    )

		if not isinstance(title, str):
		raise TypeError("Title must be a string")

		@@ -0,0 +1 @@
		``Warning_banner`` method added to ``Console`` class.

Uh oh!

Conversation

otekraden commented Nov 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Checklist:

Uh oh!

freakboy3742 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

otekraden Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

otekraden commented Nov 18, 2025

Uh oh!

otekraden commented Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

otekraden commented Dec 3, 2025

Uh oh!

freakboy3742 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

otekraden commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kattni commented Dec 27, 2025

Uh oh!

otekraden commented Jan 22, 2026

Uh oh!

freakboy3742 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

freakboy3742 commented Feb 3, 2026

Uh oh!

otekraden commented Feb 4, 2026

Uh oh!

freakboy3742 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

otekraden commented Apr 1, 2026

Uh oh!

freakboy3742 left a comment

Choose a reason for hiding this comment

otekraden commented Nov 14, 2025 •

edited

Loading

otekraden Dec 2, 2025 •

edited

Loading

otekraden commented Dec 2, 2025 •

edited

Loading

otekraden commented Dec 23, 2025 •

edited

Loading

otekraden commented Apr 3, 2026 •

edited

Loading