-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to remove main window in multi window Application #99
Comments
I do not quite know how to fix it... because seems the main wl_surface cannot be destroyed then the iced compositor will also been destroyed.. a bit hard for me.. what is the usecase? |
@Decodetalkers thanks for such fast changes The use case is showing and hiding window of application launcher. Application is usually started without the main window when DE/WM starts and then window is shown by pressing global shortcut. I have been testing your changes which added But I am facing a unwrap panic here, when removing a window
Found the issue, the window id specified with |
The problem is that we cannot know the main id.. and for iced_layershell, the main id may be more than one. Then this time we cannot know if the id is the main window. Possible solution is to send close request from the widget in view, where they know the id for other manually created windows, there are functions to mark their identities, and we can get their id from the identities, but for main windows, it seems a little difficult.. should the main id be also stored? and another optional function to allow user to get the main windows? |
#101 please try this pr. now I add the ability to record the mainwindow ids, now it is possible for you to know the id of mainwindow |
by the way, how can iced get the mainwindow id? |
I am not quite sure how I would need use that
Basically this is the difference between If you are using When using |
Either way, it is already possible to get window id with I just need you to fix:
|
Emm. If you meet removing window panic, that means you have passed an id does not exist I think that NewLayerShell won't accept any id, you can only receive the id by registering the function of set_id_info, and use the info to find the id, and also you need to listen on remove_id functionhttps://github.com/waycrate/exwlshelleventloop/blob/master/iced_examples/counter_mulit_pattern/src/main.rs#L99-L110 Why is it needed to pass id to the namespace function? by the way, have you register the functions in the way likes This allows you to get the registered id which match the passed WindowInfo, now the pr #101 allow you with the same way to get the id of MainWindow, just need to tell iced_layershell which field of enum is the mainwindow, and iced_layershell will return that id for you |
And that pr allows you to mark one field of the enum to accept the creating and removing event of main windows. I think that will meet your needs. The only thing you need to do is just register the set_id_info and remove_id |
Haa... I see.. that LayershellCustomActionsWithId, this id means the id of the sender, not the id to be created... sorry for that, you had better to use the macro to impl it will be better.. the id in LayershellCustionActionWidhIdAndInfo, is used to change the state of the already existed layershell. It is used to change the attribute of the layershell, like layer, anchor, margin, so when you create a new layershell, the id is still not exist, so in this case , the id in and you need to register a WindowInfo, to mark the type of layershell.. sorry for your confuse, because I write a such bad document |
Ok, I see. The problem is that the api style doesn't match to usual iced. It is needlessly complicated to have callback-style api to get id of the windows. Why would I need to implement all id_info, set_id_info and remove_id_info if i could just pass my id to the create new layer message and store it my self (like already implemented in project-gauntlet/gauntlet@9a57c47) it is a lot less code and it is how it is done in usual iced and in PopOS's fork with layer shell
same reason why there is id in |
Namespace is not a title, it is just used to tell wm what this program is. And a program just owned one namespace. Because we need to mark different layershell, get their identity. You can take a look at that example As I already have told you. You should not implement the tryInto trait yourself, but should use the macro. The id used in that action just means the sender, when you want to create a new layershell, the sender will not exist, so in this case that place it is useless. So I recommend you to use that macro. It will add proper field to that enum, without useless fields. |
Ha.. I have already understand your problem.. the window::open in iced return the For another thing about why I create the WindowInfo.. because the layershell is not created just after the messaged be sended, sometimes maybe with multi times of clicked, it will create more than once layershell, so it need to be controlled in some enum, so I create the WindowInfo.. Above all, I will create a pr for it.. then you can take a try updateEmm.. seems not good.. only if the info contains the message of id.. because the logic of this crate cannot know the id before the layershell being created, the only thing it has is just the WindowInfo, only when the WindowInfo has the message of Id, then it can be used, but then I need to induced another trait... After all, this lib cannot do the thing like what |
Ok, after thinking about this thing... this design is a mistake.. but now I do not have enough energy to change it .. |
done #103 but I still keep remove_id, because if when invoke remove window, this time window still not been removed, that will cause render problems |
done, now you can try the new rc version.. I think that will solve your problem |
Works now as intended, thanks a lot! |
In multi_window Application it is not currently possible to remove main window. Main window seems to have id 0 if start mode is background code or is otherwise random. In iced 0.13 window::Id::MAIN was removed in favor of always specifying id for new windows. And window::Id::unique() starts at 1. Additionally in daemon mode (new multi_window replacement) application starts without any windows. Also there is no way to get an id of a window in iced_layershell, which is possible in iced 0.13
The text was updated successfully, but these errors were encountered: