Gtkwialog continuing development information

[wiak]

Okay, I start a new thread to allow me to continue providing details of my continuing personal development of this work.

I continue to reserve, however, the right on whether or not to make any public release versions.

Having no other option available to me on this forum, I started this new thread to provide a temporary means by which I can continue to detail developments of work I have undertaken for my own use on my personal gtkwialog fork of gtkdialog. The thread in which I was developing gtkwialog for public use now contains out of date and erroneous information, which I have asked to access so that I can update it and replace the old material with new development work.

Only technical discussions related to gtkwialog (and not gtkdialog) on this thread please. Also I would be grateful if you please only contribute positively (which includes bug reports and performance/functionality issues), or don't post to this thread at all is fine. Only the old pre-alpha for-testing-only binaries remain (unfortunately) available - though the old test results on these remain useful for my current personal gtkwialog development.
In particular, if you have something against gtkwialog, please express such opinions in threads of your own elsewhere, which I won't be responding to.

I mainly use all threads like this one for my own documentation purposes, though I also keep backup copies in case anything ever happens to the forum.

I won't be adding to this first new post for a while though. Having now some experience at converting Puppy apps to work on dash systems via gtkwialog, I'm adding some extra functionality to make the conversion process even more convenient (whilst keeping it 100% backwards compatible with the functionality I previously added and with legacy gtkdialog). Come back to this thread in a few weeks time maybe, if you are interested in the work, because I expect it to be at least that long before I publish more about it.

[Assuming any later public release] The final or should I say first ready to distribute version only will be added to DebianDog Organisation gtkwialog repository (which at that stage will include binary and source code) along with hopefully many converted traditional Puppy apps, either via their original author's permission, or forked if necessary to allow them to run when dash is the underlying system shell.

I won't be provided links to any test binaries this time out since that turned out to be a mistake. So downloads of any sort for testing only or actual distribution will only be available once I am myself satisfied with the final results of my own testing and have updated the github repository accordingly. The prealpha binaries, which were for early testing only, and not to be considered in any way as official releases, remain on the old locked thread. I would like to remove these now so please bear that in mind.

Work will also now recontinue in the temporarily suspended Precord and Cast2chrome, which depend on gtkwialog.

wiak

[darry19662018]

Wiak I wish you the sincerest best with this - your attention to detail and wanting perfection in your work is inspiring.

[wiak]

I've expanded the [-a] and [-b] mode syntax of next version of gtkwialog to be eventually published to allow mixing of these blocking and non-blocking modes in the one dialog and some of the addition also simply for the convenience of the programmer. In particular, in present testing version:

Inside the <action>commandstring</action> tags the programmer can now use -b at start of any commandstring to indicate -b mode is to be used for that particular action (even if main dialog is specified as being in -a mode or in legacy gtkdialog mode). Similarly, -a can alternatively be specified at start of any such commandstring.

In addition, simply as a convenience, the programmer can use

-bs to indicate use -b mode but interpret the rest of the commandstring with /bin/sh -c
-bb to indicate use -b mode but interpret the rest of the commandstring with /bin/bash -c

-as to indicate use -a mode but interpret the rest of the commandstring with /bin/sh -c
-ab to indicate use -a mode but interpret the rest of the commandstring with /bin/bash -c

These are tiny changes that involve hardly any additional code, and full backwards compatibility with previous gtkwialog operation is being guaranteed, as is 100% compatible legacy gtkdialog mode; accordingly, gtkdialog can always simply be made a symbolic link to gtkwialog, which means that older gtkdialog Puppy apps will run 100% exactly as they did under legacy gtkdialog.

None of these very newest additions to my latest gtkwialog under development are set in concrete however. I'm just indicating my strong intention that the -a and -b mode behaviour of original gtkwialog testing will remain always stable.

In addition to these under-development versions I plan to experiment with a gtkwialog version that includes UNIX system message queues mode and also TCP/IP socket capability (including UDP connectionless and TCP connection-oriented) to allow remote client/service control, amongst other uses, where that is desired. I haven't decided yet if that enhanced version will ever be published for distribution.

