FLTK dialogue tool like YAD or Zenity?

[Karl Harbinger]

Does anyone know if a dialogue tool like YAD or Zenity exists that is based on FLTK?

[Ian MacArthur]

On Thu Jun 16 2016 19:47:57, Karl Harbinger wrote:
> Does anyone know if a dialogue tool like YAD or Zenity exists that is based on FLTK?

Not that I know of, as such (though there may be, I just don’t know!)

When I needed something similar, I kinda wrote my own, but all it could do was open a file chooser or a pre-made dialog box, so only useful for my one specific usage...

The closest thing, I guess, might be libfltkui, but I have no experience of using that; https://code.google.com/archive/p/libfltkui/downloads

Also, maybe (again, never tried this...) OpenExposition : https://sourceforge.net/projects/openexposition/


There are bindings to a few scripting languages though, that you could leverage to do that job:

Tcl : http://pages.infinit.net/cclients/files/fltk.html

perl : http://www.cpan.org/authors/id/M/MK/MKENNEDY/

Lua : https://code.google.com/archive/p/luafltk/

And of course,

Python : http://pyfltk.sourceforge.net


And likely others...

[Karl Harbinger]

I started to work on such a program: https://github.com/darealshinji/fltk-dialog
I'm still a beginner in programming and the program still has some flaws.

I have a big problem with the @ character. If you take this source code:

#include <FL/Fl.H>
#include <FL/fl_ask.H>

#include <iostream>
#include <string>
#include <string.h>


std::string findAndReplace(std::string ReplaceString,
                           std::string FindWord,
                           std::string ReplaceWord)
{
  size_t index;
  while ((index = ReplaceString.find(FindWord)) != std::string::npos) {
    ReplaceString.replace(index, FindWord.length(), ReplaceWord);
  }
  return ReplaceString;
}

char *translate(char *inputText)
{
  std::string s(inputText);
  s = findAndReplace(s, "\\n", "\n");
  s = findAndReplace(s, "\\t", "\t");
  s = findAndReplace(s, "@", "<at>"); /* works */
  //s = findAndReplace(s, "@", "@@"); /* doesn't work */

  char *a = new char[s.size() + 1];
  a[s.size()] = 0;
  memcpy(a, s.c_str(), s.size());
  return a;
}

int msg(char *msg)
{
  msg = translate(msg);
  fl_message("%s", msg);
  return 0;
}

int main(int argc, char **argv)
{
  if (argc <= 1) {
    std::cerr << "usage: " << argv[0] << " <message>" << std::endl;
    return 1;
  }
  return msg(argv[1]);
}

If you compile this and run it i.e. like this: ./myprog "Line 1\nLine2"
it will replace the '\n' with a real newline character.
When I enter a message like "abc@xyz" it wants to replace the @ with something else, because the @ is used to display symbols in FLTK, ie. @-> will turn into an arrow.
The message will simply not be displayed after the first instance of @.
An "@" can be displayed by a double @, but using the findAndReplace() function from above to replace '@' with '@@' doesn't work, but I can replace it with anything else.

Any idea how to solve this without patching src/fl_symbols.cxx in the FLTK source code?


[Greg Ercolano]

On 07/09/16 11:12, Karl Harbinger wrote:
> I have a big problem with the @ character.

> [..]

> Any idea how to solve this without patching src/fl_symbols.cxx in the FLTK source code?

Yeah, the @ symbol stuff is a pain.

Two choices:

1) Preface the string with @. which will turn off symbols for just that string
2) Disable symbols globally with: http://seriss.com/people/erco/fltk/#DisableSymbols

[Albrecht Schlosser]

On 09.07.2016 20:12 Karl Harbinger wrote:

> I have a big problem with the @ character. If you take this source code:

...
> std::string findAndReplace(std::stringReplaceString,
> std::stringFindWord,
> std::stringReplaceWord)
> {
> size_t index;
> while((index =ReplaceString.find(FindWord))!=std::string::npos){
> ReplaceString.replace(index,FindWord.length(),ReplaceWord);
> }
> returnReplaceString;
> }
>
> char*translate(char*inputText)
> {
> std::strings(inputText);
> s =findAndReplace(s,"\\n","\n");
> s =findAndReplace(s,"\\t","\t");
> s =findAndReplace(s,"@","<at>");/* works */

> //s = findAndReplace(s, "@", "@@"); /* doesn't work */
>
> char*a =new char[s.size()+1];
> a[s.size()]=0;
> memcpy(a,s.c_str(),s.size());
> return a;
> }

...

> If you compile this and run it i.e. like this: ./myprog "Line 1\nLine2"
> it will replace the '\n' with a real newline character.
> When I enter a message like "abc@xyz" it wants to replace the @ with
> something else, because the @ is used to display symbols in FLTK, ie.
> @-> will turn into an arrow.
> The message will simply not be displayed after the first instance of @.
> An "@" can be displayed by a double @, but using |the findAndReplace()
> function from above to replace '@' with '@@' doesn't work, but I can
> replace it with anything else.
>
> Any idea how to solve this without patching src/fl_symbols.cxx in the
> FLTK source code?

