dk / Prima

prima.eu.org
Other
108 stars 27 forks source link

Make "drops" style as default in Prima::Spinner and add "indeterminate" mode to Prima::Gauge #53

Closed MaxPerl closed 7 years ago

MaxPerl commented 7 years ago

Hello Dmitry,

I would like to make the drops style as the default style. I forwent doing this first because my version of drops looked not very good. But after your enhancement the drop style is fantastic.

I would also like to propose to change the style name of the "yinyang" style to "spiral" because I think "yinyang" was not very meaningful and describes the style not very good.

Lastly I added pod Docu for the spiral style and improved minor misspelling..

Best wishes, Max

MaxPerl commented 7 years ago

Second pull request: As promised I added indeterminate mode to Prima::Gauge (similar to the indeterminate mode in TK or the pulse command in Gtk3). Perhaps it would be a good idea to rename the widget to Prima::Progressbar or create a new widget with the name Prima::Progressbar.

Sorry for posting it in one Pull request. I don't know how to split it. I am not so familiar with github...

MaxPerl commented 7 years ago

Enclosed you find a simple example for the indeterminate mode:

use Prima;
use Prima::Application;
use Prima::Sliders;

my $mw = Prima::MainWindow->new(
        size => [150, 50],
        text => 'ProgressBar Example');

my $progressbar = $mw->insert(
    Gauge,
    indeterminate => 1,
    origin => [0,0],
    height => 10,
    growMode => gm::GrowHiX,
);
$progressbar->width($progressbar->owner->width);

run Prima;
dk commented 7 years ago

Hi,

I don't like renaming the widget for the back-compat reasons, and creating a widget just for naming sake, well, too .. I like though the 'indeterminate' addition!

dk commented 7 years ago

Wait,

I'm not really sure I get it. What I do understand is:

What I don't understand is:

Also there are other things:

I think these have to be addressed

/dk

MaxPerl commented 7 years ago

Hello Dmitry,

I don't like renaming the widget for the back-compat reasons,

Sorry. This concerned the Prima::Gauge or Prima::ProgressBar question. Of course, this is a very good reason.. And I agree completely with this..

why do you need to add extra painting instead of just dynamically modifying value?

I don't know whether I understand your question. I need an extra painting because the left or bottom side of the slider has to move with the slider. therefore I have to calculate the X or Y position of the left or top bound of the slider which is done by $left_bound = $complete - ($self->{sliderLength} * $y [or $x] / $range + 0.5)

I don't think creating Timer always is a good resource use - I'd propose to create it only when needed, because determinate Gauges never use them

Good idea! I will think how I can this implement.

{direction} etc shouldn't be user settable properties

This is a good idea, too.

dk commented 7 years ago

On Sun, Feb 12, 2017 at 12:03:59PM -0800, MaxPerl wrote:

I don't like renaming the widget for the back-compat reasons, No problem. This is of course a good reason and in the end it is your decision. Nevertheless in the question of the Spinner widget I think the back-compat argument is no knockout argument because the widget is new and no version is yet shipped with the new Spinner widget. But it only was a proposal. I can also live with the circle style as default...

Are we talking about Gauge or Spinner? My argument was about the former; the latter is okay to rename

why do you need to add extra painting instead of just dynamically modifying value?

I don't know whether I understand your question. I need an extra painting because the left or bottom side of the slider has to move with the slider. therefore I have to calculate the X or Y position of the left or top bound of the slider which is done by $left_bound = $complete - ($self->{sliderLength} * $y [or $x] / $range + 0.5)

Ah yes, my bad, sorry. I ran the example and I see this now. That's okay then.

I don't think creating Timer always is a good resource use - I'd propose to create it only when needed, because determinate Gauges never use them

Good idea! I will think how I can this implement.

{direction} etc shouldn't be user settable properties

This is a good idea, too.

For my taste it is better to be changed to 0/1 rather than left/right, it is confusing if the gauge is vertical).

-- Sincerely, Dmitry Karasik