Gtkwialog project

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#61 Post by wiak »

I did an ultra-quick /usr/local/pfind/pfind conversion attempt, which is attached. It partially works in dash (for example try searching from the Advanced button gui); this or some other component of pfind needs a bit extra debugging for perfection, but can't be far away...

If you don't have time or manage to debug it, I'll try some other time.

By the way, I found it useful to search and replace for this term also:

Code: Select all

&</action>
which needed a sh -c at the beginning too (for job control).

that end part of that action line being replaced with:

Code: Select all

&"</action>'"
and its front part replaced with:

Code: Select all

"'<action>sh -c "
Note that with these multi-function modularised shell/gtkdialog Puppy apps, I usually change to the relevant folder where they all are and do the likes of:

Code: Select all

grep '&</action>' *
and

Code: Select all

grep '<input>' *
and

Code: Select all

grep 'export -f' *
and finally, a more generic action tag search:

grep '<action[[:space:]]>' *

and similar...

to find in which files likely problems are. Then I open these up in geany for the actual search/replace style conversion. That part of the process is surprisingly quick once I've practiced it.

NOTE: pfind also needs usleep (though works without it), which isn't in XenialDog64 at least.

EDIT: /usr/local/pfind/pfilesearch/pfilesearch also needs a few fixes for conversion. I've also attached my converted version and that seems to fix things. Still some minor pfind bugs I see, but I think they are in the non-converted one anyway on XenialDog64, which is where the attached files are from. Need tested though and I'd advise a diff on the original and these converted ones to see exactly how I did it.

pfind was certainly not the easiest program to convert since quite a lot of sh -c commands are required in it, and the need to search multiple files to find the need - but easy once the method to do so is worked out.

EDIT: Still some debugging required - it is not forgetting the previous search result. Also, may need to try it first without the modified pfilesearch additon and using the Advanced buttons search first of all (then partially working with dash). Unless I get round to further debugging of course.

EDIT2: May have fixed the bulk of it. Was a bashism (case statement form I think in pfilesearch, so needed to amend pfind line 429 to:

"' <action>bash -c ". $PROGPATH/fu ... /action>'"

It is possible there are some other instances I've used sh -c when bash -c will be necessary. For speed of conversion I guess always easiest to use bash -c though who knows what trouble that may cause later!

EDIT3: Note that you get rid of the initial pfind grep error messages if you export a value for LANG before running the program. Generally not important. There are some other small error messages during running, but I think they are there whether using bash or dash (?). Program seems to work fine though.

EDIT4: Downloads deleted since I have since converted most recent pfind 6.3

wiak
Last edited by wiak on Tue 05 Jun 2018, 05:37, edited 8 times in total.

phat7
Posts: 179
Joined: Fri 05 Jun 2015, 08:54

#62 Post by phat7 »

How to execute gtkwialog_0.8.4_i386.deb.tar you linked on page 1?

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#63 Post by wiak »

phat7 wrote:How to execute gtkwialog_0.8.4_i386.deb.tar you linked on page 1?
You haven't given me sufficient information to answer you properly phat7, (but I'll do my best anyway). In particular, are you on a Debian-based system or a Puppy? - note that the file is a deb package (though I believe many pups can use that too).

After first removing the dummy (false) .tar extension you should install the package. The installation package manager will then put the gtkwialog executable file into /usr/bin, which is in your system's executable search PATH so will be found from then on. Just like with legacy gtkdialog, you use this to create new programs. Example scripts that should work with it automatically are given in post 4 of this thread; you need to copy the content of any one of these examples into a text file, give that text file a filename of your choice, and make it executable, from the commandline, with

Code: Select all

chmod +x your_chosen_filename
For example, once you correctly have gtkwialog installed in /usr/bin from the supplied deb package, you could try executing the following one of the post 4 example scripts:

Code: Select all

#!/bin/bash 

sub_filemanager (){ 
 rox & 
} 
export -f sub_filemanager 

script=' 
<vbox> 
  <entry> 
    <variable>MYENTRY</variable> 
    <input>ls -al /bin/sh</input> 
  </entry> 
  <hbox width-request="480"> 
    <text><label>Open filemanager:</label></text> 
    <button> 
      <input file stock="gtk-home"></input> 
      <action>bash -c sub_filemanager</action> 
    </button> 
    <button ok></button> 
  </hbox> 
</vbox>' 
export script 

