Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sat, Jun 24, 2006 at 02:50:54PM +0200, Lars Gullik Bjønnes wrote:
| > Andre Poenitz <[EMAIL PROTECTED]> writes:
| >
| > | Depends on the phase of the moon. Just committing stuff without asking
| > | too much and not wondering too much about the discr
On Sat, Jun 24, 2006 at 02:50:54PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | Depends on the phase of the moon. Just committing stuff without asking
> | too much and not wondering too much about the discrepancy of what people
> | do themselves and what they
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Depends on the phase of the moon. Just committing stuff without asking
| too much and not wondering too much about the discrepancy of what people
| do themselves and what they require from others helped me for quite a
| while. I would be surprised if tha
On Thu, Jun 22, 2006 at 02:39:21PM -0500, Bo Peng wrote:
> >We have abondoned Coding_Rules(?) a long time ago and used 'do whatever
> >the majority in src/* does'
>
> Because it is easier to change the rules than change source code. BTW,
> the style I like is:
>
> class ThisClass
> {
> int thisF
On Fri, Jun 23, 2006 at 08:44:21AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | We have abondoned Coding_Rules(?) a long time ago and used 'do whatever
> | the majority in src/* does'
>
> No.
Have a look at the archives.
Andre'
On Fri, Jun 23, 2006 at 01:37:19PM +0200, Lars Gullik Bjønnes wrote:
> No. I am saying that we should change the code rules when we see a
> need. That might be allowing "this_is_a_variable", but that has not
> really ben discussed yet.
We could do that. A head count in src suggests a small majorit
On Fri, Jun 23, 2006 at 09:44:38AM +0200, Abdelrazak Younes wrote:
> Lars Gullik Bjønnes wrote:
> >Andre Poenitz <[EMAIL PROTECTED]> writes:
> >
> >| We have abondoned Coding_Rules(?) a long time ago and used 'do whatever
> >| the majority in src/* does'
> >
> >No.
>
> Is that an answer to a quest
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Man... isn't that what we are discussing right now? What is the
| difference between this and a "real" discussion?
Putting on the correct hat perhaps.
I have only been discussing:
- Do we have code rules
- What do they say, and do w
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Lars Gullik Bjønnes wrote:
| > | > Andre Poenitz <[EMAIL PROTECTED]> writes:
| > | > | We have abondoned Coding_Rules(?) a long time ago a
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Lars Gullik Bjønnes wrote:
| > | > Andre Poenitz <[EMAIL PROTECTED]> writes:
| > | > | We have abondoned Coding_Rules(?) a long time ago and used 'do
| > | > whatever
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Andre Poenitz <[EMAIL PROTECTED]> writes:
| > | We have abondoned Coding_Rules(?) a long time ago and used 'do
| > whatever
| > | the majority in src/* does'
| > No.
|
| Is that an answer t
Lars Gullik Bjønnes wrote:
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > We have abondoned Coding_Rules(?) a long time ago and used 'do whatever
| > the majority in src/* does'
|
| Because it is easier to change the rules than change source code. BTW,
| the style I like is:
|
| class ThisClass
|
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Andre Poenitz <[EMAIL PROTECTED]> writes:
| > | We have abondoned Coding_Rules(?) a long time ago and used 'do
| > whatever
| > | the majority in src/* does'
| > No.
|
| Is that an answer to a question, an imperative a
On Friday 23 June 2006 08:44, Abdelrazak Younes wrote:
> Does your "No" weight more than our three "Yes"?
That is one of the privileges of the BDFL (python jargon).
> The weather is hot today...
Foggy around here, so not much. But then we always expected our lost king to
appear in a foggy m
Lars Gullik Bjønnes wrote:
Andre Poenitz <[EMAIL PROTECTED]> writes:
| We have abondoned Coding_Rules(?) a long time ago and used 'do whatever
| the majority in src/* does'
No.
Is that an answer to a question, an imperative an definitive "No" or
just your opinion?
I think that changing the
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > We have abondoned Coding_Rules(?) a long time ago and used 'do whatever
| > the majority in src/* does'
|
| Because it is easier to change the rules than change source code. BTW,
| the style I like is:
|
| class ThisClass
| {
| int thisFunction();
|
|
Andre Poenitz <[EMAIL PROTECTED]> writes:
| We have abondoned Coding_Rules(?) a long time ago and used 'do whatever
| the majority in src/* does'
No.
--
Lgb
We have abondoned Coding_Rules(?) a long time ago and used 'do whatever
the majority in src/* does'
Because it is easier to change the rules than change source code. BTW,
the style I like is:
class ThisClass
{
int thisFunction();
private:
int m_member;
}
int g_someGlobalStuff;
Bo
On Tue, Jun 20, 2006 at 12:52:29PM +0200, Lars Gullik Bjønnes wrote:
> | FWIW, I agree with Andre virtual functions in the public interface of
> | classes is a very nice and powerful feature of C++. I use it a lot.
>
> Well, using NVI does not reduce the powerfullness of the feature IMHO.
It does
On Mon, Jun 19, 2006 at 09:42:59PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | And to not try to force Lars making changes. We'd end up with ideas like
> | 'do not use virtual functions in the public interface of classes' and a
> | free demonstration that it
On Mon, Jun 19, 2006 at 09:45:13PM +0200, Lars Gullik Bjønnes wrote:
> | In src/*?
> |
> | I wait for your counting.
> |
> | I posted the result of mine.
>
> Are you saying that 30 vs 15 is conclusive?
In this country you can change any law you wish with such a majority.
Apart from that, about
On Mon, Jun 19, 2006 at 09:41:57PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Mon, Jun 19, 2006 at 05:48:29PM +0200, Abdelrazak Younes wrote:
> | > By the way, this is written nowhere and I had the impression that
> | > "gui_instance_" style was the rul
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Andre Poenitz <[EMAIL PROTECTED]> writes:
| > | And to not try to force Lars making changes. We'd end up with
| > ideas like
| > | 'do not use virtual functions in the public interface of classes' and a
| > | free demon
Jose' Matos wrote:
On Tuesday 20 June 2006 09:21, Abdelrazak Younes wrote:
Man, we should definitely take a decision on that! Please don't let this
discussion dye.
Usually I don't point such mistakes or else I would be forced to look to my
own. ;-)
In this case I make an exception:
d
On Tuesday 20 June 2006 09:21, Abdelrazak Younes wrote:
> Man, we should definitely take a decision on that! Please don't let this
> discussion dye.
Usually I don't point such mistakes or else I would be forced to look to my
own. ;-)
In this case I make an exception:
dye != die
dye is
Andre Poenitz wrote:
On Mon, Jun 19, 2006 at 06:17:58PM +0200, Abdelrazak Younes wrote:
- Long variables are named like thisLongVariableName.
So without the trailing underscore then?
For me variables are temporary variables inside a function or variable
passed to a function. We are t
Lars Gullik Bjønnes wrote:
Andre Poenitz <[EMAIL PROTECTED]> writes:
| And to not try to force Lars making changes. We'd end up with ideas like
| 'do not use virtual functions in the public interface of classes' and a
| free demonstration that it hurts nicely (aka 'doDispatch')
Oh, but I don't
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Jun 19, 2006 at 03:11:58PM +0200, Lars Gullik Bjønnes wrote:
| > | I can't use reference because I want to be able to change work_area_
| > | at run-time. This work_area_ is not created nor deleted here so it is
| > | a _safe_ use of pointer. Fee
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Jun 19, 2006 at 06:02:52PM +0200, Lars Gullik Bjønnes wrote:
| > Perhaps the wrong heading but... from development/Code_rules/Rules:
| >
| > * Naming rules for classes
| >
| > - Use descriptive but simple and short nam
Andre Poenitz <[EMAIL PROTECTED]> writes:
| And to not try to force Lars making changes. We'd end up with ideas like
| 'do not use virtual functions in the public interface of classes' and a
| free demonstration that it hurts nicely (aka 'doDispatch')
Oh, but I don't agree.
I still belive the ab
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Jun 19, 2006 at 06:29:14PM +0200, Lars Gullik Bjønnes wrote:
| > Then it is misleading. We use the same naming scheme for member
| > functions and member variables.
|
| 'We' as in the old days?
'We' as we have documented it.
| Could well be, b
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Jun 19, 2006 at 05:48:29PM +0200, Abdelrazak Younes wrote:
| > By the way, this is written nowhere and I had the impression that
| > "gui_instance_" style was the rule in the current code. Could you
| > confirm that please because I used the "g
On Mon, Jun 19, 2006 at 06:29:14PM +0200, Lars Gullik Bjønnes wrote:
> Then it is misleading. We use the same naming scheme for member
> functions and member variables.
'We' as in the old days?
Could well be, but that does not mean that the other n-1 do.
> | Really if you look at current source
On Mon, Jun 19, 2006 at 05:48:29PM +0200, Abdelrazak Younes wrote:
> By the way, this is written nowhere and I had the impression that
> "gui_instance_" style was the rule in the current code. Could you
> confirm that please because I used the "gui_instance_" style everywhere
> already :-(
I th
On Mon, Jun 19, 2006 at 06:02:52PM +0200, Lars Gullik Bjønnes wrote:
> Perhaps the wrong heading but... from development/Code_rules/Rules:
>
> * Naming rules for classes
>
> - Use descriptive but simple and short names. For stuff specific to
> LyX
>
On Mon, Jun 19, 2006 at 06:17:58PM +0200, Abdelrazak Younes wrote:
> > - Long variables are named like thisLongVariableName.
>
> So without the trailing underscore then?
>
> For me variables are temporary variables inside a function or variable
> passed to a function. We are talking her
On Mon, Jun 19, 2006 at 03:11:58PM +0200, Lars Gullik Bjønnes wrote:
> | I can't use reference because I want to be able to change work_area_
> | at run-time. This work_area_ is not created nor deleted here so it is
> | a _safe_ use of pointer. Feel free to suggest something else that
> | retain po
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Lars Gullik Bjønnes wrote:
| > | > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > | | Do you mean this one:
| > | > | | > - Long variables are named l
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | | Do you mean this one:
| > | | > - Long variables are named like thisLongVariableName.
| > | | So without the trailing undersco
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | | Do you mean this one:
| > | | > - Long variables are named like thisLongVariableName.
| > | | So without the trailing underscore then?
| > No. Private cla
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| Do you mean this one:
|
| > - Long variables are named like thisLongVariableName.
|
| So without the trailing underscore then?
No.
Private class member variables get a _ at the end.
Where is that wr
On Sat, Jun 17, 2006 at 08:52:12AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Thu, Jun 15, 2006 at 12:39:32PM +0200, Abdelrazak Younes wrote:
> >>Minus potential compilation problems with gtk and/or xforms I think I am
> >>ready to merge my branch with trunk. Please find attached
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| > | By the way, this is written nowhere and I had the impression that
| > | "gui_instance_" style was the rule in the current code. Could you
| > | confirm that please
Abdelrazak Younes wrote:
Really if you look at current source code it is mostly this style:
class ThisIsOneClass
{
void thisIsOneMethod(OneType one_type);
OneType one_type_;
}
I think this coding style is nice as it is not misleading. So either we
update the code rules or we change t
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| By the way, this is written nowhere and I had the impression that
| "gui_instance_" style was the rule in the current code. Could you
| confirm that please because I used the "gui_instance_" style
| everywhere already :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Lars Gullik Bjønnes wrote:
| > | > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | > | Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > | | | UniqueGui
| >
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | | | UniqueGui
| > | | UniqueGuiInstance
| > | | GuiImplementation
| > | | GuiInstanc
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > Then QtGui (Oh!)
|
| I really don't like it but that's the only thing that would please you Ok.
I am not sure that I like it either but I am also unsure if we are
discussing the same thing; ref other mail.
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > Then QtGui (Oh!)
|
| I really don't like it but that's the only thing that would please you Ok.
I am not sure that I like it either but I am also unsure if we are
discussing the same thing; ref other mail.
| We kind of agreed to stay wit
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| | Index: src/frontends/gtk/GView.h
| | ===
| | --- src/frontends/gtk/GView.h (revision 14120)
| | +++ src/frontends/gtk/GView.h (working copy)
| | @@ -12,9 +12,12 @@
| | #
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | | | UniqueGui
| > | | UniqueGuiInstance
| > | | GuiImplementation
| > | | GuiInstanc
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| This has nothing to do with the "theApp" global variable.
I have not mentioned TheApp one single time... only TheGui.
Man, we were talking about the "theApp" pointer! You were answering to
my remark:
| If you re
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > | LyXGui
| > | > | GuiGui
| > | > | MyGui
| > | > | MyGuiIsBig
| > | > I think I liked 'GuiInstance'
| > | | Good.
| > | | > | If you really insist I will use MainGu
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | | | UniqueGui
| > | | UniqueGuiInstance
| > | | GuiImplementation
| > | | GuiInstance
| > | | LarsGui
| > | | Ahh
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | LyXGui
| > | GuiGui
| > | MyGui
| > | MyGuiIsBig
| > I think I liked 'GuiInstance'
|
| Good.
|
| > | If you really insist I will use MainGui because the kernel won't
| > see
| > | it anyway and the rest will just u
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| | UniqueGui
| | UniqueGuiInstance
| | GuiImplementation
| | GuiInstance
| | LarsGui
|
| Ahh... you are tickling my ego.
|
| | LyXGui
| | GuiGui
| | MyGui
| | MyGuiI
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | LyXGui
| > | GuiGui
| > | MyGui
| > | MyGuiIsBig
| > I think I liked 'GuiInstance'
|
| Good.
|
| > | If you really insist I will use MainGui because the kernel won't
| > see
| > | it anyway and the rest will just use "theApp->gui()".
| > with q
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| UniqueGui
| UniqueGuiInstance
| GuiImplementation
| GuiInstance
| LarsGui
Ahh... you are tickling my ego.
;-)
| LyXGui
| GuiGui
| MyGui
| MyGuiIsBig
I think I liked 'GuiInstance'
Good.
| If you really insist I
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| | UniqueGui
| | UniqueGuiInstance
| | GuiImplementation
| | GuiInstance
| | LarsGui
|
| Ahh... you are tickling my ego.
|
| | LyXGui
| | GuiGui
| | MyGui
| | MyGuiIsBig
|
| I think I liked 'GuiI
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| UniqueGui
| UniqueGuiInstance
| GuiImplementation
| GuiInstance
| LarsGui
Ahh... you are tickling my ego.
| LyXGui
| GuiGui
| MyGui
| MyGuiIsBig
I think I liked 'GuiInstance'
| If you really insist I will use MainGui because the kernel won't see
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| > | > | + lyx::frontend::WorkArea * work_area_;
| > | > Do we want bald pointers? Even just as cache?
| > | | I can't use reference becaus
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| > | > | + lyx::frontend::WorkArea * work_area_;
| > | > Do we want bald pointers? Even just as cache?
| > | | I can't use reference because I want to be able to cha
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| | > | +lyx::frontend::WorkArea * work_area_;
| | > Do we want bald pointers? Even just as cache?
| |
| | I can't use reference because I want to be able to change work_area_
| | at run-time. This work_area_ is not
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | + lyx::frontend::WorkArea * work_area_;
| > Do we want bald pointers? Even just as cache?
|
| I can't use reference because I want to be able to change work_area_
| at run-time. This work_area_ is not created
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| | > | + lyx::frontend::WorkArea * work_area_;
| | > Do we want bald pointers? Even just as cache?
| |
| | I can't use reference because I want to be able to change work_area_
| | at run-time. This work_area_ is not created nor deleted here s
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | |// Build temporary cursor.
| > | - cmd.y = min(max(cmd.y,-1), workarea().workHeight());
| > | + cmd.y = min(max(cmd.y,-1), workarea().height());
| > spacing
|
| You mean:
|
| cmd.y = min(max(cmd.y, -1), workarea().height());
|
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| #include "frontends/Alert.h"
| +#include "frontends/Clipboard.h"
| #include "frontends/Dialogs.h"
| #include "frontends/FileDialog.h"
| #include "frontends/font_metrics.h"
| #include "frontends/LyXView.h"
| -#inc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Hello,
|
| Minus potential compilation problems with gtk and/or xforms I think I
| am ready to merge my branch with trunk. Please find attached the
| complete patch. I will wait for some green lights before applying.
|
| Abdel.
| Index: src/Buffer
Jose' Matos wrote:
On Monday 19 June 2006 09:28, Abdelrazak Younes wrote:
No. Time.
What does that that mean?
Give us (Lars ;-) time to see the changes. :-)
I thought it meant "No. Period."
I have no problem with waiting but note that I've asked Lars multiple
times for comments and he _
On Monday 19 June 2006 09:28, Abdelrazak Younes wrote:
> > No. Time.
>
> What does that that mean?
Give us (Lars ;-) time to see the changes. :-)
--
José Abílio
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > Andre Poenitz wrote:
| >> On Thu, Jun 15, 2006 at 12:39:32PM +0200, Abdelrazak Younes wrote:
| >>> Minus potential compilation problems with gtk and/or xforms I
| >>> think I am ready to merge
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Thu, Jun 15, 2006 at 12:39:32PM +0200, Abdelrazak Younes wrote:
| >> Minus potential compilation problems with gtk and/or xforms I think
| >> I am ready to merge my branch with trunk. Please fi
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > Andre Poenitz wrote:
| >> On Thu, Jun 15, 2006 at 12:39:32PM +0200, Abdelrazak Younes wrote:
| >>> Minus potential compilation problems with gtk and/or xforms I
| >>> think I am ready to merge my branch with trunk. Please
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Thu, Jun 15, 2006 at 12:39:32PM +0200, Abdelrazak Younes wrote:
| >> Minus potential compilation problems with gtk and/or xforms I think
| >> I am ready to merge my branch with trunk. Please find attached the
| >> complete
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Thu, Jun 15, 2006 at 12:39:32PM +0200, Abdelrazak Younes wrote:
Minus potential compilation problems with gtk and/or xforms I think I
am ready to merge my branch with trunk. Please find attached the
complete patch. I will wait for some green lig
Andre Poenitz wrote:
On Thu, Jun 15, 2006 at 12:39:32PM +0200, Abdelrazak Younes wrote:
Minus potential compilation problems with gtk and/or xforms I think I am
ready to merge my branch with trunk. Please find attached the complete
patch. I will wait for some green lights before applying.
Goo
On Thu, Jun 15, 2006 at 12:39:32PM +0200, Abdelrazak Younes wrote:
> Minus potential compilation problems with gtk and/or xforms I think I am
> ready to merge my branch with trunk. Please find attached the complete
> patch. I will wait for some green lights before applying.
Good boy.
> void ex
On Fri, Jun 16, 2006 at 09:16:09AM +0100, Angus Leeming wrote:
> Georg Baum wrote:
> > Enrico Forestieri wrote:
> >> Please, don't use _WIN32 in place of
> >> Q_WS_WIN when something is related
> >> to Qt. Q_WS_WIN is also defined when
> >> using a cygwin Qt/native (I mean
> >> non-X11), whereas _
Georg Baum wrote:
> Enrico Forestieri wrote:
>> Please, don't use _WIN32 in place of
>> Q_WS_WIN when something is related
>> to Qt. Q_WS_WIN is also defined when
>> using a cygwin Qt/native (I mean
>> non-X11), whereas _WIN32 is not. In
>> this case the Windows clipboard is
>> used, so I think tha
Enrico Forestieri wrote:
> Please, don't use _WIN32 in place of Q_WS_WIN when something is related
> to Qt. Q_WS_WIN is also defined when using a cygwin Qt/native (I mean
> non-X11), whereas _WIN32 is not. In this case the Windows clipboard is
> used, so I think that it should be #elif defined(Q_W
On Thu, Jun 15, 2006 at 08:48:45PM +0200, Georg Baum wrote:
> -#ifdef Q_WS_WIN
> +#elif defined(_WIN32)
> // Windows clipboard uses \r\n for lineendings, and we use \n
> - return subst(str, '\n', '\r\n');
> + return subst(str, "\n", "\r\n");
> +#else
> + return str;
> #endif
Pl
Georg Baum wrote:
Am Donnerstag, 15. Juni 2006 12:39 schrieb Abdelrazak Younes:
Hello,
Minus potential compilation problems with gtk and/or xforms I think I am
ready to merge my branch with trunk. Please find attached the complete
patch. I will wait for some green lights before applying.
I
Am Donnerstag, 15. Juni 2006 12:39 schrieb Abdelrazak Younes:
> Hello,
>
> Minus potential compilation problems with gtk and/or xforms I think I am
> ready to merge my branch with trunk. Please find attached the complete
> patch. I will wait for some green lights before applying.
I scanned the
83 matches
Mail list logo
