Hi Wiak,
Having read your latest comment in the other thread, I wonder - why don't you make the recommended behaviour default, and the legacy behaviour a switch, rather than the other way around? If people want to use gtkwialog as a drop in replacement for gtkdialog they could create a suitable alias that will provide the switch, couldn't they?
Gtkwialog project
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Yes, I prefer that to dissuade others from using old mode that causes problems on dash systems as well documented. However, that would mean that legacy gtkdialog apps would need modification to work with gtkwialog (a switch addition to indicate 'legacy mode'). I decided that proper full backward compatibility could only be achieved if, by default, gtkwialog used legacy gtkdialog mode, to help the current gtkdialog user community. The only thing I am asking for is the name change to gtkwialog to allow proper differentiation of the change; that being agreed I am happy to finally consider gtkwialog being hosted officially on Puppy sites; an alternative could be Dog sites; that doesn't really matter to me - documentation will have to stress that legacy mode is not desired for new apps.disciple wrote:Hi Wiak,
Having read your latest comment in the other thread, I wonder - why don't you make the recommended behaviour default, and the legacy behaviour a switch, rather than the other way around? If people want to use gtkwialog as a drop in replacement for gtkdialog they could create a suitable alias that will provide the switch, couldn't they?
A branch of gtkdialog is really not very acceptable for the reasons I have given - a branch has nothing really to do with the actual name change I feel is appropriate since any branch just gets reabsorbed anyway.
EDIT: Creating a branch in that fashion is therefore very much against my own will as the developer of these additions. However, the overall program is GPLv2 license copyright László Pere so on publishing I cannot force my own will in practice, only in unsatisfied comment.
In the circumstances of that, I think I may aim to host gtkwialog on Dog github if fredx181 agrees to that. Indeed, in the circumstances, that it was Dog developers only who helped with the development testing, that is more appropriate I guess. Puppy Team will of course be free to adopt or not adopt this new alternative.
wiak
Last edited by wiak on Wed 30 May 2018, 07:35, edited 1 time in total.
I am determined, by the way, that gtkwialog be my last project (though I will maintain the majority of my work). I decided to retire a couple of years ago, but had weX design at the back of my mind; that remains one of my own favourites but was shown no interest other than by the Dogs. Then, for some unknown reason, I decided to have a go at woof-CE, the result of which being makepup, but aside from one pretty much off-the-cuff remark by one Puppy Steward that project received no interest from Puppy Stewared's Team at all so not sure it was of any use in the end, which is fine, by the way, I am not complaining - may be of no use indeed. Anyway, I had always been annoyed by gtkdialog's behaviour with bash export -f and almost by chance otherwise decided to try and do something about it. A good time to retire I feel. I am happy with gtkwialog.
wiak
EDIT: Because I have allowed gtkdialog mode to be the default in gtkwialog, by the way, in system implementation/install there is no practical problem anyway. If Puppy want to create a dotpet of gtkwialog and call that gtkdialog and rename it as you will internally, it will work out-of-the-box as if it is legacy gtkdialog. So it is not even necessary to have gtkdialog as symlink to gtkwialog on Puppy systems. And since the Dogs are officially considered as being under the Puppy umbrella, hosting gtkwialog on the Debian Dog Organisation github site will keep it in-house anyway.
wiak
EDIT: Because I have allowed gtkdialog mode to be the default in gtkwialog, by the way, in system implementation/install there is no practical problem anyway. If Puppy want to create a dotpet of gtkwialog and call that gtkdialog and rename it as you will internally, it will work out-of-the-box as if it is legacy gtkdialog. So it is not even necessary to have gtkdialog as symlink to gtkwialog on Puppy systems. And since the Dogs are officially considered as being under the Puppy umbrella, hosting gtkwialog on the Debian Dog Organisation github site will keep it in-house anyway.
Temporary download links to the, hopefully and expected, final for-testing-only versions of gtkwialog can now be found in first post of this thread:
http://www.murga-linux.com/puppy/viewto ... 434#993434
I will begin work of tidying up and publishing the source code repository of this gtkwialog, gtkdialog fork, within the next day, or two.
The foot of post four of this thread contains some very basic programs you can use should you wish to begin tests of this program:
http://www.murga-linux.com/puppy/viewto ... 443#993443
wiak
http://www.murga-linux.com/puppy/viewto ... 434#993434
I will begin work of tidying up and publishing the source code repository of this gtkwialog, gtkdialog fork, within the next day, or two.
The foot of post four of this thread contains some very basic programs you can use should you wish to begin tests of this program:
http://www.murga-linux.com/puppy/viewto ... 443#993443
wiak
Possibly a better solution is to create symlink. I don't care whether the symlink is gtkdialog>>gtkwialog or vise-versa but this would eliminate any new and perhaps unnecessary CLI switches and would make gtkwialog a drop in replacement for gtkdialog. Any script requiring the gtkwialog mods can and should be called with the 'gtkwialog' exec; legacy scripts called with 'gtkdialog'.disciple wrote:Hi Wiak,
Having read your latest comment in the other thread, I wonder - why don't you make the recommended behaviour default, and the legacy behaviour a switch, rather than the other way around? If people want to use gtkwialog as a drop in replacement for gtkdialog they could create a suitable alias that will provide the switch, couldn't they?
I am not much of a C programmer but I did manage to do something similar with netmon_wce (to enable wireless polling by default), which @wiak you are quite familiar.
IMHO this could be the best solution and it would be up to a distro builder to adopt gtkwialog or not.
Cheers.
Puppy Linux Blog - contact me for access
Well, I'm presuming you are meaning like symlinks to busybox. That could be used to eliminate commandline switches certainly, though I'm not sure what is wrong with commandline switches anyway. (edit: existing gtkdialog sources already includes code for using commandline switches for other modes, such as debug, which made the additonal switch code addition trivial and straightforward.) There being three modes all of which could be used by default would mean three symlinks. As things stand gtkwialog is a drop in replacement for gtkdialog either by renaming the program or via one symlink (gtkdialog -> gtkwialog, simple as that).01micko wrote:Possibly a better solution is to create symlink. I don't care whether the symlink is gtkdialog>>gtkwialog or vise-versa but this would eliminate any new and perhaps unnecessary CLI switches and would make gtkwialog a drop in replacement for gtkdialog. Any script requiring the gtkwialog mods can and should be called with the 'gtkwialog' exec; legacy scripts called with 'gtkdialog'.disciple wrote:Hi Wiak,
Having read your latest comment in the other thread, I wonder - why don't you make the recommended behaviour default, and the legacy behaviour a switch, rather than the other way around? If people want to use gtkwialog as a drop in replacement for gtkdialog they could create a suitable alias that will provide the switch, couldn't they?
Seems like overkill having to tinker with the code and use time on that further 'multiple-symlink-required' change to be honest, which from my understanding of what you said would require system symlinks:
gtkdialog -> gtkwialog
gtkwialog_mode1 -> gtkwialog
gtkwialog_mode2 -> gtkwialog
Or perhaps I have misunderstood your suggestion?
No new programs have been written to use new modes of gtkwialog as yet so no switches used unnecessarily one way or the other.
wiak
Last edited by wiak on Wed 30 May 2018, 08:56, edited 1 time in total.
Anyway, I've been working intensely on this code for some time and was happy to reach an endpoint I am happy with so I can rest for a while.
I will post the repository on Debian Dog Organization site and it is of course GPLv2 per the license requirements. Distribution makers can use or do what they want accordingly. Easiest is just use gtkdialog -> gtkwialog; if you simply want it as a drop in replacement for legacy gtkdialog operation nothing else needs to be done.
wiak
I will post the repository on Debian Dog Organization site and it is of course GPLv2 per the license requirements. Distribution makers can use or do what they want accordingly. Easiest is just use gtkdialog -> gtkwialog; if you simply want it as a drop in replacement for legacy gtkdialog operation nothing else needs to be done.
wiak
OK, enjoy a rest.wiak wrote:Anyway, I've been working intensely on this code for some time and was happy to reach an endpoint I am happy with so I can rest for a while.
I will post the repository on Debian Dog Organization site and it is of course GPLv2 per the license requirements. Distribution makers can use or do what they want accordingly. Easiest is just use gtkdialog -> gtkwialog; if you simply want it as a drop in replacement for legacy gtkdialog operation nothing else needs to be done.
wiak
I'll delete the branch I made since you aren't interested and that can be the end of it for me as far as I'm involved.
Cheers.
Puppy Linux Blog - contact me for access
deb packages released
debian packages for 32bit and 64bit gtkwialog released (currently attached to first post of this thread):
http://www.murga-linux.com/puppy/viewto ... 434#993434
As per XenialDog64 these install to /usr/bin
#CHANGES: Minor gtkwialog --version info.
Once you are satisfied they are working correctly you no longer need legacy gtkdialog installed since gtkwialog is fully backwards compatible. Instead you can make /usr/bin/gtkdialog a symlink to gtkwialog since, by default, gtkwialog has been arranged to be a drop-in replacement. NOTE WELL however that such change is at your own risk until the program has been fully tested. However, in my tests the program has operated correctly (USUAL DISCLAIMERS APPLY REGARDING NO GUARANTEES OF FIT FOR PURPOSE)
When writing new programs it is highly recommended, however, that you start gtkwialog with its -b switch for synchronous blocking mode (meaning control won't return to the dialog until command is completed - which is the same as legacy gtkdialog though gtkwialog has advantages as described below). Or use switch -a, instead, if you happen to want asynchronous non-blocking mode (meaning instant return to the dialog leaving the started command running in the background).
Using the -b mode (and the -a mode) has the huge benefit that it allows you to use bash with export -f function_name syntax and the program still operate correctly when system shell is dash (or busybox ash, for example). i.e. the resulting bash/gtkwialog program utilities will be compatible with systems, such as Debian, running dash for /bin/sh, as well as for distributions like Puppy that use bash for /bin/sh
Note that a couple of simple test scripts can be found at the bottom of the following linked post 4 of this thread (along with a somewhat technical explanation of the <action>command_string modes gtkwialog brings):
http://www.murga-linux.com/puppy/viewto ... 443#993443
Over the next day or two, I'm working on tidying-up and uploading the gtkwialog source code to Debian Dog Organization page at:
https://github.com/DebianDog/gtkwialog
The program is GPLv2.
wiak
http://www.murga-linux.com/puppy/viewto ... 434#993434
As per XenialDog64 these install to /usr/bin
#CHANGES: Minor gtkwialog --version info.
Once you are satisfied they are working correctly you no longer need legacy gtkdialog installed since gtkwialog is fully backwards compatible. Instead you can make /usr/bin/gtkdialog a symlink to gtkwialog since, by default, gtkwialog has been arranged to be a drop-in replacement. NOTE WELL however that such change is at your own risk until the program has been fully tested. However, in my tests the program has operated correctly (USUAL DISCLAIMERS APPLY REGARDING NO GUARANTEES OF FIT FOR PURPOSE)
When writing new programs it is highly recommended, however, that you start gtkwialog with its -b switch for synchronous blocking mode (meaning control won't return to the dialog until command is completed - which is the same as legacy gtkdialog though gtkwialog has advantages as described below). Or use switch -a, instead, if you happen to want asynchronous non-blocking mode (meaning instant return to the dialog leaving the started command running in the background).
Using the -b mode (and the -a mode) has the huge benefit that it allows you to use bash with export -f function_name syntax and the program still operate correctly when system shell is dash (or busybox ash, for example). i.e. the resulting bash/gtkwialog program utilities will be compatible with systems, such as Debian, running dash for /bin/sh, as well as for distributions like Puppy that use bash for /bin/sh
Note that a couple of simple test scripts can be found at the bottom of the following linked post 4 of this thread (along with a somewhat technical explanation of the <action>command_string modes gtkwialog brings):
http://www.murga-linux.com/puppy/viewto ... 443#993443
Over the next day or two, I'm working on tidying-up and uploading the gtkwialog source code to Debian Dog Organization page at:
https://github.com/DebianDog/gtkwialog
The program is GPLv2.
wiak
They are part of gtk, and you can't add more just by putting images somewhere.
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Yes.disciple wrote:They are part of gtk, and you can't add more just by putting images somewhere.
https://developer.gnome.org/gtk2/stable ... Items.html
You can register your own icons though. This is pinstall from weX:
Code: Select all
#!/bin/sh
gtk-update-icon-cache -f -i /usr/share/icons/hicolorCode: Select all
<window title="weX" icon-name="wex48" resizable="false">Code: Select all
<button>
<input file icon="wex48"></input>
<variable>WHATEVER</variable>
<action>command_string</action>
</button>In wex, though, button icons are in /usr/local/share/pixmaps/wex
They are used directly via their filepath:
Code: Select all
<button tooltip-text="$(gettext 'RECORD/CONTINUE RECORD')">
<input file>/usr/local/share/pixmaps/wex/wex_record.png</input>I mentioned that you cannot mix -a and -b modes of gtkwialog. That is not really an issue since most of the time -b (for blocking) would be the best mode to use. However -a (for asynchronous non-blocking) mode is super-efficient for starting up a program effectively in the background, without needing any shell process to also be called for job control purposes (though programmer always has the choice).
Whilst I thus intend the current commandline switch selectable operation 'modes' to remain stable in terms of future compatability, I am looking into adding an optional facility to start up a program in non-blocking background mode even when -b mode otherwise chosen. Then we will get benefit of both at same time - no shell process command required yet with ability to either block till a command finishes before returning control to the dialog or to return immediately (leaving command program fork/exec'd and running in its own process) like with overall -a mode.
I'll only try that alteration in a testing branch however, and it will not at all effect the current gtkwialog operation anyway. i.e. I will ensure the interface remains stable for any additions ensuring full backwards compatibility.
-------------------------
In short explanation:
Neither -a nor -b modes involve running any shell as part of processing an <action>command_string</action>. But one of the jobs of a shell is to provide job control (shell uses a symbol & in relation to that). So if you want to background a process when currently using the gtkwialog -b <action> mode, you would need to start up a shell (since the command_string you give is what you get...):
where, command, might for example be leafpad.
whereas, you can fork/exec a process in non-blocking -a mode simply with:
No & symbol being required (and wouldn't mean anything anyway since no shell being used to run this command). In this -a mode once command is fork/exec'd in this way, control returns immediately to the dialog (i.e. non-blocking) so command effectively 'runs in the background' albeit without needing any controlling shell.
Wouldn't it be nice when using the -b mode to also be able to avoid the need for starting up a shell to run a process in its own space (by which I mean fork/exec'd and not blocking). A method for doing that is what I plan to implement, but again it won't upset any current behaviours in my plan (will be using & symbol or similar to simply say use -a mode on this particular <action>. When no shell process is being run the & symbol doesn't mean anything special anyway...).
Funny thing about legacy gtkdialog, if most people were like me, they probably didn't realise a /bin/sh -c process was being used with <action>command_strings</action>. Rather, as programmers, we just came to learn by word of mouth and trial and error, what worked and what didn't (to some extent). Big shock therefore was that bash -f export didn't work with <action>bash -c calls if underlying system shell dash or ash... There would be some other not well understood subtleties. In other words, as I've said before, with legacy gtkdialog, <action>bash -c function_name</action>, for example doesn't mean what it says (bash -c function_name). Rather it means:
/bin/sh -c "bash -c function_name", which is really quite different (i.e. with old gtkdialog you don't really get what you put in... And similarly, other actions don't really do what the visible action command_string syntax alone suggests (you have to always remember that hidden /bin/sh -c with legacy gtkdialog (and some of its negative consequencies).
wiak
Whilst I thus intend the current commandline switch selectable operation 'modes' to remain stable in terms of future compatability, I am looking into adding an optional facility to start up a program in non-blocking background mode even when -b mode otherwise chosen. Then we will get benefit of both at same time - no shell process command required yet with ability to either block till a command finishes before returning control to the dialog or to return immediately (leaving command program fork/exec'd and running in its own process) like with overall -a mode.
I'll only try that alteration in a testing branch however, and it will not at all effect the current gtkwialog operation anyway. i.e. I will ensure the interface remains stable for any additions ensuring full backwards compatibility.
-------------------------
In short explanation:
Neither -a nor -b modes involve running any shell as part of processing an <action>command_string</action>. But one of the jobs of a shell is to provide job control (shell uses a symbol & in relation to that). So if you want to background a process when currently using the gtkwialog -b <action> mode, you would need to start up a shell (since the command_string you give is what you get...):
Code: Select all
<action>sh -c "command &"</action>whereas, you can fork/exec a process in non-blocking -a mode simply with:
Code: Select all
<action>command</action>Wouldn't it be nice when using the -b mode to also be able to avoid the need for starting up a shell to run a process in its own space (by which I mean fork/exec'd and not blocking). A method for doing that is what I plan to implement, but again it won't upset any current behaviours in my plan (will be using & symbol or similar to simply say use -a mode on this particular <action>. When no shell process is being run the & symbol doesn't mean anything special anyway...).
Funny thing about legacy gtkdialog, if most people were like me, they probably didn't realise a /bin/sh -c process was being used with <action>command_strings</action>. Rather, as programmers, we just came to learn by word of mouth and trial and error, what worked and what didn't (to some extent). Big shock therefore was that bash -f export didn't work with <action>bash -c calls if underlying system shell dash or ash... There would be some other not well understood subtleties. In other words, as I've said before, with legacy gtkdialog, <action>bash -c function_name</action>, for example doesn't mean what it says (bash -c function_name). Rather it means:
/bin/sh -c "bash -c function_name", which is really quite different (i.e. with old gtkdialog you don't really get what you put in... And similarly, other actions don't really do what the visible action command_string syntax alone suggests (you have to always remember that hidden /bin/sh -c with legacy gtkdialog (and some of its negative consequencies).
wiak
Last edited by wiak on Fri 01 Jun 2018, 05:20, edited 1 time in total.
Aside from the above post idea, my plan is to now create, possibly slightly improved, versions of cast2chrome, precord, and wex, (in that order since I am using cast2chrome on a daily basis myself) that use gtkwialog -b mode such that these will be able to be run in Debian with dash, or Slitaz with ash. Not a big job. Then I'll take a look at some of the Dog utils and tackle some of them if necessary (for my own use at least) in case no-one else finds time for that or chooses not to.
wiak
wiak
detaching stdout of <action> commands
Detaching stdout of <action> commands (issue when gtkdialog or gtkwialog output is being assigned to a variable via command-substitution):
An interesting practical and illustrative example discussed on Gtkdialog Tips thread; I've posted gtkwialog related info about it there:
http://www.murga-linux.com/puppy/viewto ... 141#994141
An interesting practical and illustrative example discussed on Gtkdialog Tips thread; I've posted gtkwialog related info about it there:
http://www.murga-linux.com/puppy/viewto ... 141#994141
I've translated quite a few of the gtkdialog examples from zigbert's Gtkdialog Tips thread to use gtkwialog -b mode.
I did it in a hurry so haven't checked if my converted versions will also all run on systems with dash as system shell - but most will; I think a couple might need a few more tweeks. Find them in post 4 of this thread here. Hopefully they will help you convert your own programs should you want to try running them on distributions that have dash or ash or bash as their system shell:
http://www.murga-linux.com/puppy/viewto ... 443#993443
I'm going to make a start converting some of my own programs now.
wiak
I did it in a hurry so haven't checked if my converted versions will also all run on systems with dash as system shell - but most will; I think a couple might need a few more tweeks. Find them in post 4 of this thread here. Hopefully they will help you convert your own programs should you want to try running them on distributions that have dash or ash or bash as their system shell:
http://www.murga-linux.com/puppy/viewto ... 443#993443
I'm going to make a start converting some of my own programs now.
wiak
Hi wiak, Just want to say (again) that you've done a great job, not only your discovery resulting in creating gtkwialog, but also the excellent documentation, examples, technical background, etc... etc... Hats Off !
One thing I wonder about, looking at your DebianDog/gtkwialog repository:
I see 7 commits from you containing change of Readme and some more, but are the differences for gtkwialog compared to original gtkdialog there ?
Fred
One thing I wonder about, looking at your DebianDog/gtkwialog repository:
I see 7 commits from you containing change of Readme and some more, but are the differences for gtkwialog compared to original gtkdialog there ?
Fred
Not yet, Fred, been too busy and since considering minor code tweeks and not actually using github during my developments I'm not quite ready to push the source code there yet. But will happen soon enough. There is one particular area of code in gtkdialog I want to double-check how it works, just in case I've missed something, and also I want to convert a couple of my apps just as a double check. I've been converting precord, which has quite a lot of bash-related export code so a good test - haven't quite finished it yet. After that I'll push up the source code since it will be ready for proper testing and recompiling and pull requests and so on.fredx181 wrote: One thing I wonder about, looking at your DebianDog/gtkwialog repository:
I see 7 commits from you containing change of Readme and some more, but are the differences for gtkwialog compared to original gtkdialog there ?
pu
Fred
wiak
What an amazing job Thunor did of re-factoring the original gtkdialog code. I've been reading through some of it and the amount of work he did is far more enormous than any non-C programmer would imagine. It was far from just better implementing the Widgets to more closely match their inherent GtkDialog system capabilities. It would take a near obsession to learn the whole inner-workings of gtkdialog that Thunor obviously did.
My addition is simple, but is hopefully very useful for the very small effort I needed to expend implementing it. Most of my effort was simply background research to try find out why bash -f export didn't work well with gtkdialog - and looking at YAD code gave me the simple solution to that - just a small number of changes needed to gtkdialog itself over a very few files and thus with predictable results since nothing else needed to be touched (so far anyway... luckily).
Just a pity, I feel, that gtkdialog hadn't been written to use vbox and hbox constructions with simple curly bracket groupings (instead of pseudo xml tags) as used in IUP (with Lua and the other languages it supports), which is much nicer to program in (simpler, easier to read, supports comments, and harder to make mistakes in).
wiak
My addition is simple, but is hopefully very useful for the very small effort I needed to expend implementing it. Most of my effort was simply background research to try find out why bash -f export didn't work well with gtkdialog - and looking at YAD code gave me the simple solution to that - just a small number of changes needed to gtkdialog itself over a very few files and thus with predictable results since nothing else needed to be touched (so far anyway... luckily).
Just a pity, I feel, that gtkdialog hadn't been written to use vbox and hbox constructions with simple curly bracket groupings (instead of pseudo xml tags) as used in IUP (with Lua and the other languages it supports), which is much nicer to program in (simpler, easier to read, supports comments, and harder to make mistakes in).
wiak
One, apparently rare, limitation found using gtkwialog on systems that do not use bash as the underlying system shell /bin/sh
(and legacy gtkdialog has that limitation anyway)
I spent one hour tonight converting Precord to use gtkwialog -b. That went fine and worked perfectly when underlying system shell was bash (which is no big deal since old version worked under legacy gtkdialog too with bash as system shell...).
But when I changed /bin/sh to be dash, the legacy gtkdialog version simply couldn't work at all because Precord is written in bash and uses a great many bash export -f functions. That being of course known and expected... But:
Though all the <action> contructs in the gtkwialog -b version of Precord can all find these functions, there is one other construct that happens to be used in current Precord that also calls up one of the bash functions and that is the <input> tag in one of the entry widgets (which calls bash function DateFile1). Unfortunately, none of the code I have added helps with that <input> tag situation, so that is a current limitation. Indeed, despite studying the code, I frankly do not yet know how <input> calls up exported functions - it is certainly not via the system() call.
I can only surmise, from the complex code involved, that it directly reads the function code from the shell environment, via perhaps a gtk library call, and then sends that function code to be processed via the mechanisms I have optionally modified. If so, legacy gtkdialog <input> command processing may expect a shell to interpret the function via system(), which does of course only work if underlying system shell is bash. So calling bash functions from <input> constructs certainly won't work with legacy gtkdialog.
Unfortunately, if my surmise turns out to be correct, then because the execution of that bash exported function requires an instance of bash to be running, which isn't the case with the gtkwialog -a or -b mod glib async or sync calls either (which don't call up any shell process) then that construct simply cannot work whichever mode is used when bash is not the underlying system shell. It is a small limitation, but one that has to be borne in mind.
In summary:
Though gtkwialog -b (or -a) mode can be used to convert many or even most legacy gtkdialog apps to work with dash, it does currently have at least this one newly found limitation:
The easiest way around this for new programs is to never use exported bash functions in <input> tags.
Example of code that will not work when dash is the system shell:
Here is a simple exemplar program that will work using /bin/sh as bash but not when /bin/sh is dash, despite gtkwialog -b being used. Doesn't work with legacy gtkdialog either of course, when /bin/sh is dash:
I'll write more on this limitation if I find more or any solution in code, but truthfully I think it probably has to be accepted as a limitation of both gtkdialog and gtkwialog. Fortunately, it is a limitation that can easy be avoided in the case of gtkwialog; not gtkdialog which cannot work at all with dash as system shell when bash exported functions being used anywhere.
Hopefully you understand what I'm talking about, but if not, just accept that as one limitation that has to be avoided if writing dash compatible apps in this manner.
I'm now looking through some other familiar bash/gtkdialog to see which will suffer from this limitation. I'll list any I've looked at here:
1. peasywifi, does not use <input> tags in the above manner so should convert nicely with gtkwialog -b for use with underneath dash shell (though its shebang would also need changed to #!/bin/bash for the exported functions to work.
2. My program cast2chrome should also convert nicely.
3. As fredx181 has I believe already proved, debdog-install (and xenialdog-install) should convert nicely (don't think these call exported functions anyway)
4. My program domyfile should convert nicely.
5. Despite being derived from Precord (albeit a long chain of ancestry) it looks like weX will convert nicely.
6. peasypdf should convert nicely (and probably most peasy apps).
7. ffconvert looks like it will convert okay.
Hmmm... I can't find any other problematic ones... only Precord... trust me to try to convert that first!
Quite a number of old Puppy util/apps don't use bash export -f at all, so they shouldn't generally need to be converted at all - just use gtkwialog in legacy mode (needs no switch for that).
Oh well, time will tell - I'll try converting cast2chrome next and come back to finish Precord later. If there is any particular app you'd like me to check (and maybe even convert), just let me know.
All going well with a couple of conversions in the next few days, I'll upload the source code to the DD organization github repository thereafter since I'm not planning any non-compatible changes if most basically converting fine.
wiak
(and legacy gtkdialog has that limitation anyway)
I spent one hour tonight converting Precord to use gtkwialog -b. That went fine and worked perfectly when underlying system shell was bash (which is no big deal since old version worked under legacy gtkdialog too with bash as system shell...).
But when I changed /bin/sh to be dash, the legacy gtkdialog version simply couldn't work at all because Precord is written in bash and uses a great many bash export -f functions. That being of course known and expected... But:
Though all the <action> contructs in the gtkwialog -b version of Precord can all find these functions, there is one other construct that happens to be used in current Precord that also calls up one of the bash functions and that is the <input> tag in one of the entry widgets (which calls bash function DateFile1). Unfortunately, none of the code I have added helps with that <input> tag situation, so that is a current limitation. Indeed, despite studying the code, I frankly do not yet know how <input> calls up exported functions - it is certainly not via the system() call.
I can only surmise, from the complex code involved, that it directly reads the function code from the shell environment, via perhaps a gtk library call, and then sends that function code to be processed via the mechanisms I have optionally modified. If so, legacy gtkdialog <input> command processing may expect a shell to interpret the function via system(), which does of course only work if underlying system shell is bash. So calling bash functions from <input> constructs certainly won't work with legacy gtkdialog.
Unfortunately, if my surmise turns out to be correct, then because the execution of that bash exported function requires an instance of bash to be running, which isn't the case with the gtkwialog -a or -b mod glib async or sync calls either (which don't call up any shell process) then that construct simply cannot work whichever mode is used when bash is not the underlying system shell. It is a small limitation, but one that has to be borne in mind.
In summary:
Though gtkwialog -b (or -a) mode can be used to convert many or even most legacy gtkdialog apps to work with dash, it does currently have at least this one newly found limitation:
I will have to therefore make a slight modification to Precord to workaround that remaining dash-related issue.you cannot call bash functions from <input> tags, only from <action> tags if underlying system shell is dash. There may be similar limitation; just remember -a and -b modes are specifically mainly related to <action>tag commandline_string opertion
The easiest way around this for new programs is to never use exported bash functions in <input> tags.
Example of code that will not work when dash is the system shell:
Here is a simple exemplar program that will work using /bin/sh as bash but not when /bin/sh is dash, despite gtkwialog -b being used. Doesn't work with legacy gtkdialog either of course, when /bin/sh is dash:
Code: Select all
#! /bin/bash
hello (){
echo "hello world"
}
export -f hello
export MAIN_DIALOG='
<vbox>
<entry>
<variable>ANYTHING</variable>
<input>hello</input>
</entry>
</vbox>
'
gtkwialog -b --program=MAIN_DIALOGHopefully you understand what I'm talking about, but if not, just accept that as one limitation that has to be avoided if writing dash compatible apps in this manner.
I'm now looking through some other familiar bash/gtkdialog to see which will suffer from this limitation. I'll list any I've looked at here:
1. peasywifi, does not use <input> tags in the above manner so should convert nicely with gtkwialog -b for use with underneath dash shell (though its shebang would also need changed to #!/bin/bash for the exported functions to work.
2. My program cast2chrome should also convert nicely.
3. As fredx181 has I believe already proved, debdog-install (and xenialdog-install) should convert nicely (don't think these call exported functions anyway)
4. My program domyfile should convert nicely.
5. Despite being derived from Precord (albeit a long chain of ancestry) it looks like weX will convert nicely.
6. peasypdf should convert nicely (and probably most peasy apps).
7. ffconvert looks like it will convert okay.
Hmmm... I can't find any other problematic ones... only Precord... trust me to try to convert that first!
Quite a number of old Puppy util/apps don't use bash export -f at all, so they shouldn't generally need to be converted at all - just use gtkwialog in legacy mode (needs no switch for that).
Oh well, time will tell - I'll try converting cast2chrome next and come back to finish Precord later. If there is any particular app you'd like me to check (and maybe even convert), just let me know.
All going well with a couple of conversions in the next few days, I'll upload the source code to the DD organization github repository thereafter since I'm not planning any non-compatible changes if most basically converting fine.
wiak