Are dialogs supposed to be transparent?

[ed2050]

Question

Is this expected behavior?

I ran the dialog example from the docs, with one small change. I removed ui.card from the dialog because it seemed unnecessary.

from nicegui import ui

with ui.dialog() as dialog:   # <-- was ui.card () here
    ui.label('Hello world!')
    ui.button('Close', on_click=dialog.close)

ui.button('Open a dialog', on_click=dialog.open)

ui.run()

Result : dialog was completely transparent. Just floating text 'Hello world!' in the middle of page. Can see the image behind it completely.

Is this intended behavior or some bug on my system? What purpose does a transparent dialog serve?

[falkoschindler]

Yes, that is normal behavior. Somehow Quasar decided to create transparent dialogs which are usually filled with cards or some other panel. I guess this allows for all kinds of overlays, which wouldn't be possible if a dialog always came with a card.

I don't like it too much, but decided to stick with Quasar's default. If we could nest a card automatically, then what is ui.dialog? Is it a dialog or a card? You need it to be a dialog in order to apply dialog-related props like "persistent" or "auto-close", but you also need access to the card for customizing color, border, padding, shadow...

In theory we could create a dialog which contains a card. We could add a with_card: bool = True parameter for the rare case when you don't want a card. But styling the card is still a bit tedious, since you'd need to write

with ui.dialog().props('auto-close') as dialog:
    dialog.card.classes('bg-gray p-16')
    ...

instead of the more natural

with ui.dialog().props('auto-close'):
    with ui.card().classes('bg-gray p-16'):
        ...

Long story short: At the moment this normal behavior, but I'm up for suggestions how to improve it.

[ed2050]

I agree, duplicating methods is bad. Adding dialog.card_classes etc is not a good approach. It's confusing.

Exposing dialog.card is slightly better but still confusing. User has to learn quasar to figure out whether to call dialog.classes or dialog.card.classes.

Why not just apply to both? When user calls dialog.classes ('foo') then dialog applies 'foo' to both itself and its internal card. Same with properties. Does it matter who's responsible as long as both elements have it?

I don't know quasar internals, maybe it wouldn't work. Seems like the simplest approach though.

[falkoschindler]

To be honest, blindly applying attributes to both elements feels wrong. I'm not sure if it breaks anything, but if you ask me, it smells quite a bit.
When skimming through card and dialog props, I found at least one problematic prop that is available for both elements: "square". I'm not sure what a square dialog with a regular card looks compared to a regular dialog with a square card, but at least it is technically different and we would mix them together. Who knows what else is added in the future.

[ed2050]

Oddly enough neither one is square. But they look the same to me. 🤷‍♂️ code below.

I get your point that there could be problematic combinations. But I'm interested in the common case. Make easy things easy and hard things possible. If putting the class / prop on both is fine most of the time, that's an improvement to me. You can always diambiguate the rare corner cases with more explicit calls when needed : mydialog._card.classes ('foo') or mydialog.classes ('foo', propagate = false).

That said, I'm not tied to this idea. It's just better than current approach, which feels hacky to me. Where:

with ui.dialog (), ui.card () :
    # do something

uses execution order side effects to create an implicit parent / child relationship. That's confusing. Much clearer to do:

with ui.dialog () :
    with ui.card () :
        # do something

Both are doable with current lib. First is used in docs though. Just goes to show: one man's hacky is another man's gem.

Then we're back to the original problem: dialog itself is not a free-standing element. It needs a card or such. Why expose that to the user? I like @natankeddem's solution below.

Test Code

import nicegui
from nicegui import ui

def mainpage () :

    ui.label ('test page')
    
    with ui.dialog ().props ('square') as d :
        with ui.card () :
            ui.label ('square dialog')
        d.open ()
    
    with ui.dialog () as d :
        with ui.card ().props ('square') :
            ui.label ('square card')
        d.open ()
        
    ui.run ()
    