gtkwialog -b -p script
From the directory you've stored the your_chosen_filename program, you run it with:

Code: Select all

./your_chosen_filename
If rox filemanager is not on your system, you could, say, change the rox & code line number 4 above to be pcmanfm &, or whatever filemanager your system has.

wiak

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#64 Post by wiak »

After the above success with pfind, I decided to have a go at pburn since it has a similar code organization. I regret that decision...

pburn is full of <action> lines of various sorts that need a shell added when trying to convert with gtkwialog -b mode. I believe there are also bashisms in some of these actions, so legacy gtkdialog won't work when underlying shell is dash.

I have had to give up on that one for now - tons and tons of code changes needed and what makes it harder is that it keeps changing from dialogs surrounded by double quotes to dialogs surrounded by single quotes, which require a different overall <action> quoting pattern...

And the <action></action> lines are all embedded in the middle of complex lines (rather than being separated to own lines).

A nightmare to convert.

Perhaps it would be easier to leave it in legacy gtkdialog mode (which is gtkwialog also with -a or -b option) and then modify some of the code to us dash ok rather than bash for the <action>commandlines. I haven't put head into that mode of thought yet, so I'm not sure if that is easy, easier, or likely. Has Slitaz not once used pburn? If so, and using busybox ash, they must have recoded some of it for legacy gtkdialog, but maybe I'm imagining I saw it in Slitaz (or somewhere else).

I may come back to it - but don't hold out hope for that...

I much prefer to convert the bash export -f using programs (such as my own and also some of the rcsrn51's peasy suite) - that's usually easy.

wiak

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

bash/gtkwialog app cast2chrome now published

#65 Post by wiak »

I've now published my first dash, ash, and bash system compatible app, 'cast2chrome' here:

http://www.murga-linux.com/puppy/viewto ... 012#991012

Depends on gtkwialog of course (running in -b mode).

wiak

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#66 Post by fredx181 »

Hi wiak, thanks for the pfind convert, I can' t really compare with what I did because I was testing with newer version 6.3, but will look at it later (now busy with new BionicDog release, almost ready).
Anyway I learned that not only "export -f" or other bashisms need to be modyfied but also other commands need the bash -c or sh -c in front of it.
About pburn... I had the feeling already that it would be too complicated, so I tried with pfind (which turned out to be a "hard nut to crack" for me).

Fred

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#67 Post by wiak »

fredx181 wrote:Hi wiak, thanks for the pfind convert, I can' t really compare with what I did because I was testing with newer version 6.3, but will look at it later (now busy with new BionicDog release, almost ready).

Fred
Ah sorry, I was careless not using new pfind. Point me to where it is and I'll convert it.

EDIT: I've looked at the DD github site but couldn't see Bionic repository with new one (EDIT2: found it). I have now downloaded pfind 6.3 deb from Bionic repo.

wiak

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#68 Post by wiak »

EDIT: Please note that I missed a line in the pfind available in the download link below but Fred has found it for me. It is in script /usr/local/pfind/func inside menuitem() at the top of that code. The line in there needs changed to this:

Code: Select all

<action>bash -c "echo '$2' > /tmp/pfind-tmp'$PROGPID'"</action>
As Fred says, that gets the right click action working on the menu list of found items (something like that anyway). Note that the bash -c (or sh -c) is required here because of the > redirection. A shell is needed to do redirection. end_of_EDIT

For my own use, and testing, I have now converted pfind 6.3 (from BionicDog repo) to use gtkwialog -b and thus work with underlying dash shell(for example on pristine Ubuntu or Debian) or busybox ash shell (e.g. on pristine Slitaz).

Had some trouble in getting it to work because needed the following format for if true, and if false action commandstrings (previously I had the bash -c stupidly at the very front here...):

Code: Select all

<action>if true bash -c "echo true > '$WORKDIR'/ADVANCED_GUI_STATUS"</action>
Note that above quoting works when overall dialog is surrounded by single quotes. When it is surrounded by double quotes it is probably best (or at least I find it easier) to temporarily modify the dialog to use single quotes for the <action>commandstring line. That is:

Code: Select all

"'<action>if true bash -c "echo true > '$WORKDIR'/ADVANCED_GUI_STATUS"</action>'"
I have a deb of my converted pfind package temporarily at the link below so fredx181 can test it, but note that this is not a release, official or unofficial, per say - pfind is not my program...

Please find fixed download provided by Fred a few posts down.

NOTE WELL: this will NOT work with legacy gtkdialog. You need gtkwialog installed on your system for this dash-or-ash-or-bash-capable version.

I don't in any case guarantee it is a perfect conversion. May need a few tweaks yet, though seems to work fine in my quick tests.

@fred: actually I've now PM'd you about this conversion so you can arrange what to do with it.

wiak
Last edited by wiak on Wed 06 Jun 2018, 17:40, edited 1 time in total.

darry19662018
Posts: 721
Joined: Sat 31 Mar 2018, 08:01
Location: Rakaia
Contact:

#69 Post by darry19662018 »

Hi Wiak,

I have installed this Gtkwialog in Racy 5.5 and removed the old pfind and installed your new modified one and it works. Pfind seems a lot faster using gtkwialog.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#70 Post by wiak »

darry19662018 wrote:Hi Wiak,

I have installed this Gtkwialog in Racy 5.5 and removed the old pfind and installed your new modified one and it works. Pfind seems a lot faster using gtkwialog.
It possibly will be a bit faster since not so many system calls to shell with the gtkwialog -b mode being used in that modified pfind.

Surprised it worked in Racy - good to know, thanks.

wiak

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#71 Post by fredx181 »

Here's pfind_6.3_gtkwialog with the small fix for right-click menu included (see wiak's EDIT on top of his before last post)
https://fredx181.github.io/StretchDog/N ... og_all.deb

