Re: Getting rid of qttableview.[Ch]

[younes . a]

Hum this mail is not in gmane too...

Quoting Jean-Marc Lasgouttes [EMAIL PROTECTED]:
  Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:

 Abdelrazak Nothing happened to qttableview.h only to qttableview.C.
 Abdelrazak qttableview.h is the verbatim copy of december 2001; so
 Abdelrazak this is not a move of config.h to qttableview.C but a
 Abdelrazak creation.

 Indeed. And I have checked that both qt and boost input limits.h
 without any guard, which means that we can indeed remove the
 HAVE_LIMITS_H macro.

Houra!!! We spoke about that bloody change for a complete day.

 I am not sure it will change anything, though.

This one in particular not much indeed. But it's one less configure test that
consumes times.

Abdel.

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

 younes == younes a [EMAIL PROTECTED] writes:

  Indeed. And I have checked that both qt and boost input without
 any guard, which means that we can indeed remove the HAVE_LIMITS_H
 macro.

younes Houra!!! We spoke about that bloody change for a complete day.

You would have been more convincing if you did the research yourself.
For the future, I think that what boost does can be considered as a
good guideline.

What about getting rid of the stuff in support/lyxdir.h in favour of
boost stuff. I am not sure everything can go away, but it seems there
is room for cleanup.

Careful cleanup, of course :)

JMarc

Re: Getting rid of qttableview.[Ch]

[Abdelrazak Younes]

Jean-Marc Lasgouttes a écrit :

younes == younes a [EMAIL PROTECTED] writes:



 Indeed. And I have checked that both qt and boost input without
any guard, which means that we can indeed remove the HAVE_LIMITS_H
macro.


younes Houra!!! We spoke about that bloody change for a complete day.

You would have been more convincing if you did the research yourself.


I think (not sure) I have said that the original file didn't do the test 
and that Qt is very portable so why should we?



For the future, I think that what boost does can be considered as a
good guideline.

What about getting rid of the stuff in support/lyxdir.h in favour of
boost stuff. I am not sure everything can go away, but it seems there
is room for cleanup.


Hey, that's my point since the beginning ;-)


Careful cleanup, of course :)


Sure boss. I'll try to do something next week-end. But I will not touch 
autotools stuff.


Abdel.

Re: Getting rid of qttableview.[Ch]

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  younes == younes a [EMAIL PROTECTED] writes:
| 
|   Indeed. And I have checked that both qt and boost input without
|  any guard, which means that we can indeed remove the HAVE_LIMITS_H
|  macro.
| 
| younes Houra!!! We spoke about that bloody change for a complete day.
| 
| You would have been more convincing if you did the research yourself.
| For the future, I think that what boost does can be considered as a
| good guideline.
| 
| What about getting rid of the stuff in support/lyxdir.h in favour of
| boost stuff. I am not sure everything can go away, but it seems there
| is room for cleanup.

support/lyxdir.h?

-- 
Lgb

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

 Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:

Abdelrazak I think (not sure) I have said that the original file
Abdelrazak didn't do the test and that Qt is very portable so why
Abdelrazak should we?

Yes, but the file was not part of qt itself, and I was suspicious it
might not be as portable as the rest. My fault, I admit.

 For the future, I think that what boost does can be considered as a
 good guideline. What about getting rid of the stuff in
 support/lyxdir.h in favour of boost stuff. I am not sure everything
 can go away, but it seems there is room for cleanup.

Abdelrazak Hey, that's my point since the beginning ;-)

So, why don't you do that first? mkdir should be too difficult to get
right, for a start :)

JMarc

Re: Getting rid of qttableview.[Ch]

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
| 
| Abdelrazak I think (not sure) I have said that the original file
| Abdelrazak didn't do the test and that Qt is very portable so why
| Abdelrazak should we?
| 
| Yes, but the file was not part of qt itself, and I was suspicious it
| might not be as portable as the rest. My fault, I admit.
| 
|  For the future, I think that what boost does can be considered as a
|  good guideline. What about getting rid of the stuff in
|  support/lyxdir.h in favour of boost stuff. I am not sure everything
|  can go away, but it seems there is room for cleanup.
| 
| Abdelrazak Hey, that's my point since the beginning ;-)
| 
| So, why don't you do that first? mkdir should be too difficult to get
| right, for a start :)

Actually that one is troublesome... last time I checked boost have no
way of setting the mode for the created dir.

And... the easy way to change these functions is not to change the
header files, at least not initally, but just change the
implementation.

And if possible add a test to support/tests

-- 
Lgb

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars support/lyxdir.h?

