|
Post by Uncle Buddy on May 7, 2021 23:54:32 GMT -8
Treebard Version 0.0 was born at 3:34 p.m. on May 8, 2021, Manila time. In commemoration of this momentous occasion, I'll post real code as evidence that complex GUIs can be written in a fast-performing, relatively easy-to-learn coding medium. (Like Python/Tkinter/SQLite with fast and modern added.) Here is the code that means, to me, that the search for the solution to Python's slowness is not a waste of time. Let's hear it for genealogists can write their own code.# tut2_widgets.jl
using Dash, DashHtmlComponents, DashCoreComponents
# app = dash() app = dash(external_stylesheets = ["https://codepen.io/chriddyp/pen/bWLwgP.css"])
dropdown_options = [ Dict("label" => "New York City", "value" => "NYC"), Dict("label" => "Montreal", "value" => "MTL"), Dict("label" => "San Francisco", "value" => "SF"), ] app.layout = html_div(style = Dict("columnCount" => 2)) do html_label("Dropdown"), dcc_dropdown(options = dropdown_options, value = "MTL"), html_label("Multi-Select Dropdown"), dcc_dropdown( options = dropdown_options, value = ["MTL", "SF"], multi = true, ), html_label("Radio Items"), dcc_radioitems(options = dropdown_options, value = "MTL"), html_label("Checkboxes"), dcc_checklist(options = dropdown_options, value = ["MTL", "SF"]), html_label("Text Input"), dcc_input(value = "MTL", type = "text"), html_label("Slider"), dcc_slider( min = 0, max = 9, marks = Dict([i => (i == 1 ? "Label $(i)" : "$(i)") for i = 1:6]), value = 5, ) end
run_server(app, "0.0.0.0", 8000, debug = true) dash-julia.plotly.com/In two words: Julia, Dash, and SQLite. OK, so I can't count.
|
|
|
Post by Uncle Buddy on May 27, 2021 19:26:33 GMT -8
I've been splitting my time between Treebard GPS and Treebard v. 0.0.0.
Julia + Dash would work, but in working through the tutorials and looking at what would be involved, what came up for me is my distaste for layer upon layer of code. I like Dash, I think it could be learned pretty easily, but what's going on behind the scenes?
Dash takes my Julia code and writes Javascript.
Javascript is the language of the internet. The GUI or widget toolkit for the internet is HTML which is styled with CSS. To make the GUI/widgets/web app do something, Javascript is used. To write your code in Python or Julia instead of Javascript, you have to use a framework such as Dash or create your own framework. So instead of learning Javascript, you have to learn Dash. This is certainly doable. But if I become dependent on Dash, then all of Treebard is dependent on Dash. If Dash is abandoned or turns out to be incapable of doing something important, it's a big problem.
So I asked myself, why not write the whole app in Javascript? Part of the Treebard creed is "no dependencies". When I looked into this, I found that things had changed since 2015 when I first looked into writing a genieware web app.
At that time, it sounded like the normal way to write a web app was to use PHP for the backend. I couldn't stand to look at PHP code so I got interested in Python, fooled around with a framework called Web2Py, and gradually lost interest because my goals were too big and I had no experience in Python. In 2018 my interest was rekindled when I realized I could write a standalone Windows app in Python instead of a web app. My reasons for preferring a web app were set aside, but not forgotten.
Now in 2021 I've come full circle because the reasons for preferring a web app haven't gone away. Having users do their work online has nothing to do with it. It would just be a side benefit which others would probably appreciate more than I would. Personally I don't see the point of doing everything online. And part of the Treebard creed is portability instead of trying to be all things to all people. Treebard users will still use a graphics program to do complex graphics, a word processing program to do their word processing, and a web browser to connect to the internet. It would be nice if those who want to work online could do so, but that is probably someone else's task to make happen. My reasons for preferring a web app are unrelated to enabling users to work online.
How much time have I spend in the past three years working around Windows' insistence on barging in on my design? It's been a great learning experience to create the Toykinter widgets but in a browser, there is no Windows title bar or Windows menu bar to replace. You just make the page look the way you want.
More importantly, browsers run the same web app in Windows, Mac, and Linux. It's always in the back of my mind, when working on Treebard GPS in Python & Tkinter, that I have no idea what my code is going to do except in Windows. Tkinter is supposed to be cross-platform but I have no reason to suspect that this is true of all the code I've written. The creators of modern browsers, on the other hand, have taken it upon themselves to make their browsers cross-platform.
Tkinter's most famous feature is its supposed decrepitude. This has been meaningless to me as Treebard GPS has been a beginner's learning project for getting my feet wet. The fact that Tkinter still works and probably will for a long time to come will not stand up against the mobs who believe that Tkinter looks old and crusty and "not modern". I can shout about how Treebard is here to stay and takes no interest in current GUI fashion, but that will not have an effect on public opinion. Tkinter is being shouted down and removing it from Python is being discussed with major Python updates.
I have also spent huge chunks of time creating my own widgets such as a combobox and a scrollbar since the creators of Tkinter's ttk widgets--which were supposed to be modern at the time they were created--made them dependent on Windows themes.
So look around the internet, look at the most attractive websites... do they look like they are made from Tkinter widgets? Not a chance. Tkinter doesn't have to look old-fashioned or ugly, but let's just say that for HTML and CSS to look old-fashioned, you'd have to work at it. Unlike Tkinter, which is virtually abandoned as to its updating or development, HTML and CSS are not only enabling developers to follow fashion trends, but are in fact creating fashion trends. We see a lot of superfluous animation and special effects in websites today. This is being done because it's now easy to do. Treebard doesn't need fancy visual effects but it would be nice to easily make a button that doesn't look like it was plucked off the screen of a computer that weighs more than my dog Ringo and runs a 750 Mb hard drive.
The amount of support for HTML, CSS and Javascript is phenomenal. Anything you'd ever want to do has already been done and there's someone online teaching exactly how to do it. Tkinter is still well supported but only because some of its teachers aren't dead yet.
In case I forgot to mention it, the main reason for writing two versions of Treebard was that the GPS version could be started immediately in Python/Tkinter/SQLite whereas I needed time to look into how to rewrite Treebard GPS into a modern, fast-running app called Treebard version 0.0.0. I do tend to jump into things and gave up fighting that part of my character a long time ago. But accessing a huge genealogy database with Python was never my goal. I just wanted to get started on something and I'm glad I did.
Now in 2021 when I look into how to write a web app in Javascript, it's no longer all about PHP. The world has changed. The answer now is simple: NodeJS is a solid, well-supported project which allows you to write the backend in Javascript. No more two languages to write one app. And it's fast, so it can run large databases.
So I've found an 83-lesson tutorial which teaches how to write a NodeJS backend for a web app with no dependencies and no frameworks. This isn't how most people approach it, but I seem to be allergic to dependencies. When I looked into frameworks before, for each dependency there were six other dependencies. As someone who jumps into things, I prefer to fight one very large crocodile vs. a whole bunch of little ones.
So anyhow, the short version is that I'm taking NodeJS seriously and working through the research and tutorials in hopes that I can try to overcome the "impostor syndrome". That's the feeling which novice coders have when taking on projects that they currently have no idea how to complete. If I get to the end of this NodeJS tutorial even halfway knowing what to do, then I believe Treebard v. 0.0.0 could turn out to be a purely Javascript web app with no dependencies.
|
|
|
Post by Uncle Buddy on Jun 21, 2021 17:32:39 GMT -8
It looks like the 83-lesson tutorial mentioned above on Node.js is going to be unnecessary, although I will be doing a Node tutorial in my spare time just so I know what it is. The problem with moving the project beyond Python is that Python can use a SQLite database directly, whereas most other languages including JavaScript need a second language to deal with the back-end. The front-end is the GUI. Treebard v. 0 will use HTML and CSS for the front-end, and JavaScript is the obvious choice for manipulations within the GUI. Fortunately these days, NodeJS can be used to extend the ability of JavaScript to deal with the back-end also. The back-end is the database, the file system, the computer itself. Without Node, JavaScript couldn't do these things. This is why I chose Python to begin with, back when Node was just a baby, because the logical alternative was PHP and MySQL, but Python and SQLite was a more pleasant way to get started and figure out what writing an application was all about. The question is this: do I learn to write my own back-end server and handle the Node myself without frameworks and dependencies? Actually since I'll probably only be alive long enough to write a few applications, why would I bother? Well philosophically I don't like dependencies and I don't want Treebard to be hard to maintain. The more dependencies Treebard has, the harder it will be to maintain. Breaking (non-backwards-compatible) changes are made in the dependencies and that will break Treebard. I did look into using React since it's so popular, but it soon became obvious that Vue.js would do the same stuff but be easier to learn and use. I was all set to use it when I finally figured out, kinda late, that Vue and React are front-end frameworks. That's not what I was looking for. I want to write my own JavaScript. Then I learned that the 83-lesson tutorial on Node that I'd already started (or the company that created it) had a bad reputation. Not a game-killer in itself; there are plenty of ways to learn Node. But in the meantime this application Electron placed itself squarely in my sights once again. In my search for a batteries-included replacement for Python, Electron came up over and over, but that was before I'd realized that I wanted to write Treebard v. 0 in JavaScript. I finally looked into Electron and I'm glad I did. Electron was created by Github, I guess because they wanted to make their very own code editor, so they created Electron and used it to create Atom. Atom is now owned by Microsoft, but Electron is an open-source project and has been used for a lot of big and popular projects such as Atom, VS Code, Slack, Netflix, and many others. Electron is just what I was looking for. It incorporates the abilities of Chrome and Node to handle the back-end. The gist of it is that with Electron, I can write a website-like application but it will work like a browser, not in a browser. In other words, it's a stand-alone desktop app with its own built-in browser as a base of operations, but it's not a web app that you use in your Firefox or Opera or Chrome browser. This is exactly what I wanted. Because it's written purely in JavaScript, HTML and CSS, and because it handles the back-end as well as the front-end, Electron is the perfect replacement for Python, in a case like ours, where we want to develop an app using one program to do everything. And that is the key to enabling any old genealogist to write his own genieware. Python spoiled me by making it possible to write a complete application without any dependencies (except Pillow which was needed for handling graphics). Electron comes pretty close to being as easy to use as that. Unlike front-end frameworks, it doesn't write my JavaScript for me. It's not that kind of framework so it's not like learning a new language. Its purpose is to marry the front-end to the back-end so I can get to work writing my application. I've been testing it out pretty thoroughly and I love it. EDIT: I've removed some tutorial links and replaced them with these. The first is for the offical Electron docs which are quite useful, easy to understand, up-to-date, and downright necessary. You might want to try a few tutorials first so you know what kind of problems these docs are going to help you avoid. The main problem you'll encounter with tutorials that are even a few years old is that most of them are out-of-date. So the second link below is the only one I've found that isn't out-of-date. Regarding the broken tutorials. I've gotten most of them to work but I've taken my time in actually concentrating on the official Electron docs. Which makes me appreciate them all that much more. Be aware that the simple fixes widely suggested in a variety of places online might force the app to work against the better judgment of today's (2021) built-in Electron defaults. So I can't really suggest any other tutorials except these two, except to say that trying some broken tutorials should motivate you to actually read the docs, do the official tutorial, and get a basic foundation in what's really going on. Also, the current version of Electron works right with SQLite so you can ignore the tutorials that show you how to "rebuild" Electron to work with SQLite. www.electronjs.org/docswww.youtube.com/watch?v=I1_aeciYALI&list=PL_2VhOvlMk4X_kQF7EfzNxRNnYrRlfIG9
|
|
|
Post by Uncle Buddy on Jul 19, 2021 4:56:33 GMT -8
Here's a link to my Github repos. There are four of them now. github.com/ProfessorUdGuruCwrwgl: I took a few weeks off to start a project in Electron which aims to reproduce the most elementary functionalities of a code editor. Toykinter: I teased the custom widgets out of the Treebard GPS project and created a demo app for them. Treebard v. 0.0.0: where I plan to be putting most of my energy soon. Treebard GPS: the three years I've spent working in Python/Tkinter/SQLite to demonstrate functionalities of a working genealogy database entry program. This experience will be invaluable as I set off to reproduce those same functionalities in programming languages which are capable of running large databases efficiently. I plan to finish the ongoing refactoring and get the events table up to speed before I transfer over to Treebard 0.0.0.
|
|
|
Post by Uncle Buddy on Jun 7, 2022 19:19:15 GMT -8
Planning NOT to use Electron since it's based on googleware Chromium. Gotta avoid contributing to the MONOCULTURE that is the current state of the internet and getting worse. www.youtube.com/watch?v=7xvtz3pN_SwMy current feeling is that Treebard GPS is where it's at for me. Python is getting faster, not slower. If Gramps can get away with using Python, then why can't I? At my age I have to curtail my ambitions, shoot for achievable goals, and as I've said many times, let Treebard v. 0.0.0 be someone else's problem.
|
|