Suggested for investigation: dialogbox

Development Third-Party
1

I came across this:

I know, we have alert, filepanel, hdialog, shanty, even kdialog. This seems able to do more:

widget-types-demo
widget-types-demo896×687 95.8 KB

Closer to yoshi, then.

Release 1.0 on the github page is for QT4.8. Clone the git repo instead.

Problem 1 <SOLVED>

The documentation says to use qmake -qt=qt5 -makefile

That won’t work. Use qmake qt=qt5

Problem 2

It compiles and the result looks good

#!/bin/bash

dialogbox <<EODEMO
add label "<small>This script demonstrates the dialogbox application exit codes usage." note
set note stylesheet "qproperty-textInteractionFlags: NoTextInteraction;"
add separator
add label "<big>Please confirm the operation" msg
set msg stylesheet "qproperty-wordWrap: false;
          qproperty-textInteractionFlags: NoTextInteraction;"

add frame horizontal
add stretch
add pushbutton C&ontinue apply exit
add pushbutton C&ancel exit
end frame
set title "Demo 1"
EODEMO

if [ "$?" == "0" ]
then
  echo User rejected dialog
else
  echo User accepted dialog
fi

exit 0

screenshot1
screenshot1219×159 7.04 KB

Except that while it displays our beloved yellow tab, it doesn’t react to it. In a word, it doesn’t close. Which makes it useless.

Normally I’d shrug my shoulders and say “above my pay grade”. But I actually think this could be useful to us. If we could get it working, it would open at least part of the Haiku GUI environment to any language that can make a system call. So if anyone who agrees and speaks QT5 would like to take a crack at it …

You’re welcome.

4 Likes
2

It’d be a Qt GUI environment.

From someone that doesn’t speak QT:

The problem may be below the app. The debugger shows it is waiting in the parser destructor. There’s a call there to terminate() and wait() for… reasons. I think the first one is supposed to kill the thread running the run() method and the other waits until it is really finished. The thing is the first one does finish the thread, at least the OS part, as there’s a pthread_func thread running DialogParser::run() that disappears, so it would seem QThread is waiting on nothing. Removing the wait triggers an assert due to the QThread being destructed when the thread is still running, or something like that. Adding a timeout does finish that part correctly, but the window is still there. Again blocked on QThread::wait(), but I don’t know which one now.

Mine too, it seems.

3

Yes it would. Until someone writes a native equivalent, it will have to do. Yoshi can do most of this, but somehow it never took off. The yab dependency? The default color scheme? I don’t know.

4

I’m not sure what the use for this would be. Simple alerts in an ineractive shell script, yes, I get it, but building such complicated GUIs? It feels like at that point you should consider using a programming language that allows to use the API directly?

And in general, when my shell scripts get longer than 3 lines, I start considering moving them to a proper programming language. Shell script isn’t a great one I think.

1 Like
5

I can see that since you are a professional developer. For us normal blokes, that is not an option. Most on my bash scripts are about 20-50 lines. My maintenance tasks are are about 10-25 lines. My most complex ones are about 100 lines or more–but usually average around 75 lines.

I have three daily tasks that generate my daily bible readings for three bible translations that hits my SQL database and collects the bible texts, organizes, formats, and creates a text for each that is consumable and presented by Koder or StyleEdit (Zeta version).

OOP is too complex for me–it is hard to keep track what is what and where stuff is. Now top-down programming like bash scripting is easier to understand and use. I have been scripting in form or another for 40+ years.

1 Like
6

Scripting is not the problem, just that bash (or more general posix shell) is a terrible language, the only thing it has going for it is that it has a standard and availability (beeing on most unixy systems per default).

If you have the choice to install your own interpreter then you can install another one like python, perl, raku and write much easier, maintainable and safer scripts (safer in the sense of much harder to get wrong)

7

C++ is a huge waste of time no matter if you are a profesional or not. Countless hours of debugging wasted on my side with it. Sometimes it is worth the performance. For simple applications like this, it certainly isn’t.

