Home   Archive   Permalink

Full Circle

Every couple decades, just like styles of clothing, what was long uncool becomes stylish again:
I hope this style trend makes a big return, and sticks around for a while.

posted by:   Nick     8-Oct-2017/8:10:17-7:00

BTW, has anyone used IMGUI for a project?

posted by:   Nick     8-Oct-2017/9:54:44-7:00

I can not at all believe you wrote about this as I've been spending hours and hours looking at GUI systems(I'm always going back to this) and came up with "Immediate Mode Graphical User Interfaces" (IMGUI)like you and read a bit about it. These are being pushed by game designers. The object oriented GUI stacks have become bloated piles of undecipherable gobbledygook that it takes you twice as long to learn and program the GUI than it does the program that you want to write.
There's several people working on this. One library that I found seems to be fairly complete.
Look at the examples, they look good. So here's my thinking if this was linked with R3 but substituting the calls with VID dialects, amazing how similar the simple calls are to VID, maybe it would work out and it's a maintained library that supposedly is basic C++ and so is cross platform. Here's a great video by one of the game designers that inspired the library to be created.
MollyRocket video (Immediate-Mode Graphical User Interfaces - 2005)
Even better here's something Nick I think would be interested in. Nick has always said he wanted to run Rebol in a browser, the whole thing. Here's a step in that direction. There's a feature called webassembly designed to run C++ in a browser.
And here is a guy working on running the ImGUI library in a browser. It's just a hop, skip and a jump to including all of R3 or more likely RenC combined with ImGUI and you have a complete R3 in a browser.

posted by:   Sam the Truck     1-Nov-2017/11:55:23-7:00

