> > Bennett, i have an idea. if you still suffer from the focusing problem,
> > can you try this patch?
>
>
> It looks like I'm slow and you've already applied this patch, right?
no, i have commited fix for a different issue.
>In any
> case, focus coming out of fullscreen mode hadn't been work
On Sun, Mar 30, 2008 at 6:14 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:
> > 1. When coming out of fullscreen mode, the normal window returns, but it
> > does not automatically take focus as it should.
>
> Bennett, i have an idea. if you still suffer from the focusing problem,
> can you try this pa
> 1. When coming out of fullscreen mode, the normal window returns, but it
> does not automatically take focus as it should.
Bennett, i have an idea. if you still suffer from the focusing problem,
can you try this patch?
pavel
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiVie
On Feb 22, 2008, at 1:33 PM, Pavel Sanda wrote:
I have encountered a couple other problems that seem directly
related to
fullscreen mode:
1. When coming out of fullscreen mode, the normal window returns,
but it
does not automatically take focus as it should.
Bennett, is that focus thing o
> > I have encountered a couple other problems that seem directly related to
> > fullscreen mode:
> >
> > 1. When coming out of fullscreen mode, the normal window returns, but it
> > does not automatically take focus as it should.
Bennett, is that focus thing ok in the current trunk?
>
> pavel
Pavel Sanda wrote:
I have encountered a couple other problems that seem directly related to
fullscreen mode:
1. When coming out of fullscreen mode, the normal window returns, but it
does not automatically take focus as it should.
hmm, it does here. i guess that will be some qt thing on mac.
On Feb 19, 2008, at 9:14 PM, Pavel Sanda wrote:
It's not a focus problem (and screen-recenter and mouse selection
doesn't
affect it). Playing around a little more, I find that the arrow
keys are
recognized and the insertion point changes accordingly, but the
cursor does
not move on screen.
> It's not a focus problem (and screen-recenter and mouse selection doesn't
> affect it). Playing around a little more, I find that the arrow keys are
> recognized and the insertion point changes accordingly, but the cursor does
> not move on screen. So, after pressing down-arrow several times,
On Feb 19, 2008, at 8:22 PM, Pavel Sanda wrote:
The added preferences all seem to work well. The only oddity I've
noticed
concerns "Toggle tabbar". When this is selected and there are
multiple tabs
in normal mode, switching to fullscreen mode properly hides the
tabs. But
(staying in fullscr
> The added preferences all seem to work well. The only oddity I've noticed
> concerns "Toggle tabbar". When this is selected and there are multiple tabs
> in normal mode, switching to fullscreen mode properly hides the tabs. But
> (staying in fullscreen mode) selecting File > New brings up the
On Feb 19, 2008, at 4:56 PM, Pavel Sanda wrote:
A final question/request (which may go beyond what you want to do,
so feel
free to ignore it): especially with widescreen monitors (standard
on Macs),
fullscreen mode as currently implemented results in unreadably
long lines.
Would it be possi
> A final question/request (which may go beyond what you want to do, so feel
> free to ignore it): especially with widescreen monitors (standard on Macs),
> fullscreen mode as currently implemented results in unreadably long lines.
> Would it be possible to define line length (or % of screen wid
> > > >> i need to call some kind of redraw when comming back from fullscreen
> > > >> mode
> > > >> (scrollbar needs some update and probably recomputation).
> > > >
> > > > I don't really understand why you need that as a redraw should be
> > > > triggered
> > > > automatically following a res
> > >> i need to call some kind of redraw when comming back from fullscreen mode
> > >> (scrollbar needs some update and probably recomputation).
> > >
> > > I don't really understand why you need that as a redraw should be
> > > triggered
> > > automatically following a resize event (which you g
On Tue, Feb 19, 2008 at 11:12:37AM +0100, Abdelrazak Younes wrote:
> Pavel Sanda wrote:
1. more workareas handling needs to be added (toolbars toggling wont
work with them now)
>> this seems to be tricky. Abdel, would it be complicated to have one
>> toolbars
>> info per workarea?
>
> Y
> >> i need to call some kind of redraw when comming back from fullscreen mode
> >> (scrollbar needs some update and probably recomputation).
> >
> > I don't really understand why you need that as a redraw should be triggered
> > automatically following a resize event (which you get if you come ba
>> i need to call some kind of redraw when comming back from fullscreen mode
>> (scrollbar needs some update and probably recomputation).
>
> I don't really understand why you need that as a redraw should be triggered
> automatically following a resize event (which you get if you come back from
>
Pavel Sanda wrote:
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.
OK.
I
>> 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
Pavel Sanda wrote:
1. more workareas handling needs to be added (toolbars toggling wont work
with them now)
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.
>> 1. more workareas handling needs to be added (toolbars toggling wont work
>> with them now)
this seems to be tricky. Abdel, would it be complicated to have one toolbars
info per workarea? i seem to be lost in gui hierarchy - why there are two
nested loops in fullscreen initialization - one ove
Pavel Sanda wrote:
hola,
because more people didnt like the 'handy' way (TM) of ui toggling i introduced
some gui interface
and thus F11 and users configuration should be basically usable now.
i know about two issues currently:
1. more workareas handling needs to be added (toolbars toggling wo
> I agree I was not very clear and maybe that things are not very clear
> in my mind :) But I do not like this approach of toggling "by hand"
> the toolbars and menubar. It does not feel right (says the man who
> does not code).
the vision here is to have:
1) all these bundled in one single comma
Jean-Marc Lasgouttes wrote:
Pavel Sanda <[EMAIL PROTECTED]> writes:
I think this is the main problem with using fullscreen as it is
envisionned here. A useful fullscreen needs more thought (maybe a
different workarea that does fullscreen plus some extra whistles?)
i dont follow you here. whats
Pavel Sanda <[EMAIL PROTECTED]> writes:
>> I think this is the main problem with using fullscreen as it is
>> envisionned here. A useful fullscreen needs more thought (maybe a
>> different workarea that does fullscreen plus some extra whistles?)
>
> i dont follow you here. whats the main problem?
> > A final question/request (which may go beyond what you want to do, so
> > feel free to ignore it): especially with widescreen monitors
> > (standard on Macs), fullscreen mode as currently implemented results
> > in unreadably long lines. Would it be possible to define line length
> > (or % of s
Bennett Helm <[EMAIL PROTECTED]> writes:
> Wouldn't a zoom/dpi trick result in not simply fewer characters per
> line but also fewer lines per screen? That would seem to defeat one
> of the purposes of going full screen: to maximize the number of lines.
Or rather do not change the width of lines
Bennett Helm <[EMAIL PROTECTED]> writes:
> A final question/request (which may go beyond what you want to do, so
> feel free to ignore it): especially with widescreen monitors
> (standard on Macs), fullscreen mode as currently implemented results
> in unreadably long lines. Would it be possible to
> By the way Pavel, could you add a binding to "ui-toggle fullscreen". F11 is
> key used by Firefox for the toggling, as much as a standard as it gets. I
there is still one thing missing to give proper shortcut for fullscreen
switching. we need to remember the visibility of all toolbars, so we c
Abdelrazak Younes wrote:
I've done this change. The left and right margin are set to one fourth
of the screen width for now, the result is good with my 1024 wide screen
but I don't really know if makes sense for smaller or bigger screen.
Someone had an idea about a fixed width per font size i
Abdelrazak Younes wrote:
Pavel Sanda wrote:
I think an adjustment of the zoom and/or dpi settings while in
fullscreen should do the trick.
what should that dpi thing do? i just tried now to set different values,
I think it must be used in combination of the zoom factor.
but nothing happens
Pavel Sanda wrote:
I think an adjustment of the zoom and/or dpi settings while in
fullscreen should do the trick.
what should that dpi thing do? i just tried now to set different values,
I think it must be used in combination of the zoom factor.
but nothing happens with my screen or fonts.
On Samstag 09 Februar 2008, Pavel Sanda wrote:
> >I think an adjustment of the zoom and/or dpi settings while in
> >fullscreen should do the trick.
>
> what should that dpi thing do? i just tried now to set different values,
> but nothing happens with my screen or fonts. but i dont understand what
On Feb 9, 2008, at 8:45 AM, Pavel Sanda wrote:
Bennett, try whether "ui-toggle fullscreen" hide the global
menu by
chance...
pavel
It does work, and the menubar nicely appears automatically when the
mouse goes to the top of the screen. Nice work!
I that intentional Pavel? If yes, I am im
>> Bennett, try whether "ui-toggle fullscreen" hide the global menu by
>> chance...
>>>
>>> pavel
>>
>> It does work, and the menubar nicely appears automatically when the
>> mouse goes to the top of the screen. Nice work!
>
>I that intentional Pavel? If yes, I am impressed :-)
i just
Pavel Sanda wrote:
dynamic_cast(d.current_work_area_)->setFrameStyle(
QFrame::NoFrame);
this line work, we got rid of 1mm margin.
still 2 pixel border remain, it has to be from guiview?
Or from your window manager?
no certainly not.
but i found a trick - to give setcon
Bennett Helm wrote:
On Feb 8, 2008, at 5:44 PM, Pavel Sanda wrote:
Bennett, try whether "ui-toggle fullscreen" hide the global menu by
chance...
pavel
It does work, and the menubar nicely appears automatically when the
mouse goes to the top of the screen. Nice work!
I that intentional Pa
On Fri, Feb 08, 2008 at 11:44:20PM +0100, Pavel Sanda wrote:
> - break;
> + case LFUN_UI_TOGGLE: {
> + string const arg = cmd.getArg(0);
> + if (arg == "statusbar")
> +
> statusBar()->setVisible(!st
> There are a couple glitches I discovered in a few minutes of testing.
> First, ui-toggle fullscreen does not work unless a document is open. (Is
> that intentional?)
i know about it, but its not intentional :) i was lazy to change it because
whats the point of fullscreen when no file is opened
On Feb 8, 2008, at 5:44 PM, Pavel Sanda wrote:
Bennett, try whether "ui-toggle fullscreen" hide the global menu
by chance...
pavel
It does work, and the menubar nicely appears automatically when the
mouse goes to the top of the screen. Nice work!
There are a couple glitches I discovered
>>> I guess that keeping trace of the menuBar pointer (via a static variable
>>> outside the ctor) and try to hide it could work.
>>>
>>> One has to try...
>> so to complete this menubar hiddening under mac and window decoration
>> under ms win
>> should be done. do you think its part of lyx assi
> > > dynamic_cast(d.current_work_area_)->setFrameStyle(
> > > QFrame::NoFrame);
> >
> > this line work, we got rid of 1mm margin.
> > still 2 pixel border remain, it has to be from guiview?
>
> Or from your window manager?
no certainly not.
but i found a trick - to give setcontents
On Fri, Feb 08, 2008 at 09:02:42PM +0100, Pavel Sanda wrote:
> slowly approaching the final destination :)
>
> > void GuiView::setFullScreen()
> > {
> > menuBar()->hide();
> > statusBar()->hide();
> > dynamic_cast(this)->setFrameStyle(QFrame::NoFrame);
>
> this line seqfaults. guiview
slowly approaching the final destination :)
> void GuiView::setFullScreen()
> {
> menuBar()->hide();
> statusBar()->hide();
> dynamic_cast(this)->setFrameStyle(QFrame::NoFrame);
this line seqfaults. guiview inherits QFrame?
> dynamic_cast(d.current_work_area_)->setFrameSt
Pavel Sanda wrote:
I don't know for sure but I guess it should be done within LyX. For Mac,
the method I've outlined above should probably work. I see that Firefox is
able to hide all window decoration under Windows so I guess it is possible
to do it for LyX too.
thats worth studying, becaus
> I don't know for sure but I guess it should be done within LyX. For Mac,
> the method I've outlined above should probably work. I see that Firefox is
> able to hide all window decoration under Windows so I guess it is possible
> to do it for LyX too.
thats worth studying, because firefox is
Pavel Sanda wrote:
I guess that keeping trace of the menuBar pointer (via a static variable
outside the ctor) and try to hide it could work.
One has to try...
so to complete this menubar hiddening under mac and window decoration under ms
win
should be done. do you think its part of lyx assig
> I guess that keeping trace of the menuBar pointer (via a static variable
> outside the ctor) and try to hide it could work.
>
> One has to try...
so to complete this menubar hiddening under mac and window decoration under ms
win
should be done. do you think its part of lyx assignment or should
Abdelrazak Younes wrote:
Pavel Sanda wrote:
Why not just using hide()/show() intead of filling/emptying the
menubar?
hide method hides ... i was searching for it in docs and havent
found, now i
see they are inherited. next time i drop reading manuals and try hide()
directly in code ;)
I se
Bennett Helm wrote:
On Feb 6, 2008, at 12:01 PM, Pavel Sanda wrote:
You could also introduce LFUN_STATUSBAR_TOGGLE by the way if you want to
achieve real full screen.
does the following patch looks more sensible to you?
pavel
I just tried it, but menubar hiding doesn't work on Mac. (Statusb
>>> You could also introduce LFUN_STATUSBAR_TOGGLE by the way if you want to
>>> achieve real full screen.
>>
>> does the following patch looks more sensible to you?
>> pavel
>
> I just tried it, but menubar hiding doesn't work on Mac. (Statusbar hiding
> does.) Is this a Qt/Mac limitation?
i rem
On Feb 6, 2008, at 12:01 PM, Pavel Sanda wrote:
You could also introduce LFUN_STATUSBAR_TOGGLE by the way if you
want to
achieve real full screen.
does the following patch looks more sensible to you?
pavel
I just tried it, but menubar hiding doesn't work on Mac. (Statusbar
hiding does.)
> Yes but I guess it could be a bit shorter:
nice ;) i will commit it.
pavel
Pavel Sanda wrote:
You could also introduce LFUN_STATUSBAR_TOGGLE by the way if you want to
achieve real full screen.
does the following patch looks more sensible to you?
Yes but I guess it could be a bit shorter:
@@ -1524,6 +1525,15 @@ bool GuiView::dispatch(FuncRequest const & cmd)
> You could also introduce LFUN_STATUSBAR_TOGGLE by the way if you want to
> achieve real full screen.
does the following patch looks more sensible to you?
pavel
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index d93c74f..ac0bc2f 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -10
Pavel Sanda wrote:
Why not just using hide()/show() intead of filling/emptying the menubar?
hide method hides ... i was searching for it in docs and havent found, now i
see they are inherited. next time i drop reading manuals and try hide()
directly in code ;)
I see :-)
A good advice is to re
> Why not just using hide()/show() intead of filling/emptying the menubar?
hide method hides ... i was searching for it in docs and havent found, now i
see they are inherited. next time i drop reading manuals and try hide()
directly in code ;)
> You could also introduce LFUN_STATUSBAR_TOGGLE by t
Pavel Sanda wrote:
hi,
its not the first time the issue of fullscreen mode of lyx when editing
document is raised on dev list and in bugzilla we have enh request too.
i think that if we are not supporting it directly it would be very easy to add
minimalistic support for advanced users, which wi
58 matches
Mail list logo