Sorry. support/lyxlib.h. I think most of it is covered by boost, isn't
it?

JMarc

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars Actually that one is troublesome... last time I checked boost
Lars have no way of setting the mode for the created dir.

What mode does it use? I see we use either 700 or 777, why is that?

We could just rely on umask, couldn't we? I remember a discussion on
this subject, but not the outcome.

Lars And... the easy way to change these functions is not to change
Lars the header files, at least not initally, but just change the
Lars implementation.

Or not use the function at all, but rather boost directly?

JMarc

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

 Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Actually that one is troublesome... last time I checked boost
Lars have no way of setting the mode for the created dir.

Jean-Marc What mode does it use? I see we use either 700 or 777, why
Jean-Marc is that?

Answering to myself:

I see boost only uses 777. We need 700 to avoid making our temp files
readable/writeable to other users.

JMarc

Re: Getting rid of qttableview.[Ch]

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| 
| Lars support/lyxdir.h?
| 
| Sorry. support/lyxlib.h. I think most of it is covered by boost, isn't
| it?

getcwd
rename¹
copy
unlink
mkdir²

¹ boost::rename might not be good enough, our falls back to copy if
the files reside on different filesystems.

² boost::mkdir does not take a mode argument, and thus is not really
usable for us.

-- 
Lgb

Re: Getting rid of qttableview.[Ch]

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| Lars And... the easy way to change these functions is not to change
| Lars the header files, at least not initally, but just change the
| Lars implementation.
| 
| Or not use the function at all, but rather boost directly?

I would prefere just the implementation initially, then it is clearly
localized, and you change all callers at once.

-- 
Lgb

Re: Getting rid of qttableview.[Ch]

[younes . a]

Hum this mail is not in gmane too...

Quoting Jean-Marc Lasgouttes <[EMAIL PROTECTED]>:
> > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> Abdelrazak> Nothing happened to qttableview.h only to qttableview.C.
> Abdelrazak> qttableview.h is the verbatim copy of december 2001; so
> Abdelrazak> this is not a move of config.h to qttableview.C but a
> Abdelrazak> creation.
>
> Indeed. And I have checked that both qt and boost input 
> without any guard, which means that we can indeed remove the
> HAVE_LIMITS_H macro.

Houra!!! We spoke about that bloody change for a complete day.

> I am not sure it will change anything, though.

This one in particular not much indeed. But it's one less configure test that
consumes times.

Abdel.

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

> "younes" == younes a <[EMAIL PROTECTED]> writes:

>>  Indeed. And I have checked that both qt and boost input without
>> any guard, which means that we can indeed remove the HAVE_LIMITS_H
>> macro.

younes> Houra!!! We spoke about that bloody change for a complete day.

You would have been more convincing if you did the research yourself.
For the future, I think that what boost does can be considered as a
good guideline.

What about getting rid of the stuff in support/lyxdir.h in favour of
boost stuff. I am not sure everything can go away, but it seems there
is room for cleanup.

Careful cleanup, of course :)

JMarc

Re: Getting rid of qttableview.[Ch]

[Abdelrazak Younes]

Jean-Marc Lasgouttes a écrit :

"younes" == younes a <[EMAIL PROTECTED]> writes:



 Indeed. And I have checked that both qt and boost input without
any guard, which means that we can indeed remove the HAVE_LIMITS_H
macro.


younes> Houra!!! We spoke about that bloody change for a complete day.

You would have been more convincing if you did the research yourself.


I think (not sure) I have said that the original file didn't do the test 
and that Qt is very portable so why should we?



For the future, I think that what boost does can be considered as a
good guideline.

What about getting rid of the stuff in support/lyxdir.h in favour of
boost stuff. I am not sure everything can go away, but it seems there
is room for cleanup.


Hey, that's my point since the beginning ;-)


Careful cleanup, of course :)


Sure boss. I'll try to do something next week-end. But I will not touch 
autotools stuff.


Abdel.

Re: Getting rid of qttableview.[Ch]

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "younes" == younes a <[EMAIL PROTECTED]> writes:
| 
| >>  Indeed. And I have checked that both qt and boost input without
| >> any guard, which means that we can indeed remove the HAVE_LIMITS_H
| >> macro.
| 
| younes> Houra!!! We spoke about that bloody change for a complete day.
| 
| You would have been more convincing if you did the research yourself.
| For the future, I think that what boost does can be considered as a
| good guideline.
| 
| What about getting rid of the stuff in support/lyxdir.h in favour of
| boost stuff. I am not sure everything can go away, but it seems there
| is room for cleanup.