wiak

[wiak]

Just a progress report to myself and as a note in case anyone wondered if I was still working on gtkwialog development. Yes, I am.

Currently implemented mixed (legacy, -b, -a) mode dialogs, so programmer can pick and choose which mode they want for different <action>commandstrings in their dialog (previously a dialog could only use either a, b or legacy mode; not a chosen mix).

At least temporarily dropped the convenience idea: -bs, -bb, -as, -ab; think the idea is a bit messy, and certainly not essential; however, I'm still thinking about it.

Actually, in theory, I think I know how to make a version with an option that could run legacy gtkdialog apps, on dash system, without any mods at all (aside from using the appropriate as yet unwritten new gtkwialog mode) but I'm not sure there are enough good legacy gtkdialog apps to make so much legacy support worthwhile; better really to write/re-write new apps... and avoid legacy mode altogether since that dream-mode actually involves quite a lot of addon (messy) code that I don't actually like to support... better to use -a, or -b modes in practice.

In the meantime, I have figured out how <input>commandstring works; was actually easy but hadn't looked at it in detail before. So, in theory, I can now arrange -a and -b gtkwialog modes to work there now too (final piece of puzzle concerning getting gtkwialog working via bash -c on dash-based systems); only problem is that there are a lot of source code files involved in the change, so will take me a while to implement, assuming I get round to it.

Realistically, gtkwialog may be resisted and unwanted by many and never adopted other than by myself, so maybe not worth too much effort on my part, despite a certain amount of interest that the original test version generated. Current version actually fulfills my own needs (which is all I intended it for) despite not having that bash-related <input> handling code implemented, so it depends how enthusiastic I feel about spending more hours on this to complete that part.

I understand now that I probably made a mistake originally trying to develop forked gtkwialog on this forum, which resulted in some reactions that certainly limited my own enthusiasm too. I just had an old habit of recording my dev work on this forum, as an archive as much as anything, and should really have used github or similar instead and not involved Puppy forum at all. Wish I could delete the prealpha testing-only versions still though. Nevertheless, I'm tempted to 'fix' the <input>commandstring mode, despite the number of files involved, if only for the sake of some completion. But otherwise, current gtkwialog modes are sufficient for my own (slightly modified) programs to function on dash-based systems too.

Probably won't post any more about this now though, until and if I complete it to my satisfaction, which may be soon or may be a long time away.

wiak

[wiak]

Update:

In latest gtkwialog, I have now turned some theories I had into practice (though not fully packaged yet). In particular, my latest gtkwialog offers -a, -b, and legacy gtkdialog modes along with ability to mix these modes in any dialog. These additions in my personal test version were completed a while ago.

Breaking news is that I have also now implemented addition 'support legacy gtkdialog apps mode' which allows older bash/gtkdialog apps that contained bashisms to run unaltered on dash-based system such as pristine Debian. To my surprise my new code worked first time. I would still advise writing new gtkwialog apps using the -b mode since avoids forcing a shell process to be run (though programmer can always arrange that on individual basis with bash -c construct). I am pretty confident now however that my final gtkwialog will not only function as 100% gtkdialog drop-in replacement, but also allow these older gtkdialog apps to run on dash shell systems without needing any modifications (which is a huge saving in work for their programmers).

Generally speaking, gtkwialog will free up the programmer to program the apps in whatever way they prefer yet still have them (and, I believe, all existing legacy gtkdialog apps) able to run on bash or dash or ash etc based systems without needing sh linked to bash.

All I need to do now to complete this is add some selection logic to swap modes as appropriate to programmers desire, and then I just need to test, package, and incorporate in my local github repository prior to upload.

I'm going slow on this so will still take a while, but initial test of traditional precord, for example, had it working on dash linked sh without any mods required to the old code.

Unmodified legacy pfind, for example, has also now been quickly tested as working with XenialDog with dash as system shell, as has... pburn... See attached screenshots. In these tests, I am using my newest gtkwialog compile and have gtkdialog simply as a symbolic link to that.

