search

LivelyKernel / lively.next

lively.next is a personal programming kit. It emphasizes liveness, directness, and interactivity.
https://lively-next.org
MIT License
67 stars 16 forks source link

Problems with Selections and Halos #560

Closed linusha closed 1 year ago

linusha commented 1 year ago

I think there are several issues with selections and how they trigger/remove halos at the moment.

  1. It is possible to select the selection/halo (?) of a selection.

https://user-images.githubusercontent.com/14252419/201143490-47868250-2238-44f6-821d-455d92a10782.mp4

  1. I would expect a click in the world, i.e., not on any morph, to always remove all halos. When we have selected multiple morphs before, this is not the case.

https://user-images.githubusercontent.com/14252419/201143856-d937cb4a-e302-4b70-a0ea-9b66c99cc26c.mp4

@merryman in case you have any insights/ideas how to tackle this, I would appreciate any pointers. Otherwise, I will start debugging, as operations such as these should be working robustly in order to facilitate a good direct manipulation workflow.

merryman commented 1 year ago

Yes this seems all kinds of messed up. A couple ideas what to look for:

  1. Selection may not have the halosEnabled flag set correctly.
  2. It may be that the halosEnabled mechanism itself is broken.
  3. Lastyl I would browse for bugs in either the top bar or the world itself. It is rather problematic that we have split up the halo logic between these two objects.
linusha commented 1 year ago

https://user-images.githubusercontent.com/14252419/201315676-0b880c93-fdaf-4c1d-97e1-2c1a36e76501.mp4

Another one: In Halo mode, elements do not always show that they are included in an selection (red border), even when the grey selection area includes them. In Hand mode this works (see the second half of the video).

linusha commented 1 year ago

edit: One probably needs to differentiate more when talking about the question below, as I believe the problems above have different origins. E.g., there is the click-and-drag selection behavior and the general mechanism to toggle halos when clicking on a morph in halo mode.

  1. Lastyl I would browse for bugs in either the top bar or the world itself. It is rather problematic that we have split up the halo logic between these two objects.

Where would you say it belongs? I do not have a complete overview over how the functionality is split yet, and am still in the process of investigating, but I could see arguments for both cases: On one hand, having this functionality in the topbar would allow to utilize it on targets that are not worlds, e.g., Rick's Galyley IIRC. On the other hand, especially the possibility of selecting elements via dragging the mouse might be handy in situations where one would not want to have a topbar? A new edition of lively101 comes to mind... However, there are probably not super many of these situations, and it would still be possible to just have an invisible topbar.

TL;DR: I slightly lean towards this functionality belonging into the topbar. What do you think?

merryman commented 1 year ago

TL;DR: I slightly lean towards this functionality belonging into the topbar. What do you think?

I would agree, although that move is kind of ironic with our recent decision to move side bar logic into the world again. That logic used to be in the top bar and maybe we did not think that through fully. We should have documented our thoughts about that. I cant find any comments in #453.

Anyways, I would agree right now that this halo capability should be controlled solely by the top bar. Especially since the top bar has this aspect of dynamically attaching itself to different targets. That way we keep the flexibility of changing the top bar's focus when we have tools that act as alternative workspaces to the world (qinoq).

linusha commented 1 year ago

I would agree, although that move is kind of ironic with our recent decision to move side bar logic into the world again. That logic used to be in the top bar and maybe we did not think that through fully. We should have documented our thoughts about that. I cant find any comments in #453.

I actually think that this is not at odds with the move of the sidebar logic. When we initially introduced the sidebar logic resp. touched it when I introduced the flaps, the logic was part of the topbar, as it was triggered via a topbar button before we had the flaps. However, since exchanging the button for the flaps, there was no real reason anymore, why that code (= sidebar logic) should belong to the topbar. Thus, I still think that is a valid move, as the flap has more to do with the world than the topbar, in my opinion.

merryman commented 1 year ago

I would agree, although that move is kind of ironic with our recent decision to move side bar logic into the world again. That logic used to be in the top bar and maybe we did not think that through fully. We should have documented our thoughts about that. I cant find any comments in #453.

I actually think that this is no at odds with the move of the sidebar logic.

When we initially introduced the sidebar logic resp. touched it when I introduced the flaps, the logic was part of the topbar, as it was triggered via a topbar button before we had the flaps. However, since exchanging the button for the flaps, there was no real reason anymore, why that code (= sidebar logic) should belong to the topbar. Thus, I still think that is a valid move, as the flap has more to do with the world than the topbar, in my opinion.

Ah, good call. Yes that makes sense. So if it was really just about this flap logic moving out of the top bar into the world, I have nothing more to complain about.

linusha commented 1 year ago

I think I have weeded out all :beetle: related to this. The fixes will be part of #551, mainly because the new text formatting popup was the cause for finding all this, as using it was de-facto impossible with the selections just going ham.

I also believe the code splitting between the top-bar and the world is not as bad as we thought. It might also be that I have spend too much time looking at this and now have a distorted view on the topic. Therefore, here is what I think is going on:

There are three building blocks to the opening/closing behavior of halos. However, all three of them have distinct use cases:

  1. The halo itself. It is resposible for the "halo cycle", i.e., we have an open halo and do Ctrl+Click. The Halo cycles through the morph hierarchy.
  2. The world. The world handles (initial) halo invocations based on Ctrl+Click and Ctrl+Shift+Click. Thus, it is possible to invoke halos for a single morph as well as for a selection. Note, that this would be possible even without a topbar at all. Thus, it also works independently of the current target of the topbar. In my opinion, this is a feature, as it allows us to use the halo anywhere in the world even when the world is currently not the target of the topbar. If the target is the world, and the topbar is in halo mode, the world halo behavior will win.
  3. The topbar. It is responsible for a) halo invocations based on spanned selections (halo and hand mode), as well as halo invocation for a single morph in halo mode. This functionality can be provided on targets other than a world.

Does that make sense to you?

merryman commented 1 year ago

Sounds good. I would just add that 2. is reserved for the LivelyWorld inside the lively.ide package. So it is some custom behaviour we add into the mix that for instance is not present when we use a "vanilla" morphic world for an app written in lively.next. So all in all these are 3 different building blocks all of which make the lively.next IDE point and click inspectable.

linusha commented 1 year ago

Sounds good. I would just add that 2. is reserved for the LivelyWorld inside the lively.ide package.

Yes, that is correct.