GUI Designer for TUI

[x2nie]

Hi all, this was weekend project while I started creating TUI, Text User Interface that will run in console / command line.


It would be similar to TV (turbo vision) or FV (freepascal vision) did. Actually it depends on video,driver etc. of freepascal.
But, TUI let you use Lazarus for designing WYSIWIG (what you see is what you get) UI aspect.


The advantage (or funny things for me) of developing TUI is that it has it own resolution that never be identical to screen resolution;
because default Lazarus's coordinate system (pixels in screen) must deal with console coordinate (80x25 chars).
So it very fun to try (at least according to me).


I heard in this forum about someone developing new OS (using Arduino?) with freepascal, that can interact with console / command line.
Maybe TUI will be useful for him.





Well, I generally don't know for what situation TUI will be useful. I just do it away and have no specific plan.
In other hand, I used TUI to learn how Lazarus works, and hope this experience would be contributed back to Lazarus for improving the Lazarus support of non-LCL component-design/editor.



These are TUI's current work:
* Based on TComponent, not Object.
* Design/Editor using Lazarus (Property Editor, resize/move/drag-drop with mouse or keyboard, synedit sourcecode editor)
* Runtime run on console, cross-platform of course,
* has 3 components: TtuiView (base for all other), TGroup (base for container), TtuiLabel (for test the text drawing)
   and TtuiWindow (root component for each unit, similar as TForm)
* + 1 sample compilable runnable Demo project

* Left,Top,Width&Height of form designer doesn't affect the bounds of root component. (newest feature of TUI)




TODO / Future plan:
* real TApplication class for TUI. it has not yet.
   - we can construct TApplication based on TGroup (fpc/packages/fv/views.pas)
   - alternatively, based on TCustomApplication (fpc/packages/fcl-base/src/custapp.pp)
* interact with keyboard and mouse in runtime. it has not yet.
* add more widgets: button, scrollbar, progressbar, listbox, checkbox, radiobox etc.


Ohyeah, TUI is in it's very basic ability.
So, any suggestions are welcome.


download: https://github.com/x2nie/tui

[Leledumbo]

I heard in this forum about someone developing new OS (using Arduino?) with freepascal, that can interact with console / command line.
Maybe TUI will be useful for him.

If you mean Ultibo, that's for Raspberry Pi. I might not be into it yet (lost interest developing IoT), but surely a Lazarus style application development could be a nice addition to it. Maybe make a video and it could be added to: https://ultibo.org/make/

[x2nie]

If you mean Ultibo, that's for Raspberry Pi.

Ohyeah, maybe that is it. I forgot the detail.
but hey, Raspberry Pi is also already has GUI, right? if using Linux.


Thanks for the link. Amazing, I just see that Ultibo able to interact with touchscreen.
Anyway, it seem Ultibo has uncommon screen resolution (40x25 chars) isn't it? Or it has no console screen at all because there are 2 different font size.
However, apparently no dialog / form ever shown from Raspberry's screen in videos.


And I just visit the Ultibo repository / source code,
and maybe involving lazarus form (like TUI did) will make the codes more clearer. (No offense, just idea).
because *.LFM is the correct place to put data/images/resources/properties.
---------------------


Well, I added the screenshot of above form being designed while in action (runtime), proving that TUI really run (and jerk yet).

[x2nie]

furthest imagination I have about TUI is using it to develop such Window Manager (like TWIN at screenshot below)


At least, it would far better than developing TUI in real console (such classic VB for DOS)


or maybe a nerd music player?


----------------
Anyone have another idea to make TUI (Console) applications looks good?

[Thaddy]

Anyone have another idea to make TUI (Console) applications looks good?

Something like this? All done in high ascii...

[molly]

Anyone have another idea to make TUI (Console) applications looks good?

Get it away from dos (legacy) dependency.

Use a virtual screen buffer that allows for every unicode character to be stored. (finally getting rid of those code-pages)

Render the virtual screen buffer with SDL into a texture using custom fonts (and some hard-coded default in-build fonts, that also allows for custom graphic chars so you can create real neat check-boxes etc). This also allows to get rid of that dratfull 80x25 limitation (if i must run dos applications, i always do it > 80 x 25). It also allows for more colours if/when support for that is added. More important;y it allows for running those applications full-screen or windowed on users request again.

Bonus: Render that sdl texture into an opengl object, let's say a cube. Now every side of the cube can have it's own virtual screen buffer rendered running its own dosapp. Add some nice interface to be able to switch between applications 

Most importantly, have fun !   

[abouchez]

IMHO the main idea of such apps is that they should work from a ssh remote link.
True UI with components may be much easier to deal with than plain command-line, for some data.

So I wouldn't go into the "texture rendering" path, and stay with standard remote console access.

What may be a good add-on is perhaps the future ability of run a web app from the very same source code.
That is, you can run the app from ssh console, OR you may run the app from a web server, and use HTML5 components to display the very same screens...
Open new possibilities, e.g. for remote administration tools of servers.

[molly]

What may be a good add-on is perhaps the future ability of run a web app from the very same source code.
That is, you can run the app from ssh console, OR you may run the app from a web server, and use HTML5 components to display the very same screens...
Open new possibilities, e.g. for remote administration tools of servers.

