>> this seems to be tricky. Abdel, would it be complicated to have one >> toolbars >> info per workarea? > > Yes, very complicated and not good. The toolbars are part of a main window > i.e. GuiView. But perhaps you mean one toolbar by view?
yes, view is what i actually wanted. >In which case the > toolbars are already independent AFAIK. Not sure about that really, maybe > the ToolbarBackend is not 'multiview aware'? That would be bad. i call it on d.toolbars_->... in guiview, which suggest its depenedent on view, but actually it does affect other windows. > The reason why we have a vector of tabworkarea instead of one is because > the code is ready for "split view" i.e. two visible work areas inside the > same window separated either vertically of horizontally. hey, we do have vertical split? how i can launch it in gui? i'm still not sure how to manage the bilingual stuff and this may be option. >I will add this > information in the documentation in 'Application.h' (did you read it by the > way?). reading now. >>> Hum, I put the additional test in case the outliner is opened and the >>> available width is smaller. In this case you >> ahh, comment needed :) i wondered why the second part of condition... > > Yes a comment is probably needed, could you do it as part of your patch > please? done. > use the full width anyway so I would propose instead a check box 'Limit > text screen width' that will enable/disable the width edit box. done. i need to call some kind of redraw when comming back from fullscreen mode (scrollbar needs some update and probably recomputation). what routine should i call? (this routine is not triggered when moving with cursor but its trigger when i select some text into selection by mouse). pavel
