Welcome on this 2nd edition of my monthly blogging challenge, Code Libre! You can check the previous post if you think you missed anything or just want a recap of what this serie of blog posts. Here’s a quick recap: Code Libre is a short list of cool open-source projects I’ve found while browsing the Internet. Sometimes I do test them, sometimes I don’t.

Electron-wallpaper

   I’ve always been a fan of conky and rainmeter but when I used them, they required specific scripting tools and language to use them and build with them. In fact, the most advanced setup I had with conky years ago was showing the date with a custom font. Now with this node module, you can use an Electron window instead. That means that instead of using lua code or xml config files to customize your fancy dynamic wallpaper, you now only need to know HTML, JS and CSS. It also means that the code you write for your animated dashboard could potentially be cross-platform. I did not however find or look into any equivalent for Linux node modules, so this is Windows only.

• Project’s repository

Phalcon

   Since PHP is a scripting language that can take extensions made in C, we can imagine that maybe some day, someone will actually use this ability to write quicker PHP applications. And this is just what this framework does. It leverages the speed of C and allows PHP developers to keep using a language they already know while taking advantage of a much faster framework. I still think I would stick to Symfony for PHP applications, but this is still a very interesting technology!

• Project’s website
• Project’s repository

Mastodon

   A decentralized social media platform. Anyone can setup a Mastodon instance and monitor it as they please but the best part is that each Mastodon instances can communicate to each other. In a way, this could be social medias going back to mail servers where everything was decentralized and mail servers used to send mails back and forth each others. This is not only great because with this solution, one can speak freely without fear of censorship and because the network of instances should be able to standup and still work if another instance is taken down.
   This isn’t the first time I’ve seen open-source social media alternatives however this one seems to have a significant community and this is very good! When comparing to a similar open-source project that I’ve discovered years before: pump.io, Mastodon have almost 10 times the number of Forks and Stars on Github. I love this idea of social media platform where each instance of the platform can pull and push data from another instance. I wish more people would turn to open-source alternative as this would - I think - free us from issues we have with the giants.
   I’ve also heard of a blogging system named Plume that could potentially plug into Mastodon as well as work in a similar fashion. Yet another interesting decentralized media!

• Project’s website

Open-source Rover

   Last but not least, the JPL Open Source Rover project! NASA recently open-sourced a 6-wheel rover based on the one that is on Mars. This version of the rover is also designed to be accessible to everyone and “inspire the next generation of scientists, engineers and roboticists”. They give most of the details required to build the robot, going from the parts to the steps to actually build it!

• Project’s repository

That’s it

   I hope you enjoyed this post! I decided to not use any kind of analytic software to track the readers so having feedback means a lot! So how about you, do you explore Github too sometimes? Have you found any interesting stuff? I would love to hear your opinion and/or your feedback! I’ll see you next time :).

-Tym

   I presented the system of dynamic anchors that allowed an element of the GUI to use positions or sizes based either on a percentage of the window either on a fixed pixel size. I also explained a bit how it works under the hood. You can check the whole post here.

Dynamic Anchors

   That system to represent the sizes and positions allowed me to create a dependence on the position of another anchor. An anchor can now depend on another’s position. This allows the user to create a unified widget out of multiple different components such as a modal with a line of text and a button. In order to do this, I implemented a system of observers in the Anchor class so when the window is resized or the anchors are changed, they will notify their observers so they can make the change too. This is particularly useful when you want to make a widget that can be moved with his inner components together.

The red Debug text has its anchors relative to the cyan rectangle.

Responsive Skinning

   Since the GUI is supposed to be adaptable to any window size, the skinning of the GUI elements should be able to stretch without loosing its look. My solution to this is similar to the way the Unity Engine handles its GUI components. It takes a texture and then splits the texture in 9 different parts. Each part is used at a different place of the element. The sprite is split in a way that a pixel is left at the middle of each part. That way when the middle parts are stretched it will not look different because it is only one pixel. Here is an example with a sprite having a letter in each corner.

Regardless of the size of the window, the letters in the corners stays the same size.

   While this is pretty handy to have components with responsive styles, this comes at a cost. For some components like a button it requires 3 different skins, one for the basic state, one for the hover state and the other one for when the user is actually clicking on the button.

Current limitations

   The Anchor system is way too complicated and requires a factory to complete all the parameters in a simple and quick manner. An other issue is the number of parameters a component requires. A simple button requires 4 anchors, 3 skins, 3 colors and more…