Your problem has nothing to do with FLTK, your program is wrong.

(1) If you replace '@' with '@@' in findAndReplace() your program runs
into an infinite loop, because the while loop doesn't terminate (it
finds '@' again and again.

(2) Another tip: instead of allocating a = new char[s.size()+1], copying
and terminating the string with 0 you could just return s.c_str()
because this is always a "C String", i.e. a zero terminated string.

[Karl Harbinger]

Greg Ercolano

[...]

2) Disable symbols globally with: http://seriss.com/people/erco/fltk/#DisableSymbols

 

That did it! Thanks.

Albrecht Schlosser

[...]

(2) Another tip: instead of allocating a = new char[s.size()+1], copying
and terminating the string with 0 you could just return s.c_str()
because this is always a "C String", i.e. a zero terminated string.

That's why I did that:
error: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
   return s.c_str();

[Albrecht Schlosser]

On 10.07.2016 00:35 Karl Harbinger wrote:

> Albrecht Schlosser
>
> [...]
>
> (2) Another tip: instead of allocating a = new char[s.size()+1],
> copying
> and terminating the string with 0 you could just return s.c_str()
> because this is always a "C String", i.e. a zero terminated string.
>
>
> That's why I did that:
> error: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
> return s.c_str();

Well, then your translate() function should better return 'const char*',
and you're done. Since you presumably only want to display the string
with fl_message() (as in msg()) or use it for your dialog, that's likely
the better solution. And, BTW, msg() should also take a 'const char*'
argument instead of 'char *'.

But beware: whatever solution you choose, calling translate() multiple
times with different strings would free and/or overwrite the translated
string, so you must take care to copy the string to local space after
translation anyway.

Okay, what about the modified const correct version in the attachment?

[djcj]

That worked! It helped me to optimize my code, thanks.

[Karl Harbinger]

I think I'm done with the program. Can I advertise it somehow so it get's more attention? https://github.com/darealshinji/fltk-dialog

[Duncan Gibson]

> I think I'm done with the program. Can I advertise it somehow so it
> get's more attention? https://github.com/darealshinji/fltk-dialog

Well I've downloaded it and been able to build it in /tmp
but as there is no documentation I have no idea what it does
apart from the options listing from fltk-dialog --help

Maybe you need to expand README.md or include a manual page?

Or maybe I'm just being thick...

D.


This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

[Karl Harbinger]

Usage is similar to that of Zenity: https://help.gnome.org/users/zenity/stable/
But adding my own documentation is probably a good idea.

[Ian MacArthur]

On Mon Dec 19 2016 15:53:01, Karl Harbinger wrote:

Usage is similar to that of Zenity: https://help.gnome.org/users/zenity/stable/
But adding my own documentation is probably a good idea.

I think the “usual" thing to do would be to create a page for it in the links pages http://www.fltk.org/links.php

Though whether anybody ever looks at at the links pages or not I really can not tell!

And, as noted, some docs would probably be a popular addition!

Cheers,

-- 

Ian

[Karan Ahuja]

wow.

i need the forms dialog.

will try it out as i come to need it.

cheers,

karan

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Karl Harbinger]

I've started to document the commands in the wiki: https://github.com/darealshinji/fltk-dialog/wiki

[Greg Ercolano]

On 12/22/16 10:23, Karl Harbinger wrote:
> I've started to document the commands in the wiki: https://github.com/darealshinji/fltk-dialog/wiki

I've had to write one of these back in the early 2000's for the
company I work for (commercial software).

