[GH-ISSUE #230] Can't create custom (third-party) widget due to 'internal' package #125

New issue

Closed

opened 2026-03-03 16:22:36 +03:00 by kerem · 4 comments

kerem commented

2026-03-03 16:22:36 +03:00

Owner

Originally created by @kvnxiao on GitHub (Apr 8, 2020).
Original GitHub issue: https://github.com/mum4k/termdash/issues/230

Originally assigned to: @mum4k on GitHub.

Hi @mum4k , it's me again,

I've been using this library for my project pretty well so far, but I seem to have stumbled upon an issue where I cannot create a third-party custom widget that implements the widgetapi.Widget interface because canvas (and some other draw functions) are part of an internal package. This leads to Go complaining about use of internal package not alloweduse of internal package not allowed.

This prevents me from creating a new custom widget that satisfies my requirements unless I manually fork the repository and add my custom widget into the termdash project's source.

Am I approaching this the wrong way?

Maybe this would be a good thing to clarify / address together with https://github.com/mum4k/termdash/issues/228 for the next release?

Originally created by @kvnxiao on GitHub (Apr 8, 2020). Original GitHub issue: https://github.com/mum4k/termdash/issues/230 Originally assigned to: @mum4k on GitHub. Hi @mum4k , it's me again, I've been using this library for my project pretty well so far, but I seem to have stumbled upon an issue where I cannot create a third-party custom widget that implements the `widgetapi.Widget` interface because `canvas` (and some other draw functions) are part of an internal package. This leads to Go complaining about `use of internal package not alloweduse of internal package not allowed`. This prevents me from creating a new custom widget that satisfies my requirements unless I manually fork the repository and add my custom widget into the termdash project's source. Am I approaching this the wrong way? Maybe this would be a good thing to clarify / address together with https://github.com/mum4k/termdash/issues/228 for the next release?

kerem

2026-03-03 16:22:36 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-03 16:22:37 +03:00

Author

Owner

@mum4k commented on GitHub (Apr 8, 2020):

Hello again @kvnxiao. You raise a good point, in retrospect choosing "internal" as a directory name was unfortunate. It definitely is a goal or Termdash to allow users to implement their own third-party widgets.

The goal was (and is) to indicate that certain API surface of Termdash won't carry backward compatibility guarantee. Specifically the internal helpers won't - they may change at any time to prevent restricting any internal development efforts. If users want guaranteed compatibility on their widgets, the best approach might be to push the widgets upstream into Termdash.

What we can do is rename that directory from "internal" to "private" and clarify the meaning in the main README. I agree that we can release this together with the Go modules, we can release the next version right when this gets in.

Do you want to send a PR renaming the directory from "internal" to "private" in the devel branch, or would you prefer if I take care of this?

@mum4k commented on GitHub (Apr 8, 2020): Hello again @kvnxiao. You raise a good point, in retrospect choosing "internal" as a directory name was unfortunate. It definitely is a goal or Termdash to allow users to implement their own third-party widgets. The goal was (and is) to indicate that certain API surface of Termdash won't carry backward compatibility guarantee. Specifically the internal helpers won't - they may change at any time to prevent restricting any internal development efforts. If users want guaranteed compatibility on their widgets, the best approach might be to push the widgets upstream into Termdash. What we can do is rename that directory from "internal" to "private" and clarify the meaning in the main README. I agree that we can release this together with the Go modules, we can release the next version right when this gets in. Do you want to send a PR renaming the directory from "internal" to "private" in the devel branch, or would you prefer if I take care of this?

kerem commented

2026-03-03 16:22:37 +03:00

Author

Owner

@kvnxiao commented on GitHub (Apr 8, 2020):

I think a change involving package renaming would be easier to do from your side so that we don't have to go through the PR process over github 😛

@kvnxiao commented on GitHub (Apr 8, 2020): I think a change involving package renaming would be easier to do from your side so that we don't have to go through the PR process over github 😛

kerem commented

2026-03-03 16:22:37 +03:00

Author

Owner

@mum4k commented on GitHub (Apr 9, 2020):

I think that is a fair assessment. Sounds good, I will make the change and push a release shortly.

@mum4k commented on GitHub (Apr 9, 2020): I think that is a fair assessment. Sounds good, I will make the change and push a release shortly.

kerem commented

2026-03-03 16:22:37 +03:00

Author

Owner

@mum4k commented on GitHub (Apr 10, 2020):

This should be all done and pushed to master, please let me know if you encounter any further issues.

@mum4k commented on GitHub (Apr 10, 2020): This should be all done and pushed to master, please let me know if you encounter any further issues.

kerem referenced this issue

2026-03-03 16:23:18 +03:00

[PR #125] [MERGED] Allow users to provide custom Y axis scale for the LineChart. #209