But I can’t see how bash and a tool like dialog are going to solve that. Whenever you have a GUI, the code can’t execute linearly anymore. The user can click any button in any order, and each of these actions will have to run some piece of code. This doesn’t necessarily means complicated C++ code, memory management and everything. My firs GUI projects a long time ago were in RapidQ (Some free clone of visual basic) and then Delphi. Building the interface was done by drag and dropping widgets, and then writing bits of code for each button. I had no idea what I was doing pretty much, and still managed to build a workable application.

8

It doesn’t necessarily have to be C++ on Haiku as yab has bindings to the Haiku API as well. Might be a better choice for somebody just slightly going over the limits of bash scripting.

9

@nephele --I come from the days of mainframes and Unix systems. Yes, the Bourne Shell, which Bash is a derivative, is older than most computer users. It is the de facto shell for good reason. However, the Bash bashers always complain for one reason or another over the past two decades–so use another shell as you prefer–there are many alternatives as you see fit. Use what you like and be comfortable with your preferred shell. For me, it is Bash. I use Bash because it does exactly what I need it do for more 40+ years (collectively) and I have seen it grow and improve over that same time period.

I have used Perl extensively in my past to consume, transform, translate, and aggregate data & files–but I have not used it in the last 20 years. Why use Perl when bash can do it without an interpreter. As for others, just have no interest in them.

Also, I do not use Haiku’s GUI portions available to me, such as aforementioned objects noted in previous comments. Though, the dialogbox seems interesting if it could be created for Haiku. For most part, as GUI as I get, I write code to call a GUI app or one of my databases to consume data.

@PulkoMandy – I am an IT professional whose focus is in system and database administration, with strong emphasis in SQL development–hence using my aptitude for top-down programming.
I am glad that there are OOP programmers out there creating apps we interact with everyday–I am not one of them.

I even considered using Java (CLI)–but why, when bash can do it. I looked at Yab (CLI)–but I do not have the time to learn it…though I will try it in the near future when I more time to play with it to create non-GUI apps.

Back to my initial response, it was just to simply note that there many more Haiku users with no programming skills and, for others that are like me, do not have the skills as OOP developers do.
I use what I know–shell scripting and batch programming.

Thank you for what you guys do to continually improve Haiku! I and many other users really do appreciate it!!

1 Like
10

Dunno about this dialogbox thing, but as a general rule tools of this nature can be very useful. I wrote a whole journaling tool (in Python) using dialog for the user interface, that nowadays can be used on Haiku. I also use Zenity to give Tcl/Tk and Tkinter apps decent file dialogs on Linux. It’s not like regular GUI programming because it’s a series of modal dialogs; yet they can be surprisingly expressive and good-looking. Doesn’t have to be Bash, either. This can be done from any programming language with a system function or equivalent. (In fact Bash makes it more convoluted than others). So I’m glad Haiku has tools like Yoshi and Shanty. They deserve more love.

1 Like
11

ATM yab is not ideal for non-GUI apps because it is not compiled against ncurses. Annoyingly, all the ncurses-reliant commands are still in the documentation. Yes, there is a note that you need a special version of yab to use them (which you have to compile yourself) but it can only confuse newbies.

I am currently experimenting with several BASIC dialects to come up with something specifically to write Haiku non-GUI apps that can still throw up simple GUI dialogs. I have made some progress with an older version of yabasic: clasqm/basenjilibs: Haiku-specific libraries for yabasic - Codeberg.org and I am now porting that to BaCON to see how that would work in Haiku.

12

If it helps, someone else was recently asking about BaCon which is available on Haiku almost at the latest version, and has excellent support for TUI apps. I used it to make a game port that became the most popular edition; the Haiku build has a glitch, because it was written in an older version of the language and never updated. As a bonus, it’s a widely ported compiler.

13

I played a bit and I’m not skilled/experienced enough for this, but I’m guessing that the issue is that the GUI thread is blocked by the QThread command-parser class. If you comment-out the parser.start(); line in dialog_main.cc then the window reacts to clicking on the close in the Window tab. (But of course, if the parser part is not running, then the whole app doesn’t do anything since you can’t send it ‘commands’).

My guess is that assuming this dialogbox app works on other platforms (??), then maybe the Haiku Qt5 port is not correctly implementing QThread or requires some other implementation details that need to be shimmed-in for Haiku ??