[yast-devel] Type of widget id
Hi developers, I found one design issue and I am not sure what is correct expected usage. Problem is with id of widget used in yast. Till now I thought that it can be any basic type, so string, symbol, number, whatever. But during friday debugging of issue with ReplacePoint CWM widget I found that some libraries and calls have limitation 1) CWM expects that id of widget is String, and as ID is used that string. If not, it will abort with nil id ( as it try to get string only ) 2) call Yast::UI.ReplaceWidget accept only symbol as id of replace point. Nothing else is accepted. So I think now you see why CWM ReplacePoint widget have troubles, as Id cannot be symbol and! String at same time. In the end I solve it with some workaround, but I would like what is intended usage? Really unlimited basic types? Or String only or Symbol only? I think it make sense to fix such annoying expectations. We have control over both parts, so we can change it. I just do not know all reasons behind, so if you have idea about these two limitations, if you can write it. And of course if you have any opinion or idea about this id and its limitation, I will welcome it. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, Jan 23, 2017 at 09:30:56AM +0100, Josef Reidinger wrote:
Hi developers, I found one design issue and I am not sure what is correct expected usage. Problem is with id of widget used in yast. Till now I thought that it can be any basic type, so string, symbol, number, whatever. But during friday debugging of issue with ReplacePoint CWM widget I found that some libraries and calls have limitation
1) CWM expects that id of widget is String, and as ID is used that string. If not, it will abort with nil id ( as it try to get string only )
Yes.
2) call Yast::UI.ReplaceWidget accept only symbol as id of replace point. Nothing else is accepted.
No. Actually in all places where YUI expects a widget ID, you can pass a symbol, **or** a term whose value **can** be a non-symbol. And we always pass a term whose name is `id` (written `Id` in Ruby), and the value is typically a symbol for hand coded widgets but string for CWM widgets. But [the documentation](https://doc.opensuse.org/projects/YaST/openSUSE11.3/tdg/ReplaceWidget.html) only mentions the first of the overloaded signatures, the one with `symbol`.
So I think now you see why CWM ReplacePoint widget have troubles, as Id cannot be symbol and! String at same time. In the end I solve it with some workaround, but I would like what is intended usage? Really unlimited basic types? Or String only or Symbol only? I think it make sense to fix such annoying expectations. We have control over both parts, so we can change it. I just do not know all reasons behind, so if you have idea about these two limitations, if you can write it.
And of course if you have any opinion or idea about this id and its limitation, I will welcome it.
See also https://github.com/yast/yast-yast2/pull/535 -- Martin Vidner, YaST Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
On 23.01.2017 09:30, Josef Reidinger wrote: [widget IDs]
1) CWM expects that id of widget is String, and as ID is used that string. If not, it will abort with nil id ( as it try to get string only )
2) call Yast::UI.ReplaceWidget accept only symbol as id of replace point. Nothing else is accepted.
Back in the days, that ID was defined to be (YCP) type 'any'. The UI never
imposed any limitation on the type. libyui has an abstract base type
YWidgetID and one specialization YStringWidgetID. The only relevant methods
(pure virtual in the base class) are isEqual() and toString() (the latter
being important for debugging).
IMHO it should not be that hard to enable at least Ruby symbols in addition
to strings, and maybe also numeric types. Compound types like hash, array and
any combination of them would be bit over the top IMHO, but we should allow
at least those basic types (string, symbol, int).
CWH should be able to use a to_s method if it gets anything else.
Kind regards
--
Stefan Hundhammer
On 23.01.2017 11:01, Stefan Hundhammer wrote:
CWH should be able to use a to_s method if it gets anything else.
CWH too, of course, because he's a smart guy ;-) but I really meant CWM here.
Kind regards
--
Stefan Hundhammer
participants (3)
-
Josef Reidinger -
Martin Vidner -
Stefan Hundhammer