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
Has anyone seen this before?
I've got a few GUI apps that build on Linux and OS X 10.5. I'm using FLTK
1.1.7 for the GUI code, and CMake to build the programs and to generate the OS
X application bundles.
I want users to be able to launch the programs from the command line, because I
want
My apologies. I accidentally posted to the wrong forum.
Cheers,
Christian
Has anyone seen this before?
I've got a few GUI apps that build on Linux and OS X 10.5. I'm using FLTK
1.1.7 for the GUI code, and CMake to build the programs and to generate the
OS X application bundles.
I want
I think this operator| works and is a very good way to get the type-safe
calls to work.
matthiasm wrote:
On 13.08.2008, at 13:27, Duncan Gibson wrote:
Isn't there an idiom where you declare a class, but its constructor
is not public, and then have instances declared at class level?
A
[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
14 matches
Mail list logo
