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

Fix responsive #79

Open
wants to merge 15 commits into
base: master
Choose a base branch
from
Open

Fix responsive #79

wants to merge 15 commits into from

Conversation

metal3d
Copy link
Contributor

@metal3d metal3d commented Oct 30, 2023

Changes Made:

  • Completely rewrote and refactored the responsive layout.
  • Optimized and precisely placed and sized elements.
  • Resolved issues with previous tests, ensuring logical testing now.

Behavioral Changes:

  • The old layout usage is now obsolete and deprecated due to significant behavioral changes.
  • Introduced a real fyne.Container utilizing the layout, replacing the previous improper use.
  • Ensured proper padding between elements in a line.
  • Non-responsive elements can now be added to the container and will be automatically resized to the default 100% of the container width.
  • Elements are now sized simultaneously while counting paddings, eliminating the need for multiple size calculations.
  • Corrected the error where window size was used to compute responsive element sizes; now, responsiveness is determined by the container size.

Note:

  • Breaking Changes: Existing implementations relying on the old layout might need adjustments due to these substantial changes.

- The padding were not respected between element in a line and stepping
  to the next line
- We now prefer move the first element in a row to the X padding, to
  avoid computation - the responsive behavior is to center elements in a
  row, so it must be OK
- We accept now that a non-responsive element is added to the container,
  it will be resized to the default 100% of the container width
- We previously use the window size to compute the reponsive element
  sizes. That's an error... The reponsivity should be set to the
  container size. That fixed now.
@metal3d metal3d marked this pull request as draft October 30, 2023 09:46
@metal3d metal3d marked this pull request as ready for review October 30, 2023 22:52
@Jacalz
Copy link
Member

Jacalz commented Oct 30, 2023

You can delete the old one entirely if you want to. We have no stability guarantees in this repo :)

@metal3d
Copy link
Contributor Author

metal3d commented Oct 31, 2023

You can delete the old one entirely if you want to. We have no stability guarantees in this repo :)

This is the case 🙂

I use the layout as I should and I added the container object.

@metal3d
Copy link
Contributor Author

metal3d commented Oct 31, 2023

Oh I forget to change the layout.Responsive inside the demo.
I'll do it in a few minutes.

@metal3d metal3d marked this pull request as draft October 31, 2023 09:15
@metal3d metal3d marked this pull request as ready for review October 31, 2023 13:24
Constants needs initial computation. Prefer using functions
// Some helpers to define common ratios.

// FullRatio is the full size of the container.
func FullRatio() Ratio { return 1.0 }

Choose a reason for hiding this comment

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

Why not define constants?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To not store the value. Functions are compiled only if they are used. It's, it seems, a good practice. Maybe I'm wrong.

Choose a reason for hiding this comment

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

Constants are the same https://stackoverflow.com/a/38982889 Most Go I see uses constants

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes.

But for example, Fyne returns colors from function calls, like the Padding or like some several values that are "constant". I propose functions to ensure that we can adapt the ratios from possible futur configuration. For example, following themes.

If it's really a problem, I can of course change the code and set it as constants.

Copy link
Member

@andydotxyz andydotxyz left a comment

Choose a reason for hiding this comment

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

Lots of nice improvements in there, thanks for submitting this. However I'm not sure that adding more "Responsive" entry points is desirable, is there a way to have fewer package global API with this change? Like if the container had Ali for managing ratios instead of passing in wrapped types?

// Responsive(widget.NewLabel("Hello World"), 1, .5), // 100% for small, 50% for others
// )
func NewResponsive(objects ...fyne.CanvasObject) *fyne.Container {
container := container.New(layout.NewResponsiveLayout())
Copy link
Member

Choose a reason for hiding this comment

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

You can pass the objects in the constructor

// ctn := NewResponsive()
// ctn.Add(Responsive(widget.NewLabel("Hello World"), 1, .5))
// ctn.Add(Responsive(widget.NewLabel("Hello World"), 1, .5))
func Responsive(object fyne.CanvasObject, ratios ...Ratio) fyne.CanvasObject {
Copy link
Member

Choose a reason for hiding this comment

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

Hmm, is adding more static functions desirable to handle what is metadata for a single type of container?
It may be a wider design question but if the info cannot be passed in constructor is there a simpler way to handle it that keeps the API entry points to a lower number?

My concern is that "Responsive" could be assumed to work in other places. Like if we accidentally added a "StayLeft" function to describe the position of an item in a border container...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's a question I've been asking myself for some time.

NewReponsive returns a *fyne.Container where the Add() method only accepts fyne.CanvasObject, which is perfectly fine.

As a result, I have two possible choices:

  • either I allow metadata to be added, as I do with Reponsive(), but this effectively transforms the objects into "something else with metadata". But the advantage is that I can always add them to another container without affecting the way it works (for example, to test, I change my container to Grid, which doesn't cause any problems).
  • or I overload fyne.Container to return a ResponsiveContainer that have a Add() method that accepts responsive configuration. But then I'll have two problems:
    • if I change my container to test another one, the "Add()" method will no longer be respected
    • functions that accept fyne.Container will refuse my object

I was thinking of allowing this with NewResponsive() by returning a "config" function signed like this: func(widget, ratios... float32).

So to do it this way:

ctn, configFunc := NewResponsive(label, entry)

configFunc(label, 0.5, 1)
configFunc(entry, 1)

// But how do I add a widget now?
ctn.Add(label2) // This may refresh the view... 
configFunc(label2, 0.5) // and here too

It doesn't look very attractive to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, I think we can adapt the NewResponsive function to make this:

label := widget.NewLabel...
entry := widget.NewEntry...
other := widget.NewEntry...

config := []Ratios{
  {Object: label, Ratios: []float32{1, 0.5}}, // only the label
}

// use the config (or nil)
ctn := NewReponsive(&config, label, entry) // note that entry is not configured

// adding anthor widget
config.SetRatio(other,0.5, 0.5, 1) // if needed...
ctn.Add(other)

That means that I need to keep the Ratios configuration inside the layout, and to remove the Responsive() function + responsive widget.

Copy link
Member

Choose a reason for hiding this comment

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

This seems cleaner

layout/responsive.go Outdated Show resolved Hide resolved
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

4 participants