if __name__ in {"__main__", "__mp_main__"} :
    mainpage ()

[falkoschindler]

Regarding multiple elements in one with statement:

In my point of view

with ui.dialog(), ui.card():

is equivalent to

with ui.dialog():
    with ui.card():

It is just one line shorter and reduces indentation. It might be a bit unconventional, but completely valid Python with no more or less side-effects.

[ed2050]

I completely agree that it's valid and it works. The relationship is just less clear. Second form is more explicit about which is parent and which is child. If you're used to seeing it a lot, perhaps they read the same. As someone new to nicegui, the implicit form makes me stop and think.

[natankeddem]

Probably the unpopular opinion but instead of a with_card: bool = True I would just make the argument child: Element = ui.card. that way if you want custom styling you make an extended class and pass that in. Lets not forget the default_... methods which mean you probably don't need to style the card unless it is different from other cards on the page. This also allows you to utilize elements other than ui.card in the future if they are useful in dialogs as well.

[natankeddem]

Yes, it would be a type. Styling would be accomplished in 2 ways. Which I am doing today in my personal project:
https://github.com/natankeddem/bale/blob/ffbc9b71c0a1c6652dcfc94da26def067bd432c0/bale/tabs/history.py#L141C11-L141C11

First style would be inherited utilizing the default_x methods. Secondly the user would utilize an extended class. An example of usage:

ui.card.default_style("max-width: none")
ui.card.default_props("flat bordered")

class MyCard(ui.card):
    def __init__(self) -> None:
        super().__init__()
        self.tailwind.border_color("red")

with ui.dialog(MyCard) as dialog:
    dialog.child.border_color("green") # unlikely

My point with this implementation is that in most of my use cases most of the cards in my UI are styled idenically, for consistency. Or at minimum all my dialogs (which could share the MyCard). If you really needed to access the child card we could expose that as a property, but I don't think it would be used that often.

[ed2050]

@natankeddem -
I don't like this model. It forces you to apply all styling to MyCard statically in the class definition, before passing the type to dialog. Leaves no room for styling MyCard dynamically (e.g. different border colors for different message types).

You'll prob say "just make a different class for each dialog type". RedCard, YellowCard, BlueCard, etc. That makes the problem even worse. My goal is to separate content from styling. A proliferation of short do-nothing classes just to change color works completely against that goal.

If you want to program this way, that's fine. But please leave room in nicegui for other programming styles.

[natankeddem]

I don't understand the criticism. I am showing 3 different mechanisms to deploy styling to the child container. You said before you liked:

dialog.card.classes('bg-gray p-16')

I don't understand why now utilizing a property with a different name changes things? I was just trying to be more open to the idea that there might be containers in dialogs which wouldn't be cards.

dialog.child.border_color("green")

You are free to apply styling via the child property which will expose the card instance. Maybe there was a misunderstanding here? I didn't want to make any implementation code just yet since we are still talking about how the user would utilize the modified ui.dialog.

[ed2050]

Hi @natankeddem, perhaps I misunderstood your suggestion. I thought you proposed to pass a hidden container class that couldn't be touched after initialization. Your last line was:

If you really needed to access the child card we could expose that as a property, but I don't think it would be used that often.

I was pushing back against that last part. Access to the container would be needed often for some programming styles. I'm against container access as an afterthought "maybe, not really needed" idea.

Styling approaches

For the record, I don't particularly like dialog.card.classes ('bg-gray p-16'). I meant that among the options @falkoschindler proposed, that was the best choice. In fact I am firmly against mixing styling with content, so 'bg-gray p-16' is about as bad as it gets in my book.

That said, I can happily live with dialog.card.classes ('renamedialog') where styles for .renamedialog are set in css. Might seem like a minor semantic difference, but it goes back to mixing styles and content. bg-gray p-16 is an immutable style I don't control and can only update by changing source code. .renamedialog is a concept that can be easily changed in user css files without touching the code base. It can even be set on user side with preferences without touching the web server.