1
2
3
4
5
6
7
8

ActionButton(sf::RenderWindow &, const std::function<void()>,
const std::string &txt, const sf::Font &font,
Anchor pX, Anchor pY, Anchor sX, Anchor sY,
const Skin &off, const Skin &on, const Skin &hovered,
int charSize = 16, sf::Color textColor = sf::Color::Red,
sf::Color hoverColor = sf::Color::Red,
sf::Color triggerColor = sf::Color::Red,
bool show = true);

   It’s not that good, it makes the process of creating the elements way too complicated. The same goes for the component interface that every component is supposed to have. Some components require being able to react specifically to some events so more methods are added to the interface but that only creates more methods that aren’t used in already existing component or simple ones. Here is what this interface looks like at the moment this post is published:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

class IComponent
{
    public:
        virtual ~IComponent() {}
        /**
        * @return true if has to be drawn
        */
        virtual bool isVisible() const = 0;
        virtual void setVisible(bool) = 0;
        /**
        * @return true if mouse is in hot zone
        */
        virtual bool isIn(float x, float y) const = 0;
        virtual void trigger() = 0;
        virtual void unTrigger() = 0;
        virtual void hover(float elapsed) = 0;
        virtual bool isHover() const = 0;
        virtual void unHover() = 0;
        virtual bool isActive() const = 0;
        virtual void setActive(bool) = 0;
        virtual void triggerKey(const sf::Event &,
                                float elapsed) = 0;
        virtual void update(float elapsed) = 0;
        virtual void draw(float elapsed) = 0;
        /*       /!\         /!\         /!\         /!\
        ** if creating a new component, don't forget to add 
        ** observers to Anchors in the component's constructor
        */
        virtual void resize(const sf::Window &) = 0;
        virtual bool propagateAfter() const = 0;
};

   Adding to the cost of having to handle so many parameters or so many useless methods when creating a new UI component, the developer has to store and handle the Skin objects and carry them everywhere he wants to create a new component or widget. This also prevents the creation of a default look for the GUI. Some application might not require such advanced behaviour regarding the skinning of the GUI elements.

Takeaway

   I am not satisfied with the result of this GUI engine and I’ll probably start over a third time but like the last time, I learned a lot while doing so. I am not sure yet if I’ll make this attempt open-source or not, but I probably will in some time. Here are the things I’ll try to avoid when creating the next iteration of my GUI engine:

• Way too many methods in the component interface.
• Creating a simple component is too complex.
• Lack of default theme.
• Using Visual Studio as only build reference for the project.

   An other thing I would like to keep in mind for the next version is the ability to use the GUI engine in a simple SFML project without requiring the states system I started with. That way, anyone could use this GUI library without as much restrictions. I hope you enjoyed this post :).

-Tym

   So as I explained in the last post, I browse Github a lot and sometimes I find very interesting stuff. A friend of mine once asked if I would do a quick summary of my findings on my blog even if I don’t particularly test them so here it is! It’s named Code Libre, pronounced like the cocktail but with Code instead of Cuba. I wanted some kind of fancy name because I plan to do this often and it could be considered as a serie of posts I guess. So without further ado, let’s dive in.

Ninja

   Did you ever wish you could become a ninja? Well sadly this tool won’t make you one but it might make you feel like you are compiling like a ninja. It’s a small build system focused on speed.
   If your C/C++ project already has a CMakeLists.txt file, you only need to run cmake -GNinja and it will generate a Ninja Makefile! Once this is done, type ninja and boom your code is compiling (at least if your C++ can compile).
   I’ve actually tried this tool to build a specific branch of the SFML Library and it went so fast I thought something went wrong and I didn’t setup the library correctly! This tool seems very interesting however I still need to look into how it works to debug code built using this system on Visual Studio as I love it’s debug tools.

• Project’s repository

CppSharp

   If you want to use C# but your favorite library is in C/C++, this tool might be useful for you. According to the project’s README.md, it seems to be a tool and set of libraries that could bind C/C++ libraries to C#. Some parts of this tool are based on Clang, the C/C++ compiler. It is also part of the Mono project so it should be compatible on multiple platforms.

• Project’s repository

