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
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 -
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 see.
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:
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
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.org
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
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 ?
Martin answered
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 and
Zitat von Martin Schreiber fp...@bluewin.ch:
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
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
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.
2009/11/13 Michael Van Canneyt mich...@freepascal.org:
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
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 to
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 is that
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 different
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 -
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 Thu, Nov 12, 2009 at 9:26 PM, Florian Klaempfl
flor...@freepascal.org 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
dmitry boyarintsev schrieb:
On Thu, Nov 12, 2009 at 9:26 PM, Florian Klaempfl
flor...@freepascal.org 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
On Fri, Nov 13, 2009 at 12:44 AM, Florian Klaempfl
flor...@freepascal.org 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,
dmitry boyarintsev schrieb:
On Fri, Nov 13, 2009 at 12:44 AM, Florian Klaempfl
flor...@freepascal.org 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
On Fri, Nov 13, 2009 at 12:55 AM, Florian Klaempfl
flor...@freepascal.org 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
- 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
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
encoding
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
On Tue, Nov 10, 2009 at 7:33 AM, Florian Klaempfl
flor...@freepascal.org 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
28 matches
Mail list logo
