1. Is there a way to add some debug/troubleshooting logging to gtkdialog to help identify where things go awry? Or is there already someplace to find diagnostic info from gtkdialog?

2. Because this seems, to me, to be a case where a data item is tested but is not the expected data, thus producing random results, could you examine the gtkdialog code that handles the "exit" process to look for a possible bug of that sort?

I recommend that you compile gtkdialog yourselves and place some debugging code into it.

Helping other people debug is always difficult because everyone has their own method. I try strace and then pepper the hell out of the code near where strace stops with printfs/echoes of sequential numbers, others use a methodical approach, write test code, step through a debugger/tracer. It all depends on whether you are a programmer, "software engineer" or code hacker... or whatever.

Speaking of compiling gtkdialog, I was contemplating trying to build it for win32, but before I even start I know of at least 1 stumbling block. I don't think windows has popen(), (someone correct me if I am mistaken) but glib has a wrapper that should work on both: g_spawn_command_line_async(s,NULL) or one of its relatives.

thunor, peebee,
I have been away from puppy for almost a full day, so have just now reviewed all that you have accomplished together. Thank you, both, for working the problem. Now it is my turn, to digest the recommendations and evidence, then fix the code.
Richard

To accommodate different coding styles I have allowed anything between "if !file(filename)" to "if ! file ( filename )" and similarly for command(). Technically speaking I am parsing the start of every action directive so you could do <action>if command(cat /some/file) echo "this is pointless"</action> but it would be two processes instead of one which is indeed pointless.

With command() -- just as with <action>shell command</action> -- the widget variables are placed into the shell therefore you could conditionally execute code based upon the value of other widgets.

Both the file() and command() functions are expecting true/yes/!0 or false/no/0 so a file will require this data to be within it and a command will require this data to be echoed to stdout.

Is it intuitive? Does it make sense? Otherwise let me know.

I'm going to update the wiki and widget reference now and maybe tweak a couple of things before putting together a source code package release.

Yeah, this will be handy for lots of things I'm sure. I'm writing an application and I want to do a conditional exit which is now possible, well I guess it was before with the checkbox trick but I think that that laborious trick is now redundant.

I want to do a conditional exit which is now possible, well I guess it was before with the checkbox trick but I think that that laborious trick is now redundant.

As I see it, the checkbox trick is still the best solution where several widgets wants to refresh (parts) of the gui. Ie. in pMusic there are plenty of occasions to update the playlist/window-title/albumart/... (or the trackinfo window that contain heaps of widgets to refresh). Much easier with one checkbox than conditional <action> code in all related widgets.

Regarding the recent conditional execution code, I'm investigating moving it to something like <action condition="if ! command(shellcommand)">function:parameter</action> because it's more integrated into how gtkdialog deals with everything and I'm thinking about the possible expansion of this feature at a later date, so carry on using it but you might have to slightly modify it. Hey, that's what it's like living on the cutting edge

I guess everyone who's written a gtkdialog application will have experienced the following issue although I know that I've become accustomed to working around it -- I'm talking about the escaped double-quotes problem.

When constructing the contents of an action you know that if you wrap the lot in double-quotes then you can't use double-quotes inside unless you escape them, but the escapes (backslashes) remain within the string i.e. there's no processing of these to remove the backslashes from the front of double-quotes so you end up with this:

Code:

<action>"echo \"sometext\""</action>

echoing this:

Code:

"sometext"

The advantage of wrapping the action's contents in double-quotes is that you can split complex actions across multiple lines, but the moment you need to embed double-quotes it all falls apart. The solution to this which most people are aware of is not to wrap everything in double-quotes but to write everything on one long line. Ok, so at least there's a workaround to that problem but it can't be fixed because escaped double-quotes within existing applications should really be escaped escaped double-quotes.

The recently added condition tag attribute belonging to the action directive initially presented me with the problem that the contents of a tag attribute are wrapped in mandatory double-quotes so you can't work around them, but since this is a new feature and would be rather limited if you couldn't properly embed double-quotes, I scan the string and remove the backslash from the front of double-quotes.

So far so good, except that there's some weird stuff going on with backslashes within tag attributes:

The shell correctly removes the escape character from the space in the first action, and the second results in everything up to "text" being cut! I'm sure that the parser rules are responsible for this and fixing it should be achievable, but you should be aware that it exists although if it happens in a condition tag attribute then it'll cut the function name and you'll get a warning message about it being unknown.

if function(argument) will expect "true", "yes" or a value that isn't zero e.g. "-89" or "18" to evaluate as true else it'll evaluate as false.

if ! function(argument) will expect "false", "no" or "0" to evaluate as true else it'll evaluate as false.

Basically what I'm doing here is if function(argument) = "true" and if function(argument) = "false" but in a simpler way.

It's like the existing prefix "if true function:parameter" and "if false function:parameter" for toggling widgets but I've replaced the true and false with functions. I can see though that people will think that "!" is actually notting.

Ok, maybe I should use if function_is_true(argument) and if function_is_false(argument) which is clearer right? I'm going to think about it.

[EDIT] I'm changing it now...

[EDIT2] Checkout/update to r480 please. It's now "if function_is_true(argument)" and "if function_is_false(argument)" which is much clearer.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum