zigbert wrote:Bugreport
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:
Code: Select all
<action>[ $FORMAT = flac" ] && disable:BITRATE</action>
or
Code: Select all
<action>[ $FORMAT = flac" ] && <action>disable:BITRATE</action></action>
I'll add a feature request for it.
zigbert wrote: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.