quite difficult to use.
I tend to agree.
OK, I have handled the search-type and spell-type dialogs.
Now what do we expect for other document-related dialog. The three
solutions are
1/ disable the dialog (like GuiCharacter)
2/ disable each and every widget when the document is read-only
handled the search-type and spell-type dialogs.
Now what do we expect for other document-related dialog. The three
solutions are
1/ disable the dialog (like GuiCharacter)
2/ disable each and every widget when the document is read-only
(GuiExternal, but the ButtonController::addReadOnly thing
began to do that (old search and new search). I do not know
though what we want for dialogs like External, where everything is
supposed to be disabled for read-only.
I am not sure either of where is the good place to do that, both in old
style GuiDialog and in new-style ones.
JMarc
--
lyx
Am Dienstag, dem 01.12.2020 um 10:46 -0500 schrieb Richard Kimberly
Heck:
> Jürgen knows the most about this, I think, but my sense is that (2)
> is
> the way to go. I find the ButtonController quite difficult to use.
I tend to agree.
Jürgen
signature.asc
Description: This is a digitally signe
widgets in the dialog, see
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg128222.html
>
> The archive above explains that this enabling/disabling clashes with
> explicit disabling like in the Box dialog.
>
> So the very unsatisfying situation is that we have code in dialogs
with
explicit disabling like in the Box dialog.
So the very unsatisfying situation is that we have code in dialogs which
annotates which widgets should be disabled in read-only mode, but these
calls do nothing.
Any bright idea on how to fix this?
I see two approaches:
1/ add a ButtonContr
In general, LyX's dialogs behave differently when they are closed and
opened as opposed to when they are already open and are "opened again".
For example, when the Label Settings dialog is closed and opened, its
entire label text gets selected. In contrast, when the dialog is al
Am Donnerstag, 20. Dezember 2018 13:47:27 CET schrieb Jürgen Spitzmüller
:
> Am Donnerstag, den 20.12.2018, 13:35 +0100 schrieb Kornel Benko:
> > Am Donnerstag, 20. Dezember 2018 13:27:18 CET schrieb Jürgen
> > Spitzmüller :
> > > Am Donnerstag, den 20.12.2018, 13:16 +0100 schrieb Kornel Benko:
>
Am Donnerstag, den 20.12.2018, 13:35 +0100 schrieb Kornel Benko:
> Am Donnerstag, 20. Dezember 2018 13:27:18 CET schrieb Jürgen
> Spitzmüller :
> > Am Donnerstag, den 20.12.2018, 13:16 +0100 schrieb Kornel Benko:
> > > This, or one of the last commits creates a crash.
> > >
> > > 1.) lyx test1.lyx
Am Donnerstag, 20. Dezember 2018 13:27:18 CET schrieb Jürgen Spitzmüller
:
> Am Donnerstag, den 20.12.2018, 13:16 +0100 schrieb Kornel Benko:
> >
> > This, or one of the last commits creates a crash.
> >
> > 1.) lyx test1.lyx # for instance a new file
> > 2.) open char dialog
> > =
Am Donnerstag, den 20.12.2018, 13:16 +0100 schrieb Kornel Benko:
>
> This, or one of the last commits creates a crash.
>
> 1.) lyx test1.lyx # for instance a new file
> 2.) open char dialog
> ==> crash
Not here. Do you have a backtrace?
Jürgen
>
> Kornel
signature.as
Am Donnerstag, 20. Dezember 2018 12:55:12 CET schrieb Juergen Spitzmueller
:
> commit e087722900e32c3718b0655d2716bf6fbbdfddc1
> Author: Juergen Spitzmueller
> Date: Thu Dec 20 12:56:30 2018 +0100
>
> Maintain default status for all dialogs using ButtonController
>
Le 19/03/2018 à 17:29, Richard Kimberly Heck a écrit :
Yes, I'd guess 2.3.2. It's a reasonably big change. Presumably packagers
will have to
decide how to handle it, too.
Good, it is in 2.3.2-staging now.
JMarc
On 03/19/2018 11:57 AM, Jean-Marc Lasgouttes wrote:
> Le 19/03/2018 à 15:51, Jürgen Spitzmüller a écrit :
>> Am Montag, den 19.03.2018, 15:03 +0100 schrieb Jean-Marc Lasgouttes:
>>>> I would not be opposed to a backport.
>>>
>>> As it is with native dia
Le 19/03/2018 à 15:51, Jürgen Spitzmüller a écrit :
Am Montag, den 19.03.2018, 15:03 +0100 schrieb Jean-Marc Lasgouttes:
I would not be opposed to a backport.
As it is with native dialogs for everyone by default?
Yes.
Riki, what do you think about it? Is it 2.3.2 stuff? I guess it will
Am Montag, den 19.03.2018, 15:03 +0100 schrieb Jean-Marc Lasgouttes:
> > I would not be opposed to a backport.
>
> As it is with native dialogs for everyone by default?
Yes.
Jürgen
>
> JMarc
signature.asc
Description: This is a digitally signed message part
Le 19/03/2018 à 14:40, Jürgen Spitzmüller a écrit :
Am Montag, den 19.03.2018, 11:52 +0100 schrieb Jean-Marc Lasgouttes:
It is in now.
Works here.
I am not sure what we want wrt 2.3.x.
I would not be opposed to a backport.
As it is with native dialogs for everyone by default?
JMarc
Am Montag, den 19.03.2018, 11:52 +0100 schrieb Jean-Marc Lasgouttes:
> It is in now.
Works here.
> I am not sure what we want wrt 2.3.x.
I would not be opposed to a backport.
Jürgen
>
> JMarc
signature.asc
Description: This is a digitally signed message part
Le 14/03/2018 à 12:06, Kornel Benko a écrit :
Only if it affects previous lyx-versions IMHO.
Since lyx ignores (with warning) unknown settings, it should not be needed.
It is in now. I am not sure what we want wrt 2.3.x.
JMarc
Am Mittwoch, 14. März 2018 11:36:24 CET schrieb Jean-Marc Lasgouttes
:
> Le 10/03/2018 à 11:17, Kornel Benko a écrit :
> > I'd say, now is the right time to commit the proposed patch. Having
> > different defaults for linux and Mac/Windows can be done in configure.
>
> Let's apply for master firs
Le 10/03/2018 à 11:17, Kornel Benko a écrit :
I'd say, now is the right time to commit the proposed patch. Having different
defaults for linux and Mac/Windows can be done in configure.
Let's apply for master first. A question: if I do not intend to add pref
update code, do I have to update the
Am Donnerstag, 1. Februar 2018 08:22:30 CET schrieb Guenter Milde
:
> On 2018-01-31, Jürgen Spitzmüller wrote:
> > Am Mittwoch, den 31.01.2018, 11:00 +0100 schrieb Jean-Marc Lasgouttes:
> >> Le 31/01/2018 à 08:20, Jürgen Spitzmüller a écrit :
> ...
>
> >> > The nice thing about the buttons is tha
On 2018-01-31, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 31.01.2018, 11:00 +0100 schrieb Jean-Marc Lasgouttes:
>> Le 31/01/2018 à 08:20, Jürgen Spitzmüller a écrit :
...
>> > The nice thing about the buttons is that they only occur when it
>> > makes
>> > sense. And remember we do not only hav
ought about it sometimes is the removal of the
> native file dialogs and the placement in the Help menu of an entry that
> would allow to open the file picker for Examples. Because, at least to
> me, Examples conceptually belong to Help and not to File.
Agreed. See also https://www.lyx.org/tr
ll
> have a generic place for images.
Indeed.
> There is also the case of ui or bind files, but I think using a
> popup
> menu there would be much more useful.
How would that look like?
>
> > > > This would be the best solution IMHO. But do you know how to
>
how to make
setSidebarUrl work with proper entries? (I don't).
Well, first, remember that it means no native dialog.
Why? Doesn't the method work with native dialogs?
No:
https://code.woboq.org/qt5/qtbase/src/widgets/dialogs/qfiledialog.cpp.html#_ZN11QFileDialog14setSidebarUrlsERK5QListI4QUrlE
JMarc
Am Dienstag, den 30.01.2018, 23:24 +0100 schrieb Jean-Marc Lasgouttes:
> Nice, so to speak. To be frank, I have no interest in reworking 20+
> dialogs to give them nice buttons. But this is of course desirable
> in
> the long term.
I agree.
> > > 1/ apply this patch, ma
On 31/01/2018 4:41 a.m., Jean-Marc Lasgouttes wrote:
Le 30/01/2018 à 16:33, José Abílio Matos a écrit :
One option that I thought about it sometimes is the removal of the
native file dialogs and the placement in the Help menu of an entry
that would allow to open the file picker for Examples
Le 30/01/2018 à 19:32, Jürgen Spitzmüller a écrit :
The following patch allows to select the type of file dialog at
runtime
(see ticket http://www.lyx.org/trac/ticket/11003 for why I am doing
that).
Nice.
Nice, so to speak. To be frank, I have no interest in reworking 20+
dialogs to give
Am Dienstag, den 30.01.2018, 15:01 +0100 schrieb Jean-Marc Lasgouttes:
> Currently native file dialogs are used on windows and Mac. It is
> possible to select them on unix with cmake, but not autoconf.
>
> The following patch allows to select the type of file dialog at
> runtime
On Tue, Jan 30, 2018 at 02:01:54PM +, Jean-Marc Lasgouttes wrote:
> Does somebody use the custom Documents/Examples buttons? Are they really
> needed?
I use them, but the cost of forgetting that they are not available on
all platforms always comes back to bite me when I give a presentation on
On Tuesday, 30 January 2018 15.41.28 WET Jean-Marc
Lasgouttes wrote:
> You mean _custom_ file dialogs, right?
>
> JMarc
Sure. My mistake. :-)
--
José Abílio
Le 30/01/2018 à 16:33, José Abílio Matos a écrit :
One option that I thought about it sometimes is the removal of the
native file dialogs and the placement in the Help menu of an entry that
would allow to open the file picker for Examples. Because, at least to
me, Examples conceptually belong
On Tuesday, 30 January 2018 14.53.45 WET Pavel Sanda wrote:
> I use them sometimes, but can't say whether it's because of real usage or
> devel activities... P
Me too. :-)
I think that the question regarding the usefulness of the those dialogs could
get a
better feedback on th
Jean-Marc Lasgouttes wrote:
> Does somebody use the custom Documents/Examples buttons? Are they really
> needed?
I use them sometimes, but can't say whether it's because of real usage or
devel activities... P
Le 30/01/2018 à 15:01, Jean-Marc Lasgouttes a écrit :
Does somebody use the custom Documents/Examples buttons? Are they really needed?
I use these two quite often (more frequently examples), but my use of LyX is
mostly for translations.
--
Jean-Pierre
Currently native file dialogs are used on windows and Mac. It is
possible to select them on unix with cmake, but not autoconf.
The following patch allows to select the type of file dialog at runtime
(see ticket http://www.lyx.org/trac/ticket/11003 for why I am doing that).
Currently all
On Tue, Sep 12, 2017 at 11:05:44AM +0200, Stephan Witt wrote:
> commit 97dc58513884bb89b6a015c2c7dc61c8bb3f7dfe
> Author: Stephan Witt
> Date: Tue Sep 12 11:05:42 2017 +0200
>
> #10662 use drawers for bibliography dialogs
>
> This change solves dialog stack
Le 04/12/2016 à 19:59, Enrico Forestieri a écrit :
On Sun, Dec 04, 2016 at 06:38:42PM +0100, Guillaume Munch wrote:
+// FIXME: This dialog has issues with line breaking and size, in particular
with
+// html. But it could easily be reimplemented as a QMessageBox using
+// QMessageBox::setCheckB
On Sun, Dec 04, 2016 at 06:38:42PM +0100, Guillaume Munch wrote:
> commit 588d939722f4a516e8e4a932086e574bc3b13065
> Author: Guillaume Munch
> Date: Sun Dec 4 18:28:03 2016 +0100
>
> Cosmetic changes to the needauth dialogs
>
> * Use rich text for thi
On 09.10.2016 20:18, Guillaume Munch wrote:
Le 09/10/2016 à 19:51, Guillaume Munch a écrit :
commit cf26d53e037cf59b5816cdb2f5c7d835b83d480a
Author: Daniel Ramöller
Date: Mon Oct 3 20:20:16 2016 +0200
Remove question marks from Windows dialogs
Welcome to the project!
Thanks!
On Sun, Oct 09, 2016 at 08:18:37PM +0200, Guillaume Munch wrote:
> Le 09/10/2016 à 19:51, Guillaume Munch a écrit :
> > commit cf26d53e037cf59b5816cdb2f5c7d835b83d480a
> > Author: Daniel Ramöller
> > Date: Mon Oct 3 20:20:16 2016 +0200
> >
> > Remove qu
Le 09/10/2016 à 19:51, Guillaume Munch a écrit :
commit cf26d53e037cf59b5816cdb2f5c7d835b83d480a
Author: Daniel Ramöller
Date: Mon Oct 3 20:20:16 2016 +0200
Remove question marks from Windows dialogs
Welcome to the project!
Comment (by spitz):
Fixed for {{{GuiBox}}} at [14d3d7de458/lyxgit]. Please test, further
adjustments might be needed. Observe how the code is much cleaner now.
Many thanks.
It works fine AFAICS.
regards Uwe
because I personally show the outline only when I
want to use it and otherwise I hide it.
Is there any design-related documentation someone can point me to on
when to focus on dialogs? My first reaction is that whenever a dialog
is chosen to be shown (whether it is visible or not), the focus should
On Tue, Nov 12, 2013 at 3:46 AM, Jürgen Spitzmüller wrote:
> 2013/11/12 Scott Kostyshak
>
>> I do not see LyX 1.y.x in the "File > Save As" dialog. I can only save
>> as .lyx. I do see it in the SendTo dialog.
>
>
> Yes, this is a bug in the dialog. I have a pending patch somewhere in my
> long pi
2013/11/12 Scott Kostyshak
> I do not see LyX 1.y.x in the "File > Save As" dialog. I can only save
> as .lyx. I do see it in the SendTo dialog.
>
Yes, this is a bug in the dialog. I have a pending patch somewhere in my
long pipe.
Jürgen
SendTo and SaveAs dialogs)
I do not see LyX 1.y.x in the "File > Save As" dialog. I can only save
as .lyx. I do see it in the SendTo dialog.
Note that I'm in favor of your patch, I just wonder if there is a
reason why it shows for you in "Save As" and not for me.
Scott
>So when a file is readonly, the desired behavior should be:
>
>1. values are populated to the dialogs,
I fixed this in r32694 in general.
>(bug with insetInfo)
I fixed this in r32695.
> (and insetLabel etc)
I fixed this in r32696.
>2. values should be grayed out and canno
>>>
>>You are right, I think, that the values should still be there.
>>
> No, they are not, you're right.
So when a file is readonly, the desired behavior should be:
1. values are populated to the dialogs, (bug with insetInfo and insetLabel etc)
2. values shoul
>>> Is the file marked read-only?
>>>
>> Yes, but the values should still be populated to the dialogs, right?
>> At least the figure dialog displays filenames in this case. Or is
this
>> a bug for the figure dialog?
>>
>>
>You are ri
>>> Is the file marked read-only?
>>>
>> Yes, but the values should still be populated to the dialogs, right?
>> At least the figure dialog displays filenames in this case. Or is
this
>> a bug for the figure dialog?
>>
>>
>You are ri
On 12/31/2009 12:15 AM, Bo Peng wrote:
Is the file marked read-only?
Yes, but the values should still be populated to the dialogs, right?
At least the figure dialog displays filenames in this case. Or is this
a bug for the figure dialog?
You are right, I think, that the values
> Is the file marked read-only?
Yes, but the values should still be populated to the dialogs, right?
At least the figure dialog displays filenames in this case. Or is this
a bug for the figure dialog?
Bo
Dear all,
In the spirit of a new year, I checked out the lyx trunk and would
like to see what has been done to lyx in order to fix perhaps a number
of standing insetInfo bugs. I was pleasantly surprised that scons is
still working and compiled the trunk without problem under a Ubuntu
9.10 system.
Jürgen Spitzmüller writes:
> Steve Litt wrote:
>> Can one choose not to include KDE integration?
>
> This is not KDE integration. It's just Qt using KDE's native dialog instead
> of
> LyX's home-brewn, which has always been a bad compromise.
And I guess this can be disabled at KDE level. No ne
Steve Litt wrote:
> Can one choose not to include KDE integration?
This is not KDE integration. It's just Qt using KDE's native dialog instead of
LyX's home-brewn, which has always been a bad compromise.
Jürgen
On Wednesday 17 June 2009 10:51:27 am Jürgen Spitzmüller wrote:
> Jean-Marc Lasgouttes wrote:
> > Actually, I would have proposed that generally
>
> +1
>
> > if only we were able
> > to use QFileDialog::setSidebarUrls. The problem with that method is that
> > the URLs cannot be given names, so that
Jürgen Spitzmüller wrote:
> > just questioning...
>
> I do not understand the question. Why should we lose them? Instead of the
> custom buttons, they will be accessible via the sidebar of the file dialog.
then its perfect. (i didn't checked how it looks like).
pavel
Pavel Sanda wrote:
> > > won't we loose templates and examples directory?
> >
> > why this?
>
> just questioning...
I do not understand the question. Why should we lose them? Instead of the
custom buttons, they will be accessible via the sidebar of the file dialog.
Jürgen
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > Jürgen Spitzmüller wrote:
> > > this now with our custom buttons, do we? IOW, we do not lose anything
> > > (wrt the status quo) if we ditch the custom dialog, right?
> >
> > won't we loose templates and examples directory?
>
> why this?
just que
Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > this now with our custom buttons, do we? IOW, we do not lose anything
> > (wrt the status quo) if we ditch the custom dialog, right?
>
> won't we loose templates and examples directory?
why this?
Jürgen
Jürgen Spitzmüller wrote:
> this now with our custom buttons, do we? IOW, we do not lose anything (wrt
> the
> status quo) if we ditch the custom dialog, right?
won't we loose templates and examples directory?
pavel
Jean-Marc Lasgouttes wrote:
> Actually, I would have proposed that generally
+1
> if only we were able
> to use QFileDialog::setSidebarUrls. The problem with that method is that
> the URLs cannot be given names, so that if we add $lyxrid/clipart in
> the sidebar, it will appear as "clipart". And
Abdelrazak Younes wrote:
>> We could have in the user
>> directory (because the sysem directory is not browsable in OS X)
>> links/
>> Clipart/ -> sysdir/clipart
>> User Clipart/ -> userdir/clipart
>> Templates/ -> sysdir/templates
>> ...
>>
>> And use some of these as needed to replace our o
Jean-Marc Lasgouttes wrote:
Le 15/06/2009 10:37, Abdelrazak Younes a écrit :
Actually, I would have proposed that generally if only we were able
to use QFileDialog::setSidebarUrls. The problem with that method is
that
the URLs cannot be given names, so that if we add $lyxrid/clipart in
the sid
Le 15/06/2009 10:37, Abdelrazak Younes a écrit :
Actually, I would have proposed that generally if only we were able
to use QFileDialog::setSidebarUrls. The problem with that method is that
the URLs cannot be given names, so that if we add $lyxrid/clipart in
the sidebar, it will appear as "clipar
Jean-Marc Lasgouttes wrote:
Le 13/06/2009 01:34, Richard Heck a écrit :
David Palacio wrote:
Hi,
On KDE 4.3, when using a KDE widget style, Qt applications get KDE
file dialogs for free. That is not the case for Lyx. I guess it is
because Lyx customizes the file dialog. It would be great for
Le 13/06/2009 01:34, Richard Heck a écrit :
David Palacio wrote:
Hi,
On KDE 4.3, when using a KDE widget style, Qt applications get KDE
file dialogs for free. That is not the case for Lyx. I guess it is
because Lyx customizes the file dialog. It would be great for Lyx to
get the integration Qt
David Palacio wrote:
Hi,
On KDE 4.3, when using a KDE widget style, Qt applications get KDE file dialogs
for free. That is not the case for Lyx. I guess it is because Lyx customizes
the file dialog. It would be great for Lyx to get the integration Qt
applications have in KDE 4.
If this
Hi,
On KDE 4.3, when using a KDE widget style, Qt applications get KDE file dialogs
for free. That is not the case for Lyx. I guess it is because Lyx customizes
the file dialog. It would be great for Lyx to get the integration Qt
applications have in KDE 4.
Vincent van Ravesteijn wrote:
Hi all,
In preparation for the GuiTabular dialog I added a buttoncontroller
policy for Dialogs with an autoapply checkbox.
As as example I added a patch for the GuiCharacter dialog.
(PS if you want me to shut up and apply the patches immediately, just
give a
Hi all,
In preparation for the GuiTabular dialog I added a buttoncontroller
policy for Dialogs with an autoapply checkbox.
As as example I added a patch for the GuiCharacter dialog.
(PS if you want me to shut up and apply the patches immediately, just
give a hint)
Vincent
Index: src
Vincent van Ravesteijn - TNW wrote:
What's the smiley for blushing?
rh
It's this one :$
(I hope)
Well, http://messenger.yahoo.com/features/emoticons/ claims it's: :">,
but that makes no sense to me. :-$ is alleged to be "Don't tell anyone".
rh
> What's the smiley for blushing?
>
> rh
It's this one :$
(I hope)
Vincent
José Matos wrote:
On Friday 08 August 2008 17:32:58 Abdelrazak Younes wrote:
You're in good hands with Richard :-)
Indeed. :-)
What's the smiley for blushing?
rh
On Friday 08 August 2008 17:32:58 Abdelrazak Younes wrote:
> You're in good hands with Richard :-)
Indeed. :-)
> Abdel
--
José Abílio
Vincent van Ravesteijn - TNW wrote:
Abdelrazak Younes wrote:
I will be off-line for 3 weeks so could somebody please take care of
this patch and upcoming Vincent's contributions?
Since you did the same for me when I started, Abdel, I'll be happy to
take that role here.
Have
>> Abdelrazak Younes wrote:
>>
>> I will be off-line for 3 weeks so could somebody please take care of
>> this patch and upcoming Vincent's contributions?
>
> Since you did the same for me when I started, Abdel, I'll be happy to
take that role here.
>
> Have a good break!
>
> rh
Thank you very m
? If so, I included a small
patch that will fix this for the two dialogs mentioned. I just
adapted them to the design of the GuiGraphics Dialog.
Your patch looks good Vincent :-)
I will be off-line for 3 weeks so could somebody please take care of
this patch and upcoming Vincent&#
bject: [Going off-line] (was Re: [PATCH] Dialogs lose information when
cursor moves
Vincent van Ravesteijn - TNW wrote:
> Hi,
> I noticed that for instance the Hyperlink Dialog loses all information
> when clicking on the main buffer. The same occurs with the Include
> Child Do
small
patch that will fix this for the two dialogs mentioned. I just adapted
them to the design of the GuiGraphics Dialog.
Your patch looks good Vincent :-)
I will be off-line for 3 weeks so could somebody please take care of
this patch and upcoming Vincent's contributions? I am sure there wi
the two dialogs mentioned. I just adapted them to the
design of the GuiGraphics Dialog.
Vincent
Index: src/frontends/qt4/GuiHyperlink.cpp
===
--- src/frontends/qt4/GuiHyperlink.cpp (revision 26082)
+++ src/frontends/qt4
hi,
1. do ctrl+f in your document. find window pops-up and focus goes to it.
2. change focus back to edit window and press ctrl+f again. window correctly
pops up, even keyboard input is in edit box, but focus is not on the dialog.
as a consequence strange things happen from time to time (th
On Tue, Nov 27, 2007 at 12:04:03AM +0100, Andre Poenitz wrote:
> On Sun, Nov 25, 2007 at 11:13:48PM +0100, Jean-Marc Lasgouttes wrote:
> > Andre Poenitz a écrit :
> >> Is there a specific reason we do not keep our dialogs to stay above the
> >> application?
>
On Sun, Nov 25, 2007 at 11:13:48PM +0100, Jean-Marc Lasgouttes wrote:
> Andre Poenitz a écrit :
>> Is there a specific reason we do not keep our dialogs to stay above the
>> application?
>> The current state is pretty annoying with focus-on-mouse-hover +
>> autoraise...
Andre Poenitz a écrit :
Is there a specific reason we do not keep our dialogs to stay above the
application?
The current state is pretty annoying with focus-on-mouse-hover +
autoraise...
Are you sure we do that? I think we just say they are our children, and
the wm is responsible for doing
Is there a specific reason we do not keep our dialogs to stay above the
application?
The current state is pretty annoying with focus-on-mouse-hover +
autoraise...
Andre'
Uwe Stöhr schrieb:
There is a serious problem for all current dialogs:
You can set dialog elements to disables state, but whenever you press
the apply button, this is overwritten and all elements are set bach to
enabled state.
I found the reason for this now. It's in ButtonController:
There is a serious problem for all current dialogs:
You can set dialog elements to disables state, but whenever you press the apply button, this is
overwritten and all elements are set bach to enabled state.
This one prevents to make the optional parameters really optional using
checkboxes. To
On Tue, Sep 11, 2007 at 08:37:12AM +0200, Abdelrazak Younes wrote:
> [EMAIL PROTECTED] wrote:
> >Author: poenitz
> >Date: Tue Sep 11 00:32:59 2007
> >New Revision: 20202
> >
> >URL: http://www.lyx.org/trac/changeset/20202
> >Log:
> >shuffle some frontend stuff around. merge controller(base) and "Ke
[EMAIL PROTECTED] wrote:
Author: poenitz
Date: Tue Sep 11 00:32:59 2007
New Revision: 20202
URL: http://www.lyx.org/trac/changeset/20202
Log:
shuffle some frontend stuff around. merge controller(base) and "Kernel". Make
frontend::Dialog pure virtual
Good move. I think you should also move Dia
> There have been several update() methods in the different layers
> of the GUII machinery. I had to rename some when merging classes,
> and even if these changes were rather mechanical it's rather likely
> that something went wrong somewhere.
So is there any planned big changes?
Bo
On Sat, Sep 08, 2007 at 06:05:28PM +0200, Abdelrazak Younes wrote:
> It seems that Dialog::update() and by consequence Dialog::updateView()
> are never called...
>
> Is it something known or shall I investigate?
Would be nice if you did.
There have been several update() methods in the different
Abdelrazak Younes wrote:
It seems that Dialog::update() and by consequence Dialog::updateView()
are never called...
Is it something known or shall I investigate?
It's been reported that OK buttons are not functioning. That presumably
has to do with Andre's cleanup. I've also noticed that Inser
It seems that Dialog::update() and by consequence Dialog::updateView()
are never called...
Is it something known or shall I investigate?
Abdel.
On Thu, Sep 06, 2007 at 05:30:32PM +, Angus Leeming wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> > > Anyway, you're doing the work and you have to convince the other active
> > > developers that what you envision is something they want too. The views
> > > of
> > > retired devs matte
Andre Poenitz <[EMAIL PROTECTED]> writes:
> > Anyway, you're doing the work and you have to convince the other active
> > developers that what you envision is something they want too. The views of
> > retired devs matter only in that they can illuminate the discussion
> > and help some opinion-fo
gt; The orgy is the Mailer interface to
> serialize chunks of the kernel data structure to/from strings.
Uh... I did not think of that.
> And anyway, user interaction with the dialogs is *not* a perf bottleneck so
> your "kernel strings" to/from "qt strings" argument
trings" as soon as it accesses the
> controller or gets string data out of it.
Ah, OK. But that's not an orgy ;-) The orgy is the Mailer interface to
serialize chunks of the kernel data structure to/from strings.
And anyway, user interaction with the dialogs is *not* a perf bottle
1 - 100 of 530 matches
Mail list logo
