Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refresh dialogs correctly, fixes #1866 #1931

Merged
merged 8 commits into from Feb 23, 2021
Merged

Conversation

fpabl0
Copy link
Member

@fpabl0 fpabl0 commented Feb 9, 2021

Description:

Fixes #1866

Checklist:

  • Tests included.
  • Lint and formatter run with no errors.
  • Tests all pass.
  • Move win.Refresh from dialog to widget.PopUp.
  • Add popup tests.

@fpabl0
Copy link
Member Author

fpabl0 commented Feb 9, 2021

I have not updated the test images, because I am not sure why those images were correct before:

Before:
dialog-custom-ugly

After:
dialog-custom-ugly

@Jacalz Jacalz changed the title Fix #1866 Refresh dialogs correctly, fixes #1866 Feb 9, 2021
fpabl0 added a commit to fpabl0/fyne that referenced this pull request Feb 9, 2021
dialog/base.go Outdated Show resolved Hide resolved
dialog/base.go Outdated Show resolved Hide resolved
widget/popup.go Outdated Show resolved Hide resolved
widget/popup.go Show resolved Hide resolved
Copy link
Member

@toaster toaster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change in the theme test images is expected due to the bugfix.
Nevertheless, I’d prefer to have a new test which checks the particular situation #1866 describes.
The test should:

  1. render the shown dialogue with theme A and check the image
  2. hide the dialogue
  3. switch the theme
  4. show the dialogue and check the image
  5. hide the dialogue again
  6. switch the theme back
  7. show the dialogue and check the image

@toaster
Copy link
Member

toaster commented Feb 15, 2021

@andydotxyz:
After examining this, I found that the dialog rendering looks good by chance.
I want to refactor it (for 2.1) to create a render subtree that reflects the expected output better. Also, I’d like to separate dialog from its layout. Any objections?

@fpabl0
Copy link
Member Author

fpabl0 commented Feb 15, 2021

I’d prefer to have a new test which checks the particular situation #1866 describes.

Got it. I will do it.
After looking carefully, I think the popup refresh should occur in popup.Show and not in dialog.Show because it is more a problem of the widget.Popup than the dialog.

Basically it would mean to have this in dialog:

func (d *dialog) Show() {
	if !d.desiredSize.IsZero() {
		d.win.Resize(d.desiredSize)
	}
	d.applyTheme() // <<< instead of d.Refresh()
	d.win.Show()
}

And this in widget.Popup:

// Show this pop-up as overlay if not already shown.
func (p *PopUp) Show() {
	if !p.overlayShown {
		if p.Size().IsZero() {
			p.Resize(p.MinSize())
		}
		p.Canvas.Overlays().Add(p)
		p.overlayShown = true
	}
	p.Refresh() // <<< added
	p.BaseWidget.Show()
}

What do you think? @toaster

Also, I’d like to separate dialog from its layout.

I think this part was already done by @andydotxyz in one of the latest commits.

@toaster
Copy link
Member

toaster commented Feb 15, 2021

After looking carefully, I think the popup refresh should occur in popup.Show and not in dialog.Show because it is more a problem of the widget.Popup than the dialog.

[…]

What do you think? @toaster

I think this whole thing is more a problem of all outside tree widgets and theme changes. Currently, we don’t have a public interface to apply theme changes and Refresh is not necessarily recursive.
As a workaround™ (probably in place forever ;)), I suggest to call internal.app.ApplyThemeTo() within BaseWidget’s Show() method.
@andydotxyz WDYT?

@andydotxyz
Copy link
Member

Currently, we don’t have a public interface to apply theme changes and Refresh is not necessarily recursive.

We removed that because it was confusing/duplication.
The framework should ensure that Refresh() is called on all widgets through ApplyThemeTo.
See the code in internal/app/theme.go when the settings change the theme should already be applied.

If the dialog is not in the overlay list then it probably should ensure the same state by using
ApplyThemeTo(overlay, window.Canvas()). I don't think this should be put in BaseWidget as it only applies to overlay layers.

@andydotxyz
Copy link
Member

Also, I’d like to separate dialog from its layout.

I think this part was already done by @andydotxyz in one of the latest commits.

Yes this has already been done.

