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/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
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
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:
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
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
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 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
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:
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
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
901 - 938 of 938 matches
Mail list logo