Some advice: I allowed stdin (or optionally, a file) to allow the user
to specify the form template, and also a separate file to allow the
defaults to be specified and saved (so that the next time the form opens,
the user's last settings could reappear in the form).

In my case the program is called 'input', so one could use a shell script
to bring up the interface with something like:

input -uifile - << EOF

First Name: ____________
Last Name: _______________________

Tel#: _______________________
Date: _______________________

Notes: _______________________________________________
_______________________________________________
_______________________________________________

<<CANCEL>> <<SUBMIT>>
EOF

..which would open a window with those field prompts, and includes
"cancel" and "submit" buttons. The ascii art defined the field
widths and layout placement.

It writes out the form's values as key/value pairs, where the key names
were the prompts with the spaces removed, e.g. "First Name:" would become
the keyname "FirstName", and the values were all strings.
Multiline values for fields were allowed too, by just repeating
the key name for each line in the multiline field, e.g.

Notes: value for line 1..
Notes: value for line 2..
Notes: value for line 3..

Afraid I can't release the source code, as the company owns this program,
but the docs are here, in case you're looking for ideas on what to do.

The following documents the more verbose 'command' technique to define
the window size, input fields, buttons, etc.
http://seriss.com/rush.103.00/input/index.html

I also later added an 'ascii art' way the user could define forms,
so that the vertical and horizontal arrangement could be defined
in a graphic way using ascii. So for example this 'ascii art':

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

Job Title: ______________ ?
Scene Path: ____________________________________________ ? Browse"*.{ma,mb}"
Project Path: ____________________________________________ ? Browse"<DIR>"

Renderer: "default,maya(sw),arnold(arnold),mentalray(mr),mentalray-standalone(mi),mi-gen(mi),hardware(hw),vector(vr),renderm
Threads: "1,2,3,4,all,_" ?


= Frames: ______________ ?
= Batch Frames: ______________ ? |= Batch Clip: "yes,no" ?


Max Time: "00:00:00,00:05:00,00:10:00,00:30:00,01:00:00,01:30:00,02:00:00,02:30:00,03:00:00,_" ?
MaxTimeState: "Que,Fail,Done,Hold" ?

Cpus: ___________________________________________________ ? <ShowCpus>
___________________________________________________
___________________________________________________

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

So basically the width of the underbar lines defines the width of the fields,
and the vertical arrangement defined the vertical position of the fields.

The above ascii art ends up creating an FLTK UI that looks like this:
http://seriss.com/rush.103.00/submit-maya/index.html

There's some meta tags not shown in the above to define e.g. the size
of the window, the title, and how to define different tabs for a form
with multiple pages.

For that meta data, I chose to use little angle brackets to set those values:

<<WINDOW WIDTH=720>>
<<PROMPT X=160 COLWIDTH=334>>
<<TITLE>> "Rush Maya Submit"
<<TAB>> "Main"
..ascii art form goes here..
<<ENDPAGE>>
<<TAB>> "Maya"
..ascii art form for this new tab goes here..
<<ENDPAGE>>
..etc..

So this all defined relatively complex input forms, in some cases
allowing the user to hit buttons in the form that updated the form,
invoking the same script that created it, in order to add some logic
to change values in the form procedurally, based on things the user
typed in so far. When the user hit this button, the form window would
remain open, but saved out the key/value pairs to a tmp file, and invoked
the script with a special -update flag, so the script would load the
key/value pairs, make changes to the file, and resave, and exit. The
main program would then load the changes, and update the form on the
screen.

This allowed for fairly complex behavior, much like callbacks.

Anyway, FYI, depending on how complicated you want to get with this thing.
I needed all these features for the multi platform product I was working on
(still used to this day), where the scripting languages built around it can
be anything from perl to python, or even sh/csh scripts.

[Karl Harbinger]

Wow, this is really, really nice. I don't mind my program to be a bit "bloated" with such features.
I already added a way to disable unwanted features using preprocessor macros.
I just don't know if my programming skills are good enough yet to write something this complex.

Am Donnerstag, 22. Dezember 2016 20:30:56 UTC+1 schrieb Greg Ercolano:

On 12/22/16 10:23, Karl Harbinger wrote:
> I've started to document the commands in the wiki: https://github.com/darealshinji/fltk-dialog/wiki

        I've had to write one of these back in the early 2000's for the
        company I work for (commercial software).

        Some advice: I allowed stdin (or optionally, a file) to allow the user
        to specify the form template, and also a separate file to allow the
        defaults to be specified and saved (so that the next time the form opens,
        the user's last settings could reappear in the form).

  [...]

[Greg Ercolano]

On 12/23/16 07:06, Karl Harbinger wrote:
> Wow, this is really, really nice. I don't mind my program to be a bit "bloated" with such features.
> I already added a way to disable unwanted features using preprocessor macros.
> I just don't know if my programming skills are good enough yet to write something this complex.

It's not too hard.

I can give you some hints over the parts that you get stuck on.

The main programming tasks are:

o Parsing the input template file
(I like to use a combo of fgets() and sscanf() so fgets() can keep
track of the line# for reporting errors with line#s, and sscanf()
to parse each line into the separate fields)

o Creating a new FLTK widget for each template command.

o Parse a key/value file to read defaults

o Write a key/value file when the user hits 'submit' (or whatever)
and optionally run an external command (specified by the template file)
and passing it the pathname to the key/value file so it can then do
something with it.

You can add other features later, like being able to let the user
press a button or configure changes to an input field to trigger
an external event to procedurally react to the input field's contents
by first writing the key/values of the form to a temp file, running
the user's program, passing it the pathname of a temp file, wait for
it to get done, then read back the temp file and re-apply the values
to the FLTK widgets, using e.g. value() to change Fl_Input and Fl_Menu_Button
fields, and text() to change Fl_Text_Buffer/Fl_Text_Editor fields.

So be sure to design your classes so that each type of FLTK widget you
support in your template file can read+write the key/value pairs from
an external file. There's some easy tricks to doing that, again I can
guide you on my approach for doing that.

That's pretty much it; just break that out into separate programming tasks
and address them one at a time.

An easy place to start is writing the key/value pair load/save functions,
making sure to handle multiline fields and white space properly.

Then make the template reader (a variation on the key/value file reader),
and start small: support just creating a window and input field with x/y
placement.

I had some automation for keeping track of the X/Y positions by allowing
the template to either specify absolute x/y positions, or relative x/y
positions, keeping track of the 'current' x/y positions. This way it's
easy to add new fields by inserting a few lines into the template,
without having to re-adjust x/y absolute positions.

It's all relatively easy stuff, just pulling together the big picture
can be a little tricky.

But it's a satisfying task, because the effort you expend lets other
users create shell scripts in /any/ language that can create simple
FLTK interfaces and submit forms.