Le samedi 5 septembre 2009 21:42:05, Lionel Chauvin a écrit : > >Ah, ok. Now I see it. > >Do you think we should revert the commit or try fixing it some way? > > I do not want spend time on this. We have more useful things to do. > > If someone want work on it: > Imo the best way is to create a tabbar entirely independant of Rekonq. So, > it could be used by other applications. I don't know if a such tabbar must > be based on KTabWidget or KTabBar. If it is based only on KTabBar, I don't > know if it is possible to tweak the position of scroll buttons. A solution > is perhaps decreases the widget's maximum width in order to keep space for > the addTabButton. > > > > > _______________________________________________ > rekonq mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/rekonq > I spend this morning on this problem. I am convinced an option to have an "add tab" button must be added in qtabbar itself (in qt). "close tab" buttons have been added to this class, why not an "add tab" button ? It is not easy to extend this class and do the stuff because the way it is drawn must be changed to respect the scroll buttons.
Someone know where I can propose this to the qt team ? Andrea, can you return to the previous state of tabbar/mainview to fix the regression ? Lionel. _______________________________________________ rekonq mailing list [email protected] https://mail.kde.org/mailman/listinfo/rekonq
