Fiddle::Pointer and OOP: can we modify Fiddle::Pointer? If not can we add something else that acts mostly like a pointer but also more advanced when necessary?

[rubyFeedback]

Hey there,

You wrote in the past that ruby-libui does not want to provide incomplete solutions, e. g. the "half-baked" comment, in regards to OOP. I understand that.

At the same time, I think there is a difference in philosophy at work in regards to GUI-centric design.

For example, in pseudo code for libui:

hbox1  = UI.hbox # create a new horizontal box
entry1 = UI.entry('ATG') # create a new entry, and set the text to 'ATG')

Ok so far so fine. I am doing something similar in one of my gems, just that rather than UI or LibUI I use directly Gtk.hbox and Gtk.entry, so this is not a huge difference to libui.

But this step I don't like:

UI.box_append(hbox1, entry1, 1)

In ruby-gtk we may tend to use this instead:

hbox1.add(entry1)

To me, personally, I think using a method like this, aka .add(), or .pack_start() or .pack_end(), is so much more convenient.

I even like doing something like this:

hbox1 << entry1

Using << is great.

I had a look at the "widgets" and .class always says Fiddle::Pointer.

So I assume we kind of work with the pointers as-such, and ruby as DSL is mostly just a convenient wrapper over these pointers then.

I also assume - but may be wrong - that adding "functionality" to such pointers is ... not trivial, since they don't provide a platform for more actions - such as the .add() example.

Wouldn't it be cool if we could have some kind of meta data structure that could be used to wrap over the raw libui pointers? These would still act like Fiddle::Pointers, but we may add additional functionality, in the sense that something like:

hbox1.add(entry1)

would then be possible.

Sadly I am a total noob when it comes to C/C++, so I have no idea how difficult or simple that would be, and how much work. Mostly I am not even concerned about the internals, I just want to be able to have a more centric OOP-like DSL. Right now I have to use:

UI.do_something

and while that works, it's a bit tedious.

I'd rather prefer some layer similar to gtk, where we have widgets and work on these widgets then. Like the box.add() example. So this is the part that I think would be super-convenient.

I already wrote a module that extends the default LibUI, so I can get away with things such as UI.entry() and what not, but I have no idea what to do about Fiddle::Pointer. Can they be modified? Are they unique? Is it dangerous when treating them like other ruby objects? I kind of want to have something like box.add() but I am scared - perhaps Fiddle::Pointer is restricted similar to Numeric in ruby which isn't quite "full" OOP either.

Last but not least: I think half-hearted OOP may still be better than no OOP, if it is centered around the DSL part - aka to treat what matz once said about ruby in this ancient interview:

https://www.artima.com/articles/the-philosophy-of-ruby

So perhaps we can have some kind of meta-OOP-layer, even if it is not a "full" OOP layer like in gtk or qt. :)

PS: The various procs are also a bit tedious. I much prefer working with methods. Of course the proc can just be a wrapper over a method call, so this can be solved, but I found it more convenient if I don't use any procs. But that is another issue; for here I am more interested in a box.add(widget) DSL.

PSS: I understand that libui's philosophy will remain to be simple which is fine. I'd just think simplicity may also exist in simpler APIs/DSLs. :)

[kojix2]

Hello.

I understand what you are trying to say. Now I have to tell you the truth.

• I know very little about C.
• I know absolutely nothing about C++ language.
• I also don't know much about Fiddle::Pointer.

Nevertheless, I can make a tool like LibUI. I can't even believe I made it. Of course, I'm not making it alone.

• The coding style is based on Andrew Kane and his awesome projects.
• @kou has been helping me in some important points. He is a maintainer of Fiddle.

The reason why this is possible is that creating bindings is like creating a plastic model, you only need to focus on the interface of the function and connect C functions and Ruby methods.

If you want to make LibUI object-oriented, why don't you actually do it? This might be easier than you think!

It might be better to put the high-level object-oriented API in a separate repository from LibUI.

[kou]

I agree with kojix2. Creating a high-level object-oriented API based on the current LibUI API is better. It doesn't require any C and Fiddle knowledge. It just wraps existing API. We can use only Ruby for it.