support/lyxdir.h?

-- 
Lgb

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:

Abdelrazak> I think (not sure) I have said that the original file
Abdelrazak> didn't do the test and that Qt is very portable so why
Abdelrazak> should we?

Yes, but the file was not part of qt itself, and I was suspicious it
might not be as portable as the rest. My fault, I admit.

>> For the future, I think that what boost does can be considered as a
>> good guideline. What about getting rid of the stuff in
>> support/lyxdir.h in favour of boost stuff. I am not sure everything
>> can go away, but it seems there is room for cleanup.

Abdelrazak> Hey, that's my point since the beginning ;-)

So, why don't you do that first? mkdir should be too difficult to get
right, for a start :)

JMarc

Re: Getting rid of qttableview.[Ch]

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| 
| Abdelrazak> I think (not sure) I have said that the original file
| Abdelrazak> didn't do the test and that Qt is very portable so why
| Abdelrazak> should we?
| 
| Yes, but the file was not part of qt itself, and I was suspicious it
| might not be as portable as the rest. My fault, I admit.
| 
| >> For the future, I think that what boost does can be considered as a
| >> good guideline. What about getting rid of the stuff in
| >> support/lyxdir.h in favour of boost stuff. I am not sure everything
| >> can go away, but it seems there is room for cleanup.
| 
| Abdelrazak> Hey, that's my point since the beginning ;-)
| 
| So, why don't you do that first? mkdir should be too difficult to get
| right, for a start :)

Actually that one is troublesome... last time I checked boost have no
way of setting the mode for the created dir.

And... the easy way to change these functions is not to change the
header files, at least not initally, but just change the
implementation.

And if possible add a test to support/tests

-- 
Lgb

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> support/lyxdir.h?

Sorry. support/lyxlib.h. I think most of it is covered by boost, isn't
it?

JMarc

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> Actually that one is troublesome... last time I checked boost
Lars> have no way of setting the mode for the created dir.

What mode does it use? I see we use either 700 or 777, why is that?

We could just rely on umask, couldn't we? I remember a discussion on
this subject, but not the outcome.

Lars> And... the easy way to change these functions is not to change
Lars> the header files, at least not initally, but just change the
Lars> implementation.

Or not use the function at all, but rather boost directly?

JMarc

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Actually that one is troublesome... last time I checked boost
Lars> have no way of setting the mode for the created dir.

Jean-Marc> What mode does it use? I see we use either 700 or 777, why
Jean-Marc> is that?

Answering to myself:

I see boost only uses 777. We need 700 to avoid making our temp files
readable/writeable to other users.

JMarc

Re: Getting rid of qttableview.[Ch]

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> support/lyxdir.h?
| 
| Sorry. support/lyxlib.h. I think most of it is covered by boost, isn't
| it?

getcwd
rename¹
copy
unlink
mkdir²

¹ boost::rename might not be good enough, our falls back to copy if
the files reside on different filesystems.

² boost::mkdir does not take a mode argument, and thus is not really
usable for us.

-- 
Lgb

Re: Getting rid of qttableview.[Ch]

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| Lars> And... the easy way to change these functions is not to change
| Lars> the header files, at least not initally, but just change the
| Lars> implementation.
| 
| Or not use the function at all, but rather boost directly?

I would prefere just the implementation initially, then it is clearly
localized, and you change all callers at once.

-- 
Lgb

Re: Getting rid of qttableview.[Ch]

[Lars Gullik Bjønnes]

Abdelrazak Younes [EMAIL PROTECTED] writes:

| Abdel.
| Index: qttableview.C
| ===
| --- qttableview.C (revision 13796)
| +++ qttableview.C (working copy)
| @@ -1,36 +1,24 @@
|  /**
| -** $Id: qttableview.C,v 1.7 2005/04/26 10:30:22 leeming Exp $
| +** $Id: qttableview.cpp,v 1.1.1.9 2005/09/22 12:53:59 chehrlic Exp $
|  **
|  ** Implementation of QtTableView class
|  **
|  ** Created : 941115
|  **
| -** Copyright (C) 1992-2000 Trolltech AS.  All rights reserved.
| +** Copyright (C) 1992-2005 Trolltech AS.  All rights reserved.
|  **
|  ** This file contains a class moved out of the Qt GUI Toolkit API. It
|  ** may be used, distributed and modified without limitation.
|  **
|  **/
|  
| -#include config.h
| -

If this is compiled in LyX space, do not remove config.h

Note that even the boost .cpp files get compiled with config.h


-- 
Lgb

Re: Getting rid of qttableview.[Ch]

