I see.
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Michael Schnell wrote:
> So MSE-GUI creates it's own Widget set instead of using something like
> GTK. Is this really advantageous ?
Definitely - depending on your needs. That's the whole reason we started
fpGUI Toolkit as well. LCL, GTK, etc simply did not do what we needed.
In creating our own
I did not yet try or consider to use the "GUI" part of MSEGUJI, as my
intention is about doing embedded stuff (e.g. with NoGUIApplication). So
sorry for may ignorance about this seemingly already thoroughly
discussed issue.
___
fpc-devel maillist - fpc-
I see that this should not be discussed here :) . Thanks !
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Fri, 13 Nov 2009, Martin Schreiber wrote:
On Friday 13 November 2009 15:58:10 Michael Schnell wrote:
So MSE-GUI creates it's own Widget set instead of using something like
GTK. Is this really advantageous ?
Michael, you are joking, right? ;-)
Please join us on NNTP:
news://news.grid-sky.
On Friday 13 November 2009 15:58:10 Michael Schnell wrote:
> So MSE-GUI creates it's own Widget set instead of using something like
> GTK. Is this really advantageous ?
>
Michael, you are joking, right? ;-)
Please join us on NNTP:
news://news.grid-sky.com/public.mseide-msegui.talk
to get answers t
2009/11/13 Michael Van Canneyt :
>
>
> On Fri, 13 Nov 2009, Michael Schnell wrote:
>
>> So MSE-GUI creates it's own Widget set instead of using something like
>> GTK. Is this really advantageous ?
>
> Oh boy, this promises to start a long thread...
>
> ... which Jonas is likely to end if he gets fe
On Fri, 13 Nov 2009, Michael Schnell wrote:
So MSE-GUI creates it's own Widget set instead of using something like
GTK. Is this really advantageous ?
Oh boy, this promises to start a long thread...
... which Jonas is likely to end if he gets fed up with it :-)
Michael.
So MSE-GUI creates it's own Widget set instead of using something like
GTK. Is this really advantageous ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Zitat von Martin Schreiber :
On Friday 13 November 2009 13:26:29 Graeme Geldenhuys wrote:
Michael Schnell wrote:
> Martin Schreiber wrote:
>> On Linux xlib and xft have utf-16 interfaces.
>
> What exactly are xlib and xft and why does MSE-GUI seemingly use those
> while LCL seemingly uses somet
On Friday 13 November 2009 13:26:29 Graeme Geldenhuys wrote:
> Michael Schnell wrote:
> > Martin Schreiber wrote:
> >> On Linux xlib and xft have utf-16 interfaces.
> >
> > What exactly are xlib and xft and why does MSE-GUI seemingly use those
> > while LCL seemingly uses something else ?
>
> Marti
Michael Schnell wrote:
> Martin Schreiber wrote:
>> On Linux xlib and xft have utf-16 interfaces.
>
> What exactly are xlib and xft and why does MSE-GUI seemingly use those
> while LCL seemingly uses something else ?
Martin answered this already. But just to be clear, xlib and xft have
both utf-8
On Friday 13 November 2009 12:51:58 Michael Schnell wrote:
> Martin Schreiber wrote:
> > On Linux xlib and xft have utf-16 interfaces.
>
> What exactly are xlib and xft and why does MSE-GUI seemingly use those
> while LCL seemingly uses something else ?
>
xlib is the C-library used under Linux to c
Martin Schreiber wrote:
>>
> On Linux xlib and xft have utf-16 interfaces.
What exactly are xlib and xft and why does MSE-GUI seemingly use those
while LCL seemingly uses something else ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.or
On Friday 13 November 2009 10:16:46 Michael Schnell wrote:
>
> Why should the (future) lcl use "ANSIString". I suppose using ANSIString
> for UTF-8 data was just a nasty hack to do Unicode with the _current_
> FPC. (In contrast the MSE-GUI hack was using Widestring, which is less
> ambiguous and se
Florian Klaempfl wrote:
> Well, I guess you're talking about lazarus ;) I don't see yet however,
> if and how the ansistring abuse in the lcl will bite one ...
Why should the (future) lcl use "ANSIString". I suppose using ANSIString
for UTF-8 data was just a nasty hack to do Unicode with the _curr
Martin Schreiber wrote:
UnicodeString
- always utf-16 encoded.
- str:= 'abc'; length(str) = 6, stringcodepage(str) = 1200.
- str:= 'abä'; length(str) = 6, stringcodepage(str) = 1200.
- no encoding checks by concanteation, concatenation does not work because of
wrong length() value.
- setlength(
On Fri, Nov 13, 2009 at 12:55 AM, Florian Klaempfl
wrote:
> Well, I guess you're talking about lazarus ;) I don't see yet however,
> if and how the ansistring abuse in the lcl will bite one ...
not really. But it's good to know that LCL is safe as well :)
thanks,
dmitry
__
dmitry boyarintsev schrieb:
> On Fri, Nov 13, 2009 at 12:44 AM, Florian Klaempfl
> wrote:
>> Well, an ansistring has an implicit encoding: system. This won't change
>> and if one uses only unicodestrings and ansistrings, no change will be
>> noticed.
>
> Thanks. It's always nice to hear "No chang
On Fri, Nov 13, 2009 at 12:44 AM, Florian Klaempfl
wrote:
> Well, an ansistring has an implicit encoding: system. This won't change
> and if one uses only unicodestrings and ansistrings, no change will be
> noticed.
Thanks. It's always nice to hear "No changes required" :)
> No, because it would
dmitry boyarintsev schrieb:
> On Thu, Nov 12, 2009 at 9:26 PM, Florian Klaempfl
> wrote:
>> Ansistring: system encoding
>> RawByteString: variable encoding, cannot be checked at compile time,
>> when working with RawByteStrings, you've to take care of the newly
>> introduced encoding field
>
> Le
On Thu, Nov 12, 2009 at 9:26 PM, Florian Klaempfl
wrote:
> Ansistring: system encoding
> RawByteString: variable encoding, cannot be checked at compile time,
> when working with RawByteStrings, you've to take care of the newly
> introduced encoding field
Let's say there's a library that works wit
Martin Schreiber schrieb:
> On Thursday 12 November 2009 19:26:06 Florian Klaempfl wrote:
>>> What are the differences of AnsiString and RawByteString?
>> Ansistring: system encoding
>
> System encoding at compile time or run time?
Runtime, as it is currently.
On Thursday 12 November 2009 19:26:06 Florian Klaempfl wrote:
> > What are the differences of AnsiString and RawByteString?
>
> Ansistring: system encoding
System encoding at compile time or run time?
___
fpc-devel maillist - fpc-devel@lists.freepascal
Martin Schreiber schrieb:
> On Tuesday 10 November 2009 10:33:07 Florian Klaempfl wrote:
>>> So please don't destroy this ideal solution by dropping current FPC
>>> UnicodeString in favour of the Delphi string which is complicated,
>> Who says that? If you don't mess with code pages, the only diffe
On Tuesday 10 November 2009 10:33:07 Florian Klaempfl wrote:
> >
> > So please don't destroy this ideal solution by dropping current FPC
> > UnicodeString in favour of the Delphi string which is complicated,
>
> Who says that? If you don't mess with code pages, the only different
> you'll might see
On 10 Nov 2009, at 15:05, Felipe Monteiro de Carvalho wrote:
But for GUI software the conversion speed impact is tiny, and the
head-ache caused be a string type whose encoding is not know is by far
much worse. Tons of string related code will stop working and need to
be adapted at the gain of a
On Tue, Nov 10, 2009 at 7:33 AM, Florian Klaempfl
wrote:
>>
>> - There is only one encoding in MSEgui framework, it is the same on all
>> platforms.
>
> Which is performance wise neither a good decision.
Could be, if are writing a specialized command line tool or something like that.
But for GUI
I don't see why using D2009 strings would hurt that much.
If there is a compiler option to encode string constants as utf-16 or
maybe an additional plain 16 Bit String type, that encoding would
automatically be used for the "Strings" and thus all have the same
encodings and in fact are reference c
In our previous episode, Martin Schreiber said:
> - The current FPC UnicodeString is fast, simple, has little overhead and is
> well tested.
Do you have any benchmark data on the overhead that delphi adds ? Because I
don't think it is much slower if all strings are initialized on the same
encodin
>
> - There is only one encoding in MSEgui framework, it is the same on all
> platforms.
Which is performance wise neither a good decision.
> - In the majority of cases the fast and convenient character access by index
> can be used. This is important for beginners.
> - The current FPC Unicode
31 matches
Mail list logo
