Gtkwialog project

[wiak]

Hi Wiak,

I have made a Wiki entry for Gtkwialog.
http://www.puppylinux.org/wikka/Gtkwialog

Any changes you wish made to the entry please let me know.

Thanks darryl, but the new version of gtkwialog makes the text you put in wrong cos gtkwialog now allows choice of legacy gtkdialog mode anyway, so don't need both gtkdialog and gtkwialog any longer for that.

[wiak]

Hi Wiak,

I have made a Wiki entry for Gtkwialog.
http://www.puppylinux.org/wikka/Gtkwialog

Any changes you wish made to the entry please let me know.

Thanks darry, but the new version of gtkwialog makes the text you put in wrong cos gtkwialog now allows choice of legacy gtkdialog mode anyway, so don't need both gtkdialog and gtkwialog any longer for that. So it's the last sentence that particularly needs changed. Maybe something like:

People who want to run legacy shell/gtkdialog apps that export bash functions, and who do not want to modify them, will want to either continue using legacy gtkdialog or use gtkwialog in legacy mode (which is provided in gtkwialog for backwards compatability).

But it is up to you; I'm just providing the program and making comment.

[darry19662018]

Thanks Wiak,
Being a fork with diverged functionality gtkwialog has been given a different code name hence users can choose to use either legacy gtkdialog or this new gtkwialog as they see fit. People who have legacy shell/gtkdialog apps , who do not wish to modify them, will want to continue using legacy gtkdialog."
I have ammended the page with that quote - important to have the correct information.

[wiak]

Thanks Wiak,
Being a fork with diverged functionality gtkwialog has been given a different code name hence users can choose to use either legacy gtkdialog or this new gtkwialog as they see fit. People who have legacy shell/gtkdialog apps , who do not wish to modify them, will want to continue using legacy gtkdialog."
I have ammended the page with that quote - important to have the correct information.

Sorry, darry, I meant you to keep the first sentence in too because it is important to me that gtkwialog is not pushed over using legacy gtkdialog. So the text would better read:

Being a fork with diverged functionality gtkwialog has been given a different code name hence users can choose to use either legacy gtkdialog or this new gtkwialog as they see fit. People who want to run legacy shell/gtkdialog apps that export bash functions, and who do not want to modify them, will want to either continue using legacy gtkdialog or use gtkwialog in legacy mode (which is provided in gtkwialog for backwards compatability).

It's quite a mouthful, but it's accurate.

wiak

[darry19662018]

Sweet done:)

[wiak]

Code: Select all

#!/bin/sh

# Simple Example to show the subtle difference in
# <action>command_strings for the three modes
# available in gtkwialog.
# You can substitute viewnior for gpicview, for example, if you want.
# After you close the first window, the next of the three will open: 

#POPUP WINDOW 1
mode_gtkdialog_legacy=' 
<vbox>
  <hbox> 
    <text><label>Open image viewer:</label></text> 
    <button> 
      <input file stock="gtk-home"></input> 
      <action>gpicview &</action> 
    </button> 
    <button ok></button> 
  </hbox>
</vbox>' 
export mode_gtkdialog_legacy 

#POPUP WINDOW 2
mode_synchronous_blocking=' 
<vbox> 
  <hbox>
    <text><label>Open image viewer:</label></text> 
    <button> 
      <input file stock="gtk-home"></input> 
      <action>sh -c "gpicview &"</action> 
    </button> 
    <button ok></button> 
  </hbox>
</vbox>' 
export mode_synchronous_blocking 

#POPUP WINDOW 3
mode_asynchronous_nonblocking=' 
<vbox> 
  <hbox>
    <text><label>Open image viewer:</label></text> 
    <button> 
      <input file stock="gtk-home"></input> 
      <action>gpicview</action> 
    </button> 
    <button ok></button> 
  </hbox>
</vbox>' 
export mode_asynchronous_nonblocking 

# popup mode_gtkdialog_legacy example window
./gtkwialog_prealpha64n -p mode_gtkdialog_legacy

# popup mode_synchronous_blocking example window
./gtkwialog_prealpha64n -b -p mode_synchronous_blocking

# popup mode_asynchronous_nonblocking example window
./gtkwialog_prealpha64n -a -p mode_asynchronous_nonblocking

exit 0

[mistfire]

@wiak witch of the mode on gtkwialog supports bash exported function if the interpreter in the script is bash?

[wiak]

@wiak witch of the mode on gtkwialog supports bash exported function if the interpreter in the script is bash?

You need synchronous blocking mode, which is -b command arg:

Code: Select all

gtkwialog -b

So inside the dialog you then call the bash functions with:

<action>bash -c function_name</action>

and gtkwialog will find the function even if the underlying /bin/sh is a symlink to busybox ash.

wiak

[wiak]

Probably final test binary for gtkwialog is now released (download link as usual in first post of this thread):

http://www.murga-linux.com/puppy/viewto ... 434#993434

#CHANGES: Just minor documentation changes.

Hasn't been any test reports from previous release but thanks to those who tested first version (particularly fredx181 and rcsrn51). A couple of simple test scripts can be found at the botton 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

I've only uploaded 64bit binary at the moment, but I intend uploading 32bit one in a few hours time.

wiak

[disciple]

Hi Wiak,
Regarding your thoughts about the Puppy Linux "stewards" (I'm not sure when that description was invented), I think that is another matter entirely, as gtkdialog is a separate project.

Looking at the list I note that it is mostly just a list of who keeps the various web infrastructure up and running. John obviously created and runs the forum (note that even Flash the ever present forum moderator isn't included). IIRC Raffy either created the wiki or resurrected it many moons ago.
The only roles really related to Puppy itself are:
- deciding on an "official" current version of Puppy (it seems that Dog is considered a different distro or distros, so presumably isn't actually relevant here)
- maintaining woof-ce (does Dog use woof-ce?)

I guess Dog must have at least one person that is essentially its own "steward", even if that term isn't used.

BTW thanks for piquing my interest in Dog - it looks good. I've seen people mentioning it all the time on the forum, but I didn't know what they were talking about, because they never include a link. I remember when it was being called DebianDog, but I didn't know it was the same thing. Having found its website the only trouble was making sense of all the different versions - maybe a Debian/Ubuntu enthusiast would know which one they want right away, but I certainly didn't!

[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]

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?

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.

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

[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/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

[01micko]

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?

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'.

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.

[wiak]

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?

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'.

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

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

[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]

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

OK, enjoy a rest.

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.

[wiak]

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

[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?