On Wed, May 31, 2006 at 12:12:53PM +0200, Edwin Leuven wrote:
attached my latest patch
i'd like to put it in
any objections?
As usual: Please stick to LyX style. For examples refer to code in
src/*.C, not in frontend/whatever. [It's much better nowadays, though]
+{
+ if
On Wed, May 31, 2006 at 12:12:53PM +0200, Edwin Leuven wrote:
> attached my latest patch
>
> i'd like to put it in
>
> any objections?
As usual: Please stick to LyX style. For examples refer to code in
src/*.C, not in frontend/whatever. [It's much better nowadays, though]
> +{
> + if
attached my latest patch
i'd like to put it in
any objections?
thanks, edwin
Index: development/scons/SConscript
===
--- development/scons/SConscript(revision 13969)
+++ development/scons/SConscript(working copy)
Edwin Leuven [EMAIL PROTECTED] writes:
attached my latest patch
i'd like to put it in
any objections?
None from me; looks good.
Some points to think about though:
1. Doxygen comments in InsertTableWidget.h.
2. dynamic_cast rather than static_cast in InsertTableWidget::event?
3. You'll upset
Edwin Leuven wrote:
attached my latest patch
i'd like to put it in
any objections?
Not an objection but I'd like you to keep in mind that this code needs
to generalized. So I hope that in due time (in time with math symbols)
you (we) clean that up. I thing the right strategy is define a
Abdelrazak Younes wrote:
Not an objection but I'd like you to keep in mind that this code needs
to generalized. So I hope that in due time (in time with math symbols)
you (we) clean that up. I thing the right strategy is define a new kind
of Action that will do exactly that. It could be a new
Angus Leeming wrote:
Some points to think about though:
1. Doxygen comments in InsertTableWidget.h.
2. dynamic_cast rather than static_cast in InsertTableWidget::event?
3. You'll upset André with formatting if (foo!=bar). Space it out a bit.
it is in with these changes
4. Should these
Edwin Leuven [EMAIL PROTECTED] writes:
| +bool InsertTableWidget::event(QEvent * event)
| +{
| + if (event-type() == QEvent::MouseMove) {
| + QMouseEvent * me = static_castQMouseEvent *(event);
| + mouseMoveEvent(me);
| + return true;
| + } else if
Lars Gullik Bjønnes wrote:
this looks like a switch to me. Use that if it works.
done
attached my latest patch
i'd like to put it in
any objections?
thanks, edwin
Index: development/scons/SConscript
===
--- development/scons/SConscript(revision 13969)
+++ development/scons/SConscript(working copy)
Edwin Leuven <[EMAIL PROTECTED]> writes:
> attached my latest patch
> i'd like to put it in
> any objections?
None from me; looks good.
Some points to think about though:
1. Doxygen comments in InsertTableWidget.h.
2. dynamic_cast rather than static_cast in InsertTableWidget::event?
3. You'll
Edwin Leuven wrote:
attached my latest patch
i'd like to put it in
any objections?
Not an objection but I'd like you to keep in mind that this code needs
to generalized. So I hope that in due time (in time with math symbols)
you (we) clean that up. I thing the right strategy is define a
Abdelrazak Younes wrote:
Not an objection but I'd like you to keep in mind that this code needs
to generalized. So I hope that in due time (in time with math symbols)
you (we) clean that up. I thing the right strategy is define a new kind
of Action that will do exactly that. It could be a new
Angus Leeming wrote:
Some points to think about though:
1. Doxygen comments in InsertTableWidget.h.
2. dynamic_cast rather than static_cast in InsertTableWidget::event?
3. You'll upset André with formatting "if (foo!=bar)". Space it out a bit.
it is in with these changes
4. Should these
Edwin Leuven <[EMAIL PROTECTED]> writes:
| +bool InsertTableWidget::event(QEvent * event)
| +{
| + if (event->type() == QEvent::MouseMove) {
| + QMouseEvent * me = static_cast(event);
| + mouseMoveEvent(me);
| + return true;
| + } else if (event->type()
Lars Gullik Bjønnes wrote:
this looks like a switch to me. Use that if it works.
done
guys i have a question about the following.
here i dispatch the funcrequest to insert a table:
+void InsertTableWidget::mouseReleaseEvent(QMouseEvent * event)
+{
+ if (underMouse()) {
+ QString const data = QString(%1 %2).arg(bottom_).arg(right_);
+
Edwin == Edwin Leuven [EMAIL PROTECTED] writes:
Edwin thing is: the table gets inserted but not at the cursor
Edwin position but at the beginning of the buffer!
You should always dispatch to LyXView::getLyXFunc().dispatch()
workAreaDispatch is limited to mouse interaction.
JMarc
Jean-Marc Lasgouttes wrote:
You should always dispatch to LyXView::getLyXFunc().dispatch()
workAreaDispatch is limited to mouse interaction.
got it. thanks!
guys i have a question about the following.
here i dispatch the funcrequest to insert a table:
+void InsertTableWidget::mouseReleaseEvent(QMouseEvent * event)
+{
+ if (underMouse()) {
+ QString const data = QString("%1 %2").arg(bottom_).arg(right_);
+
> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
Edwin> thing is: the table gets inserted but not at the cursor
Edwin> position but at the beginning of the buffer!
You should always dispatch to LyXView::getLyXFunc().dispatch()
workAreaDispatch is limited to mouse interaction.
JMarc
Jean-Marc Lasgouttes wrote:
You should always dispatch to LyXView::getLyXFunc().dispatch()
workAreaDispatch is limited to mouse interaction.
got it. thanks!
Edwin == Edwin Leuven [EMAIL PROTECTED] writes:
Edwin what i haven't done: implement a lyxfunc
Edwin the main reason is that it is not clear to me that we would
Edwin want to introduce special casing in the core in order to avoid
Edwin it in the frontend...
What you can do is create a special
Jean-Marc Lasgouttes wrote:
What you can do is create a special casing in ToobarBackend.C for your
popup widget.
thanks, i'll have a look there
icon palette and menu are syntactically the same thing, only the
display differs (icons vs. labels). These things should be implemented
in
Edwin == Edwin Leuven [EMAIL PROTECTED] writes:
It seems to me that the icon palettes and menus that we need for a
math toolbar are static, am I wrong? In this case, supporting them
is as simple as enumerating in the .ui file.
Edwin unless we want to allow user defined iconpanels ...
These
> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
Edwin> what i haven't done: implement a lyxfunc
Edwin> the main reason is that it is not clear to me that we would
Edwin> want to introduce special casing in the core in order to avoid
Edwin> it in the frontend...
What you can do is
Jean-Marc Lasgouttes wrote:
What you can do is create a special casing in ToobarBackend.C for your
popup widget.
thanks, i'll have a look there
icon palette and menu are syntactically the same thing, only the
display differs (icons vs. labels). These things should be implemented
in
> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
>> It seems to me that the icon palettes and menus that we need for a
>> math toolbar are static, am I wrong? In this case, supporting them
>> is as simple as enumerating in the .ui file.
Edwin> unless we want to allow user defined
On Tue, May 23, 2006 at 09:23:19PM +0200, Edwin Leuven wrote:
i do what i can andre (although i have no clue what you are referring
to) ...
We write 'a = 1;', not 'a=1;', and 'for (', not 'for('...
and now that i have your attention:
have you an idea on how to catch mouse events outside
Andre Poenitz wrote:
We write 'a = 1;', not 'a=1;', and 'for (', not 'for('...
i try to be good in the attached...
have you an idea on how to catch mouse events outside the iconview
widget here:
http://leuven.ecodip.net/lyx/iconview.zip
Is that the one you send to qt-interest?
yeah,
On Tue, May 23, 2006 at 09:23:19PM +0200, Edwin Leuven wrote:
> i do what i can andre (although i have no clue what you are referring
> to) ...
We write 'a = 1;', not 'a=1;', and 'for (', not 'for('...
> and now that i have your attention:
>
> have you an idea on how to catch mouse events
Andre Poenitz wrote:
We write 'a = 1;', not 'a=1;', and 'for (', not 'for('...
i try to be good in the attached...
have you an idea on how to catch mouse events outside the iconview
widget here:
http://leuven.ecodip.net/lyx/iconview.zip
Is that the one you send to qt-interest?
yeah,
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
In principle it should be as easy as replacing QTabularCreate in
qt4/Dialog.C with your new dialog. Then, to correctly position your
dialog, you will need to add a method in ControlTabularCreate that
will give the coordinate of toolbar button.
Abdelrazak Younes wrote:
Here are my comments Edwin...
First I think the LIconview name is not correct. Maybe
InsertTableWidget? In any case, please drop the 'L' as we are already in
lyx namespace.
Second, the file name should be the same as the class including the
case. So that would be
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
I have to admit I don't like the special code below. Did you try to
use the Controller framework instead?
i must admit i didn't. having a controller for calling a function seems
a bit overkill to me, that's why i didn't bother. i guess it can
Abdelrazak Younes wrote:
I agree it's overkill and we already discussed at length the subject.
But all other dialogs go through this controller framework so I would
prefer that you use that. Besides, I suspect that the change would be
even less intrusive if you do so. No need need to touch the
Edwin Leuven [EMAIL PROTECTED] writes:
Don't forget to add liconview.[Ch] to Makefile.am too:
Index: development/scons/SConscript
===
--- development/scons/SConscript (revision 13913)
+++ development/scons/SConscript
Angus Leeming wrote:
The const in bool const foo isn't needed/wanted in the header, only in the
.C file. Think of it as an implementation detail.
No doxygen comments.
ok
What does the updateonly do?
only the update() call (and not the action() ), that is: enable/disable
the widget
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
I agree it's overkill and we already discussed at length the subject.
But all other dialogs go through this controller framework so I would
prefer that you use that. Besides, I suspect that the change would be
even less intrusive if you do so.
Edwin Leuven a écrit :
Angus Leeming wrote:
only the update() call (and not the action() ), that is: enable/disable
the widget
See my other mail. I think you should try to reuse that part also.
While you're at it, it should be std::string const tooltip =
std::string().
will change that
Abdelrazak Younes a écrit :
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
I agree it's overkill and we already discussed at length the subject.
But all other dialogs go through this controller framework so I would
prefer that you use that. Besides, I suspect that the change would be
even
Abdelrazak Younes wrote:
Hum... thinking more about it, you could as well reuse the same QLAction
for the menu item call. I don't think the present dialog version provide
any more functionality than what you are proposing. I mean, it's not
like one will want to insert a 100x100 table, this
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
Hum... thinking more about it, you could as well reuse the same
QLAction for the menu item call. I don't think the present dialog
version provide any more functionality than what you are proposing. I
mean, it's not like one will want to insert a
Abdelrazak Younes wrote:
OK, you have a point... Forget about it and just create a new LFUN please.
ok, the problem then is how to get the pos() of the toolbutton without
touching qltoolbar... will try to figure that out
thanks,
edwin
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
OK, you have a point... Forget about it and just create a new LFUN
please.
ok, the problem then is how to get the pos() of the toolbutton without
touching qltoolbar... will try to figure that out
I don't have the documentation at hand but I
On Tue, May 23, 2006 at 03:49:12PM +0200, Edwin Leuven wrote:
the attached slightly modifies qlaction and avoids changing qltoolbar.
opinion?
You definitely should try harder to stick to LyX coding style
no matter whether you agree with the rules or not.
It took us several years to end up
On Mon, May 22, 2006 at 11:07:34PM +0200, Edwin Leuven wrote:
+ for(int i=0; irowCount() ; ++i)
Mind your spacing. It's not LyX style all over the place.
for (int i = 0; i rowCount(); ++i)
And of course you could try to evaluate rowCount only once.
Andre'
Andre Poenitz wrote:
On Tue, May 23, 2006 at 03:49:12PM +0200, Edwin Leuven wrote:
the attached slightly modifies qlaction and avoids changing qltoolbar.
opinion?
You definitely should try harder to stick to LyX coding style
no matter whether you agree with the rules or not.
It took us
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
In principle it should be as easy as replacing QTabularCreate in
"qt4/Dialog.C" with your new dialog. Then, to correctly position your
dialog, you will need to add a method in ControlTabularCreate that
will give the coordinate of toolbar button.
Abdelrazak Younes wrote:
Here are my comments Edwin...
First I think the LIconview name is not correct. Maybe
InsertTableWidget? In any case, please drop the 'L' as we are already in
lyx namespace.
Second, the file name should be the same as the class including the
case. So that would be
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
I have to admit I don't like the special code below. Did you try to
use the Controller framework instead?
i must admit i didn't. having a controller for calling a function seems
a bit overkill to me, that's why i didn't bother. i guess it can
Abdelrazak Younes wrote:
I agree it's overkill and we already discussed at length the subject.
But all other dialogs go through this controller framework so I would
prefer that you use that. Besides, I suspect that the change would be
even less intrusive if you do so. No need need to touch the
Edwin Leuven <[EMAIL PROTECTED]> writes:
Don't forget to add liconview.[Ch] to Makefile.am too:
> Index: development/scons/SConscript
> ===
> --- development/scons/SConscript (revision 13913)
> +++ development/scons/SConscript
Angus Leeming wrote:
The "const" in "bool const foo" isn't needed/wanted in the header, only in the
.C file. Think of it as an implementation detail.
No doxygen comments.
ok
What does the updateonly do?
only the update() call (and not the action() ), that is: enable/disable
the widget
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
I agree it's overkill and we already discussed at length the subject.
But all other dialogs go through this controller framework so I would
prefer that you use that. Besides, I suspect that the change would be
even less intrusive if you do so.
Edwin Leuven a écrit :
Angus Leeming wrote:
only the update() call (and not the action() ), that is: enable/disable
the widget
See my other mail. I think you should try to reuse that part also.
While you're at it, it should be "std::string const & tooltip =
std::string()".
will change
Abdelrazak Younes a écrit :
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
I agree it's overkill and we already discussed at length the subject.
But all other dialogs go through this controller framework so I would
prefer that you use that. Besides, I suspect that the change would be
even
Abdelrazak Younes wrote:
Hum... thinking more about it, you could as well reuse the same QLAction
for the menu item call. I don't think the present dialog version provide
any more functionality than what you are proposing. I mean, it's not
like one will want to insert a 100x100 table, this
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
Hum... thinking more about it, you could as well reuse the same
QLAction for the menu item call. I don't think the present dialog
version provide any more functionality than what you are proposing. I
mean, it's not like one will want to insert a
Abdelrazak Younes wrote:
OK, you have a point... Forget about it and just create a new LFUN please.
ok, the problem then is how to get the pos() of the toolbutton without
touching qltoolbar... will try to figure that out
thanks,
edwin
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
OK, you have a point... Forget about it and just create a new LFUN
please.
ok, the problem then is how to get the pos() of the toolbutton without
touching qltoolbar... will try to figure that out
I don't have the documentation at hand but I
On Tue, May 23, 2006 at 03:49:12PM +0200, Edwin Leuven wrote:
> the attached slightly modifies qlaction and avoids changing qltoolbar.
> opinion?
You definitely should try harder to stick to LyX coding style
no matter whether you agree with the rules or not.
It took us several years to end up
On Mon, May 22, 2006 at 11:07:34PM +0200, Edwin Leuven wrote:
> + for(int i=0; i
Andre Poenitz wrote:
On Tue, May 23, 2006 at 03:49:12PM +0200, Edwin Leuven wrote:
the attached slightly modifies qlaction and avoids changing qltoolbar.
opinion?
You definitely should try harder to stick to LyX coding style
no matter whether you agree with the rules or not.
It took us
Abdelrazak Younes wrote:
In principle it should be as easy as replacing QTabularCreate in
qt4/Dialog.C with your new dialog. Then, to correctly position your
dialog, you will need to add a method in ControlTabularCreate that
will give the coordinate of toolbar button.
the attached patch is
Abdelrazak Younes wrote:
In principle it should be as easy as replacing QTabularCreate in
"qt4/Dialog.C" with your new dialog. Then, to correctly position your
dialog, you will need to add a method in ControlTabularCreate that
will give the coordinate of toolbar button.
the attached patch is
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
(talking to myself guys, don't pay attention...)
I am listening Edwin :-)
great! (ready for abuse? ;-)
to put this in the toolbar we need to initialize the widget with the
proper button as a parent and then connect some signals (or so i
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
(talking to myself guys, don't pay attention...)
I am listening Edwin :-)
great! (ready for abuse? ;-)
to put this in the toolbar we need to initialize the widget with the
proper button as a parent and then connect some signals (or so i
am trying to program up a insert-tabular-popupwidget that can be
connected to a toolbutton
the archive here:
http://leuven.ecodip.net/lyx/iconview.zip
includes the code + windows executable to illustrate what i
am after
comments appreciated and in particular hints as how to make it popup and
Edwin Leuven a écrit :
am trying to program up a insert-tabular-popupwidget that can be
connected to a toolbutton
the archive here:
http://leuven.ecodip.net/lyx/iconview.zip
includes the code + windows executable to illustrate what i
am after
comments appreciated
It looks great.
and in
Abdelrazak Younes wrote:
It looks great.
thanks (just a shameless copy of the openoffice widget though...)
and in particular hints as how to make it popup and
behave as a menu with a toolbutton. haven't been able yet to figure this
out...
You could do the same as now: create a borderless
Edwin Leuven wrote:
atm it is a widget.
would be nice it we could make it behave as a qmenu...
initializing with a parent, then overloading show() as follows seems to work
void LIconView::show()
{
move(parentWidget()-geometry().x(),
parentWidget()-geometry().y() +
Edwin Leuven a écrit :
Edwin Leuven wrote:
atm it is a widget.
would be nice it we could make it behave as a qmenu...
initializing with a parent, then overloading show() as follows seems to
work
Good.
void LIconView::show()
{
move(parentWidget()-geometry().x(),
Abdelrazak Younes wrote:
(talking to myself guys, don't pay attention...)
I am listening Edwin :-)
great! (ready for abuse? ;-)
to put this in the toolbar we need to initialize the widget with the
proper button as a parent and then connect some signals (or so i think)
have you any ideas
am trying to program up a "insert-tabular-popupwidget" that can be
connected to a toolbutton
the archive here:
http://leuven.ecodip.net/lyx/iconview.zip
includes the code + windows executable to illustrate what i
am after
comments appreciated and in particular hints as how to make it popup
Edwin Leuven a écrit :
am trying to program up a "insert-tabular-popupwidget" that can be
connected to a toolbutton
the archive here:
http://leuven.ecodip.net/lyx/iconview.zip
includes the code + windows executable to illustrate what i
am after
comments appreciated
It looks great.
and in
Abdelrazak Younes wrote:
It looks great.
thanks (just a shameless copy of the openoffice widget though...)
and in particular hints as how to make it popup and
behave as a menu with a toolbutton. haven't been able yet to figure this
out...
You could do the same as now: create a borderless
Edwin Leuven wrote:
atm it is a widget.
would be nice it we could make it behave as a qmenu...
initializing with a parent, then overloading show() as follows seems to work
void LIconView::show()
{
move(parentWidget()->geometry().x(),
parentWidget()->geometry().y() +
Edwin Leuven a écrit :
Edwin Leuven wrote:
atm it is a widget.
would be nice it we could make it behave as a qmenu...
initializing with a parent, then overloading show() as follows seems to
work
Good.
void LIconView::show()
{
move(parentWidget()->geometry().x(),
Abdelrazak Younes wrote:
(talking to myself guys, don't pay attention...)
I am listening Edwin :-)
great! (ready for abuse? ;-)
to put this in the toolbar we need to initialize the widget with the
proper button as a parent and then connect some signals (or so i think)
have you any ideas
80 matches
Mail list logo