I return from a week away to find 900 new LyX messages. Ouch :-(
Rob Lahaye wrote:
> Vaguely I remember that Angus once mentioned something like this.
> It was too specialized C++ coding for me to comprehend, so I may
> have misunderstood. But Angus may know much more about this issue
> and whethe
Andre Poenitz wrote:
> The new xforms preamble dialog is _far_ to small. It basically always
> requires resizing first.
>
> No good. Please revert.
OK. But I would like to revert this along with the patch that allows
resizing also to smaller size than original default (now you can only
resize to
On Tue, Mar 18, 2003 at 06:47:50AM +0900, Rob Lahaye wrote:
> Concerning Andre's comment. Are you complaining about you having
> long lines (width), or having many lines (height)?
The number of lines is more or less ok. I would not mind having a few more,
though. But the lines are definitely to sh
John Levon wrote:
> On Tue, Mar 18, 2003 at 09:36:38AM +0900, Rob Lahaye wrote:
>
> I have more than reasonable xforms font settings.
>
>
>>>what ? since when ? That sucks
>>
>>As far as I know, it has always been that way.
>>Ever tried to downsize the default size of an Xforms dialog?
>>You ca
On Tue, Mar 18, 2003 at 09:36:38AM +0900, Rob Lahaye wrote:
> Line length also depends on fonts settings
I have more than reasonable xforms font settings.
> > what ? since when ? That sucks
>
> As far as I know, it has always been that way.
> Ever tried to downsize the default size of an Xf
son for it? Would Xforms crash?
Insisting on (unnecessarily) large dialogs, _should_ also require
a general Xforms code change to allow downsizing Xforms dialogs to
smaller size than original default.
I myself have no idea where this Xforms "do-not-allow-smaller-than-
initial-size" code is located. Any idea? Angus?
Rob.
On Tue, Mar 18, 2003 at 06:47:50AM +0900, Rob Lahaye wrote:
> Concerning Andre's comment. Are you complaining about you having
> long lines (width), or having many lines (height)?
> I think this is so arbitrary. For me the dialog is still far too
> large, since I have at most 3 short lines in the
John Levon wrote:
> On Mon, Mar 17, 2003 at 05:39:10PM +0100, Andre Poenitz wrote:
>
>>The new xforms preamble dialog is _far_ to small. It basically always
>>requires resizing first.
>
> It's too thin but I think it's tall enough
This relates to my changes to the Xforms dialog layouts.
John,
On Mon, Mar 17, 2003 at 05:39:10PM +0100, Andre Poenitz wrote:
> The new xforms preamble dialog is _far_ to small. It basically always
> requires resizing first.
It's too thin but I think it's tall enough
regards
john
The new xforms preamble dialog is _far_ to small. It basically always
requires resizing first.
No good. Please revert.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Rob Lahaye wrote:
> I once started prettifying the Xforms dialogs' layout, but I haven't
> finished it, because of the freeze & release of 1.3.0. Shall I continue
> where I left it?
Sure. But please be aware that 'prettifying' and 'making tiny' aren
On Wed, Feb 26, 2003 at 08:47:18PM +0900, Rob Lahaye wrote:
> I once started prettifying the Xforms dialogs' layout, but I haven't
> finished it, because of the freeze & release of 1.3.0. Shall I continue
> where I left it?
Why not? Better now than in 1.4 freeze ;-)
Andre
Hi,
I once started prettifying the Xforms dialogs' layout, but I haven't finished it,
because of the freeze & release of 1.3.0. Shall I continue where I left it?
Regards,
Rob.
Angus Leeming wrote:
Here are the remaining four dialogs from Rob's monster patch.
Printer, Spellchecker, Texinfo and Wrap.
Angus,
You patched a small bug in FormSpellchecker.C (the case of "progress == 0").
Please consider the patch below, to do this job instead.
Thanks,
Rob.
RCS file: /cvs/
Angus Leeming wrote:
Well if you're going to be pedantic, most of the dialogs derive from
controllers/ViewBase.h
aleem@thorax:xforms$ grep virtual ../controllers/ViewBase.h
virtual ~ViewBase() {}
virtual void apply() = 0;
virtual void build() = 0;
virtual void hide
On Friday 25 October 2002 1:01 pm, Rob Lahaye wrote:
> Angus Leeming wrote:
> > On Friday 25 October 2002 12:41 pm, Rob Lahaye wrote:
> >
> > Not here it doesn't and my version is identical to that in
> > cvs. mv FormWrap.C FormWrap.C_safe
> > cvs update FormWrap.C
>
> Ah, sorry, forgot to do a
Angus Leeming wrote:
On Friday 25 October 2002 12:41 pm, Rob Lahaye wrote:
Not here it doesn't and my version is identical to that in cvs.
mv FormWrap.C FormWrap.C_safe
cvs update FormWrap.C
Ah, sorry, forgot to do a cvs update for that.
2) External.h has the line:
ButtonPolicy::SMInput
On Friday 25 October 2002 12:41 pm, Rob Lahaye wrote:
> Angus Leeming wrote:
> > Here are the remaining four dialogs from Rob's monster
> > patch. Printer, Spellchecker, Texinfo and Wrap.
> >
> > All the diff's look fine to me, they all compile and I've
> > tried them out in minimal fashion. Ok to
On Fri, Oct 25, 2002 at 08:41:35PM +0900, Rob Lahaye wrote:
> ButtonPolicy::SMInput input(FL_OBJECT *, long);
>
>There's no "virtual" here. Is that on purpose or is it missing
>by mistake?
A function only need to be declared 'virtual' in the base class of a
hierarchy. In the derived
Angus Leeming wrote:
Here are the remaining four dialogs from Rob's monster patch.
Printer, Spellchecker, Texinfo and Wrap.
All the diff's look fine to me, they all compile and I've tried them
out in minimal fashion. Ok to apply?
Two questions/remarks:
1) FormWrap.h has NO longer the line:
v
On Friday 25 October 2002 3:45 am, Rob Lahaye wrote:
> Angus Leeming wrote:
> > Here are the remaining four dialogs from Rob's monster
> > patch. Printer, Spellchecker, Texinfo and Wrap.
> >
> > All the diff's look fine to me, they all compile and I've
> > tried them out in minimal fashion. Ok to a
Angus Leeming <[EMAIL PROTECTED]> writes:
| Here are the remaining four dialogs from Rob's monster patch.
| Printer, Spellchecker, Texinfo and Wrap.
|
| All the diff's look fine to me, they all compile and I've tried them
| out in minimal fashion. Ok to apply?
yes.
--
Lgb
Angus Leeming wrote:
Here are the remaining four dialogs from Rob's monster patch.
Printer, Spellchecker, Texinfo and Wrap.
All the diff's look fine to me, they all compile and I've tried them
out in minimal fashion. Ok to apply?
Angus
One small thing only:
Index: src/frontends/xforms/FormSpe
On Friday 27 September 2002 11:59 am, R. Lahaye wrote:
> Angus Leeming wrote:
> > On Friday 27 September 2002 4:13 am, R. Lahaye wrote:
> >>Jürgen and others,
> >>
> >>Some time ago I posted my desire to remove the text_warning
> >>areas in the Xform
R. Lahaye wrote:
> OK - got it. I'll stop arguing.
I would put in a smile on another day.
> But, may I then suggest to change the font size of the message from
> "FL_SMALL_SIZE" to "FL_NORMAL_SIZE"?
Yes, shure.
> The font is difficult to read, because it's in red.
No idea who changed that. I
Juergen Spitzmueller wrote:
> R. Lahaye wrote:
>
>>The space is always occupied by the (mostly void) text widget; and
>>all it says (to the power user!) that the input is invalid.
>
>
> No, it's a hint to the unexperienced user. We have disabled the input filter
> for the power users, which mi
R. Lahaye wrote:
> The space is always occupied by the (mostly void) text widget; and
> all it says (to the power user!) that the input is invalid.
No, it's a hint to the unexperienced user. We have disabled the input filter
for the power users, which might irritate the unexperienced user (see b
Angus Leeming wrote:
> On Friday 27 September 2002 4:13 am, R. Lahaye wrote:
>
>>Jürgen and others,
>>
>>Some time ago I posted my desire to remove the text_warning
>>areas in the Xforms
>>
>>dialogs. You (Jürgen) replied then that:
>>
>>&
On Friday 27 September 2002 4:13 am, R. Lahaye wrote:
> Jürgen and others,
>
> Some time ago I posted my desire to remove the text_warning
> areas in the Xforms
>
> dialogs. You (Jürgen) replied then that:
> > I have spent a lot of time in implementing this "powe
R. Lahaye wrote:
> As a test example, I have attached how this may look like in the graphics
> dialog (the text_warning is still there in the example, but that should
> then go!)
IMHO the warning message is a bit clearer for new users, but I don't mind as
long as there is some kind of visual fee
Jürgen and others,
Some time ago I posted my desire to remove the text_warning areas in the Xforms
dialogs. You (Jürgen) replied then that:
> I have spent a lot of time in implementing this "power user" stuff (ability to
> enter length directly without the choices). Please th
On Thursday 12 September 2002 10:15 am, R. Lahaye wrote:
> Angus Leeming wrote:
> > On Thursday 12 September 2002 8:33 am, R. Lahaye wrote:
> >>This makes the dialogs only less bulky. Hardly any code
> >>cleaning done. (the filedialog code needs a clean up, but
> >>that's for after the freeze).
>
Angus Leeming wrote:
> On Thursday 12 September 2002 8:33 am, R. Lahaye wrote:
>
>>This makes the dialogs only less bulky. Hardly any code
>>cleaning done. (the filedialog code needs a clean up, but
>>that's for after the freeze).
>
> Well personally I think that the new TeXInfo patch is just ug
On Thursday 12 September 2002 8:33 am, R. Lahaye wrote:
> Hi,
>
> This makes the dialogs only less bulky. Hardly any code
> cleaning done. (the filedialog code needs a clean up, but
> that's for after the freeze).
>
> Please apply, if OK.
>
> src/frontends/xforms/ChangeLog|6
Hi,
This makes the dialogs only less bulky. Hardly any code cleaning done.
(the filedialog code needs a clean up, but that's for after the freeze).
Please apply, if OK.
src/frontends/xforms/ChangeLog|6
src/frontends/xforms/FormTexinfo.C| 45 ++---
src/fron
On Fri, Sep 06, 2002 at 05:36:58PM +0900, R. Lahaye wrote:
> > Not good; you should switch tooltip depending up on what it will
> >actually do
>
> Reusing "tooltips().init()" for a second time on a widget is not working.
> Problably a buggy implementation of tooltips. The present patch has t
John Levon wrote:
> On Fri, Sep 06, 2002 at 11:59:04AM +0900, R. Lahaye wrote:
>
>>Attached.
>>Rob.
>
> I'm not applying this in its current state :
>
> 1. Tooltips do not have full stops
> 2. "str = _("Go to selected reference or go back");
>
> Not good; you should switch tooltip depend
On Fri, Sep 06, 2002 at 11:59:04AM +0900, R. Lahaye wrote:
> Attached.
> Rob.
I'm not applying this in its current state :
1. Tooltips do not have full stops
2. "str = _("Go to selected reference or go back");
Not good; you should switch tooltip depending up on what it will
actually do
John Levon wrote:
> On Fri, Sep 06, 2002 at 11:35:03AM +0900, R. Lahaye wrote:
>
>
>>Please have a look at the patch attached to the beginning of this thread
>
>
> Send it my way again please with changelog
Attached.
Rob.
ChangeLog | 16 +++
FormBibitem.C
On Fri, Sep 06, 2002 at 11:35:03AM +0900, R. Lahaye wrote:
> Please have a look at the patch attached to the beginning of this thread
Send it my way again please with changelog
regards
john
--
"Take the ideas you find useful. Try not to get hung up on the labels."
- Jonathan S. Shapir
ialog will never save the gravity/resize properly, because of a bug
(forgotten "%s" in a couple of string print-statements, silly bug!).
However, just viewing the .fd files without saving/modifying anything won't do any
harm.
By now I have a whole bunch of better, nicer, smaller and c
On Mon, Sep 02, 2002 at 07:52:03PM +0900, R. Lahaye wrote:
> I saw that there's a small bug in the Apply/Cancel button of the
> citation dialog. Please ignore; but let me know if the redesign
> of these xforms dialog is appreciated.
Yes it (probably) is. I still have a broken fdesign so can't lo
R. Lahaye wrote:
>
> Hi,
>
> I have improved and reshaped three Xforms dialogs:
>
>form_citation.fd
>form_ref.fd
>form_spellchecker.fd
>
> I made these few dialogs less bulky with a better layout.
> Patch attached.
I saw that there's a small
Hi,
I have improved and reshaped three Xforms dialogs:
form_citation.fd
form_ref.fd
form_spellchecker.fd
I made these few dialogs less bulky with a better layout.
Patch attached.
I used some of John's improvements in Qt, added tooltips, and set the proper
gravity/resize p
> "Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
Rob> Furthermore, the facelift of the dialogs will focus on reducing
Rob> the height of widgets (NOT width, so that translations with
Rob> longer keywords still fit in) and rearranging few widgets inside
Rob> the dialog to allow the proper res
Hi,
I would like to continue with making the xforms dialogs much less bulky and
add the proper resize/gravity attributes, so that resizing the dialogs finally
makes sense. The latter is possible due to Jean-Marc's patch to the fdesign
source code.
(Without this patch, fdesign destroye
s, this sounds encouraging.
Together with Angus supportive email to go for improving Xforms layout,
with the wonderful Qt design of John in mind, I may try to give a few
Xforms dialogs a go, to make them as nice as John's Qt.
Or come with a newer layout that improves Xforms as well as Qt :).
Thanks,
Rob.
On Mon, 12 Aug 2002, Rob Lahaye wrote:
> John Levon wrote:
[...]
> > Rob wrote:
> >>The frontend's look&feel may be different, but items should be in exactly
> >>the same dialog,
> >
> > Like I said, it's up to the xforms people to play catch up.
>
> Well, do the xforms people agree? Is Qt indeed
On Mon, Aug 12, 2002 at 11:55:36AM +0900, Rob Lahaye wrote:
> >I don't see these as problems.
>
> In my opinion this breaks the idea of GUII.
Au contraire, this has been the intention of LyX's GUII work for a very
long time. We are *not* going to go down the XUL path ;)
> I'll report whenever
> "Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
>> Like I said, it's up to the xforms people to play catch up.
Rob> Well, do the xforms people agree? Is Qt indeed the UI default
Rob> going-to-be and all other frontends should follow the Qt layout.
Rob> Or is the underlying plan to abandon
John Levon wrote:
> On Sun, Aug 11, 2002 at 06:01:37PM +0900, Rob Lahaye wrote:
>
>> *) 4 tabs instead of 5
>> *) items are rearranged to different locations.
>
>
> I don't see these as problems.
In my opinion this breaks the idea of GUII.
>> *) etc. etc.
>
> please elaborate ;)
Okay.
On Sun, Aug 11, 2002 at 06:01:37PM +0900, Rob Lahaye wrote:
> First of all: am I right that Qt is still in the state of "under
> construction",
This is right.
> implying we should not scrutinize the details too much?
This is wrong. Please report ANY problems you have. I/Edwin may know about
t
John Levon wrote:
> On Sat, Aug 10, 2002 at 09:22:06AM +0900, Rob Lahaye wrote:
>
>>This UI layout definitely needs to be equalized eventually!
>
>
> This is up to the xforms people to do. Qt makes several things a LOT
> easier to do. If you spot usability problems with the Qt dialogs,
> please
On Sat, Aug 10, 2002 at 09:22:06AM +0900 or thereabouts, Rob Lahaye wrote:
>
> Hi,
>
> I'm quite suprised how much the Qt dialogs differ from the Xform
> ones. I don't mean the way they look, but their contents. Some Qt
> dialogs have a totally different layout and arrangement of items.
>
> Thi
On Sat, Aug 10, 2002 at 09:22:06AM +0900, Rob Lahaye wrote:
> This should be avoided. Explaining how to use LyX will be unnecessarily
> complicated:
> if you use Xforms, do blablabla, however, in Qt you should do.
>
> This UI layout definitely needs to be equalized eventually!
This is up t
Hi,
I'm quite suprised how much the Qt dialogs differ from the Xform ones. I don't mean
the way they look, but their contents. Some Qt dialogs have a totally different
layout and arrangement of items.
This should be avoided. Explaining how to use LyX will be unnecessarily complicated:
if you use
Hi,
I'm quite suprised how much the Qt dialogs differ from the Xform ones. I don't mean
the way they look, but their contents. Some Qt dialogs have a totally different
layout and arrangement of items.
This should be avoided. Explaining how to use LyX will be unnecessarily complicated:
if you us
> Angus> Aiee! Ok, I'm an idiot. Please apply, or you won't be able
> Angus> to launch any new dialogs! A.
> I do not see what the problem was, but I'll apply that anyway (you
> know better than I do).
On today's evidence, I doubt that!
My panic was caused by an old, temporary lyx executabl
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Aiee! Ok, I'm an idiot. Please apply, or you won't be able
Angus> to launch any new dialogs! A.
I do not see what the problem was, but I'll apply that anyway (you
know better than I do).
JMarc
Aiee! Ok, I'm an idiot. Please apply, or you won't be able to launch any
new dialogs!
A.
Index: src/frontends/xforms/FormInset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormInset.C,v
retrieving revi
On Tue, 24 Oct 2000, R. Lahaye wrote:
> Are both still 'hidden' for the regular cvs-testers ?
> I believed the new GraphicsInsets were.
It's not really hidden. Just not easy to get at. Type "graphics-insert" in
the minibuffer.
Angus
Angus Leeming wrote:
> Baruch has been testing FormGraphics for/with me; all appears well.
> I've subjected FormTabular to lots of testing myself. All appears to work
> well. However, Jürgen, this is a complex beast and really it's your baby so
Are both still 'hidden' for the regular cvs-testers
On Tue, 24 Oct 2000, Jean-Marc Lasgouttes wrote:
> Did you try to do some clever trick in the Changelog diff? It did not
> work and the patch is malformed. You can check this with the --dry-run
> option of patch I guess.
Tried no tricks; just cut and pasted "cvs diff ChangeLog" into the main
pat
>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Anyway, here is a patch that does no more than make
Angus> FormGraphics and FormTabular daughter classes of FormInset. All
Angus> xforms dialogs now conform to this derived class structure.
sigh... why are my patches so large at the moment. I'm a firm believer in
small is beautiful :-(
Anyway, here is a patch that does no more than make FormGraphics and
FormTabular daughter classes of FormInset. All xforms dialogs now conform to
this derived class structure.
In the pr
On Tue, 10 Oct 2000, Angus Leeming wrote:
> Morning, Allan.
Beat you. I decided to stop by Uni to do a bit more LyX work after an
evening Alpha course so it's still night time here (yesterday's
night time if you think about it).
> > I'd still prefer to see you override connect() in appropriat
On 10-Oct-2000 Angus Leeming wrote:
>
> Attached is a patch that compiles cleanly!
I commited this patch without compiling it!
I don't have time as I have to go now, please forgive if it breaks
something but I'm in a hurry!
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
On 10-Oct-2000 Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> I think that I "lost" some changes (Buffer * -> Buffer const *)
> Angus> that I made to lyx_cb.[Ch]. so this patch will not apply
> Angus> cleanly. I'm in the process of re-building
On Tue, 10 Oct 2000, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> I think that I "lost" some changes (Buffer * -> Buffer const *)
> Angus> that I made to lyx_cb.[Ch]. so this patch will not apply
> Angus> cleanly. I'm in the process of re-buil
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I think that I "lost" some changes (Buffer * -> Buffer const *)
Angus> that I made to lyx_cb.[Ch]. so this patch will not apply
Angus> cleanly. I'm in the process of re-building against current CVS
Angus> and will then re-post the
On Tue, 10 Oct 2000, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> patch_insets == In patch_insets, I modified the
> Angus> Inset::Clone method, so that it is passed a Buffer const &
> Angus> parameter. I also modified all Inset c-tors
On 10-Oct-2000 Jean-Marc Lasgouttes wrote:
> I am willing to apply this patch, but I'd rather have the opinion of
> Lars and Juergen first.
Please let me apply this one! I just wait for Lars aproval, I'm of your
opinion and would like to have this in!
Jürgen
--
-._-._-._-._-._-._-._-._-
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> patch_insets == In patch_insets, I modified the
Angus> Inset::Clone method, so that it is passed a Buffer const &
Angus> parameter. I also modified all Inset c-tors that are passed a
Angus> Buffer *. They are now passed a B
Morning, Allan.
> I'd still prefer to see you override connect() in appropriate classes
> rather than turn FormBase into a swiss-army knife. Perhaps we need a
> FormInsetBase since it's basically insets that will get caught out on a
> buffer change -- that is, put updateOrHide() in FormInsetBase
On Mon, 9 Oct 2000, Angus Leeming wrote:
> Attached are two patches. Both are physically large but very simple.
>
> patch_insets
> ==
Haven't looked at this one.
> patch_xforms
> ==
> the updateBufferDependent signal is now connected to
> FormBase::updateOrHide(). If the daugh
Attached are two patches. Both are physically large but very simple.
patch_insets
==
In patch_insets, I modified the Inset::Clone method, so that it is passed a
Buffer const & parameter. I also modified all Inset c-tors that are passed a
Buffer *. They are now passed a Buffer const & al
On Thu, 05 Oct 2000, Angus Leeming wrote:
> > The patch attached to this mail resolves this problem for buffer-dependent
> dialogs. The dialogs of most insets should hide when the visible document
> is changed, but some, such as the Table of Contents dialog should be
> updated instead.
>
> Angus
On Thu, 05 Oct 2000, Jean-Marc Lasgouttes wrote:
> Angus> The patch attached to this mail resolves this problem for
> Angus> buffer-dependent dialogs. The dialogs of most insets should
> Angus> hide when the visible document is changed, but some, such as
> Angus> the Table of Contents dialog shoul
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> The patch attached to this mail resolves this problem for
Angus> buffer-dependent dialogs. The dialogs of most insets should
Angus> hide when the visible document is changed, but some, such as
Angus> the Table of Contents dialog sh
The patch attached to this mail resolves this problem for buffer-dependent
dialogs. The dialogs of most insets should hide when the visible document is
changed, but some, such as the Table of Contents dialog should be updated
instead.
Angus
patch05Oct2000.bz2
80 matches
Mail list logo
