@edvin Maybe. I think we're in agreement with providing the goto() abstraction. The extra information I'm hinting at is stuff like a Stage's size and title (if relevant) or maybe pre and post action on the transition

If you provide this declaratively you will need to evolve the support a lot. If you just do it in code, everyone will instantly be able to do whatever they want, and they don't need to learn another API. (I think). We can test both approaches. Do you mean the stage size and title of the source by the way?

I meant the target. The arguments to line 3 of your psuedo code would include View details that would be maintained separately from the View code (in the Navigation object).

Not sure I follow completely. By the way, I wrote

when(target)

but it should have been

when(source)

. The target is obviously the

this

.

Let me just add the basic support I'm talking about, and you can show me what becomes cumbersome.

ok

Let's say we add something like this to `UIComponent`:

@User uploaded a file: Goto support

We would obviously also have overloads to support

goto(target: KClass<UIComponent>)

and also view parameters, but this gets the point across.

Updated the example above with a version of goto that takes a type and optional parameters as well.

Now you can even veto the operation if you want.

The View's onGoto (for modals) would contain an open call to itself?

Yeah, that would just be

openModal()

@User uploaded a file: Untitled

A view that is asked to "go somewhere" can also now clean up if it is already embedded somewhere, or veto if that's the case.

Haven't thought this through or even tested, so I'm not saying this is the right approach, this is just what I had in mind 🙂

I added another example to the navigation above.

sry. typing in some tornadofx code...i'm really rusty

Haha 🙂

At least you have a good keyboard 😁

yeah...although i feel like it needs the o-ring mod...but let's not get into that again

By the way, you can make sure that you don't frak up the ui by checking stuff like:

@carlw When you have time: Did you envision more functionality from the navigation service? If so, let's hear it and see if it fits into the goto function or if it's too simplistic 🙂

trying to get some ideas down...the other toolkits i was referencing include a UIControl in addition to the pop/push/goto functionality. This might be of use, but since everyone is navigating differently in a desktop (unlike a mobile), it shouldn't be a requirement.

this is what I was thinking about as an implementation. i would have had this out 10 message ago but have been struggling with the kotlin. I don't think it's better than hanging the functionality off of the goto(). I was thinking a logical navigation might be useful (ex "main" versus MainView)

@User uploaded a file: Separate nav object and commented: goto() backed by map with navigation logic (ex replaceWith versus openModal)

Hello fellow devs 🙂 o/

@carlw It seems like

Navigation.goto

doesn't receive info about which

UIComponent

you go from, so you only know the target, is that right?

Ohoy, Per 🙂