Prior to any publication of this far more functional gtkwialog, I would like to remove my old pre-alpha gtkwialog binaries, which were stressed as for testing-only, since these should not be used for future developements (though the -a, -b and legacy modes work correctly on these old test binaries - but not the truly dash-compatible mode for old gtkdialog apps).

wiak

[fredx181]

Hi wiak,

Breaking news is that I have also now implemented addition 'support legacy gtkdialog apps mode' which allows older bash/gtkdialog apps that contained bashisms to run unaltered on dash-based system such as pristine Debian.

That is certainly great news !
My first thought was that a symlink gtkdialog > gtkwialog (and sh > dash) would be only needed.
But then I realized that there are scripts including bashisms with #!/bin/sh on top, they should be changed to #!/bin/bash, I guess.
But anyway things will be a whole lot easier, congratulations !!

Fred

[wiak]

But then I realized that there are scripts including bashisms with #!/bin/sh on top, they should be changed to #!/bin/bash, I guess.
But anyway things will be a whole lot easier, congratulations !!

Fred

Yes, can't do anything about wrong shebangs like that of course, but at least that will only apply to some creations and relatively easy to fix.

wiak

[wiak]

But then I realized that there are scripts including bashisms with #!/bin/sh on top, they should be changed to #!/bin/bash, I guess.
But anyway things will be a whole lot easier, congratulations !!

Fred

Yes, can't do anything about wrong shebangs like that of course, but at least that will only apply to some creations and relatively easy to fix.

wiak

Most programs I've previously checked already used correct #!/bin/bash shebang, but co-incidentally first one I needed to use today didn't. Oh well... minor fix and all fine as explained below.

I'm getting very close to a new release now. Been a considerable amount of work involving code changes to twenty-five gtkdialog C source code files, some of these additions being quite involved and tricky (for me anyway). Still have around 14 widget_xxx.c files to complete, but the main alterations already done and quickly tested.

Hopefully it will be appreciated that the final release will need tons of testing by developers/app-builders with so much code mods/additions/refactoring involved. Of course it is up to the legacy gtkdialog app creators, and distribution developers, whether they choose to test or use this or not. However, the chances of me being able to find bugs weeks from now, when I am no longer fresh from writing the code are low - a few weeks not writing C code and I always become very rusty at it - fine right now though, so I advise, if interested in running your apps over dash, test soon after release rather than later when I will have moved onto other priorities and project interests.

Anyway, I'm personally much closer now to having my XenialDog64 system running with a dash system shell. I use peasywifi so today temporarily modified the startup script, /root/Startup/peasywifi_auto to contain the following:

Code: Select all

env GTKWMODE=B peasywifi my_wifi_connect_name

(or could use export GTKWMODE=B for more persistent environment addition)

Unfortunately, though peasywifi is written to use bashisms (export -f) it had a /bin/sh shebang since presumed /bin/sh -> bash. Anyway, I fixed the peasywifi shebang on my system to #!/bin/bash to correctly indicate the program uses bash and on rebooting (with dash as my system shell) peasywifi successfully connected to my wifi-router.

