> svn -r 7280 works okay, 7281 ff. is broken on Windows and Linux.
>
> Ian, what do you see?
Just tested. Here's what I did:
Backed out my Makefile/makedepend changes in case they clash with
Albrecht's.
Then svn up to r7287.
Edit config.h to #define USE_PRINT_BUTTON 1
Then make clean ; make
> I also had the white page symptom. But, after a full recompile,
> everything turned in place. So I recommend a fresh recompile,
> also for MSWindows.
Hmmm - not working for me... (winXP / Msys / mingw)
Tried this:
$ svn up ; make clean ; make
And this happened:
Compiling Fl_Gl_Window.cxx...
> > Looks like some of yesterday's patches to the Fl_Printer / Fl_Device
> > stuff have broken the win32 includes somewhat...
> >
> > $ svnversion .
> > 7281
> > Thoughts?
>
> Fixed in 7282 :-)
>
> It's somewhat strange, since it compiles on Linux and Mac, but w/o
> looking deeper, I assume th
Gents,
Looks like some of yesterday's patches to the Fl_Printer / Fl_Device
stuff have broken the win32 includes somewhat...
Compiling Fl_Window_iconize.cxx...
In file included from ../FL/win32.H:48,
from ../FL/x.H:39,
from Fl_Window_iconize.cxx:28:
../FL/Fl_De
> - Don't you believe we should remove the "Print front window"
> window of MSWin + X11 platforms before next friday's snapshot ?
I'd vote yes on this one...
> - I would suggest to keep the corresponding Mac application menu
> item because it is probably useful and does no harm (I've removed
> i
> 1) Fl.cxx (a C++ file) seems to include..
Though explicitly compiled a obj-c++ in the Makefile for that very
reason...
I see that Manolo has pushed a change for this into svn - does it help?
--
Ian
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon,
Found a little feature (very minor) probably was always there in the
fl_printer tree too but I never noticed before.
With a fresh checkout of fltk-1.3, on winXP, running the test/cube.exe
demo, I notice that the menu button that has been added to access the GL
print cb is:
- too tall to fit in t
> Ever since, "." - the current directory - is first in my
> $(PATH) variable ;-)
Ha - wrong solution!
You need to teach your fingers to automatically type "./" before you
type any "local" command.
Soon it becomes a reflex and doesn't slow you down at all, with less
potential for the Bad Man t
> I checked out latest 1.3 SVN and it built OK on my
> intel mac running Tiger.
>
> Tried to build the same directory on my PPC mac running Tiger
> (make distclean; make), but it failed to build Fl.o
> with these errors:
OK - that's odd; my Mac (at home) is an old PPC box run
> > hm. does this also mean that someone can render utf8 text into
> > Fl_GL_Window without external libraries?
>
> At least under Mac OS X, the present 1.3 code renders any utf
> string of any font in Fl_Gl_Window's using textures.
I think that recent winXX variants also cope with this OK, IIRC
> If you mean that we should ask the developers for
> their votes to
> merge the development branch back to the main 1.3 branch,
> then YES.
I'd vote yes on this - the testing I've done suggests it works, and so
far all my other code still *seems* to build and run OK.
I'm sure there will be iss
> >> http://www.fltk.org/articles.php?L980
About Fl_Gl_Device... Would the idea be to direct *all* fltk rendering
via the GL layer then, and use GL for all drawing?
And does that foreshadow the reappearance of the old "shiny" demo, which
I always quite liked?
> See the last paragraph: m
> Should we apply as mentors?
Can any of us commit the time to do the mentoring right?
In the past I have been peripherally involved in a few projects that did
GSoC, and what I saw was that, on the projects that Did It Right, the
mentors put quite a lot of time and effort in, the students produc
> > Does anyone know if the fltk repo's are accessible other
> than by http?
> I'm using https:
Forgot to follow-up on this: For the record, switching to https has
worked for me and I can access the repos once more, bypassing the
blocking of webdav on the http proxy.
So that works - at leas
> This simple program crashes when trying print Fl_Help_View, with
> Fl_PSfile_Device it don't crash but generates an invalid
> postscript file.
It is probably not valid to call end_page() without first calling
start_page(), so I think you are getting segfaults trying to delete page
items that
> Fl_Bitmap now prints with correct color and transparency on MSWindows.
Great!
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 02426132
> I can do it. Do you have any particular wording in mind?
Not really, sorry. I just thought that we should make it more obvious
that fltk2 is deprecated and *not* the latest version.
But I don't know how best to write that.
I guess it is the "latest version" thing that is maybe key here? I gue
> I'm using https:
Cheers Albrecht, I'll give that a try (though I suspect I'll be no
better off anyway!)
Thanks for the tips,
--
Ian
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 0242
Does anyone know if the fltk repo's are accessible other than by http?
The monkeys that guard the gates here at work, have decided to block the
webdav http extensions, which of course means that svn now chokes when I
try and "svn up" my checked out copies.
Of course, the odds are that they will
All,
Who has the access rights, and the necessary html skilz, to tweak the
Download page on the website?
I'm thinking that we should rework the section about svn at the foot of
that page to de-emphasize the fltk2 repo and direct folk to the fltk-1.3
repo in the first instance.
Maybe even add som
> >> Again, quoting from the v8a change.log file:
> >>
> >> "Add data source and destination managers for read from
> and write to
> >> memory buffers. New API functions jpeg_mem_src and jpeg_mem_dest."
> >
> > I must have overlooked that.
>
> I just implemented that for FLTK 1.3. It's alread
> > Great; I'll check that and the drag patch in tomorrow morning
> > when I get in. It can always be further refined later
> if need be.
>
>Done; fixes for mousewheel and right/middle drag events
> checked into svn r7213
Tested this with my Wacom puck. Seems to be doing the Right
> > I was mainly thinking that the bundled lib would be
> statically linked
> > anyway, so ABI differences are a Don't Care.
>
> I was more thinking of source compatibility here. There shouldn'n be
> any ABI problems, especially because the bundled jpeg lib has another
> name.
Yup - OK.
For n
> I say v7, but was not aware that there was v8 and v8a. I don't see
> any useful documentation on http://www.ijg.org/ that seems to be the
> official site, i.e. no release notes, no change log, ...
Yup - it is not the most verbose homepage...
However, it currently says (grabbed right now from m
All,
Do we want to think about upping our bundled version of libjpeg?
The reason I ask is that, after many years of quiescence (no updates
since 6b in March 1998) there seems to have been a flurry of activity,
pushing out a v7 last year and then a v8. Current is v8a as I type this
(though who kno
I had imagined that it would be feasible (and relatively
easy
using Roman's PostScript backend as a template) to write
a PDF
backend that would use the excellent PDFlibLite (usable
without restriction for open source software, but no
> Or maybe just assume anything less than 1 is 1,
> and don't scale at all.
Given my experience with the Wacom puck, that might be best?
I need to dig out a USB scrollmouse from somewhere and hook that up and
try it - maybe this eve...
So, what we are talking about is something lik
> imacarthur wrote:
> > I dug out the puck for my Wacom tablet on this OSX 10.4.11
> machine -
> > the puck has a mousewheel on it.
> >
> > Ran Greg's mousewheel test code, and in the shell I get [..]
> > +/-3 values appear when I roll the wheel one click. The bigger
> > numbers appear when
> Not a button, but the first "printer" in the printer selection box
> is "Print To File".
Cool.
> As I wrote before, I'm copying the fluid printing
> features, thus you can see it in action on Linux in fluid's
> File/print menu.
OK - I don't have a linux box to hand, and under win32 the fluid
> Currently the dialog pops up, I can select
> options, but then I let it fall back to the PS output. The fluid
> implementation doesn't create a file for printing, but pipes the
> output directly into the lp command.
Will there be a button on the print dialog for "save to PS file"?
That could
> I would more like to have an API to access defined printers etc., but
> that's a dream, isn't it? I *really* don't like
> interpretation of other
> programs' output.
CUPS can maybe do this for us?
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS1
> > I had expected that, like Fl_Gl_Window, my Cairo widget would appear
> > empty... So I'm not at all sure why that actually worked at all.
> > Probably I did not test it correctly...
>
> Just a guess: I don't know how your Cairo hooks work, but if Cairo
> uses the current display context set u
> Or, Ian, coming back to your way (as I interpret it). lpstat
> is invoked
> like this:
>
>lpstat = popen("lpstat -p -d", "r");
>
> I tried:
>
>lpstat = popen("LC_MESSAGES=C lpstat -p -d", "r");
>
> and this worked as well. Looks much cleaner to me, because it only
> modifies the lps
Did some more testing with r7194, to verify that it operates correctly
with my Cairo hooks.
Seems to be OK.
On the Mac, I also tried printing the "front window" that has my Cairo
rendered context in it (as a widget subclassed from Fl_Box) and was
surprised to discover that the window contents wer
> Just to keep you informed: I've copied the fluid printer dialog and
> started to integrate it in the PS printing functions. The
> dialog works,
> and I can get the values, but there are lots of global variables and
> functions that need adjustments. But I'm making progress. Nothing yet
> to sho
> I have also (boldly) added a new configuration called DebugX11
> that allows to build an X11-based FLTK-1.3-Fl_Printer on Mac OS X,
> and thus to test the Linux/Unix side of FLTK (remember that Mac OS X
> is on top of unix). All libraries and demos should readily compile,
> and they should also
> I reworked a bit the example proposed yesterday, and I'm resending it
> here, by the way how hard will be to have zoom at design time
> on fluid,
I'm not a big fan of supporting zoom within the toolkit.
Though if others want it, and are able to implement and support it, then
fair enough.
S
> > A lot of build-time warnings about "class FL_xyz has
> virtual functions
> > with non-virtual destructor" type stuff.
>
> Hmm, we fixed some already, but this is important. Can you tell us
> which Fl_xyz this was about?
Don't have that machine here - will post later.
I *think* it was fro
> There is a place to upload a binary so I can upload the
> compiled code I
> have here to be tested on other machines for the zombie proccess ?
Not as such - most folk just post them on their own website, if they
need to.
That said, a lot of people (i.e. me, for example) will not download
arb
> > IMHO 1.2 and 2.x died because nothing was ever officially
> released. I'd prefer to get the ABI "good enough" and release
> 1.3.0. When applied to the many apps out there, we will get
> plenty of feedback for fixing... .
>
> Yep, agreed.
>
> > 1.3 is already such a huge improvement over 1
All,
Some notes on testing r7187 of the printing patch on a few random
targets last night.
OSX PPC 10.4.11:
Build and runs OK. Not obviously slower than stock (though this
particular machine is slow by modern standards anyway...)
My offscreen tests worked OK, and printed OK.
Other tests seem to
> > - Roman's code allows to produce PS for levels 1, 2 or 3. What level
> > is it reasonable/useful to expect to be supported in
> today's printers ?
>
> Don't bother with Level 1. Level 2 is still widely used, and
> all current printers use Level 3.
Does level-3 function as a superset of l
> > Do we want to do it for 1.3 though? I can not say.
>
> Yes, that's the main question. We have some kind of catch-22
> situation:
> We can't get full (PS) printing support w/o device abstraction, but we
> must be sure that we want it (now). Last Friday we didn't have it at
> all, but Manol
> I'm compiling with pthread libraries, and also tested with
> mingw 3.4.5
> without pthread and have zombies as well,
I only ever use "native" threads and never use pthreads on windows, so
that might be a difference.
But right now, with mingw 3.4 on winXP I can't reproduce the effect you
desc
> We developers all don't want to have another "dead" project like
> FLTK 1.2 and now obviously also FLTK 2, so that we should be
> absolutely sure that
>
> (a) the code is okay and works as expected
> (b) it is the right way to go
> (c) it is possible to extend it later
> (d) it is accep
> It's a question to behave consistently if we scale/zooned the widgets
> size/position we should as well do the same with it's font size.
Why?
The behaviour you describe is consistent, and is pretty much what every
toolkit does. Indeed, I can't, off-hand, think of any that scale label
font size
> But, I should probably have been more explicit: what we really need to
> test (also) is the "normal" FLTK behavior on all platforms.
Ah. OK - that'll take a bit longer... Maybe a lot longer!
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A
> I ask all developers (and other willing testers) to check out the
> printing development branch [1], test it and give feedback. Thanks.
Just tried this on winXP / mingw and it appears to be working OK.
Built fine, and stuff does come out the printer.
I am not seeing the zombie process left
> To Matthias: It would be really good if you would not do much
> structural changes for UTF-8 now, since this might indeed complicate
> the merge. Currently I succeeded in merging the main branch changes
> into the printing branch, so that we would be able to do the merge-
> back easily.
I don'
> - Roman's code allows to produce PS for levels 1, 2 or 3. What level
> is it reasonable/useful to expect to be supported in today's
> printers ?
I don't really know the answer but: Is level 2 the best compromise?
In my specific case, I have some old Brother laser printers that use
"BrotherScr
> Agreed. Although the device abstraction is very interesting, it would
> IMHO be too big to do it before the release of 1.3.0. We can merge
> the current printing support back in the main 1.3 branch, and then
> we can release 1.3 after fixing the remaining UTF-8 things. With or
> without Linux
Just refreshing my mingw build this morning, got a few warnings that I
hadn't noticed before:
Fl_Native_File_Chooser_common.cxx:59: warning: 'char* strapp(char*,
const char*) ' defined but not used
Fl_Native_File_Chooser_WIN32.cxx:51: warning: 'void dnullprint(cha
> >> Indeed this printing patch was done through device abstraction.
>
> > That sounds just fantastic! Can we still combine this with the
> > work done for 1.3 printing?
>
> Q. Will the release of 1.3.0 fix the API/ABI for the 1.3.x series?
I imagine that it would.
And that the device abstracti
> > I *think* this STR is valid:
> > http://www.fltk.org/str.php?L2158=20
>
> Hey!
>
> It took me weeks of debugging to come up with that one line fix!
>
> :-)
And a very lovely fix it is too.
Also: You do realise, having found this bug, that this probably makes
you *the* expert on fixing bu
> UTF8 is working OK right now. I will go backwards through all
> functions and methods that use text and change their argument
> name to something_utf8 to mark it utf8-safe. The one huge
> effort will be Text_Buffer/Editor.
Though there are some "low hanging fruit" there too...
I *think* thi
> I am trying to do a simple single layer map editor like this one :
>
> http://www.choosetheforce.com/files/nov13_05/smee14.png
>
> How would you do a single layer map editor? Can you give me
> some piece of advice?
I'd probably render the whole lot in an fl_offscreen, to be honest, then
in
> > Evan: I tried your patch. With it the sudoku demo no longer
> > executes shortcuts of the system menu bar. So I won't commit it.
> > I retain the idea of removing unused variables. Thanks.
> > Is the FL_KEYUP event for cmd-keys really important ?
>
> Oh right, yes this would bypass the system
> Does anybody (Ian?) know why the vertical coordinates flip
> that transforms bottom-to-top quartz coordinates into top-to-bottom
> FLTK coordinates incorporates a 0.5 unit translation ?
This is probably more a Matthias question than me...
I'd guess (and this is just a guess wrt Quartz) it is fo
> > However, Evan's other problem is that the OSX text
> rendering is slow now
> > under 1.3 because of other changes to implement UTF8.
>
> This is all plain ascii, but I'm sure the utf8 changes are
> the root cause.
Yes - but ASCII is just UTF8... Just a very little part of it!
What I meant
> > Unfortunately, I still can't switch to 1.3 entirely because of the
> > Fl_Text_Display problems (text misplaced and too slow).
>
> Is this a Fl_Text_Display problem when displaying plain ascii, or is
> it related to using UTF-8, as in http://www.fltk.org/str.php?L2158 ?
Yes - I think that ST
> Unfortunately, I still can't switch to 1.3 entirely because of the
> Fl_Text_Display problems (text misplaced and too slow).
That one has "hard to fix" written all over it.
Ideas welcome...
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A
> > What would prevent you adopting it, though?
>
> My expectation about how long it would take for serious bugs
> in 1.3.x to get addressed. If the FLTK maintainers consider
> 1.3.x to be pre-release, I wouldn't anticpate the FLTK
> developers miss a football match just to fix outstanding bu
> BTW, is there any sense of when FLTK
> 1.3.0 will be released?
Not so far - just "when it's done"... Help always welcome, of course.
> I'm trying to gauge whether or not
> we should adopt it yet.
It works OK for me. The API seems to be largely stable, and pretty well
back-compatible with f
> I have uploaded in the new print-support-dedicated branch
> (branch-1.3-Fl_Printer) all current changes.
> Interested developers may check it out and test it.
> Presently, many things run well under MSWindows and Mac OS X.
> I have also created a (temporary in my mind) new directory, doc,
> cont
> Is anyone currently maintaining CMake support in 1.3.x?
No, I don't think the cmake files are maintained.
> If
> not, and if I get it working, should I submit patches for my
> work? And if so, to whom?
File an STR against 1.3 to hold any patches you produce, thanks.
http://www.fltk.org/s
> Conversely, I use BullzipPDFPrinter (freeware) under MSWindows
> not to waste printer paper. It's at
> http://www.bullzip.com/download.php
> (I run MSWindows within the excellent VirtualBox on my Mac).
Cool, didn't know that one existed. Interesting.
It looks like it pretty much automatically
> BTW.: what do you use for testing on the Mac? Is there a way
> to redirect the printer output to a {PS|PDF} file or maybe as
> a PS stream to a TCP socket?
Yes, the Mac printer dialog has preview and output to file options that
generate PDF, so it is trivial to generate PDF output.
SELEX Gal
> As an aside, is there an official reason to use int instead of bool?
> I notice fltk prefers int. is_ in the function name is clear enough,
> but bool is still better documentation. Oh, also why I suggested
> as_group is because there's a common convention that is_ is for a
> predicate, but th
> I reverted the change in svn for now and I will perhaps not be able
> to work on this in the next few days. It's a pity that it didn't
> work, but I knew that there was an inconsistent state during the
> delete loop. I didn't expect this fix_focus/send_event problem
> though, but this is definit
> imacarthur wrote:
> > About 20-plus years ago, I wrote a PS to CGM "interpreter" for a
> > display unit we had.
>
> Yikes -- sounds like a big project to parse postscript
> and convert..!
Not so bad as it sounds... The device who's output we were processing
only used a subset of all t
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
> > # svn pl tree.dsp
> > Properties on 'tree.dsp':
> > svn:eol-style
> > --- snip
> >
> > ..maybe that's just the way SVN is.
>
> You need "svn pl -v" to see the values.
> And yes, they're there.
I never understood why they (svn) did it like that; it does seem very
odd - you ask for the
> > Please note: I removed the check for the MAJOR/MINOR being 1.3 or
> > greater, since the code checked in will now always be 1.3
> or greater.
> > Seems better not to confuse this check in with 1.1.x, as the 1.1.x
> > line is being stopped at 1.1.10, and the FNFC included in FLTK won't
>
Hi Mike,
> > +#if !(defined WIN32) && !(defined __APPLE__)
>
> This should be:
>
>#if !defined(WIN32) && !defined(__APPLE__)
Ah, OK.
Is this a portability thing, or a coding convention, or...?
I ask because the way I had it (i.e. the "!(defined WIN32)" way) seems
to work OK, and now I loo
> > the new files lack their correct SVN properties, and the
> > test/ folder should have an additional svn:ignore for
> > "native-filechooser". I can add the SVN properties, if you
> > like - please tell me.
>
> Ahh, OK -- this I don't know anything about.
> Yes, please do make these
> > OK - but can we assume that the mingw/cygwin builds
> probably *will*
> > build it, since they use the autoconf output the same as linux?
>
> That sounds correct, but I don't have those build environments
> to verify.
Tested with mingw on winXP. Seems to work OK. Two warnings
> My recommendation would be the last option, because this would
> be the best way for embedded targets and other memory constrained
> systems, if it works as I believe (but this needs further
> verification and tests with FNFC).
Been playing about some more with this - it works OK.
If Fl_File_
> > - and probaly other thngs I do not know about...
>
> One of them: require the user program to call it and don't call it
> from Fl_Native_File_Chooser. This would give the user the option
> to use the images or not and open the possibility to link w/o
> libfltk_images. I'm pretty sure that my
> Since Fl_File_Browser *fileList is a private field of the
> Fl_File_Chooser object, even subclasses won't be able to access
> it, unless it's made protected or FNFC is made a friend of
> Fl_File_Chooser. So there's no way out of modifying
> the Fl_File_Chooser object, except using my dirty hack.
Manolo,
Just a thought (and I have not looked at the code so this is probably
wrong) but rather than modifying the Fl_File_Chooser object, could the
FNFC derive a widget from it, where we could add methods to get at these
things...?
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher
> I have a seemingly catch-22 situation with
> Fl_Native_File_Chooser (FNFC).
>
> It seems to make sense to have this widget be part of libfltk.a
> (as opposed to libfltk_images.a)
>
> The Linux version of Fl_Native_File_Chooser calls
> Fl_File_Icon::load_system_icons()
> as part of it's init,
> > I don't know. Since we have some older version project files, does
> > anybody know if these can be written with newer VS software, e.g.
> > with VS 2008 Express?
>
> BTW, I have VS 7 .NET as well.
>
> I guess Matt must be handling the Visual Studio files.
If needs must, I think
> > The only things I'm not sure of are how to add it to the
> Microsoft projects.
Very much *not* my area of expertise...
> I don't know. Since we have some older version project files, does
> anybody know if these can be written with newer VS software, e.g.
> with VS 2008 Express?
>
> > Is t
> puzzle. Now we only
> > need to find a way to implement it in a consistent way...
>
> It seems like the most consistent thing we could do is just:
>
> 1) always use fl_snprintf() instead of snprintf()
>
> 2) make fl_snprintf() always call the FLTK
> implemen
On this mornings rebuild of 1.3 svn I got this warning:
Fl_Preferences.cxx: In member function `char
Fl_Preferences::Node::copyTo(Fl_Tree*, Fl_Tree_Item*)':
Fl_Preferences.cxx:1630: warning: unused variable 'tic'
Fl_Preferences.cxx:1632: warning: no return statement in function
returning non-void
> And that means I can not test my UUID patches...
Well, I have done some testing of my UUID patch, and it was *almost*
right.
But not...
Attached is a revised patch that does do the Right Thing, in so far as
the UUID generation is concerned on win32.
I have not been able to fix the general br
>
> I took a look at your patch and stumbled over this:
>
> -#ifdef WIN32
> +#ifdef _WIN32
>
> Why did you change this? My understanding is that FLTK defines
> "WIN32" (without underscore) for all FLTK Windows builds, and
> this is used everywhere in the code. I assume that this has been
> done
All,
Is Fl_Preferences actually working, on windows, in fltk-1.3 for you?
I ask because I had worked up a patch for Matthias' new UUID scheme
(attached, BTW) but when I went to test it it segfaulted badly.
But... Tunrs out it is not my patch that is bad - the stock fltk-1.3 svn
segfaults for me
Should we (can we?) post to fltk.announce about the release of 1.1.10,
just "for the record" as it were?
It hasn't had any posts since 1.1.7 was released. All the posts are by
Mike - maybe he is the only one who can post there?
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Marti
> Some notes: I didn't expect to "find" the linked snprintf
> function by name, but tried it anyway. The result is that
> it doesn't find it.
I guess we must assume it is linked (statically?) by the cygwin build
system from its own libc or something?
> I didn't find the secure function _snprintf
> Anyway, this has changed recently by combining all Fl_Widget
> flags in one file, and maybe this needs to be checked again.
>
> > I suppose we could put an:
> > #ifdef _WIN32_
> > public:
> > #endif
> >
> > Type of thing around the enum definition...?
>
> Hmm, or make it public anyway, or may
> c:\fltk-1.3.x-r6960\src\Fl_win32.cxx(236) : warning C4005:
> 'POLLIN' : macro redefinition
> C:\Program Files\Microsoft
> SDKs\Windows\v6.0A\\include\winsock2.h(1495) : see previous
> definition of 'POLLIN'
> c:\fltk-1.3.x-r6960\src\Fl_win32.cxx(237) : warning C4005:
> 'POLLOUT' : ma
> 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 y
> 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 g
Controversial...
This is a bit off-topic, but after all the good work that Manolo's been
putting in, I happened to be looking at the various CREDITS files we
have in svn right now, and it rather seems to me that they need a bit of
revision. For example, the fltk-1.1.x CREDITS file refers to
fltk-
> 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 i
> > 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.
> This stack dump you gave me shows that when you are in the FNFC,
> keyboard events get sent to carbonTextHandler, a function of
> Fl_cocoa.mm, and this is bad because FLTK does not
> know the FNFC window.
>
> So, could you, please, try and comment out line
> InstallEventHandler(GetEventDisp
> 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.
> > 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 agr
501 - 600 of 871 matches
Mail list logo