[Lars Gullik Bjønnes]

Abdelrazak Younes <[EMAIL PROTECTED]> writes:

| Abdel.
| Index: qttableview.C
| ===
| --- qttableview.C (revision 13796)
| +++ qttableview.C (working copy)
| @@ -1,36 +1,24 @@
|  /**
| -** $Id: qttableview.C,v 1.7 2005/04/26 10:30:22 leeming Exp $
| +** $Id: qttableview.cpp,v 1.1.1.9 2005/09/22 12:53:59 chehrlic Exp $
|  **
|  ** Implementation of QtTableView class
|  **
|  ** Created : 941115
|  **
| -** Copyright (C) 1992-2000 Trolltech AS.  All rights reserved.
| +** Copyright (C) 1992-2005 Trolltech AS.  All rights reserved.
|  **
|  ** This file contains a class moved out of the Qt GUI Toolkit API. It
|  ** may be used, distributed and modified without limitation.
|  **
|  **/
|  
| -#include 
| -

If this is compiled in LyX space, do not remove 

Note that even the boost .cpp files get compiled with 


-- 
Lgb

Re: Getting rid of qttableview.[Ch]

[Abdelrazak Younes]

Abdelrazak Younes a écrit :
I see that qttableview in current lyx code is exactly the same as the 
one in my local Qt3Win tree except for the include of config.h and the 
test on HAVE_LIMITS_H. This change was done at revision 9876 by Angus 
with the following log:


Consistent use of preprocessor guards;
include config.h in .C files, not .h ones;
licence blurb.

This class was supposed to be obsoleted after Qt3.0 but I see that it is 
in my Qt3Win tree. Is it also there on the official Qt3 distribution? If 
yes, we should just use it and remove the copy from src/frontends/qt3/


This is yes apparently but as stated in 
http://doc.trolltech.com/3.3/porting.html#20 the class is probably not 
compiled in the library.


By the way, there is not any explanation as to why testing for 
HAVE_LIMITS_H have been introduced in svn history. I think it is again a 
gettext need.
I guess it is OK if I revert qttableview to the official version without 
the macro test, isn't it?


The following patch do so and removes limits.h from pch.h (they are just 
a bunch of macro anyway so there is _no_ need to precompile it).


Abdel.
Index: moc/pch.h
===
--- moc/pch.h   (revision 13796)
+++ moc/pch.h   (working copy)
@@ -15,9 +15,6 @@
 #include algorithm
 #include cmath
 #include iomanip
-#ifdef HAVE_LIMITS_H
-# include limits.h
-#endif
 #include map
 #include sstream
 #include stack
Index: pch.h
===
--- pch.h   (revision 13796)
+++ pch.h   (working copy)
@@ -15,9 +15,6 @@
 #include algorithm
 #include cmath
 #include iomanip
-#ifdef HAVE_LIMITS_H
-# include limits.h
-#endif
 #include map
 #include sstream
 #include stack
Index: qttableview.C
===
--- qttableview.C   (revision 13796)
+++ qttableview.C   (working copy)
@@ -1,36 +1,24 @@
 /**
-** $Id: qttableview.C,v 1.7 2005/04/26 10:30:22 leeming Exp $
+** $Id: qttableview.cpp,v 1.1.1.9 2005/09/22 12:53:59 chehrlic Exp $
 **
 ** Implementation of QtTableView class
 **
 ** Created : 941115
 **
-** Copyright (C) 1992-2000 Trolltech AS.  All rights reserved.
+** Copyright (C) 1992-2005 Trolltech AS.  All rights reserved.
 **
 ** This file contains a class moved out of the Qt GUI Toolkit API. It
 ** may be used, distributed and modified without limitation.
 **
 **/
 
-#include config.h
-
 #include qttableview.h
 #ifndef QT_NO_QTTABLEVIEW
 #include qscrollbar.h
 #include qpainter.h
+#include qdrawutil.h
+#include limits.h
 
-#ifdef HAVE_LIMITS_H
-# include limits.h
-#endif
-
-/* Added by J. Levon for compilation with Qt 2.3.1 */
-#ifndef Q_CHECK_PTR
-#define Q_CHECK_PTR CHECK_PTR
-#endif
-#ifndef Q_ASSERT
-#define Q_ASSERT ASSERT
-#endif
-
 enum ScrollBarDirtyFlags {
 verGeometry  = 0x01,
 verSteps = 0x02,
@@ -67,7 +55,7 @@
 
 
 // NOT REVISED
-/*!
+/*
   \class QtTableView qttableview.h
   \brief The QtTableView class provides an abstract base for tables.
 
@@ -135,7 +123,7 @@
 */
 
 
-/*!
+/*
   Constructs a table view.  The \a parent, \a name and \f arguments
   are passed to the QFrame constructor.
 
@@ -176,7 +164,7 @@
 inSbUpdate  = FALSE;
 }
 
-/*!
+/*
   Destroys the table view.
 */
 
@@ -188,7 +176,7 @@
 }
 
 
