Thank you for explaining the settings for "update-policy". I tried various values, but nothing happened until I raised the value. I then got a delay... but still it only works when clicking middle mouse button.

I could add a delay in the bash code to wait for the value is stable (user has settled on a new value) before executing the rest on the function. This would be a bad substitute since it wouldn't act snappy.

edit:
I must add that I refresh the <hscale> every second by executing <actions> of a <progressbar>. Maybe this conflicts with "update-policy".
........
Ok, I removed the "update-policy" in my code, but nothing changed. Also removed the block-function-signals="true", but no go.

1.)
With the code below I have to click the mouse-middle-button to get the correct value of $PROGRESS. Left click always return 0 or 100.

Ok, I'm looking at your post again. Let's start with 1

I've been playing with my example and middle-clicking the bar and it instantly moves the slider under the mouse. Left clicking the bar is similar to paging up and down and the page size depends on, well I'm not sure really, but scale-step="1" seems to give it some precision. I have also noticed that you are using the default 0 to 100 step 10. Is that OK? You can use scale-min="0" scale-max="240" scale-step="1" or something if you want.

[EDIT] I've been testing my example again and the page size when left-clicking the bar is in units of 10x the step, so if you use the defaults of scale-min=0, scale-max=100 and scale-step=10 then left-clicking the bar will go from 0 to 100 to 0. Is this what you mean?

[EDIT2] OK, I think I know what's going on You are refreshing the value every second, and because you are using 0 to 100 step 10, when you left-click the bar the slider goes right to the ends and returns either 0 or 100, and then refreshing restores its value Right? If that is the case then you need to use scale-step="1" or something. If you are playing music, shouldn't you be setting scale-max to the length of the track in seconds or have you decided to use 100%.

2.)
The action is executed when mouse is pressed down (not released as I expected). This makes it impossible to drag the slider to a given position and then execute the <action>. I tried to include <action signal="released"> as in the <button> widget, but it failed.

The value_changed signal is emitted when the value changes. If you use scale-step="1" and left-click the bar somewhere, the slider will move and repeat-move and as the value is changing it will emit value_changed signals. Using the update-policy="1" will enable you to left-click the bar or drag the slider and no signal will be emmitted until you release the mouse (I just tried it). I think though that you may now be aware of this one.

[EDIT] Ok, I think we were posting at the same time. It's great that you got it to work Well done. I'm looking forward to seeing it in action

Fixed the exclusive default signal i.e. it wasn't possible to have a default action and another action specifying the same signal.

Removed the odd manual emission of the default "changed" signal when using the fileselect function i.e. inserting text.

Fixed widget_entry_refresh which wasn't distinguishing between <input> and <input file> directives (file loading wasn't implemented anyway) and then attempted to execute the <input file> if declared.

Added support for the save function (now a full action function set).

Added support for the custom tag attribute "block-function-signals".

Added support for the "activate" signal emitted from pressing Enter.

Added support for the "icon-press" and "icon-release" signals, actually prefixed with "primary-" or "secondary-" to distinguish between them.

Features Supported by Later Versions of GTK+
Some widget properties and features may be unavailable to you if you are using an older version of GTK+, but they will not prevent you from compiling and using Gtkdialog as Gtkdialog checks the user's version of GTK+ at compile time and removes support for unsupported properties and features to enable compilation against different GTK+ versions. Ultimately though, the features that the application developer chooses to implement and therefore the version of GTK+ that his application requires is not within my realm of operation.

2.18 for the redefinable "invisible-char" in password entries.

2.16 for the "caps-lock-warning" icon in the password entries.

2.16 for the primary and secondary icons and signals.

2.16 for the progress bar.

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

It would hugely useful if you could come up with a way to stay compatible with gtk+-2.16 -at compile-time, at least. What I mean is a way to disable those features which require later versions of gtk. Or, if you could supply patches which could be used to remove just those features so one could still compile against gtk-2.16 for older systems, or whatever.

I've built a system which intentionally sticks with gtk+-2.16 since ti's the last gtk2 version which has a stable API and no glaring bugs. The next version of my system will probably use the last gtk2 version -hoping that some major distros will also stick with gtk2 and keep patching up bugs for awhile.

It would hugely useful if you could come up with a way to stay compatible with gtk+-2.16 -at compile-time, at least. What I mean is a way to disable those features which require later versions of gtk. Or, if you could supply patches which could be used to remove just those features so one could still compile against gtk-2.16 for older systems, or whatever.

I've built a system which intentionally sticks with gtk+-2.16 since ti's the last gtk2 version which has a stable API and no glaring bugs. The next version of my system will probably use the last gtk2 version -hoping that some major distros will also stick with gtk2 and keep patching up bugs for awhile.

Hi amigo

Which means then that you haven't been compiling Gtkdialog from SVN and trying the examples

What you've said I'm already doing. When I code support for a newer feature I wrap it in a GTK version check macro which simply removes the code if GTK is too old. Later GTK properties (tag attributes) of widgets that aren't supported by the user's version of GTK are ignored/ineffective; I don't have to do anything there.

I don't think that I should be castrating later GTK versions, instead it should be the responsibility of the application developer which features he is going to support, and I have made an effort to explain which features are supported by newer versions. After all, Gtkdialog is a Linux project, not written solely for one distro.

I'm also expecting folk to alert me to any compilation issues [which I may have missed] which I can resolve.

Thunor, you are right that I haven't compiled any of your new code. I'm glad that you are already taking care of the backwards-compatibility issues -we don't see much of that around here, so I thought it worth bringing up.

I *will* be compiling your new code pretty soon(on a system with gtk-2.16.6), though, and will gladly notify you if any problems come up.

I appreciate very much that you are keeping gtkdialog alive and extending its' usefulness!

The "official" gtkdialog PET on ibiblio.org 'common' repo is thunor's revision 86 I think. I'm going to upgrade it soon, and I want to put in examples to illustrate the new features, well more examples to illustrate old features also.

The PET has /usr/share/doc/gtkdialog3/examples (in devx), which are the original ones.

I was thinking of adding /usr/share/doc/gtkdialog3/examples_extra.

When I get onto doing that, I will trawl through this thread, but if you want to send any to me, just short examples of a particular feature, not full applications, kindly email them: STARTbkaulerATgmailDOTcomEND
Put "gtkdialog" somewhere in the email title._________________http://bkhome.org/news/

The "official" gtkdialog PET on ibiblio.org 'common' repo is thunor's revision 86 I think. I'm going to upgrade it soon, and I want to put in examples to illustrate the new features, well more examples to illustrate old features also.

The PET has /usr/share/doc/gtkdialog3/examples (in devx), which are the original ones.

I was thinking of adding /usr/share/doc/gtkdialog3/examples_extra.

When I get onto doing that, I will trawl through this thread, but if you want to send any to me, just short examples of a particular feature, not full applications, kindly email them: STARTbkaulerATgmailDOTcomEND
Put "gtkdialog" somewhere in the email title._________________http://bkhome.org/news/

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