Trying to sort out the bugs for pMusic 3, I have met another gtkdialog-issue.
While the previous mentioned (use reorderable="true" in <tree>) is not documented in the gtkdialog reference guide, this one is:
Somehow, hidden <entry> does show up.
This happens only if <entry> is set invisible in the first place. After executing 'show' and then 'hide', the <entry> is not visible anymore

Last year we discussed the tree widget and the "reorderable" gtk property: the tree widget uses the wrong model (tree model) and you'll end up dragging rows onto other rows and they'll disappear into branches that you can't reach, so it doesn't work as expected.

"reorderable" is not a gtkdialog custom tag attribute, it's a gtk property so it's not documented within gtkdialog's widget reference although the gtk properties are linked to.

The strange behaviour with the hidden entry widget I have experienced myself. This is not new, I have tested this back to gtkdialog3-0.7.20-pe-1 so it's likely always been like that but you've never been able to show widgets before so now it's an issue. gtkdialog uses the gtk function gtk_widget_show_all() to show (make visible) all the widgets at start-up, then any tag attributes that are gtk properties are applied, so visible="false" is a gtk property which hides the already shown widget. I have experienced this resulting in some weird behaviour just as you have with the entry widget although some widgets seem to hide cleanly. gtk is responsible for rendering the widgets so if it leaves artifacts then that's how it is, but I can look into showing widgets individually which might solve this. I say "artifact" because it is visible="false" even though you can see it (try typing into it and then show it).

zigbert wrote:

What does the <input> control of the <menu> widget?

true or false although pretty pointless. It exists because the menu widget is actually a menuitem with a submenu so the interface is the same as the menuitem widget.

zigbert wrote:

Would it be possible to combine the builtin functions with other <actions>. Something like:

I have no idea if this is a bug, a limitation or just how stuff are supposed to work. - But I will mention it anyway

<comboboxentry> is only returning the signal for key-release-event.
Other signals seems to be 'dead'

I detected key-press-event, key-release-event, hide, show, activate and changed. The entry part is a child widget and I'm guessing that you're expecting to be able to detect the same signals as an entry widget. The process of connecting up the common GtkWidget signals is automated so gtkdialog is connecting them to the comboboxentry widget, not the child entry widget although this could be done manually within the widget_comboboxentry.c module. What signals do you want? I can add a feature request for it.

I'm not looking to do another massive update. I'd like to do a small 0.8.3 update because I've got another project I want to continue. I'm still a happy Puppy user so I'll be around now and then but I think some people more involved with Puppy should volunteer to be project committers because it's an important fundamental component of Puppy and life moves on. At some point somebody may require a modification to the code and nobody except me will be able to commit and I won't be around.

I want to ask experts:
Probably-whether in gtkdialog (the old version 0.8 or 0.5) to receive from combo-boxes a string of parameters for a call of the external program?
I have placed the question on page:
http://murga-linux.com/puppy/posting.php?mode=quote&p=661379
Post subject: make string of argements for scrot-program

I have solved this task with the help gcc + GTK2 (37 KB).
But I want to reduce the size of the program and to eliminate possible errors in the absence of libraries.
Therefore the script in this case is more preferable (1.7 KB).
But the answer there it will not be probable.

Therefore I ask now here.
Certainly it would be desirable to hear judgement such as thunor, zigbert ...
Certainly if this question is of interest for developers gtkdialog

I'm guessing that you're expecting to be able to detect the same signals as an entry widget. [...] What signals do you want? I can add a feature request for it.

You got me right. I was looking for a button-release-event to avoid <action> to execute when clicking in the entry widget.

Thank you for your very clear explanations. I admire your knowledge of what your doing. You show yourself as a very skilled person.

Please remember my nr. 1 Puppy rule: If things are not funny anymore, go do something else. When somebody start yelling about lack of critical features or serious bugs, I very soon get pissed. Puppy is NOT SERIOUS, it should be pure fun. I take a break, and come back when my inspiration is peaking.

I am very thankful for what you have done with gtkdialog. There will always be limits, and I build guis out of what's available. pMusic is experimental code to push the limits of gtkdialog. It is a learning project.

There are multiple formats for the input data and multiple methods of inputting it which can also be combined, so the data has to be output as it is in the tree widget -- raw -- and you'll need to process it with "cut" to match it to the format that you're going to use to reinput it.

It's now possible to prevent the exporting of declared variables by using <variable export="false">VARNAME</variable>.

For example you have a text widget which you've named TEXT and it contains a document from an <input> or <input file> directive and you will be refreshing it at some point, but you're not interested in having TEXT="the-entire-contents-of-the-document..." exported to the shell every time a widget emits a signal so now you can disable it to increase performance.

Thunor,
I am new to this thread and have not yet examined the pages since 31. I think I need your help to understand and resolve what appears to be an unexpected way of exiting from a dialog.

I am integrating Frisbee into the mainstream puppy configuration, somewhat successfully. I saw this problem during testing with the recent betas of Precise pup 5.4.1 but cannot re-create the situation now. In 5.4.1 I see no problem, because the Frisbee dialog window always exits as expected, returning control to the script that invoked gtkdialog3. (We are starting Frisbee by way of the "connect wizard's" "Wired or wireless LAN" option.)

However, peebee and others see the "exit" (via the "Exit" button) failing the first time the dialog is used. Subsequent uses of the Frisbee script exit normally. When I was seeing that problem, I could repeat it if I chose another network tool, exited it, then chose Frisbee again. Furthermore, when Frisbee exits normally, another dialog appears to allow the user to try another tool. When the exit process malfunctions, that dialog does not appear, implying that not only did gtkdialog not return to its caller, it also bypassed the caller's caller. That behavior suggests that something actually kills the process running the dialogs.

