Skip to content
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

Sync position of adw::TabPages in adw::TabView and FactoryVecDeque #573

Open
zefr0x opened this issue Nov 10, 2023 · 1 comment
Open

Sync position of adw::TabPages in adw::TabView and FactoryVecDeque #573

zefr0x opened this issue Nov 10, 2023 · 1 comment

Comments

@zefr0x
Copy link

zefr0x commented Nov 10, 2023

If I have both adw::TabView and adw::TabBar, when I change the position of a tab from the TabBar, it's position will be changed in the TabView, but not in the FactoryVecDeque, so I lose track of TabPages.

I think that FactoryView::factory_update_position should be implemented for adw::TabView. Way isn't it implemented? Is there any problem?

I tried to use TabView::connect_page_reordered to change the position in the FactoryVecDeque but I wasn't able to. I didn't find a way to reorder elements in FactoryVecDeque when I just have the a TabPage and it's new position.

Is there any thing that I can do?

@AaronErhardt
Copy link
Member

Currently, only the position of the element in the factory container is synced with the position of the widgets and not the other way around. FactoryView::factory_update_position is only for widgets, so it would not fix your problem and I don't think there's any benefit of implementing it as there is no Position type you could choose for ordering tab pages.

I think I tried to get bidirectional sync working, but I'm not sure why exactly I didn't implement it. I could have another look at the problem, but this might take some time.

zefr0x added a commit to zefr0x/stackbloatless that referenced this issue Mar 5, 2024
It's better, but is has some bugs for now. The position of tabs are not
synced with the factory vector.

This issue should be solved in Relm4's side, or we should find a hack to
solve it. If it wasn't solved this commit should be reverted before a beta
release.

Read More:
    Relm4/Relm4#573
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants