The two sliders you show are made by function funcscaType3Create.
I have been able to make them full sliders by modifying the scale-max value in the function.
But I am almost sure that that function was made for a specific purpose.
So I would like to see explanation of it's use to clarify it.

Nice (or actually not nice) to see that your vertical markup is all over the place, similar to mine You also seem to have missing marks.

[EDIT] I've just noticed that my Polished-Blue screenshot has missing marks too, so I'm guessing that that's a theme issue also (there should be three marks on the 2nd and 3rd scales only, the 3rd scale being staggered top/bottom, left/right).

I think it's possible that currently the markup isn't very stable which would explain why I haven't yet found an application that's using it.

It's a "fill-level (e.g. prebuffering of a network stream)". It stops somewhere near the middle because that's where the fill-level is If you set restrict-to-fill-level="false" it won't stop at the fill-level. Admittedly possibly of limited use as we can't adjust the fill-level, but I didn't make this stuff up, they're GTK+ properties and I'm just illustrating what you can do.

Anyway 8-bit, thanks for the screenshot as I can see we're all having the same vertical scale markup problems. Normally I have two distros installed but at the moment I've only got Puppy, so it would be nice to see what it looks like on a non-Puppy distro.

BTW for anyone who's interested in what I'm going to tackle next, I've been reviewing the menu system but it's not designed to cope with submenus -- comparable to the differences between listing a folder and listing a folder recursively -- so I'm going to have a think about it and at the same time hack away at some easier things.

thunor,
thank you for the explanation.
As a test, I changed restrict-to-fill-level in the type3create function from true to false and was able to achieve a full range slider that still remembered it's original position when the refresh button was clicked.
So thank you again.

Understanding helps greatly in writing scripts that utilize these new features you are working on.

Somebody asked me how to use the new features whilst still maintaining compatibility with older versions of Gtkdialog. I guess the way to do it is to check the version of the binary, but it's complicated by the fact that it went from 0.59.8 to 0.6.0, so I came up with this:

Code:

#Change this to gtkdialog2 and gtkdialog3 to test.
GTKDIALOG=gtkdialog

[EDIT2] I think that this is as good as it gets. ${GTKDV[1]}${GTKDV[2]} will equal "5908" for gtkdialog2, "7020" for gtkdialog3 and "7021" and up for gtkdialog. You can easily construct your XML for different gtkdialog versions by testing against ${GTKDV[1]}${GTKDV[2]}.

Code:

#Change this to gtkdialog2 and gtkdialog3 to test.
GTKDIALOG=gtkdialog

The hscale and vscale widget example has been driving my crazy getting it to display right.
So in my usual bunbling way, I added an item to the type2 function.
My result although not correct, does display correctly. Why does it work? Evidently the last item in the type2 function gets placed incorrectly.

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.

I am testing the <hscale> widget in Pmusic 2, and I am having some trouble.

The default signal is "value_changed" which activates itself when slider is moving. My problem is that it does run <action> both when it is refreshed (<action>refresh:HSCALE</action>) from another widget, and when user moves it. My hope is to show progress when refreshing, and jump-in-track-time if user moves the slider. Is this possible? I checked the gtk-scales signals, but couldn't find any answer.

I am testing the <hscale> widget in Pmusic 2, and I am having some trouble.

The default signal is "value_changed" which activates itself when slider is moving. My problem is that it does run <action> both when it is refreshed (<action>refresh:HSCALE</action>) from another widget, and when user moves it. My hope is to show progress when refreshing, and jump-in-track-time if user moves the slider. Is this possible? I checked the gtk-scales signals, but couldn't find any answer.

Hi Sigmund

The "value_changed" signal is emitted when the "value" changes regardless of how. It's getting late and I need to go to bed now, but how about having a custom tag attribute to block signals on refreshes Sounds sensible. I can do it in the morning.

I want to make sure I understand the parameters passed to the type2 function in the hscales and vscales example.
What I have come up with is
$2 is the scale type being either h for horizontal or v for vertical
$3 is the slider width of the scale
$4 is the height of the scale
$5-$7 are the position of the markup left, right, top, bottom, on the slider
For a vertical slider, markup position parameter values passed to function type2 are
0 being left of slider, 1 being right of slider
And for a horizontal slider, markup position parameter vales passed to function type 2 are
2 being top of slider, and 3 being bottom of slider.

Now if this is right, why are the markup tags on the vertical scale being displayed in the wrong place on the slider?
Could it be that gtk2 or pango are not receiving the parameters in a format they expect?

Also, if one plays with the example I posted that displays right and changes any of the parameters for the vscale, it will not display correctly.

I am making progress
block-function-signals="true" works great - thank you.
But I still have some issues

I am trying to control the <action> of hscale.

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.

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.

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