alexrustic

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

Hi, thank you for your comment. It's a good idea, I'll add this section.

I was convinced that the fact that the name of the project is a direct reference to a well-known programming technique (hooking), negates the need to explain what I thought was obvious.

Thanks for drawing my attention to it. I will also explain why the library makes use of decoration (in the previous iteration it didn't, so yes there is a need to explain the motivation).

Hi HN !

I'm Alex, a tech enthusiast who likes to build stuff from scratch.

The more time we spend doing something, the more comfortable we feel and the less dependent we are on an external learning resource. Since I spend a lot of time in a text editor, I can spend days writing Python code without checking an online resource. On the other hand, since I spend so little time in the command-line shell, I often found myself looking online for commands to build and publish Python packages.

Considering the text editor and files as the software development stage [1], the backstage [2] would be the tasks performed in the background to manage the project. These tasks would relate to the different stages of the project lifecycle (build, test, publish, et cetera).

I thought it would be both cool and useful to have a tool that would serve as the backstage entry point for any of my projects. This tool would be called 'Backstage' [3] and would allow me to quickly discover the available tasks (including their descriptions) for a given project. Tasks would be defined in a file named 'backstage.tasks' (preferably located at the root of the target project) and would consist of collections of commands to be executed sequentially. To execute a task, I would just have to type in the command line its name possibly followed by arguments. For example: 'backstage build' or 'backstage release 1.0'.

INI File [4] or TOML would be the perfect file format candidate for the 'backstage.tasks' file. But unfortunately they are designed to handle sections with key-value pairs when I need a simple way to define sequences of commands aligned under their respective task name. So I built Jesth (Just Extract Sections Then Hack) [5], a new file format that looks like INI file but lets me decide how to interpret the body of a given section.

After a few days of programming, I successfully built the first iteration of Backstage and placed a 'backstage.tasks' file in my projects directory. From that day on, releasing a new version of a project was stress-free.

This first iteration served its purpose as I expected until one day I forgot to enable internet connection while using Backstage to publish a new version of a project. Project documentation was generated successfully, version management, build and 'Git Commit' were done automatically, but 'Git Push' failed and the task was aborted. This specific task was supposed to run without interruption because each time it is executed, unique and timestamped events occur. Enabling internet and re-running this task would update the target project version and create a new superfluous version.

From that day I understood that I had to improve the syntax of the 'backstage.tasks' file to avoid this kind of annoying situations in the future. The most obvious solution was to introduce variables and control flow. I took the time to anticipate what I will need in the future. Then I decided to add stuff like data types, namespaces, multithreading, test support, builtin commands, et cetera. Eventually, the syntax of the 'backstage.tasks' file evolved into an eponymous (Backstage) three-speed scripting language.

The three-speed scripting language concept is inspired from the three forward gear ratios of early automobiles transmission system [6].

In first gear, a `backstage.tasks` file is intended to store a list of tasks related to a specific project, each task exposing a list of commands or subtasks to be executed. Here, a command represents a process or pipeline of processes to be spawned. Environment variables can be used in commands via variable interpolation [7]. No other logic is involved.

In second gear, the `backstage.tasks` file not only stores the tasks like in first gear, but here logic intervenes, variables are defined, control flow is used, built-in commands are called, et cetera. Basically, in second gear, Backstage unleashes its power and allows the programmer to anticipate problems, make sophisticated combinations of subtasks, in short to write a real script to automate things.

In third gear, in addition with whatever can be done with previous gears, the programmer can directly from the `backstage.tasks` file, call Python functions with arguments and get the return ! Thanks to this third gear, any too complex or overly verbose calculation can be written in Python and called from Backstage. This functionality alone proves that Backstage is all about making the programmer's life better, not pretending to replace existing mature solutions that actually work.

These three speeds make Backstage versatile enough to act either as a simple task runner or as a scripting language with a built-in bridge to the powerful Python ecosystem. Not only are tasks defined in 'backstage.tasks', but their documentation and tests can also be embedded there. The command line interface allows the user to discover available tasks, read their documentation, use a glob-like [8] syntax to search for a task by its name or by a keyword that is part of the documentation of the task.

I use Backstage a lot and want it to stay cross-platform and relevant long term. So, as said before, Backstage has data types, namespaces, multithreading, test support, built-in commands but also regular expression support, timestamp and date/time conversions, support for here document [9] directly in 'backstage.tasks' file, automatic normalization of path strings, intuitive variable persistence mechanism, et cetera.

Backstage allows the programmer to spawn and pipe processes, capture their output, push data into a process's input, redirect STDOUT and STDERR. File and directory manipulation is intuitive, so one can create, move or copy files or directories with built-in commands, browse an arbitrary directory and access properties such as creation time or size, consume the contents of a large file line by line or in bulk.

There is more to say, it's a work in progress and I'm excited to share this project with you. Backstage is available on PyPI and you can start playing [10] with it from now. You are welcome to share what you think about this project.

[1] https://en.wikipedia.org/wiki/Stage_(theatre)

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

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

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

[5] https://github.com/pyrustic/jesth

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

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

[8] https://en.wikipedia.org/wiki/Glob_(programming)

[9] https://en.wikipedia.org/wiki/Here_document

[10] https://github.com/pyrustic/backstage#demo

Hi HN !

I'm Alex, a tech enthusiast who likes to build stuff from scratch. Often my programs have data to store or a configuration file to read and/or edit. Therefore, I design relational databases [1] and write SQL queries to manage complex data with relationships, and for other needs, I used to do unmaintainable hacks (custom file formats) with plain old files. But that was before I discovered Pickle [2], the Python data serialization module. A simple way to store a representation of memory-living data collections on local disk.

Therefore, Pickle became my favorite way to store data, until one day I needed to exchange data with another program written in another language. Pickle is Python-specific by the way. Due to this embarrassing situation, I needed to find a way to "replace" Pickle. The new method should be language-agnostic.

CSV [3], INI file [4] and JSON [5] respectively entered the room.

As an open standard file format with a formal specification, JSON sounds very serious. The Internet speaks in JSON [6]. Therefore, I adopted JSON. So at this point, for my personal projects, I had SQLite for interaction with relational databases, files to store binary data, and JSON for everything else. But one thing is missing: a single tool to unify these APIs under the same umbrella, and so with a single installation I could do data persistence and exchange wherever I want.

Instead of one, for aesthetic reasons, I built two libraries: Litedao for SQL related stuff and Shared for data collections (dict [7], set, list) and binary data. Litedao was designed to use SQLite and Shared to use JSON and files. I had from my point of view a smooth developer experience when it came to the data of my personal programs. But since I need SQL less than JSON, the Litedao library caught my attention less. Therefore, more bugs have been fixed in Shared and more functionalities have been added.

Due to this situation, I decided to integrate Litedao into Shared so that it could get more attention from me. It worked ! Therefore, Shared becomes a lightweight library for data exchange and persistence that smoothly handles collections (dict, list, set), binary data, and SQL queries. For aesthetic and functional reasons, Shared is a triptych whose classes share similar interfaces: Document, Dossier, and Database. The Document class allows individual access to files that are likely to be edited manually by a human, example: a configuration file. The Dossier class stores collections and binary data in a dossier without bothering the developer about how the data is actually saved. The Database class allows interaction with SQLite databases.

Among other functionalities, there is a command-line interface for exchanging data between programs, Autosave mode, Readonly mode, and Temporary Data mode.

My project, still in Beta, is written in Python and I'm still working on it while using it intensively. Today, I discovered that Shared entered the top 5000 most downloaded packages from PyPI [8][9][10] in the last 30 days. Thanks for reading, let me know if you have any feedback and feel free to ask questions.

[1] https://www3.ntu.edu.sg/home/ehchua/programming/sql/Relation...

[2] https://docs.python.org/3/library/pickle.html

[3] https://en.wikipedia.org/wiki/Comma-separated_values

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

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

[6] https://stackoverflow.blog/2022/06/02/a-beginners-guide-to-j...

[7] https://docs.python.org/3/tutorial/datastructures.html#dicti...

[8] https://pypi.org/

[9] https://hugovk.github.io/top-pypi-packages/

[10] https://zenodo.org/record/6786416

Hi HN !

Before discovering JSON, I worked on projects where I had to design relational databases [1] and write SQL queries. I understood the difference between a relational database and a file format, but couldn't resist the temptation to adopt JSON to store data locally.

Ever since I adopted JSON to store data locally, I wanted a class with an intuitive interface to play with JSON files. Eventually, the class evolved into a library.

I had to make a graphical SQL editor to test a GUI framework, so I created the LiteDao package (Lite Data Access object) which offers an intuitive interface to connect to a database with SQLite. The project worked as I wanted it to.

So, I had two different packages to play with data. I wanted to unify these two packages into a single class. But I failed to do so.

I came back to the challenge, and this time I had the idea of a single package with three classes with almost same intuitive interface that meet three needs: the need to expose a configuration file so that the user can modify values, the need to store collections and binary data without worrying about how they are actually saved, and the need to work with a relational database. These classes are respectively named Document, Dossier, and Database.

I managed to implement it in Python and added a command line interface [2] that allows different applications to exchange collections and binary data.

I would like to know what you think [3] of this project which is still in beta and which I already use in several other projects which are also in beta.

[1] https://www3.ntu.edu.sg/home/ehchua/programming/sql/Relation...

[2] https://github.com/pyrustic/shared#command-line-interface

[3] https://news.ycombinator.com/item?id=12886522 (Crocker's rules)

See also:

VPN by Google One comes to iOS

https://news.ycombinator.com/item?id=30165696

See also Los Angeles Times article about this:

How a 91% rate sparked the golden age of tax avoidance in 1950s Hollywood

https://www.latimes.com/business/la-fi-nocera-tax-avoidance-...

Hi HN !

I am Alex, the author of Pyrustic, a collection of lightweight Python projects that share the same policy.

Two functions are enough to know to make a command line application: the function to display text and the function to retrieve the input entered by the user. To make a GUI application, we need to know what widgets to use and the settings to configure them, think about the user experience, create the layout and, most importantly, write well organized code. GUI programming is difficult [1], especially when we do not have a lot of time available and therefore when we have an idea of an application project with GUI, we will tend to postpone [2] the development, sometimes to abandon the project under development because it gets complicated, or instead just create a command line application.

I am not opposing the command line interface to the GUI. There are a few command line programs that I like best in this form. I also like apps that have both a GUI and a command line interface.

I've been working on a framework called TkF for several months now, to make Python GUI applications. The framework uses Tkinter (a thin object-oriented layer on top of Tcl/Tk included in the Python Standard Library) and it just works. But it still takes me long time to create a GUI. So I thought about creating a GUI builder based on TkF. I don't like using a GUI builder but that sounds like a nice challenge: to create a simple to use GUI builder that I will love to use myself !

After several days of thinking, my thoughts drifted away from the Python philosophy: simple is better than complex. I finally gave up on the idea of the GUI builder and decided to create something else that could allow me to create a GUI, as fast as a GUI builder without using the mouse. I made Dresscode, a framework built on TkF.

With Dresscode, the main views of the GUI are Pages and widgets (graphical Components) are positioned on pages with a simple layout mechanism managed with two booleans: new_row and new_col. To increase productivity, I implemented this simple idea: a navigation bar automatically populated with references to the Pages (example: Home, About, et cetera) of the application.

So far, everything was fine until a few weeks ago. I was editing the READMEs of the projects TkF and Dresscode. The README of the TkF project has a nice cover image [3] which is a screenshot of a demo made with TkF. I wanted such a nice image as cover for the Dresscode README. But this demo cannot be done as it 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 has a limited flexibility in order to gain in productivity.

Again a new challenge: I decided to think about how 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 place a graphical component on a page. But it's not enough. Some graphical components may need to be enlarged to fit the width of the page or the height or both. For that, I simply borrowed from Tcl/Tk the main parameters of the Pack geometry manager: "anchor", "expand", "fill", and "side".

Thanks to serendipity [4], I had other interesting ideas and I thought that all of this might form a concept that can be implemented in different programming languages. I named the concept GASP: GUI As Stapled Pages. Here, the navigation bar represents the staple. I decided to abandon Dresscode and to create a new project from scratch still in Python: Gaspium [5], the reference framework to build GASP apps.

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 flexible layout mechanism is controlled with five parameters ("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.

As a developer, the GASP concept introduced a new GUI programming metaphor that improved my productivity [6][7]. As an application user familiar with monolithic applications, I see a GASP application as a collection of useful programs, each with a graphical user interface that can be arbitrarily invoked from the command line.

There is the heavily commented source code of a small demo [8] on the Gaspium README. This demo is a GASP application built with Gaspium. You can copy paste and run the demo source code as is (you need to "pip install gaspium" first).

It is a pleasure to share with the HN community this command-line-friendly GUI programming metaphor and its reference implementation. Please post [9] any feedback, ideas, questions or relevant experience, I'd love to hear it !

Thank you for your attention !

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

[2] https://news.ycombinator.com/item?id=23537317 (Procrastination is driven by our desire to avoid difficult emotions, says expert)

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

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

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

[6] https://blog.codinghorror.com/the-ultimate-dogfooding-story/

[7] https://news.ycombinator.com/item?id=453721 (The ultimate dogfooding story)

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

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

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

Hi HN !

I am happy to show you the new version of Hubstore.

Hubstore is available on PyPI and is not intended to be an alternative to PyPI. I think Hubstore lends itself well to situations where, for example, you want to be able to name your project whatever you want without worrying about name collisions: for example a programming course where the name of the project is the same for each student who must build it and publish it on the same platform.

Hubstore not only allows you to install applications, but also to run them from the same interface in order to be able to intercept crashes and offer to report them (Github Issues).

I wanted Hubstore to offer a default list of apps that can be updated with new app recommendations. But instead, I implemented the Promoted feature which allows each developer to promote other apps. So as a user, when you download an application X from developer Y whom you trust, this developer Y can present to you other apps A, B, C and D which come either from him or from other developers in who he trusts. Let's not be naive, the goal is not to create a perfect chain of trust ! I'm just curious to know how it will turn out.

Regarding the promotion algorithm, for the moment it is almost non-existent: Hubstore just displays a list of all the promoted applications (avoiding duplicates). For the next release, I am thinking of an algorithm which: - introduces randomness; - limits to 3 or 4 the number of apps in the Promotion list (user can always click on the More button to refresh the window); - 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

See also CNBC article about this:

Following complaints, Microsoft will make Windows 11 compatible with more PC chips

https://www.cnbc.com/2021/08/27/microsoft-windows-11-will-be...

See also TechCrunch article about this:

US government watchdog rejects Blue Origin’s protest over lunar lander contract

https://techcrunch.com/2021/07/30/government-watchdog-reject...

Related thread: https://news.ycombinator.com/item?id=27960672

Pyrrha website: https://pyrrha-platform.org/

See also CNBC article about this:

Bezos offers to cover $2 billion in NASA costs in exchange for astronaut lunar lander contract

https://www.cnbc.com/2021/07/26/bezos-offers-to-cover-2-bill...

See also Wired article about this:

A New Tool Shows How Google Results Vary Around the World

https://www.wired.com/story/tool-shows-google-results-vary-w...

See also:

Everyone's Airpods Will Die; Not Possible to Swap (2019)

https://news.ycombinator.com/item?id=21194977

See also Star News Online article about this:

Former coworker of 'brilliant, respected' Wilmington engineer speaks out about lawsuit

https://www.starnewsonline.com/story/news/2021/06/15/wilming...

See also VentureBeat article about this:

Battlefield 2042 to debut on October 22 on consoles and PC

https://venturebeat.com/2021/06/09/battlefield-2042-to-debut...

Hi HN !

A few days ago I wrote Shared [1] a library to store, expose, read and edit data collections. Data collections are stored on the hard drive in separate files. I needed a mechanism to know when the content of a data collection has changed, so only the updated data collection will be stored. Thus came to me the idea of writing Probed.

This is a work in progress, I will write some documentation and tests later. Tell me what you think [2].

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

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

See also The New York Times article about this:

Train Workers’ Covid Bonus Offer Turns Out to Be a Phishing Test

https://www.nytimes.com/2021/05/13/world/europe/phishing-tes...

See also CNBC article about this:

NTSB releases preliminary report on fatal Tesla crash in Spring, Texas

https://www.cnbc.com/2021/05/10/ntsb-releases-preliminary-re...

See also CNBC article about this:

Uber, Lyft, DoorDash stocks fall sharply after U.S. Labor secretary says gig workers should be classified as employees

https://www.cnbc.com/2021/04/29/uber-lyft-doordash-stocks-fa...

Thanks for pointing this out.

I just noticed that these links [1][2] point to the same article.

[1] https://www.buzzfeednews.com/article/ryanmac/full-facebook-s...

[2] https://www.buzzfeednews.com/ryanmac/full-facebook-stop-the-...

Thank you ! A quick hint from HN is valuable !

I definitely need to quickly build a website to summarize the project's ecosystem. The documentation was more messy months ago. I discovered a framework for writing better documentation [1] which made things less messy.

> We certainly need a practical way to make Python desktop GUI apps

You can take a look at Dresscode [2]. This is my latest project [3]. It aims to quickly create a desktop application without prior knowledge of Tkinter. Also, it's suitable to existing codebases (no need to alter your existing codebase). If Pyrustic Framework is C, Dresscode would be Python !

[1] https://news.ycombinator.com/item?id=26002656

[2] https://github.com/pyrustic/dresscode#readme

[3] https://news.ycombinator.com/item?id=26731674

Thanks for the feedback!

A few months ago, Hubstore [1] was not compatible with existing Python distribution packages. Today, Pyrustic Manager produces Wheels, Hubstore consumes Wheels and therefore is de facto compatible with many existing applications.

Feedback helps me improve the project. So, I'm glad to read your review !

I just discovered Thonny, I'm going to take a look at it.

Regarding the black color, personally that doesn't make it harder to use [2]. This is a dark theme that I named Cyberpunk Theme. The goal is not to show that black makes a GUI looks beautiful, but to promote the theme/style mechanism I designed to custom the look. I promote a separation between the theme/style and the layout of widgets a bit like HTML/CSS but without creating a another yet DSL. The theme was actually incorporated into the Pyrustic codebase. I removed it weeks ago. Now it is a distribution package available on PyPI. So tomorrow, someone can if they want to do a light theme that they'll call Sunny or Snowflake.

I intend to make a website to show a summary of all the Pyrustic sub-projects, because for the moment you have to read a lot of lines before understanding the project. Also, GUI/aesthetics is only part of the project. For example there is pyrustic.threadom, a library to perform GUI-Toolkit-compatible multithreading easily.

Thanks again for the feedback !

[1] https://news.ycombinator.com/item?id=26008018

[2] https://news.ycombinator.com/item?id=18537458

Hi HN !

A few days ago, I showcased Dresscode [1]: dress up your code with a beautiful GUI. Dresscode is a shortcut for creating a GUI, you don't even have to know how to use the GUI toolkit under the hood.

I think it is worth writing a tutorial for GUI dev while continuing to promote Dresscode [2]. It is also a pleasure to try to grab the reader's attention and keep it until the end of the tutorial.

If you are not into GUI development, let us know [3] if you were (partially) convinced by this short tutorial.

[1] https://news.ycombinator.com/item?id=26731674

[2] https://github.com/pyrustic/dresscode#readme

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

Thanks you. Plenty more to come ! It is a great pleasure to make stuff and share. I will write a tutorial soon to show how to create a custom theme for the GUI.

See also ZDNet article about this:

Critical Zoom vulnerability triggers remote code execution without user input

https://www.zdnet.com/article/critical-zoom-vulnerability-tr...

Hi HN !

I created the Pyrustic framework [1][2] and built a few applications with it, including Hubstore [3] to connect users to applications.

I wondered if it was possible to make GUI dev even easier. I thought of a GUI builder, with drag and drop and everything that surrounds it. My current idea is complex to build, I hate using GUI builder, so the one I am going to create should be the one I will love to use. So I tried to create an intermediate product... Something between a GUI builder and a raw framework beast: Dresscode !

I just finished the project (thanks Kolourpaint and Gifski). I started it last Sunday. I am therefore only addressing early adopters for the moment.

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 [4] to help them get interested in GUI dev. In the meantime, there is Dresscode !

Dresscode allows you to easily add a GUI to your project (next one or existing one) without altering the existing code base. And no need to learn how to use a GUI toolkit !

I hope this project will be useful to a lot of people and that it will make some of them want to use the Pyrustic framework to have full control over the GUI. Pyrustic could be like C, and Dresscode could be like Python :)

Your feedback is highly appreciated! [5]

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

[2] https://news.ycombinator.com/item?id=23930255

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

[4] https://github.com/pyrustic/pyrustic/#tutorial

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

See also TechCrunch article about this:

Facebook confirms ‘test’ of Venmo-like QR codes for person-to-person payments in U.S.

https://techcrunch.com/2021/04/06/facebook-confirms-test-of-...