Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> So each and every Attribute change will have a full entry in the
> Attribute list, with full instantiation of every Attributes: Font,
> Language, CT, purple markers, etc. This means an awful lot of
> redundancies and this will soon become a nightma
On Mon, Oct 29, 2007 at 07:36:12PM +0100, Abdelrazak Younes wrote:
> In my mind there would be only three: Font, Language and Change Traking;
> I am not a proponent of charstyle as attributes. But even though I was,
> implementing them generically should be doable.
>
>> I think I prefer the notion
On Mon, Oct 29, 2007 at 12:30:42PM +0100, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
>> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>>> If you mean an unified interface for Paragraph then I'd agree. The
>>> Range template I am talking about would be private to Paragraph. Then,
>>> if
On Mon, Oct 29, 2007 at 11:33:03AM +0100, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
>> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>>> Basically, the current FontList will be a specialisation of this
>>> template:
>>>
>>> typedef Range FontList;
>>>
>>> And we need the same thing for
Andre Poenitz wrote:
On Sun, Oct 28, 2007 at 09:37:02PM +0100, Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Sun, Oct 28, 2007 at 08:05:10PM +0100, Abdelrazak Younes
wrote:
Anyway, I think the language and font information should not be
in the same class. I don't understand why we are force
On Sun, Oct 28, 2007 at 09:37:02PM +0100, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
>> On Sun, Oct 28, 2007 at 08:05:10PM +0100, Abdelrazak Younes wrote:
>>> Anyway, I think the language and font information should not be in the
>>> same class. I don't understand why we are forced to set a f
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> OK, then we just need some interface methods that would give that
> information by looking up the inner independent ranges, ex:
>
> struct AttributeRange {
> pos_type start;
> pos_type end;
> FontInfo font;
> Change change;
>
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
If you mean an unified interface for Paragraph then I'd agree. The
Range template I am talking about would be private to Paragraph. Then,
if we could have:
CharAttributes Paragraph::getAttributes(pos_type)
that will r
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> If you mean an unified interface for Paragraph then I'd agree. The
> Range template I am talking about would be private to Paragraph. Then,
> if we could have:
>
> CharAttributes Paragraph::getAttributes(pos_type)
>
> that will replace Paragraph::g
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> This basically means that we rename FontInfo to Font, Font to AttrList
> and that we integrate Change tracking in there... or am I
> misunderstanding you?
Something like that. But it is just an idea.
>> I think an unified list like that would help
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Basically, the current FontList will be a specialisation of this
template:
typedef Range FontList;
And we need the same thing for languages:
typedef Range LanguageList;
Ideas, comments?
I think I'd prefer to have a
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Basically, the current FontList will be a specialisation of this
template:
typedef Range FontList;
And we need the same thing for languages:
typedef Range LanguageList;
Ideas, comments?
I think I'd prefer to have a
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Basically, the current FontList will be a specialisation of this
> template:
>
> typedef Range FontList;
>
> And we need the same thing for languages:
>
> typedef Range LanguageList;
>
> Ideas, comments?
I think I'd prefer to have a AttrList object
Abdelrazak Younes wrote:
Dov Feldstern wrote:
Abdelrazak Younes wrote:
PS: Dov, there could be some problems with this last commit and bidi
support. I've tried hard to only change the interfaces and to
maintain the logic but bugs happen. Please let me know if there's
anything wrong.
Abdel.
Dov Feldstern wrote:
Abdelrazak Younes wrote:
PS: Dov, there could be some problems with this last commit and bidi
support. I've tried hard to only change the interfaces and to maintain
the logic but bugs happen. Please let me know if there's anything wrong.
Abdel.
Hmm, yes, there are: it l
Dov Feldstern wrote:
Abdelrazak Younes wrote:
PS: Dov, there could be some problems with this last commit and bidi
support. I've tried hard to only change the interfaces and to maintain
the logic but bugs happen. Please let me know if there's anything wrong.
Abdel.
Hmm, yes, there are: it l
Abdelrazak Younes wrote:
PS: Dov, there could be some problems with this last commit and bidi
support. I've tried hard to only change the interfaces and to maintain
the logic but bugs happen. Please let me know if there's anything wrong.
Abdel.
Hmm, yes, there are: it looks like the language
Dov Feldstern wrote:
Abdelrazak Younes wrote:
Dov Feldstern wrote:
Abdelrazak Younes wrote:
PS: Dov, there could be some problems with this last commit and bidi
support. I've tried hard to only change the interfaces and to
maintain the logic but bugs happen. Please let me know if there's
a
Abdelrazak Younes wrote:
Dov Feldstern wrote:
Abdelrazak Younes wrote:
PS: Dov, there could be some problems with this last commit and bidi
support. I've tried hard to only change the interfaces and to
maintain the logic but bugs happen. Please let me know if there's
anything wrong.
Yea
Martin Vermeer wrote:
On Sun, Oct 28, 2007 at 08:05:10PM +0100, Abdelrazak Younes wrote:
Anyway, I think the language and font information should not be in the
same class. I don't understand why we are forced to set a font when we
only want to set the language for example. What we need is a t
Dov Feldstern wrote:
Edwin Leuven wrote:
Dov Feldstern wrote:
ATM it doesn't compile, though, so it's hard to test it ;) .
compiles here...
not here... Linux, g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
My fault, sorry. It's fixed now.
Abdel.
Andre Poenitz wrote:
On Sun, Oct 28, 2007 at 08:05:10PM +0100, Abdelrazak Younes wrote:
Anyway, I think the language and font information should not be in the same
class. I don't understand why we are forced to set a font when we only want
to set the language for example. What we need is a temp
On Sun, Oct 28, 2007 at 08:05:10PM +0100, Abdelrazak Younes wrote:
> Anyway, I think the language and font information should not be in the same
> class. I don't understand why we are forced to set a font when we only want
> to set the language for example. What we need is a templated 'Range' cla
Dov Feldstern wrote:
Abdelrazak Younes wrote:
PS: Dov, there could be some problems with this last commit and bidi
support. I've tried hard to only change the interfaces and to maintain
the logic but bugs happen. Please let me know if there's anything wrong.
Yeah, I'm sitting here cringin
Edwin Leuven wrote:
Dov Feldstern wrote:
ATM it doesn't compile, though, so it's hard to test it ;) .
compiles here...
not here... Linux, g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE
-DQT_GENUINE_ST
R -DQT_NO_STL
Dov Feldstern wrote:
ATM it doesn't compile, though, so it's hard to test it ;) .
compiles here...
Abdelrazak Younes wrote:
Hello,
I've just split the Font class in saner bits:
* Font::FontBits -> FontInfo
* Font::FONT_XXX -> all enums transfered to FontEnums.h and renamed to
FontXxx
I've replaced Font uses with FontInfo were the language() member was not
needed, basically all draw() and
On Sun, Oct 28, 2007 at 08:05:10PM +0100, Abdelrazak Younes wrote:
> Hello,
>
> I've just split the Font class in saner bits:
>
> * Font::FontBits -> FontInfo
> * Font::FONT_XXX -> all enums transfered to FontEnums.h and renamed to
> FontXxx
>
> I've replaced Font uses with FontInfo were the la
Hello,
I've just split the Font class in saner bits:
* Font::FontBits -> FontInfo
* Font::FONT_XXX -> all enums transfered to FontEnums.h and renamed to
FontXxx
I've replaced Font uses with FontInfo were the language() member was not
needed, basically all draw() and metrics methods.
There wa
29 matches
Mail list logo
