#83 add scale widget

[PhilippMDoerner]

First draft of the Scale Widget and a single example. I'd first debate whether it is fine as is and once we have I'd add examples to the widget file

[can-lehmann]

Some general notes:

• Before merging you need to add your example to the examples/README.md file. You also have to add a screenshot for it. Ideally this screenshot is taken at 200% screen resolution (see gnome setting / displays), but displayed at half its width, so it looks good on devices with high screen resolutions. (use the existing entries in this file as a guide)

• Regarding code style: See the style guide, mainly the following:

  Imported Procedures: Procedures imported from C code using {.importc.} should always be called using myProc(argument0, ...).

• Once everything is finished, please rebuild the widget docs (see CONTRIBUTING.md).

[PhilippMDoerner]

Actually do you have a particular feeling about float vs float64? Mostly because float implicitly is float64 on basically any reasonably modern system and I don't think I consistently used float64 everywhere when typing things.

(Also I posted a thing on discord in the appdev channel on expanding the widgets to have editable controls for basically any property a widget has in the examples, I dunno if you read that one, was a suggestion for a possibly new issue which may be useful for newcomers to the project)

[PhilippMDoerner]

Some general notes:

* Before merging you need to add your example to the `examples/README.md` file. You also have to add a screenshot for it. Ideally this screenshot is taken at 200% screen resolution (see gnome setting / displays), but displayed at half its width, so it looks good on devices with high screen resolutions. (use the existing entries in this file as a guide)

* Regarding code style: See [the style guide](https://github.com/can-lehmann/owlkettle/blob/main/CONTRIBUTING.md#style-guide), mainly the following:

Imported Procedures: Procedures imported from C code using {.importc.} should always be called using myProc(argument0, ...).

* Once everything is finished, please rebuild the widget docs (see CONTRIBUTING.md).

I have done so and in fact made a small addition to CONTRIBUTING.md to point out that there's also the genDocs nimble task.

I have also heavily added doc-comments and am in fact contemplating to add links to the corresponding GTK docs as well for every single property.

[can-lehmann]

Actually do you have a particular feeling about float vs float64? Mostly because float implicitly is float64 on basically any reasonably modern system and I don't think I consistently used float64 everywhere when typing things.

I don't really have a preference, though I believe I tried to use float in owlkettle.

[PhilippMDoerner]

Actually do you have a particular feeling about float vs float64? Mostly because float implicitly is float64 on basically any reasonably modern system and I don't think I consistently used float64 everywhere when typing things.

I don't really have a preference, though I believe I tried to use float in owlkettle.

In that case I swapped the rest over for consistencies sake. Also resolved the last issues so I don't think there's anything else to do so far.

Edit: I lied, I found that I hadn't shot the image at 200%, I hadn't regenerated the docs after moving from float64 to float and the meta-text of the image in examples/README.md was inaccurate. That's fixed now though, I think I've got everything.

[PhilippMDoerner]

Updated the example to make every field manipulatable so you can essentially see the widget in all kinds of configurations. That is except for the marks field, I can't seem to get my idea there to work properly =/

[PhilippMDoerner]

Looking over AcrionRow and its inheritance chain made me realize: ActionRow inherits from other widgets and that is modeled in owlkettle by those widgets also being there.

Would it have been better for Range to first make a Range renderable to then have Scale inherit from it? That way anything else based on Range wouldn't need to implement property hooks etc. from Range, it could have them just by inheriting from it.

[can-lehmann]

Just wanted to quickly confirm that the doc comments are NOT copied from the GTK docs (since GTK is licensed under the LGPL).

[PhilippMDoerner]

They are not, I wrote them myself off the cuff from what I understand their meaning and effect to be. That is true for any doc-comment I write since I find the GTK docs sometimes rather abstract and not telling me about interactions between certain variables that you need to infer.

[can-lehmann]

Looks good. I changed the example around a bit so that it additionally includes controls for the orient, valuePosition and marks fields (+ updated the screenshot).

[PhilippMDoerner]

From what I could see you removed the fields from Base-Widget (sensitive, sizeRequest and tooltip) in the scale example.

Should I assume that controls on the sidebar should not include fields that a given Widget has from its Parents in general? Or just BaseWidget (as PopOverMenu for example inherits some stuff from Popover etc.)?

[can-lehmann]

I don't think I removed any fields (the diffs look much larger than they actually are, because I changed the layout to be side by side instead of top/bottom).

I think the BaseWidget fields were never exposed in the example: https://github.com/can-lehmann/owlkettle/pull/90/commits/d28e6c23e0af73b0f9ba55ffa7e1747c9a0dc53b

[can-lehmann]

Main change was just layout, moving to adwaita + adding the controls for the remaining fields mentioned above.

[PhilippMDoerner]

Ohhhh I might have added those in the #94 PR, nevermind then. Mainly asking since I adopted the approach of adding all Parent fields also to those sidebars in order to show the user everything they can do with a given widget.

[can-lehmann]

Thats fine.