On 2022-10-31 08:36, Daniel wrote:
On 24/10/2022 00:15, Christopher Hillenbrand wrote:
Dear LyX developers,
Here's a patch for adjusting editor text width in windowed mode (see
ticket https://www.lyx.org/trac/ticket/9376). It's an adaptation of
the previous patch uploaded by stwitt (two years a
On 2022-10-24 00:15, Christopher Hillenbrand wrote:
Dear LyX developers,
Here's a patch for adjusting editor text width in windowed mode (see
ticket https://www.lyx.org/trac/ticket/9376). It's an adaptation of
the previous patch uploaded by stwitt (two years ago). Please try it
out when you get
> * The validator allows to enter "10em", but the value is then changed
> after application to "10cm". Not good. A special validator would need
> to be set up for this task.
I didn't realize that would happen! Thanks for catching it.
> Meanwhile, I have added you to the credits. Welcome aboard!
Le 31 octobre 2022 08:34:43 GMT+01:00, Daniel a écrit :
>On 27/10/2022 18:12, Jean-Marc Lasgouttes wrote:
>> Concerning the 7in default: I see in LaTeX sources that the default text
>> width is 360pt, that is, 5in. What does the 7in come from? [I am not asking
>> for change, I ask :)]
>
>I am
On 24/10/2022 00:15, Christopher Hillenbrand wrote:
Dear LyX developers,
Here's a patch for adjusting editor text width in windowed mode (see
ticket https://www.lyx.org/trac/ticket/9376). It's an adaptation of
the previous patch uploaded by stwitt (two years ago). Please try it
out when you get
On 27/10/2022 18:12, Jean-Marc Lasgouttes wrote:
Concerning the 7in default: I see in LaTeX sources that the default text
width is 360pt, that is, 5in. What does the 7in come from? [I am not
asking for change, I ask :)]
I am not asking for change, I just answer:
It came from you: https://www.
Am Sonntag, dem 30.10.2022 um 16:39 -0400 schrieb Christopher
Hillenbrand:
> That is a valid point!
> Restricting the units and using a CheckedLineEdit are still probably
> worthwhile considering, so here are those changes separately.
Thanks. I have some thoughts about that:
* The validator allow
That is a valid point!
Restricting the units and using a CheckedLineEdit are still probably
worthwhile considering, so here are those changes separately.
Best regards,
Chris
On Sun, Oct 30, 2022 at 3:11 PM Jürgen Spitzmüller wrote:
>
> Am Sonntag, dem 30.10.2022 um 11:43 -0400 schrieb Christophe
Am Sonntag, dem 30.10.2022 um 11:43 -0400 schrieb Christopher
Hillenbrand:
> I am attaching a patch that implements Jean-Marc's checkbox-free UI
> suggestion and restricts the available units to inches, cm, and
> %textwidth.
Actually, I find the checkbox helpful. It allows to quickly switch
on/off
Dear Jürgen and Jean-Marc:
Thanks for cleaning up my patch and committing it!
> Concerning the 7in default: I see in LaTeX sources that the default text
> width is 360pt, that is, 5in. What does the 7in come from? [I am not
> asking for change, I ask :)]
The 7 in default is from the discussion o
Am Sonntag, dem 23.10.2022 um 18:15 -0400 schrieb Christopher
Hillenbrand:
> Dear LyX developers,
>
> Here's a patch for adjusting editor text width in windowed mode (see
> ticket https://www.lyx.org/trac/ticket/9376). It's an adaptation of
> the previous patch uploaded by stwitt (two years ago).
Am Donnerstag, dem 27.10.2022 um 18:12 +0200 schrieb Jean-Marc
Lasgouttes:
> Note that the unit selector is usually after the value.
I fixed this and also removed the redundant "Screen used" label.
--
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo
Le 25/10/2022 à 16:39, Christopher Hillenbrand a écrit :
Thanks for testing my patch, Cor! (And thanks, Jürgen, for your feedback)
I agree in principle with your proposed improvements. One possible
solution is to go back to using pixels--currently, the fullscreen
width is limited this way. It is
Thanks for testing my patch, Cor! (And thanks, Jürgen, for your feedback)
I agree in principle with your proposed improvements. One possible
solution is to go back to using pixels--currently, the fullscreen
width is limited this way. It is also possible to display only inches
and cm as units.
It
Op 24-10-2022 om 00:15 schreef Christopher Hillenbrand:
Dear LyX developers,
Here's a patch for adjusting editor text width in windowed mode (see
ticket https://www.lyx.org/trac/ticket/9376). It's an adaptation of
the previous patch uploaded by stwitt (two years ago). Please try it
out when you
Am Sonntag, dem 23.10.2022 um 18:15 -0400 schrieb Christopher
Hillenbrand:
> Dear LyX developers,
>
> Here's a patch for adjusting editor text width in windowed mode (see
> ticket https://www.lyx.org/trac/ticket/9376). It's an adaptation of
> the previous patch uploaded by stwitt (two years ago).
AR:
case LyXRC::RC_FULL_SCREEN_TABBAR:
case LyXRC::RC_FULL_SCREEN_TOOLBARS:
- case LyXRC::RC_FULL_SCREEN_WIDTH:
+ case LyXRC::RC_SCREEN_WIDTH:
case LyXRC::RC_VISUAL_CURSOR:
case LyXRC::RC_CLOSE_BUFFER_WITH_LAST_VIEW:
case LyXRC::RC_VIEWER:
diff --git a/src/LyXRC.h b/src/LyXRC.h
index 6e82
On 2020-08-01 14:04, racoon wrote:
On 2020-08-01 13:42, Stephan Witt wrote:
Am 01.08.2020 um 12:50 schrieb racoon :
On 2020-08-01 12:43, Stephan Witt wrote:
Am 01.08.2020 um 09:48 schrieb Daniel :
I am trying to fix Ticket #9376. My attempt so far is attached.
However, I have hit a little
ed7511a6d1..3a631ad86b 100644
--- a/src/LyXRC.h
+++ b/src/LyXRC.h
@@ -86,13 +86,13 @@ public:
RC_FILEFORMAT,
RC_FORWARD_SEARCH_DVI,
RC_FORWARD_SEARCH_PDF,
- RC_FULL_SCREEN_LIMIT,
+ RC_SCREEN_LIMIT,
RC_FULL_SCREEN
Am 01.08.2020 um 12:50 schrieb racoon :
>
> On 2020-08-01 12:43, Stephan Witt wrote:
>> Am 01.08.2020 um 09:48 schrieb Daniel :
>>>
>>> I am trying to fix Ticket #9376. My attempt so far is attached. However, I
>>> have hit a little road block in that the clang compiler does not give me
>>> use
On 2020-08-01 12:43, Stephan Witt wrote:
Am 01.08.2020 um 09:48 schrieb Daniel :
I am trying to fix Ticket #9376. My attempt so far is attached. However, I have
hit a little road block in that the clang compiler does not give me useful
information (for me at least):
CXXLDlyx
Undefined sy
Am 01.08.2020 um 09:48 schrieb Daniel :
>
> I am trying to fix Ticket #9376. My attempt so far is attached. However, I
> have hit a little road block in that the clang compiler does not give me
> useful information (for me at least):
>
> CXXLDlyx
> Undefined symbols for architecture x86_64:
On 2020-08-01 09:56, Richard Kimberly Heck wrote:
On 8/1/20 3:48 AM, Daniel wrote:
I am trying to fix Ticket #9376. My attempt so far is attached.
However, I have hit a little road block in that the clang compiler
does not give me useful information (for me at least):
CXXLD lyx
Undefined sym
On 8/1/20 3:48 AM, Daniel wrote:
> I am trying to fix Ticket #9376. My attempt so far is attached.
> However, I have hit a little road block in that the clang compiler
> does not give me useful information (for me at least):
>
> CXXLD lyx
> Undefined symbols for architecture x86_64:
> "std::__
FULL_SCREEN_LIMIT,
+ RC_SCREEN_LIMIT,
RC_FULL_SCREEN_SCROLLBAR,
RC_FULL_SCREEN_STATUSBAR,
RC_FULL_SCREEN_TABBAR,
RC_FULL_SCREEN_MENUBAR,
RC_FULL_SCREEN_TOOLBARS,
- RC_FULL_SCREEN_WIDTH,
+
On Wed, May 16, 2018 at 04:03:44AM +, Zhexuan Gong wrote:
> Yes, it's still there in 2.3.0 and perfectly reproducible.
Thanks for checking.
Scott
signature.asc
Description: PGP signature
Yes, it's still there in 2.3.0 and perfectly reproducible.
On Tue, May 15, 2018 at 8:47 PM, Scott Kostyshak wrote:
> On Fri, Feb 02, 2018 at 06:25:25PM +, Scott Kostyshak wrote:
> > On Sat, Oct 28, 2017 at 12:47:29AM +, Zhexuan Gong wrote:
> > > Dear Lyx developers,
> > >
> > > I'm not s
On Fri, Feb 02, 2018 at 06:25:25PM +, Scott Kostyshak wrote:
> On Sat, Oct 28, 2017 at 12:47:29AM +, Zhexuan Gong wrote:
> > Dear Lyx developers,
> >
> > I'm not sure if any of you are aware of this bug. I'm using the latest
> > 2.2.3 Lyx on Mac. And whenever Lyx is in macOS' native full s
On Sat, Oct 28, 2017 at 12:47:29AM +, Zhexuan Gong wrote:
> Dear Lyx developers,
>
> I'm not sure if any of you are aware of this bug. I'm using the latest
> 2.2.3 Lyx on Mac. And whenever Lyx is in macOS' native full screen mode
> (using the green button on the title bar, not the View->Full S
Dear Lyx developers,
I'm not sure if any of you are aware of this bug. I'm using the latest
2.2.3 Lyx on Mac. And whenever Lyx is in macOS' native full screen mode
(using the green button on the title bar, not the View->Full Screen), the
document tab row will disappear mysteriously whenever a new
Le 26/04/2017 à 23:33, racoon a écrit :
Hi!
I think this patch went under the radar:
http://www.lyx.org/trac/ticket/9376
It would be great to have a way to set a fixed maximum line width in LyX.
I posted some ideas there. No please have a look at #10616 please ;)
http://www.lyx.org/trac/tick
Hi!
I think this patch went under the radar:
http://www.lyx.org/trac/ticket/9376
It would be great to have a way to set a fixed maximum line width in LyX.
Daniel
Hi Abdel
Thanks a lot for your help!
Indeed I use Qt 4.4. I commented out the lines that you told me and it
works now!
- Sebastian
in 1.2.0svn) this
feature disappeared again and the menu entries are not accessible from
the fullscreen mode, even if one knows the key-combinations by heart.
The menu-access is enabled by default on Windows and Mac in all 1.6.x
version and on Linux/X11 too starting with 1.6.4 (or 1.6.5svn) if
fullscreen mode, even if one knows the key-combinations by heart.
I am working permanently in fullscreen mode and use permanently
key-combinations like alt-i-l (insert label), alt-i-n-n (insert
lyx-note), alt-i-f (insert footnote), a-i-r (insert reference) and so
on.
Since I recently switched from the
in
fullscreen mode, but that's not a solution. I want to be in fullscreen,
without a menu, but I want to use the key-bindings that I can use in
ordinary mode. Abdel, do you remember your patch of that time? Where is
it gone?
Best, Sebastian
Hi Pavel
Thanks for the answer! So I have to wait for 1.6.4...
Good to hear at least that it's fixed there.
But I don't understand why it has been removed from the trunc for 1.6.0?
It has been in the trunc for all the 1.6.svn ... :(
Anyway, seems I have to compile.
- Sebastian
Sebastian Guttenberg wrote:
> Or is this problem already fixed in newer versions?
it was in 1.6.0 only for windows version. later versions
eg 1.6.4 has it in linux too.
pavel
Hi all
Last year, when still using the svn-version of lyx1.6, I was posting a
concern about the inability of accessing the menu entries in full screen
mode
(see the thread of May 15, 2008, 10:28 am,
http://n2.nabble.com/keep-menu-key-bindings-also-in-fullscreen-mode-td491005.html
)
At that time
> No, the Alt key is unfortunately heavily used in math, ex: Alt-m-f for a
> fraction.
Ah, sorry. See what you mean. I rarely use those, but the latex command
instead. That's why I didn't realize.
> > Will there be any other solution?
> >
>
> There will be one hopefully when I finally have
Sebastian Guttenberg wrote:
This feature has been disabled on Linux, or more exactly on X11 because
of annoying menubar popping up in math. It should be still there on Mac
and Windows.
? Well, the menu bar was only popping up if one used the alt key, and the
latter one only used
if one w
> This feature has been disabled on Linux, or more exactly on X11 because
> of annoying menubar popping up in math. It should be still there on Mac
> and Windows.
? Well, the menu bar was only popping up if one used the alt key, and the
latter one only used
if one wanted to access something fr
Sebastian Guttenberg wrote:
Hi Abdel
Remember that you wrote this patch for enabling the menu-key-bindings in
full-screen mode? I liked this feature very much but since my last
svn-update it disappeared :-( What happened? Can you include it again?
This feature has been disabled on Linux, or m
Hi Abdel
Remember that you wrote this patch for enabling the menu-key-bindings in
full-screen mode? I liked this feature very much but since my last
svn-update it disappeared :-( What happened? Can you include it again?
Best, Sebastian
> Abdelrazak Younes
> Wed, 28 May 2008 02:26:44 -0700
>
>> Seb
Sebastian Guttenberg wrote:
Hi Pavel and Abdel!
Thanks a lot for your answers. Sorry, for the late reaction, I forgot to
check the mailing list for a while.
To Abdel: This patch sounds like the perfect solution! I will try it
out! thanks a lot for bothering!
This is already in trunk, you don'
Hi Pavel and Abdel!
Thanks a lot for your answers. Sorry, for the late reaction, I forgot to
check the mailing list for a while.
To Abdel: This patch sounds like the perfect solution! I will try it
out! thanks a lot for bothering!
Best, Sebastian
--
This message has been scanned for viruses and
ghtly different and every touch can work in other way in different
systems.
The Alt key handling is directly handled by Qt. The solution is to
catch this key in the same way we catch the Tab key in
GuiView::event() (see QEvent::ShortcutOverride). Then, if we are in
fullscreen mode _and_ the me
touch can work in other way in different
systems.
The Alt key handling is directly handled by Qt. The solution is to
catch this key in the same way we catch the Tab key in
GuiView::event() (see QEvent::ShortcutOverride). Then, if we are in
fullscreen mode _and_ the menubar is hidden _and_ the pr
ay in different
systems.
The Alt key handling is directly handled by Qt. The solution is to catch
this key in the same way we catch the Tab key in GuiView::event() (see
QEvent::ShortcutOverride). Then, if we are in fullscreen mode _and_ the
menubar is hidden _and_ the pressed key is Alt, we s
Sebastian Guttenberg wrote:
>(and perhaps simple to implement?)
i don't know how to do it easily. also note that this fullscreen stuff
is more fragile part of code since every arch like win/linux/mac works
slightly different and every touch can work in other way in different
systems.
if you can't
Hi all
Having a small laptop screen, I like very much working in full-screen
modes. However, all menu-related key-bindings which I can use in the
ordinary mode (like e.g.for inserting a footnote) do not
work in the fullscreen mode. I would find it very convenient if all
menu-related key
> > 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 comi
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 pro
> 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/fronten
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
> > 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
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
can you try to repeat this behaviour when
just resizing
the window?
I only get it in fullscreen mode -- not when resizing the window. I
only noticed the problem today, but then I don't remember ever trying
the arrow keys after fullscreen mode previously; so I don't know if
it'
behaviour when just resizing
the window?
>> but certainly can't confirm 2 chars/second here. also dont know how this
>> could
>> be joined with fullscreen patch. it doesnt touch painting code.
>
> Note that the typing lag remains in fullscreen mode even when I have
&
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.
> 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) selecti
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
> 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
> > > >> 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 a
> > >> 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
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
>> 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
a check box 'Limit
text screen width' that will enable/disable the width edit box.
done.
Which means that you agree I guess... I am impressed by my power of
persuasion :-)
i need to call some kind of redraw when comming back from fullscreen mode
(scrollbar needs some update an
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
n (width_ - (lyxrc.full_screen_width * width_) / 100) / 2;
Why a proportional width? I think the max width in pixel is more sensible.
this is obviously clash of philosophies :) i like to have full width of screen
used.
Then just disable the fullscreen mode in BufferView?
width in pixels means i ne
>> 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
s toggling wont work with
them now)
2. borders of new tab in fullscreen mode are not correct.
(i will address these later).
comments welcomed.
int BufferView::rightMargin() const
{
- if (!full_screen_ || width_ < max_row_width + 20)
+ if (!full_screen_)
return 10
with
them now)
2. borders of new tab in fullscreen mode are not correct.
(i will address these later).
comments welcomed.
pavel
diff --git a/lib/bind/cua.bind b/lib/bind/cua.bind
index 91f37c5..93b42cf 100644
--- a/lib/bind/cua.bind
+++ b/lib/bind/cua.bind
@@ -112,6 +112,8 @@
ll be thousand and one opinions how the fullscreen mode should be
and i really dont want to spend my time on flames in maillist).
that one command can be done after these "by hand" toggles are done
(have no time atm, but plan to do it).
more clear now?
pavel
f by Qt. Remains the toolbars,
it should be easy to memorize their state and restore them back when
leaving the full screen mode. But, this should be a user setting: some
would prefer to hide the toolbars, others not (I don't). Same for the
scrollbar.
By the way Bennett (and Pavel),
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
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. Wo
toolbars, so we can show
them after getting back to normal mode.
> just tried MS Word fullscreen mode and I must say that it looks like a joke
> compared to what we have now :-) Good job Pavel!
thank you too ;) we can declare some contest between users who make the most
sexy
fullscre
I just tried MS Word fullscreen mode and I must say that it looks
like a joke compared to what we have now :-) Good job Pavel!
Abdel.
happens with my screen or fonts. but i dont understand what
has this to do with the width of painting screen.
It doesn't, I was think of zooming the screen fonts when working in
fullscreen mode. But apparently this is not what Bennett and others
want. Adding right and left margin is easy, righ
. but i dont understand what
has this to do with the width of painting screen.
It doesn't, I was think of zooming the screen fonts when working in
fullscreen mode. But apparently this is not what Bennett and others
want. Adding right and left margin is easy, right now they are hardcode
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
[Forwarding to list]
Begin forwarded message:
From: Hans Meine <[EMAIL PROTECTED]>
Date: February 9, 2008 7:33:13 AM EST
To: [EMAIL PROTECTED]
Subject: Re: Fullscreen mode (new patch)
On Samstag 09 Februar 2008, Bennett Helm wrote:
A final question/request (which may go beyond wh
>> 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
ntentional Pavel? If yes, I am impressed :-)
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?)
Second, Document > Outline does not work after fullscreen mode has been
invoke
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
o file is opened?
> Second, Document > Outline does not work after fullscreen mode has been
> invoked, even after returning to normal windowed mode. (The menu item
> successfully toggles as indicated by the checkmark, but no outline
> appears.)
this works under linux.
> I suspe
glitches I discovered in a few minutes of testing.
First, ui-toggle fullscreen does not work unless a document is open.
(Is that intentional?)
Second, Document > Outline does not work after fullscreen mode has
been invoked, even after returning to normal windowed mode. (The menu
item successful
TOGGLE, "toolbar-toggle", NoBuffer, Buffer },
{ LFUN_MENU_OPEN, "menu-open", NoBuffer, Buffer },
-/*!
- * \var lyx::kb_action lyx::LFUN_MENUBAR_TOGGLE
- * \li Action: Toggles visibility of the main menu.
- * \li Notion: This can be used for the fullscreen mode.
- * \
> > > 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
1 - 100 of 135 matches
Mail list logo
