13 schrieb Daniel :
>>>>>>>>>
>>>>>>>>> On 2020-07-30 21:21, Stephan Witt wrote:
>>>>>>>>>> Am 29.07.2020 um 22:59 schrieb Daniel :
>>>>>>>>>>>
>>>>>>
:
On 2020-08-01 09:32, Stephan Witt wrote:
Am 31.07.2020 um 07:13 schrieb Daniel :
On 2020-07-30 21:21, Stephan Witt wrote:
Am 29.07.2020 um 22:59 schrieb Daniel :
On 2020-07-29 21:03, Stephan Witt wrote:
Am 29.07.2020 um 10:15 schrieb LyX Ticket Tracker :
#10571: Tabs not showing properly
Am 04.08.2020 um 15:52 schrieb Jürgen Spitzmüller :
>
> Am Dienstag, den 04.08.2020, 15:42 +0200 schrieb Stephan Witt:
>>> It would be good if someone on more standard linux environment like
>>> GNOME/KDE
>>> could test as well.
>>
>>
>> That would be good.
>
> On GNOME I see no difference betw
0 21:21, Stephan Witt wrote:
>>>>>>>>> Am 29.07.2020 um 22:59 schrieb Daniel :
>>>>>>>>>>
>>>>>>>>>> On 2020-07-29 21:03, Stephan Witt wrote:
>>>>>>>>>>> Am 29.07.2020 um 10:15 schr
Am Dienstag, den 04.08.2020, 15:42 +0200 schrieb Stephan Witt:
> > It would be good if someone on more standard linux environment like
> > GNOME/KDE
> > could test as well.
>
>
> That would be good.
On GNOME I see no difference between master and stable.
Jürgen
signature.asc
Description: This
Am 03.08.2020 um 23:45 schrieb Pavel Sanda :
>
> On Sun, Aug 02, 2020 at 10:55:55AM +0200, Stephan Witt wrote:
>> Here is the current state of my patch to improve switch to/from full-screen.
>>
>> It contains additional code to detect switch to/from window maximize state.
>> This is actually not
On Sun, Aug 02, 2020 at 10:55:55AM +0200, Stephan Witt wrote:
> Here is the current state of my patch to improve switch to/from full-screen.
>
> It contains additional code to detect switch to/from window maximize state.
> This is actually not used yet. On Mac it could be a possibility to implemen
:
On 2020-07-30 21:21, Stephan Witt wrote:
Am 29.07.2020 um 22:59 schrieb Daniel :
On 2020-07-29 21:03, Stephan Witt wrote:
Am 29.07.2020 um 10:15 schrieb LyX Ticket Tracker :
#10571: Tabs not showing properly in macOS full (and split) screen
Am 02.08.2020 um 17:52 schrieb Yu Jin :
>
> Am So., 2. Aug. 2020 um 10:56 Uhr schrieb Stephan Witt :
> Does it work as expected for you and on Linux? Can anyone test it on Windows,
> please?
>
> I have tested on Windows. First I want to mention that your patch was
> corrupted, git said "error:
itt wrote:
>>>>> Am 31.07.2020 um 07:13 schrieb Daniel :
>>>>>>
>>>>>> On 2020-07-30 21:21, Stephan Witt wrote:
>>>>>>> Am 29.07.2020 um 22:59 schrieb Daniel :
>>>>>>>>
>>>>>>>> On 2020-07-29 21:0
Am So., 2. Aug. 2020 um 10:56 Uhr schrieb Stephan Witt :
> Does it work as expected for you and on Linux? Can anyone test it on
> Windows, please?
>
I have tested on Windows. First I want to mention that your patch was
corrupted, git said "error: corrupted patch at line 21", I had to add a
whites
On Sun, Aug 2, 2020 at 2:56 AM Stephan Witt wrote:
>
> Does it work as expected for you and on Linux? Can anyone test it on
> Windows, please?
>
I can test on Windows 10 with a 4K display, but I cannot build. If you can
send an installer, I'll give it a try.
Thanks,
Joel
--
lyx-devel mailing
:
On 2020-07-29 21:03, Stephan Witt wrote:
Am 29.07.2020 um 10:15 schrieb LyX Ticket Tracker :
#10571: Tabs not showing properly in macOS full (and split) screen
---+-
Reporter: racoon | Owner: lasgouttes
Type: defect | Status
>> Am 29.07.2020 um 22:59 schrieb Daniel :
>>>>>>
>>>>>> On 2020-07-29 21:03, Stephan Witt wrote:
>>>>>>> Am 29.07.2020 um 10:15 schrieb LyX Ticket Tracker :
>>>>>>>>
>>>>>>>>
t;>> On 2020-07-29 21:03, Stephan Witt wrote:
>>>>>> Am 29.07.2020 um 10:15 schrieb LyX Ticket Tracker :
>>>>>>>
>>>>>>> #10571: Tabs not showing properly in macOS full (and split) screen
>>>>>>> ---
On 2020-08-01 09:32, Stephan Witt wrote:
Am 31.07.2020 um 07:13 schrieb Daniel :
On 2020-07-30 21:21, Stephan Witt wrote:
Am 29.07.2020 um 22:59 schrieb Daniel :
On 2020-07-29 21:03, Stephan Witt wrote:
Am 29.07.2020 um 10:15 schrieb LyX Ticket Tracker :
#10571: Tabs not showing properly
Am 31.07.2020 um 07:13 schrieb Daniel :
>
> On 2020-07-30 21:21, Stephan Witt wrote:
>> Am 29.07.2020 um 22:59 schrieb Daniel :
>>>
>>> On 2020-07-29 21:03, Stephan Witt wrote:
>>>> Am 29.07.2020 um 10:15 schrieb LyX Ticket Tracker :
>>>>&g
On 2020-07-30 21:21, Stephan Witt wrote:
Am 29.07.2020 um 22:59 schrieb Daniel :
On 2020-07-29 21:03, Stephan Witt wrote:
Am 29.07.2020 um 10:15 schrieb LyX Ticket Tracker :
#10571: Tabs not showing properly in macOS full (and split) screen
Am 29.07.2020 um 22:59 schrieb Daniel :
>
> On 2020-07-29 21:03, Stephan Witt wrote:
>> Am 29.07.2020 um 10:15 schrieb LyX Ticket Tracker :
>>>
>>> #10571: Tabs not showing properly in macOS full (and split) screen
>>> ---+
Am 30.07.2020 um 16:33 schrieb Pavel Sanda :
>
> On Wed, Jul 29, 2020 at 09:03:27PM +0200, Stephan Witt wrote:
>> The attached patch improves the situation on Mac. I???m confident that this
>> is the right move.
>> But I???m unable to tell if it works on other platforms or if it breaks the
>> cu
On Wed, Jul 29, 2020 at 09:03:27PM +0200, Stephan Witt wrote:
> The attached patch improves the situation on Mac. I???m confident that this
> is the right move.
> But I???m unable to tell if it works on other platforms or if it breaks the
> current state.
>
> Furthermore I???m not sure what to d
On 2020-07-29 21:03, Stephan Witt wrote:
Am 29.07.2020 um 10:15 schrieb LyX Ticket Tracker :
#10571: Tabs not showing properly in macOS full (and split) screen
---+-
Reporter: racoon | Owner: lasgouttes
Type: defect
Am 29.07.2020 um 10:15 schrieb LyX Ticket Tracker :
>
> #10571: Tabs not showing properly in macOS full (and split) screen
> ---+-
> Reporter: racoon | Owner: lasgouttes
> Type: defect | Status: new
>
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
he
> > > document tab row will disappear mysteriously whenever a new document is
> > > created or the current tab is closed. This is annoying since one cannot
> > > switch between tabs any more. The problem will persist even if one
> exit the
> > > full screen
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 document is
> > created or the current tab is closed. This is annoying since one ca
On Sun, Dec 24, 2017 at 05:22:46PM +, john kennan wrote:
> When two files are open in tabs, with Tables selected in the outline pane
> in the first file, the selection doesn't hold after switching to the other
> file and back if the other file has no tables -- the selection reve
title bar, not the View->Full Screen), the
> document tab row will disappear mysteriously whenever a new document is
> created or the current tab is closed. This is annoying since one cannot
> switch between tabs any more. The problem will persist even if one exit the
> full screen mo
When two files are open in tabs, with Tables selected in the outline pane
in the first file, the selection doesn't hold after switching to the other
file and back if the other file has no tables -- the selection reverts to
Table of Contents. This seems undesirable (OSX, 2.3rc1).
John
sly whenever a new document is
created or the current tab is closed. This is annoying since one cannot
switch between tabs any more. The problem will persist even if one exit the
full screen mode. The only way to make the tab row reappear is to first
exit the full screen mode, then enter the full
Am Freitag, 22. Mai 2015 um 10:41:38, schrieb Juergen Spitzmueller
> + tab_tooltip = qt_("%1 (read only)").arg(it->abs());
Is this really correct? Looks suspect.
Kornel
signature.asc
Description: This is a digitally signed message part.
On Mon, Apr 28, 2014 at 4:11 AM, Vincent van Ravesteijn wrote:
>
>
>
> On Wed, Apr 23, 2014 at 3:28 PM, Scott Kostyshak wrote:
>>
>> On Tue, Apr 22, 2014 at 1:09 AM, F M Salter
>> wrote:
>> > I have checked that this behavior does not occur with 2.1rc1.
>> > However the ticket appears not to be
On Wed, Apr 23, 2014 at 3:28 PM, Scott Kostyshak wrote:
> On Tue, Apr 22, 2014 at 1:09 AM, F M Salter
> wrote:
> > I have checked that this behavior does not occur with 2.1rc1.
> > However the ticket appears not to be accessible through the bug tracker.
> > Regards
> > Frank Salter
>
> Hi Frank,
On Tue, Apr 22, 2014 at 1:09 AM, F M Salter wrote:
> I have checked that this behavior does not occur with 2.1rc1.
> However the ticket appears not to be accessible through the bug tracker.
> Regards
> Frank Salter
Hi Frank,
Thanks for the feedback. I marked the bug as fixed.
Scott
I have checked that this behavior does not occur with 2.1rc1.
However the ticket appears not to be accessible through the bug tracker.
Regards
Frank Salter
On 20/04/14 19:42, LyX Ticket Tracker wrote:
#7631: Page tabs disappear with table tools
On Tue, Nov 26, 2013 at 4:16 PM, Juergen Spitzmueller wrote:
> commit 766e8b1e3319c75bebb9811af6dc3df97d9a0119
> Author: Juergen Spitzmueller
> Date: Tue Nov 26 16:12:52 2013 +0100
>
> Also when not using tabs, do not open a file twice if already opened
> (part of #8787
On Thu, Jan 5, 2012 at 10:44 AM, Gustav Eje Henter
wrote:
> On 2012-01-04 20:55, Liviu Andronic wrote:
>> [1] http://www.lyx.org/trac/ticket/5861
>
>
> Thank you for your reply.
>
> I noticed that bug, but I don't think that is what I'm seeing. The one table
> I have has eight rows and five column
On 2012-01-04 20:55, Liviu Andronic wrote:
On Wed, Jan 4, 2012 at 12:16 PM, Gustav Eje Henter wrote:
The issue is that some tabs are very sluggish. Scrolling takes approximately
LyX is known to be slow when displaying _long_ tables. The issue is
that the table is being redrawn at each key
On Wed, Jan 4, 2012 at 12:16 PM, Gustav Eje Henter
wrote:
> The issue is that some tabs are very sluggish. Scrolling takes approximately
>
LyX is known to be slow when displaying _long_ tables. The issue is
that the table is being redrawn at each key press. Is this [1] what
you're see
On On 04/01/12 14:54, Rainer wrote:
On 04/01/12 14:40, Vasek wrote:
Hi, I had the same problem on 11.04. Upgrade to the latest version
solved it for me. I did the following:
1. run: sudo apt-get build-dep lyx
2. Download source packages for the latest LyX from precise:
http://packages.ubuntu.c
Hi,
I had the same problem on 11.04. Upgrade to the latest version solved it for
me.
I did the following:
1. run: sudo apt-get build-dep lyx
2. Download source packages for the latest LyX from precise:
http://packages.ubuntu.com/precise/lyx
[lyx_2.0.2-1ubuntu1.dsc]
[lyx_2.0.2.orig.tar.gz]
[lyx_2
Gustav Eje Henter wrote:
> The issue is that some tabs are very sluggish. Scrolling takes
> approximately one second per tick on the mouse wheel, and similarly for
> Page Up/Page Down. Typing sometimes lags many characters behind, math mode
> being particularly bad at appro
> >
> > Hi, I had the same problem on 11.04. Upgrade to the latest version
> > solved it for me. I did the following:
>
> Definitely recommended, but I experienced a considerable slow down in
> scrolling when floats with graphics / tables are open - may be the
> case for you as well?
For me, 2.0
es for a while which have been
>> slowing my work.
>>
>> The issue is that some tabs are very sluggish. Scrolling takes
>> approximately
> one
>> second per tick on the mouse wheel, and similarly for Page
>> Up/Page Down.
> Typing
>> sometimes lags ma
Gustav Eje Henter ee.kth.se> writes:
>
> Hello LyX people,
>
> Thank you for a wonderful piece of software! Unfortunately, I've been seeing
> performance issues for a while which have been slowing my work.
>
> The issue is that some tabs are very sluggish. Scrol
Hello LyX people,
Thank you for a wonderful piece of software! Unfortunately, I've been seeing
performance issues for a while which have been slowing my work.
The issue is that some tabs are very sluggish. Scrolling takes approximately one
second per tick on the mouse wheel, and simi
Am 09.10.2010 um 13:32 schrieb LyX Ticket Tracker:
> #5970: tab switching keyboard shortcut only works with three or more tabs
> --+-
> Changes (by spitz):
>
> * keywords: os=macosx => os=macosx fixedinb
xPol wrote:
> To increase space for the doc title in tabs, it would be convenient not
> to display the 'close' button, except while hovering on the tab.
It's not exactly what you want, but you can get rid of the close buttons (in
favour of a global one) in Preferences
To increase space for the doc title in tabs, it would be convenient not to
display the 'close' button, except while hovering on the tab.
P
Jean-Marc Lasgouttes wrote:
> Should we have different defaults on different platforms?
Yes, I would think there are OS-specific conventions indeed.
Jürgen
Jürgen Spitzmüller wrote:
>> Is that a konqueror-only setting or a system-wide one?
>
> Konqueror-only AFAICS. KMail also has tabs, but they (still) have a
> general button only, plus a context menu.
And to add even more confusion: Dolphin, the new standard file manager, has
Jürgen Spitzmüller writes:
> Jean-Marc Lasgouttes wrote:
>
>> Is that a konqueror-only setting or a system-wide one?
>
> Konqueror-only AFAICS. KMail also has tabs, but they (still) have a general
> button only, plus a context menu.
I guess that, if everybody does it in h
nqueror-only setting or a system-wide one?
JMarc
> Firefox (3.0.4 here) has buttons per tabs, too. I did not find a way to
> alter this.
Indeed. Note that firefox has undo for tab closing (S-C-t), this
mitigates potential errors.
JMarc
Jean-Marc Lasgouttes wrote:
> Is that a konqueror-only setting or a system-wide one?
Konqueror-only AFAICS. KMail also has tabs, but they (still) have a general
button only, plus a context menu.
> Note that firefox has undo for tab closing (S-C-t), this
> mitigates potential errors
f in
prefs and have one button for all (as we used to have and as previous KDE
versions had).
Firefox (3.0.4 here) has buttons per tabs, too. I did not find a way to
alter this.
Jürgen
Jean-Marc Lasgouttes wrote:
> Pavel Sanda writes:
>
> > Pavel Sanda wrote:
> >
> > are there some objections to put this into trunk?
>
> Well, I'd prefer a well-thought solution that works for everybody.
i'm not sure what you mean. this rc setting was created because people
have different ideas
Pavel Sanda writes:
> Pavel Sanda wrote:
>
> are there some objections to put this into trunk?
Well, I'd prefer a well-thought solution that works for everybody. What
is the KDE/qt4 standard in this respect?
JMarc
Hi all
If one opens several tabs, in particular 4 or more and changes the order
of the tabs using the mouse, then this order change is not taken into
account for the key-combinations or to
navigate through the tabs. They still follow the original tab-order.
- Sebastian
Pavel Sanda wrote:
are there some objections to put this into trunk?
pavel
> diff --git a/src/LyXRC.cpp b/src/LyXRC.cpp
> index b79d4be..7de65b9 100644
> --- a/src/LyXRC.cpp
> +++ b/src/LyXRC.cpp
> @@ -165,6 +165,7 @@ LexerKeyword lyxrcTags[] = {
> { "\\serverpipe", LyXRC::RC_SERVERPIPE },
hi,
i thought the fix for http://www.lyx.org/trac/ticket/5977 would be
easyfix but i was wrong. the problem is how to update guiview after
preferences get applied.
the patch below at least let this change happen after some bigger updates
like fullscreen switch. until its fixed i consider this op
> hi Vincent,
> we have problem with the new tabs in listings. tab is not
> supposed to add fixed number of spaces, but instead jump
> to the next tabstop.
> this correctly adhered in tex output, but lyx gui shows
> it wrongly so "//" commetaries in C code done
Vincent van Ravesteijn - TNW wrote:
> I know this. [quilty_smiley] Introducing tabstops would have complicated
> the general painting and cursor painting [unhappy_smiley]. At least I
> thought so at the time I did it.
i trust your decision.
pavel
hi Vincent,
we have problem with the new tabs in listings. tab is not supposed
to add fixed number of spaces, but instead jump to the next tabstop.
this correctly adhered in tex output, but lyx gui shows it wrongly
so "//" commetaries in C code done by tabs are not correctly aligned...
pavel
nto the file (one or more, in various windows and tabs).
In the menus this should be represented IMHO (and some HIGs) with
1) Open File (opens file in current window into a new tab)
2) Close File (closes file in ALL views)
3) New Tab (opens a new empty tab)
Not possible. A tab is a document view
, in various windows and tabs).
In the menus this should be represented IMHO (and some HIGs) with
1) Open File (opens file in current window into a new tab)
2) Close File (closes file in ALL views)
3) New Tab (opens a new empty tab)
Not possible. A tab is a document view, it cannot be empty. But
Something relevant for the menus, but not quite clear to me (and I
believe in parts a bit buggy/inconsistent). Maybe somebody can explain.
What I think we should have (conceptually):
a) "Files" (=documents)
and
b) "Views" onto the file (one or more, in various windows and
Abe Lau wrote:
Trying out lyx 1.6.0beta3 (texlive-latex-2007) on Gentoo Linux, with the
option "Load opened files from last session", the order of files in the tabs
are not preserved but all alphabetically sorted. I suppose preserving the
tab order would be a good idea, as what versi
Trying out lyx 1.6.0beta3 (texlive-latex-2007) on Gentoo Linux, with the
option "Load opened files from last session", the order of files in the tabs
are not preserved but all alphabetically sorted. I suppose preserving the
tab order would be a good idea, as what version 1.5 did as
Stefan Schimanski wrote:
I cooked up some more clever elide mode for the LyX buffer tabs. In
trunk currently the whole path is used (possibly with some
unmotivated ... in the middle) which is usually far too long.
The algorithm I propose here will start with absolute paths. From
left to
I cooked up some more clever elide mode for the LyX buffer tabs. In
trunk currently the whole path is used (possibly with some
unmotivated ... in the middle) which is usually far too long.
The algorithm I propose here will start with absolute paths. From
left to right single path segments
Hi!
I cooked up some more clever elide mode for the LyX buffer tabs. In
trunk currently the whole path is used (possibly with some
unmotivated ... in the middle) which is usually far too long.
The algorithm I propose here will start with absolute paths. From left
to right single path
Eric Cavalcanti wrote:
Hi again,
Another related suggestion: there should be an option to open in a new
window, so we can put two windows side-by-side when editing multiple files.
This would greatly improve efficiency when editing a file with data from
another one.
File>New Window.
I ju
On 18/3/08 6:40 PM, "Stefan Schimanski" <[EMAIL PROTECTED]> wrote:
>
> Am 18.03.2008 um 09:33 schrieb Jean-Marc Lasgouttes:
>
>> Stefan Schimanski <[EMAIL PROTECTED]> writes:
>>
>>> I suggest the following, i.e. only the base name without path or
>>> extension. Just a simple appended '*' for c
Am 18.03.2008 um 09:33 schrieb Jean-Marc Lasgouttes:
Stefan Schimanski <[EMAIL PROTECTED]> writes:
I suggest the following, i.e. only the base name without path or
extension. Just a simple appended '*' for changed buffers and the
Qt::ElideNone mode to avoid the useless "...". In short: as
min
Stefan Schimanski <[EMAIL PROTECTED]> writes:
> I suggest the following, i.e. only the base name without path or
> extension. Just a simple appended '*' for changed buffers and the
> Qt::ElideNone mode to avoid the useless "...". In short: as
> minimalistic as possible.
The name with path was a r
Am 18.03.2008 um 01:39 schrieb Eric Cavalcanti:
On 18/3/08 10:35 AM, "Stefan Schimanski" <[EMAIL PROTECTED]> wrote:
Am 17.03.2008 um 07:09 schrieb Eric Cavalcanti:
Hi,
This is a suggestion for improvement on the tabs when we have
multiple open
files. Those who work with
On 18/3/08 10:35 AM, "Stefan Schimanski" <[EMAIL PROTECTED]> wrote:
>
> Am 17.03.2008 um 07:09 schrieb Eric Cavalcanti:
>
>> Hi,
>>
>> This is a suggestion for improvement on the tabs when we have
>> multiple open
>> files. Those who wo
Am 17.03.2008 um 07:09 schrieb Eric Cavalcanti:
Hi,
This is a suggestion for improvement on the tabs when we have
multiple open
files. Those who work with many open files (as you may need in a
thesis or a
book with many chapters) have probably noticed that the caption in
the tabs
all
Am 18.03.2008 um 01:24 schrieb Eric Cavalcanti:
Hi again,
Another related suggestion: there should be an option to open in a
new
window, so we can put two windows side-by-side when editing
multiple files.
This would greatly improve efficiency when editing a file with
data from
another o
Hi again,
>> Another related suggestion: there should be an option to open in a new
>> window, so we can put two windows side-by-side when editing multiple files.
>> This would greatly improve efficiency when editing a file with data from
>> another one.
>>
>>
> File>New Window.
I just found
Hi,
On 18/3/08 3:00 AM, "Richard Heck" <[EMAIL PROTECTED]> wrote:
> Eric Cavalcanti wrote:
>> Hi,
(...)
> Can you please bugzilla some of this? Some of these are enhancements,
> but some of them are just bugs.
Will do.
>> Another related suggestion: there should be an option to open in a new
>>
> It would also be nice to be able to drag and drop to change the order of the
> tabs.
this is implemented in 1.6
p
Eric Cavalcanti wrote:
Hi,
This is a suggestion for improvement on the tabs when we have multiple open
files. Those who work with many open files (as you may need in a thesis or a
book with many chapters) have probably noticed that the caption in the tabs
all become ".." after a
Hi,
This is a suggestion for improvement on the tabs when we have multiple open
files. Those who work with many open files (as you may need in a thesis or a
book with many chapters) have probably noticed that the caption in the tabs
all become ".." after a few files are open, which
Stefan Schimanski wrote:
Am 14.03.2008 um 23:13 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 14.03.2008 um 19:50 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Here is another try, following your proposal.
Sorry Stefan, I won't have the time to review it for the next two
wee
Am 14.03.2008 um 23:13 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 14.03.2008 um 19:50 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Here is another try, following your proposal.
Sorry Stefan, I won't have the time to review it for the next two
weeks (going on well deserve
Stefan Schimanski wrote:
Am 14.03.2008 um 19:50 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Here is another try, following your proposal.
Sorry Stefan, I won't have the time to review it for the next two
weeks (going on well deserved vacations). But I trust your code anyway
so I gue
Am 14.03.2008 um 19:50 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Here is another try, following your proposal.
Sorry Stefan, I won't have the time to review it for the next two
weeks (going on well deserved vacations). But I trust your code
anyway so I guess it should be OK. Cros
Stefan Schimanski wrote:
Here is another try, following your proposal.
Sorry Stefan, I won't have the time to review it for the next two weeks
(going on well deserved vacations). But I trust your code anyway so I
guess it should be OK. Cross-checking with Andre' might be a good thing
too ;-).
Here is another try, following your proposal.
Stefan
0001-preference-option-to-open-buffers-in-tabs-or-new-w.patch
Description: Binary data
0002-on-Mac-close-GuiView-when-the-last-tab-was-closed.patch
Description: Binary data
0003-create-global-menubar-on-Mac-without-a-parent.-It.patch
- on Mac, there is one unique toolbar so, when the last GuiView is
closed, the global toolbar should be hidden. This means that we
should keep trace of the global menubar pointer when created.
What do you mean here?
Stefan
So I reimplemented everything like you proposed. But I cannot get
the shortcuts to work. They are handled usually by the
GuiView::event(..) handler. If there is no GuiView around, this does
not work. There are some kind of low level event filter in
QApplication, but I am not sure that's rig
Am 13.03.2008 um 10:25 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 13.03.2008 um 08:36 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Here is a series of patches
1) which add an open-in-window mode (enabled on Mac by default)
That's fine.
2) which keep LyX running, even af
Stefan Schimanski wrote:
Am 13.03.2008 um 08:36 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Here is a series of patches
1) which add an open-in-window mode (enabled on Mac by default)
That's fine.
2) which keep LyX running, even after closing the last window on Mac
Not fine, see
Am 13.03.2008 um 08:36 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Here is a series of patches
1) which add an open-in-window mode (enabled on Mac by default)
That's fine.
2) which keep LyX running, even after closing the last window on Mac
Not fine, see below.
3) which close a
Stefan Schimanski <[EMAIL PROTECTED]> writes:
> Here is a series of patches
>
> 1) which add an open-in-window mode (enabled on Mac by default)
Please do not use an #ifdef to set this default. This should be
simply set in the mac's lyxrc.dist.
JMarc
Abdelrazak Younes wrote:
Stefan Schimanski wrote:
Here is a series of patches
1) which add an open-in-window mode (enabled on Mac by default)
That's fine.
2) which keep LyX running, even after closing the last window on Mac
Not fine, see below.
3) which close a window when the last tab
Stefan Schimanski wrote:
Here is a series of patches
1) which add an open-in-window mode (enabled on Mac by default)
That's fine.
2) which keep LyX running, even after closing the last window on Mac
Not fine, see below.
3) which close a window when the last tab is closed on Mac
That sh
On Mar 12, 2008, at 5:52 PM, Stefan Schimanski wrote:
Am 12.03.2008 um 22:49 schrieb Andre Poenitz:
On Wed, Mar 12, 2008 at 10:40:07PM +0100, Stefan Schimanski wrote:
Here is a series of patches
1) which add an open-in-window mode (enabled on Mac by default)
2) which keep LyX running, even a
Am 12.03.2008 um 22:49 schrieb Andre Poenitz:
On Wed, Mar 12, 2008 at 10:40:07PM +0100, Stefan Schimanski wrote:
Here is a series of patches
1) which add an open-in-window mode (enabled on Mac by default)
2) which keep LyX running, even after closing the last window on Mac
3) which close a wi
1 - 100 of 161 matches
Mail list logo
