Yes. Changing the theme fixes the problem. It seems that the "windows11"
theme is the only one with this issue.
On Mon, Jul 8, 2024 at 4:49 PM LyX Ticket Tracker wrote:
> #13082: Tools | Preferences | Look & Feel | Display graphics | Preview
> size box
>
On 2020-07-25 07:06, Daniel wrote:
On 2020-07-21 21:05, racoon wrote:
On 2020-07-21 21:04, Stephan Witt wrote:
Am 21.07.2020 um 06:31 schrieb Daniel mailto:xraco...@gmx.de>>:
In my copy of master all layout icons look like the Default icon.
Anyone else seeing this (attached)?
Daniel
On 2020-07-21 21:05, racoon wrote:
On 2020-07-21 21:04, Stephan Witt wrote:
Am 21.07.2020 um 06:31 schrieb Daniel mailto:xraco...@gmx.de>>:
In my copy of master all layout icons look like the Default icon.
Anyone else seeing this (attached)?
Daniel
—
No, not on my system.
Stephan
On 2020-07-21 21:04, Stephan Witt wrote:
Am 21.07.2020 um 06:31 schrieb Daniel mailto:xraco...@gmx.de>>:
In my copy of master all layout icons look like the Default icon.
Anyone else seeing this (attached)?
Daniel
—
No, not on my system.
Stephan
Thanks. Okay, maybe I just got a b
In my copy of master all layout icons look like the Default icon. Anyone
else seeing this (attached)?
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 06/11/2016 06:11 AM, Stephan Witt wrote:
> Am 29.05.2016 um 23:56 schrieb Richard Heck :
>> commit 3a2fc1595b316e0847d25b0604ec9188d953af01
>> Author: Stephan Witt
>> Date: Tue May 10 18:06:48 2016 +0200
>>
>> Correct path names were to look for RPM based
Am 29.05.2016 um 23:56 schrieb Richard Heck :
>
> commit 3a2fc1595b316e0847d25b0604ec9188d953af01
> Author: Stephan Witt
> Date: Tue May 10 18:06:48 2016 +0200
>
>Correct path names were to look for RPM based dictionaries for hunspell on
> Linux.
>
> diff --gi
Am 10.05.2016 um 18:08 schrieb Stephan Witt :
>
> commit 5c1a9063cfe95b5b4b31734d6a38ec69a142d5e6
> Author: Stephan Witt
> Date: Tue May 10 18:06:48 2016 +0200
>
>Correct path names were to look for RPM based dictionaries for hunspell on
> Linux.
>
> diff --gi
On 23/07/2015 16:45, Jean-Marc Lasgouttes wrote:
Le 23/07/2015 16:29, Richard Heck a écrit :
I wonder how bad this will be. In practice, people do not actually use
that many different words when writing. Probably no more than a few
hundred, and a couple thousand, at most.
It is not a problem o
Le 23/07/2015 16:29, Richard Heck a écrit :
I wonder how bad this will be. In practice, people do not actually use
that many different words when writing. Probably no more than a few
hundred, and a couple thousand, at most.
It is not a problem of words, it is a problem of lines of text. For
ex
Le 23/07/2015 16:19, Helge Hafting a écrit :
There are many strings - but instead the number of rows in a document is
limited. There is one entry per screen line, right? (Assuming all are
indeed different.) Even a 1000-page book will have a very limited number
of screen lines - compared to the si
uint qHash(const & docstring d) { return qHash(toqstr(d)); }
Alternatively, we could borrow the qHash code:
https://searchcode.com/codesearch/view/47469703/
From a quick look, it actually converts the QString to unicode before
operating on it:
uint qHash(const QString &key)
{
Den 23. juli 2015 10:16, skrev Jean-Marc Lasgouttes:
Except for #9691.
The big remaining problem though is that I rely on a
map for caching word widths and this will probably fill
up with long editing sessions. In the original rowpainter2 code, there
were only words in the cache, and the n
Le 23/07/2015 08:09, Jürgen Spitzmüller a écrit :
Am Donnerstag 23 Juli 2015, 00:43:35 schrieb Jean-Marc Lasgouttes:
Le 22/07/2015 17:42, Jürgen Spitzmüller a écrit :
Yes, this is with recent master. I can easily reproduce it with sec 2.5.1
of the User Guide, for instance (see attached screensh
Am Donnerstag 23 Juli 2015, 00:43:35 schrieb Jean-Marc Lasgouttes:
> Le 22/07/2015 17:42, Jürgen Spitzmüller a écrit :
> > Yes, this is with recent master. I can easily reproduce it with sec 2.5.1
> > of the User Guide, for instance (see attached screenshot).
>
> OK, try again now. Let's see how i
Le 22/07/2015 17:42, Jürgen Spitzmüller a écrit :
Yes, this is with recent master. I can easily reproduce it with sec 2.5.1 of
the User Guide, for instance (see attached screenshot).
OK, try again now. Let's see how it fares.
JMarc
Le 22/07/2015 13:34, Jürgen Spitzmüller a écrit :
Am Mittwoch 22 Juli 2015, 11:55:32 schrieb Jean-Marc Lasgouttes:
I fixed this problem. Now I am interested in any row-breaking behavior
that does not sound good.
It breaks between xref inset and closing bracket, e.g. in "(for details, cf.
[XRef
Am Mittwoch 22 Juli 2015, 11:55:32 schrieb Jean-Marc Lasgouttes:
> I fixed this problem. Now I am interested in any row-breaking behavior
> that does not sound good.
It breaks between xref inset and closing bracket, e.g. in "(for details, cf.
[XRef Inset])."
Jürgen
Le 22/07/2015 09:40, Jean-Marc Lasgouttes a écrit :
Are you interested in *any* difference in behavior I notice when
testing? For example, if a linebreak is at a different (but still
sensible) place than it was before?
No, because I am not sure that my row breaking after str-metrics was
sensibl
Le 22/07/2015 05:56, Scott Kostyshak a écrit :
On Tue, Jul 21, 2015 at 6:04 PM, Jean-Marc Lasgouttes
wrote:
I landed in master now.
I could be imagining things, but scrolling feels smoother to me.
Yes it should. The number of QPainter::drawText calls is reduced a lot
(but the strings are
On Tue, Jul 21, 2015 at 6:04 PM, Jean-Marc Lasgouttes
wrote:
> I landed in master now.
I could be imagining things, but scrolling feels smoother to me.
Are you interested in *any* difference in behavior I notice when
testing? For example, if a linebreak is at a different (but still
sensible) pl
Qt and/or STL wants to have a look
JMarc
From f76e728dbc026e54ff6bdb9d5cf7568012a148e7 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Tue, 21 Jul 2015 23:19:40 +0200
Subject: [PATCH] Use QCache to cache string width
This buys us a hash table and some LRU eviction of old strings
Richard Heck wrote:
> On 07/21/2015 09:36 AM, Scott Kostyshak wrote:
>> On Tue, Jul 21, 2015 at 8:10 AM, Jean-Marc Lasgouttes
>> wrote:
>>
>>> Basically, I'd appreciate if some people could test it so that we can
>>> see what's right and what's wrong. Since leave on thursday for vacation,
>>> the
Am 21.07.2015 um 18:04 schrieb Richard Heck :
> On 07/21/2015 09:36 AM, Scott Kostyshak wrote:
>> On Tue, Jul 21, 2015 at 8:10 AM, Jean-Marc Lasgouttes
>> wrote:
>>
>>> Basically, I'd appreciate if some people could test it so that we can see
>>> what's right and what's wrong. Since leave on thu
On 07/21/2015 09:36 AM, Scott Kostyshak wrote:
On Tue, Jul 21, 2015 at 8:10 AM, Jean-Marc Lasgouttes
wrote:
Basically, I'd appreciate if some people could test it so that we can see
what's right and what's wrong. Since leave on thursday for vacation, the
choice is between landing it now or lan
On Tue, Jul 21, 2015 at 8:10 AM, Jean-Marc Lasgouttes
wrote:
> Basically, I'd appreciate if some people could test it so that we can see
> what's right and what's wrong. Since leave on thursday for vacation, the
> choice is between landing it now or landing it in late August when I come
> back. B
Hello,
I have now done most of what I wanted on the rowpainter2 branch. When I
decided a few month ago that it would be a good JMarc Week of Code
project I thought that 2.2 would be near enough then and that this work
would be 2.3 material. Now I guess it makes more sense to land it for
2.2.
nother email address (shanxueq...@gmail.com
<mailto:shanxueq...@gmail.com>) when I registered for GSoC. I would greatly
appreciate if any prospective mentors can take a look and give me some
suggestions.
Best,
Xueqing Shan
*Xueqing Shan*
Vanderbilt Univers
;mailto:shanxueq...@gmail.com>) when I registered for GSoC. I would greatly
>> appreciate if any prospective mentors can take a look and give me some
>> suggestions.
>>
>> Best,
>> Xueqing Shan
>>
>> *Xueqing Sha
nxueq...@gmail.com
<mailto:shanxueq...@gmail.com>) when I registered for GSoC. I would greatly
appreciate if any prospective mentors can take a look and give me some
suggestions.
Best,
Xueqing Shan
*Xueqing Shan*
Vanderbilt University, '16
--
Regard
f any prospective mentors can take a
look and give me some suggestions.
Best,
Xueqing Shan
*Xueqing Shan*
Vanderbilt University, '16
Scott Kostyshak wrote:
> Looks good. Thanks for adding this. I will add stuff eventually, but
> I'm not sure when. I'm also not sure what the relationship should be
> between this doc and the README files in '/development/autotests'.
> Perhaps the README files should be for technical information,
On Sat, Feb 16, 2013 at 1:01 PM, Georg Baum
wrote:
> Scott Kostyshak wrote:
>
>> It's not possible to just use the same application that was used in
>> previous years?
>
> It is a process, not a static result.
OK.
>>> Not at the moment. Unless somebody complains I'll simply create this
>>> docum
Scott Kostyshak wrote:
> It's not possible to just use the same application that was used in
> previous years?
It is a process, not a static result.
>> Not at the moment. Unless somebody complains I'll simply create this
>> document when I'll find some time again, and if you'd like a specific
>>
On Mon, Feb 11, 2013 at 4:01 PM, Georg Baum
wrote:
> Scott Kostyshak wrote:
>
>> On Wed, Feb 6, 2013 at 3:05 PM, Georg Baum
>> wrote:
>>>
>>> This has been requested several times, but I did not find the time to
>>> write one up to now. I do not want to dump it into a hidden place where
>>> nobod
Scott Kostyshak wrote:
> On Wed, Feb 6, 2013 at 3:05 PM, Georg Baum
> wrote:
>>
>> This has been requested several times, but I did not find the time to
>> write one up to now. I do not want to dump it into a hidden place where
>> nobody will find it. Recently I had the idea of a development manu
On Sat, Feb 9, 2013 at 8:59 PM, Pavel Sanda wrote:
> Scott Kostyshak wrote:
>> Should we see if he's interested this year?
>
> Are you prepared to take the mentoring role?
Prepared in terms of time and eagerness? Yes.
Prepared in terms of ability? This depends on the specific project.
For most pr
Scott Kostyshak wrote:
> Should we see if he's interested this year?
Are you prepared to take the mentoring role?
Pavel
t;
>> No, I think the main problem was that we were not able to gain enough
>> momentum
>> to proceed with the formalities and clear goals, so no application happened.
>> If you would like to apply it's perhaps time to start organizining things...
>
> OK I will loo
momentum
> to proceed with the formalities and clear goals, so no application happened.
> If you would like to apply it's perhaps time to start organizining things...
OK I will look into the requirements and decide soon. I probably won't
do it because although I would like to spend a
Scott Kostyshak wrote:
> I think there was one student interested last year but the problem was
> that LyX wasn't accepted. Is that right?
No, I think the main problem was that we were not able to gain enough momentum
to proceed with the formalities and clear goals, so no application happened.
If
On Sat, Feb 9, 2013 at 5:43 PM, Pavel Sanda wrote:
> Scott Kostyshak wrote:
>> I wonder if this would improve chances of being accepted for Google
>> Summer of Code.
>>
>> If there's any task that you can delegate to me, I'd be happy to help.
>
> You mean you would like to apply for GSoC?
I meant
Scott Kostyshak wrote:
> I wonder if this would improve chances of being accepted for Google
> Summer of Code.
>
> If there's any task that you can delegate to me, I'd be happy to help.
You mean you would like to apply for GSoC?
Pavel
On Wed, Feb 6, 2013 at 3:05 PM, Georg Baum
wrote:
> Jean-Marc Lasgouttes wrote:
>
>> BTW, is there somewhere a description of how these test work? A readme
>> file would be nice.
>
> This has been requested several times, but I did not find the time to write
> one up to now. I do not want to dump
Jean-Marc Lasgouttes wrote:
> Le 06/02/2013 13:43, Kornel Benko a écrit :
>> tex2lyx tests:
>> 1.) Remove empty layout 'Plain'
>> 2.) Adapt to changed look of layout 'Verbatim'
>
> I am not sure (yet) whether this is a good thing. Th
Am Mittwoch, 6. Februar 2013 um 14:51:32, schrieb Jean-Marc Lasgouttes
> Le 06/02/2013 13:43, Kornel Benko a écrit :
> > tex2lyx tests:
> > 1.) Remove empty layout 'Plain'
> > 2.) Adapt to changed look of layout 'Verbatim'
>
> I am n
Le 06/02/2013 13:43, Kornel Benko a écrit :
tex2lyx tests:
1.) Remove empty layout 'Plain'
2.) Adapt to changed look of layout 'Verbatim'
I am not sure (yet) whether this is a good thing. The fact is that my
new code avoids extra empty paragraphs at the en
Lars Gullik Bj?nnes wrote:
> lar...@gullik.org (Lars Gullik Bj?nnes) writes:
> This second bundle is _really_ close to what I think could be used as a
> starting point for a git lyx repo. One thing missing is pruning of empty
> commits, and fixing up the author names that were noted as lacking last
Vincent van Ravesteijn wrote:
> I'm annoyed by the capitals only in the email address of Georg.Baum (but
> well that's nitpicking).
And I am annoyed if that address is written without capitals, since I use
that spelling since ages. If you want everything in lowercase please use the
.lyx.org add
On 10/12/2011 09:29 PM, Lars Gullik Bjønnes wrote:
> lar...@gullik.org (Lars Gullik Bjønnes) writes:
>
> | I have created a repo with basically the contents I think we should juse
> | going forward. This repo is not directly accessible, but distributed as
> | a git bundle.
>
> This second bundle is
lar...@gullik.org (Lars Gullik Bjønnes) writes:
| I have created a repo with basically the contents I think we should juse
| going forward. This repo is not directly accessible, but distributed as
| a git bundle.
This second bundle is _really_ close to what I think could be used as a
starting poi
Vincent van Ravesteijn writes:
| Op 12-10-2011 19:45, Lars Gullik Bjønnes schreef:
>> gitglossary - grafts: Grafts enables two otherwise different lines
>> of development to be joined together by recording fake ancestry
>> information for commits. This way you can make git pretend the set
>> of p
Op 12-10-2011 19:45, Lars Gullik Bjønnes schreef:
gitglossary - grafts: Grafts enables two otherwise different lines of
development to be joined together by recording fake ancestry
information for commits. This way you can make git pretend the set of
parents a commit has is different from what
Vincent van Ravesteijn writes:
>> | This worked seemingly perfekt (except for the strangish history) for
>> | 1.5.3.
>>
>> grafts does not get resolved by a clone. Seems that git-filter-branch is
>> required for that.
>
| I don't really understand the problem. In the git repo it's pretty
| easy t
lar...@gullik.org (Lars Gullik Bjønnes) writes:
| (I'll go through the other series as well and try to be really thorough)
This is the 1.4 tags:
1.4.0pre1
1.4.0pre2
1.4.0pre3
1.4.0pre4
1.4.0pre5
1.4.0pre6 - fixed by grafting
1.4.0 - fixed by grafting
1.4.1
1.4.2
1.4.3
1.4.4
1.4.5
1.4.5.1
| This worked seemingly perfekt (except for the strangish history) for
| 1.5.3.
grafts does not get resolved by a clone. Seems that git-filter-branch is
required for that.
I don't really understand the problem. In the git repo it's pretty easy
to split commits and rewrite the history right ?
lar...@gullik.org (Lars Gullik Bjønnes) writes:
| lar...@gullik.org (Lars Gullik Bjønnes) writes:
>
>
| [...]
| | Thinking... no I think I can test out grafts without major surgery. It
| | is making the grafts permanent that is a flag-day. Then it is more
| | ok-ish. Will test.
>
| This worked see
lar...@gullik.org (Lars Gullik Bjønnes) writes:
[...]
| Thinking... no I think I can test out grafts without major surgery. It
| is making the grafts permanent that is a flag-day. Then it is more
| ok-ish. Will test.
This worked seemingly perfekt (except for the strangish history) for
1.5.3.
--
Vincent van Ravesteijn writes:
>> I am inclined to ignore this difference and place the tag in the best
>> spot, instead of where it would be "correct". The diff above will then
>> added in the next commit after the 1.6.8 tag.
>
| The difference is really minor, so it would not be a problem.
>
|
1.6.8 - because the 1.6.8 branch (read: svn tag) seems to be made from
a wc with local changes. This is the diff from where I really want to
place the tag:
diff --git a/ANNOUNCE b/ANNOUNCE
index f5276aa..d8c87f7 100644
--- a/ANNOUNCE
+++ b/ANNOUNCE
@@ -70,9 +70,6 @@ want to apply one of the fo
Vincent van Ravesteijn writes:
>> Now you can look around in this repo and see what the result is like.
>
| I like it.
>
>> I know of one small mistake, I misspelled Josès surname.
>
| I'm annoyed by the capitals only in the email address of Georg.Baum
| (but well
Now you can look around in this repo and see what the result is like.
I like it.
I know of one small mistake, I misspelled Josès surname.
I'm annoyed by the capitals only in the email address of Georg.Baum (but
well that's nitpicking).
Also a couple of tags are missing, they
I have created a repo with basically the contents I think we should juse
going forward. This repo is not directly accessible, but distributed as
a git bundle.
How to get it:
download http://dl.dropbox.com/u/23498902/lyx-git-test.bundle
(223 MB)
then:
git clone
Now you can look around
> The include inset label have the tag "(embedded)". This is because we
> check the "embed" parameter for emptiness. But this parameter content is
> very bizarre IMHO, sometimes a file name, sometimes "true" or "false".
> This needs fixing...
I see. This is fixed for InsetInclude. I will have
Bo Peng wrote:
>> This one is caused by the Embedded stuff by Bo:
>
> Will fix it soon.
Fixed.
Thanks.
There is also the bug that any included file is marked as (embedded) in
the InsetInclude label, independently of the embedded status.
I do not see this here.
- New doc
- insert
> > 1. Loading open files from last session does not work.
Fixed.
Bo
> >> This one is caused by the Embedded stuff by Bo:
> >
> > Will fix it soon.
Fixed.
> There is also the bug that any included file is marked as (embedded) in
> the InsetInclude label, independently of the embedded status.
I do not see this here.
Bo
Bo Peng wrote:
> 2. Every time I open a file, save it, and open it again, it opens as
> changed, so that if I immediately close it it asks if I want to save.
This one is caused by the Embedded stuff by Bo:
Will fix it soon.
Thanks.
There is also the bug that any included file is marked a
> > 2. Every time I open a file, save it, and open it again, it opens as
> > changed, so that if I immediately close it it asks if I want to save.
>
> This one is caused by the Embedded stuff by Bo:
Will fix it soon.
Bo
Bennett Helm wrote:
On Mar 12, 2008, at 10:30 AM, Bo Peng wrote:
"A first alpha version of LyX 1.6.0 will be released later this week
for those who like the bleeding edge experience." 24/02/08
Is there any big must-have feature which we should wait for?
As far as I know, embedding wa
Anand Rangarajan wrote:
> For a while now (about a year), I've noticed that math fonts look
> fuzzy in lyx_1.4.0cvs. In contrast, they look fine for lyx_1.3.x on the
> same machine. I've attached a screenshot.
Yes, I get this too on both a FC3 i686 machine and on an Alpha runn
Maria G. wrote:
Hi -
I've set up a theme for Linux, so that application windows look
green instead of grey. LyX, however, despite being an excellent
document processor, especially for maths, still looks grey. It would
be really nice if LyX could conform to the L&F of the environme
Hi -
I've set up a theme for Linux, so that application windows look
green instead of grey. LyX, however, despite being an excellent
document processor, especially for maths, still looks grey. It would
be really nice if LyX could conform to the L&F of the environment it
is ins
Am Samstag, 25. September 2004 12:56 schrieb Lars Gullik Bjønnes:
>
> Is this all that is needed to use tex2lyx as default latex->lyx
> translator? Or are there some importer stuff that must be done as
> well?
No, this is all, but two remarks:
- if relyx is called with the -f flag, tex2lyx shoul
Is this all that is needed to use tex2lyx as default latex->lyx
translator? Or are there some importer stuff that must be done as
well?
? tex2lyx-1.diff
Index: configure.m4
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/configure
Am Freitag, 7. Februar 2003 18:11 schrieb Juergen Spitzmueller:
> http://apps.kde.com/fr/2/info/vid/8784?br=true
Sorry, misread. I actually thought Matthias himself did the announcement ;-)
(but thanks Moritz anyway)
Jürgen.
http://apps.kde.com/fr/2/info/vid/8784?br=true
Jürgen
A support function for getting the current type of change at the cursor,
needed for deciding what to do on user input
Index: src/BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.11
On Tuesday 15 October 2002 5:49 pm, Lars Gullik Bjønnes wrote:
> Did you put the same comment bout the ev->xbutton.button in
> the .C file? If not, why? That would be the correct place for
> it, and easy to find as well... If?, then why in the
> ChangeLog... just redundant information.
You're p
On Tuesday 15 October 2002 5:06 pm, Andre Poenitz wrote:
> On Tue, Oct 15, 2002 at 05:05:51PM +0100, Angus Leeming wrote:
> > I would contend that "why" does not hurt when the "what" is
> > not intuitive. Especially since you venture in here but
> > rarely and I would like some reminder of "why".
On Tue, Oct 15, 2002 at 05:05:51PM +0100, Angus Leeming wrote:
> I would contend that "why" does not hurt when the "what" is not
> intuitive. Especially since you venture in here but rarely and I
> would like some reminder of "why".
Don't ask. Just commit.
Andre'
--
Those who desire to give
On Tuesday 15 October 2002 4:48 pm, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | Here's a reasonable
> | ChangeLog entry.
>
> Not if we stick to the "what" and not the "why" in the
> Changelog.
>
> | Angus
> |
> | 2002-10-15 Angus Leeming <[EMAIL PROTECTED]>
> |
> |
On Tue, Oct 15, 2002 at 04:29:45PM +0100, Angus Leeming wrote:
> > This works very well.
>
> I'lll let you commit it when you're ready. Here's a reasonable
> ChangeLog entry.
I am ready, but I have a tree full of small changes which start going in
the "can't separate them anymore" direction...
On Tuesday 15 October 2002 4:10 pm, Andre Poenitz wrote:
> On Tue, Oct 15, 2002 at 03:57:03PM +0100, Angus Leeming wrote:
> > Perhaps you'd test it out and check that it provides you
> > with what you require.
>
> This works very well.
I'lll let you commit it when you're ready. Here's a reasonabl
On Tue, Oct 15, 2002 at 03:57:03PM +0100, Angus Leeming wrote:
> Perhaps you'd test it out and check that it provides you with
> what you require.
This works very well.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T
On Tuesday 15 October 2002 1:46 pm, Andre Poenitz wrote:
> On Tue, Oct 15, 2002 at 01:34:28PM +0100, Angus Leeming wrote:
> > On Tuesday 15 October 2002 12:52 pm, Andre Poenitz wrote:
> > I've read through the xforms source a little.
> > Were I not /still/ compiling libqt, I'd try this out for
> >
On Tuesday 15 October 2002 1:46 pm, Andre Poenitz wrote:
> On Tue, Oct 15, 2002 at 01:34:28PM +0100, Angus Leeming wrote:
> > On Tuesday 15 October 2002 12:52 pm, Andre Poenitz wrote:
> > I've read through the xforms source a little.
> > Were I not /still/ compiling libqt, I'd try this out for
> >
On Tue, Oct 15, 2002 at 02:07:29PM +0100, José Abílio Oliveira Matos wrote:
> > Last Sunday I managed to compile the xforms frontend on my best machine
> > at home within a mere 2 hours and 10 minutes. Without debug info of
> > course...
>
> I think that you should try distcc http://distcc.samb
On Tuesday 15 October 2002 13:53, Andre Poenitz wrote:
> But it was quick ;-)
>
> Last Sunday I managed to compile the xforms frontend on my best machine
> at home within a mere 2 hours and 10 minutes. Without debug info of
> course...
I think that you should try distcc http://distcc.samba.org/
On Tuesday 15 October 2002 1:53 pm, Andre Poenitz wrote:
> On Tue, Oct 15, 2002 at 01:50:33PM +0100, Angus Leeming wrote:
> > Just finished. Ouch!
>
> But it was quick ;-)
>
> Last Sunday I managed to compile the xforms frontend on my
> best machine at home within a mere 2 hours and 10 minutes.
>
On Tue, Oct 15, 2002 at 01:50:33PM +0100, Angus Leeming wrote:
> Just finished. Ouch!
But it was quick ;-)
Last Sunday I managed to compile the xforms frontend on my best machine
at home within a mere 2 hours and 10 minutes. Without debug info of
course...
Andre'
--
Those who desire to give u
On Tuesday 15 October 2002 1:46 pm, Andre Poenitz wrote:
> On Tue, Oct 15, 2002 at 01:34:28PM +0100, Angus Leeming wrote:
> > On Tuesday 15 October 2002 12:52 pm, Andre Poenitz wrote:
> > I've read through the xforms source a little.
> > Were I not /still/ compiling libqt, I'd try this out for
> >
On Tue, Oct 15, 2002 at 01:34:28PM +0100, Angus Leeming wrote:
> On Tuesday 15 October 2002 12:52 pm, Andre Poenitz wrote:
> I've read through the xforms source a little.
> Were I not /still/ compiling libqt, I'd try this out for you.
Could you please try once youve finished compiling qt?
Andre
On Tuesday 15 October 2002 12:52 pm, Andre Poenitz wrote:
> On Tue, Oct 15, 2002 at 12:41:46PM +0100, Angus Leeming wrote:
> > can you extract the info from ev->xbutton.state?
> >
> > man XButtonEvent:
> > The state member is set to indicate the logical state of
> > the pointer buttons and modifi
On Tue, Oct 15, 2002 at 12:41:46PM +0100, Angus Leeming wrote:
> can you extract the info from ev->xbutton.state?
>
> man XButtonEvent:
> The state member is set to indicate the logical state of the pointer
>buttons and modifier keys just prior to the event, which is the bitwise
>
On Tuesday 15 October 2002 12:31 pm, Andre Poenitz wrote:
> On Tue, Oct 15, 2002 at 12:26:52PM +0100, Angus Leeming wrote:
> > > No. This is 0 in any case. For further processing it would
> > > be nice if the button is know, though.
> >
> > So you're saying that we think we're passing the button i
On Tue, Oct 15, 2002 at 12:26:52PM +0100, Angus Leeming wrote:
> > No. This is 0 in any case. For further processing it would be
> > nice if the button is know, though.
>
> So you're saying that we think we're passing the button id, but
> in fact we're not because ev->xbutton.button is 0 always?
<>
t;unlock" it when I paste some
> text elsewhere in the owner with the mouse button ? How do you make sure
> asynchrnous geometry changes are propogated backwards properly ?
You've never had a look at mathed, have you? There are no 'dummy cell
positions'. Pasting is "moving
On Thu, Aug 01, 2002 at 12:08:29PM +0200, Jean-Marc Lasgouttes wrote:
> It looks nice to me and I do not have many clever comments. A question
> though: we will be adding lots of objects with virtual methods (or
> lots of virtual methods to exisiting insets). What is the price we
> will have to p
1 - 100 of 197 matches
Mail list logo
