Another shoes weird behavior

[dredknight]

Hello again everyone :),

I started working on a second version of one of my apps. During improvement of one module I found out that although functionality wise both (the old and the new code) do the same things on theory it wasn't like that when the time came for execution. Here is a sample code:

Open debug, notice how the each cycle is parsed as far as the slots are drawn.

Shoes.app do
list = 1..99
@new_list = []
	
	check(checked: false) { |c| @menu.contents.each { |f| f.contents[0].checked = c.checked? ? true : false }}
	@menu = flow left: 0, top: 50, width: 100, hight: 400 do
		 list.each_with_index do |n, i| 
			   flow width: 0.8, height: 30 do ###################This line is different
					check(checked: false) { |cc| cc.checked? ?	@new_list.push(n) :	@new_list.delete(n) }
					para n
					border red
			   end
		 end
	end
debug(@new_list = [])
end

This is the second code. Check debug, now the cycle rotates till the end.

Shoes.app do
list = 1..99
@new_list = []
	
	check(checked: false) { |c| @menu.contents.each { |f| f.contents[0].checked = c.checked? ? true : false }}
	@menu = flow left: 0, top: 50, width: 100, height: 400 do
		 list.each_with_index do |n, i| 
			   flow width: 0.8 do ###################This line is different
					check(checked: false) { |cc| cc.checked? ?	@new_list.push(n) :	@new_list.delete(n) }
					para n
					border red
			   end
		 end
	end
debug(@new_list = [])
end

The only difference between both is the line I have a comment next to. Why does the height cause such issue?
My assumptions are that without the height slots that cannot fit the window are still drawn with zero height.

On the other side, when the height is defined, GTK stops drawing at the moment when the slot canvas has no more space to add and waits for the user to scroll to another page.

Whatever the reason this behavior should not exist.

[dredknight]

With 3.3.7 R3301 this behaves the same way.

1. Execute the first code
2. Mark "Select all" checkbox on top.
3. Open debug
4. Array contains elements between 1 and 15.

Repeat the same for the second code, array will contain all elements (99).

From one side this execution pattern does not seem intuitive but from the other I have the feeling this may be a restriction that comes from how Shoes works on the background and may be hard to alter...

[ccoupe]

There is a mis-spelling in your example hight: 400. Does that change anything important? They look the same on linux 3.3.8

Where you expecting that checking the box that marks/unmarks the others that their individual click procs would be called? If so, I need to think about it. I can imagine cases where you would not want that to happen.

[dredknight]

@ccoupe the height typo does not affect the code actually (even if fixed). I fixed the snipets in the example.
Here is the debug results when "Mark all" tick is selected.
Yes I would really want to select ALL of them if the code forces it to and not wait for the GTK to do it after the user has scrolled down.

[ccoupe]

There are a couple of issues here. On OSX , neither example triggers any of the 100 click procs. I, for one consider that the proper behaviour. The manual is not very clear about this but I tend to think of 'click' as something the user does with a mouse and then that one check proc is activated. From that perspective, Gtk3 shouldn't activate any of the 100 click procs, hidden or not - so it's an error or undefined behavior with gtk3. You could write a loop that gets the click procs for all 100 and call them your self, except some would be called twice and some only once, depending on what Gtk3 thinks.

[dredknight]

Interesting... hmm.. by saying "Gtk3 shouldn't activate any of the 100 click procs" do you mean that because they are not drawn yet (user has not scrolled down) they are not yet created in Shoes so when I click the "Select all" check box on the top, only the one that exist are ticked?

Could you give a short example of what a "click proc loop" looks like?

[ccoupe]

Visually they should have check marks. (visibile control or not). BUT the click proc should NOT be called because the visual state was changed by something other than a mouse click. .It takes a mouse click to active the click proc. In that scenario it doesn't matter if some of them are hidden until scrolled into view.

[dredknight]

Actually the "real life" scenario I am using them is the following:

1. The user opens the app and selects some or all elements
2. After the elements are chosen he clicks next and the elements are deployed.

Now, having in mind the above and the case where the user wants to select all elements through "select all" checkbox. He will click "Next" button without scrolling to the bottom. In that case the application will deploy only the elements that were in the visible spectrum (a.k.a. [1...14] from the picture) because the rest were not visualized and filled in the array at first place.

Frankly I did a workaround by using the second example in the first thread, I was just wondering if this is important to be taken precautions for in some way for the future but I dont know how I can contribute.

[ccoupe]

At the Gtk3 level we attach a 'signal' to the gtk widget and it gets triggered (a callback) and then shoes looks for the script writers click proc to call. If Gtk3 doesn't signal because the control is hidden then Shoes can't know enough to call the proc anyway. Your application's logic and the tests above are a bit different. When 'next' is pushed is the time to see if each control is checked?

[dredknight]

That is a good call. My code logic is the same as in the example so when "Select all" is checked the code does look if all controls are checked BUT lists all controls in the pane and checks them.

Technically all 100 controls are ticked but the code sniffs only the drawn ones so it gets just the first 14.
I guess my alternative is to have an array with each "Checkbox" and check that array instead of searching for the "checkboxes" in the pane via GTK.

[ccoupe]

I guess my alternative is to have an array with each "Checkbox" and check that array instead of searching for the "checkboxes" in the pane via GTK.

That's what I'd do (it's also what needs to be done to work on OSX). There are several things at play - the graphical appearance, the shoes widget state (checked?) and for the click proc, when it is called. They are loosely synchronized, at best.