Utterances

   Recently, I changed the comment system of my blog and switched over to Github issues. I made the style and the API calls to Github by myself. Few days later, I stumble uppon this project which seems to do exactly that and seems to have even more features. So if you are interested in doing something similar for your blog or website, this might be worth looking to. It is even used on the Haxe documentation.

• Project’s repository

Forgelin

   Kotlin has been spiking my interest for some time and when I found this project, it made me want to play Minecraft. I always dreamed about creating my own mods on this game but never took the time to make something as complex as I imagined. This project seems to allow the creation of Minecraft mods in Kotlin. It kind of make sense since Minecraft and its mods are in Java, Kotlin should work too since it operates on the JVM.

• Project’s repository

That’s it

   I hope you enjoyed this post! To my surprise someone actually commented on my blog yesterday and I would like to thank him again for this. I decided to not use any kind of analytic software to track the readers so having feedback means a lot! So how about you, do you explore Github too sometimes? Have you found any interesting stuff? I would love to hear your opinion and/or your feedback! I’ll see you next time :).

-Tym

   Welcome to my blog Again! I initially picked a theme named Cactus Dark that I found on the Hex website that looked nice and had some kind of programmer feel to it. However, I wasn’t really happy with how the theme behaved on a large screen such as a desktop one. So I went ahead and made some small changes for displays that are large enough to fit the entire menus.

• There is now a side menu for the navigation.
• Post related navigation & buttons are a side menu too (I love side menus).
• There is now a progress bar on post pages that progresses as the user scrolls down the page.
• I changed the color of few things so the color accent is more present.
• New comment system that I’ll explain later in this post.
• RSS Feed now works.
• New download page layout.
• A working tag page

Github as a comment platform

   Since the beginning of the transition of this blog to Hexo, the comment system was run using Disqus. On one hand, it allows me to keep a statically hosted website (which is free) and have dynamic comments that do no require people making an account just for my blog. On the other hand, I have to include their scripts which after reading some articles led me to think again about it since I care about privacy. So I took the same route as both of those blogs took and switched to Github for comments while making the few changes I wanted on the theme.

   There are few upsides and downsides to this but I’ll begin with Disqus before listing the ups and downs of using Github as a comment system. While Disqus is pretty handy (you only have to configure the already embedded Hexo plugin and poof it works), it means that users are also required to have a Disqus account to comment on your blog. The way it is designed also requires me to check on it regularly to moderate/approve pending comments, which make yet another thing to check when booting the computer. Comments sections were also automatically created and made available to the Disqus’ thread of the blog when developing locally, creating a new Disqus thread per dummy/draft/test posts that would not even be of any use and would come as duplicates of final post threads.

   Meanwhile Github was not really intended for this, I had to do some work to get it working as I wanted. Since Github is one of those websites I browse almost constantly during my free time this also remove that one more place to check when I boot up my computer. Regarding privacy, I trust Github more than Disqus and the way the comment section is now done is just a single Github API call to get an issue’s comments. From my point of view, all of this has many advantages and makes managing comments easier (even if there are none yet).
   Regarding the user’s perspective, I could imagine arguments that could be seen as assets or drawbacks. The most positive asset is that now, if someone is interested in this blog, they can subscribe to the Github’s repository containing all the issues to get it included in their Github’s feed. As an example, a long time ago a friend told me that he was waiting for me to deliver a mailing list to update him on the blog posts I would make, however, I did not have a proper marketing email setup ready and the mailing list was filled with mail addresses that were most likely inserted by bots scouting for Wordpress installations. Now he can subscribe to the Github repository and have notifications when a new post is released. Users are no longer required to have a Disqus account but they are required to have a Github one if they wish to comment. Since I’m mostly talking about software and programming in my blog, I assume it is more likely that someone will have a Github account than a Disqus one (even if I may be wrong). Looking at the comments of one of those articles that led me to it also made me notice that once a user comments on an issue he will automatically watch the issue and receive emails when some one else comments or mentions him. I can see why this could be annoying but this also means that the user will be notified if someone responds to his comment.

More details

   If you like the new version of this theme, you can find it on Github at Tym17/KosmoKot, it’s mainly some kind of fork from the original theme but when it was at version 2.0, so the version of the theme about 7 months ago from the time this post is released. This gave me an occasion to practice my front end skills as well as learn new techs: Stylus and EJS. And I had a lot of fun doing it. I was also surprised that when looking for an alternative in Javascript to the PHP templating engine Twig, I never found EJS.
   The main things I modified were the features I mentioned at the top of this post. I am very happy of how I made the comment section as the required javascript code to load the comment engine is only included in the pages that requires it.

