New Themes

[VisenDev]

Initial implementation of a Dracula and a Jungle theme. Added corresponding new fonts

[david-vanderson]

This is awesome - thanks so much!

My read of the pixel_intv license means it restricts commercial use, is that correct? If so we'll have to find an alternative so that the whole dvui repo can stay licensed under the MIT license.

Also do you think there should be a dvui.themes namespace?

[VisenDev]

My read of the pixel_intv license means it restricts commercial use, is that correct? If so we'll have to find an alternative so that the whole dvui repo can stay licensed under the MIT license.

Oh my bad, I didn't read over the license too closely. I will find a replacement.

Also do you think there should be a dvui.themes namespace?

I think that would be a good idea.

Fonts should probably also be its own namespace. I am also considering reworking the implementation of the Font fields of Theme so that ttf_bytes are not stored directly in the font handle. This would allow for a Theme (Which contains a Font) to be easily serialized into json, and thus open the door for end users of dvui applications to load custom themes at runtime from a json file.

[VisenDev]

Okay I replaced the commercial-use restricted font with a font under the Open Font License which seems much more permissive.

[david-vanderson]

Thanks! Looks pretty good!

One question I have with the font_bytes change is how to implement something where the user is adding a font to an app at runtime. I'm trying to think of a way to have both (being able to serialize a theme and adding a font at runtime). Any ideas?

The only thing I've thought of so far is to have the theme record a "font name", but then we're into the swamp of trying to find a font matching a name, and how do you pick between a built-in font and an external font.

Maybe it could help to understand more of the motivation behind wanting to serialize a theme? Can you give me details about what the usecase is here?

[VisenDev]

One question I have with the font_bytes change is how to implement something where the user is adding a font to an app at runtime. I'm trying to think of a way to have both (being able to serialize a theme and adding a font at runtime). Any ideas?

The only thing I've thought of so far is to have the theme record a "font name", but then we're into the swamp of trying to find a font matching a name, and how do you pick between a built-in font and an external font.

I would just replace the TTFBytesEnum with a StringHashMap that maps font names to bytes. The StringHashMap can be populated with builtin fonts on initialization, and the user can add new entries to the hashmap at runtime to register new fonts.

I just didn't do this since I didn't know if we wanted to support custom fonts at runtime. But I can work on implementing this.

Maybe it could help to understand more of the motivation behind wanting to serialize a theme? Can you give me details about what the usecase is here?

If I develop an application like a text editor with dvui, I'd like users to be able to easily load new custom themes, rather than being limited to the themes I had built in when I compiled the application. Removing ttf_bytes from the Font implementation allows opens the door for dvui.Themes to be serialized and correspondingly parsed from a file directly.

[VisenDev]

Example of serializing a theme at runtime.

(The other reason I was interested in Theme serialization is because I was thinking about working on a dvui-theme-designing application - so being able to import and export themes as text was important)

[david-vanderson]

That sounds good to me! Do we need to worry about a builtin font having the same name as one the user is trying to add?

After thinking about it for a bit, I don't have a good solution, so maybe we don't worry about it for now - just have a single StringHashMap initially populated by the compiled in fonts, and can be extended at runtime.

[VisenDev]

Okay I added a ttf_bytes_database to dvui.Window which maps font ids to ttf bytes

[david-vanderson]

Let me know when you are ready for me to merge this.

[VisenDev]

Let me know when you are ready for me to merge this.

It should be ready to go

[VisenDev]

I'm pretty happy with how the Jungle theme turned out. Once the raylib backend is working, I'm gonna try to use this for the UI in my game.

[david-vanderson]

That looks really good! I hope to look through this and merge it in the next couple of days.

[david-vanderson]

Okay I merged locally and pushed. Clearly I'm not great at doing github stuff, but I think I got everything here.

Let me know if I missed anything or you disagree with any followup changes I made. Thank you very much!

[david-vanderson]

Oh - one question. You added Color.merge() - is there a more specific name we can use for this, like Color.alphaBlend()?

[VisenDev]

Oh - one question. You added Color.merge() - is there a more specific name we can use for this, like Color.alphaBlend()?

Yes, feel free to change it. I just wanted to add a color combining function to make the creation of style_err and style_accent easier when making new themes