-/*!
+/*
   \internal
   Reimplements QWidget::setBackgroundColor() for binary compatibility.
   \sa setPalette()
@@ -199,7 +187,7 @@
 QWidget::setBackgroundColor( c );
 }
 
-/*!\reimp
+/*\reimp
 */
 
 void QtTableView::setPalette( const QPalette p )
@@ -207,7 +195,7 @@
 QWidget::setPalette( p );
 }
 
-/*!\reimp
+/*\reimp
 */
 
 void QtTableView::show()
@@ -217,12 +205,12 @@
 }
 
 
-/*!
+/*
   \overload void QtTableView::repaint( bool erase )
   Repaints the entire view.
 */
 
-/*!
+/*
   Repaints the table view directly by calling paintEvent() directly
   unless updates are disabled.
 
@@ -259,20 +247,20 @@
 eraseInPaint = FALSE;
 }
 
-/*!
+/*
   \overload void QtTableView::repaint( const QRect r, bool erase )
   Replaints rectangle \a r. If \a erase is TRUE draws the background
   using the palette's background.
 */
 
 
-/*!
+/*
   \fn int QtTableView::numRows() const
   Returns the number of rows in the table.
   \sa numCols(), setNumRows()
 */
 
-/*!
+/*
   Sets the number of rows of the table to \a rows (must be non-negative).
   Does not change topCell().
 
@@ -308,13 +296,13 @@
 updateFrameSize();
 }
 
-/*!
+/*
   \fn int QtTableView::numCols() const
   Returns the number of columns in the table.
   \sa numRows(), setNumCols()
 */
 
