(OLD) (ARCHIVED) Puppy Linux Discussion Forum

[disciple]

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?

[wiak]

[wiak]

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]

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/viewtopic.php?p=993434#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/viewtopic.php?p=993443#993443

wiak

[01micko]

[wiak]

[wiak]

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

[01micko]

[wiak]

debian packages for 32bit and 64bit gtkwialog released (currently attached to first post of this thread):

http://www.murga-linux.com/puppy/viewtopic.php?p=993434#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/viewtopic.php?p=993443#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

[smokey01]

@wiak,

Where does gtkdialog/gtkwialog source the stock icons from. Are they part of the source code?

If so, is it possible to add more?

[disciple]

They are part of gtk, and you can't add more just by putting images somewhere.

[wiak]

[wiak]

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

[wiak]

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 (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/viewtopic.php?p=994141#994141