[Semi-OT] Markdown rendering extension for Thunderbird
I use Thunderbird to read this forum and have gotten jealous of the Markdown formatting that the website supports but that Thunderbird doesn't. So I made [an extension](https://addons.thunderbird.net/en-US/thunderbird/addon/render-markdown-messages/) to render Markdown-formatted messages in Thunderbird. Unfortunately this doesn't allow sending messages with Markdown formatting from Thunderbird—that would probably belong in the [Markdown-here](https://addons.thunderbird.net/en-US/thunderbird/addon/markdown-here-revival/) extension but can't work yet because Thunderbird currently [doesn't allow modifying the content-type header](https://bugzilla.mozilla.org/show_bug.cgi?id=1717221) (bug filed by Vladimir). My extension is limited to reading Markdown-formatted messages.
Re: bindbc-raylib3 release 0.4.0
On 12/10/21 2:57 AM, o3o wrote: On Wednesday, 3 November 2021 at 11:24:09 UTC, Steven Schveighoffer wrote: I have some questions: 1. Why raylib 4.0.0? It’s not released yet 2. Why a new project? What is the difference between this and your bindbc-raylib project? 3. Why “3” as a suffix? My apologies for the late reply. 1. Why raylib 4.0.0? It’s not released yet 3. Why “3” as a suffix? When I started porting, raylib was at version 3, a few days later ramon released version 4... OK. I think when I wrote this, 4.0.0 was not released (but I think it happened in a couple days from then) 2. Why a new project? What is the difference between this and your bindbc-raylib project? bindbc-raylib code is "handmade" and contain all raylib versions (many `versions` conditions) but was very difficult to follow all the breaking changes on raylib API. OK interesting. So you can use the same raylib binding but just define the version you want? bindbc-raylib3 contains only raylib version 4.0 and the code is automatically generated. I agree that auto-generating is the way to go. That's what raylib-d now does. raylib 4.0.0 I think had some drastic API changes. You may be interested to note that starting with the next version, raylib will define a version string that is an exported symbol. I plan to use this to avoid incorrect bindings at runtime: https://github.com/raysan5/raylib/commit/ef6959ed540cd650e13611c35ea543922ab83a98#diff-25a6634263c1b1f6fc4697a04e2b9904ea4b042a89af59dc93ec1f5d44848a26 -Steve
Re: DQt: Qt bindings using extern(C++)
On Friday, 10 December 2021 at 17:38:56 UTC, Tim wrote: I have not released the converter yet. It is currently not very user friendly and needs many manual changes to the result, which I want to improve. It also has Qt specific parts. I will definitely be watching for the release of the converter code! Today I read through the D tour, so I now feel like I have a fairly good grasp of the language and am ready to start doing things with D instead of with C++, which means that I am doubly excited about getting DQt to work with all of Qt. Qt does not use many types from the C++ STL or new C++ features in the API. This makes the bindings for Qt a bit easier, because only types from Qt are necessary. Maybe Qt 5 doesn't use lots of new C++ features, but Qt 6 may be harder to generate bindings for since it requires C++17 instead of C++98. Anyway, if you ever want some extra help with this project, I'd be glad to lend a hand!
Re: DQt: Qt bindings using extern(C++)
On Friday, 10 December 2021 at 02:35:12 UTC, LorenDB wrote: Can we see the converter source? I'd be interesting in both looking at the code and also seeing if I can modify it to work with another library (i.e. Wt). I have not released the converter yet. It is currently not very user friendly and needs many manual changes to the result, which I want to improve. It also has Qt specific parts. Qt does not use many types from the C++ STL or new C++ features in the API. This makes the bindings for Qt a bit easier, because only types from Qt are necessary.
Re: Skia library for D, porting from SkiaSharp API.
On Wednesday, 8 December 2021 at 02:39:57 UTC, Imperatorn wrote: On Monday, 6 December 2021 at 09:08:20 UTC, zoujiaqing wrote: SkiaD is a cross-platform 2D graphics API for D based on Mono's SkiaSharp. It provides a comprehensive 2D API that can be used across mobile, server and desktop models to render images. https://github.com/gearui/skiad Nice, consider adding it to dub if you haven't done so already Thanks, dub repo is here: https://code.dlang.org/packages/skiad
Re: bindbc-raylib3 release 0.4.0
On Wednesday, 3 November 2021 at 11:24:09 UTC, Steven Schveighoffer wrote: I have some questions: 1. Why raylib 4.0.0? It’s not released yet 2. Why a new project? What is the difference between this and your bindbc-raylib project? 3. Why “3” as a suffix? -Steve My apologies for the late reply. 1. Why raylib 4.0.0? It’s not released yet 3. Why “3” as a suffix? When I started porting, raylib was at version 3, a few days later ramon released version 4... 2. Why a new project? What is the difference between this and your bindbc-raylib project? bindbc-raylib code is "handmade" and contain all raylib versions (many `versions` conditions) but was very difficult to follow all the breaking changes on raylib API. bindbc-raylib3 contains only raylib version 4.0 and the code is automatically generated.
