Whilst working on the new spinbutton widget I unearthed a bug in the tag_attributes.c:try_set_property function, the function that is responsible for passing tag attributes that are GTK+ widget properties on to GTK+ to set. The part that was responsible for converting char strings to unsigned integer values wasn't converting to anything, so that's why the "border_width" GTK+ property always appeared to be around 50 -- "0" being ASCII 48, "1" being ASCII "49", "2" being ASCII 50 etc. etc. Therefore the GTK+ "border_width" property now works as expected and this affects quite a few Gtkdialog widgets descended from the GtkContainer class. A short while ago I created the h/vbox and window "margin" custom tag attribute to compensate for this problem but it would appear to be redundant now (I'll leave it in though as it might be being used, but I'll remove it from the documentation).

thunor
Pmusic 2 is taking advantage of your wonderful work. Of course I meet some challenges, and I thought I would share some of them.

1.) H O T K E Y S
If I use <menuitem visible="false" accel-key="0xff52" accel-mods="4"> the hotkey won't work - because visible is set to false. Is this defined by purpose? I see it as a nice way to include hotkeys for other functions than I would like to include to the menus. In this example I want CTRL+up to increase volume level, but find it unlogical to include a menultem as the <hscale> works very well as the gui-alternative for setting volume level.

2.) P R O G R E S S B A R
Pmusic is getting more complex, and some parts of gtkdialog is not friendly to projects like Pmusic. - i.e. I let the main <progressbar> handle the refreshing of
- position of progress <hscale>
- album art for playing song
- play or pause icon in button
- playlist content - to show new items added from external source (like filemanager and external Music-source-window)

The problem is that <hscale> preferable should be updated each second. But this will deselect whatever the user has selected in the playlist <tree>, and that is rather anoying. The best solution for the <tree> would be to refresh only when the user actually adds something, but this won't move the progress <hscale> very often. A solution would of course be to use a unique <progressbar> for the refreshing of the playlist <tree>, but this would steal cpu, and Pmusic is aready using enough cpu-power.

The idea to solve this is hopefully simple:
<input file> is not in use by <progressbar> and could contain a value used in <action>if value refresh:PLAYLIST</action>. In other words; if <input file> contains 'refreshplaylist' (or whatever value) the playlist should be refreshed. Like this one progressbar could be used as a refresh-hub, and gtkdialog would be useful for BIG projects.

The very best would be if the <input file> could hold several values and the <action> activates if one of the values matches. This would make it possible to refresh several widgets, - or just one of them...

3.) C H E C K B O X
Pmusic 2 is close to beta-stage, but still there is one thing that is holding me back from freezing the new graphical theme-standard. You have worked alot with improving the pixmaps in gtkdialog. Still, I am not able to use the <draw-indicator="false"> for <checkbox> with only showing a pixmap (no label). Most audio-players uses only icons on the checkboxes for 'loop' and 'shuffle'. This is not a big thing for me, but I have to decide before I announce the grapical theme-standard for Pmusic 2 as final.

2.) P R O G R E S S B A R
Sounds to me like you need a proper timer widget like the one described here -> http://code.google.com/p/gtkdialog/issues/detail?id=15. I'm working on the spinbutton widget at the moment but I can add the timer widget pretty easily if you want me to.

3.) C H E C K B O X
I can add one of these (togglebutton widget) equivalent to our existing button i.e. with label/stock/icon/pixmap but it'll toggle. If you need this widget as soon as possible then it could be done by the weekend.

2.) P R O G R E S S B A R
Sounds to me like you need a proper timer widget like the one described here -> http://code.google.com/p/gtkdialog/issues/detail?id=15. I'm working on the spinbutton widget at the moment but I can add the timer widget pretty easily if you want me to.

If the timer widget will use less cpu than than a <progressbar> it could be a solution.

thunor wrote:

3.) C H E C K B O X
I can add one of these (togglebutton widget) equivalent to our existing button i.e. with label/stock/icon/pixmap but it'll toggle. If you need this widget as soon as possible then it could be done by the weekend.

In the Puppy world we should never rush . Please consider it as a suggestion, and do what you feel like. I will sure use a toggle-button if it exist. - If not, I will use the already working checkbox. I can release the Pmusic beta and make a note about the not finished theme-standard.

Updated 2011-08-10 16:34 to illustrate that it's effectively an entry widget with an attached h/vscale widget.

The default signal is "value-changed", emitted when the range value changes.

The "changed" signal is emitted when typing into the entry.

The "activate" signal is emitted when the user activates the entry with the Enter key.

"range-min", "range-max", "range-step" and "range-value" are custom tag attributes that accept double precision floating point numbers (the GTK+ "digits" property specifies the number of decimal places that are displayed within the value).

Use either the "range-value" custom tag attribute, the <default> directive, the <input> directive or the <input file> directive to set the spinbutton's value.

Use the custom tag attribute block-function-signals/block_function_signals="true/yes/1" if you want to isolate signals originating from user widget manipulation from the refresh function.

There are no GTK+ version requirements for this spinbutton widget but there are for some of the entry properties, therefore you should see this post regarding those.

You can see in the terminal that spb1 executes action functions at start-up and this is due to GTK+ emitting both "changed" and "value-changed" signals on application of the "digits" property. Just to note that it's GTK+ doing this on widget realization and not Gtkdialog so I'm not in a position to do anything about it.

<spinbutton> widget example:

Code:

#!/bin/sh

# NOTE: This example requires at least gtkdialog-0.7.21 (please visit
# http://code.google.com/p/gtkdialog/). Additionally if you are using
# Puppy Linux then you may find that an historical version of gtkdialog
# already exists in /usr/sbin, and if that is the case then you should
# modify the shell variable below to point to the new gtkdialog binary.

Instead of 4 buttons of "Enable", "Disable", "Refresh", and "Save",
there would be 3 buttons.
The "Disable" button with icon would be shown and when clicked on besides disabling the entry box, would change to a "Enable button with icon".
Each time it was clicked that button would change to it's opposite button and also change to enable or disable the entry box.
It would allow making a smaller application window that still functioned as it should.

I thought I saw an example of moving items inside a <tree> widget. I am talking about my example in the tips-thread. Thunor (I think) showed how it could be done by using gtk-options. Do you know where to find this?

Damn it, how hard can it be to write correct. I have to repeat myself:

I thought I saw an example of moving items inside a <tree> widget. I am NOT talking about my example in the tips-thread. Thunor (I think) showed how it could be done by using gtk-options. Do you know where to find this?

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