That is the same idea, just using another rendering engine back-end. There is no difference otherwise.

However, the rest of my suggestions do differ from standard legacy.

[marcov]

I would just redo FV on LCL principles.

If I would draw a blank slate I'd go slightly beyond, and add some interfaces to the mix. (Iserializable and icontrol), but I think simply basing yourself on top of tcomponent is a good way to focus on the actual problem, and not redesign the whole streaming etc.

The root visual component can draw window like structures (or not, depending on properties)

As to terminal or GUI, I would simply abstract it with a framebuffer(as TV already does, with the video unit), have multiple actual backend.

The backend could be textmode/terminal or a simple lazarus GUI program emulating just the basics of a textmode framebuffer. That also makes development easier without the arcane terminal limitations and complexities.

Just don't rule out textmode completely since running over putty is one of the main remaining useful features of full screen textmode programs.

FV/textmode IDE HAS such backend abstraction originally, concentrating keyboard/video/mouse in the respective unit with were originally interfaces and could be replaced, and unit drivers as a mediator. As Molly correctly statess, the interfaces and implementation might need an upgrade (or better, alternative) for unicode first. videow or videou might be a good name.

[marcov]

What may be a good add-on is perhaps the future ability of run a web app from the very same source code.
That is, you can run the app from ssh console, OR you may run the app from a web server, and use HTML5 components to display the very same screens...
Open new possibilities, e.g. for remote administration tools of servers.

But make it viewable in Lynx then. Otherwise you still need a gui and it won't work in putty :-)

[Thaddy]

Yup, Marco, that's what I want: render lazarus in textmode
Anyway, keep it lightweigth.

[marcov]

Anyone have another idea to make TUI (Console) applications looks good?

Something like this? All done in high ascii...

The text in the right window is definitely proportional (look at the l's and i's), so this is probably graphics mode.

[x2nie]

WOW , now my head like was blown up with amazing ideas ! I love all of them.

I think I could start to imagine of how awesome if TUI could be to accommodate above ideas, that are very interesting.
but damn, how stupid I am, some stuff are beyond my knowledge. (I didn't try yet the SDL, HTML5, PuTTY, Font Management etc.)
--In fact, I just visit PuTTY at wikipedia today.
So currently I don't know how to hook TUI into that stuffs.


Nevertheless, summing up whole of you guys's ideas into consideration, Next TUI would be:
* Able to get out from console/text-mode,
   by emulating text-mode within such a TForm as root component, or as whole desktop space + multi form emulated.
* Still support to run in text-mode by default, also for reason of being used by PuTTY

* Able to use UTF8/Unicode
* Still support ASCII/codepage by default. (I don't know how to deal with codepage yet)

* Able to work with more than 16 color
* Still support the classic 16 console colors

* Able to draw graphics, such as custom checkbox/radiobox in both emulated screen and console/text-mode
* Able to draw graphics, such as Linux/Brand logo in emulated screen only
* But, all coordinate used is in console world (80x25, 80x50)

* Wouldn't support multiple font size. (At least for beta version)


I think the key (most important) aspect of above features is in the implementation of various backend (TUI's buffer).

For example:
FV and current TUI only need one (plus one more for swap) buffer, this buffer has similar size of current screen mode (maybe 80x50).
each cell represent double byte : one byte for a char/text representation and another byte for both 2 colors of text color and background color.
So when we implement the use of 64colors + Unicode, we can't use that buffer type because of:
* 64 color of text + 64 color of background = 128bit wouldn't occupied in one byte.
* Unicode/ UTF8 has dynamic width of a character. sometime 8bit, 16bit, 24bit.
* Using unicode shall require to support RTL (right to left), like arabic, hebrew. (well maybe not in beta version)

That way, we should create a whole new buffer type to accommodate that.
No, not only the buffer type.
Actually the next TUI will need a new rendering system replacing the limited capacity of static -size console buffer.
So, rather than direct writing to buffer, let each buffer-backend to decide how to render the text, therefor how to do with colors.


Well, I have no problem to realizing that plan. as far as TUI characteristic doesn't be changed:
TUI = designing Text User Interface with Lazarus as UI Designer.

So, I think TUI will never be:
* multiple font-size.
   Different font may need different coordinate for each other, that may drive to need of universal pixel coordinate,
   which is out of TUI business.
   (Well,  At least, multiple font style may came to consideration to be supported in console-emulated mode.)

* Interaction with mouse in pixel.
   TUI will always interact with mouse in character/console coordinate.
   I have no plan to extend mouse interaction precision with TUI into pixel coordinate.
   Although somebody can extend it into pixel precision, that would be as beyond my ability.


-----------------------------------------------

Anyway, I have a question:
Do we still need a buffer for whole activity (like current FV),
or shall we use a  buffer for each TWindow (like TForm has it's own canvas) ?

I think using a buffer for each TtuiWindow will make work easier, but it will consume more RAM. I don't know for sure. ?

[x2nie]

... that's what I want: render lazarus in textmode
...

What it mean? Do you want Lazarus to be a console app? I think its amazing, but not sure if you really wanted it.

[Thaddy]

Oh, yes I do....
It is also a good test, because a proper widget set will compile lazarus itself in textmode too.
That's the ultimate consequence of such an effort