I think I am not explaining this right.
What I want to see is a compiler-specific extension that is used by the
string header file. This has zero effect on the code you write to use
std::string. The use of the extension is hidden inside the header file,
which was provided with the compiler.
What reasons do you have for thinking std::string is no good for utf8
strings? In fact it works quite well for them.
The trick is to realize that the character encoding is irrelevant. Think
of bytes only. Only a display algorithim should have to think about
anything other than bytes.
MacArthur, Ian (SELEX GALILEO, UK [EMAIL PROTECTED] writes:
With that being said,
FLTK is nice, fast, a bit unstable and experimental - but definitely
usable.
You are using fltk-2 IIRC? If you find it a bit unstable and
experimental for your needs, you should maybe give fltk-1 a
matthiasm [EMAIL PROTECTED] writes:
I would go even further and not only copy the label, but also pre-
store wrapping information, graphical elements (@-notation), and the
position of possible shortcut-underscores. It would make the
HelpWidget a hudred times faster and speed up the
On 1 Sep 2008, at 21:23, Brian wrote:
You are using fltk-2 IIRC? If you find it a bit unstable and
experimental for your needs, you should maybe give fltk-1 a spin
too -
it is intended as the stabel and NOT-experimental branch, so that
might be more to your needs?
I'm sorry but i
On 01.09.2008, at 22:27, Brian wrote:
Btw fltk::HelpWidget really needs to have the contents clipboard
copyable.
It does in FLTK1. It should be possible to port that feature to FLTK2
from the FLTK1 code.
http://robowerk.com/
___
With that being said,
FLTK is nice, fast, a bit unstable and experimental - but definitely
usable.
You are using fltk-2 IIRC? If you find it a bit unstable and
experimental for your needs, you should maybe give fltk-1 a spin too -
it is intended as the stabel and NOT-experimental branch, so
On 27.08.2008, at 22:31, Rafal wrote:
So I would vote
* I would add a bit more debugging code and perhaps even leave more
important one on even in release (users do not care if applications
reacts
to button press in 0.152234 or 0.152216 seconds)
What do you mean by that? I don't have
On 27.08.2008, at 23:58, rlseal wrote:
This policy is justifiable? So I should create storage for all of my
labels and then pass via pointers to all of my other widgets -
making me
maintain this storage for the lifetime of the widget? Then I decide to
delete my widget; leaving my label to
matthiasm wrote:
On 27.08.2008, at 23:58, rlseal wrote:
This policy is justifiable? So I should create storage for all of my
labels and then pass via pointers to all of my other widgets -
making me
maintain this storage for the lifetime of the widget? Then I decide to
delete my
matthiasm [EMAIL PROTECTED] writes:
On 27.08.2008, at 06:13, Greg Ercolano wrote:
Brian wrote:
However I have to agree that adding complexity to a base class
shouldn't be
taken lightly. I'm always for ripping unnecessary stuff out (begin/
end/current
being a good
matthiasm wrote:
hundreds (Rafal, count them) of widgets easily. The FLUID menu bar has
The fact that even simple programs these days hav 50MB and more ust
Erm, no.
I ment that:
1) On typical desktop computer application is free to use 50+ MB of ram
without any problems (only using 200-500
On the other hand, EVERY developer will notice pitfalls of -label() doing
copy, or lack of helpfull features like this label-widgets in widget thing.
And he will take say 20% slower to develop,
and program will have 20% less functions or more bugs etc - and THAT will
affect end users and
First test app I wrote late last year with fltk the labels were all jacked
up.
Ran memory leak tester. Figured out label() didn't copy the values. Also
figured out at that time that the constructors don't allocate space for label.
Yeah. Same here. I am sure there are hundreds of
[EMAIL PROTECTED] wrote:
I'm just sort of thinking out loud here... I do know that
on more than one occasion I've wished it were possible to have
more than one label on a widget.
Hmm, but wouldn't it be better in such a case to create
a custom widget, or just an Fl_Group with
rlseal [EMAIL PROTECTED] writes:
Ugh, I wonder if the above reasoning results in too much copied code/multi
inheritance type conditions.
This is the whole problem. You are not refreshing a label every 7
milliseconds - you're not running a label in a tight loop several
thousand
Greg Ercolano wrote:
So for an app that makes a 1000 x 1000 array of widgets,
adding just 2 bytes to Fl_Widget makes that app use 2MB more ram.
Yes, a very common case.
Most applications I use today have a milion of widgets. Or two milions.
--
Rafał Maj
Software developer
Rafal [EMAIL PROTECTED] writes:
Greg Ercolano wrote:
So for an app that makes a 1000 x 1000 array of widgets,
adding just 2 bytes to Fl_Widget makes that app use 2MB more ram.
Yes, a very common case.
Most applications I use today have a milion of widgets. Or two milions.
He's
Brian wrote:
He's being exteme.
However I have to agree that adding complexity to a base class shouldn't
be
taken lightly. I'm always for ripping unnecessary stuff out
Normal small appl will have like 50 widgets. 500 for bigger application.
Typical label is say 40 char long.
Lets assume a
On 25.08.2008, at 01:00, Rafal wrote:
[EMAIL PROTECTED] wrote:
The vast majority of widget labels tooltips are compile time
constants
Other than your own apps, do you have any evidence whatsoever
to support this statement?
I also disagree with saying that majority of labels are
[..]
My proposal would be (and it solves the problem above as well) to stop
continue what was internally done already and pull all label code out
of the widget and simply allow any kind of widget as a label-child
of a widget. The advantages should be obvious: create html based
complex
On 25.08.2008, at 14:49, [EMAIL PROTECTED] wrote:
Having done this, I think there wouldn't be any remaining meaningful
distinction between Widget and Group, and the latter could
be eliminated altogether. That would be a Good Thing (tm), imo.
I have thought about that quite a bit and I am
Sounds good, I have e few comments/questions:
matthiasm wrote:
Example
w = new Fl_Value(10, 10, 200, 200, Hello);
would internally call this:
w = new Fl_Value(10, 10, 200, 200);
w-label(new Fl_Label(Hello));
I think we will need keep two versions - label/copy_label on two
[EMAIL PROTECTED] writes:
I'll throw in my $.02 here
Me too.
[..]
The vast majority of widget labels tooltips are compile time constants
Other than your own apps, do you have any evidence whatsoever
to support this statement?
Other apps shipping with fltk2 support? dillo-fltk
[EMAIL PROTECTED] wrote:
Great idea. Expanding on it a bit, it should make it fairly
easy to allow widgets to have more than 1 label (why not?). Alignment
would become a property of the label rather than the widget, which
seems like a logical place for it anyway, at least to me.
font etc.
Ugh, I wonder if the above reasoning results in too much copied code/multi
inheritance type conditions.
This is the whole problem. You are not refreshing a label every 7
milliseconds - you're not running a label in a tight loop several
thousand iterations long, etc.. . The whole point
[..]
font etc. yes, but I am not sure about alignment - as it is property
relative to something above it, ...
True enough, but is not the same thing true of any widget? The
widget's position is relative to something (window or screen) above it.
... so it should be rather property of the
[EMAIL PROTECTED] wrote:
[..]
font etc. yes, but I am not sure about alignment - as it is property
relative to something above it, ...
True enough, but is not the same thing true of any widget? The
widget's position is relative to something (window or screen) above it.
... so it should
[..]
Also strictly speaking we would need to distinguish between two alignments:
1. row indentation (right, left, centre)
2. position of the label relative to the widget
The first one is a sole property of the label and if the second (which
is rather what we have in mind here) would be
[EMAIL PROTECTED] wrote:
I'm just sort of thinking out loud here... I do know that
on more than one occasion I've wished it were possible to have
more than one label on a widget.
Hmm, but wouldn't it be better in such a case to create
a custom widget, or just an Fl_Group with
I'll throw in my $.02 here
Me too.
[..]
The vast majority of widget labels tooltips are compile time constants
Other than your own apps, do you have any evidence whatsoever
to support this statement?
anyways, why add the extra overhead that's not needed?
And it integrates wonderfully well
Brian wrote:
Also arguing that replacing char* by std::string and so on would make FLTK2
more bug free is a complete...
Using std::string *would* make fltk2 more bug free.
But it would be a mistake.
Maybe it could be a compile time option to enable std::string()
methods.
[EMAIL PROTECTED] wrote:
The vast majority of widget labels tooltips are compile time constants
Other than your own apps, do you have any evidence whatsoever
to support this statement?
I also disagree with saying that majority of labels are compile time
constant, because:
1) mostly:
I'll throw in my $.02 here
Fabien Costantini [EMAIL PROTECTED] writes:
Rafal wrote:
Hi, after using FLTK2 for some time, I have following ideas how to overall
improve it;
Improve it ? you mean now that it is stable enough and released ?
(sorry for the bad joke)
It is possible to
Rafal wrote:
Hi, after using FLTK2 for some time, I have following ideas how to overall
improve it;
Improve it ? you mean now that it is stable enough and released ?
(sorry for the bad joke)
Text mode :
1) nicer modern C++
Sorry again, but I couldn't care less about this kind of issues,
35 matches
Mail list logo
