Evolving the GUI definition

> While other Nim GUI are mostly unknown territory. Unfortunately true. Though I've really enjoyed hacking away on Fidget & Fidgetty. There's lot of potential, but _also_ lots of work and never ending details. I'd really like to be able to re-use the native text input boxes like the browsers (u

Evolving the GUI definition

> Long compile times can also imply that the compiler does something complex > like actually optimizing your programs (C++) or proving properties that are > important for security (Ada). I always figured that "in the future" compilers will take successive refinement approaches. The first pass w

Evolving the GUI definition

> Do you think so? You need to keep in mind the hardware that Wirth did have > and the goals that he wanted to achieve. Yes I do think so and both Ada and C++ are successes too if the criterion is "they did what their inventors wanted to achieve". > I still believe that it was better than C++ a

Evolving the GUI definition

> Oberon is actually unusable by today's standards: That is obvious. > But even by yesterday's standards it really was worse than C++ and Ada. Do you think so? You need to keep in mind the hardware that Wirth did have and the goals that he wanted to achieve. The language was simple, but we all

Evolving the GUI definition

> Again, look at VST's, bright and colour full and very fit for use. I just want to add my take on the story of VST plugin GUIs. They: 1. Have their roots in a time when skinning applications was all the rage. 2. For years, most had so little actual code in them, that the only real differenc

Evolving the GUI definition

> The problem is that this language was designed in the 1980s and still today > nobody knows it. Why? I don't know. Maybe it was because "the industry took > off", but it was miles ahead of both Ada and C++. Oberon was a very well > designed language. Oberon is actually unusable by today's stan

Evolving the GUI definition

I think Nim + some form of Web GUI is the best option for now. Not because it's better, but because you can re-use your web skills and new things you learn about web, you later will be able to re-use in other projects. Other Nim GUI options require learning new API that will be dead knowledge as

Evolving the GUI definition

I only tried to make a picture, but you quoted the wrong parts of my picture. I will explain what is wrong today: Do you know prof Wirth? You probably know that he created Pascal. What not a lot of guys know is that after he created Pascal he continued with new languages, Modula and after that h

Evolving the GUI definition

> summary of Nim GUI's libraries. Actually we have more than 20 currently. See list just above this heading: I have recently added the www links.

Evolving the GUI definition

@grd I need some precisions to understand fully your opinion. > That is why we today need to live with C++ and C, and Windows, and the WWW > and you name it. What's the problem with it ? They might all seem old technologies WWW being very different from an the OS Windows, and the two languages.

Evolving the GUI definition

Lol. Lately I have been phrasing this as: Delegation can save so much, but trust is also tricky!

Evolving the GUI definition

What you are describing is the paradigm of all human endeavours.

Evolving the GUI definition

If you want to have my opinion, I need to say that my opinion differs from a lot of other guys. The problem is that way too many guys want the best idea built, but they never ever think about the consequences about their ideas. That is why we today need to live with C++ and C, and Windows, and

Evolving the GUI definition

Haha, you are perfectly right! I will try to update the document! Thanks for the remark, this looks like it is driving the original point home :)

Evolving the GUI definition

hey, wait, it seems that there is an easy to reach fix (update blogpost): nbKaraxCode: const helloId = "helloId" inputId = "inputId" var hello = "welcome to the hello program" name = "" exited = false karaxHtml: if exit

Evolving the GUI definition

You don't handle the `exit` word at all. In the input section, you will probably have to add an if case to output the "Thanks for playing" part. I guess the problem in the conversion is the way you end the program. Do you hide the button, once exit has been given as input ? Do you leave the butt

Evolving the GUI definition

> try converting the following imperative script even by hand: interesting challenge! this is my solution using nimib's `nbKaraxCode` (karax without boilerplate): nbKaraxCode: const helloId = "helloId" inputId = "inputId" var hello = "welcome to t

Evolving the GUI definition

What if, every widget is an executable, is written using what ever gui lib, tied together using a lightweight inter-process bus to present itself as a singe app for inspiration, look at DAW's and their VST's, AU's etc. then, forget about native look and feel. Applications should be written to t

Evolving the GUI definition

[for the curious: Godot is reactive (aka declaritive). That is why it works across platforms; but you must also stay within its very restrictive bounds. Don't be calling the OS or anything.]

Evolving the GUI definition

I suspect you are asking for some kind of great cross-platform GUI framework. Sadly, IMO, having a good universal cross-platform GUI is nearly impossible, for all language,s for multiple reasons. One of the more basic reasons is handling the OS environment. Some environments, such as Windows or

Evolving the GUI definition

Hmmm... and another thought: One pattern I've ended up embracing in Fidgetty has been Nim's "enlightened procedural style". Essentially just using proc's that when called modify the current environment, whatever that is. With Nim's templates you can make this work with functional or object-orie

Evolving the GUI definition

Interesting ideas! I'm not sure it'd be possible or even desirable to directly share end user code / widgets between frameworks though. However, there's lots of ideas and core libraries that can be shared. Things like [Windy](https://github.com/treeform/windy) and [nim-native-dialogs](https://g

Evolving the GUI definition

I don't know about all your other ideas, but is pretty automatic as CLIs go. The `shoe` approach of just populating variables still leaves a need for users to specify activity. `cligen` just takes that one step further to have the user specify the proc instea

Evolving the GUI definition

Evolving THE GUI definition? Please chim-in with views or ideas to sort things out, correct or add. Are we already further, or yet not here at all?: What's needed? With many platforms and gui toolkits around, it seems they all have their basic platform- and toolkit specific way,