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

Tabs support #1836

Merged
merged 17 commits into from May 8, 2021
Merged

Tabs support #1836

merged 17 commits into from May 8, 2021

Conversation

adrianre12
Copy link
Contributor

Description:

This PR adds tab support to Entry and Label via the text Canvas. It is done by replacing font.Drawer with painter.Drawer. painter.
Drawer embeds font.Drawer and implements custom DrawString() and MeasureString() that handle the tab rune.
When a tab rune is encountered the draw dot is advanced to the next tab position. The tab positions are whole multiples of
tabWidth * spaceWidth where tab width is in characters and the space width is in dots.
The tab width is set in the theme and defaults to 4. The space width is found from the width of the current fonts space glyph.

I have reverted the tab approximations done in #761

Fixes #1791

Monospaced=true
image

MonoSpaced=false
image

Checklist:

  • [X ] Tests included.
  • [X ] Lint and formatter run with no errors.
  • [X ] Tests all pass.

Where applicable:

  • [X ] Public APIs match existing style.

go.mod Outdated Show resolved Hide resolved
go.sum Outdated Show resolved Hide resolved
go.sum Outdated Show resolved Hide resolved
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.

This is a ggreat apprach, sorry it got left for a while.
One or two change requests and an open question about where we really should store the "4 spaces" option.

internal/painter/drawer.go Outdated Show resolved Hide resolved
internal/painter/drawer.go Show resolved Hide resolved
theme/theme.go Outdated Show resolved Hide resolved
widget/textgrid.go Outdated Show resolved Hide resolved
// TextStyle represents the styles that can be applied to a text canvas object
// or text based widget.
type TextStyle struct {
Bold bool // Should text be bold
Italic bool // Should text be italic
Monospace bool // Use the system monospace font instead of regular
tabWidth int // Width of tabs in spaces
Copy link
Member

Choose a reason for hiding this comment

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

Can't we just used a public field like the other items? the check for 0 can be done inside the text code instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

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 think this is done. The default code below is what causes the exposed public API above - if we just use a public field as suggested then the default handling would be in painter / widget and would avoid the additional API requirements.

widget/textgrid.go Outdated Show resolved Hide resolved
widget/textgrid.go Outdated Show resolved Hide resolved
widget/textgrid.go Outdated Show resolved Hide resolved
widget/textgrid.go Show resolved Hide resolved
widget/textgrid.go Outdated Show resolved Hide resolved
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.

Not sure we were on the same page regarding the benefits of TextStyle.TabWidth.
Exposing the field instead of the methods used would reduce the API footprint of TextStyle as well as remove the need for the public DefaultTabWidth.

@@ -30,12 +30,33 @@ const (
TextWrapWord
)

const (
// DefaultTabWidth is the default width in spaces
Copy link
Member

Choose a reason for hiding this comment

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

API introduced needs a since header:

//
// Since: 2.1

However - I don't think this API is necessary. If the defaulting was handled in the renderer and widget packages we could hide it in an internal package until we decide if this detail should be exposed...

// TextStyle represents the styles that can be applied to a text canvas object
// or text based widget.
type TextStyle struct {
Bold bool // Should text be bold
Italic bool // Should text be italic
Monospace bool // Use the system monospace font instead of regular
tabWidth int // Width of tabs in spaces
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 think this is done. The default code below is what causes the exposed public API above - if we just use a public field as suggested then the default handling would be in painter / widget and would avoid the additional API requirements.

// TabWidth either returns the set tab width or if not set the returns the DefaultTabWidth
func (ts *TextStyle) TabWidth() int {
if ts.tabWidth == 0 {
return DefaultTabWidth
Copy link
Member

Choose a reason for hiding this comment

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

Neither this nor the setter are required if the field is public

@andydotxyz
Copy link
Member

Hey @Jacalz would you be OK if I landed this and made the changes I requested, or did you have additional requests?
I feel bad that some PRs are hanging on so long when it's just simple differences holding it back.
Folk get busy but I'd like to help land some of these older changes.

@Jacalz
Copy link
Member

Jacalz commented May 8, 2021

Go ahead. It's fine for me 🙂

@andydotxyz andydotxyz merged commit f7c9f60 into fyne-io:develop May 8, 2021
@andydotxyz
Copy link
Member

Thanks so much for all your work on this @adrianre12, I have now landed it with the changes requested above.
When you have time feel free to look at develop branch if you want to check over my work.

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