Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
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)
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)
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)