pyrustic VS litemark

Note that the above docstring format exists and the documentation generator that consumes it is not public. This docstring format is visible in the source code of my projects (https://pyrustic.github.io).

Braq is also used by Paradict for config files. This is what a config file in Paradict format might look like:

  [user]

Hi HN !

I am excited to publish my very first white paper. I've been working on a framework called TkF (originally called Pyrustic Framework) for several months now, to make Python applications. The framework uses Tkinter (the default Python GUI toolkit), comes with new widgets (megawidgets to be precise), a dark theme, a CLI tool to manage Python projects, and other libraries I have developed for styling, multithreading, etc. I did other side projects to test the framework and discover weaknesses which I then correct. I was happy with the project because it just works.

But I was not really productive with TkF. It takes a long time to create a GUI [1]. So I thought about creating a GUI builder. After several days of thinking, my thoughts drifted away from the Python philosophy: simple is better than complex. I eventually gave up on the idea of the GUI builder because among other reasons, I don't like using a GUI builder, for example it hides a lot of the complexity that comes back like a boomerang afterwards. A big software bazooka does not necessarily convince everyone, for example many people still prefer to use Vim or Emacs instead of an IDE [2].

So I created the framework Dresscode. I chose this name Dresscode only to be able to make the sentence "Dress up your code with a beautiful GUI !". If TkF is C, Dresscode would be Python. With Dresscode, main views are Pages and widgets are graphical Components. Dresscode is not a GUI builder but it is designed to build a GUI as fast as a GUI builder but with two drawbacks: you will have to type some code (although it is not a lot of code compared to TkF), and the layout mechanism is not very flexible. Still to allow the developer to be productive, I implemented a very simple idea: a navigation bar automatically populated with references to the Pages (example: Home, About, etc) of the application.

A few days ago, I was editing the READMEs of each of the Pyrustic Open Ecosystem [3] projects to improve them. The README of the TkF project has a nice cover image [4] which is a screenshot of a demo made with TkF. I wanted such a pretty image for the README of Dresscode. But this demo cannot be done as is with Dresscode without cheating. There are two buttons "Cancel" and "Connect" under a form which cannot be reproduced as it with Dresscode because the layout mechanism is not very flexible (flexibility restricted to gain in productivity).

I wanted to unlock the potential of the layout mechanism without sacrificing developer productivity. To do this, I introduced the notion of "parent" which allows the developer to freely decide where he wants to install a widget (or group of widgets) on a view. Thanks to serendipity [5], I had other interesting ideas. I thought that all of this might form a concept that can be implemented in other programming languages. So I named the concept GASP: GUI As Stapled Pages. Here, the navigation bar represents the staple. I decided to create a new project and to abandon Dresscode. I wrote the reference framework named Gaspium [6] then wrote a white paper to encourage other people to adopt the concept and implement it in other programming languages (even other implementations still in Python but with Qt or wxWidgets or GTK etc).

Gaspium is a lightweight framework for building GASP applications and it was created with TkF. In short, we define pages to which we add graphical components. With a single line we add a complex graphical component to a page and the layout mechanism is controlled with only 5 keyword arguments ('parent', 'side', 'anchor', 'fill', and 'expand') whose defaults are sufficient in most cases. Then we add these pages to an instance of the App class. The first page added is de facto the home page and it will be open when the application is started. Adding a page makes it automatically referenced in the application's navigation bar. Each graphical component can be identified with a unique identifier in order to be able to read its content or update it. Each page has a unique identifier assigned automatically or manually. You can open an arbitrary page directly from the command line and even pass data to it. Gaspium is suitable for: building internal tools, teaching GUI programming, building GUI wrapper for command line scripts, prototyping, building utilities for yourself or other programmers, lightweight commercial apps, et cetera.

The concept of GASP not only makes it possible to be more productive in GUI programming, but it changes the relationship that developer and user have with an application. On the developer side, the concept of GASP structures his ideas to think of his project in independent parts (the pages), which represents a big advantage in terms of organization and maintainability of his project. For the application user familiar with monolithic applications, the concept of GASP turns the application into a series of useful programs, each with a graphical interface that can be invoked arbitrarily from the command line.

I already use Gaspium according to the principle of dogfooding. Gaspium documentation is still precarious for the moment, but that will change soon. The Pyrustic Open Ecosystem of which Gaspium is a part, has been updated (Generation of documentation, git workflow, packaging, versioning, PyPI release ...) with an internal tool that I created in a very short time with Gaspium and Backstage (Backstage [7] is a CLI tool to manage Python projects). I can't wait to read your thoughts [8] on all of this, or show me a similar project etc. If you hate GUI programming or find it too difficult, I would like to know if this GASP concept makes you want to do GUI programming and why. Thank you for your attention !

[1] https://blog.codinghorror.com/ui-is-hard/

[2] https://news.ycombinator.com/item?id=25036036 (Why are so many coders still using Vim and Emacs?)

[3] https://pyrustic.github.io (Pyrustic Open Ecosystem)

[4] https://raw.githubusercontent.com/pyrustic/misc/master/asset... (Cover image for the README of the TkF project)

[5] https://news.ycombinator.com/item?id=1826666 (Paul Buchheit: Serendipity finds you)

[6] https://github.com/pyrustic/gaspium

[7] https://github.com/pyrustic/backstage

[8] http://sl4.org/crocker.html (Crocker's Rules)

[1] https://github.com/pyrustic/pyrustic

- ensures that more an app is recommended by different developers, as well as a chance to be in the promotion list often (until the user decides to install it).

The choice to put a Promoted button on which the user can click may seem naive. Implementing intrusive pop-ups can be recommended as a more pragmatic method. This choice to trust the altruistic curiosity of users was influenced by an observation (I have 0 statistics to show) I made here on Hackernews: there are always users who click on Newest (https://news.ycombinator.com/shownew) to bring up posts that might deserve attention, though these users are not affiliated with these posts.

I want Hubstore to make it easy to distribute and promote Python apps (built with Pyrustic Framework or not). This is still a beta version for early-adopters.

Under the hood:

- Hubstore is built with Pyrustic Framework [1]

- data storage is done with Shared [2]

- autocomplete is done with Suggestion [3]

- GUI-compatible multithreading is done with Threadom [4]

- Hubstore consumes Python Wheels

- Hubstore uses Github's Release Asset feature [5]

- Apps can be built and released with Backstage [6]

- the dark theme is based on Cyberpunk-Theme [7]

- all views implement Viewable [8]

- Hubstore uses Kurl [9] to fetch resources from api.github.com

I would like to know what you think [10] of this project.

[1] https://github.com/pyrustic/pyrustic

[2] https://github.com/pyrustic/shared

[3] https://github.com/pyrustic/suggestion

[4] https://github.com/pyrustic/threadom

[5] https://github.blog/2013-07-02-release-your-software/

[6] https://github.com/pyrustic/backstage

[7] https://github.com/pyrustic/cyberpunk-theme

[8] https://github.com/pyrustic/viewable

[9] https://github.com/pyrustic/kurl

[10] http://sl4.org/crocker.html

I created Pyrustic Framework which uses Tkinter as GUI Toolkit, then I made a collection of graphical components like Table, Scrollbox, and more.

I think there are a lot of people who would like to add a GUI to their existing projects. But they don't want or don't have the time to or are afraid to learn how to use a GUI toolkit. By the way, I'm writing a tutorial to help them get interested in GUI dev. In the meantime, there is Dresscode !

Hi HN !

I'm Alex, a tech enthusiast. I'm excited to show you Exonote [1] and Exn [2], two projects I'm working on.

Years ago I crafted Litemark [3] and Codegame [4], two projects for creating codegames, which are programming puzzles with a backstory. A codegame is made up of levels stored in plain old text files as prose written with Litemark, a markup language inspired by Markdown [5]. The player would open the Codegame app to access the first level of the game, read the prose, and then submit Python code to solve the puzzle. The submitted code is evaluated by the Codegame app, then the return compared to the expected result previously defined by the author for this level. A correct answer would unlock the next level.

The idea behind Litemark and Codegame has evolved to embrace more possibilities, leading to the creation of Exonote and Exn which are no longer limited to "programming puzzles with a backstory".

Exonote is a Markdown-inspired markup language for writing rich, scriptable, and interactive notes. An eponymous Python package is available on PyPI to serve as the reference library. The lowercase word 'exonote' could be used as a common noun for a document written with this markup language.

This markup language makes it possible to add interactivity to notes by embedding GUI programs written with Tkinter [6]. Additionally, all or part of an exonote can be arbitrarily generated using custom Python scripts.

On top of Exonote, with Tkinter I built Exn, a lightweight Python desktop application to browse a dossier of exonotes. A dossier is a directory that contains plain old text files with the ".exn" extension (exonotes), assets (images for examples), and Python source code.

Exn's graphical user interface is a metaphor for a book whose pages are exonotes. Thus, the left and right arrow keys allow the reader to navigate from one page to another. The order of the pages is determined by an index file which can be generated automatically from the command line. This file contains the list of exonotes (ordered by their creation timestamp), their titles, and their tags.

Exn also has a built-in search engine that supports regular expressions [7], a Table of Contents (ToC) builder, a 'switcher' (Ctrl+Tab) and other cool stuff.

By expanding the original Litemark/Codegame idea, I unwittingly introduced a security risk. Suppose Bob doesn't have a personal website but has a GitHub repository that he uses as the public dossier for his exonotes. Alice is a tech savvy who knows what exonotes are and would love to explore the contents of the dossier with Exn. But she worries about the security risk of running untrusted code.

To solve this problem without going on an endless sandbox over-engineering journey, I added to Exn two command line options to browse a folder with low and high restriction. Low restriction mode blocks the execution of embedded programs while high restriction mode not only does the same but also blocks executable links (preventing the user from inadvertently running code by clicking on an executable link).

There is more to say about this (double) project, such as the Viewer API to manipulate the live representation of an exonote from a Python script.

This project is functional, still a work in progress with precarious documentation. I'm planning to add a nice plugin mechanism (at the moment it's only possible to change colors and font size of elements) so people can customize Exn (themes, et cetera) or add new functions.

A demo [8] is available to play around with and there is also a "Why use this project" section in the README which contains some interesting stuff not covered in this post.

I would like to know what you think [9] of Exonote and Exn. Your questions, criticisms, and suggestions are welcome !

Postscript: I found by serendipity that the third most popular post on HN (Mechanical Watch by Bartosz Ciechanowski) [10] looks like what I thought was a cool example of what can be done with Exonote/Exn. I had imagined a bike enthusiast working on a prototype on the weekends, taking notes, inserting relevant hyperlinks and images, building interactive 3D models of different parts of the bike and embedding them into the notes, et cetera. It would be a dossier of exonotes describing from scratch how the bike was built, with an astonishing level of detail. This person could keep this dossier private forever or publish it online. Once released, depending on the dossier's license, it can evolve much like open source software.

[1] https://github.com/pyrustic/exonote

[2] https://github.com/pyrustic/exn

[3] https://github.com/pyrustic/litemark

[4] https://github.com/pyrustic/codegame

[5] https://en.wikipedia.org/wiki/Markdown

[6] https://en.wikipedia.org/wiki/Tkinter

[7] https://en.wikipedia.org/wiki/Regular_expression

[8] https://github.com/pyrustic/exn#demo

[9] http://sl4.org/crocker.html

[10] https://news.ycombinator.com/item?id=31261533

[1] https://github.com/pyrustic/litemark

Hi HN !

I am excited to present the Codegame Platform to you.

Imagine being able to:

- write in a Markdown dialect (Litemark [1]) a text that gratifies the intellectual curiosity of the reader;

- gamify [2] the process by transforming each page into a level with the possibility of giving the reader a test to move from one level to another;

- don't worry about implementing what is said in the previous line: just write Markdown with your favorite text editor;

- without writing a single line of code that will be executed on the reader's computer, evaluate the solution that the user submits to a test;

- turn a reader into a player, a set of Markdown files into a serious game (a codegame);

- see a preview of what the future player will see with a command "preview" from a CLI;

- turn your project into a distribution package, publish it (thanks to GitHub Releases Assets) and monitor the number of downloads and stargazers simply with 3 commands ("build", "publish, "info remote") from a CLI;

- promote your project simply by sharing the URL of your repository or the "owner/repository" shortcut that users can simply paste into the search bar of a GUI (Codegame Platform);

- download the packaged project (the codegame) as a user and use it with the same application that allowed you to create, package and publish this same project ...

I imagined the above lines during this month and just posted the first implementation on Github.

First, I developed Litemark, a dialect of Markdown. I wanted something that would allow the creator of a codegame to insert images, links and also source code (read-only). It would be a plus if the creator is comfortable with the markup language. Markdown is a good candidate and on top of that a lot of people can write Markdown. I also wanted to be able to use my Pyrustic Framework which is not made for the web. And no question of using a HTML rendering engine ! I could have used Pandoc but it's also exciting to do projects from scratch. After Litemark, I wrote the library Codeval [3] which allows you to test code according to a given specification (input, output, maximum execution time). Then I developed Codegame Platform.

Having written Litemark from scratch allowed me to make some quick changes to meet the needs of the Codegame Platform. Example: The Litemark distribution package has a Viewer that can hide a given codeblock. This is the trick I use to hide the test specs from the player.

I think this project is suitable for:

- teaching programming, algorithms, data structures;

- teaching ethical hacking;

- building a well-articulated chain of puzzles with an exciting story behind it;

- automating coding interviews [4];

- fun, and more...

This is a work in progress. I would love to know what you think [4] about it, any suggestions, reviews, fixes, if you would have liked to use an app like this when you were new to programming, if you would like to create codegames and why, or if you would like to play codegames and why, or if you would like to implement the concept in another programming language or still with Python with another framework and why, if you know a similar project, etc ...

[1] https://github.com/pyrustic/litemark

[2] https://en.wikipedia.org/wiki/Serious_game

[3] https://github.com/pyrustic/codeval

[4] https://en.wikipedia.org/wiki/Coding_interview

[5] http://sl4.org/crocker.html