Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 25 Sep 2018, 19:27
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Gtkwialog continuing development information
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [13 Posts]  
Author Message
wiak

Joined: 11 Dec 2007
Posts: 939
Location: not Bulgaria

PostPosted: Sat 09 Jun 2018, 00:08    Post subject:  Gtkwialog continuing development information  

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

Last edited by wiak on Mon 09 Jul 2018, 01:56; edited 13 times in total
Back to top
View user's profile Send private message 
darry19662018

Joined: 31 Mar 2018
Posts: 228

PostPosted: Sat 09 Jun 2018, 00:27    Post subject:  

Wiak I wish you the sincerest best with this - your attention to detail and wanting perfection in your work is inspiring.
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 939
Location: not Bulgaria

PostPosted: Mon 11 Jun 2018, 00:43    Post subject: mixed action modes now allowed
Subject description: in latest development version of gtkwialog
 

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
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 939
Location: not Bulgaria

PostPosted: Tue 19 Jun 2018, 06:48    Post subject:  

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
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 939
Location: not Bulgaria

PostPosted: Thu 05 Jul 2018, 04:58    Post subject:  

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
pfind_original_working_over_dash.jpg
 Description   
 Filesize   49.6 KB
 Viewed   276 Time(s)

pfind_original_working_over_dash.jpg

pburn_working_over_dash.jpg
 Description   
 Filesize   56.64 KB
 Viewed   278 Time(s)

pburn_working_over_dash.jpg

Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 3394
Location: holland

PostPosted: Thu 05 Jul 2018, 07:14    Post subject:  

Hi wiak,

Quote:
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

_________________
Dog Linux website
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 939
Location: not Bulgaria

PostPosted: Thu 05 Jul 2018, 08:09    Post subject:  

fredx181 wrote:

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
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 939
Location: not Bulgaria

PostPosted: Thu 12 Jul 2018, 03:59    Post subject:  

wiak wrote:
fredx181 wrote:

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:
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
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 3394
Location: holland

PostPosted: Thu 12 Jul 2018, 12:35    Post subject:  

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.

Fred

_________________
Dog Linux website
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 939
Location: not Bulgaria

PostPosted: Thu 12 Jul 2018, 19:02    Post subject:  

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. 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:
if [ "$1" == "start" ] || [ "$1" == '' ]] ; then
/etc/rc.d/rc.network &

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


or alternatively:

Code:
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).
Back to top
View user's profile Send private message 
darry19662018

Joined: 31 Mar 2018
Posts: 228

PostPosted: Fri 13 Jul 2018, 02:32    Post subject:  

Added this to the Puppy Wiki:
http://puppylinux.org/wikka/Gtkwialog
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 3394
Location: holland

PostPosted: Fri 13 Jul 2018, 04:36    Post subject:  

Quote:
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)

Quote:
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

_________________
Dog Linux website
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 939
Location: not Bulgaria

PostPosted: Fri 13 Jul 2018, 09:23    Post subject:  

fredx181 wrote:

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
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [13 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0669s ][ Queries: 13 (0.0050s) ][ GZIP on ]