Pavel Sanda wrote:
> hi,
>
> time to think about beta3.
> there is already a couple of things which need to be released
> and tested so we should start freezing at certain time.
friday night i would like to freeze trunk, let it for testing
during the weekend and release new beta in sun/mon...
p
Pavel Sanda wrote:
> text. the rest is usable for middle button pasting - primary-selection-paste
> pushes whats in selection stack (i.e. select something in terminal and middle
> button for putting inside lyx). selection-paste takes selected text inside
> lyx window push it into stack and then aga
Tommaso Cucinotta wrote:
>> After a look at the code, I'm puzzled with the purpose and functionality
>> of the related LFUNs:
>> { LFUN_PASTE, "paste", Noop, Edit },
>> { LFUN_CLIPBOARD_PASTE, "clipboard-paste", Noop, Edit },
>> { LFUN_PRIMARY_SELECTION_PASTE, "primary-
Tommaso Cucinotta wrote:
>>
>> Edit -> Paste Special -> Simple Text (by Lines) (C-S-v),
>>
>> then the pasted line gets itemized, numbered, etc., i.e., the format is
>> copied instead of being ignored as I thought it should have been.
>>
>> Is this a bug ? Should it be reported on the Trac, or i
sp...@lyx.org wrote:
> Author: spitz
> Date: Mon Jan 3 21:53:37 2011
> New Revision: 37090
> URL: http://www.lyx.org/trac/changeset/37090
>
> Log:
> * nn.po: revert to previous. Something is fishy.
> "Plural-Forms: nplurals=2; plural=n != 1;\n"
> -"Language: nn"
> +<<< .mine
> +"Language: n
On Mon, Jan 3, 2011 at 9:06 PM, Stephan Witt wrote:
> Am 03.01.2011 um 20:11 schrieb LyX Ticket Tracker:
>
>> #7151: Math/Table autoshow broken in OS X (2.0b2)
>> -+--
>> Reporter: metrics | Owner: lasgouttes
>>
Am 03.01.2011 um 18:40 schrieb LyX Ticket Tracker:
> #1720: LyX/Mac: TOC Menus entries are not correctly disabled when a dialog has
> focus
>
> Comment:
>
> Stephan,
>
> Can you share your thoughts about this bug ?
Sorry, I didn't had this one at the list.
I'll have a look and answer ASAP.
St
Am 03.01.2011 um 20:11 schrieb LyX Ticket Tracker:
> #7151: Math/Table autoshow broken in OS X (2.0b2)
> -+--
> Reporter: metrics |Owner: lasgouttes
> Type: defect | Status: closed
> Priority: nor
> I see. Another possibility: toggle fullscreen.
>
> Stephan
No I don't think so.
GuIView::resetDialogs() call "constructToolbars();". So, only in this
case it is absolutely necessary that we have saved the toolbar
settings, otherwise they are lost during the construction of the
toolbars.
Vincen
Am 03.01.2011 um 17:10 schrieb Vincent van Ravesteijn:
In GuiApplication::readUIFile() the settings for views gets removed if the
ui file is newer than the saved timestamp in the settings.
Later the non existing settings will be used to initialize the visibility.
The default va
>>> In GuiApplication::readUIFile() the settings for views gets removed if the
>>> ui file is newer than the saved timestamp in the settings.
>>> Later the non existing settings will be used to initialize the visibility.
>>> The default value for a non existing setting is 0.
>>>
> I say yes.
But w
Am 03.01.2011 um 15:25 schrieb Vincent van Ravesteijn:
>> Ha! That's it.
>>
>> The combination of changed ui file and already stored settings is the
>> culprit. Thanks!
>>
>> In GuiApplication::readUIFile() the settings for views gets removed if the
>> ui file is newer than the saved timestamp
> Ha! That's it.
>
> The combination of changed ui file and already stored settings is the
> culprit. Thanks!
>
> In GuiApplication::readUIFile() the settings for views gets removed if the
> ui file is newer than the saved timestamp in the settings.
> Later the non existing settings will be used t
Am 03.01.2011 um 13:56 schrieb Abdelrazak Younes:
> On 01/03/2011 09:26 AM, Vincent van Ravesteijn wrote:
>> Furthermore, I'm not sure yet what causes the bug, because it seems
>> that if the user sets the toolbar visibility from within LyX, this
>> setting is lost again on the new start-up of LyX
On 01/03/2011 02:03 PM, Vincent van Ravesteijn wrote:
Furthermore, I'm not sure yet what causes the bug, because it seems
that if the user sets the toolbar visibility from within LyX, this
setting is lost again on the new start-up of LyX. Why are the settings
not stored properly when exiting LyX
>> Furthermore, I'm not sure yet what causes the bug, because it seems
>> that if the user sets the toolbar visibility from within LyX, this
>> setting is lost again on the new start-up of LyX. Why are the settings
>> not stored properly when exiting LyX ?
>
> AFAIR LyX checks the time tag of "ui/d
On 01/03/2011 09:26 AM, Vincent van Ravesteijn wrote:
Furthermore, I'm not sure yet what causes the bug, because it seems
that if the user sets the toolbar visibility from within LyX, this
setting is lost again on the new start-up of LyX. Why are the settings
not stored properly when exiting LyX
>
> I would add the name of the toolbar to the error message.
Ok.
> And if the settings were written with the default value for visibility_ (0)
> then restoreSession() happily will restore that nonsense value.
>
You are right. But we should never write a value of 0.
Do you already have an idea
Am 03.01.2011 um 13:13 schrieb Vincent van Ravesteijn:
> Hmm.. gmail sent the mail to early:
>
>
>> void GuiToolbar::restoreSession()
>> {
>>QSettings settings;
>>
>>setVisibility(settings.value(sessionKey() + "/visibility").toInt());
>> }
>>
>>
>
> void GuiToolbar::restoreSe
> Now I have the following reduced patch left. Ok to apply?
>
I fixed the second part also (making up for my own mistake in r37068).
See the other thread for my comments about the other part.
Vincent
Hmm.. gmail sent the mail to early:
> void GuiToolbar::restoreSession()
> {
> QSettings settings;
>
> setVisibility(settings.value(sessionKey() + "/visibility").toInt());
> }
>
>
void GuiToolbar::restoreSession()
{
QSettings settings;
int const error_val = -1;
On Mon, Jan 3, 2011 at 12:52 PM, Stephan Witt wrote:
> Am 03.01.2011 um 11:28 schrieb Vincent van Ravesteijn:
>
>>>
>>> But somehow there is a connection between visibility flags and the
>>> toolbar type, isn't it? The allowauto_ flag depends on visibility.
>>> This looks a little bit weird.
>>
>>
Am 03.01.2011 um 12:42 schrieb v...@lyx.org:
> Author: vfr
> Date: Mon Jan 3 12:42:01 2011
> New Revision: 37068
> URL: http://www.lyx.org/trac/changeset/37068
>
> Log:
> Remove GuiToolbar::allowauto_ and define this property in the
> Toolbars.h::Visibility enum.
>
> Now, there is the bug tha
> As a linux user, when I mark something, I expect it to be in the clipboard
> already - because I marked it. (In linux, you don't need to "copy". This
> saves keypresses.) With this model, LyX is correct:
> * select word2, putting it on the clipboard
> * redundant "copy"
> * select word1, putting
Am 03.01.2011 um 11:28 schrieb Vincent van Ravesteijn:
>>
>> But somehow there is a connection between visibility flags and the
>> toolbar type, isn't it? The allowauto_ flag depends on visibility.
>> This looks a little bit weird.
>
>
> Yes, this is just an example of bad programming practice.
On 28. des. 2010 23:22, Pavel Sanda wrote:
Jack Tanner wrote:
1. Create a new document.
2. Type in two words, word1 and word2.
3. Select and copy word2.
4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed inside
a new note.
5. Paste.
Expected: paste outputs word2, as copied in (
>
> But somehow there is a connection between visibility flags and the
> toolbar type, isn't it? The allowauto_ flag depends on visibility.
> This looks a little bit weird.
Yes, this is just an example of bad programming practice.
In the Visibility enum, we are now mixing up flags indicating whe
Am 03.01.2011 um 09:26 schrieb Vincent van Ravesteijn:
>> I encountered the problem yesterday too after recompile and restart without
>> updating the resources.
>> So I tried to understand the cause and I don't understand the code in
>> GuiView::restoreLayout().
>>
>> As I read the code the cal
On 03/01/2011 09:43, Vincent van Ravesteijn wrote:
What I forgot to say is: Why don't we implement saveState() and
restoreState() in GuiToolbar which overrides QToolbar::saveState() and
restoreState(). Then restoring the visibility of the toolbars is done
by QMainWindow::restoreState. (At least,
> I said "simplest solution" :-)
> I didn't say this is the _right_ solution.
>
Ok, I'll try to remember this lesson.
I often fail to see the simplest solution to problems. Now I know why.
Vincent
>> What I forgot to say is: Why don't we implement saveState() and
>> restoreState() in GuiToolbar which overrides QToolbar::saveState() and
>> restoreState(). Then restoring the visibility of the toolbars is done
>> by QMainWindow::restoreState. (At least, that is what I would think).
>
> Yes, tha
On 03/01/2011 09:31, Vincent van Ravesteijn wrote:
First, there are two different types of settings of toolbars: the
location of the toolbars, and the visibility of the toolbars. The
former is managed by Qt in QMainWindow::saveState()/restoreState().
The latter is done by LyX in
GuiToolbar::saveS
On 03/01/2011 09:33, Vincent van Ravesteijn wrote:
I think the simplest solution would be to always call restore the toolbars
following the toolbars.ui settings and disregard the session management.
This would have the side effect that any moved toolbars state will be lost
as the toolbars will be
>
> I think the simplest solution would be to always call restore the toolbars
> following the toolbars.ui settings and disregard the session management.
> This would have the side effect that any moved toolbars state will be lost
> as the toolbars will be restored in their default state.
>
Why wo
> First, there are two different types of settings of toolbars: the
> location of the toolbars, and the visibility of the toolbars. The
> former is managed by Qt in QMainWindow::saveState()/restoreState().
> The latter is done by LyX in
> GuiToolbar::saveSession()/restoreSession(). The reason for t
On 03/01/2011 07:49, Stephan Witt wrote:
See http://www.lyx.org/trac/ticket/7099
I encountered the problem yesterday too after recompile and restart without
updating the resources.
So I tried to understand the cause and I don't understand the code in
GuiView::restoreLayout().
As I read the co
> I encountered the problem yesterday too after recompile and restart without
> updating the resources.
> So I tried to understand the cause and I don't understand the code in
> GuiView::restoreLayout().
>
> As I read the code the call of initToolbars() depends on the success of the
> restoreSta
37 matches
Mail list logo