By default, for legacy reasons, gtkwialog uses legacy gtkwialog mode which uses /bin/sh. Setting environment variable GTKWMODE=B tells the new gtkwialog to use underlying /bin/bash instead (and thus work with the likes of export -f syntax in <action> and <input> command-strings.

The latest gtkwialog actually has three mechanisms that can be used to determine the exec mode that will be used for gtkwialog command executions:

1. Lowest priority (most convenient for running legacy apps over dash system) is setting environment variable GTKWMODE as above.
2. Using a commandline argument to gtkwialog, such as -a (for glib non-blocking async), -b (for glib sync blocking), -B (for bash) or no arg for /bin/sh legacy mode takes precedence over environment variable method. Or finally,
3. (highest precedence), there is an "inline" mode, where starting an <action> or <input> commandstring with -a, -b or -B forces that mechanism (different action or input lines can thus use different modes depending what the programmer wants).

Anyway, back to making the necessary alterations/additions to the final 14 gtkdialog widget_xxx.c source files, further self-testing, and after that work on my github... Should be ready in about a week at this rate.

wiak

[fredx181]

Anyway, I fixed the peasywifi shebang on my system to #!/bin/bash to correctly indicate the program uses bash and on rebooting (with dash as my system shell) peasywifi successfully connected to my wifi-router.

Also then '/etc/init.d/rc.network-start' (part of peasywifi package) needs shebang changed to bash.
EDIT: But that's probably (not really sure) for providing wired connection at boot.

Fred

[wiak]

Anyway, I fixed the peasywifi shebang on my system to #!/bin/bash to correctly indicate the program uses bash and on rebooting (with dash as my system shell) peasywifi successfully connected to my wifi-router.

Also then '/etc/init.d/rc.network-start' (part of peasywifi package) needs shebang changed to bash.
EDIT: But that's probably (not really sure) for providing wired connection at boot.

As the script stands, yes, that's true. However, that's nothing per se to do with gtkwialog (or gtkdialog), it's just that the "if [[...]]" construct is a bashism. Since rc.network-start is a system script, and hence better if interpreted by dash (or whatever /bin/sh links to) it would be better modifying rc.network-start to as follows and keeping shebang as #!/bin/sh (i.e. simple removal of the bashism):

Code: Select all

if [ "$1" == "start" ] || [ "$1" == '' ]] ; then
/etc/rc.d/rc.network &

elif [ "$1" == "stop" ] ; then
/etc/rc.d/rc.network stop
fi

or alternatively:

Code: Select all

if [ "$1" == "start" -o "$1" == '' ] ; then
/etc/rc.d/rc.network &

elif [ "$1" == "stop" ] ; then
/etc/rc.d/rc.network stop
fi

The double-quotes round the "$1" are necessary to tell the shell its a string, but more generally also better anyway.

wiak

EDIT: Actually, I only use wifi connection myself, but I should point out that I don't think there actually is any /etc/rc.d on my xenialdog64 system, so above script won't do anything as it stands on xenialdog64 - maybe that issue has been fixed for DD Stretch and BionicDog since they were designed to use peasywifi? Need to fix on my xenialdog I guess (or maybe some newer peasywifi deb was produced and I didn't notice that when installing).

[darry19662018]

Added this to the Puppy Wiki:
http://puppylinux.org/wikka/Gtkwialog

[fredx181]

fredx181 wrote:
wiak wrote:
Anyway, I fixed the peasywifi shebang on my system to #!/bin/bash to correctly indicate the program uses bash and on rebooting (with dash as my system shell) peasywifi successfully connected to my wifi-router.


Also then '/etc/init.d/rc.network-start' (part of peasywifi package) needs shebang changed to bash.
EDIT: But that's probably (not really sure) for providing wired connection at boot.


As the script stands, yes, that's true. However, that's nothing per se to do with gtkwialog (or gtkdialog), it's just that the "if [[...]]" construct is a bashism.

Yes, not to do with gtkwialog, but just thought mentioning it because when I changed sh > dash, I didn't have a (wired) connection at boot and changing that script fixed it.
(that was for me with only peasywifi installed, no other network-manager)

Actually, I only use wifi connection myself, but I should point out that I don't think there actually is any /etc/rc.d on my xenialdog64 system

It should be there, as it's part of peasywifi package.
The reason that you don't have it could be because you did a remaster recently, the remaster scripts remove that folder, which is a bug (fixed now, see below)
Anyway, new version of remaster-scripts (1.0.3) and quick-remaster (1.0.9) in Xenialdog repos.

Fred

[wiak]

The reason that you don't have it could be because you did a remaster recently, the remaster scripts remove that folder, which is a bug (fixed now, see below)
Anyway, new version of remaster-scripts (1.0.3) and quick-remaster (1.0.9) in Xenialdog repos.

Fred

Okay, that's why it had probably gone. I"ll fix that on my system. Meanwhile, I made faster progress today and finished all the widget code additions. Haven't at all tested some things yet though, so will be lucky if all fine. Thereafter will work on github resource.

wiak