Fred

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#72 Post by wiak »

I have read a comment posted elsewhere that indirectly suggested that gtkwialog used with bash, when the underlying /bin/sh is dash is somehow in some way unsafe or prone to failure. That comment is false. Gtkwialog is simply more flexible than legacy gtkdialog in a way that allows it to be safely used by someone who prefers to use the more powerful bash programming language (no matter what the underlying system shell is).

Gtkwialog, in that sense, is simply a better Gtkdialog, which did prevent the use of many of bash's powerful features when underlying shell was the likes of dash or ash. Gtkwialog removes that limitation. Bash was designed for the purpose of writing more sophisticated scripts and there is nothing unsafe about bash (despite some using the word bashisms as an attack on a perfectly good language when used correctly via a bash interpreter, which gtkwialog, unlike gtkdialog, allows).

Neither code protectionism or jealousy are ever a good reason to attack developments and progress by others in that underhand negative and more than potentially misleading manner. If a person has no interest in this project, that is fine, but misleading others about its potential or value is not, which is more than just having a different opinion. Get your technical facts straight and correct (rather than twisted) if you are going to state them in that manner, for whatever your 'personal' reasons may be.

wiak (alias mcewanw - early developer with Toni and Fred of DebianDog family)

User avatar
aaaaa
Posts: 39
Joined: Tue 22 May 2018, 14:57

#73 Post by aaaaa »

Hello wiak

I haven't used gtkwialog, but i read it adds improvements to gtkdialog

I think the changes can be safely added to gtkdialog. I was thinking of env variables.

For example, a script can be marked as GTKWIALOG by adding

Code: Select all

#!/bin/sh
.
.
.
export GTKWIALOG=1
In gtkdialog itself, the code to determine if the new approach is to be used would be as simple as this:

Code: Select all

#include <stdlib.h>

if (getenv("GTKWIALOG")) {
 GTKWIALOG=1;
}
This is just an idea i had..

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#74 Post by wiak »

Yes, these are alternatives to command argument mode switches, though I've no problem with the latter either.

Your suggestion is certainly better than the earlier multiple symlink suggestion IMO, but I'm lazy to have to export new variables to the environment, as and when mode change required, and prefer the command arg switches to be honest, which were also trivial to implement. The program works exactly as standard gtkdialog anyway if no switch to say otherwise put on the commandline. So it's all in a name in that sense really. I won't push gtkwialog if no one wants to use it anyway - just for my own fun in the end maybe, except that any such gtkdialog-like apps I write in the future will use it and any developments on my older apps.

wiak

User avatar
aaaaa
Posts: 39
Joined: Tue 22 May 2018, 14:57

#75 Post by aaaaa »

So i read a bit more about the current situation, ok.

But it was just a suggestion, i myself don't care much about the fate of gtkdialog.

But i'd be tempted to use this patched version when the time is right (i.e. 2019).

You might to want add those lines anyway (getenv())

Ok, i read some previous comments, just want to reiterate that it's interesting. Now i know about the repo.

It's easy to sync both repos

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#76 Post by wiak »