@@ -260,7 +268,7 @@ func (l *dialogLayout) Layout(obj []fyne.CanvasObject, size fyne.Size) {
l.d.bg.Move(fyne.NewPos(0, 0))
l.d.bg.Resize(size)

btnMin := obj[3].MinSize().Max(obj[3].Size())
btnMin := obj[3].MinSize()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed the part .Max(obj[3].Size()) because it makes the dialog button ignore the theme change (sizing variables). @andydotxyz do you know if there was a reason to have that part?
By removing it, a test image from the color picker changed, however it seems that before this change, that test image was wrong:
Left side is after this change and right side is before this change:

Captura de Pantalla 2021-02-16 a la(s) 01 36 49

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't recall - but this is the change 72cac28

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I see, that change breaks dialog.NewProgress..., however:
btnMin := obj[3].MinSize().Max(obj[3].Size())
Isn't the above code breaking the principle that objects inside a Layout cannot manipulate manually their size neither their position? @andydotxyz

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I have seen that both dialog.NewProgress and dialog.NewProgressInfinite are deprecated and the message says:

// Deprecated: Create a new custom dialog with a widget.ProgressBarInfinite() inside.

So using dialog.NewCustom the widget would be inside dialog content and not as a button as it is done currently inside dialog.NewProgress.
However it is still possible to make the dialog.NewProgress looks like before, doing this:

c := container.NewVBox(widget.NewProgressBarInfinite())
d := dialog.NewCustom("Title", "", c, w)
d.Resize(fyne.NewSize(200, d.MinSize().Height))
d.Show()

But NewCustom always render a dismiss button, I think there should be a way to tell dialog.NewCustom to not render that button if user does not want it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are describing widget.NewModalPopUp

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I didn't understand, what do you mean?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, what I was meaning is: isn't a dialog with no buttons a modal popup?
I.e. dialogs are dismissable using buttons, to do something that isn't you can show a modal popup.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either way, for now perhaps the right thing to do is place a comment next to that line saying "// TODO remove once progress dialogs are gone" - if there is no sensible way to fix the issue with this PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the comment in the deprecation should be fixed.
Anyhow, as I am sure you agree, we can't break the feature even if it's deprecated.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dialogs are dismissable using buttons, to do something that isn't you can show a modal popup.

Oh I see, yes you are right.

for now perhaps the right thing to do is place a comment next to that line saying "// TODO remove once progress dialogs are gone"

By doing it, a wrong test image needs to be committed, is that ok?

if there is no sensible way to fix the issue with this PR.

We could update dialog.NewProgress with the above code, then we don't need to commit wrong test images, while ensuring the same behavior.

Maybe the comment in the deprecation should be fixed.

Yes, I think.

Anyhow, as I am sure you agree, we can't break the feature even if it's deprecated.

Completely, agreed.

dialog/base.go Show resolved Hide resolved
…o respect theme and canvas size changes) methods, fix popup tests
@toaster
Copy link
Member

toaster commented Feb 17, 2021

If the dialog is not in the overlay list then it probably should ensure the same state by using
ApplyThemeTo(overlay, window.Canvas()). I don't think this should be put in BaseWidget as it only applies to overlay layers.

Yes, as long as a dev does not remove an object from the tree, keeps it and adds it again later on. However, this is quite unlikely.

dialog/base.go Outdated Show resolved Hide resolved
@andydotxyz
Copy link
Member

Yes, as long as a dev does not remove an object from the tree, keeps it and adds it again later on. However, this is quite unlikely.

If required we could add that if an element has been hidden for a while it should have Refresh() called?
If we start removing renderers from hidden widgets after a time this may even happen automatically.

@fpabl0
Copy link
Member Author

fpabl0 commented Feb 18, 2021

It seems that there is a flaky test related to entry widget:
https://github.com/fyne-io/fyne/pull/1931/checks?check_run_id=1930590506#step:5:101

toaster
toaster previously approved these changes Feb 19, 2021
…en theme change in widget.PopUp, added popup tests
@fpabl0
Copy link
Member Author

fpabl0 commented Feb 19, 2021

I have added a little layout fix (that I didn't notice until I wrote the popup tests) for popup that would benefit dialog too, please kindly check.

toaster
toaster previously approved these changes Feb 20, 2021
Copy link
Member

@toaster toaster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@andydotxyz
Copy link
Member

Can we just clarify please, is the size / layout of the deprecated progress dialog still broken with this proposed change?

@fpabl0
Copy link
Member Author

fpabl0 commented Feb 21, 2021

Yes, it is broken, if we re-write the progress dialog to:

c := container.NewVBox(widget.NewProgressBarInfinite())
d.setButtons(c)
d.Resize(fyne.NewSize(200, d.MinSize().Height))

then it works as before.

@fpabl0
Copy link
Member Author

fpabl0 commented Feb 21, 2021

Well, my assumption was wrong the above code does not fix broken progress dialogs, but this does:

bar := widget.NewProgressBarInfinite()
rect := canvas.NewRectangle(color.Transparent)
rect.SetMinSize(fyne.NewSize(200, 0))

d.setButtons(container.NewMax(rect, bar))

Is that fine? It is just a workaround to a deprecated feature, so I think it would be ok, what do you think? @andydotxyz

@andydotxyz
Copy link
Member

Is that fine? It is just a workaround to a deprecated feature, so I think it would be ok, what do you think? @andydotxyz

Yes, like you say it's a workaround but the code is on the way out.

@andydotxyz
Copy link
Member

Looks great - are you still happy @toaster ?

@toaster
Copy link
Member

toaster commented Feb 23, 2021

Looks great - are you still happy @toaster ?

Yes, I am :).

@andydotxyz andydotxyz merged commit 7668395 into fyne-io:develop Feb 23, 2021
andydotxyz pushed a commit that referenced this pull request Feb 23, 2021
* fix modalPopUpRenderer refresh and refresh dialog when it is shown to fix #1866

* update themedBackgroundRenderer functions to respect fyne style guidelines

Conflicts:
	dialog/base.go
@fpabl0 fpabl0 deleted the fix/1866 branch February 26, 2021 17:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants