On 04/21/13 10:50, Greg Ercolano wrote:
I made one of these once; in my case I didn't use a tile,
just used a regular Fl_Group in which the widgets were positioned,
and put a thin widget between each that acted as a 'resizer' which:
1) enlarged/shrunk
On 04/20/13 14:04, dirac wrote:
Hi guys,
I'm building a stack of horizontal widgets, like that (I hope the ASCII
art works):
+---Fl_tile---+
| +-+ |
| | widget 0| |
| +-+ |
| +-+ |
On 04/21/13 02:09, Ian MacArthur wrote:
Can someone to point me to a toggle switch widget?
There's no 3-position switch that I'm aware of.
When I needed this, I just put 3 radio-buttons in a group and that was fine -
and trivial to do.
Ya, or an Fl_Menu_Button with three items in
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2953
Version: 1.3-feature
Seems odd that Fl_Multiline_Output and Fl_Multiline_Input
don't have an append() method.
insert(string) is not quite the same, such as if the
101 ICONDISCARDABLE sudoku.ico
|_
|
icon((char *)LoadIcon(fl_display, MAKEINTRESOURCE(101)));
Though I'm uneasy about just assuming the value is 101
- in principle we could make it
On 04/16/13 01:57, MacArthur, Ian (Selex ES, UK) wrote:
In fact, I think when the following three calls are being used
together,
they have to appear in this specific order or they won't work right..
at least on win32 anyway:
1) icon() -- if used with xclass(), this must be first
On 04/16/13 06:15, Andrew wrote:
All process of work with text editor is based on work with text buffer
( which in my design is unique for each window) and reacting on buttons
callbacks like copy, open,etc.
One thing of importance; Fl_Text_Editor uses the Fl_Text_Buffer to
render
On 04/15/13 00:48, Duncan Gibson wrote:
I'm diverting this to fltk.development rather than this specific RFE...
Sorry about cluttering up your STR, but I was on a roll.
Tried to move it to fltk.dev, but I'd've (*) had to make an intro
and write for a wider audience..
On 04/15/13 09:53, David FLEURY wrote:
I reactivate this, just to known if I had to keep it somewhere on my
repo to patch my fltk, or something like this will be apply in the
official repo.
If I understand this correctly, making a win32 icon for the fluid app
so that the
On 04/15/13 13:28, David FLEURY wrote:
Le 15/04/2013 21:57, Ian MacArthur a écrit :
Is there an STR for this somewhere? I can't find it... so I can't find the
patch.
I am not used to create a STR. I did not create one.
Ian; he included the patch here on fltk.dev at the head of this
On 04/15/13 14:28, Ian MacArthur wrote:
On 15 Apr 2013, at 22:13, Greg Ercolano wrote:
On 04/15/13 13:28, David FLEURY wrote:
Le 15/04/2013 21:57, Ian MacArthur a écrit :
Is there an STR for this somewhere? I can't find it... so I can't find the
patch.
I am not used to create a STR. I
I just noticed a few things on win32:
[1] If an app sets the window's xclass() *before* it sets the icon(),
the icon won't show up in the title bar.
[2] In the win32 osissues page, under Setting the Icon of a Window
there's a NOTE: that reads:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2951
Version: 1.4-feature
Can't say regarding [1] or [2].
For [3], I'd say google for double slider widget and range slider
and see what you can gather in the way of
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2951
Version: 1.4-feature
Oh, and for [5], I think tooltips would be good for some but not all
cases.. text fields that are always visible would probably be needed
very
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2951
Version: 1.4-feature
Oops, and responsive to keyboard navigation. This means:
o responding to FL_FOCUS to handle drawing the focus box
(or not based on
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2951
Version: 1.4-feature
..and don't forget to take into account handling deactivation,
affecting how the widget draws itself, etc.
It occurs to me maybe I should write
Glad you've got the login stuff sorted.
However, this is weird:
On 04/13/13 03:27, Duncan Gibson wrote:
Anyway, I was about to update the commits graph on Article #825, and
went to http://fltk.org/site/str.php?L2806 to download the python and
gnuplot scripts only to find the attachments all
On 04/13/13 14:47, testalucida wrote:
can someone explain, what's wrong with this code? There's no FL_DRAG event
upcoming in the Box class:
The docs for the FL_DRAG event will tell you why:
http://fltk.org/doc-1.3/events.html
Under the section Mouse Events:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9871)
Albrecht We're only calling const methods anyway, as x(), y(), window(),
Albrecht and this code is not
On 04/12/13 01:20, MacArthur, Ian (Selex ES, UK) wrote:
@manolo: Great -- agree with all, except perhaps loosing const here:
- const Fl_Window *win = (const Fl_Window*)this;
+ Fl_Widget *win = (Fl_Widget*)this;
I think we can maintain const protection on the variable this way:
const
On 04/12/13 10:44, Albrecht Schlosser wrote:
Yes, though for some reason as_window() is not const,
(it probably should be), which is why that cheat is necessary at the end
there. Maybe using const_castFl_Widget*(w)-as_window() is better,
which is what I decided to go with in
On 04/12/13 11:05, Albrecht Schlosser wrote:
Hmm, I'm not a const and ABI specialist, I mean I don't know
all the implications that would arise if we changed this method.
Ya, I'll have to double check that one, but I think changing
the prototypes (args, return values) of
On 04/12/13 13:19, Ian MacArthur wrote:
I'm in favour of allowing the C++ style casts.
I expect that it probably works with all the extant compilers now?
Does anyone know for sure?
The static_cast mod flew in all my tests on redhat9 and irix6.5,
and those are as old as the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9876)
Updated fixes in r9875 and r9876.
About to close, unless there's more to add.
Regarding const mods to
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9876)
Oh, I should add..
all mods to date (r9876, including static_cast) build OK on:
redhat9, irix6.5, centos
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9876)
Sorry, as Ian points out on fltk.dev, meant to say const_cast
in the above, not static_cast.
Link:
On 04/12/13 16:17, Ian MacArthur wrote:
The static_cast mod flew in all my tests on redhat9 and irix6.5,
and those are as old as the friggin hills.
You say static_cast here?
Bleh, mental typo. I meant this:
$ grep const_cast Fl_Window.cxx
return
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9871)
@manolo: Great -- agree with all, except perhaps loosing const here:
- const Fl_Window *win = (const
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
We can probably avoid breaking ABI if we implement this new bitflag
as part of the existing flags, eg:
enum { // values for flags:
:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
Oh, I see, you are suggesting this, /and/ a global flag to affect
the entire menu, yes.
I guess we can't avoid breaking ABI for the global
On 04/11/13 02:18, MacArthur, Ian (Selex ES, UK) wrote:
If I understand correctly, the capslock state info is correct during
regular keypresses, just not when the capslock key is hit.
Yes - in all the tests I tried, the Caps Lock state was always correct
during (and after) regular
On 04/10/13 00:01, Duncan Gibson wrote:
and I no longer remember my subversion access password]
FWIW, I believe there's a process for resetting your password
at the right hand side of the login page:
http://fltk.org/login.php
Thanks for the pointer, Greg
That's how I
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2
As a side note, in r9870, the new method suggest here to find the
top-level window's offset relative to the current widget
has been renamed to:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Can the knowledge of the top enclosing window of an object
be useful without knowledge of the object coordinates
relatively to this
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
as_window()
Yes, that looks good.. I'll do some tests; want to make sure
it inherits through all the window options we have
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Oh, BTW, I think I missed what Manolo might have been getting at
wrt the 'top_window_offset()' method.
So where we're at now, just to
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
OK:
r9871: top_window(): implemented (using as_window())
r9872: top_window_offset() now a member of Fl_Widget (was Fl_Window)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9871)
..and finally:
r9873: CHANGES file updated.
Comments before close?
Link:
On 04/09/13 23:24, Ivan Nedrehagen wrote:
I also suspect that there might be problems replicating this bug, so I will
try to do some digging of my own. Since I have built the FLTK library on my
own, I might tinker a bit with the source and might run a strace (or windows
equiv.) on the glut
On 04/09/13 02:19, Duncan Gibson wrote:
and I no longer remember my subversion access password]
FWIW, I believe there's a process for resetting your password
at the right hand side of the login page:
http://fltk.org/login.php
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2772
Version: 1.3-current
Fix Version: 1.3-current (r9869)
Fixed in Subversion repository.
Link: http://www.fltk.org/str.php?L2772
Version: 1.3-current
Fix Version: 1.3-current (r9869)
On 04/09/13 02:42, MacArthur, Ian (Selex ES, UK) wrote:
Anyway, since it's not much code, could we probably add it to the
header file as an inline method ?
Would an inline method in a header file be DLL friendly though?
Though that would limit the ABI impact I guess.
Right,
On 04/08/13 15:50, Greg Ercolano wrote:
On 04/08/13 15:32, Albrecht Schlosser wrote:
On 06.04.2013 07:55, Greg Ercolano wrote:
BTW: toplevel_window() doesn't look bad, but what about top_window().
Less typing ;-)
Yes, what I based 'toplevel_window()' on was that in our code
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
This STR spawned from a discussion on fltk.development,
Subject: RFC: method to find top level window?
The suggestion is to add a method
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Attached file test-top_window.cxx...
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature#include FL/Fl.H
#include
On 04/09/13 07:08, Roman Kantor wrote:
I have got a number of complains from end users how the menu items behave -
probably different than they are used to or how other toolkits behave.
The complain is that clicking on ANY item causes the whole menu to close,
even if it is:
1) A submenu.
On 04/09/13 12:18, Howard Rubin wrote:
On Mon, 08 Apr 2013 20:17:31 -0700, Greg Ercolano e...@seriss.com wrote:
unsigned n;
XkbGetIndicatorState(d, XkbUseCoreKbd, n);
caps_state = (n 0x01) == 1;
That works perfectly, and even better, needs no timer
On 04/09/13 12:29, Greg Ercolano wrote:
we could perhaps provide a wrapper to get the
state of the keyboard LEDs (for operating systems that provide this)
e.g. fl_get_indicators() or some such that returns flags.
Maybe fl_get_keyboard_leds() and fl_set_keyboard_leds
I tried the following FLTK code with the above X11 only code
and it seemed to work more reliably.
Ian writes:
Not so much for me - though that may be an issue with the VM rather than
a real problem.
I find that, with this code, if I toggle Caps Lock on/off a few times,
I can
On 04/09/13 10:07, Ivan Nedrehagen wrote:
Which version of FLTK (1.3.1, 1.3.2..)
I use FLTK 1.3.2
Also: do the FLTK opengl test programs cube.exe and shape.exe exhibit
this same behavior?
Yes they do.
Right, good to know.
I cannot replicate with Win7 +
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2
OK; fixes applied to fltk 1.3.x svn current for these:
Item #1: fixed in r9865 -- Apple specific overlay emulation issue
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2
Fix Version: 1.3-current (r9867)
Fixed in Subversion repository.
Leaving this open to allow for comments before closing.
Link:
On 04/08/13 15:32, Albrecht Schlosser wrote:
On 06.04.2013 07:55, Greg Ercolano wrote:
BTW: toplevel_window() doesn't look bad, but what about top_window().
Less typing ;-)
Yes, what I based 'toplevel_window()' on was that in our code,
the term 'top-level' is used fairly
//hH
int Sbut::handle ( int event )
{
if ( event == FL_PUSH )
{
cout Sbut handle 1: PUSH endl;
do_callback();
return 1;
}
return 0;
}
Also, unrelated, the above bit of code should be repaired.
As it is, the
On 04/08/13 10:35, Howard Rubin wrote:
On Fri, 05 Apr 2013 23:39:28 -0700, Greg Ercolano wrote:
an fltk timer would probably be needed to get the correct
state info shown reliably.
Thanks for the replies.
No luck with an fltk timer, on Ubuntu Linux 10.04. Test program below
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2
Attaching a v7 patch; simplified the docs a bit.
Also added an Fl_Tabs code example while I was at it
(which should be committed separately)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2
And again oops; last message that says Regarding #2 should read
Regarding #1. Pff, even had my coffee already.
BTW, I'm being overly verbose here
On 04/02/13 02:28, Ivan Nedrehagen wrote:
Does anyone know how I can get the Fl_Gl_Window to play nicely in windows?
Which version of FLTK (1.3.1, 1.3.2..)
Also: do the FLTK opengl test programs cube.exe and shape.exe exhibit
this same behavior?
I cannot
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2
To fix #2, I'm thinking the attached patch, rasterpos_bugfix.patch,
might be a good way to implement the fix with code reuse in mind.
This adds a
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2
Suggesting the attached Fl_Tabs-add-when-v6.patch
which modifies Fl_Tabs to handle when().
Includes doxygen docs that describe the various combos
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2945
Version: 1.3-feature
Have you ruled out this might be a problem with your own machine?
Have you had problems with viruses recently? (ie. if you have an out
of data
On 04/06/13 09:02, Manolo Gouy wrote:
Seems nutty, but is the entire file src/Fl_mac.cxx unused code?
Perhaps it should be removed from SVN,
Yes, Fl_mac.cxx is now totally useless, being replaced by Fl_cocoa.mm.
I believe it can be deleted, since one can recover it from svn
in the unlikely
On 04/05/13 22:58, Edzard Egberts wrote:
It seems, that caps-lock handling starts to work after key handling and
I think there might be other problems, like switching caps lock, when
there is another window in focus. I think a better way is, to use a
timer and to check for change of state
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2
Thanks for the patches!
Can you supply a small compilable app that demonstrates the problem for
(1) and (2)? Along the lines of e.g.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2
Assigning this STR to myself.
Confirmed #2:
Attaching rasterpos-fix-before-and-after-screenshot.jpg
showing the problem/solution, and agree
Hmm, aren't we loosing the close of /dict with this change?
Modified: branches/branch-1.3/fltk-config.cmake.in
===
--- branches/branch-1.3/fltk-config.cmake.in2013-04-05 15:09:50 UTC (rev
9860)
+++
On 04/05/13 08:59, Howard Rubin wrote:
I need to immediately detect when Caps Lock is turned on or off in our
login screen, so I can alert the user. Neither of the approaches I've
tried works.
Do you see the same problem when using the fltk
test/keyboard application?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2634
Version: 1.4-feature
Getting around to revisiting this.
Unfortunately the changes suggested so far aren't in patch format,
so it's hard to determine what changed to
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2634
Version: 1.4-feature
I'm also attaching a zip that contains Domingo's changes
from a posting he made to fltk.dev on 03/08/2010
with the same files broken out:
On 12/12/10 06:08, Domingo Alvarez Duarte wrote:
Due to the massive modifications there is no patch here it's the whole new
Fl_Help_View
Re-awakening this old thread to revisit..
Domingo, unfortunately I think the code you attached in this thread
is the original fltk
On 03/08/10 08:03, Domingo Alvarez Duarte wrote:
I've got the original files and inserted on then only the changes I
made, quite a lot !
OK, here's an older thread with your Fl_Help_View.{cxx,H} files
that have your changes; add these to STR# 2634 as a zipfile:
On 04/04/13 02:52, MacArthur, Ian (Selex ES, UK) wrote:
I tried to show some html-text for help, but Fl_Helpview doesn't take
care of br and mucks up formatting. Doc tells, Fl_Helpview should
take care of br, shouldn't it?
Hmm, yes, that does seem a bit broken...
As a hackaround, it looks
On 04/04/13 09:44, Manolo Gouy wrote:
It'd be good if we could fix adjacent BR's though.
I recall our html parser's source being a bit tricky to grok,
but I think I worked on a small part of it once.. will see if
I can figure this one out.
I've seen that commenting out line
On 04/04/13 14:32, Greg Ercolano wrote:
On 04/04/13 09:44, Manolo Gouy wrote:
I've seen that commenting out line 657 of file src/Fl_Help_View.cxx
seems to fix this problem. But does this have other negative effects?
[..]
That does seem to allow multiple BRs to work.
But also
On 04/03/13 18:34, Lynn Quam wrote:
Since I have not previously reported FLTK bug fixes, I would like
to know the procedure that I should use.
Hi Lynn,
Go to the main fltk.org page and click on 'Bugs Features', and then
click
Submit Bug or Feature Request, and follow the
On 04/03/13 08:44, marty moore wrote:
I notice that old examples used
int i = (int)v;
but that won't work with gcc-4.4.5
Right -- probably a precision loss error during the void* - int,
since sizeof(void*)==8 and sizeof(int)==4.
I think the best approach (in 1.3.x) is
On 04/03/13 09:05, Ian MacArthur wrote:
void mycallback(widget* w, void* v) {
eop e = (eop) (atoi((char*)v));
What is it you are trying to do here?
Probably trying to sidestep the 'precision loss' error from the
newer compilers due to sizeof(void*) != sizeof(int).
On 04/03/13 13:22, marty moore wrote:
long i = (long)(w-argument()); compiles, but always results in '0'.
Doesn't w point back to the Fl_Menu_Button that had the menu?
Probably depends on if you're setting the callback for the widget,
or the callback for the items.
Each
On 04/01/13 18:47, Bruce wrote:
Trying to build subset of Fldigi for
80m PSK31 USB
and the cursor on the waterfall stalls at 2984.
I see the PSK31 frequency range as being 1.6 to 3.580
Something that I am misunderstanding
or is there a fix for this?
Hi Bruce,
If you're trying
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2942
Version: 1.3-feature
Hmm, doesn't that patch take /away/ the current control
an app has over the button pushed color via selection_color()?
selection_color() can be
OK, so since Fl_Tabs currently has no defined when() behavior,
it seems we can define the behavior of the non-default values how we want,
as long as the default behavior remains unchanged.
Having looked exhaustively at similar widgets (Fl_Radio_Button Fl_Browser)
to divine the when() flags
*correction*
On 03/29/13 17:40, Greg Ercolano wrote:
The above departs from the current behavior of Fl_Browser and Fl_Radio_Button
in that the keyboard behavior for PUSH vs. RELEASE follows the same logic as
the mouse.
(In the other widgets, keyboard callbacks are always on *PUSH
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2
Attaching a test program, when.cxx, to test the when() behavior
of tabs vs. radio buttons vs. hold + multi browser.
Also, used this program to
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2
Meh, forgot to rename the test program;
uploaded as tabs.cxx instead of when.cxx.
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2
So here's a big table comparing the when() behavior of radio and
browser, comparing mouse clicks and keyboard nav clicks:
http://seriss.com/people/erco/fltk/when-behavior-03-26-2013.html
Fixed that table up a bit to make it easier to read.
Hit Reload to see the changes.
During
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2941
Version: 1.3-feature
Based on fl_measure(), I'd say symbol support isn't hard.
The symbols simply scale to the current string height, whatever it is.
So if it's a
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2941
Version: 1.3-feature
symbols simply scale to the current string height, whatever it is.
I should add fltk's @ symbols are not really like characters,
they're more
On 03/26/13 16:48, Gonzalo Garramuno wrote:
fltk-2 is, as you know, deprecated, and no one is available to maintain nor=
fix it, so we can't really go on distributing it, until it gets fixed...
Sure you can distribute it. It is there in the main page, what version to
download.
I
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2941
Version: 1.3-feature
Would be nice if an alternate version of fl_text_extents() were available
that could handle crlfs in the string.
Probably wouldn't be too hard;
On 03/27/13 11:41, chris wrote:
Hm, doesn't fl_measure() do all this already?
No, fl_measure() measures typographical area,
whereas fl_text_extents() measures the 'inking area'.
These are very different.
See the test/unittests program, text rendering test for a
*Correction*
In particular how the two functions calculate differently the bounding
region
for the characters ('), (-), and (_); fl_measure() returns the *SAME*
x,y and height
for those characters, whereas fl_text_extents() does not.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2941
Version: 1.3-feature
@Ian, can't blame you -- impressed you took on fl_text_extents()
at all.. big job, multiple platforms!
But isn't the multiline issue simpler?
On 03/25/13 22:51, Greg Ercolano wrote:
On 03/25/13 19:37, Greg Ercolano wrote:
With radio buttons, the behavior is:
[..]
Actually, some elaboration; tests revealed a subtlety I wasn't aware of:
[..]
Oh, and here's a test program (below) I was using to check when() behavior
On 03/26/13 01:54, MacArthur, Ian (Selex ES, UK) wrote:
Actually, some elaboration; tests revealed a subtlety I wasn't aware of:
Huh; that's not quite what I expected, either.
Though, now I think of it, I'm not sure what I *did* expect the behaviour to
be.
I only rarely use the when
On 03/26/13 10:47, Greg Ercolano wrote:
I wonder if it is worth poking at a few non-radio buttons
and see if that is the same or whether some of these behaviours
are peculiar to the radio-button case?
Good idea; Fl_Browser is the only one I can think of that has
multiple states
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.3
testalucida posted on fltk.general today:
using Fl_Tabs, wanting to make a single tab group,
and wants to receive callbacks whenever the one tab is
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.3
Also attaching a patch suggestion for Fl_Widget's when() docs
to elaborate on the use of FL_WHEN_NOT_CHANGED.
Link: http://www.fltk.org/str.php?L2939
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2940
Version: 1.3.3
There are some behaviors of @ symbols that aren't documented but
should be in this section: http://fltk.org/doc-1.3/common.html
I posted a bit about
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2
Taking ownership, fixed subject typo.
Put an RFC on fltk.development to see if implementing all the when()
behavior of radio buttons makes sense
Question:
I want to verify that '@' symbols in labels (eg. @-) are only
allowed at either *the very beginning* or *very end* of a string,
or at both ends, and nothing else (ie. not in the middle of a
string, or mixed into multiple lines).
Another interesting thing
1 - 100 of 3008 matches
Mail list logo