I might add this is exactly what I've been saying about RED. To make RED work you need to get the thing running and feature complete. The GUI as long as it looks modern will be fine. If all the time spent fooling with making all the GUI's look native was spent on a simple "paint" type program that could capture the look of a GUI from an onscreen capture then copy that to whatever control element you wished to use then RED could be ported rapidly to anywhere and every where. You could even make new widgets by painting them and then add attributes,(text or numerical levels or radio dots(on/off) or knob values or whatever, to them in the paint program. The paint program would do all the low level stuff, you would save it to a file named for the widget and you would just call whatever name you gave the widget in VID or cut and paste the file into your program.
The other killer program to add to RED is substituting main processor instructions,(processing), for graphics chip calls to speed up graphics using the graphics processor. This could be an add on worked on last. Using the graphics processors speeds up things a lot. This could be done, I think, with Vulcan. This is another thing pushed by game developers as OpenGL is too damn slow, too damn voluminous, too confusing and too big. Vulcan is a big push by all the game people and the graphic cards manufacturers so it will be well supported. It also breaks down the calls needed into little parts that could be slipped in at the lower level while leaving all the stuff at the top,(VID), alone.
All the signs are that what Carl talked about, bloat, is starting to choke the whole industry. The mass of crude is so thick that it's all anyone can do just to get any programs written. No one can keep all these "necessary" libraries in their heads. Think if RenC or RED could run on all platforms, in a browser or be complied for all new platforms easily with a nice GUI that could be modded in any way you want and widgets added easily. It would take over.

posted by:   Sam the Truck     1-Nov-2017/12:55:58-7:00

https://pbrfrat.com/post/imgui_in_browser.html is really cool. That's exactly what I was hoping for with R3-GUI, but this community had very little interest in porting the GUI. I'd still pay to have R3-GUI ported to web, iPhone, etc.

posted by:   Nick     2-Nov-2017/7:19:22-7:00

I think this might also interest you also. It has the same ability to to be run in a browser as it's C language so I' assuming it could be compiled like IMGUI. I bet it would work great for portable stuff as they only have a small amount of active elements on each page.
Zero Memory Widget
It hasn't been worked on since 2009 but...you know some things are just done. It works off of the (GIMP Drawing Kit) library which is the underlay of GTK+ windowing system and the library for the GIMP paint program which can do lots of stuff graphics wise.. Seems it covers most of the stuff the AGG library and more but has some functions to handle cursors, drag and drop and a few other nice functions. It also is ported to several systems, windows, X11, etc. It would be great for RED or R3(might save RED a lot of time writing interfaces to various OS systems from scratch). It does look ugly compared to the examples in the IMGUI. He says it will work on a 150MHZ computer fine so any phone these days can handle that.
Anyways I'll stop babbling these two are the ones I've found that seem most interesting and can be integrated.

posted by:   Sam the Truck     2-Nov-2017/10:32:12-7:00

There are so many alternatives to the heavy standard tool sets that are most common. It's great to see that some people still work towards providing improvements.

posted by:   Nick     2-Nov-2017/10:55:19-7:00

In response to 'Sam the Truck':
Love the idea of rebol/red. I think 'bloat' in the industry can't really be avoided (at least not everywhere). Another view is that 'bloat' creates opportunity to 'specialize' - one person can no longer complete a large project easily. But many of us (me included) like to be 'lone wolves' and do it 'all'. There are upsides and downsides to both approaches. I don't believe there will be ever be an 'ideal' solution for everything. Pick your ideal way to work (team or individual) and pick the best tools for the job/project.
For the individual approach, the tools need good 'recent/updated' docs, and an active community. This makes people feel good, they don't feel like they've been left behind working with 'old' tech. I don't believe there is a definitive way to achieve mass-adoption though, sometimes it takes luck, sometimes a killer app. If more of us share our rebol/red knowledge as often as possible (blogs, tutorials, etc.) it will help improve this stack at least, and keep it alive. I already get the feeling that rebol is dying when I look at the tutorials ... I'm sure it's not, but it certainly appears that way when I see things like 'last updated 2013'. I think someone who's invested in keeping this community going should update these tutorials and at the very least update the screenshots to Windows 10. Even if the content doesn't change, at least make it look like someone is working on it 'today'.
Sorry, a bit of a rant, but really would just like to see this amazing technology have a chance. I will try to do my part to help as well. Cheers everyone!

posted by:   Steve     20-Aug-2018/19:32:06-7:00

I'm sorry Steve, lately I've been putting in 16 hours a day, 7 days a week, running a full time business and producing a new television show, so have no time to make cosmetic improvements to more than a decade old tutorial just to improve appearances for those who are already using the material.

posted by:   Nick     22-Aug-2018/9:32:16-7:00

If you'd like to do the work of updating images and links, I'd be happy to upload a new copy of the tutorials...

posted by:   Nick     22-Aug-2018/10:38:26-7:00

...and also, the subject of some of the tutorials (REBOL 2) has not been updated for years either. Any documentation on those subjects is as correct now as it was years ago. Although, I suspect many people have noticed the sad state where some R2 documentation says something about some feature that will be explained in some future documentation, and that alleged documentation is nowhere to be found. I spotted that a couple times in the REBOL/View documents. That's why I wrote my own View "manual" so to speak. It is my opinion, based on nothing really, that Carl erred in his approach to open-sourcing REBOL by not arranging for a new Benevolent Dictator For Life. That's why I have hopes for Red which has such a person.

posted by:   Steven White     23-Aug-2018/9:01:56-7:00

There is an invite on rebol.com to work on some documentation, rebol.org in particular. There are a lot of things today that just didn't exist when rebol.org was written.
I thought the entire script library could be neatly and simply displayed with accordions (collapsible content). Or text overlays perhaps. I'm no expert and if anyone wants to beat me to it - great!
Renewing documentation is quite a task for one person. Chopping up the task into bits that a person might do from time to tie using a template format could get the job done. Many hands make light work.
It wouldn't be a live rewrite,only the completed work would replace the exisitng material.

posted by:   Alexis     23-Aug-2018/19:27:45-7:00

Oh my gosh, Nick, no apologies needed! So sorry, my post wasn't meant to target the original author (or any one individual). It was a statement about community involvement. Sorry if it came across that way. I should have written it a bit better. Your work is much appreciated. What I meant when I said 'someone should update these tutorials' was that 'anyone' in the rebol/red community should update them. I realize they are not in wiki format, but perhaps they could be? Retain the original tutorial, but transfer a copy of the content to a wiki where it can be updated by the community?
Just a suggestion. And it's just my opinion and an observation. I've been known to be wrong often ;-)

posted by:   Steve     23-Aug-2018/22:48-7:00

Another suggestion might be to put the material on something like GitHub, put it under a Creative Commons licence, and open it up to pull requests for changes?

posted by:   Steve     23-Aug-2018/22:56:54-7:00