What’s next

   I don’t know yet. I have a lot of ideas for blog posts but I need to take the time to write them and if they contain pseudo code, test them. A friend of mine was also interested in some kind of condensed form of my open-source findings (I accumulated about 1.3k Starred repositories on Github at the time this post is released), so I might as well finally start doing this, may it be on random occurrences or monthly. If there is anything you may be interested in, do not hesitate to comment below and I’ll look into it!

-Tym

   While thinking about creating interesting content for my blog after not having posted anything for a while, I taught that blogging about my progress on my quest to make my very own GUI engine from scratch might gather the interest of some people like it was the case on the unofficial French SFML’s discord.
   So here it is! Since I started this GUI engine a while ago, I might not be able to cover as much details as I could have when I was freshly programming it. I will however try to explain it in details and if any questions arises, the Disqus comments thingy at the bottom should be there!

Introduction

   At it’s core, the engine is designed to allow me to create games using the SFML Library. I always liked to create things from scratch and this engine is no exception. The main idea is that a class will take care of the window as well as it’s loop and will contain a finite state machine. A small variety of states can actually be fed to this state machine to this day:

• Abstract State: This state is nothing more than a few functions like update(elapsedTime) and draw(elapsedTime). It doesn’t really do anything and is usually there to serve as a boilerplate for any upcoming states that one might want to create.
• Abstract UI State: This one is very similar to the above state however the key difference is that it embeds a container of uiComponents and a few key functions that takes care of calling the proper functions for those interface components such as hover() or trigger() when an item is hovered or clicked/triggered.

   With those states, I -or anyone using this library- should be able to make simple game using my GUI engine. One point of which I truly appreciate is that the UI components only require to be instantiated once and depending on their role, might not need extra care after the state has been instantiated except when changing its content or something among those lines, but no extra checking for the Window’s events or extra resizes.

2nd Iteration

   Since this is my 2nd attempt at creating a GUI engine, I already had some constraints I discovered while creating the very first GUI Engine.
   The main flaws were that if any event was to happen and that any UI component would have been above or under an other UI component or any other sensitive area (for mouse events), it would have triggered everything in the zone! So I required a way to stop the propagation of the events once it would hit a component. With this problem in mind, I tinkered around and managed to implement a solution that works for now. I think however that when I will start implementing more complicated components such as drag and drop-able components, I might face some issues.
   The other issue is that components relied heavily on some kind of utility class that I would add to almost every component class that did not do much. It could have been replaced by a singleton or could have been made in a better way. This utility allowed me to place my components on the window using a percentage ratio of the window, allowing the rest of the game to keep its original size but having a GUI that scales up or down depending on the window’s size. One of the solutions that came to my mind were that I should just drop the way I used to place the components, completely forgetting about using percentage on the game’s window. However, by mixing that utility class to a point class, it allowed me to create dynamic anchor on my windows. Elements could now be created with positions that could be either fixed/precise positions in pixels (or at least, SFML’s window’s units) as well as percentage of the Window.

Demo of two buttons using percentage and precise anchor types for position and size.

Conclusion

   To this day, some features are still missing the Library for me or anyone to use it in a efficient or enjoyable fashion. I just added today a way to have anchors that can depend on other anchors to determine a position or size, but there is still some unsolved problems lying around them or some aspects that I would like to change to its usability. But that is a subject for an other post.
   I hope you enjoyed my first non-“Hello world” post I put on a blog for the last 2 years this blog post :).

-Tym

   Welcome to my blog! Last year I taught it would be a nice thing to get a blog running as one of those new year resolutions but I only assembled a WordPress and few plugins together and published 2 posts, which isn’t that much for an initiative about posting useful stuff and updates on things I create?

   So this year, I decided I would keep it simple. I got my hands on Hexo which is (in my opinion) very easy to understand and use. It also seems simpler than WordPress and (hopefully) I won’t get as much junk from bots scavenging peaceful WordPress installations.

That’s a nice theme

   This blog uses a modified Hexo theme I found on Github at probberechts/cactus-dark. I tweaked it a bit to have the greenish accent set with my favorite color (That blue I put everywhere). I might as well tweak it some more in the future and maybe fix some bugs I encountered but this theme looks really nice. Thank you probberechts!

-Tym