Split the Package?

[liamzee]

Might it be more useful to split monomer off into a core monomer package, as well as some widget collections that depend on monomer?

For instance, I think there's a bunch of stuff missing on monomer animation, as well as options that might be missing in monomer and would be nice to add. As is, I'd have to do a pull request on the entire monomer repository, adding code that might not be easily ported. If monomer were split off into monomer-core, monomer-widgets-core, etc, it'd make it easier for others to develop their own widget packages for monomer and share them.

Moreover, it'd make it easier to learn the library because instead of having to go through all widgets, you'd only need to go through the core library and learn an abbreviated monomer-widgets-core library instead, instead of not having priority through the assorted widgets.

[Deltaspace0]

@liamzee Hi, actually I recently added a bunch of new animations to my fork of monomer. I am just waiting for my pull request of removing redundant imports and fixing typos in documentation to be merged, so I can rebase my animation branch and open PR for them. Meanwhile you can check them out on my fork.

Also, I have been working on my custom collection of widgets for monomer. I needed some composites in my projects and I wrote them and figured that they can be useful for other people, so I created a repo with all of them. If @fjvallarino creates an official monomer-widgets-core repo which you are talking about, then I would consider moving all my custom widgets there.

[fjvallarino]

@liamzee @Deltaspace0 the Monomer package is already Monomer Core. It provides the following features:

• OS and event handling abstractions.
• Application lifetime.
• A foundational set of widgets that most applications need.

The last point may be the most controversial since some of the widgets are clearly not foundational. Mostly I'm thinking about alert/confirm, colorPicker/colorPopup, split, and themeSwitch, but depending on each one's perspective, others could be included. Some reasons for having widgets in the library's core are:

• Excluding those items, I believe the library needs to provide a basic set of features without requiring users to find out which extra packages they need. Separating them into widgets-core would create a more confusing user experience.
• Some of the mentioned widgets were used as a test bed for figuring out how things could be done (ColorPicker and ColorPopup) and to also show that other things could indeed be done (the really basic animation package the library includes).
• As such, reading their source code can be useful when thinking about new widgets.
• Additionally, having some of these widgets around in the main package helps me test things more easily because I can avoid compile/reload cycles and only use ghcid. Losing this would cause friction and complicate testing issues that are reported.

What do I think about external packages implementing widgets? I think that's the correct way of handling new widgets. Take, for example, Hagrid. It provides really useful functionality, relying on the core features provided by the library, but it's an independent package that can evolve as fast as its maintainer wants and can do things however is deemed better. The creator owns the package and can implement its vision without restrictions of any kind.

If somebody creates a package with a single widget or a collection of widgets, I'd be more than happy to link to it on the project's main page. This also applies to most of the widgets I could create in the future (save for a couple of layout-related ones). Doing this will simplify the maintenance of the core library and avoid having me as a blocker. Can I help if questions arise? Absolutely. But most new widgets do not require changes to the Core library; if changes are required, we can discuss/implement them.

Going back to the original question: I think forking the library to add a new widget is not the best option and having separate packages is the preferred way, since it gives more control to the creator of the widgets and removes blockers. I will make it clearer in the Readme.

[liamzee]

@fjvallarino I'm more concerned with the quality of some of the widgets; for instance, external link is not a widget compositor, which means that I'd need to reverse engineer it to get Andy Warhol's image to spawn an IO request to open a browser with a link to the monomer site.

I'd personally consider myself too inexperienced to hack around the core library, but I'd love to attempt to contribute (with some oversight) onto widget libraries, but I was hoping more for officially supported extension libraries under your control, such as animation, common IO tasks, and so on.

I guess it goes into a certain other conversation, I really love your work and I suspect that if monomer has enough friends, it might end up becoming the dominant Haskell GUI framework, the absence of which having been claimed to have limited Haskell's adoption.