On 30 Jun 2010, at 9:16, Yuri wrote:
So, what I would recommend as best is: link static to the fltk
libs but
link shared to the system libs.
I generally don't even keep a set of fltk .so libs around these
days...
Others may take a different view, of course!
static linkage in some
On 24 Jun 2010, at 17:18, Domingo Alvarez Duarte wrote:
It seems that -mms-bitfields is one of then, I searched the net and
I'm
not sure if this is from gcc 4.5 or TDMGCC specific .
Are you saying that -mms-bitfields is no longer supported by the gcc
you are using?
I suspect that
On 24 Jun 2010, at 18:23, Manolo Gouy wrote:
In my hands, this small test program displays all scripts well
under Mac OS X, but does not display the Hiragana part under X11+Xft,
though cyrillic and greek output correctly.
OK - you haven't set any font, so you'll just be getting the system
On 23 Jun 2010, at 17:51, Domingo Alvarez Duarte wrote:
Today I've tryied tdmgcc 4.5 mingw and I noticed that FLTK doesn't
compile
with it, apparently gcc 4.5 removed several compiler options that the
configure script test.
Do you know which ones?
On 21 Jun 2010, at 17:19, Manolo Gouy wrote:
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2339
Version: 1.3-current
Fix Version: 1.3-current (r7652)
Fixed in Subversion repository.
Added rtl_draw member function to class Fl_Graphics_Driver
to close this STR.
Right to
On 20 Jun 2010, at 10:33, manolo gouy wrote:
First, fl_push_no_clip() calls CGContextRestoreGState, so it must
be called after a CGContextSaveGState call, or an error message
occurs.
OK - I see taht.
Second, fl_push_no_clip() calls Fl_X::q_fill_context() which reverses
Y coordinates so
On 15 Jun 2010, at 18:05, Greg Ercolano wrote:
I've not been watching this thread carefully,
but I wonder if this isn't one of those window manager hints
we're supposed to set for various types of windows that's causing
this?
Either something we're setting, or
On 13 Jun 2010, at 9:02, Domingo Alvarez Duarte wrote:
I have an apllication that has a menubar and it works fine on
windows but
on linux the menubar drawing is noticeable slow.
It's easy to see the problem open fluid and navigate the menubar with
keyboard and even with the mouse you can
On 11 Jun 2010, at 21:05, Csaba Biegl wrote:
I'd say the whole RGBA image drawing should be redone using the
Xrender extension, with the current code left in there as a
fallback for stone age X servers. Based on a quick look at its
sources, 2.0 seems to be doing something like this
Manolo,
Is there any chance you can take a look at STR 2257 please?
There's some ongoing regression with handling offscreen context's on
OSX with fltk-1.3, and I have no idea what is causing it.
I think you are the only one who might be able to figure it out!
It's starting to bite me, as I
Mike, Greg et al,
For the examples directory, I was thinking of putting in a few things
I hope might be helpful, but I want to put them under a quite non-
restrictive license, as I imagine people will want to use them as the
basis for their own work.
So for things we just want to give away
On 9 Jun 2010, at 10:12, Albrecht Schlosser wrote:
On 07.06.2010, Csaba Biegl wrote:
I also just tested this on Slackware 13.0 64 bit. Can confirm
everything Ian said. Disabling XDBE fixes quite a few issues:
Csaba, thanks for testing and the report. I'm confident that
svn -r 7636 fixes
On 9 Jun 2010, at 16:59, Albrecht Schlosser wrote:
I made all windows non-buffered (Fl_Window), and this worked
okay.
Note: the mandelbrot demo program has been converted from using
Fl_Window
to using Fl_Double_Window together with a lot of other demo programs:
I'll have a look if I
Hmm, it occurs to me: should the example programs have
LGPL headers same as the FLTK code does, or should they have regular
*GPL* headers since they're not really library code?
For instance, the end user might start with an example program
and derive their own
The stock fltk-1.3 configure assumes --enable-xdbe, and it appears
that does not work satisfactorily, at least under ubuntu/gnome/
compiz/whatever that these boxes have.
I assume it is *not* a graphics driver problem as one box is ATI,
the other nvidia.
Yep, so do I. I can see
Another reference point is that, on my newly built ubuntu 10.4
reference machines (one ATI graphics, one nvidia graphics) the
overlay test does not show the red overlay rectangle.
I'm pretty sure (but did not test) that 1.1.10 was OK, so this also
looks like a 1.3 regression... Related?
On 24 May 2010, at 20:09, Greg Ercolano wrote:
I haven't seen anyone in the FLTK community submit a scrollable
tab widget. If someone did, then that widget would definitely want
to have no limits on the number of tabs. Until then, though, there's
probably no need,
On 20 May 2010, at 11:12, Matthias Melcher wrote:
I think we should not support CP1252 at all. An illegal UTF-8
sequence should generate the illegal character which in some
cases is a box shaped character or a question mark.
I think I disagree, I'm afraid to say.
Better heads than mine
On 18 May 2010, at 14:09, Duncan Gibson wrote:
The downside is that although the fl_utf8decode() strategy (with
CP1252 C1 0x80-0x9f conversion) is a lot safer than the fl_utf8len
() one,
it is certainly not as Fast and Light. But if we don't convert
to use fl_utf8decode() and fl_utf8fwd(),
On 18 May 2010, at 19:24, Duncan Gibson wrote:
Me:
The downside is that although the fl_utf8decode() strategy
(with CP1252 C1 0x80-0x9f conversion) is a lot safer than
the fl_utf8len() one, it is certainly not as Fast and Light.
Well on my box, the following program says it's approx 1.5 :
On 16 May 2010, at 9:49, Domingo Alvarez Duarte wrote:
Here is a patch that shows several places where FL_EXPORT is missing
OK - handy.
plus some structs changed to classes.
OK, but; Why are the structs wrong? It seems to me the public
visibility is harmless (and possibly good) here, so
On 14 May 2010, at 15:00, B Wise wrote:
I have been compiling and using FLTK 1.1.x for a few years, and I
decided to upgrade to 1.3. However, some problem is making it
impossible to compile. I tried a few separate versions of FLTK
1.3.x and I get the same problems regardless of which
On 12 May 2010, at 18:41, Greg Ercolano wrote:
It's dying because the pointer 'transparent_c' is NULL
at the time the fl_draw_pixmap() function in fl_draw_pixmap.cxx
calls make_unused_color().
Hmm, I think this is one of Manolo's additions for the Fl_device /
Fl_Printer
On 2 May 2010, at 10:00, Matthias Melcher wrote:
On 02.05.2010, at 10:47, imacarthur wrote:
On 1 May 2010, at 22:44, Matthias Melcher wrote:
--dbvisualc6 dbname targetpath : create all IDE files for an
Xcode3 project
I thought this was a typo in Matt's post, but it seems
On 27 Apr 2010, at 17:52, Michael Sweet wrote:
On Apr 26, 2010, at 3:40 PM, Greg Ercolano wrote:
Default build of fltk 1.3.x current fails on a Power PC (non-
intel)
machine running 10.4.11 with gcc 3.3 (gcc_select 3.3).
...
Fl_Gl_Device_Plugin.cxx:101: error:
On 22 Apr 2010, at 18:55, Duncan Gibson wrote:
If I kick off the both test/editor to read misc/cp1252*.txt I get:
1.3: cp1252.txt:
missing columns 128 onward, ie no 8-bit chars,
and missing the right wall of the table too
[I've switched workspaces and it has hung too]
On 20 Apr 2010, at 23:07, Duncan Gibson wrote:
Anyway, this has been committed and is now live...
Lovely.
I wonder if Fl_Text_Buffer should be tweaked to use the new
fl_wcwidth(char*) directly rather than fl_wcwidth_(ucs) version then?
It (Fl_Text_Buffer character_width) seems to be
On 17 Apr 2010, at 12:25, Matthias Melcher wrote:
This is possible because my version of FLTK can open windows on
different screens, even when they use different window managers. I
believe that this feature would set FLTK apart from other GUI
libraries and make it very valuable for
On 17 Apr 2010, at 23:31, Stewart Dickson wrote:
I just downloaded
http://ftp2.easysw.com/pub/fltk/snapshots/fltk-1.3.x-r7513.tar.gz
built and installed it using:
cd /usr/local/src/fltk-1.3.x-r7513
./configure
make
sudo make install
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc.
On 18 Apr 2010, at 9:56, manolo gouy wrote:
I realize you may also have to add
-framework AudioToolbox
To sum up, you should have this in your link command(s):
-framework Carbon -framework AudioToolbox -framework Cocoa
There's a thing: do we actually use anything from framework Carbon
On 18 Apr 2010, at 20:05, Duncan Gibson wrote:
Just to be on the safe side, and before I start tweaking Makefiles etc
to pull these changes into the main build, I would very much
appreciate
it if some kind users out there could check that the equivalent of:
gcc -c
On 16 Apr 2010, at 16:24, manolo gouy wrote:
The issue is whether we want to draw all of UTF, and it's far too
big
to be memorized glyph per glyph, or only latin characters, and the
single glyph texture approach becomes possible and preferable.
Ah - but no text is really all that likely
On 13 Apr 2010, at 22:41, Kurt Van Dijck wrote:
It's not my intention to start discussing TinyX vs. dfb, I'm just
interested and know not that much of dfb.
* Does dfb make use of hardware acceleration in userspace, or kernel
framebuffer drivers?
My understanding (and this is probably wrong)
On 13 Apr 2010, at 23:15, Michael Sweet wrote:
It's been a while, but
Mike, how can you say that - you were *the* GL guy...! :-)
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
On 11 Apr 2010, at 14:37, Matthias Melcher wrote:
I suggest moving them all into a folder named depreciated and
wait two weeks. If nobody complains, we can still remove them.
That would be deprecated rather than depreciated I suggest. The
former means still available, but recommended not
On 11 Apr 2010, at 16:12, Matthias Melcher wrote:
Ah, sure, you are right. Deprecated it is: to express disapproval.
Though I think the literal meaning is something more like to pray
for relief from...
So when we say that a function is deprecated, we are saying we pray
that no one has to
On 10 Apr 2010, at 11:33, Duncan Gibson wrote:
src/xutf8/fl_wcwidth.c
#include mk_wcwidth.c
int fl_wcwidth(unsigned int ucs) {
return mk_wcwidth(ucs);
}
I liked my version better...
but then it struck me that there are no existing fl_* files in
On 6 Apr 2010, at 19:33, Albrecht Schlosser wrote:
I will push this minimal fix into svn for now,
Yep, saw your commit. You killed one (indent) byte ;-)
Ah. Sorry about that.
I was fiddling about in the code anyway, must have made a mess.
You see, if we had some automatic way of sorting the
On 5 Apr 2010, at 19:31, Albrecht Schlosser wrote:
Will do, but will be later today - note that from a quick
inspection of
the patch, that looks fine.
TIA for testing ...
Well...
I've tested it on every linux box I have easy access to here at home,
and it works just fine.
But... it
On 2 Apr 2010, at 17:59, Matthias Melcher wrote:
Looking at fltk-2, Bill already saw (and solved) the issue:
OK - that looks like the way to go for fltk3 to, then, I guess?
(I bloody hate using namespace blah by the way... It completely
negates the usefulness of namespaces...)
It is
On 2 Apr 2010, at 18:13, Matthias Melcher wrote:
Thanks for fixing my horrible English spelling!
Better than my German...
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
On 3 Apr 2010, at 5:29, Greg Ercolano wrote:
I think maybe Microsoft's IDE has some nutty default where 'tab'
is set to '4' or something weird. (?not sure?)
Actually, I think it is worse than that - I'm pretty sure the editor
in VC6 used to default to 3.
I can't comment on the
On 3 Apr 2010, at 17:07, none @easysw.com, ff@.easysw.com (none)
none .easysw.com wrote:
⌘ command
Though apparently it's called a St Johns Arms and is used in
signage to denote a place of interest.
Huh, well there you go!
___
fltk-dev
On 31 Mar 2010, at 17:54, manolo gouy wrote:
Nothing is ready for the X11 platform.
That's where the question mark is.
For X11 there are essentially two separate (but very similar)
mechanisms to consider, the ICCM's Selection Buffer mechanism and the
later XDnD mechanism.
It is not so
On 26 Mar 2010, at 16:12, Greg Ercolano wrote:
Cmake seems to possibly be the direction FLTK wants to go
for multi-compiler support. Though I'd see if everyone else
is in agreement on this; I'm not sure this is quite written
in stone yet..
Greg, I think there may be
On 19 Mar 2010, at 14:40, Domingo Alvarez Duarte wrote:
MacArthur, Ian (SELEX GALILEO, UK) wrote:
-u old_file new_file changes.patch
Every day is a day to learn something !
Thanks a lot for the explanation, and here it has:
diff -u G:\tmp\c\fltk-svn\FL\Fl.H Fl.H Fl.H.patch
diff -u
On 19 Mar 2010, at 19:31, Domingo Alvarez Duarte wrote:
Thanks again for the tip, this way is easier !
Here it is again using this method, and also I added parameter to the
other typedefs too.
Here it is again with a better style for parameters, basically a
space after commas.
Patch
On 14 Mar 2010, at 9:22, manolo gouy wrote:
About the interrogative comment added, I imagine by Matt, at line
322 of file src/fl_font_mac.cxx:
Just for the record (and not commenting at all on the actual
question!) under svn, if you need to know who/when a change was made,
use:
On 14 Mar 2010, at 19:35, Albrecht Schlosser wrote:
As in the development branch, this menu can be used to print the
application's front window.
This is for testing purposes only and should be removed shortly.
I'm thinking of replacing it with a global shortcut, e.g.
CTRL-SHIFT-P, so that
On 14 Mar 2010, at 19:57, Albrecht Schlosser wrote:
PS: you'd better not use 'join' w/o a path in 123/joinall:
$ which join ; join --version
/usr/bin/join
join (GNU coreutils) 6.10
Also on OSX, as it happens...
immpc4:~ ian$ which join
/usr/bin/join
immpc4:~ ian$ man join
JOIN(1)
On 14 Mar 2010, at 12:01, Simon Lewis wrote:
Currently Fedora 12 ships with fltk 1.1 libs (currently 1.1.9 with
1.1.10 in testing)
It is not possible to install 1.3 libs as a number of programs
including Zynsubaddfx, html2doc etc.. depend on the 1.1 version libs.
Yup - this is a tricky
Please give your votes for the following two questions:
(1) Is it okay to do the merger ?
+1
(2) Should it be done ASAP ?
+1
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
On 11 Mar 2010, at 18:51, Matthias Melcher wrote:
I would be willing to put the time in, but I'd also have to rely on
the other Core Devs. I'd suggest a special mailing list for a
possible participant.
I'd help out where I could, but I can't promise to commit the time;
things are a bit
On 7 Mar 2010, at 9:09, Domingo Alvarez Duarte wrote:
Now that you alert me about coding standards I did ask my friend
google
and he told me about this tool:
http://invisible-island.net/bcpp/bcpp.html
I'm surprised you did not just use gnu indent.
It is very powerful, and available by
For the other one, some testing seems needed to make sure that
wheel movements don't become exagerately fast after this
multiplication by 10. I don't have here the development environment
to test. May be you've already tested that. Also the Qt solution
is what you suggest, so the patch seems
On 2 Mar 2010, at 16:21, Albrecht Schlosser wrote:
I can imagine testing the DISPLAY
environment variable and, if set, switching to Fl_X_Display, but
otherwise use the (native) Fl_Display device.
It might have to be a bit smarter than that - I often have an X-
server running on this Mac (I
On 2 Mar 2010, at 10:24, Albrecht Schlosser wrote:
Hmm, we fixed some already, but this is important. Can you tell us
which Fl_xyz this was about?
Testing with r7194, Manolo has now fixed those warnings...
All I got this time (warning wise) is:
Compiling fl_font.cxx...
fl_font_mac.cxx:38:
On 21 Feb 2010, at 10:29, manolo gouy wrote:
P.S. I have seen that, without the 0.5 pixel magical offset, pixmaps
are displayed blurred. I slowly begin to understand, with the
explanations you gave before, the purpose of this 0.5 pixel quantity.
Manolo,
In case it helps, there's a very
On 19 Feb 2010, at 9:25, Albrecht Schlosser wrote:
I also looked at Roman Kantor's Fl_Device patch [1] for FLTK 1.1.4,
and this looks much more like a way to get PostScript rendering to
work with printer devices.
NOTE: I think this is what is in the experimental fltk-1.2 tree, is
it not?
On 16 Feb 2010, at 20:12, Dufour wrote:
I will use the offset drawing method. It's a part of the tutorial
I don't quite understand. Do you have some examples of how you
would do that?
This thread is off-topic for this forum.
This forum is to be used to discuss development of the
On 16 Feb 2010, at 20:31, Evan Laforge wrote:
Fl_Text_Display is in a similar position, since it's too slow to be
usable.
I suspect that the underlying text engine is actually pretty efficient.
I also suspect, though, that when we redraw the text display, we are
re-rendering far too much
On 14 Feb 2010, at 11:04, Dufour wrote:
I have a very simple question. Do you plan to use more C++ features
in the future for FLTK? Like std::string, functors, STL, etc...
This question, or some similar variant of it, comes up every now and
then - so far the answer has always been; well,
On 14 Feb 2010, at 1:18, Evan Laforge wrote:
So from looking around in Fl_cocoa.mm I couldn't help but notice fltk
has this whole complicated system for handling non-ascii text input
that seems to be incompatible with the system provided one. That
probably made sense for X which has (or
On 14 Feb 2010, at 16:07, s...@sjssoftware.com wrote:
Ian, I don't want to be adversarial,
It's OK - I respect your input; I've seen plenty of stuff from you to
know that you know your stuff, and value your opinions: Tell me I'm
wrong and I'll believe you!
Use it or don't, but thinking
On 14 Feb 2010, at 18:02, Evan Laforge wrote:
Fltk's own, historical, compose key mechanism does not seem to me to
be involved (indeed I suspect that mainly handles the typing of LGC
glyphs that don't appear on a your keyboard, e.g. me typing ß on a UK
keyboard that has no key for it...)
On 12 Feb 2010, at 16:50, Greg Ercolano wrote:
I don't use the gnome window manager much on my Ubuntu 8.04 box,
but I am noticing all FLTK apps (1.1.x, 1.3.x, 2.x) have an 'X' cursor
by default in that environment, whereas other apps have normal
arrows or I bars.
Should FLTK set the
On 12 Feb 2010, at 19:23, Emil wrote:
Emil wrote:
Hello!
Is FLTK2 supported? If not, then why?
The official stance on the various FLTK releases is:
http://fltk.org/articles.php?L825+I0+T+P1+Q
There was a big thread on the nitty gritty details last summer,
so to prevent a lot of typing
On 8 Feb 2010, at 18:36, Albrecht Schlosser wrote:
However, since type() [3] is a fast inline method and the new
proposed methods are virtual, there might be a small performance
penalty if we would replace this all over in the FLTK core.
Yup - it's been a long time since I measured it, and
On 8 Feb 2010, at 19:09, Evan Laforge wrote:
But you'd still have to cast, right? To avoid casting (in the client
code at least) wouldn't you need:
virtual Fl_Group *Fl_Widget::as_group() const
Evan,
I'm not sure I understand... Fl_Group derives from Fl_Widget, so they
are the same as
On 8 Feb 2010, at 21:39, Evan Laforge wrote:
I'm not sure I understand... Fl_Group derives from Fl_Widget, so they
are the same as far as this is concerned... The method itself
returns int (in Albrecht's implementation) but that's in effect a
boolean... There must be something here that I am
On 7 Feb 2010, at 9:28, Albrecht Schlosser wrote:
Anyway: the problem with using vector drawing, filling, etc.
with PostScript would be to redirect all drawing functions
to the PostScript device (driver) and to implement a full set
of drawing primitives, together with all that is needed to
On 7 Feb 2010, at 11:58, Andreas Ekstrand wrote:
BTW, is it intentional to make the member variables of Fl_Group
protected and nothing but the destructor virtual? Makes it hard to
derive from and specialize...
I'm not sure I follow... they are protected (not private)
specifically so
On 6 Feb 2010, at 17:55, Albrecht Schlosser wrote:
Linux/Unix support: what should be done?
snip
Any ideas about Linux/Unix printing support and about this great
start for
printing support in FLTK? Anybody?
I suppose, when it comes down to it, Mike is *the* linux printing
guy... If he
On 6 Feb 2010, at 14:30, Andreas Ekstrand wrote:
We use an Fl_Scroll with a large number of buttons to accomplish a
fancy tree-view in our application. After an update to the latest
FLTK 1.3, we discovered a major fall in performance when clearing
the scroll in order to re-calculate
On 24 Jan 2010, at 10:42, Matthias Melcher wrote:
On 23.01.2010, at 19:50, Evan Laforge wrote:
Hi, here are some regressions with fltk 1.3. I reduced the file
demonstrating the problem as much as possible, it's still 150 lines
but should be clear. I haven't dug into the fltk side yet to
On 24 Jan 2010, at 15:53, manolo gouy wrote:
So... As I read it, after Manolo's patches were merged, this is
probably not active for the 64-bit builds, but is active for 32-bit
builds, either Quartz or Cocoa.
It would be interesting to hear what Evan finds running his test for:
- 64-bit
On 23 Jan 2010, at 14:02, Albrecht Schlosser wrote:
Albrecht Schlosser wrote:
My main point is that we are consistently using WIN32 or _WIN32
everywhere. If we decide to use _WIN32 everywhere, then we must
also change the define in fltk-config and Makefiles (or makeinclude)
or elsewhere.
Hi Evan,
I suspect that (apart from you!) Manolo's the only person who knows
what you just said!
Does sound like you are right though.
On 20 Jan 2010, at 9:52, Evan Laforge wrote:
I've just been upgrading my app to fltk 1.3 with cocoa... great work,
and thanks for doing this!
That said,
On 15 Jan 2010, at 11:46, manolo gouy wrote:
What I have been doing for years is to include FNFC as a part
of the source code of my app, and all of this code is transformed by
Debian maintainers into a package dependant on the standard
FLTK Debian package.
Thus no change to Debian's FLTK
On 16 Jan 2010, at 16:27, manolo gouy wrote:
As it is now, we'll have to maintain a separate FNFC code. But,
because
FLTK 1.1.x is now frozen, this is not a problem, a frozen FNFC will
suffice.
Yes - I think so. The freeze of 1.1.10 should mean that the
standalone FNFC can also
On 13 Jan 2010, at 22:56, Greg Ercolano wrote:
OK, I've got FNFC building under linux (Ubuntu8) and OSX,
so I figure it's ready to check in.
Under OSX I tested with both COCOA enabled and disabled
(to test both sections of the FNFC code).
Windows build files haven't been modified, so
On 1 Jan 2010, at 20:32, Albrecht Schlosser wrote:
imacarthur wrote:
Just tested this on Vista with mingw, and it fails exactly as
Greg's VS
example fails (because mingw mainly just wraps the native system
libs in
general.)
That's strange. I can't confirm this with WinXP
On 1 Jan 2010, at 16:28, Matthias Melcher wrote:
BTW: Does anyone know if the win32 libs have built-in UUID functions,
like the APPLE stuff does, that we could just use instead?
There should be functions, at least starting with XP. For earlier
verions, we can use a combination of time,
On 30 Dec 2009, at 23:14, Greg Ercolano wrote:
..and the output on win32 was just like linux, making the above code
cross platform compilable:
Z:\erco\examples\c.\test-snprintf_s
RET=6, SS='123456': TEST RESULT: OK
RET=7, SS='1234567': TEST RESULT: OK
RET=-1, SS='1234567':
Albrecht,
This is probably of little or no use to you, but I posted my add_fd()
test code in a zip here:
http://9edge.dyndns.org/tests/mcast-tests.zip
Might be of some use.
Note that, as it happens, this also incorporates my code for finding
(in a cross-platform fashion) the home
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 8:31, Albrecht Schlosser wrote:
The events argument is tested for POLLIN etc., but is defined to
use the FL_READ etc. constants in the interface documentation.
http://www.fltk.org/doc-1.3/
classFl.html#76b6c3f9043d22034a47177914fd4054
Now, looking at this again, I
On 20 Dec 2009, at 10:12, manolo gouy wrote:
I've stumbled across an odd thing testing Manolo's most excellent
cocoa port, and I don't understand it so hoped someone else could
shed some light...
What happens in the Carbon FLTK is that cmd-X keystrokes assigned
to fl_sys_menu items don't
All,
I've stumbled across an odd thing testing Manolo's most excellent
cocoa port, and I don't understand it so hoped someone else could
shed some light...
A bit of background: My music editor code makes heavy use of keyboard
shortcuts to ease the editing process, but under OSX with the
On 17 Dec 2009, at 15:46, Greg Ercolano wrote:
To be sure: Greg, would you please check what the definition of
POLL* in winsock2.h is?
Here's what's defined in the winsock2.h file:
snip
So if I read that right, the net effect is:
#define POLLIN 0x0300
#define
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,
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,
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
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
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_
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:
1 - 100 of 168 matches
Mail list logo
