General myappmaker discussion #1
Replies: 10 comments 16 replies
-
|
An excellent beginning! I am curious what other folks, and in particular what other programs in this space folks have considered/tried using and what reference texts folks would find helpful in understanding this sort of thing. Programs I have tried:
Programs which pretty regularly come up in such discussions:
|
Beta Was this translation helpful? Give feedback.
-
|
After thinking on this, here are some (possibly random) thoughts and observations. First question/concern --- what is the expressibility of a person drawing with a stylus (I would like to think that a reasonable subset of folks using this drawing-first tool will use styluses)? I think one could reasonably expect folks to be able to draw:
Other shapes (rhombus, parallelogram, regular polygons such as pentagon, hexagon, #-pointed stars, &c.) seem a bit iffy, and the above seems to match the capabilities of drawing programs. The next consideration is usage/pointer modes --- a pretty standard division for drawing programs:
Since this tool will have at least two modes: drawing/programming, there may be a need for an additional usage/pointer mode where code/programming elements may be added/interacted with. Drawing tools have a number of fairly standard modifier keys (note that each key may have a different function based on the active mode):
(that is probably not an exhaustive list, and is certainly subject to discussion and modification) A quick look at a couple of diagramming programming templates isn't yielding a consensus on mapping shapes to usage --- this probably merits further research/consideration. |
Beta Was this translation helpful? Give feedback.
-
|
A quick initial thought on mapping drawing to programming and possible interface elements/considerations: drawing a rectangle creates a text field, while a square creates a number field --- these should create matching variables in the central variable area drawing an oval creates a button drawing a circle in front of small/detail drawings (writing) or set text creates a radio button (presumably there will be more as a list) drawing a pair of triangles up/down, left/right creates a paired set of "nudges/spinners" which may be used for incrementing/decrementing a value in the adjacent field which leaves just line (ornamentation/separators/connectors?) and diamond (status indicator?)
|
Beta Was this translation helpful? Give feedback.
-
|
Hello, William! First of all, thank you for all the fixes, stylistic improvements and extra clarifications provided via your pull requests. I already read each one of them as well as each line changed and approve of everything (I'll merge them all in a second). Also thank your for the extra clarifications and pointers from these previous comments on this discussion post. Keep'em coming! They are so useful and instructional that I intend to add them to the chapter of the SDD on myappmaker's usage. Here are my replies to specific points/questions from those comments.
Great observations. The fact that you are not thoughtlessly listing the possible shapes but is also taking into consideration the common choices of other drawing programs and also the expressibility of people with styluses, that is, how easy/convenient it is for people to perform the action of drawing such shapes/paths repeatedly shows that you gave all this careful consideration. In addition to determining the most appropriate shapes to use, we must also take into account, as you already pointed out yourself since the beginning in our earlier discussions via email, accessibility. That is, we must also think of measures to facilitate drawing those shapes/paths. Styluses are indeed very useful tools and since they are so immediately comparable to the act of drawing interfaces on graph paper, it seems more than worthy to build myappmaker with extra care for stylus support and prominent usage. Getting back to the question per se, I think we must actually test all of the shapes with actual users as soon as development begins. That's because it isn't possible to determine that based solely on our own experience. There's may also be more dimensions to the problem. For instance, even if some specific shape can be used efficiently by most people, the specific output of that shape (a text field, a number field or other field), may not make sense or be as intuitive to them as we originally thought. I think only testing can give us the answers we need here. On a side note, the QGraphics framework from Qt, which will be used to draw the interface of the app being created and those shapes as well, is very suitable for drawing smooth shapes/path. It is also very efficient too. So, in terms of performance it seems we won't have any problems.
Edition using multiple modes is something I have experience with, not only from drawing programs like Inkscape, but also from the very text editor I use for software development (VIM). Being able to use multiple modes is very powerful, as it give us even more options for the available controls/actions like keys on the keyboard and actions like clicks with the mouse or a sweep with the stylus. Again, this is something for which testing with people is better. Regardless of that, though, all the points you made are very good starting points. A challenge I expect here is that of clearly conveying to people the current mode they're in. I say that because it is seems to be a common problem with software with edition with multiple modes. Multiple modes seems to be more than worth such problems/costs, though, as despite that many software projects still employ them and their userbase still use them. This might mean the main problems lie in the initial learning curve, something that we must be aware of when implementing such modes to ensure people will have the smoothest experience learning and using them.
Thanks for the pointers on the possibilities. Indeed, consensus is something that we won't find here, but I agree that proper research must be done in order to define the best configuration. In addition to that, I think testing with real users will also gives insight onto such configurations. Regardless of all that, though, even if we achieve an ideal configuration (if that is even possible), we must also allow users to change the keys as they see fit, so they can adapt the tool to their mental model/preferred workflow. Even so, being careful with the definition of the default configuration is still crucial, since non-technical people are the target users of our tool and, by definition, we must not expect these users to be eager to play with such configurations. Or at least, that's my assumption. Reconfiguring keys is not something I regard as fun either, unless of course it is for the sake of significant gains.
Again, excellent starting points. I have to give these additional thought. Also, again, user testing would be needed. However, I suspect these associations, that is, between shapes and widgets, are things that depend on the user mental model and several associated variables (like the user's perception of widgets and their shapes, etc.). Because of that, don't you think it would be useful to allow users to pick such associations as they see fit? Of course, just like the keys, we'd need a default configuration. However, allowing people to redefine such associations as they want would be not only convenient to them, but also useful when it comes to define associations between custom shapes and other new/custom widgets. For instance, a user could define that drawing a As for the line and diamond shape, I'd also have to give it some thought before I could come up with a good idea for their usage, although your suggestions are not bad (specially for the association between lines and separators, since I couldn't think of a good association for the diamond shape at the moment). Again, thank you for all the info. All the points made and questions are very useful and important considerations that I intend to add to the SDD. Please, post as much as you'd like and as often as you'd like as well, even when it is about seemingly trivial stuff, since these are crucial for helping us form a clear picture of the application, its design and usage. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, the association of Just took a quick look at the usage of AI in the Amazon Scribble. Very interesting. Something to have in mind, although, as I said in the design document, it is too soon to think of integrating AI into the apps of the Indie Python project. The use of the technology in creative fields/tasks didn't mature yet and fail at providing real, long-term value. For instance, even the use by big companies to generate video ads is met with criticism and regarded as bad taste. I think for now AI is best employed in non-creative fields that employ it for heavy calculations/model generation, etc. Have you heard of its applications for protein synthesis and making new drugs/medicine? Astounding. Now, of course, we can have text/drawing recognition, since this is a different matter altogether and doesn't require the usage of AI. It is something that seems genuinely useful and game-changing. Being able to define widgets from drawings is truly genius and something that'll certainly speed up app development. Thank you for the links as well, excellent references for further research and inspiration. I actually played a lot with the examples from the Crosscut tool (never seen anything remotely close). I'll make sure to include them as well in the design document, perhaps with a few extra words on insights related to myappmaker. Probably under a "Other implementations" section, as you suggested (it is actually a common section in design document, because analyzing other tools is often useful when designing one's own tool). I'll include this along with the instructions/recommendations from your previous messages above as well (the recommendations regarding drawing/user actions/keys used, etc., which will probably be included in the chapter on the usage of myappmaker), as I already said. However, I'll probably do that after I'm back from my 15-days vacation that will start tomorrow. Even during my vacation, though, don't hesitate to keep posting/sharing/discussing. If something urgent pops up, I'll reply right away, and if not, I'll get back to you on what's posted as soon as I'm back. Before officially starting my vacation tomorrow, I'll also post online in all Indie Python channels and other related channels (Discord, reddit, Bluesky, Twitter/X, Mastodon/Fosstodon, YouTube) about the announcement I posted Friday morning mentioning myappmaker and the other plans for the project in 2025 and after. Didn't do it yet because I had a busy weekend and posting stuff at the beginning of the week seems to reach more people (since on weekends people spend more time outside and away from the computer), which is why I wanted to wait a bit to officially announce things on Monday. |
Beta Was this translation helpful? Give feedback.
-
|
Another interesting environment is the "Glamorous Toolkit": https://news.ycombinator.com/item?id=38153318 which is a Smalltalk (Pharo) IDE which has support for something like to a Jupyter notebook. The discussion of that does raise some interesting points:
At this time, I will often just use https://www.blockscad3d.com/editor/ to knock out a design (or element of a design), and sometimes, it seems to me that using a screengrab would be a workable documentation of that element which kind of makes me wonder if the XML which it writes out for a project could be used as a format to create a vector expression of the Blockly Code. So, to continue thinking out loud, things which I think would be worth investigating are:
So maybe another way to describe this would be something like "Jupyter Notebook for SVG with widgets"? I am struck again by pyspread allowing a cell to contain pretty much anything, and especially SVG content. |
Beta Was this translation helpful? Give feedback.
-
Checked their page this week and also watched a large portion of a video presenting the project. I intend to give a deeper look later in other related resources. The environment does have quite introspective capabilities. The closest thing I ever did was the automated system testing for Nodezator. If you didn't try it already, just launch Nodezator then press Shift+Ctrl+F8 (or, alternatively, click the Run all tests at maximum speed option under Gui automation > System testing on the menubar). The automated system testing in Nodezator simply resets the app to an earlier state then replays a series of inputs. This means I can simulate various different states for the app. It is quite primitive in comparison with the Glamorous Toolkit, of course, but the principles are there. That is, if you have control of each state/element, then you can test a system in any context you'd like, which is pretty much what it is shown in the materials and videos explaining the toolkit (although I'm yet to take a deeper look on them). Frankly, it doesn't seem much different than the level of control provided by modern game engines. You see, one of the reasons I promote game development in the Indie Python project and have an ongoing game project (Bionic Blue) is because game development drives a lot of innovation given how much systems they have to balance (for instance, video game developers are well-suited for robotics). I didn't specifically foresee that this kind of introspection was a requirement of myappmaker, but since making an application per se requires fine control of each element I was kind expecting a similar level of control/introspection, which is why I mentioned in myappmaker's SDD that I'd take much inspiration from game engines:
Just like we want to employ visual interfaces for app making, game engines have been doing that for quite some time already for game making. Although I'm confident in my abilities to make games (Bionic Blue, despite being a just a demo/prototype is actually almost feature-complete, mostly lacking just content now), making game engines is an entirely different beast. Or, in our case, making a system similar to a game engine in complexity. However, that's actually quite exciting to me, because despite the challenge posed by making such integrated dynamic introspective systems, I believe the iterative approach I've been employing until now to make similar systems (like the automated system testing for Nodezator) is enough. The only unavoidable condition is that such kinds of systems require a lot, and I mean I lot, of time and effort to create, specially because of the ginormous amount of data that has to be managed. That's the reason such systems are seldomly made/maintained by a single individual.
That's an interesting perspective. Although the current description of myappmaker is relatively precise (A desktop app builder for non-technical users with features for technical users as well), your version seems more exciting, since it presents a central feature (block coding). However, since we won't use Blockly (which is for Javascript programming), but rather our own Python-based block coding solution, we shouldn't use "Blockly" on the description. Perhaps just "block coding" should suffice. Let me think about it for a few more days, just to be sure. Nonetheless, I like your idea for our description and am inclined to adopt it. Regardless of all that, though, I think we shouldn't worry so much about the description of the project this early. We've been discussing the initial requirements of this project since the very end of September when I first proposed this project and although we only have an initial draft of the software design document (SDD), it already gather more than enough requirements and details for us to begin development and testing of the tool. As I've been saying since the beginning, "no software project must spend too much time on the drawing board". This is actually a principle followed in game development as well. That's cause if a project is taking too long to get off the ground it means either the team behind it doesn't know what they are doing or they don't have the skills to make it happen. Fortunately, our discussions so far and the resulting requirements and design gathered on the SDD shows that we at least have an idea of what we want to achieve. Now it is finally time for us to begin our journey, no more excuses for delays. I spent this first week after getting back from my break replying to some pending discussions and reorganizing my work space, schedule and tools so I can get back to full speed and efficiency. This week I'll finally starting developing the first prototype of myappmaker. And don't take my excitement to begin as overconfidence in my skills. It is just that regardless of one's skills, it is important to have the courage to take the first steps. No matter whether we'll have a smooth beginning and smooth next phases until completion of the project or whether we'll find many road blocks and face many delays. Only by starting and pressing forward we'll know the real nature of the challenge and how we fare against it. Regardless of the results, by finally starting the implementation we'll be able to plan in accordance with such results. Our requirements and design gathered on the SDD are far from enough to give myappmaker its final shape, but it more than enough for us to begin the implementation and start testing and refining our existing design ideas. Since I plan on starting this week, I'll probably only have anything to show in a few weeks (by the end of this month or very beginning of February). Regardless of that, please keep commenting and working on the SDD and this discussion as always, as it is always very helpful. As always, I'll keep checking and replying to everything whenever I have the time, and occasionally keep working on the SDD as needed. Of course, in the meantime I'll also keep you updated on my progress whenever something worth reporting pops up.
Yes, I agree. Considering what I said earlier about the introspective nature of the Glamorous Toolkit, how this can be observed in game engines and how I already half-expected such capabilities would be needed given the complexity required by myappmaker, I think no further comment is necessary. I'll add this requirement to the SDD at a later date, and also the corresponding design, once I come up with the specifics (or rather, as I come up with them and collect corresponding feedback, including from yourself). I expect this all to be a long process, because as I said previously, such introspective capabilities take a lot of time to design and implement. The extensibility in my opinion is only an extension (the pun was not intended but I'd be lying if I said it didn't amuse me) of the introspective capabilities. That is, only once we have control of what myappmaker is, its systems and components, we can make it extensible. Given your questions regarding the core functionality, you seem to be well aware of that already. However, I don't want to get ahead of myself by assuming too much, so if what you meant is actually more or different than what I assumed, please, say so in order for us to establish a proper understanding regarding this.
I know you mentioned this just as an example of what could be possible in myappmaker, but just out of curiosity I took a brief look at the files that can be exported from a blockly project, and yes, that'd be totally possible, relatively simple even, that is, it'd be boring repetitive work, but easy work nonetheless. The .scad file (like the XML, it is also plain text) looks a lot cleaner though (that is, it is devoid of unnecessary details like ids and other redundant data). However, while the .scad seems to be a faithful representation of the logic in the project and can be used to produce the same output of the blocks, the XML file can do that as well and also has extra info on how exactly the blocks themselves are positioned in the 2D canvas. In myappmaker of course we are aiming for that as well, as explained in the SDD, and not only for block coding: myappmaker-sdd/ch-usage-basic-design.md Lines 109 to 115 in 53e039b That is, every interface where custom graphics are used to convey information will have a SVG export option. Other formats may be available as well, depending on the relevance of such formats for each specific info being conveyed. For instance, a form representing settings can be exported as-is in SVG, but wouldn't it be also practical to export it as JSON or some similar format, since we are only interested in the name of the fields and their corresponding values?
Awesome points. I've been thinking about the first two for some time, but didn't think about the possibility on the third point yet. I'll keep all that in mind and also, at a later date, see how we can integrate it into the SDD, that is, wherever is lacking there, since some of these points are already considered/presented there in some way or another.
Again, the introspective nature of the Glamorous Toolkit (in conjunction with your experience with NeXTstep that you mentioned) seems to have made quite an impression on you. A justified impression, of course, as such capabilities are very useful. Yes, the notebook format seems appropriate (both Jupyter Notebooks and the notebook-like interface from the Glamorous Toolkit are great examples). As for the actual name, I don't think we should worry yet, at least not this early. As for the feature, its design and implementation, yes, it is good that we are already discussing it and giving it shape this early. Giving the complexity of myappmaker and its purpose (making apps), as I said before, I'll adopt an iterative approach to its development. That is, instead of starting from a complete design, I'll start implementing what little design we have and testing and refining it over time, as I add more and more features on top of it, always refactoring, refining and incrementing the design until completion. Or rather, that's the only way I'd be able to make a system this complex. Which is not a problem per se, as I'm sure many such systems are created this way. I intend to start by creating a MVP of the canvas, with the ability to define widgets by drawing on it, like we discussed in a previous comment in this discussion. Then, after testing, refining, refactoring, consolidating our design, I'll design the next interfaces/features around it. It seems like a natural order of progression. That is, first we implement the thing we'll be manipulating in the program (widgets and the geometry management that organizes them in the 2D space), then we implement other interfaces that'll interact with them, like block coding and (perhaps) a logic editor. Just remember that my time and effort are also split between the other child projects of the Indie Python project (Nodezator and the Bionic Blue game) and between my commitments outside the Indie Python project. Regardless of that, I'm excited to work on myappmaker and finally produce a first MVP, as, like you, I do think it has a lot of potential and is overall a very interesting project. These introspective capabilities open up another sea of possibilities and useful tools. As I told you when I first proposed to turn your design ideas into a real app, we are in a unique position to provide a lot of value to people willing to create their own apps, but lacking an intuitive and practical tool for that. At the very least, just like Nodezator has helped a lot of people and inspired a lot of great ideas/designs for other projects, this project has all that's needed to do the same for the art/science of app making. The many people that supported and shared your ideals in the many discussions you had and have on hackernews deserve a tool that meets their needs, and we can at least provide a glimpse of that or, ideally, a fully-fledged, viable solution, which is our goal. This Glamorous Toolkit suggestion for inspiration was great! I'll gradually comment on the other suggestions you have been sharing as well whenever I have the time, although for the next few weeks I'll likely just focus on my development work on the first MVP for myappmaker. If I missed some important point or didn't give it enough attention, please let me know, as we have quite a beast in our hands when it comes to complexity. It ends up being very easy to miss something or not giving it enough attention/detail. But that's to be expected. We shouldn't let this delay our progress, but just keep in mind that fixing and refactoring things later is also a common thing in this kind of project. As long, of course, as we don't use this awareness as an excuse to be lax in our design and implementation efforts. Just cause we can fix things later, it doesn't mean we must be negligent. Peace |
Beta Was this translation helpful? Give feedback.
-
|
Ok as i read, i comment. I added links there in case you're not aware about these. I will see the other software named up and follow the links bellow, cool stuff here! I'll be commenting whenever i find cool stuff around. |
Beta Was this translation helpful? Give feedback.
-
|
tldraw is somehow the fundation of excalidraw, i dod'nt know. I found it out here. |
Beta Was this translation helpful? Give feedback.
-
|
A potential point of synergy/implementation target would be Jupyter notebooks --- they already have a Blockly implementation for Jupyterlabs: https://github.com/QuantStack/jupyterlab-blockly and a potential use case would be creating a GUI interface/dashboard for a data display/plot where GUI elements are a part of the display (in contrast to: https://ipywidgets.readthedocs.io/en/latest/ where they are outside). |
Beta Was this translation helpful? Give feedback.
-
|
This is a good one since they have made it really easy to integrate on any html enviroment. |
Beta Was this translation helpful? Give feedback.
-
|
We should also begin gathering lists of repositories which may have useful code. While I don't think handwriting recognition will be needful (better to depend on built-in facilities for this for text box entry), recognizing shapes will be a needful thing if the UI is to be actually drawn/sketched rather than created by drag-dropping elements from a pallete: |
Beta Was this translation helpful? Give feedback.
-
|
A similar project: was discussed on Hackernews: https://news.ycombinator.com/item?id=42586933 |
Beta Was this translation helpful? Give feedback.
-
|
Another project: |
Beta Was this translation helpful? Give feedback.
-
|
Hey WillAdams I saw qt/pyside had been cited here. I attempted to use them in the past, and there's something i dont like about SIGNALS. I have used recently Glade for the GTK framework, it is a great tool for UI making very intuitive, but very pro developer focused. even dough the way signals/events are handled visually in glade is very nice, and is what i would aim for if i would have to design a "framework" or "GUI" app. With this being said, given the need to process user input and events, there's no escape from this kind of considerations.
I can see the benefits of a blockly approach in the programing side of things, for non programmers to learn how to program, in the end is programing anyway but i think harder to scale. About the drawing/designing part, i made some experiments with libreoffice draw, to design a website for a friend, it gives the option to export as xml, svg, and other formats that i made ChatGpt to convert to html, did'nt use it in the end but i saw potential there. There are some good AI open models already that could do the trick and in the next months/years there's going to be a lot more capable LLM's (just to save some time in de Drawing part of the design) Since i'm joining to this conversation, i will comment on things as i continue to read... |
Beta Was this translation helpful? Give feedback.
-
|
Welcome to this discussion, Elotero (is it okay if I call you like that here? It is your nickname on Discord, right?)! It is awesome to have you here. Thank you for your feedback and joining us in this journey. Everyone's feedback is always greatly appreciated in all subprojects of the Indie Python project, but perhaps even more so in this kind of project in particular, given its complexity.
Thank you for your perspective on that. I do think it is too soon to consider another GUI framework though, since we are just starting development of this project. Only once we create and test a MVP version we can properly assess the suitability of the framework, that is, whether it is up to the task or we just pick another framework. If PySide ends up not being up to the task, I'll take your suggestion into consideration. Interesting points you brought up, though. I did find the concept of signals unusual when I started studying PySide, at least in comparison with Tkinter, a framework with which I have more experience. However, I learned a bit about the principle behind the usage of signals a while ago. Basically, using signals allows an object to alert other objects about an event rather than doing something about it itself, which means the original object doesn't need to worry about what needs to be done, just alerting others. This has a lot of good implications, but rather than explaining it, I'll just paste a very good summary I found online, along with the link to the original content:
(SRP stands for single responsibility principle) What's funny is that I didn't found anything about these advantages in the materials I used when I was learning PyQT/PySide, although I didn't use many different materials. Regardless of that, if you search online for the principle behind the usage of signals, you won't come across PyQT/PySide content, but across a lot of content related to the Godot game engine. By the way, the name of the principle is "Call down, signal up". The reason a lot of the content available is related to Godot is because signals are not only present in their API, but also encouraged and heavily discussed. I actually came to know about the principle because of my studies on Godot. Although I don't use it, I like to learn different tools and techs when I can. It often gives me insight on the things I use. Learning new things is also just plain fun. And finally, when you work too much time with one single tool, learning and trying new tools helps in keeping your mind fresh and you come back invigorated to keep using your usual tool. Anyway, the fact that such important concept/principle behind signals isn't more discussed in the PyQT/PySide online community and materials is almost criminal, given the importance of such principle and the popularity of the bindings. The same applies to the Qt framework in general, since PyQT/PySide are simply its Python bindings.
Interesting suggestion. In the SDD, I mentioned the possibility of using a logic editor, which consists of an interface similar to node editing, that is, it uses lines and sockets to connect blocks of logic. So it is very similar to what you are describing. Here's what it looked like in the deceased Blender game engine, where I came to know about this kind of interface:
Here's a more modern look in a more recent project that is an attempt at reviving the BGE:
And here's an addon that claims to do the same, but with a traditional node-based interface:
I'm inclined to use the former versions, rather than the latter. The reason is that it is simpler while retaining the power and flexibility suitable for logic editing. The node graph version may be overkill for this specific task, although useful. Who knows, I might make both available though, because it is not bad to have different interfaces to deal with varying degrees of complexity. They may be suitable for different users with different requirements.
Just a small correction: Blockly is Javascript-based block coding. Since myappmaker is Python-based, we'll use a Python-based block coding solution, either one created by us or one from a third party. Regardless, what you said does apply to block coding in general, regardless of the lang/tech in which it is based. Yes, I do believe block coding is harder to scale. More precisely, I believe this is something to be expected from most visual representations, including but not limited to visual code representations. However, rather than asking whether this is good or bad for app making, we must ask what the requirements are. That is, despite being usually harder to scale, block coding (plus other visual representations/interfaces for code, logic or other aspects of app making) can still be used effectively for project of small to medium scope. As for projects of large scope/high complexity, users will still be able to use regular text-based programming. This is why the description of myappmaker given in the SDD repo's description states that myappmaker is an app maker for both non-technical and technical users. Think of myappmaker like a game engine. Users of game engines are encouraged to learn and use scripting, but only for tasks/aspects of the project where it makes sense. For all other aspects, the myriad of visual tools available have their usage much more encouraged. Only when a project has specific requirements the users do rely more on scripting, but even in such cases many other tasks/aspects are still supported by the usage of visual tools. In that sense, you may think of myappmaker as an "app engine". This similarity with game engines also helps explain the appeal of myappmaker: if the language a developer uses can achieve anything, why do game engines are still recommended to developers? Since the developer is so skilled and the language so powerful, why rely on an engine? The reason is the multiple tools a game engine provides to make the tasks easier, many of which are visual tools. Even so, for more complex/specific things, game engines still make scripting available. In much the same vein, myappmaker will rely on visual tools to make the creation of apps easier to both non-technical and technical users. However, when a project requires, users will still have scripting facilities available. And even then, just like in game engines, we'll still have the visual tools supporting other aspects of the project. In other words, the visual tools are never meant as a replacement for text-based programming. We only aim to use them in areas and for tasks to which they are suitable. That's wherein our hard work lies: in designing such visual tools and making sure they are indeed more intuitive and effective than using scripting for the corresponding task. Anywhere else where we are not able to do that, scripting will be available to the user. For instance, text-based programming can achieve anything, so it can be used to draw/paint an image, however, for such task, I'd rather recommend a raster graphics editor like Krita or Photoshop. In fact, even MS Paint might do the job depending on the user skills and the requirements of the image. That's cause hand-drawing plus the mouse or pen stylus are actually better interfaces by which to transfer the image on the user's mind to the screen. In summary, we'll use block coding, where block coding excels, logic editing, where it excels, and regular scripting, where it excels or we are not able to provide an equivalent more suitable interface.
It is all a question of suitability. No tool is a must-have and no tool is a must-have-not, everything is on the table, as long as it really contributes to the project, that is, its requirements and goals. For everything that the project requires and is supposed to do though, as a developer, I don't foresee that we'd need to use AI. For instance, one of the most processor-intensive tasks I can think of for the project would be to compare something the user drawn on the canvas with possible widgets, so the drawing can be replaced by the widget, just like discussed in previous posts by William. If we had a large database of possible widgets, maybe using AI to analyze the drawings would be justifiable, but in truth we only have a dozen or so available widgets. Even if we consider custom widgets the user may want to add later, it would still leaves us with relatively few possibilities. For such small problem, I expect some light statistical treatment of the points used in the drawing should be more than enough. If this proves unsuitable during testing, then, of course, we may consider other options. For now, though, using AI for this is premature and overengineering. AI is awesome, I don't tire to say that. Its applications in science, for instance, in protein folding, and other areas are awesome. Unfortunately, though, its role is still unclear in several areas. Plus, greedy people who want to win the tech race at all costs are causing AI to be shoved down user's throats without a second thought. Here in Brazil we use WhatsApp for our daily messaging/chat needs. I don't know official figures, but its recent forced inclusion of Meta AI chatbot is regarded as intrusive and disrespectful by many and what's worse, its answers are even regarded as inaccurate or invalid, with the exception of answers to very general questions. But please, I beg you, don't let any of this discussion discourage you. My job as an open-source maintainer is not to discourage people nor assess their suggestions as simply good or bad. Things are more complex than that. My job is just to assess and discuss each suggestion based on technical and scientific principles, and ultimately deciding upon or help deciding what is most suitable in the end. As I said, I'll consider the inclusion of AI in many different forms, including for exporting specific data as you suggested. For now, though, I'm just saying that, as far as myappmaker requirements and my expectations for it go, such inclusion is very likely overengineering, and something to only be considered later, if simpler solutions don't suffice. As always, my honest thanks for yet another interesting suggestion and proactive insights.
As I said at the very beginning of this reply, your presence here is very welcome and appreciated. And needed too. Please, keep bringing new ideas, suggestions, insights and feedback to the project. I'm also aware of you other comments in other discussions, including the one you just mentioned, and I'll answer them as soon as I can, which may take a few days. If I missed something or didn't discuss it in enough detail, please, just let me know, since this is a very complex project with innumerable aspects, which makes it very easy for one to let something pass unnoticed! Peace |
Beta Was this translation helpful? Give feedback.
-
|
The "app engine" labeling is interesting, and I think might point to a potential name. Blockly is weird. It's defined as a set of graphical elements, and it's possible to then use them to create implementations for multiple programming languages, or even a markup system such as XML, though the actual implementation usually compiles the language to Javascript to actually execute as in: https://blockpy.cis.udel.edu/blockpy/load I think AI should be a tool of last resort due to the potential overhead and energy usage and memory footprint --- if we do use an AI engine, I would want it to be self-hosted within the app, and focused on a specific task using a model trained to that task so as to eliminate the possibility of "hallucinations" and incorrect results. A while back there was a PhD thesis which touched on training, which think is notable and worth reading if any AI tools are to be applied: https://www.doc.ic.ac.uk/~re14/Evans-R-2020-PhD-Thesis.pdf Just shape recognition should be all that is needed, and I posted a link on that (there are certainly others, and I think that gathering a list of projects which have compatible code which can be researched/examined/used is a very important task which will probably be an on-going effort for the entire course of the project. I will note that PySide6 does have licensing implications --- fortunately, the truly free implementation PyQT6 is similar enough that if it becomes an issue, it should not be a problem to port the code. Simplicity needs to be a core value/goal for this project if folks are going to find it approachable/usable. On that basis, I really like the example of the "BGE Logic Editor" --- it looks/feels very much like an "Inspector" which I believe is a very useful and potentially powerful UI concept. The way I see it, one would select something, then bring up its Inspector (ctrl i is the usual key command) and then interact with the inspector to set the appearance/characteristics/behaviour of the selected object (or group of objects) as desired --- a key thing to consider is an object-oriented functionality/inheritance where if multiple items are selected and an inspector is invoked, it should show the settings which are in common for all of the selected objects where it makes sense and allow a batch change. |
Beta Was this translation helpful? Give feedback.
-
|
All right!!! (y)
At least to temporally get rid of "myappmaker" XD hahah I see we all like the logic brick's approach, i personally love the blender game engine, the use of logic gates to perform event handling was mastermind and so elegant, (i never fully recovered from it's exclusion of blender development) XD. hahaha With that in mind, i think both approaches whether is logic bricks like or node based like, can be figured out to be included in signal/event handling processes, let me explain what i was thinking/meant about nodezator leverage. I imagine this pretty much in the way @WillAdams In my mind i see the signals/event listened by the widget, becoming an output socket in the node representing the widget in the "linker node editor/tab/window", kind of the in-out sockets in nodezator arguments and return. Once you select the signals the widget listen to, an output socket ex: "clicked" appear in the node that represents the widget . 
Of course it doesn't need to be a node like this, it can be a stack of widgets like the logic brick editor, is not about the visual aspect of it, rather the way you link signals/events between widgets. My objection to Signals in QT is not detrimental to its usefulness, i just felt like the way it was implemented alongside with the (i don't remember the exact name) was it "component or resources?" that have to be created too and linked to signals, was somehow cumbersome in QT and make the design complicated. So the principle "Simple is better than complex. Complex is better than complicated." Always resonate with me about QT, but i guess i comes from QT not being native Python rather a C++ (i think) binding. But is not to say that we should use or not use the framework, is just the way i feel about it. And of course all this complexity can be abstracted and taken away from user experience in "myappmaker" / "app engine" This might be related or not, to the blockly approach, and i understand that we don't want to use this particular implementation, just want to point out that implement a blockly like python approach, as such could be in itself a whole cool idea but a challenge that we should not underestimate, the potential applications could be an awesome gain but i'm not sure it is something we should count on for now. About AI/IA i suggested it as a way to unload weight from development time. I was looking on TLDRAW yesterday and it is already an SDK that integrates flawlessly with electron apps and react, not great to a python based framework but still something to keep an eye on if we end up wanting to give the user the ability to draw the widgets. I did some experiments yesterday to replicate the "make real" options of tldraw where you show a picture of an app the the IA/AI and it gives back the code/pseudo-code, i did it with Cannoli in obsidian using an open LLM from ollama "llava" with relative success. (by just showing a picture of the app i want and simple instructions) it was able to create simple "functional" apps. Last thing for now: TLDRAW this is a very cool project, that made me think about something im not sure we should discuss here since is not directly related to the project, but i had an idea about gathering resources to the project with "little" effort relatively. OK that's it for now, i will add some captures later about the experiments with Cannoli. |
Beta Was this translation helpful? Give feedback.
-
|
Here is the example test i made yesterday. This is the actual app, i'll attach the code too, not impressive but it works.
|
Beta Was this translation helpful? Give feedback.
-
|
Hello, Elotero @00-0o, just wanted to let you know I'm aware of your previous replies above since the first day you posted them. The reason I didn't reply yet is simply because I've been busy with other things, mostly other tasks within the Indie Python project. Additionally, as you know, I like to give proper replies that address all presented topics/points from the original messages. That's how a serious project advances. Oh, by the way, thanks in advance for putting all that information, including images, together, this is excellent work. Just from what I already read from it I'm sure that'll be useful reference material for this project. Regarding the other tasks I've been performing, more specifically, I've been focusing my time on finishing the first MVP version for myappmaker which I expect to upload soon, at the beginning of this month. I had the opportunity to mention this to William in an unrelated email this week, so I wanted to let you know as well. I've also been studying a bit of Haskell and its type management for related work on Nodezator. That's because typing in Python doesn't consist of simply putting annotations on parameters and variables, but also understanding several additional concept/tools that are also added to the mix and wouldn't make sense for someone who only uses duck typing, like type variables for instance. I'm also interested in studying languages other than Python so I can incorporate them in some of my open-source projects, or even make a few apps/games based on them, but that's likely to happen only a few years into the future. Also, Elotero and @WillAdams, in addition to that, this week someone posted on X about Nodezator and the post had many views and was shared a lot: https://x.com/tom_doerr/status/1886002945793106419. Thanks to such post, Nodezator's repo got a lot of visits this week and several new stars. It even ended up featured in a 80.lv article: https://80.lv/articles/this-might-be-the-cutest-way-to-visualize-python-node-editor-connections/ I even got my first GitHub sponsor, that is, more funding for the project! Each new contribution gets me near a financial status where I can work full-time on my open-source projects (the Indie Python project). By the way, William, thanks for the links to other projects shared recently as well, all of them will also be source of great references to myappmaker. Also wanted to let you know that, just as I did regarding the previous links, I'll also comment on them as soon as I have the time (or I'll schedule some time if needed). Edit: grammar |
Beta Was this translation helpful? Give feedback.
-
|
Further research/other projects to consider: |
Beta Was this translation helpful? Give feedback.
-
|
Response to my asking after that here: https://news.ycombinator.com/item?id=42943022 with links to two different repositories:
|
Beta Was this translation helpful? Give feedback.
-
|
This book seems interesting: https://mitpress.mit.edu/9780262140539/a-small-matter-of-programming/ (annoyingly, while MIT Press lists it at $9.75, it is far more expensive from the places I can find it in stock at) It looks at spreadsheets and CAD apps as two examples of programming/coding being made accessible to general users, which is an interesting premise/observation. |
Beta Was this translation helpful? Give feedback.
-
|
One feature which I hope can be implemented is theming, and one theme which I would like to see is LCARS. Discussion of that interface and its design here: |
Beta Was this translation helpful? Give feedback.
-
|
Thoughts and notes on reading list and coding style. One text which I would suggest anyone working on this project would read/consider is John Ousterhout's A Philosophy of Software Design: https://www.goodreads.com/book/show/39996759-a-philosophy-of-software-design which takes decades of experience in industry and academia and presents it in just a score of chapters. A notable text on interface design is Designing Visual Interfaces: Communication Oriented Techniques by Kevin E. Mullet and Darrell Sano --- unfortunately, one has to be careful of which edition one reads since only the first edition has good quality images of the screen grabs. Arguably the text which inspired this entire project is Herman Hesse's The Glass Bead Game (originally published as Magister Ludi) --- while Hesse seems to be out of favour these days, it is a striking and inspiring work, and the visual idea of a graphical representation of knowledge which empowers and enriches human expression is probably a big part of why I consistently try to be a visual person. While making notes for my own project and writing a post for the Google Group discussing APoSD, I wrote the following:
which came out of the posting which began in response to a quote:
That said, a quote from the Introduction sums up my hopes for this project:
|
Beta Was this translation helpful? Give feedback.
-
Hello, everyone!
This is the space wherein to discuss the design and features of the myappmaker (working title) project.
Feel free to share your opinions, feedback, concerns and constructive criticism at any time. All feedback gathered here will help improve myappmaker's design.
Beta Was this translation helpful? Give feedback.
All reactions