-/*!
+/*
   Sets the number of columns of the table to \a cols (must be non-negative).
   Does not change leftCell().
 
@@ -346,14 +334,14 @@
 }
 
 
-/*!
+/*
   \fn int QtTableView::topCell() const
   Returns the index of the first row in the table 

Re: Getting rid of qttableview.[Ch]

[Georg Baum]

Abdelrazak Younes wrote:

 This class was supposed to be obsoleted after Qt3.0 but I see that it is
 in my Qt3Win tree. Is it also there on the official Qt3 distribution?

No. The last relase that contains it was 3.0 according to
http://doc.trolltech.com.

 If 
 yes, we should just use it and remove the copy from src/frontends/qt3/

That was my thought too after I read your first post about qttableview.h,
but it is not possible.


Georg

Re: Getting rid of qttableview.[Ch]

[Abdelrazak Younes]

Georg Baum a écrit :

Abdelrazak Younes wrote:


This class was supposed to be obsoleted after Qt3.0 but I see that it is
in my Qt3Win tree. Is it also there on the official Qt3 distribution?


No. The last relase that contains it was 3.0 according to
http://doc.trolltech.com.

If 
yes, we should just use it and remove the copy from src/frontends/qt3/


That was my thought too after I read your first post about qttableview.h,
but it is not possible.


It is there in src/attic/ of Qt-3.3 as well as qtmultilineedit. See my 
other post.


Abdel.

Re: Getting rid of qttableview.[Ch]

[Georg Baum]

Abdelrazak Younes wrote:

 It is there in src/attic/ of Qt-3.3 as well as qtmultilineedit. See my
 other post.

That does not help. I am not going to compile my own qt but use the one SuSE
provides, and that does not contain it.


Georg

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

 Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:

Abdelrazak I see that qttableview in current lyx code is exactly the
Abdelrazak same as the one in my local Qt3Win tree except for the
Abdelrazak include of config.h and the test on HAVE_LIMITS_H. This
Abdelrazak change was done at revision 9876 by Angus with the
Abdelrazak following log:

Abdelrazak Consistent use of preprocessor guards; include config.h
Abdelrazak in .C files, not .h ones; licence blurb.

So you should look at what happened to qttableview.h at the same time.
At some time Angus did a lot of work to move config.h use to .C files.

JMarc

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

 Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:

Abdelrazak By the way, there is not any explanation as to why testing
Abdelrazak for HAVE_LIMITS_H have been introduced in svn history. I
Abdelrazak think it is again a gettext need. 

This has nothing todo with gettext. Some systems have the constants, but
not in limits.h.

JMarc

Re: Getting rid of qttableview.[Ch]

[Abdelrazak Younes]

Jean-Marc Lasgouttes a écrit :

Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:


Abdelrazak I see that qttableview in current lyx code is exactly the
Abdelrazak same as the one in my local Qt3Win tree except for the
Abdelrazak include of config.h and the test on HAVE_LIMITS_H. This
Abdelrazak change was done at revision 9876 by Angus with the
Abdelrazak following log:

Abdelrazak Consistent use of preprocessor guards; include config.h
Abdelrazak in .C files, not .h ones; licence blurb.

So you should look at what happened to qttableview.h at the same time.
At some time Angus did a lot of work to move config.h use to .C files.


Nothing happened to qttableview.h only to qttableview.C. qttableview.h 
is the verbatim copy of december 2001; so this is not a move of config.h 
to qttableview.C but a creation.


Abdel.

Re: Getting rid of qttableview.[Ch]

[Abdelrazak Younes]

Georg Baum a écrit :

Abdelrazak Younes wrote:


It is there in src/attic/ of Qt-3.3 as well as qtmultilineedit. See my
other post.


That does not help. I am not going to compile my own qt but use the one SuSE
provides, and that does not contain it.


Of course it doesn't help, I am proposing to update the copy to the 
current version (included in Qt3.3 source).


You guys make a big story about a grain of salt.

Abdel.

Re: Getting rid of qttableview.[Ch]

[Angus Leeming]

Abdelrazak Younes [EMAIL PROTECTED] writes:
 Of course it doesn't help, I am proposing to update the copy to the 
 current version (included in Qt3.3 source).

 You guys make a big story about a grain of salt.

The file in question is deprecated by Qt and exists in our sources as a band-aid
so that code that was written before the deprecation continues to work. All of a
sudden, and for the first time in four years, someone (you) has got interested
in its existence. Perhaps, now is the time to remove the band aid entirely and
fix the underlying code to do it the Qt way.

Angus

Re: Getting rid of qttableview.[Ch]

[Abdelrazak Younes]

Angus Leeming a écrit :

Abdelrazak Younes [EMAIL PROTECTED] writes:
Of course it doesn't help, I am proposing to update the copy to the 
current version (included in Qt3.3 source).



You guys make a big story about a grain of salt.


The file in question is deprecated by Qt and exists in our sources as a band-aid
so that code that was written before the deprecation continues to work. All of a
sudden, and for the first time in four years, someone (you) has got interested
in its existence. Perhaps, now is the time to remove the band aid entirely and
fix the underlying code to do it the Qt way.


Year, I figured out the story already. Porting the code to Qt3 using 
QTable should not be very hard. Any takers?
Personally I'd rather reserve my rare resources to Qt4 porting (which 
use QTableWidget in this case).


Abdel.

Re: Getting rid of qttableview.[Ch]

[Abdelrazak Younes]

Abdelrazak Younes a écrit :
I see that qttableview in current lyx code is exactly the same as the 
one in my local Qt3Win tree except for the include of  and the 
test on HAVE_LIMITS_H. This change was done at revision 9876 by Angus 
with the following log:


Consistent use of preprocessor guards;
include  in .C files, not .h ones;
licence blurb.

This class was supposed to be obsoleted after Qt3.0 but I see that it is 
in my Qt3Win tree. Is it also there on the official Qt3 distribution? If 
yes, we should just use it and remove the copy from src/frontends/qt3/


This is yes apparently but as stated in 
 the class is probably not 
compiled in the library.


By the way, there is not any explanation as to why testing for 
HAVE_LIMITS_H have been introduced in svn history. I think it is again a 
gettext need.
I guess it is OK if I revert qttableview to the official version without 
the macro test, isn't it?


The following patch do so and removes limits.h from pch.h (they are just 
a bunch of macro anyway so there is _no_ need to precompile it).


Abdel.
Index: moc/pch.h
===
--- moc/pch.h   (revision 13796)
+++ moc/pch.h   (working copy)
@@ -15,9 +15,6 @@
 #include 
 #include 
 #include 
-#ifdef HAVE_LIMITS_H
-# include 
-#endif
 #include 
 #include 
 #include 
Index: pch.h
===
--- pch.h   (revision 13796)
+++ pch.h   (working copy)
@@ -15,9 +15,6 @@
 #include 
 #include 
 #include 
-#ifdef HAVE_LIMITS_H
-# include 
-#endif
 #include 
 #include 
 #include 
Index: qttableview.C
===
--- qttableview.C   (revision 13796)
+++ qttableview.C   (working copy)
@@ -1,36 +1,24 @@
 /**
-** $Id: qttableview.C,v 1.7 2005/04/26 10:30:22 leeming Exp $
+** $Id: qttableview.cpp,v 1.1.1.9 2005/09/22 12:53:59 chehrlic Exp $
 **
 ** Implementation of QtTableView class
 **
 ** Created : 941115
 **
-** Copyright (C) 1992-2000 Trolltech AS.  All rights reserved.
+** Copyright (C) 1992-2005 Trolltech AS.  All rights reserved.
 **
 ** This file contains a class moved out of the Qt GUI Toolkit API. It
 ** may be used, distributed and modified without limitation.
 **
 **/
 
