On Sat, Apr 08, 2006 at 07:04:06PM +0200, Abdelrazak Younes wrote:
> Let me explain what I have in mind:
> My idea is that lyx::Action would be the action backend of LyX, that is,
> the unification of the toolbar and menubar backend.
> lyx::frontend::Action would be the frontend specialisation of
Andre Poenitz a écrit :
On Fri, Apr 07, 2006 at 05:26:58PM +0200, Abdelrazak Younes wrote:
Andre Poenitz a écrit :
On Thu, Apr 06, 2006 at 01:52:35PM +0200, Abdelrazak Younes wrote:
Leuven, E. a écrit :
I think we can shortcut that by
using QLAction and avoid the call to
"form_->controller()
Georg Baum <[EMAIL PROTECTED]> writes:
>>>I think we should in general avoid to add new packages to LaTeXFeatures
>>>unless the already existing conflicts are solved and we have a more
>>flexible package loading mechanism. The more package syou load
>>>automatically, the more conflicts can arise.
On Fri, Apr 07, 2006 at 04:30:17PM +, Angus Leeming wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > Yep, and what about creating a qt4 namespace? In due time
> > lyx::frontend::qt4::Action could inherit lyx::Action. Or is that against
> > your coding guidelines?
>
> Sounds good to
On Fri, Apr 07, 2006 at 05:26:58PM +0200, Abdelrazak Younes wrote:
> Andre Poenitz a écrit :
> >On Thu, Apr 06, 2006 at 01:52:35PM +0200, Abdelrazak Younes wrote:
> >>Leuven, E. a écrit :
> I think we can shortcut that by
> using QLAction and avoid the call to
> "form_->controller().d
On Fri, Apr 07, 2006 at 05:50:46PM +0200, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> | >> BTW, I am not too happy that we use a 'Q' prefix for _our_ Qt stuff.
> |
> | > Feel free to change that. I agree with with yo
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Yep, and what about creating a qt4 namespace? In due time
> lyx::frontend::qt4::Action could inherit lyx::Action. Or is that against
> your coding guidelines?
Sounds good to me.
Angus
Angus Leeming a écrit :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
BTW, I am not too happy that we use a 'Q' prefix for _our_ Qt stuff.
Feel free to change that. I agree with with you but I just followed the
qt2 code here. Proposal welcome for QLAction, LAction?
Since it's all in namespa
Angus Leeming <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| >> BTW, I am not too happy that we use a 'Q' prefix for _our_ Qt stuff.
|
| > Feel free to change that. I agree with with you but I just followed the
| > qt2 code here. Proposal welcome for QLAction, LAct
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> BTW, I am not too happy that we use a 'Q' prefix for _our_ Qt stuff.
> Feel free to change that. I agree with with you but I just followed the
> qt2 code here. Proposal welcome for QLAction, LAction?
Since it's all in namespace lyx::frontend, why
Andre Poenitz a écrit :
On Thu, Apr 06, 2006 at 01:52:35PM +0200, Abdelrazak Younes wrote:
Leuven, E. a écrit :
I think we can shortcut that by
using QLAction and avoid the call to
"form_->controller().dispatchInsert(str)".
do we have access to lyxview in qmathdialog so that we can pass it to
Helge Hafting wrote:
> Not much of a problem, I think. 1.5svn is a development version,
> so its file format can be a moving target. Or is the intention to
> have perfect support at all times? I don't know how much work
> it is to bump the number. But surely we can delay "official"
> support: K
Martin Vermeer wrote:
On Fri, Apr 07, 2006 at 09:01:08AM +0200, Helge Hafting wrote:
Georg Baum wrote:
I am not sure that a nicefrac: on/off/auto is that useful,
perhaps you can explain the need, when would you
want to force it off? Is there more to it than
don't use "nice fracti
On Friday 07 April 2006 12:00, Helge Hafting wrote:
> Not much of a problem, I think. 1.5svn is a development version,
> so its file format can be a moving target.
True.
> Or is the intention to
> have perfect support at all times?
That is the plan.
> I don't know how much work
> it is t
Georg Baum wrote:
Helge Hafting wrote:
Surely, lyx 1.5.0 will have many new features, so a new
file format is to be expected? There will be unicode,
there will be new insets of which nicefrac is only one.
Of course. The question is whether we bump up the file format just for the
nic
On Fri, Apr 07, 2006 at 09:01:08AM +0200, Helge Hafting wrote:
> Georg Baum wrote:
> I am not sure that a nicefrac: on/off/auto is that useful,
> perhaps you can explain the need, when would you
> want to force it off? Is there more to it than
> don't use "nice fractions" if you don't like the l
Helge Hafting wrote:
> Surely, lyx 1.5.0 will have many new features, so a new
> file format is to be expected? There will be unicode,
> there will be new insets of which nicefrac is only one.
Of course. The question is whether we bump up the file format just for the
nicefrac change.
> I am not
Georg Baum wrote:
Martin Vermeer wrote:
So done, revision 13566:
Fine!
What I forgot to mention earlier: The automatic loading of nicefrac is
(strictly speaking) a file format change. Given the problems we had in 1.3
with the wasy package I am not sure whether we should do that unle
On Thu, Apr 06, 2006 at 11:32:57AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz a écrit :
> >On Wed, Apr 05, 2006 at 12:47:22PM +0200, Abdelrazak Younes wrote:
> >>Abdelrazak Younes a écrit :
> >>>Helge Hafting a écrit :
> >>>Concerning the math panel, it used to work great also last time I
> >
On Thu, Apr 06, 2006 at 01:52:35PM +0200, Abdelrazak Younes wrote:
> Leuven, E. a écrit :
> >>I think we can shortcut that by
> >>using QLAction and avoid the call to
> >>"form_->controller().dispatchInsert(str)".
> >
> >do we have access to lyxview in qmathdialog so that we can pass it to
> >ql
Abdelrazak Younes wrote:
Hum, "Then it is a problem on Hedge side". Because toolbar icons are
fully themable and get their size with the system style.
Hm. They create resizeable icons, but using raster graphichs instead of
vectors. A recipe for disaster. I haven't "set up" qt4 in any way,
Martin Vermeer wrote:
> So done, revision 13566:
Fine!
What I forgot to mention earlier: The automatic loading of nicefrac is
(strictly speaking) a file format change. Given the problems we had in 1.3
with the wasy package I am not sure whether we should do that unless we
have a flexible package
Leuven, E. a écrit :
I think we can shortcut that by
using QLAction and avoid the call to
"form_->controller().dispatchInsert(str)".
do we have access to lyxview in qmathdialog so that we can pass it to qlaction?
Yes: Dialog::View::kernel()->lyxview()
So from QMathDialog that would be
form_
On Wed, Apr 05, 2006 at 11:34:11PM +0200, Andre Poenitz wrote:
> On Wed, Apr 05, 2006 at 07:49:17PM +0300, Martin Vermeer wrote:
> > No, I won't carry out my threat of merging in also \dfrac
> > and \tfrac. Leaving good enough alone ;-)
>
> Commit what you have with enum or such.
>
> Andre'
So
Andre Poenitz a écrit :
On Wed, Apr 05, 2006 at 12:47:22PM +0200, Abdelrazak Younes wrote:
Abdelrazak Younes a écrit :
Helge Hafting a écrit :
Concerning the math panel, it used to work great also last time I
checked (before the ui file conversion) but I see now that there's a lot
of problems
On Wed, Apr 05, 2006 at 07:49:17PM +0300, Martin Vermeer wrote:
> No, I won't carry out my threat of merging in also \dfrac
> and \tfrac. Leaving good enough alone ;-)
Commit what you have with enum or such.
Andre'
On Wed, Apr 05, 2006 at 03:02:23PM +, Angus Leeming wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
> >> Are all these in bugzilla?
>
> > Two of them are now: 2480 and 2481. As there is really nothing
> > controversial in this patch, I plan to apply it soonishly to 1.5.
> > Others can the
On Wed, Apr 05, 2006 at 12:47:22PM +0200, Abdelrazak Younes wrote:
> Abdelrazak Younes a écrit :
> >Helge Hafting a écrit :
> >Concerning the math panel, it used to work great also last time I
> >checked (before the ui file conversion) but I see now that there's a lot
> >of problems. I use exclus
On Wed, Apr 05, 2006 at 05:31:01PM +, Angus Leeming wrote:
> I think that the best solution would be to have multiple frac-derived
> insets in a single file but I'm not doing the work so I'll go back and
> hide under my stone again.
That would be my preference, too. But as I said: Commit it, I
On Wed, Apr 05, 2006 at 03:36:20PM +, Angus Leeming wrote:
> Georg Baum <[EMAIL PROTECTED]> writes:
> > > Then, would you be so kind to move them to lib/images/math and fix
> > > the Xforms and Gtk frontends in consequence? Or just copy them to
> > > lib/images/math if you don't have the time
On Wed, Apr 05, 2006 at 09:16:43AM +0200, Georg Baum wrote:
> Martin Vermeer wrote:
>
> > This bug is apparently not related to the patch. Oldfashioned \frac
> > crashes too. It is again a case of "cursor pos in mid-air": create a
> > \frac, type a character into the numerator, then into the denom
On Wed, Apr 05, 2006 at 10:01:18AM +0300, Martin Vermeer wrote:
> Is the FIXME in undo.h related to this?
> * FIXME: We need something to record undo in partial grids for mathed.
> * Right now we use recordUndoInset if more than one cell is changed,
> * but that puts the cursor in front of the i
Georg Baum a écrit :
Am Mittwoch, 5. April 2006 17:36 schrieb Angus Leeming:
These things were all the images that LyX needed in the dark and distant
days
when XForms was the only frontend. Images were originally #included as C
sources, so there was no need to distribute them. I'd suggest that
Am Mittwoch, 5. April 2006 17:36 schrieb Angus Leeming:
> These things were all the images that LyX needed in the dark and distant
days
> when XForms was the only frontend. Images were originally #included as C
> sources, so there was no need to distribute them. I'd suggest that you
move them
> o
> I think we can shortcut that by
> using QLAction and avoid the call to
> "form_->controller().dispatchInsert(str)".
do we have access to lyxview in qmathdialog so that we can pass it to qlaction?
Martin Vermeer <[EMAIL PROTECTED]> writes:
> It remains a matter of taste. Should we also split out
> \frac and \atop? More important than runtime here is
> legibility / maintainability of the source. Splitting
> out classes with only trivial differences between them
> leads to swarms of diminu
On Wed, Apr 05, 2006 at 03:58:11PM +, Angus Leeming wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
> >> I thought André and Lars both complained that you
> >> were subverting C++'s built in polymorphicism with
> >> your own homemade version and that you should use
> >> separate classes fo
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
Concerning your QMAction class, I think we could merge it with my
QLAction class. But this would maybe mean touching the controller...
food for thought.
i created QMAction because i didn't want (or didn't know how) to pass a
lyxview to an objec
Martin Vermeer <[EMAIL PROTECTED]> writes:
>> I thought André and Lars both complained that you
>> were subverting C++'s built in polymorphicism with
>> your own homemade version and that you should use
>> separate classes for each frac type, all living in
>> mathfrac.[Ch] or whatever it's called.
On Wed, Apr 05, 2006 at 03:02:23PM +, Angus Leeming wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
> >> Are all these in bugzilla?
>
> > Two of them are now: 2480 and 2481.
> > As there is really nothing controversial in this patch, I plan to apply
> > it soonishly to 1.5. Others can then
Georg Baum <[EMAIL PROTECTED]> writes:
> > Then, would you be so kind to move them to lib/images/math and fix the
> > Xforms and Gtk frontends in consequence? Or just copy them to
> > lib/images/math if you don't have the time to fix the frontends.
> No, please lets not copy. We should rather fin
Georg Baum a écrit :
Abdelrazak Younes wrote:
Then, would you be so kind to move them to lib/images/math and fix the
Xforms and Gtk frontends in consequence? Or just copy them to
lib/images/math if you don't have the time to fix the frontends.
No, please lets not copy. We should rather find
Abdelrazak Younes wrote:
> Then, would you be so kind to move them to lib/images/math and fix the
> Xforms and Gtk frontends in consequence? Or just copy them to
> lib/images/math if you don't have the time to fix the frontends.
No, please lets not copy. We should rather find out why they are in
Georg Baum a écrit :
Abdelrazak Younes wrote:
Georg Baum a écrit :
Abdelrazak Younes wrote:
I was going to. I have already committed the icons.
You forgot to add the new image to the Makefile, and you broke both
xforms and gtk :-(
Sorry to make you a watch dog again :-(
I thought those ico
Abdelrazak Younes wrote:
> Georg Baum a écrit :
>> Abdelrazak Younes wrote:
>>
>>> I was going to. I have already committed the icons.
>>
>> You forgot to add the new image to the Makefile, and you broke both
>> xforms and gtk :-(
>
> Sorry to make you a watch dog again :-(
> I thought those ic
Martin Vermeer <[EMAIL PROTECTED]> writes:
>> Are all these in bugzilla?
> Two of them are now: 2480 and 2481.
> As there is really nothing controversial in this patch, I plan to apply
> it soonishly to 1.5. Others can then add qt4. I wouldn't bother with
> xforms.
I thought André and Lars both c
Georg Baum a écrit :
Abdelrazak Younes wrote:
I was going to. I have already committed the icons.
You forgot to add the new image to the Makefile, and you broke both xforms
and gtk :-(
Sorry to make you a watch dog again :-(
I thought those icons were not used at all.
For those unfamiliar
Edwin Leuven a écrit :
So, do I commit them or not?
yes, thanks
OK, I am committing with the following hack within MathUi.ui: I have
replaced "../../../../images/" with "../lib/images".
This is a temporary measure so that the math panel get its icons
displayed under linux and when lyx is
Georg Baum wrote:
You forgot to add the new image to the Makefile, and you broke both xforms
and gtk :-(
oops
For those unfamiliar with the .xpm format: This can be read as C source (and
is used as such in the xforms and gtk frontends), so one may not
arbitrarily change the internal image nam
Abdelrazak Younes wrote:
> I was going to. I have already committed the icons.
You forgot to add the new image to the Makefile, and you broke both xforms
and gtk :-(
For those unfamiliar with the .xpm format: This can be read as C source (and
is used as such in the xforms and gtk frontends), so o
Abdelrazak Younes wrote:
Concerning your QMAction class, I think we could merge it with my
QLAction class. But this would maybe mean touching the controller...
food for thought.
i created QMAction because i didn't want (or didn't know how) to pass a
lyxview to an object in QMathDialog.
but
So, do I commit them or not?
yes, thanks
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
I was going to. I have already committed the icons. If you want to
give it a try for the rest please go ahead. I thought you had problem
with SVN access.
not atm, but i think you committed the whole bunch
No, not yet.
(haven't really gotten a
Abdelrazak Younes wrote:
I was going to. I have already committed the icons. If you want to give
it a try for the rest please go ahead. I thought you had problem with
SVN access.
not atm, but i think you committed the whole bunch
(haven't really gotten around to read the svn documentation, ho
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
Edwin Leuven a écrit :
Yep you're right, I've reached the same conclusion about qmenu at the
time of the porting. Actually, that's the reason why I haven't
ported the qt2 bullets yet :-(
perhaps we should apply the attached in the meantime?
I
Abdelrazak Younes wrote:
Everything works fine. Good job Man!
thanks
I am committing this now.
ok thanks
Concerning your QMAction class, I think we could merge it with my
QLAction class. But this would maybe mean touching the controller...
food for thought.
Now, let's discuss about the i
Abdelrazak Younes wrote:
Edwin Leuven a écrit :
Yep you're right, I've reached the same conclusion about qmenu at the
time of the porting. Actually, that's the reason why I haven't
ported the qt2 bullets yet :-(
perhaps we should apply the attached in the meantime?
I have committed it.
yo
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
Edwin,
I can't apply your patch cleanly. QMathUI.ui and QMathDialoc.C seem to
have conflict with revision 13551. From what I see in the diff, the
changes look just fine. Please commit so that we work from there. If
you can't commit, please sen
On Wed, 2006-04-05 at 10:01 +0300, Martin Vermeer wrote:
> On Tue, 2006-04-04 at 21:00 +0200, Helge Hafting wrote:
> > On Mon, Apr 03, 2006 at 12:28:11PM +0300, Martin Vermeer wrote:
> > > On Sun, Apr 02, 2006 at 08:54:46PM +0300, Martin Vermeer wrote:
...
> Are all these in bugzilla?
Two of the
Edwin Leuven a écrit :
Yep you're right, I've reached the same conclusion about qmenu at the
time of the porting. Actually, that's the reason why I haven't
ported the qt2 bullets yet :-(
perhaps we should apply the attached in the meantime?
I have committed it.
Please wait for my merged p
Abdelrazak Younes wrote:
Edwin,
I can't apply your patch cleanly. QMathUI.ui and QMathDialoc.C seem to
have conflict with revision 13551. From what I see in the diff, the
changes look just fine. Please commit so that we work from there. If you
can't commit, please send those two files.
att
Edwin,
I can't apply your patch cleanly. QMathUI.ui and QMathDialoc.C seem to
have conflict with revision 13551. From what I see in the diff, the
changes look just fine. Please commit so that we work from there. If you
can't commit, please send those two files.
Thanks,
Abdel.
Edwin Leuven
Abdelrazak Younes a écrit :
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
By the way, how are the toolbar icons for you?
they are ugly, but apart from that no problems on my side
Them it is a them problem on Hedge side.
Hum, "Then it is a problem on Hedge side". Because toolbar icons ar
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
By the way, how are the toolbar icons for you?
they are ugly, but apart from that no problems on my side
Them it is a them problem on Hedge side.
perhaps we should apply the attached in the meantime?
What do you want that?
I think I know wh
Abdelrazak Younes wrote:
By the way, how are the toolbar icons for you?
they are ugly, but apart from that no problems on my side
perhaps we should apply the attached in the meantime?
What do you want that?
I think I know where you want to go but please explain it.
BulletsModule is a wid
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
I know, this is because uic logically translates the path to the icon
"as is" so the binary doesn't find them. I am playing with the
generated header file to see how we could solve that.
why not move the images so that they can be themeable, ins
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
On Windows, all the icons are spread horizontally so in for some
cases some of the icons are off-screen. Is it the same for you?
yes
OK.
By the way, how are the toolbar icons for you?
it would be nice to have a widget iconpalette that we can
Abdelrazak Younes wrote:
I know, this is because uic logically translates the path to the icon
"as is" so the binary doesn't find them. I am playing with the generated
header file to see how we could solve that.
why not move the images so that they can be themeable, instead of
finding a solut
Abdelrazak Younes wrote:
On Windows, all the icons are spread horizontally so in for some
cases some of the icons are off-screen. Is it the same for you?
yes
it would be nice to have a widget iconpalette that we can hook on
to a toolbutton (as we use for the bullets in the qt2 frontend). it
s
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
It seems that Qt4 ui format doesn't support embedded icons like older
version did. I found similar xpm in "trunk/images". I have used those
for now but I am missing the one that should come with the style
PushButton. But the icons still do not sh
Abdelrazak Younes wrote:
It seems that Qt4 ui format doesn't support embedded icons like older
version did. I found similar xpm in "trunk/images". I have used those
for now but I am missing the one that should come with the style
PushButton. But the icons still do not show in the math panel und
Abdelrazak Younes a écrit :
Helge Hafting a écrit :
Concerning the math panel, it used to work great also last time I
checked (before the ui file conversion) but I see now that there's a lot
of problems. I use exclusively the math toolbar so I didn't notice. I'll
try to have a look at this ove
Helge Hafting a écrit :
On Mon, Apr 03, 2006 at 12:28:11PM +0300, Martin Vermeer wrote:
On Sun, Apr 02, 2006 at 08:54:46PM +0300, Martin Vermeer wrote:
See patch. No GUI support for now.
Here is a new patch, using enum, and having GUI support. Wasn't so much
work after all.
Please give this s
Martin Vermeer wrote:
> This bug is apparently not related to the patch. Oldfashioned \frac
> crashes too. It is again a case of "cursor pos in mid-air": create a
> \frac, type a character into the numerator, then into the denominator
> (leaving cur.pos() = 1), then move out of the fraction to the
On Tue, 2006-04-04 at 21:00 +0200, Helge Hafting wrote:
> On Mon, Apr 03, 2006 at 12:28:11PM +0300, Martin Vermeer wrote:
> > On Sun, Apr 02, 2006 at 08:54:46PM +0300, Martin Vermeer wrote:
> > > See patch. No GUI support for now.
> >
> > Here is a new patch, using enum, and having GUI support. Wa
On Mon, Apr 03, 2006 at 12:28:11PM +0300, Martin Vermeer wrote:
> On Sun, Apr 02, 2006 at 08:54:46PM +0300, Martin Vermeer wrote:
> > See patch. No GUI support for now.
>
> Here is a new patch, using enum, and having GUI support. Wasn't so much
> work after all.
>
> Please give this some testing.
On Mon, Apr 03, 2006 at 12:04:35PM +0300, Martin Vermeer wrote:
> Looking at tfrac and dfrac, I would rather merge them with frac too, as
> they are so small that separate insets is overkill. IMHO.
The only overkill is having lots of small files turning into 200k
monsters in a debug compile. [I pe
On Sun, Apr 02, 2006 at 08:54:46PM +0300, Martin Vermeer wrote:
> See patch. No GUI support for now.
Here is a new patch, using enum, and having GUI support. Wasn't so much
work after all.
Please give this some testing.
- Martin
Index: LaTeXFeatures.C
===
Martin Vermeer wrote:
> Looking at tfrac and dfrac, I would rather merge them with frac too, as
> they are so small that separate insets is overkill. IMHO.
Yes, why not. Storing an emum should not be more expensive than a bool, and
some switch statements in draw() and write() are also fast.
Geo
On Mon, Apr 03, 2006 at 08:38:16AM +0200, Georg Baum wrote:
> Martin Vermeer wrote:
>
> > On Sun, Apr 02, 2006 at 07:59:42PM +0200, Lars Gullik Bjønnes wrote:
> >> Martin Vermeer <[EMAIL PROTECTED]> writes:
> >>
> >> | See patch. No GUI support for now.
> >>
> >> Can we use something a bit stron
Martin Vermeer wrote:
> On Sun, Apr 02, 2006 at 07:59:42PM +0200, Lars Gullik Bjønnes wrote:
>> Martin Vermeer <[EMAIL PROTECTED]> writes:
>>
>> | See patch. No GUI support for now.
>>
>> Can we use something a bit stronger typed for the kind parameter?
>
> That would be an enum.
Another possi
On Sun, Apr 02, 2006 at 07:59:42PM +0200, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | See patch. No GUI support for now.
>
> Can we use something a bit stronger typed for the kind parameter?
That would be an enum.
- Martin
pgp7mMQ6dD6Ul.pgp
Description: PGP
Martin Vermeer <[EMAIL PROTECTED]> writes:
| See patch. No GUI support for now.
Can we use something a bit stronger typed for the kind parameter?
--
Lgb
See patch. No GUI support for now.
- Martin
Index: math_factory.C
===
--- math_factory.C (revision 13546)
+++ math_factory.C (working copy)
@@ -317,10 +317,12 @@ MathAtom createMathInset(string const &
retu
84 matches
Mail list logo