@aaaaa: the code is still being tested to see if useful and likely to be adopted.
...
But yes, your getenv preference would be a nice additional option so that one could chose the preferred method to activate the new modes - easily done and I'll bear that in mind. I used almost identical getenv code in my very old 'wiak' program of eight or more years ago as it happens.

The following by the way is pretty much the simple method being used to select the new modes anyway, albeit for commandline args rather than a getenv result:
aaaaa wrote:

Code: Select all

#include <stdlib.h>

if (getenv("GTKWIALOG")) {
 GTKWIALOG=1;
}
Just two simple flags (option_blocking or option_nonblocking) used by an if statement to control the flow logic. Pretty much impossible to get wrong - safe as pie...

wiak
Last edited by wiak on Mon 09 Jul 2018, 06:36, edited 2 times in total.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#77 Post by wiak »

I now note that Thunor knew about the bash issue with gtkdialog running /bin/sh -c via system() call:

http://murga-linux.com/puppy/viewtopic. ... 694#668694

He correctly stated that one way round was to not use bashisms (but that is restrictive since bash was specially designed as a more powerful interactive and programmer's shell; a 'better' more sophisticated programming language effectively - shame to have to ignore it when programming shell apps, whilst forcing bash, in Puppy and the Dogs, as an inefficient, slow, system shell - but bash certainly fast enough at human level for simple app/util writing).

However, Thunor got it wrong thinking/suggesting in his linked post above that another solution was to use bash -c before actions in gtkdialog - his suggestion simply doesn't work for legacy gtkdialog because, as I explained, the forced /bin/sh -c invocation strips the bash environment and the bash exported function calls are lost.

Hence my gtkwialog creation/fork, which does behave the way Thunor imagined legacy gtkdialog would but didn't. Also gtkwialog removes the need to use /bin/sh stage altogether where applicable, which makes it more efficient overall.
...

wiak
Last edited by wiak on Mon 09 Jul 2018, 06:37, edited 1 time in total.

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#78 Post by s243a »

wiak wrote:However, let the gtkdialog faithful continue to use the crippled older legacy gtkdialog mode if so be it.
You say it's faster, so if all the core puppy apps get ported to Gtkwialog, there is a high probability that it will get adopted by most or all puppies, provided that Gtkwialog continues to get maintained.

Clearly it will be the Debian based puppies that will adopt it first. I will note though that if we have to port programs to gtkwialog then it isn't really 100% compatible, and so therefore some may still want to use the old "crippled" version. Or maybe you don't mean port; maybe you mean optimize and forgive me if I missed something in this thread as I can't read everything in the world. Also note that I'm not a developer of a puppy distribution so it isn't up to me whether or not it gets adopted.

Anyway, I appreciate the work of all developers but the great thing about open source is that people can chose to use what they want even if their choice isn't the most optimal based on some criteria...so maybe gtkwialog is the greatest thing since sliced bread but but everyone won't discover whether or not it is so great overnight.

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#79 Post by MochiMoppel »

wiak wrote:Thunor got it wrong thinking/suggesting in his linked post above that another solution was to use bash -c before actions in gtkdialog - his suggestion simply doesn't work for legacy gtkdialog
Somehow Thunor's suggestion seems to work for me.
Tested with legacy gtkdialog, /bin/sh linked to /bin/ash.

Code: Select all

#!/bin/bash
func_bash() {
	SYSHELL=$(realpath /bin/sh)
	gxmessage $(cat <(echo "/bin/sh points to $SYSHELL"))
}; export -f func_bash

echo '<button label="Call exported function">
<action>bash -c func_bash</action>
</button>' | gtkdialog -s
Don't know if dash would behave differently from busybox ash.
"bash -c" is also be required when running above script in a standard sh/bash environment.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#80 Post by wiak »

s243a wrote:I will note though that if we have to port programs to gtkwialog then it isn't really 100% compatible, and so therefore some may still want to use the old "crippled" version. Or maybe you don't mean port; maybe you mean optimize and forgive me if I missed something in this thread
gtkwialog (without specifying the new commandline switches) is 100% compatible with legacy gtkdialog and I couldn't care less if it is adopted aside from the fact that it was offered. I document it here mainly for my own notes and stated from the very first that this would be my fork for my own use unless it was clearly wanted by Puppy community; the remarks by some of the more prominent amongst them suggesting that it is more than a pain than a pleasure, so relax.

wiak

Post Reply