> On Sun, Jul 28, 2002 at 02:24:46PM +1000, Amir Michail wrote:
> > We are working on a design recovery tool for
> > interactive graphical applications.
>
> Hey, cool project. I had much a similar idea to help me learn lyx
> internals a while ago, but it was of a much smaller scope, and I
> never
<>
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Monday 29 July 2002 1:22 am, David Kastrup wrote:
> > Sorry, we are still in the 0.7.3 cleanup and redocumentation cycle and
> > have not yet reached release maturity. In the course of that, I have
> > tried figuring out what goes wrong with things
On Mon, Jul 29, 2002 at 04:31:00PM +0200, Andre Poenitz wrote:
> >From what was being said I assumed that one has to copy the content.
> That might be wrong, but then, who owns the 'char *' returned by latin1()
> and if it is the QString, what happens if it gets destroyed?
The first thing I do w
On Mon, Jul 29, 2002 at 04:24:21PM +0200, Lars Gullik Bjønnes wrote:
> | And why don't you use
> >
> | std::string mystr = selectedFile().latin1();
>
> That will work.
> ... unless .latin1() can return NULL.
Ah yes... I tend to forget these things...
Andre'
--
Those who desire to give up Fre
On Mon, Jul 29, 2002 at 03:22:19PM +0100, John Levon wrote:
> > std::string mystr = selectedFile().latin1();
>
> Why bother ? data() is just as good ...
>From what was being said I assumed that one has to copy the content.
That might be wrong, but then, who owns the 'char *' returned by latin1(
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Jul 29, 2002 at 10:02:23AM -0400, Kuba Ober wrote:
>> It does return a null terminated char const *, although please notice that
>> this pointer may point to garbage on any subsequent line of your code, if the
>> source QString was destroyed.
On Mon, Jul 29, 2002 at 04:13:48PM +0200, Andre Poenitz wrote:
> std::string mystr = selectedFile().latin1();
Why bother ? data() is just as good ...
john
--
"The simpler it is, the harder it is."
- Tim Van Holder
On Mon, Jul 29, 2002 at 04:03:11PM +0200, Lars Gullik Bjønnes wrote:
> Depends on how much needs to be reevaluated to regure out the rows and
> columns...
Even then you'd probably need -O3 on g++ to get it actually inlined...
Andre'
--
Those who desire to give up Freedom in order to gain Secur
Kuba Ober <[EMAIL PROTECTED]> writes:
| On Åroda 24 lipiec 2002 04:10 am, Angus Leeming wrote:
>> On Wednesday 24 July 2002 7:25 am, Lars Gullik Bjønnes wrote:
>> > Just make sure that QString::data is required to retrun a
>> > null-terminated char const *.
>>
>> const char* data() const { retu
On Mon, Jul 29, 2002 at 10:02:23AM -0400, Kuba Ober wrote:
> It does return a null terminated char const *, although please notice that
> this pointer may point to garbage on any subsequent line of your code, if the
> source QString was destroyed.
>
> Thus, I'd always do this (unless I'm the on
On Mon, Jul 29, 2002 at 10:02:23AM -0400, Kuba Ober wrote:
> char mybuf[512];
not necessary
regards
john
--
"The simpler it is, the harder it is."
- Tim Van Holder
> if the class function rows() is an inline version that is just
> returning an int... then I prefere the for(... tabular->rows() ...)
> version.
int rows() const { return rows_; }
On poniedziałek 29 lipiec 2002 09:59 am, Edwin Leuven wrote:
> ...completely unrelated and just wondering what the experts say.
>
> How about:
>
> for(int i = 0; i < tabular->rows(); ++i) {
> for(int j = 0; j < tabular->columns(); ++j) {
>
>
> as opposed to:
>
> int const r = tabular->rows();
Edwin Leuven <[EMAIL PROTECTED]> writes:
| ...completely unrelated and just wondering what the experts say.
>
| How about:
>
| for(int i = 0; i < tabular->rows(); ++i) {
| for(int j = 0; j < tabular->columns(); ++j) {
>
>
| as opposed to:
>
| int const r = tabular->rows();
| int const c = ta
On Åroda 24 lipiec 2002 04:10 am, Angus Leeming wrote:
> On Wednesday 24 July 2002 7:25 am, Lars Gullik Bjønnes wrote:
> > Just make sure that QString::data is required to retrun a
> > null-terminated char const *.
>
> const char* data() const { return latin1(); }
>
> I don't have the Qt src to
On Mon, Jul 29, 2002 at 03:59:40PM +0200, Edwin Leuven wrote:
> for(int i = 0; i < tabular->rows(); ++i) {
> for(int j = 0; j < tabular->columns(); ++j) {
>
>
> as opposed to:
>
> int const r = tabular->rows();
> int const c = tabular->columns();
> for(int i = 0; i < r; ++i) {
> for(int
...completely unrelated and just wondering what the experts say.
How about:
for(int i = 0; i < tabular->rows(); ++i) {
for(int j = 0; j < tabular->columns(); ++j) {
as opposed to:
int const r = tabular->rows();
int const c = tabular->columns();
for(int i = 0; i < r; ++i) {
for(int j
On Mon, Jul 29, 2002 at 03:00:18PM +0200, Edwin Leuven wrote:
> As for the rest. From my layman's point of view lyxtext, tabular etc won't get
> the Design Pattern of the Year award, and seem as they could benefit from a
> bit of rethinking.
Well I'm a little more vertical and I'm not a huge
On Mon, Jul 29, 2002 at 03:00:18PM +0200, Edwin Leuven wrote:
> But then again, I am a layman and therefore probably very wrong...
Well. I have come to about the same conclusion but did not have the time so
far to come up with something better.
> And then I don't mention the most important thing
> If you can provide more of these examples to Jug perhaps he can do
> something, but I don't think it's a good idea for 1.2.x (yeT)
I tried to understand the drawing and updating code in insettabular but I
can't really say that the code is self documenting.
For the moment I am only thinking of
On Mon, Jul 29, 2002 at 01:31:38PM +0100, John Levon wrote:
> Most of theese over-drawings come from problems when we weren't doing
> enough updating in certai circumstances. There are corner cases where
> figuring out what needs to be repainted is hard.
I still think that we should at least have
- try to select the whole text with the mouse from lower right
to upper left
-> ok
- try it from upper left to lower right
-> it's not possible
with the cursor keys everything works fine.
Herbert
--
http://www.lyx.org/help/
#LyX 1.3 created this file. For more info see http://www.lyx.o
On Mon, Jul 29, 2002 at 12:24:53PM +0200, Edwin Leuven wrote:
> There are still some problems with the code I think. setPos/resetPos gets
> called when moving a cursor in a selected cell. And I have the impression
> that the whole table gets redrawm when selecting a (range of) cells.
> Selecti
On Mon, Jul 29, 2002 at 01:09:43PM +0200, Edwin Leuven wrote:
> >
> > It's not exactly trivial, though, as we currently can't nest math and
> > non-math insets within each other, so we can neither implement matrices
> > as tables nor vice versa, nor even use some common base to factor out code.
>
On Monday 29 July 2002 12:46, Andre Poenitz wrote:
> On Mon, Jul 29, 2002 at 12:41:03PM +0200, Edwin Leuven wrote:
> > > Which matrix?
> >
> > the one in mathed.
>
> Would be nice, indeed.
>
> It's not exactly trivial, though, as we currently can't nest math and
> non-math insets within each other
On Monday 29 July 2002 11:48 am, Andre Poenitz wrote:
> On Mon, Jul 29, 2002 at 11:09:24AM +0100, Angus Leeming wrote:
> > Yes, it supports it and I can easily turn the warning off. However, the
> > compiler is telling me that "long long" is not part of the standard and
> > that I should not, ther
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Monday 29 July 2002 10:56 am, Lars Gullik Bjønnes wrote:
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>> | Lars,
>> |
>> | have you any ideas about how to fix this set of warnings in the new boost
>> | code?
>>
>> does cxx support "long long" or not?
On Mon, Jul 29, 2002 at 11:09:24AM +0100, Angus Leeming wrote:
> Yes, it supports it and I can easily turn the warning off. However, the
> compiler is telling me that "long long" is not part of the standard and that
> I should not, therefore, be using it. So, I might rephrase my original
> ques
On Mon, Jul 29, 2002 at 12:41:03PM +0200, Edwin Leuven wrote:
> > Which matrix?
>
> the one in mathed.
Would be nice, indeed.
It's not exactly trivial, though, as we currently can't nest math and
non-math insets within each other, so we can neither implement matrices
as tables nor vice versa, n
On Monday 29 July 2002 10:56 am, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | Lars,
> |
> | have you any ideas about how to fix this set of warnings in the new boost
> | code?
>
> does cxx support "long long" or not?
Yes, it supports it and I can easily turn the warn
On Monday 29 July 2002 1:22 am, David Kastrup wrote:
> Sorry, we are still in the 0.7.3 cleanup and redocumentation cycle and
> have not yet reached release maturity. In the course of that, I have
> tried figuring out what goes wrong with things like seminar.sty.
> Well, they set \mag. Ugh.
>
>
> Which matrix?
the one in mathed.
On Mon, Jul 29, 2002 at 12:24:53PM +0200, Edwin Leuven wrote:
> I guess there is still work to be done. Which makes me wonder about the
> following: shouldn't tabular and matrix be build on the same codebase?
Which matrix?
Andre'
--
Those who desire to give up Freedom in order to gain Securit
> Edwin, are you satisfied with performance now?
It's a bit better now.
There are still some problems with the code I think. setPos/resetPos gets
called when moving a cursor in a selected cell. And I have the impression
that the whole table gets redrawm when selecting a (range of) cells.
Sel
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars,
>
| have you any ideas about how to fix this set of warnings in the new boost
| code?
does cxx support "long long" or not?
It is do support it, than I cannoth fathom why it complains... do yo
have a switch turned on that you shouldn't?
| cxx:
Lars,
have you any ideas about how to fix this set of warnings in the new boost
code?
Angus
cxx -std strict_ansi -DHAVE_CONFIG_H -I. -I../../../devel/src/mathed
-I../../src -I../../../devel/src/mathed/../ -I../../../devel/boost
-I/usr/local/include -nopure_cname -nocleanup -msg_display_numbe
37 matches
Mail list logo
