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
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
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 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/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
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
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 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:
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
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
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
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
[Changing the subject a bit to avoid a thread jack]
On 03/25/13 09:25, Roman Kantor wrote:
Somewhat related, it would be nice if fl_add_symbol() would accept not only
drawing functions
but also images, even without additional scaling and rotations.
In the symbol table there is an int flag
To solve STR#2939 Fl_Tabs not honoring when(FL_WHEN_NOT_CHANGED)
noticed that Fl_Tabs doesn't really make use of when() at all.
It seems to me tabs are very much like radio buttons, so it seems
it would make sense to model Fl_Tabs handling of when() after radio button's.
With radio buttons, the
On 03/25/13 19:37, Greg Ercolano wrote:
With radio buttons, the behavior is:
0) FL_WHEN_NEVER -- callback never invoked
1) FL_WHEN_CHANGED -- invokes callback when click
changes a button's state (no callback if no change)
2
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2434
Version: 1.3-feature
Fix Version: 1.3-current (r8094)
Fixed in Subversion repository.
These were all added a while ago; closing.
Link: http://www.fltk.org/str.php?L2434
Version: 1.3-feature
Fix Version: 1.3-current (r8094)
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
Fix Version: 1.3.0 (r6850)
Fixed in Subversion repository.
This was implemented but never closed.
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
Fix Version: 1.3.0 (r6850)
I'm working on fixing STR #2772 (removing extraneous code in fl_measure()) and
need to understand in detail how we support '@' symbols in FLTK.
Question:
I want to verify that '@' symbols in labels (eg. @-) are only
allowed at either *the very beginning* or *very end* of a string,
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2936
Version: 1.3-feature
(Submitted on behalf of Gonzalo's request on fltk.general 03/20/13)
Fluid seems not to allow one to define a 'namespace' for functions/methods
On 03/09/13 01:04, Ian MacArthur wrote:
On 9 Mar 2013, at 01:57, Greg Ercolano wrote:
I added a chooser for the different schemes, and squeezed in Edmanuel's
widget
panel that shows how the schemes look with different widgets.
Here's a thought (I haven't checked the latest
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2675
Version: 1.4-feature
Note: STR#2672 (patch for gleam) I think conflicts with this
patch, if both are trying to implement gleam.
Both STR's are currently active;
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2672
Version: 1.4-feature
Note: STR #2675 may be in conflict; it is suggesting a patch
that is a combo of gleam and grad schemes.
Both STRs are currently active; L
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2672
Version: 1.4-feature
Link: http://www.fltk.org/str.php?L2672
Version: 1.4-feature
___
fltk-dev mailing list
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2672
Version: 1.4-feature
Attached file unittest-mods.png...
Link: http://www.fltk.org/str.php?L2672
Version: 1.4-featureattachment:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2675
Version: 1.4-feature
Testing the latest patch -- how do I test it?
I tried building fltk and then running e.g.:
test/buttons -scheme grad1
test/buttons
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2672
Version: 1.4-feature
Attaching a patch for test/unittests that implements the test/gleam program
code into it. (unittests-schemes.patch)
Also, attached
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2672
Version: 1.4-feature
Hi Edmanuel,
Thanks for the great work -- can I suggest attaching a screenshot
showing what glean does? It would help motivate a merge.
Link:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2672
Version: 1.4-feature
Question about this patch: I noticed this line in the patch
that adds the scheme gleam to fluid:
+ Fl::scheme(gleam);
..but support of the
On 03/01/13 01:33, MacArthur, Ian (Selex ES, UK) wrote:
What Mike said: As soon as *anything* in SVN changes after a release, we need
to bump the version numbers in some way.
Or, just change it immediately after release.
Changing the version number is itself a change, and would
Not sure what that number becomes if we ever move to git, though..
What it becomes, as you know, is a human-opaque string of gibberish...
(Technically I understand why it is like that, but I really can't believe we
couldn't figure out some way to hide that behind some human-friendly
Would like to hear from Albrecht, Matt, and Mike on this as well.
Greg: Zlib or MIT with exceptions to relax use and not require citations
Ian: Zlib, add exception to relax code use
Recommendations of other licenses are fine too.
I think all we really want people NOT to do is
On 02/22/13 06:46, Patrick wrote:
Having said that, I think that a C binding would really help the project
and I would like to help, please let me know if I can.
IIRC, FLTK started as a C++ rewrite of C based xforms
(and by extension, forms)
xforms is still around:
On 02/22/13 15:15, Patrick wrote:
If you have suitable pixmaps, might be worth a shot: we'd need to be sure
about the licensing and copyright mind you - that seems to be much more a
pain these days that in was back in the day...
What about this site:
http://openclipart.org/
Presently
On 02/22/13 18:03, Patrick wrote:
I only use Linux but I would like to learn a little more about
developing on Windows.
Could you tell me where the necessary Visual
Studio files are. Maybe I will try a suicide mission and give it a try
in the next couple of months.
See the fltk
On 02/17/13 17:25, Michael Sweet wrote:
There is also the issue of how to safely execute programs from the library;
it is incredibly difficult to safely deal with file descriptors and
signals/handlers from a library without some coordination with the
application...
I guess we have
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2904
Version: 1.3-feature
Thanks Manolo! Nice addition.
Would be great if you could document any gtk/linux specifics for use
of FNFC in the docs, and try to hit on:
Reviving this issue, as we probably should address it ASAP.
Looking for dev votes on which license to use for the fltk/examples dir,
as I don't think we have a firm decision on which to use and the exact
wording.
Because of how *examples* are meant to be
Oh, and in case I wasn't clear, looking for votes on which of these
to use:
1) ISC style license (eg. open BSD see below)
2) Zlib style (see below)
3) MIT style (see below)
4) GPL2 (Mike's sugg #1, see:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L829
Version: 2.0-feature
Here's someone else that posted a message in 2010 with changes for
Fl_GIF_Image:
Hmm, I have a 10.4.11 system, and it builds 1.3.x svn current OK with
./configure --enabled-shared ; make
(Note: I didn't try the 1.3.2 tar)
Maybe an issue with cross compile env or cmake?
Try using regular make instead.
Here's the full build
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2918
Version: 1.3-feature
Agreed Ian. OP, what's your config.log say about these:
HAVE_LIBFONTCONFIG
USE_XFT
HAVE_XINERAMA
If they're 1 and you want them off, have you
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2816
Version: 1.3-feature
@Ian: Let me preface by saying I had a weak coffee this morning, so I might
be missing something obvious..
I see you're point.. re: 1.3 to me
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2816
Version: 1.3-feature
@Ian: Right, I feel the same way. Would like to see Albrecht or Matt weigh
in.
OP, feel free to comment as well on the ABI issue with respect
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2904
Version: 1.3-feature
FWIW, zenity(1) is a simple linux command line tool that can
among other things bring up a native file chooser.
$ zenity --title=Select a
Looks like Matt released 1.3.1 -- thank you!
Don't forget to post on fltk.announce as well..
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
On 11/05/12 11:05, Matthias Melcher wrote:
On 16.10.2012, at 10:42, MacArthur, Ian (SELEX GALILEO, UK)
ian.macart...@selexgalileo.com wrote:
Reawakening this thread.
+1 for 1.3.1 release, with the ABI breaking stuff turned off by default,
and calling it 1.3.1 (not .2)
Yes. I
On 12/29/11 01:22, Torsten Giebl wrote:
GIT is great, no question about it,
but i hate one thing about it and some other SCMs, it is the hash IDs.
Are you using 6ff87c4664981e4397625791c8ea3bbb5f2279a3 ?
I like the numbering of SVN.
1000
1001
1002
.
.
It is easier to remeber when
On 10/16/12 03:46, Manolo Gouy wrote:
+1 for 1.3.1 release, with the ABI breaking stuff turned off by default,
and calling it 1.3.1 (not .2)
I'd try to push it out myself if I knew how.
Let's first check what the outstanding bugs are against 1.3.1
that are release
Reawakening this thread.
+1 for 1.3.1 release, with the ABI breaking stuff turned off by default,
and calling it 1.3.1 (not .2)
As Linus says: Release Early, Release Often.
(We've been doing the opposite lately :P )
On 05/30/12 01:22, Albrecht Schlosser wrote:
On 29.05.2012 22:46, Matthias
Just pulled r9698 to check on a 3.x question on fltk.general,
but could not run a default build on linux centos 5.6:
--- snip
[..]
Compiling fltk3images/GIFImage.cxx...
Compiling fltk3images/HelpDialog.cxx...
Compiling fltk3images/images_core.cxx...
Compiling fltk3images/JPEGImage.cxx...
On 09/29/12 08:56, Kartik Patel wrote:
How do I use WRAP_AT_BOUNDS without problems in this code?
Qualify it with the class name, eg. Fl_Text_Display::WRAP_AT_BOUNDS
Apologies in advance if this is not the correct forum for this query.
Yes, please use fltk.general instead for
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2874
Version: 1.3-feature
Fix Version: 1.3-current
If we do this, let's be sure we call getenv() just once at program start
and set a bitflag, to avoid having the
On 09/08/12 08:10, Duncan Gibson wrote:
According to svn, engelsman put this in the docs:
FL_DND_* events cannot be used in widgets derived from Fl_Group or =
Fl_Window.
Is there any specific platform or any reason for this? Or is the =
sentence itself wrong?
I don't remember adding it.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2860
Version: 1.3-feature
@manolo: First patch has the xywh version of screen_num().
So of the three patches he posted here, I think he wants you to apply them
this way:
On 08/27/12 07:48, Pierre Ossman wrote:
Link: http://www.fltk.org/str.php?L2860
Version: 1.3-feature
Updated patch. Finally got a OS X test machine, and of course found a bug.
Sounds good -- any devs with multiple monitors to verify?
___
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2866
Version: 1.3-feature
This shouldn't be an STR because it's not requesting a specific change to
the lib, it's just asking a general question.
We should really answer
On 08/04/12 18:53, Greg Ercolano wrote:
When starting in fluid, choose New - Code - Function/Method,
and leave the make_wnidow default as the function name, and
attach your windows and widgets to that.
Then later, define a New - Code - Function/Method
and blank it out
1 - 100 of 938 matches
Mail list logo