-#include 
-
 #include "qttableview.h"
 #ifndef QT_NO_QTTABLEVIEW
 #include "qscrollbar.h"
 #include "qpainter.h"
+#include "qdrawutil.h"
+#include 
 
-#ifdef HAVE_LIMITS_H
-# include 
-#endif
-
-/* Added by J. Levon for compilation with Qt 2.3.1 */
-#ifndef Q_CHECK_PTR
-#define Q_CHECK_PTR CHECK_PTR
-#endif
-#ifndef Q_ASSERT
-#define Q_ASSERT ASSERT
-#endif
-
 enum ScrollBarDirtyFlags {
 verGeometry  = 0x01,
 verSteps = 0x02,
@@ -67,7 +55,7 @@
 
 
 // NOT REVISED
-/*!
+/*
   \class QtTableView qttableview.h
   \brief The QtTableView class provides an abstract base for tables.
 
@@ -135,7 +123,7 @@
 */
 
 
-/*!
+/*
   Constructs a table view.  The \a parent, \a name and \f arguments
   are passed to the QFrame constructor.
 
@@ -176,7 +164,7 @@
 inSbUpdate  = FALSE;
 }
 
-/*!
+/*
   Destroys the table view.
 */
 
@@ -188,7 +176,7 @@
 }
 
 
-/*!
+/*
   \internal
   Reimplements QWidget::setBackgroundColor() for binary compatibility.
   \sa setPalette()
@@ -199,7 +187,7 @@
 QWidget::setBackgroundColor( c );
 }
 
-/*!\reimp
+/*\reimp
 */
 
 void QtTableView::setPalette( const QPalette  )
@@ -207,7 +195,7 @@
 QWidget::setPalette( p );
 }
 
-/*!\reimp
+/*\reimp
 */
 
 void QtTableView::show()
@@ -217,12 +205,12 @@
 }
 
 
-/*!
+/*
   \overload void QtTableView::repaint( bool erase )
   Repaints the entire view.
 */
 
-/*!
+/*
   Repaints the table view directly by calling paintEvent() directly
   unless updates are disabled.
 
@@ -259,20 +247,20 @@
 eraseInPaint = FALSE;
 }
 
-/*!
+/*
   \overload void QtTableView::repaint( const QRect , bool erase )
   Replaints rectangle \a r. If \a erase is TRUE draws the background
   using the palette's background.
 */
 
 
-/*!
+/*
   \fn int QtTableView::numRows() const
   Returns the number of rows in the table.
   \sa numCols(), setNumRows()
 */
 
-/*!
+/*
   Sets the number of rows of the table to \a rows (must be non-negative).
   Does not change topCell().
 
@@ -308,13 +296,13 @@
 updateFrameSize();
 }
 
-/*!
+/*
   \fn int QtTableView::numCols() const
   Returns the number of columns in the table.
   \sa numRows(), setNumCols()
 */
 
-/*!
+/*
   Sets the number of columns of the table to \a cols (must be non-negative).
   Does not change leftCell().
 
@@ -346,14 +334,14 @@
 }
 
 
-/*!
+/*
   \fn int QtTableView::topCell() const
   Returns the index of the first row in the table that is visible in
   the view.  The index of the first row is 0.
   \sa leftCell(), setTopCell()
 */
 
