On Wed, Feb 28, 2007 at 10:57:06AM +0100, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Andre> Seems to be a small price compared to maintaining ugly code
> Andre> ourselves. Most notably when the 2 MB come from a wildly used
> Andre> library that's u
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Seems to be a small price compared to maintaining ugly code
Andre> ourselves. Most notably when the 2 MB come from a wildly used
Andre> library that's usually loaded even on 'hostile' systems (like
Andre> those running a Gnome deskt
Andre Poenitz wrote:
int QLPainter::text(int x, int y, char_type c, LyXFont const & f)
{
- char_type s[2] = { c, char_type('\0') };
- return text(x, y, s, 1, f);
+ docstring s(c, 1);
+ return text(x, y, s, f);
}
This was in the fast path a while ago. Not sure it still
On Mon, Feb 26, 2007 at 11:14:16PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Sun, Feb 25, 2007 at 10:33:21PM +0100, Lars Gullik Bjønnes wrote:
> | > And by not keeping such function is src/frontends/qt4 you have make it
> | > impossible to resurrect/beg
On Mon, Feb 26, 2007 at 06:19:56PM +0100, Jean-Marc Lasgouttes wrote:
> Michael> From my point of view, QtCore is just another library like
> Michael> boost, aspell, whatever.
>
> Not really, because we link with 2Mb of code just for the pleasure of
> having a couple unicode support functions.
S
On Mon, Feb 26, 2007 at 04:14:31PM +0100, Abdelrazak Younes wrote:
> --- lyx-devel/trunk/src/frontends/qt4/QLPainter.C (original)
> +++ lyx-devel/trunk/src/frontends/qt4/QLPainter.C Mon Feb 26 16:13:08 2007
> @@ -170,16 +170,10 @@
> }
>
>
> -int QLPainter::text(int x, int y, docstring const & s,
Lars Gullik Bjønnes wrote:
The question is how you organize the usage, not that we use it.
I don't understand what you propose Lars. I made a proposal; say yes,
say no, say perhaps... elaborate!
Abdel.
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
| >> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > Abdelrazak> What I think Michael mean (and I agree with him) is that
| > Abdelrazak> we should keep GUI related code separated from the unicode
| >
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> What I think Michael mean (and I agree with him) is that
Abdelrazak> we should keep GUI related code separated from the unicode
Abdelrazak> utilities. I proposed 'gui' and 'support' subdirector
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Feb 26, 2007 at 12:59:46AM +0100, Lars Gullik Bjønnes wrote:
| > (The biggest problem qith Qt afaik is that is based on a old release
| > of the unicode standard.)
|
| Unless you elaborate I am tempted to call this 'FUD'.
Sure.
--
Lgb
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sun, Feb 25, 2007 at 10:33:21PM +0100, Lars Gullik Bjønnes wrote:
| > And by not keeping such function is src/frontends/qt4 you have make it
| > impossible to resurrect/begin another frontend without doing surgery
| > to core code. (if src/support can
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> That sounds like a wonderful solution. Are you volunteering?
Bennett> ;)
It would be surprising. But I may have access to a mac at home
sometimes soon, so I might be able to work more on the mac port.
JMarc
Andre Poenitz wrote:
> On Mon, Feb 26, 2007 at 12:59:46AM +0100, Lars Gullik Bjønnes wrote:
>> (The biggest problem qith Qt afaik is that is based on a old release
>> of the unicode standard.)
>
> Unless you elaborate I am tempted to call this 'FUD'.
>
> Andre'
>
Nice thread --- Lars is back.
On Mon, Feb 26, 2007 at 12:59:46AM +0100, Lars Gullik Bjønnes wrote:
> (The biggest problem qith Qt afaik is that is based on a old release
> of the unicode standard.)
Unless you elaborate I am tempted to call this 'FUD'.
Andre'
On Sun, Feb 25, 2007 at 10:33:21PM +0100, Lars Gullik Bjønnes wrote:
> And by not keeping such function is src/frontends/qt4 you have make it
> impossible to resurrect/begin another frontend without doing surgery
> to core code. (if src/support can be deemed such)
I don't see a conceptional proble
On Sun, Feb 25, 2007 at 10:10:33PM +0100, Lars Gullik Bjønnes wrote:
> Have we now ditched the thought of being able to use different
> frontends completely out?
> It is now impossible to create tests on string conversion without
> linking with Qt.
We are considering Qt as a general purpose librar
On Feb 26, 2007, at 1:05 PM, Jean-Marc Lasgouttes wrote:
If someone decides to port LyX to native Cocoa interface (like
Camino versus Firefox) you will have a hard time convincing him
that he should depend on QtCore.
Abdelrazak> Not forced but he will probably find it convenient to use
Abdelra
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> What I think Michael mean (and I agree with him) is that
Abdelrazak> we should keep GUI related code separated from the unicode
Abdelrazak> utilities. I proposed 'gui' and 'support' subdirectories
Abdelrazak> in a prev
Jean-Marc Lasgouttes wrote:
"Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
If you insist on this I can move the stuff to frontend/, but there
are more serious problems to fix IMHO.
Michael> Please don't do that! Unicode has nothing to do with GUI!
But frontend is not only about GUI i
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Georg Baum schrieb:
>> I would really prefer to wait with that until it is really needed,
>> because it could well be that we may need a slightly different
>> interface when a second frontend is actually implemented.
Michael> Wh
Georg Baum wrote:
Abdelrazak Younes wrote:
I did not read the "font" bit correctly. I thought it was only about the
simple cast ucs4 to uft16 warning. Now that we use (for Qt4.2) a real
conversion, how does this comment applies?
The conversion in the relevant range for symbol fonts (0..255) i
Abdelrazak Younes wrote:
> I did not read the "font" bit correctly. I thought it was only about the
> simple cast ucs4 to uft16 warning. Now that we use (for Qt4.2) a real
> conversion, how does this comment applies?
The conversion in the relevant range for symbol fonts (0..255) is still a
simple
Georg Baum schrieb:
I would really prefer to wait with
that until it is really needed, because it could well be that we may need a
slightly different interface when a second frontend is actually
implemented.
Which may happen in fall 2083... :-)
If you insist on this I can move the stuff to f
Georg Baum wrote:
Abdelrazak Younes wrote:
-int QLPainter::text(int x, int y, char_type const * s, size_t ls,
- LyXFont const & f)
-{
- // Caution: The following ucs4_to_qstring conversion works for
- // symbol fonts only because it is no real conversion but a simple
- // cast i
Abdelrazak Younes wrote:
> -int QLPainter::text(int x, int y, char_type const * s, size_t ls,
> - LyXFont const & f)
> -{
> - // Caution: The following ucs4_to_qstring conversion works for
> - // symbol fonts only because it is no real conversion but a simple
> - // cast in reality
Georg Baum wrote:
Abdelrazak Younes wrote:
I was about to erase the ucs4_to_qstring() method entirely instead. What
do you think?
Fine with me. I never liked it anyway :-) The patch was only meant for quick
testing.
Done:
Author: younes
Date: Mon Feb 26 16:13:08 2007
New Revision: 17362
UR
Georg Baum wrote:
Abdelrazak Younes wrote:
I was about to erase the ucs4_to_qstring() method entirely instead. What
do you think?
Fine with me. I never liked it anyway :-) The patch was only meant for quick
testing.
OK, I'll do a small bit of cleaning then.
Abdel.
Abdelrazak Younes wrote:
> I was about to erase the ucs4_to_qstring() method entirely instead. What
> do you think?
Fine with me. I never liked it anyway :-) The patch was only meant for quick
testing.
Georg
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
The conversion method for qt < 4.1 is missing because you optimized it
away (iconv was too slow on windows).
I meant the _Qt_ conversion method (toUcs4()).
Yes, that is indeed missing up to 4.1.x.
What I wrote above is only true
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> The conversion method for qt < 4.1 is missing because you optimized it
>> away (iconv was too slow on windows).
>
> I meant the _Qt_ conversion method (toUcs4()).
Yes, that is indeed missing up to 4.1.x.
>> What I wrote above is only true for the
Lars Gullik Bjønnes wrote:
> That Qt handles the full unicode range does not mean that you can work
> with a single codepoint-entiry for every char.
But does that matter for us? IMHO not: In the core we can do that with
docstring and char_type, and all we need from qt is correct handling of
unico
Georg Baum wrote:
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Perhaps the bigggest problem then is the lack of a 32-bit codepoint.
That's not true since at least Qt 4.2 (they've added QString::toUcs4()
there).
qt can handle the whole unicode range since 4.0, but they store it in 1
Georg Baum <[EMAIL PROTECTED]> writes:
| Do you think that we need to do this now? I would really prefer to wait with
| that until it is really needed, because it could well be that we may need a
| slightly different interface when a second frontend is actually
| implemented. If you insist on this
Abdelrazak Younes wrote:
> Lars Gullik Bjønnes wrote:
>> Perhaps the bigggest problem then is the lack of a 32-bit codepoint.
>
> That's not true since at least Qt 4.2 (they've added QString::toUcs4()
> there).
qt can handle the whole unicode range since 4.0, but they store it in 16 bit
utf16 e
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Still this would be an additional dependency for each of the
| frontends. I reckon that the new qt4 based helper that Georg created
| can be very easily ported to any library. So, IMHO, we should use what
| qt provides for free.
Sure use what Qt pro
Lars Gullik Bjønnes wrote:
> Using qt does not mean that qt has to reside in src/support. It should
> go in some abstraction impl lib _in_ src/frontends/qt
Do you think that we need to do this now? I would really prefer to wait with
that until it is really needed, because it could well be that we
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| And by letting qt out of src/frontends/qt really is a breach of
| contract
I thought I should up the temperature a bit :-)
--
Lgb
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| How does linking with ICU in support is cleaner that linking with
| QtCore? Remember that only QtCore features are used here.
Not much perhaps, but icu would be usable with qt,xforms,gtk,curses
whatever.
Still this wou
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| How does linking with ICU in support is cleaner that linking with
| QtCore? Remember that only QtCore features are used here.
Not much perhaps, but icu would be usable with qt,xforms,gtk,curses
whatever.
| If you are scared about the potential dang
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Why do we have to load anything into Qt? I thought Qt already
| Lars> had this information?
|
| We do not load anything into Qt, but use the QChar::category facility.
|
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Georg Baum wrote:
| > Lars Gullik Bjønnes wrote:
| >
|
| >> And thus begins the downward slope.
| >> And by not keeping such function is src/frontends/qt4 you have make it
| >> impossible to resurrect/begin another frontend without doing surgery
|
Lars Gullik Bjønnes wrote:
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> And thus begins the downward slope.
|
| While this decision was taken for pragmatic and reasonable reasons, I
| agree there is a risk.
|
|
Georg Baum wrote:
Lars Gullik Bjønnes wrote:
And thus begins the downward slope.
And by not keeping such function is src/frontends/qt4 you have make it
impossible to resurrect/begin another frontend without doing surgery
to core code. (if src/support can be deemed such)
[Georg reasoning]
J
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Why do we have to load anything into Qt? I thought Qt already
Lars> had this information?
We do not load anything into Qt, but use the QChar::category facility.
Lars> If not we should look harder at ICU, because it has the ta
Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | > "Lars" == Lars Gullik Bjønnes
> | > <[EMAIL PROTECTED]> writes:
> |
> | Lars> Have we now ditched the thought of being able to use different
> | Lars> frontends completely out?
> |
> | We have agreed t
On Sun, 25 Feb 2007, Lars Gullik Bjønnes wrote:
| Lars> Have we now ditched the thought of being able to use different
| Lars> frontends completely out?
|
| We have agreed to rely on qt for special cases where reporducing the
| qt functionality would be horrible.
And thus begins the downward
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> And thus begins the downward slope.
|
| While this decision was taken for pragmatic and reasonable reasons, I
| agree there is a risk.
|
| Lars> And by not keeping such
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> And thus begins the downward slope.
While this decision was taken for pragmatic and reasonable reasons, I
agree there is a risk.
Lars> And by not keeping such function is src/frontends/qt4 you have
Lars> make it impossible to
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Have we now ditched the thought of being able to use different
| Lars> frontends completely out?
|
| We have agreed to rely on qt for special cases where reporducing the
|
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Have we now ditched the thought of being able to use different
Lars> frontends completely out?
We have agreed to rely on qt for special cases where reporducing the
qt functionality would be horrible. Currently this is for conve
50 matches
Mail list logo
