KmPlot sliders usage and associated bug

[todd rme]

On Sun, Mar 4, 2012 at 7:59 PM, Anne-Marie Mahfouf
<annemarie.mahfouf at free.fr> wrote:
> On 03/04/2012 06:56 PM, todd rme wrote:
>>
>> On Sun, Mar 4, 2012 at 6:38 PM, Anne-Marie Mahfouf
>> <annemarie.mahfouf at free.fr>  wrote:
>>>
>>> On 03/04/2012 09:02 AM, Rahul Sharma wrote:
>>>
>>> Hi,
>>> I looked into the view.cpp updatesliders() function, and I have arrived
>>> at
>>> the conclusion that the variable needSliderWindow does have a use here. I
>>> think that the control if() statement, in which the bool variable
>>> needSliderWindow is set to true, it checks whether the Slider checkbox in
>>> the left panel (function tab) is checked or not, depending on which it
>>> sets
>>> the checkable bool of m_menuSliderAction to true.
>>>
>>> And I think the intention was that when the Slider checkbox is checked,
>>> the
>>> slider window should pop-up and when it is unchecked slider window should
>>> hide.
>>>
>>> So the first thing would be to fix this.
>>> Should closing the Sliders window uncheck the Slider checkbox? What
>>> should
>>> happen when the Sliders window is closed?
>>> Also why is there the possibility to check Slider when there is no Slider
>>> use? Like in a function witn no parameter.
>>>
>>> Anne-Marie
>>>
>>>
>>> And as you were saying there is no need to have that as a toggle. That
>>> can
>>> be done in another way and just setting
>>> m_menuSliderAction->setchecked(true)
>>> does not fulfill the aim here.
>>>
>>> And one more thing I wanted to point out here is about my patch.
>>> Actually,
>>> when I looked into the code of the ksliderwindow.cpp, I found out that in
>>> order to handle the check of the m_menuSliderAction there is a slot
>>> called
>>> closeevent which emits a windowclosed signal when the window is closed,
>>> which is only called when closeevent is called. But the close button of
>>> the
>>> slider window uses a done() (perhaps inheritted from QDialog as far as I
>>> remember) to close the window which does not emit a closeevent and the
>>> the
>>> m_menuSliderAction becomes faulty, so I just fixed that.
>>>
>>> -Regards
>>>  Rahul Sharma
>>>  (NUM_1 on irc.freenode.net)
>>
>> Slightly off-topic, but why is this is a window and not a dock panel?
>> Doc panels can be pulled off and used as separate windows, but they
>> can also be integrated into the GUI.
>>
> We are trying to find out the use of this Sliders dialog. As I said, it is
> not needed in plots without parameters so a dock for this would take space
> without any purpose. Dialogs do not have the same scope than docks and
> probably only a fraction of users make use of the sliders.
>
>
> Anne-Marie

Docks are not permanent, they can be opened and closed.  Look at
dolphin, it has 5 docs, only 1 of which is enabled by default if I
remember correctly.  The other can be enabled or disabled at will from
a menu or toolbar button.

In this regard it would be little different from the current system.
Someone clicks the menu item to open it, and it opens in a dock.  Then
if the person clicks the menu item again, or clicks the close button
on the doc, it disappears and the other docs reshape to fill the
space.

Further, the doc could be pulled off to act as a standalone window if
you want, meaning users can have it behave identically to how it
currently behaves.  So we lose nothing, but we gain improvements in
window management.

-Todd