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, 02:47
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
GtkDialog - tips
Post new topic   Reply to topic View previous topic :: View next topic
Page 85 of 95 [1420 Posts]   Goto page: Previous 1, 2, 3, ..., 83, 84, 85, 86, 87, ..., 93, 94, 95 Next
Author Message
MochiMoppel


Joined: 26 Jan 2011
Posts: 1619
Location: Japan

PostPosted: Sun 04 Mar 2018, 22:26    Post subject: Re: Something that I just see now  

mister_electronico wrote:
<tree hover_expand="true" hover_selection="true">

hover_expand ? Since row expansion is not implemented in gtkdialog this should have no effect whatsoever. Does it work for you somehow?
Back to top
View user's profile Send private message 
mister_electronico


Joined: 20 Jan 2008
Posts: 960
Location: Asturias_ España

PostPosted: Mon 05 Mar 2018, 08:12    Post subject: 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.
Back to top
View user's profile Send private message Visit poster's website Yahoo Messenger 
technosaurus


Joined: 18 May 2008
Posts: 4834
Location: Kingwood, TX

PostPosted: Sat 07 Apr 2018, 21:04    Post subject:  

In case anyone is interested in adding some graphics to bash scripts:
https://developers.slashdot.org/story/18/04/07/0035203/programmer-unveils-opengl-bindings-for-bash

_________________
Check out my github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
Keef


Joined: 20 Dec 2007
Posts: 913
Location: Staffordshire

PostPosted: Sun 08 Apr 2018, 14:52    Post subject:  

...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.
CmdlineGL.jpg
 Description   
 Filesize   19.68 KB
 Viewed   375 Time(s)

CmdlineGL.jpg

CmdlineGL-2.jpg
 Description   
 Filesize   15.63 KB
 Viewed   378 Time(s)

CmdlineGL-2.jpg

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

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

PostPosted: Sun 08 Apr 2018, 19:11    Post subject:  

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.


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.

wiak
Back to top
View user's profile Send private message 
don570


Joined: 10 Mar 2010
Posts: 5147
Location: Ontario

PostPosted: Wed 09 May 2018, 14:56    Post subject: 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

_________________________________________________________
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Wed 23 May 2018, 00:48    Post subject:  

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


Joined: 26 Jan 2011
Posts: 1619
Location: Japan

PostPosted: Wed 23 May 2018, 04:33    Post subject:  

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

Quote:
and changes to variables in child processes do not get passed back by default to the parent bash process.
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.

Quote:
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).
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.
What output do you get from this bash/gtkdialog script when you run it with a dash system shell?
Code:
#!/bin/bash
echo '<button label="Print shell"><action>echo $0</action></button>'|gtkdialog -s
I would expect that the output is 'sh'.
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Wed 23 May 2018, 06:10    Post subject:  

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.

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.


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.

wiak
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1619
Location: Japan

PostPosted: Wed 23 May 2018, 10:35    Post subject:  

wiak wrote:
Obviously if your system sh points to /bin/bash you have no problems with your bash/gtkdialog programs.
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.
Quote:
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.
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?
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Wed 23 May 2018, 13:26    Post subject:  

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?


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.

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

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

PostPosted: Wed 23 May 2018, 13:34    Post subject:  

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

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

PostPosted: Wed 23 May 2018, 13:56    Post subject:  

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


Joined: 26 Jan 2011
Posts: 1619
Location: Japan

PostPosted: Wed 23 May 2018, 21:18    Post subject:  

wiak wrote:
Had gtkdialog been itself created to use bash rather than sh the problem would not exist.
I would be happy had it been created to use at least the system shell, which apparently it does not.
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.
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Wed 23 May 2018, 22:14    Post subject:  

MochiMoppel wrote:
wiak wrote:
Had gtkdialog been itself created to use bash rather than sh the problem would not exist.
I would be happy had it been created to use at least the system shell, which apparently it does not.
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:

Code:
#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.


What would fix the issues, when using gtkdialog with bash, would be if /bin/bash -c were directly used instead of /bin/sh -c and, yes, more flexibly, if gtkdialog would read in the shell environment variable SHELL and adjust the actual shell used with -c accordingly that would be close to ideal. But it doesn't do the latter.

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/blob/master/src/gtkdialog.c
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 85 of 95 [1420 Posts]   Goto page: Previous 1, 2, 3, ..., 83, 84, 85, 86, 87, ..., 93, 94, 95 Next
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.1774s ][ Queries: 13 (0.1007s) ][ GZIP on ]