-/*!
+/*
   

Re: Getting rid of qttableview.[Ch]

[Georg Baum]

Abdelrazak Younes wrote:

> This class was supposed to be obsoleted after Qt3.0 but I see that it is
> in my Qt3Win tree. Is it also there on the official Qt3 distribution?

No. The last relase that contains it was 3.0 according to
http://doc.trolltech.com.

> If 
> yes, we should just use it and remove the copy from src/frontends/qt3/

That was my thought too after I read your first post about qttableview.h,
but it is not possible.


Georg

Re: Getting rid of qttableview.[Ch]

[Abdelrazak Younes]

Georg Baum a écrit :

Abdelrazak Younes wrote:


This class was supposed to be obsoleted after Qt3.0 but I see that it is
in my Qt3Win tree. Is it also there on the official Qt3 distribution?


No. The last relase that contains it was 3.0 according to
http://doc.trolltech.com.

If 
yes, we should just use it and remove the copy from src/frontends/qt3/


That was my thought too after I read your first post about qttableview.h,
but it is not possible.


It is there in src/attic/ of Qt-3.3 as well as qtmultilineedit. See my 
other post.


Abdel.

Re: Getting rid of qttableview.[Ch]

[Georg Baum]

Abdelrazak Younes wrote:

> It is there in src/attic/ of Qt-3.3 as well as qtmultilineedit. See my
> other post.

That does not help. I am not going to compile my own qt but use the one SuSE
provides, and that does not contain it.


Georg

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:

Abdelrazak> I see that qttableview in current lyx code is exactly the
Abdelrazak> same as the one in my local Qt3Win tree except for the
Abdelrazak> include of  and the test on HAVE_LIMITS_H. This
Abdelrazak> change was done at revision 9876 by Angus with the
Abdelrazak> following log:

Abdelrazak> Consistent use of preprocessor guards; include 
Abdelrazak> in .C files, not .h ones; licence blurb.

So you should look at what happened to qttableview.h at the same time.
At some time Angus did a lot of work to move config.h use to .C files.

JMarc

Re: Getting rid of qttableview.[Ch]

[Jean-Marc Lasgouttes]

> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:

Abdelrazak> By the way, there is not any explanation as to why testing
Abdelrazak> for HAVE_LIMITS_H have been introduced in svn history. I
Abdelrazak> think it is again a gettext need. 

This has nothing todo with gettext. Some systems have the constants, but
not in limits.h.

JMarc

Re: Getting rid of qttableview.[Ch]

[Abdelrazak Younes]

Jean-Marc Lasgouttes a écrit :

"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:


Abdelrazak> I see that qttableview in current lyx code is exactly the
Abdelrazak> same as the one in my local Qt3Win tree except for the
Abdelrazak> include of  and the test on HAVE_LIMITS_H. This
Abdelrazak> change was done at revision 9876 by Angus with the
Abdelrazak> following log:

Abdelrazak> Consistent use of preprocessor guards; include 
Abdelrazak> in .C files, not .h ones; licence blurb.

So you should look at what happened to qttableview.h at the same time.
At some time Angus did a lot of work to move config.h use to .C files.


Nothing happened to qttableview.h only to qttableview.C. qttableview.h 
is the verbatim copy of december 2001; so this is not a move of config.h 
to qttableview.C but a creation.


Abdel.

Re: Getting rid of qttableview.[Ch]

[Abdelrazak Younes]

Georg Baum a écrit :

Abdelrazak Younes wrote:


It is there in src/attic/ of Qt-3.3 as well as qtmultilineedit. See my
other post.


That does not help. I am not going to compile my own qt but use the one SuSE
provides, and that does not contain it.


Of course it doesn't help, I am proposing to update the copy to the 
current version (included in Qt3.3 source).


You guys make a big story about a grain of salt.

Abdel.

Re: Getting rid of qttableview.[Ch]

[Angus Leeming]

Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Of course it doesn't help, I am proposing to update the copy to the 
> current version (included in Qt3.3 source).

> You guys make a big story about a grain of salt.

The file in question is deprecated by Qt and exists in our sources as a band-aid
so that code that was written before the deprecation continues to work. All of a
sudden, and for the first time in four years, someone (you) has got interested
in its existence. Perhaps, now is the time to remove the band aid entirely and
fix the underlying code to do it the "Qt way".

Angus

Re: Getting rid of qttableview.[Ch]

[Abdelrazak Younes]

Angus Leeming a écrit :

Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Of course it doesn't help, I am proposing to update the copy to the 
current version (included in Qt3.3 source).



You guys make a big story about a grain of salt.


The file in question is deprecated by Qt and exists in our sources as a band-aid
so that code that was written before the deprecation continues to work. All of a
sudden, and for the first time in four years, someone (you) has got interested
in its existence. Perhaps, now is the time to remove the band aid entirely and
fix the underlying code to do it the "Qt way".


Year, I figured out the story already. Porting the code to Qt3 using 
QTable should not be very hard. Any takers?
Personally I'd rather reserve my rare resources to Qt4 porting (which 
use QTableWidget in this case).


Abdel.