Default classes are useful, but too limited to cover every case.

Sorry for any confusion.

[natankeddem]

We might want to take discussions about the pros and cons of various styling philosophies to another discussion. I know I might have inadvertently started us down that path, sorry for that. Here we should only try to make sure as many different methods are captured if/when it is decided to alter ui.dialog; despite anyone's personal preferences.

[rodja]

I'm a bit lost. What exactly is the problem? Why is the current behaviour problematic (see #2040 (comment))? It's as close as possible to the Quasar API and hence allows all the stying and changes any developer could wish for...

[ed2050]

@rodja -
Depends what you mean. Is the current system functional? Yes you can make dialogs with it. If that's your only criteria then there is no problem.

However from other standpoints the current approach is lacking. Why are you forced to create an extra element to make dialog work? What's the point of having a dialog element that doesn't function by itself? It puts more cognitive load on the user to say "ok I wanted 1 dialog, but instead I really have to manage 2 separate components, a dialog and a card". Just make the card implicit.

When you create a Chat Message does the user need to create separate elements for the text, the bubble, and the avatar? No. Nicegui takes care of all those elements for you. Dialog should be the same. If a card is required to have a minimal functional dialog, then it should be handled behind the scenes.

It's as close as possible to the Quasar API and hence allows all the stying and changes any developer could wish for...

Why should nicegui follow the Quasar API as close as possible? Is the goal of nicegui to port Quasar to Python? Or is it to provide a python toolkit for building UIs? As an end user I can proudly say that I'm lazy and want to think about the framework as little as possible! 😄 My focus is on my own app logic.

That's my perspective. Obviously you're free to take a different approach. Just sharing for you to consider. Hope this helps. ✊

[natankeddem]

ui.dialog now with "Batteries Included" ™
Since some very large percentage of use cases nest a child card inside ui.dialog lets just put it in there for them by default.

[rodja]

So it's mainly a naming issue? If we would rename ui.dialog to ui.overlay we could crate a new element ui.dialog which behaves more like a dialog as it is known from other UI frameworks (with confirm/cancel buttons, borders etc).

[falkoschindler]

Or we preserve backward compatibility and the same name for ui.dialog and QDialog, while introducing a "batteries included" ui.dialog_card. It would provide the most common dialog props as initializer parameters and forward classes and style to its card element. But it either needs to derive from ui.dialog or we need to re-implement quite a bit, e.g. awaiting a ui.dialog_card.

[natankeddem]

We could change the existing dialog to move elements into a card if one isn't found. This should be backwards compatible I think? I may be forgetting an edge case this doesn't handle though?

from nicegui import Client, app, ui


class NewDialog(ui.dialog):
    def __init__(self, *, value: bool = False, child_type: ui.element = ui.card) -> None:
        super().__init__(value=value)
        self._child_type = child_type

    def __exit__(self, *_):
        children = self.slots['default'].children.copy()
        if self._child_type:
            if len(children) != 1 or not isinstance(children[0], self._child_type):
                self.child = self._child_type()
                for child in children:
                    if child != self.child:
                        child.move(self.child)
        return super().__exit__(*_)


with NewDialog() as dialog:
# with NewDialog() as dialog, ui.card():
    with ui.row():
        ui.label("Hello!")
        ui.label("Bye!")
    ui.button('Close', on_click=dialog.close)

ui.button('Open a dialog', on_click=dialog.open)
ui.run()

This had the downside that you can't interact with the child element until after the with statement, but maybe that could be solved.

[kleynjan]

Late to this party, but as for 'every dialog needs a card anyway': the current lightbox example has an ui.dialog with only an ui.image in it, and I think it's a good use case. My vote would be to stay as close as possible to the Quasar API, at least where the names of the components are identical.

+1 for a batteries-included dialog (with another name), though.

[stepheweffie]

Modals are also transparent. #2169 (comment)