hover_expand ? Since row expansion is not implemented in gtkdialog this should have no effect whatsoever. Does it work for you somehow?mister_electronico wrote: <tree hover_expand="true" hover_selection="true">
GtkDialog - tips
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Re: Something that I just see now
- mister_electronico
- Posts: 969
- Joined: Sun 20 Jan 2008, 20:20
- Location: Asturias_ España
- Contact:
HI
Sorry MochiMoppel ,I was looking for play around with different things and I forget to delete it.
It makes No sense, I was looking for how to put icons in the items when they come from a file.
Sorry
See you.
It makes No sense, I was looking for how to put icons in the items when they come from a file.
Sorry
See you.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
In case anyone is interested in adding some graphics to bash scripts:
https://developers.slashdot.org/story/1 ... s-for-bash
https://developers.slashdot.org/story/1 ... s-for-bash
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
...and it works too. Not that I have the slightest idea what to do with it, but I can always stare at the demos.
It compiles on Quirky Xerus64 with just the addition of ftgl (from PPM). Also compiled on Slacko 571 (Sailor's recent offering) and also got ftgl from PPM. Other dependencies may be needed depending on your distro.
It compiles on Quirky Xerus64 with just the addition of ftgl (from PPM). Also compiled on Slacko 571 (Sailor's recent offering) and also got ftgl from PPM. Other dependencies may be needed depending on your distro.
- Attachments
-
- CmdlineGL.jpg
- (19.68 KiB) Downloaded 426 times
-
- CmdlineGL-2.jpg
- (15.63 KiB) Downloaded 431 times
You seem to be one of the few people that actually tests anything new Keef (at least that's the impression I sometimes get)! I had a look at the bash/opengl thing too, but opengl games type programming isn't of much use to me personally, and it seems to be a pretty straight binding from bash to opengl so main job would be learning opengl programming anyway, which I'm not likely to do. Wasn't sure why it was posted under GtkDialog tips - hoped it was an alternative bash to gtk widget kind of toolkit, but it isn't as far as I can see. I suppose was posted here because it is driven from bash, like gtkdialog is, so that would explain it.Keef wrote:...and it works too. Not that I have the slightest idea what to do with it, but I can always stare at the demos.
wiak
notebook tip
A warning when using notebook tabs in a gtkdialog app...
Let us say that you are using an Entry Widget in one tab of notebook,
and want to have a similar Entry Widget in another tab.....
You MUST use different variable names for each Entry Widget,
Otherwise confusing data will be passed to shell when exiting.
As example see PTM timer 2.2
http://murga-linux.com/puppy/viewtopic.php?t=112410
_________________________________________________________
Let us say that you are using an Entry Widget in one tab of notebook,
and want to have a similar Entry Widget in another tab.....
You MUST use different variable names for each Entry Widget,
Otherwise confusing data will be passed to shell when exiting.
As example see PTM timer 2.2
http://murga-linux.com/puppy/viewtopic.php?t=112410
_________________________________________________________
The most frustrating/horrible aspect of gtkdialog (bash scripts embedding gtkdialog GUI constructs etc) is that it runs as a child process of the bash script and changes to variables in child processes do not get passed back by default to the parent bash process.
But worse than that, gtkdialog by default actually interacts with the underlying system shell (and not really the calling bash program), which, if its dash, for example, will muck most bash/gtkdialog programs up totally (since dash can't see exported bash functions often used in typical bash/gtkdialog scripts).
Hence, to get our typical bash/gtkdialog scripts to work as designed we are forced usually to make the default system shell /bin/bash, which limits the program's compatibility with other Linux systems such as pure Debian, slows down system startup scripts, and encourages us to often use unnecessarily bashisms in our script programs.
And then there is the program complexity resulting from the fact the dialog is just all held in an exported variable resulting in all the tricks required to use and process that. We get used to it... true... but hardly an ideal programming environment - more of a fudge.
And these real frustrations are on top of the clumsy pseudo-xml syntax.
But it works... and I do use it often and in terms of ease of use it becomes a matter of "what you are familiar with using"... Painful though, and needs so many 'work-arounds' especially for complex process handling if you don't want zombies left lying around.
wiak
But worse than that, gtkdialog by default actually interacts with the underlying system shell (and not really the calling bash program), which, if its dash, for example, will muck most bash/gtkdialog programs up totally (since dash can't see exported bash functions often used in typical bash/gtkdialog scripts).
Hence, to get our typical bash/gtkdialog scripts to work as designed we are forced usually to make the default system shell /bin/bash, which limits the program's compatibility with other Linux systems such as pure Debian, slows down system startup scripts, and encourages us to often use unnecessarily bashisms in our script programs.
And then there is the program complexity resulting from the fact the dialog is just all held in an exported variable resulting in all the tricks required to use and process that. We get used to it... true... but hardly an ideal programming environment - more of a fudge.
And these real frustrations are on top of the clumsy pseudo-xml syntax.
But it works... and I do use it often and in terms of ease of use it becomes a matter of "what you are familiar with using"... Painful though, and needs so many 'work-arounds' especially for complex process handling if you don't want zombies left lying around.
wiak
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Horrible? Doesn't any program you start from a script run in a subshell? Gtkdialog doesn't really need a bash script to run but not using one ... well, this can be hell.wiak wrote:The most frustrating/horrible aspect of gtkdialog (bash scripts embedding gtkdialog GUI constructs etc) is that it runs as a child process of the bash script
Of course not. This would defeat one of the purposes of a subshell. Where does Linux allow you to change variables of a calling parent process from a subprocess? I sometimes like to do that but I understand that this is a no-go.and changes to variables in child processes do not get passed back by default to the parent bash process.
This is interesting. AFAIK gtkdialog uses sh. My system shell is bash, my script runs in bash, still gtkdialog would use sh in its <action> subshells.But worse than that, gtkdialog by default actually interacts with the underlying system shell (and not really the calling bash program), which, if its dash, for example, will muck most bash/gtkdialog programs up totally (since dash can't see exported bash functions often used in typical bash/gtkdialog scripts).
What output do you get from this bash/gtkdialog script when you run it with a dash system shell?
Code: Select all
#!/bin/bash
echo '<button label="Print shell"><action>echo $0</action></button>'|gtkdialog -s
Em... to be frank you sound a bit aggressive, and I'm not sure why or maybe it is just how your sharpness comes over to me.
Of course a child process cannot directly reflect its environment back to the parent. I'm a system level C programmer originally so yes I do know that much. I won't comment further why I find that truth a real pain when using bash/gtkdialog to start stop and pause processes with signals and so on. I simply find it a pain - you are welcome to find it not a pain.
wiak
Of course a child process cannot directly reflect its environment back to the parent. I'm a system level C programmer originally so yes I do know that much. I won't comment further why I find that truth a real pain when using bash/gtkdialog to start stop and pause processes with signals and so on. I simply find it a pain - you are welcome to find it not a pain.
Yes, gtkdialog uses sh. Obviously if your system sh points to /bin/bash you have no problems with your bash/gtkdialog programs. But try your mm_view program, which I note you have written, on a Debian system, where sh points to dash. You will find it won't work and you'll have a hell of a job making it work aside from reconfiguring sh to point to bash, which most in the Debian world wouldn't want to do (or they would have bash configured as sh from the very start). I tend to use XenialDog, Puppy, Tiny Core and Slitaz in that order. I resign myself to having sh as link to /bin/bash, because it proves too painful writing bash/gtkdialog scripts to not use export -f bash function calls.MochiMoppel wrote:This is interesting. AFAIK gtkdialog uses sh. My system shell is bash, my script runs in bash, still gtkdialog would use sh in its <action> subshells.
wiak
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Occasionally I do have problems as running sh linked to /bin/bash is not the same as running /bin/bash directly. Still not a big issue.wiak wrote:Obviously if your system sh points to /bin/bash you have no problems with your bash/gtkdialog programs.
Why would it be painful? You have options, and if you want to avoid quotation hell you could always use external script files, couldn't you?I resign myself to having sh as link to /bin/bash, because it proves too painful writing bash/gtkdialog scripts to not use export -f bash function calls.
Well, yes, I could use external script files instead, and quite a number of. bash/gtkdialog programmers on this forum, for example Zigbert, basically patterned external script functions as a much-copied Puppy utils programming style. With all due respect I happen to hate that style, preferring the much simpler to read single script with the functions inside it. The individual functions tend to be small and hardly invite individual modularisation, but certainly a single externally functions script would be an acceptable workaround. Another alternative is to call bash exported functions via bash -c, rather than directly, then it doesn't matter that system sh links to dash, but sometimes using bash shell calls like that causes problems and additional complexity, so, like most here, I take the lazy way out and make sh link to bash.MochiMoppel wrote:Why would it be painful? You have options, and if you want to avoid quotation hell you could always use external script files, couldn't you?
wiak
And the painful fact is, most puppy app/utils are not thus portable to other Linux distributions since pretty much everyone here is using export -f liberally whether their scripts are broken up into modular external scripts or not. So not portable to Slitaz, which by default, uses busybox ash for sh, and not as I said to Debian, which uses dash. Either you are forced to link sh to bash, or you'd have to rewrite the programs, which can be a major rewrite.
wiak
wiak
Had gtkdialog been itself created to use bash rather than sh the problem would not exist. Then it would indeed be sufficient to simply call gtkdialog from inside a bash script whether underlying sh was ash, dash, or some other Posix-complient shell only. But then bash required on system (which however is a simple addition to any system and no need to force sh to link to bash). But I believe Thunor wanted it to use sh, per its original design, advocating users could use painful bash -c constructs to work round the compatibility issues. Pity, I think though it does seem a fudge to force system sh calls via bash within gtkdialog itself, so no easy solution.
wiak
wiak
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
I would be happy had it been created to use at least the system shell, which apparently it does not.wiak wrote:Had gtkdialog been itself created to use bash rather than sh the problem would not exist.
My environment variable SHELL is assigned to /bin/bash. Gtkdialog doesn't care. It seems to be hardcoded to use sh. I don't speak C but you do. Maybe you can determine why gtkdialog insists on using sh.
Well, gtkdialog does use the 'system' shell, which means it calls the shell via C 'system' call, but C system call means:MochiMoppel wrote:I would be happy had it been created to use at least the system shell, which apparently it does not.wiak wrote:Had gtkdialog been itself created to use bash rather than sh the problem would not exist.
My environment variable SHELL is assigned to /bin/bash. Gtkdialog doesn't care. It seems to be hardcoded to use sh. I don't speak C but you do. Maybe you can determine why gtkdialog insists on using sh.
Code: Select all
#include <stdlib.h>
int system(const char *command);
Description
system() executes a command specified in command by calling /bin/sh -c command, and returns after the command has been completed.
As things stand, in gtkdialog you can call shell functions with either the function name only (as a string), which results in them being interpreted by /bin/sh -c as /bin/sh -c "function", or you call the function using bash -c "function", which results in them being interpreted by /bin/sh -c '/bin/bash -c "function"' (which is more than a bit messy and likely to have other side effects). Well using bash -c "string_containing_command" does work, so fact is, we should be writing our gtkdialog programs that way for portability (at least when the string includes a reference to a bash exported function), but no-one on Puppy hardly ever does.
Since gtkdialog using /bin/sh -c to access functions then to see functions exported by bash using export -f, /bin/sh needs to be a link to /bin/bash to work... (unless bash -c "" syntax used when required throughout the gtkdialog xml constructs).
wiak
EDITED to fix quote marks a little so as to be a bit more accurate.
I suppose I should really try a quick mod of gtkdialog since at a quick glance it does look like a few extra lines of C could read SHELL and use fork and exec to use whatever shell SHELL points to (using getenv in C) rather than system call with /bin/sh -c. However, I am injured and tired just now (difficult to sleep and concentrate) so not sure I will get round to that try. I'm only really guessing since my quick glance at the gtkdialog source code has been only that, but maybe just need a quick fix around line 585 of gtkdialog.c, but there may well be more to it.
https://github.com/01micko/gtkdialog/bl ... tkdialog.c
Effectively, you end up needing something like:
changed to
or whatever, say, SHELL says the shell should be.
But to be robust, there is more to it, cos the parent should then wait for the child process to terminate and more. Basically needs a new C function call, which is a modified copied of existing system.c (though a much simpler, few lines of code: check SHELL, fork, exec, as above would maybe do in practice...).
EDIT:
One potential problem might be that the shell executed might need to be passed an appropriate environment (variables) so other form of exec maybe needed (I don't know off the top of my head, but maybe execle or execve). One quick explanation of all these different exec calls is given on Wikipedia:
https://en.wikipedia.org/wiki/Exec_(system_call)
(I can't get that link to format properly as a url, sorry. url tags just make post invisible).
wiak
Code: Select all
execl("/bin/sh", "sh", "-c", command, (char *) NULL);
Code: Select all
execl("/bin/bash", "bash", "-c", command, (char *) NULL);
But to be robust, there is more to it, cos the parent should then wait for the child process to terminate and more. Basically needs a new C function call, which is a modified copied of existing system.c (though a much simpler, few lines of code: check SHELL, fork, exec, as above would maybe do in practice...).
EDIT:
One potential problem might be that the shell executed might need to be passed an appropriate environment (variables) so other form of exec maybe needed (I don't know off the top of my head, but maybe execle or execve). One quick explanation of all these different exec calls is given on Wikipedia:
https://en.wikipedia.org/wiki/Exec_(system_call)
(I can't get that link to format properly as a url, sorry. url tags just make post invisible).
wiak
Last edited by wiak on Thu 24 May 2018, 06:23, edited 2 times in total.
@wiak, I use the following scripting pattern to work around the lack of export -f in non-bash Bourne shells, and keep all sub-functions in a single file. As far as my testing goes, it works for dash, ash, bourne sh, and bash. It should work for ksh (untested). Save to file, chmod +x file, run: dash file, see:
hi
there
done
I think this is more portable as far as gtkdialog scripting than changing the underlying system call. Of course, your gtkdialog XML needs to call "$0" @func instead of just "func". This pattern isn't specific to gtkdialog programming, it works for any script for which you want to keep exported functions inside the main file.
hi
there
done
Code: Select all
sub_func() { foo; echo "$@"; }
foo() { echo $VARIABLE; }
VARIABLE=hi; export VARIABLE
#Main body
case $1 in
@*) sub=sub_${1#@}; shift; $sub "$@"; exit $? ;; # relay sub_func'ions
# add cases for typical script option parsing, i.e., --help, -x, etc.
esac
# ...
if true; then
# call sub-function (fork)
"$0" @func there
# process $? from @func if needed
fi
# ...
echo done
Last edited by step on Thu 24 May 2018, 19:49, edited 1 time in total.
[url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Fatdog64-810[/url]|[url=http://goo.gl/hqZtiB]+Packages[/url]|[url=http://goo.gl/6dbEzT]Kodi[/url]|[url=http://goo.gl/JQC4Vz]gtkmenuplus[/url]
Ah yes, step, that's exactly the type of pattern I jotted down myself today as a workaround - i.e. using case just as you have done (almost... I put all my functions in a totally separate but single file). Better than tons of little external function scripts. Thanks.
The way you've organised it is much better than my rough draft though. I may well use what you suggest!
wiak
EDIT: Having said that, there is no reason I can see that modifying gtkdialog.c itself to use appropriate sh, as determined by SHELL variable contents, wouldn't likely be completely portable (though I don't know intracacies of ksh and so on, so I might be wrong). If so, these kind of workarounds would no longer be required.
The way you've organised it is much better than my rough draft though. I may well use what you suggest!
wiak
EDIT: Having said that, there is no reason I can see that modifying gtkdialog.c itself to use appropriate sh, as determined by SHELL variable contents, wouldn't likely be completely portable (though I don't know intracacies of ksh and so on, so I might be wrong). If so, these kind of workarounds would no longer be required.
- misko_2083
- Posts: 114
- Joined: Tue 08 Nov 2016, 13:42
Small typo @stepstep wrote:Save to file, chmod +x file, run: dash file, see:
hi
there
done
Code: Select all
sub_func() { foo; echo "@"; } foo() { echo $VARIABLE; } VARIABLE=hi; export VARIABLE #Main body case $1 in @*) sub=sub_${1#@}; shift; $sub "$@"; exit $? ;; # relay sub_func'ions # add cases for typical script option parsing, i.e., --help, -x, etc. esac # ... if true; then # call sub-function (fork) "$0" @func there # process $? from @func if needed fi # ... echo done
sub_func() { foo; echo "$@"; }
@wiak Is it safe to run any string from enviroment variable SHELL?