To gather what evidence I could, I added trace logging before and after the invocation of gtkdialog3, Here is the code at the end of the Frisbee script, showing the definition of the "exit" button, the added logging and the code that is expected to execute following the use of gtldialog3:

As a second experiment, peebee ran Frisbee from the command line and saw it hang. I ran the same test and saw Frisbee return to the command prompt, as one would expect. That is consistent with his seeing a problem whereas I do not get it, even though we have installed the same set of packages to implement the integrated Frisbee.

peebee wrote:

Don't know if this helps... but I tried running Frisbee from a terminal on Precise - messages are below....
but when I clicked Exit having setup a wifi connection, Frisbee did not finish - the terminal did not return to the # prompt and I had to type cntrl-c to make Frisbee finish.
There weren't any messages created when this happened.

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?

3. And, of course, please share any other thoughts you might have about this apparent malfunction, particularly if you have already addressed this problem in your releases after precise's gtkdialog version 0.8.0.

For reference, I attach the complete Frisbee script in case it holds other clues. Thank you for whatever you can do to help me troubleshoot this issue.
Richard

Don't know if this helps... but I tried running Frisbee from a terminal on Precise - messages are below....
but when I clicked Exit having setup a wifi connection, Frisbee did not finish - the terminal did not return to the # prompt and I had to type cntrl-c to make Frisbee finish.
There weren't any messages created when this happened.

I'm going to guess that this is the old "not exiting via the window manager" bug which was fixed in gtkdialog 0.8.2.

Gtkdialog can exit in two ways and one of those used to be dodgy but there was a workaround which was commonly used and it is this:

Code:

...
<action signal="hide">exit:EXIT-WM</action>
</window>

Try that -- I reckon that'll fix it

Actually all gtkdialog applications that are using < gtkdialog-0.8.2 should be including that fix on their closing window tag.

. . .
Actually all gtkdialog applications that are using < gtkdialog-0.8.2 should be including that fix on their closing window tag.

Thunor,
Thank very much for that info. Rather than expect all gtkdialog developers to update their code, I would prefer to upgrade woof to use 0.8.2 or whatever might be even more stable. Do you have any qualms about making 0.8.2 official? I see that there are further considerations about 0.8.2, so should I wait for another version that would be targeted for woof?

I could add it to my woof-update package to get things started. For that to be accepted for woof, I expect the matching source code should be made available for Barry's puppy source-code library.

Now, after reviewing the previous few thread pages, I conclude that you provide the source code but that others (i.e., oldyeller) build the pet package. I guess I should simply provide a link to oldyeller's 0.8.2 download message for Frisbee-experimenters to include in the pertenent set of packages.
Richard

What I meant to say was that new gtkdialog application developers would benefit from including that fix in their projects from the outset, but then again the issue is fixed in 0.8.2 which I'm sure will be included in forthcoming Puppy releases, so possibly it's not worth worrying about. I am not suggesting that all existing gtkdialog apps require updating.

* dons programmers cap again *

I [currently] write the source code (there are contributions by others too) and release source code packages on the gtkdialog website and then folk do whatever it is they want to do with it. On Slacko 5.3.3 for example, gtkdialog4 and gtkdialog3 are symlinks to gtkdialog (0.8.0) in /usr/sbin and I imagine this could differ across Puppy flavours, therefore packaging gtkdialog is something that involves other knowledgeable individuals.

I'm definitely no programmer (hardly a distro builder ) but I took on the decision to rationalise gtkdialog in slacko-5.3x. When I started alpha development Thunor had just started redevelopment of gtkdialog and the first thing I did was convert all the old gtkdialog2 scripts to use the new version. The patched Patriot gtkdialog-0.7.1 had a bug with piping to stdout.

Next I removed the 0.7.1 version completely. Only a few things were broken. Among them were the poor calls to stock icons and sensitivity of some password entries. These were quickly fixed and accepted upstream.

Now, I'm still living close to the bleeding edge in slacko-5.4. This is mainly to facilitate Pmusic 3, surely the most comprehensive collections of shell using gtkdialog. There have been no reports of any detrimental effects.

The packaging I use just follows Puppy's "traditional" path for gtkdialog. As far as I know it's always been under /usr/sbin so manual intervention in packaging is needed. In a woof build or a running installation the post install script offers the user a choice of whether to clobber gtkdialog3 and link it to gtkdialog or leave as is.

I'd have no doubt old yeller's package binary is fine, but I would just check what it links to if anything. I think my approach is reasonably sane, as the "gtkdialog" executable was always missing from older puppies. The examples never worked out of the box. The pseudo convention of the day is to call anything wanting at least gtkdialog-0.8.0 with "gtkdialog4". Zigbert has made a pre-emptive decision to support gtkdialog5! I do hope we don't get to that point.

In my case, I recently updated gtkdialog in Lupu 520.
I made the mistake when installing the PET packages of installing the gtkdialog Pet before installing the VTE pet.
So in that case, all the scripts that used gtKdialog stopped working including the option to use puppy package manager to uninstall that version of gtkdialog.
Luckily, I had an old version that I copied in replacing the one I had installed and then was able to install the VTE pet, reinstall the updated gtkdialog Pet and the DOC pet for it.
But If I had not been able to recover that way, I would have crippled Puppy and in effect, lost my lupusave file.

So if the developers include an updated gtkdialog in their Puppy releases, VTE should also be included.

That is unless someone knows something I do not.
BTW, the version I upgraded to was subversion 473.

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