[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
I am closing this because the STR has become much too complex. I would like
to ask the users that have still issues to post them as individual new
STRs, so we have a better handle
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
After some testing with r7037 and r7063 I find that the mouse and wheel
handling is buggy. Apparently mouse drag
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Mark: could you put up a simple example showing the bug you report ?
That would be very helpful. Alternatively,
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Hi Christophe: could you, please, tell us whether your large app
is fully supported, in 64-bit mode, by the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Today upgraded my mac to leopard -- tried compiling fltk-1.3.x-r7037
Although the compile worked, my links
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Hmmm. Resizing a window interactively does not seem to work half of the
time. When I start file_chooser from the
Matt,
What OSX host platform are you on? It *seems* to be working for me under
10.4 - as far as I can tell anyway...
One thing: I think the dependency checks may be off somewhere.
I had an odd bug that went away when I did a make clean ; make on my
fltk tree, so it might be something like that?
Matt,
What OSX host platform are you on? It *seems* to be working for me under
10.4 - as far as I can tell anyway...
One thing: I think the dependency checks may be off somewhere.
I had an odd bug that went away when I did a make clean ; make on my
fltk tree, so it might be something like
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
I just updated to svn r7031, and after a 'make distclean; make',
file_chooser seems to resize OK under Snow
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)Index:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)Index:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)Index: Fl_cocoa.mm
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Matt: there is a remaining problem with FLTK-1.3-cocoa:
demo mandelbrot does not resize correctly (to see that,
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Matt: please apply this important patch to file src/Fl_cocoa.mm .
It corrects a memory allocation bug where any
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Matt: the same issue applies with file fl_set_fonts_mac.cxx
as with fl_font_mac.cxx. Thus, please, enter also
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)Index: fl_font_mac.cxx
On 21 Dec 2009, at 15:14, manolo gouy wrote:
- FL_MENU_RADIO is now working in Fl_Sys_Menu_Bar
Well, maybe... Someone else will need to test this to confirm, but in
my hacked up menubar demo (hacked to use sys_menu_bar for testing)
the FL_MENU_RADIO entries *mostly* work, but I see
On 21 Dec 2009, at 15:14, manolo gouy wrote:
- FL_MENU_RADIO is now working in Fl_Sys_Menu_Bar
Well, maybe... Someone else will need to test this to confirm, but in
my hacked up menubar demo (hacked to use sys_menu_bar for testing)
the FL_MENU_RADIO entries *mostly* work, but I see
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Thanks Matt for this last svn update.
Remaining things:
1) one correction in function doCallback of file
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Matt: a last patch before closing this STR. :=)
Please, update the svn with the 3 files in uploaded file
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
manolo gouy wrote:
By the way, there's a minor bug in demo file sudoku.cxx, the number 8
at line 670 should be
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
... fixed in 1.1.10 as well (svn -r 6973).
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Attachment:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Thanks Matt.
With the uploaded Fl_cocoa_V2.mm file that solves the white
rectangle after FNFC bug in Ian's app,
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Attachment:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
I uploaded file Fl_Native_File_Chooser-0.86-Cocoa.tar.gz that
slightly expands the latest version (0.86) of
Manolo,
I've been testing your FNFC test code that you sent to me, and it
croaks in exactly the same manner as my own app.
I have not tried your new cocoa-based FNFC code yet though, so I will
try that next. I am just using Greg's standard FNFC code at present.
When you have been testing,
Manolo,
I've been testing your FNFC test code that you sent to me, and it
croaks in exactly the same manner as my own app.
I have not tried your new cocoa-based FNFC code yet though, so I will
try that next. I am just using Greg's standard FNFC code at present.
When you have been testing,
Yes, let's include the native file chooser code.
Matt: my feeling is that I can't post here the Fl_Native_File_Chooser
unless Greg, its author, does it or authorizes me to do so.
I'm pretty sure Greg will be OK with that.
In any case, you should mail him your patches direct, I think.
He's
Ian: I made myself a small test program with a main window
and a couple
of non-modal ones, a menu (both in the main window and the apple
menu bar) with an open file item that calls FNFC.
All of this runs as expected.
You are right, I should make a test harness so I can look at this in
Ian: I made myself a small test program with a main window
and a couple
of non-modal ones, a menu (both in the main window and the apple
menu bar) with an open file item that calls FNFC.
All of this runs as expected.
You are right, I should make a test harness so I can look at this in
Matt: we now know with Ian's posts that the additional checks
in carbonTextHandler of Fl_cocoa.mm eliminate Ian's program crash.
Eliminates the crash, certainly, though I still need to understand the
other FNFC issue...
So I suggest you upload mach-sysmenuh-cocoa.patch in the svn.
Seems
I ran 3 svn diff filename and pasted the outputs of these.
Hmm, ok that explains it...
It is not safe to paste together diffs that were made in different
directories, as the diff files include (and the patch program expects to
find) some path information for the files being processed...
If you
I also don't think that it's worth the effort to display the dragged text,
because this would be Mac-specific, and I'm sure that other users wouldn't
like it. Thus my proposal: use a generic image (or cursor symbol or ...),
just as it was before and as it is on other platforms.
Just my 2
On 13.12.2009, at 22:32, manolo gouy wrote:
Yes, the dnd effect is nice, but for whatever reason, it does not
work if data is dragged from the same program.
I don't follow you: I see the green circle in the input demo when dragging
from Multiline to Normal, and in my app when dragging text
On 14.12.2009, at 09:17, manolo gouy wrote:
I also don't think that it's worth the effort to display the dragged text,
because this would be Mac-specific, and I'm sure that other users wouldn't
like it. Thus my proposal: use a generic image (or cursor symbol or ...),
just as it was
What image do you suggest for generic drag
operations ?
We could add an optional argument to Fl::dnd() that can point
to any Fl_Image. If it is some magic value, FLTK will take a
snapshot of the text and drag that (Fl_Input). If it is NULL,
it'll simply drag some box, like it does
3: in the mailing list, there was a solution (or on Greg's
cheat page) that provided a function call for finding the
application name and the directory where the application
resides (which is often not the same as the current directory).
I have a fragment of code I've posted a few times,
Probably from a logical point of view, but it uses dynamic_cast,
and that's not (yet?) allowed according to the current CMP :-(
http://www.fltk.org/cmp.php - C++ Portability
unless we allow it for 1.3.x or 3.x ;-)
Mike, Matt ???
Albrecht
I agree, but, please, note
I also don't think that it's worth the effort to display the
dragged text,
because this would be Mac-specific, and I'm sure that other
users wouldn't
like it. Thus my proposal: use a generic image (or cursor
symbol or ...),
just as it was before and as it is on other platforms.
If it
MacArthur, Ian (SELEX GALILEO, UK) wrote:
What image do you suggest for generic drag
operations ?
We could add an optional argument to Fl::dnd() that can point
to any Fl_Image. If it is some magic value, FLTK will take a
snapshot of the text and drag that (Fl_Input). If it is NULL,
it'll
On 13.12.2009, at 22:32, manolo gouy wrote:
Yes, the dnd effect is nice, but for whatever reason, it does not
work if data is dragged from the same program.
I don't follow you: I see the green circle in the input demo when
dragging from Multiline to Normal, and in my app when dragging
On 14.12.2009, at 11:00, manolo gouy wrote:
On 13.12.2009, at 22:32, manolo gouy wrote:
Yes, the dnd effect is nice, but for whatever reason, it does not
work if data is dragged from the same program.
I don't follow you: I see the green circle in the input demo when
dragging from
Anyway, I was thinking about this (while *not* at a computer and unable
to look at the code...)
An aspect of my app that might be relevant is that it has multiple
windows - the main editor window and multiple floating toolbar
windows, which are non-modal.
What I am finding is that, after
No, it's a function of FLTK. As long as the 'drag' code is not modal for
the application (returns immediately, before the data is actually
dropped), and all FL_DND_* events are received correctly, FLTK will
interactively show the insertion point.
But it's possible that Fl:dnd() does not
By the way, I have also Cocoa-ized Fl_Native_File_Chooser, necessary
because the framework it uses is absent from 64-bit snow leopard
(though it is still in leopard), and I have sent that to Greg.
I remember that inclusion of is in the
FLTK-1.3 roadmap. Did you decide when to include it
On 13 Dec 2009, at 20:05, manolo gouy wrote:
I upload in mach-sysmenuh-cocoa.patch 3 patches as follows:
- in mac.H, add the fl_mac_set_about prototype as discussed
Yes - works for me.
- in Fl_Sys_Menu_Bar.H, add missing #ifdef __APPLE_COCOA__
because the new functions (add, remove,
On 13.12.2009, at 08:23, manolo gouy wrote:
On 12 Dec 2009, at 19:43, manolo gouy wrote:
and recap2.zip also contains my final proposal for
fl_mac_set_about(Fl_Callback *cb, void *user_data, int shortcut
= 0);
Added this into my app for testing (I already had an about box in a
One thing - the function prototype doesn't seem to be in any header
file, so I had to add one. Where are you planning to add it?
=20
=20
I put it in FL/mac.H, right after the MacCollapseWindow prototype.
This would require the user to #include FL/x.H. How to document
this header
On 13.12.2009, at 12:24, manolo gouy wrote:
FL/x.H is the correct header for this since this is a system specific =
function. You can document that by adding a \note field in the doxygen =
paragraph.
There is some ambiguity here between where to put the prototype (mac.H
is my guess) and
manolo gouy wrote:
What is present in recap2.zip is
-test if Fl::pushed() is an Fl_Input_*
[...]
Is that OK?
Probably from a logical point of view, but it uses dynamic_cast,
and that's not (yet?) allowed according to the current CMP :-(
http://www.fltk.org/cmp.php - C++ Portability
...
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
So, you begin to write objective-c code! Beautiful!
I have seen the nice improvement in the drag text effect.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)% svn diff mac.H
Index:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Yes, the dnd effect is nice, but for whatever reason, it does not work if
data is dragged from the same program.
Yes, the dnd effect is nice, but for whatever reason, it does not
work if data is dragged from the same program.
I don't follow you: I see the green circle in the input demo when dragging from
Multiline to Normal, and in my app when dragging text
from one window to another one.
In general, I
manolo gouy wrote:
What is present in recap2.zip is
-test if Fl::pushed() is an Fl_Input_*
[...]
Is that OK?
Probably from a logical point of view, but it uses dynamic_cast,
and that's not (yet?) allowed according to the current CMP :-(
http://www.fltk.org/cmp.php - C++
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
manolo gouy wrote:
About the dynamic_type question: I will see if I can do otherwise
with w-type() call. If
manolo gouy wrote:
Probably from a logical point of view, but it uses dynamic_cast,
and that's not (yet?) allowed according to the current CMP :-(
[...]
I agree, but, please, note that this dynamic_cast is in Fl_cocoa.mm,
a file that does not have to be portable because it's entirely
and
Albrecht Schlosser wrote:
manolo gouy wrote:
Probably from a logical point of view, but it uses dynamic_cast,
and that's not (yet?) allowed according to the current CMP :-(
[...]
I agree, but, please, note that this dynamic_cast is in Fl_cocoa.mm,
a file that does not have to be
All,
Is it expected that the 1.3 codebase can still build in non-cocoa
mode?
I just tried this, and it fails.
There is no option to configure to --disable-cocoa so what I did was
configure normally then hand edit config.h as follows, which I think
should be correct:
#define USE_QUARTZ 1
On 11 Dec 2009, at 23:02, manolo gouy wrote:
On 10.5-i386, the Sudoku demo does display menu accelerators with
their cloverleaf, and they work. But when I compile it PPC/SDK 10.3
they
disappear. Strange, because I did not touch any of that code.
Testing on 10.4.11 / PPC, I have tried
imacarthur wrote:
The sudoku demo does not seem to use the FL_ALT modifier, so I can
not comment on whether the saucepan is upside down or not...
With cocoa 1.3.x sudoku's system menubar item Sudoku - Hide Others
apparently has an ALT modifier, and I can confirm the saucepan
On 12 Dec 2009, at 16:13, manolo gouy wrote:
All,
Is it expected that the 1.3 codebase can still build in non-cocoa
mode?
I just tried this, and it fails.
Yes, it is definitely my goal.
But you reveal that there are some hickups...
You just have to move, in FL/mac.H, the stuff that
On 12 Dec 2009, at 16:27, Greg Ercolano wrote:
With cocoa 1.3.x sudoku's system menubar item Sudoku - Hide Others
apparently has an ALT modifier, and I can confirm the saucepan
is rightside up; the pancake is hovering in midair above the
saucepan.
This one is
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Hi all,
I have uploaded file recap2.zip that contains several patched files
and .h to solve, in addition to what
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
and recap2.zip also contains my final proposal for
fl_mac_set_about(Fl_Callback *cb, void *user_data, int
One other thing I notice: building at the command line, it looks like
the dependency file does not know that Fl.cxx depends on Fl_cocoa.mm,
so if I make any changes in Fl_cocoa.mm, it does not correctly
trigger a recompile of Fl.cxx...
Ian, could you please try and apply this patch to
On 12 Dec 2009, at 20:10, manolo gouy wrote:
One other thing I notice: building at the command line, it looks like
the dependency file does not know that Fl.cxx depends on Fl_cocoa.mm,
so if I make any changes in Fl_cocoa.mm, it does not correctly
trigger a recompile of Fl.cxx...
Ian,
On 12 Dec 2009, at 19:36, manolo gouy wrote:
I have uploaded file recap2.zip that contains several patched files
and .h to solve, in addition to what has already been mentionned:
- missing shortcuts in Sudoku system menu on PPC
Checked this - now works in my app built on 10.4.11 / PPC.
On 12 Dec 2009, at 19:36, manolo gouy wrote:
I have uploaded file recap2.zip that contains several patched files
and .h to solve, in addition to what has already been mentionned:
- missing shortcuts in Sudoku system menu on PPC
- drag with square image when not dragging from an Fl_Input_
Pending issues:
- white footprint behind Fl_Native_file_Chooser wwindow in Ian's app
I have been testing this with a debug build (both fltk and my own
code compiled with -g) and the behaviour is slightly different now:
- If I open a FNFC (Fl_Native_File_Chooser) then close it without
On 12.12.2009, at 17:27, Greg Ercolano wrote:
..so I'm guessing maybe we probably just have the wrong character code
in the source. Currently the source reads:
if (shortcut FL_ALT) {strcpy(p,\xe2\x8e\x87); p += 3;} // [upsidedown
saucepan] alternative key symbol
=20
The main kicker with this now is that as the drag happens, the drag
displays a tooltip with the contents of the drag displayed - but what
I am dragging is a long text string full of cryptic information used
to define the dragged entities, and it just looks very odd.
=20
I'm guess
On 12 Dec 2009, at 20:10, manolo gouy wrote:
One other thing I notice: building at the command line, it looks like
the dependency file does not know that Fl.cxx depends on Fl_cocoa.mm,
so if I make any changes in Fl_cocoa.mm, it does not correctly
trigger a recompile of Fl.cxx...
Ian: this patch was meant to go together with another one
for file Fl_Sys_Menu_Bar.cxx posted Wed at 8:58 FLTK time.
You may be more successful if you apply both.
OK - I'll not get to this until later today, but I will make sure that I
have both patches applied (I am not sure whether I did
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Let's do a recap of where we are now.
I upload file recap.zip containing all modified source code (and .h)
to
On the drag-n-drop issue, I did a little work on that yesterday too, but
did not get very far (had promised to help a friend install his new,
very much bigger, lathe in his workshop...)
What I found was that the code seems to be getting into MACpreparedrag()
and then croaking, but I did not
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Regarding
New API proposal:
- fl_mac_set_about(const Fl_Menu_Item *item)
to connect an FLTK menu item to the
Fl_Widget *w =3D Fl::pushed();
Fl_Window *win =3D w-window();
while(win-window()) win =3D win-window();
This seems to be as far as we get before it dies...
Could it be that your palette is nothing more than a window
with nothing inside? Fl::pushed() would return the
Regarding
New API proposal:
- fl_mac_set_about(const Fl_Menu_Item *item)
to connect an FLTK menu item to the About myprog
application menu item
Maybe it would be better to remove _mac from the name, just
in case we
add similar functions for other platforms, i.e. call it
On 11 Dec 2009, at 11:17, manolo gouy wrote:
Could it be that your palette is nothing more than a window
with nothing inside? Fl::pushed() would return the window,
w-window() would return NULL,
and while(win-window()) would crash on dereferencing a NULL pointer.
This would be corrected by:
On 11 Dec 2009, at 11:17, manolo gouy wrote:
Could it be that your palette is nothing more than a window
with nothing inside? Fl::pushed() would return the window,
w-window() would return NULL,
and while(win-window()) would crash on dereferencing a NULL pointer.
This would be
On 11 Dec 2009, at 10:29, manolo gouy wrote:
Let's do a recap of where we are now.
I upload file recap.zip containing all modified source code (and .h)
to avoid svn diff problems, and will follow Greg's advice thereafter.
Yup - files in the zip seem to be good, thanks.
One thing, IIRC there
- Sudoku crash
Seems OK.
The Sys_Menu_Bar does not have any shortcuts displayed - would I
expect it to?
The menubar demo does have shortcuts displayed, but they seem to have
the saucepan symbol - the alt key modifier. I think I expected them
to have the cloverleaf symbol - the cmd key
Regarding
New API proposal:
- fl_mac_set_about(const Fl_Menu_Item *item)
to connect an FLTK menu item to the About myprog application menu item
While testing the new Fl_Sys_Menu_Bar-add() and remove(), I have
discovered a most unexpected (at least by me) property of FLTK menus:
when one menu
(BTW: Matt do you know what the last pre-cocoa
revision number is?) in the meantime for my builds.
rev. 6950 is the last pre-cocoa version.
But what about disabling cocoa in config.h, at least as a test?
If Manolo's statement that he wrote when he started is true, then
this ought to
Please guys, unless you need to get software out to clients,
it would be much more helpful if you could stick with what we
have. The next OS X will likely not have any Carbon support
at all anymore, so we must move our code base. Without your
help, this will be very hard and even more
- the app is a music editor of sorts, and makes extensive
use of drag
and drop to move notes (and similar entities) from floating toolbars
onto the main editor window. Now, any attempt to drag an entity from
a toolbar onto the main window causes a segfault.
What data do you drag? The
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Here is a correction of the vanishing About myprog window bug.
In function do_queued_events of file
Manolo,
Tried this patch, seems to have fixed the text anti-aliasing on
10.4.11, as you said. Thanks.
I had a bit of a struggle getting this to apply - the patch seems to
have been molested in the mail so I had to unwrap a lot of the lines
by hand...
On 9 Dec 2009, at 23:36, manolo gouy
Also tried to apply this patch, but with htis installed, my fltk
tests just segfault at strt.
I had to unwrap the patch by hand so it is likely that I corrupted
something in that process.
All compiles OK, but does not work...
On 9 Dec 2009, at 17:06, manolo gouy wrote:
Here is the
Also tried to apply this patch, but with htis installed, my fltk
tests just segfault at strt.
I had to unwrap the patch by hand so it is likely that I corrupted
something in that process.
All compiles OK, but does not work...
On 9 Dec 2009, at 17:06, manolo gouy wrote:
Here is the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Yes, what works now is assigning a callback and a data pointer to
a menu bar item with, e.g.,
It's good that you tell me the crashes you detect, but do you also
see many things working well as I do?
Yes - things mostly work now.
Nobody mentions that because there are natural cycles to things; when
things mostly work, only faults get reported. That is a Good Sign.
People usually only
Matthias Melcher wrote:
Could you please repost the instructions on how to remove the PPC64 build
from the Release settings? I must have deleted that mail :-(
It's on the STR page in the archives, posted by manolo at 15:08 Dec 07, 2009
Link: http://www.fltk.org/str.php?L2221
BTW: a big
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
OK I have better grasped the Fl_Sys_Menu_Bar logic, and have corrected
Fl_Sys_Menu_Bar.cxx and Fl_Cocoa.mm
imacarthur wrote:
(BTW: Matt do you know what the last pre-cocoa
revision number is?) in the meantime for my builds.
rev. 6950 is the last pre-cocoa version.
But what about disabling cocoa in config.h, at least as a test?
If Manolo's statement that he wrote when he started is true, then
this
On 09.12.2009, at 22:16, Albrecht Schlosser wrote:
imacarthur wrote:
(BTW: Matt do you know what the last pre-cocoa
revision number is?) in the meantime for my builds.
rev. 6950 is the last pre-cocoa version.
But what about disabling cocoa in config.h, at least as a test?
If
Hmmm. Well, here goes: the latest svn builds OK at the command line
on this 10.4.11 / PPC mac, and the programs in the test folder seem
to be OK. so far as I can tell.
However, an app of my own, that was developed on this box using
fltk-1.3, now builds OK but has some odd behaviours...
-
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Are any of these fixes checked in?
I'm trying to test changes to Fl_Tree on OSX and can't compile fltk 1.3.x
svn
1 - 100 of 130 matches
Mail list logo
