|
From: TheFGFSEagle <the...@gm...> - 2022-10-10 11:30:46
|
Ah, a second pair of eyes is always good ! :)
- I thought it would be a good idea to have a toggle method so I
implemented that, and then I thought "why not use that for the close
button, it won't be called from there anyways when the window is hidden",
but yeah, it would make more sense to just call hide directly.
- For end user usage, in fact - I don't have a use case for it right now,
but I thought it wouldn't hurt to have it.
- Simple - calling del on it ! :)
As for the memory problem, I didn't think of that … so we'd need some kind
of way to delete the texture without deleting the window, redrawing the
texture when the window is reopened ? Starts to sound complicated … but on
the other hand, all windows on the Extra 500 use a custom Window class
which does something similar …
Am Mo., 10. Okt. 2022 um 08:50 Uhr schrieb James Turner <
ja...@fl...>:
>
>
> On 8 Oct 2022, at 23:44, TheFGFSEagle <the...@gm...> wrote:
>
> It would be very useful to have singleton-style Canvas (dialog) windows -
> instead of automatically destroying them when the close button is clicked,
> the attached patch changes the FGData Nasal code to only destroy and delete
> the window when a new flag destroy_on_close is set to 1, and only hide it
> otherwise - this way we can do:
>
> var equipment_dialog = canvas.Window.new(size: [200, 100], type: "dialog",
> destroy_on_close: 0).setTitle("Equipment options");
>
> in any Nasal file that is loaded on startup, and then in the menubar:
>
> <item>
> <label>Equipment options</label>
> <binding>
> <command>nasal</command>
> <script>dialogs.equipment_dialog.show();</script>
> </binding>
> </item>
>
> without caring whether that dialog has already been opened and closed.
> Tested and working ! :)
>
>
> The basic idea here is okay, but the details don’t quite make sense to me
> (maybe more coffee needed)
>
> - ‘toggle’ is called from ‘close’ where it should presumably always hide?
> Maybe have an explicit ‘hide’ method and ’a show+raise’ methods?
>
> - I don’t see a code-path which calls toggle in ‘show mode’ ? So why does
> that code path exist?
>
> - how do you (in the end) delete the dialog, to avoid leaking / eating the
> CPU- and GPU- side resources?
>
> It would be better to have a ‘create dialog first time it’s shown’ logic,
> this would avoid creating the canvas (and associated texture memory, etc),
> and have the binding do something like ‘create or show’, I think. (But
> still leaves the issue that if you do this many dialogs, we will allocate a
> ton of large textures for no great reason)
>
> Kind regards,
> James
>
> _______________________________________________
> Flightgear-devel mailing list
> Fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
|