DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2513
Version: 1.3-current
Greg: could you try again with r.8255 ? Hopefully...
Link: http://www.fltk.org/str.php?L2513
Version: 1.3-current
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2515
Version: 1.3-current
I am not sure why this change would be disruptive. It only changes the
buffers when dead keys were pressed. I will take a closer look at this
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2513
Version: 1.3-current
Yep, that got it! Thanks!
Link: http://www.fltk.org/str.php?L2513
Version: 1.3-current
___
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2513
Version: 1.3-current
One question though -- I looked at the commit.
Shouldn't the #include for AvailabilityMacros.h be /above/ our
#ifndef/#define/#endif for the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2515
Version: 1.3-current
It WAS that line. Hmm. first attempt at fixing this, but I do not have a
regular keyboard. Would you guys please verify the fix?
Link:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2515
Version: 1.3-current
Tested, and it works *somehow* (for some value of somehow ;-) ). Now, with
this version (r8259), I can type dead keys, but they show immediately
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2515
Version: 1.3-current
I did not introduce this change. Was it Manolo when he was working on
compositing?
The new behavior is standard on OS X, although the dead key
Author: matt
Date: 2011-01-11 01:31:35 -0800 (Tue, 11 Jan 2011)
New Revision: 8250
Log:
Some more random transations.
Modified:
branches/branch-3.0-2011/FL/Enumerations.H
branches/branch-3.0-2011/FL/Fl_Window.H
branches/branch-3.0-2011/fltk/Widget.h
Author: matt
Date: 2011-01-11 02:15:14 -0800 (Tue, 11 Jan 2011)
New Revision: 8251
Log:
More random translations
Modified:
branches/branch-3.0-2011/fltk/Button.h
branches/branch-3.0-2011/fltk/Group.h
branches/branch-3.0-2011/fltk/Widget.h
branches/branch-3.0-2011/test2/button.cxx
Author: manolo
Date: 2011-01-11 02:36:44 -0800 (Tue, 11 Jan 2011)
New Revision: 8252
Log:
Added missing #include's when compiled using Xcode
Modified:
branches/branch-1.3/test/demo.cxx
Modified: branches/branch-1.3/test/demo.cxx
Author: AlbrechtS
Date: 2011-01-11 02:37:47 -0800 (Tue, 11 Jan 2011)
New Revision: 8253
Log:
Fixed Doxygen version numbers (and better HTML title with version number).
Modified:
branches/branch-1.3/documentation/Doxybook
branches/branch-1.3/documentation/Doxyfile
Modified:
Author: AlbrechtS
Date: 2011-01-11 02:49:50 -0800 (Tue, 11 Jan 2011)
New Revision: 8254
Log:
Next try to improve documentation title and version numbers.
Modified:
branches/branch-1.3/documentation/Doxybook
branches/branch-1.3/documentation/Doxyfile
Modified:
Author: manolo
Date: 2011-01-11 04:08:44 -0800 (Tue, 11 Jan 2011)
New Revision: 8255
Log:
New attempt to fix STR #2513.
Modified:
branches/branch-1.3/FL/mac.H
Modified: branches/branch-1.3/FL/mac.H
===
---
Author: AlbrechtS
Date: 2011-01-11 05:06:15 -0800 (Tue, 11 Jan 2011)
New Revision: 8256
Log:
Updated documentation/README to reflect the new distribution of
pre-generated documentation as separate downloads.
Modified:
branches/branch-1.3/documentation/README
Author: matt
Date: 2011-01-11 05:07:10 -0800 (Tue, 11 Jan 2011)
New Revision: 8257
Log:
Small formatting updates for Intor.dox
Modified:
branches/branch-1.3/documentation/src/intro.dox
Modified: branches/branch-1.3/documentation/src/intro.dox
Author: AlbrechtS
Date: 2011-01-11 05:40:26 -0800 (Tue, 11 Jan 2011)
New Revision: 8258
Log:
Reverting unintentionally committed experimental code in r8256. Sorry.
Modified:
branches/branch-1.3/src/Fl_Text_Display.cxx
branches/branch-1.3/test/editor.cxx
Modified:
Author: matt
Date: 2011-01-11 08:43:52 -0800 (Tue, 11 Jan 2011)
New Revision: 8259
Log:
Attempt to fix the dead_key/special_key issue.
Modified:
branches/branch-1.3/src/Fl_win32.cxx
Modified: branches/branch-1.3/src/Fl_win32.cxx
Author: AlbrechtS
Date: 2011-01-11 12:23:46 -0800 (Tue, 11 Jan 2011)
New Revision: 8261
Log:
Updated documentation copyright dates to 2011.
Modified:
branches/branch-1.3/documentation/src/fltk-book.tex
branches/branch-1.3/documentation/src/html_footer
Author: matt
Date: 2011-01-11 12:50:36 -0800 (Tue, 11 Jan 2011)
New Revision: 8262
Log:
Fixed accidental commit of some eperimental dead key preview code. STR 2515
Modified:
branches/branch-1.3/src/Fl_win32.cxx
Modified: branches/branch-1.3/src/Fl_win32.cxx
Author: AlbrechtS
Date: 2011-01-11 12:52:38 -0800 (Tue, 11 Jan 2011)
New Revision: 8263
Log:
Fixed a few GNU compiler warnings (-pedantic): C++ comments in C files,
extraneous ';' and ',' and an invalid cast.
Modified:
branches/branch-1.3/FL/Fl_Native_File_Chooser_FLTK.H
Author: manolo
Date: 2011-01-11 23:54:42 -0800 (Tue, 11 Jan 2011)
New Revision: 8266
Log:
Another change to allow OS-independent compilation of external applications as
suggested by Greg.
Modified:
branches/branch-1.3/FL/mac.H
Modified: branches/branch-1.3/FL/mac.H
I just updated to the head of 1.3, and my app failed to compile,
complaining that Fl_X was undefined. Looking at FL/mac.H, it looks
like it's intentionally hidden when compiling against an application.
Hiding system specific stuff seems like a good idea, but it looks like
this is
I don't see the Fl_X class documented in Doxygen. Am I wrong ?
I think you're right, I don't see it either. I'm not sure where I got
the idea to use it. It seems less likely to make portability if it's
consistently not exported for all OSes, but if it's not documented
then I suppose you can
I just updated to the head of 1.3, and my app failed to compile,
complaining that Fl_X was undefined. Looking at FL/mac.H, it looks
like it's intentionally hidden when compiling against an application.
Hiding system specific stuff seems like a good idea, but it looks like
this is
On 11.01.2011 10:21, MacArthur, Ian (SELEX GALILEO, UK) wrote:
One for Manolo I guess. Though... There is the bigger question of
whether Fl_X should be exposed or not.
What do folk think?
I'd say don't expose, because it's internal and can be changed.
If we really need to expose some of the
On 11.01.2011, at 10:21, MacArthur, Ian (SELEX GALILEO, UK) wrote:
One for Manolo I guess. Though... There is the bigger question of
whether Fl_X should be exposed or not.
What do folk think?
I don't know - I'd guess not, for safety reasons, but there are some
advantages, too...
This
On 11.01.2011, at 12:06, Albrecht Schlosser wrote:
I don't know what to do with fluid, but I think that fluid should
probably use an external browser for its docs as well.
I'd rather have a short intro to Fluid inside the fluid source files and an
explanation where to find the complete docs
On 11.01.2011, at 10:21, MacArthur, Ian (SELEX GALILEO, UK) wrote:
One for Manolo I guess. Though... There is the bigger question of
whether Fl_X should be exposed or not.
=20
What do folk think?=20
=20
I don't know - I'd guess not, for safety reasons, but there are some
advantages,
On 11.01.2011, at 14:58, Manolo Gouy wrote:
This is bad. The xid should be available to the user.
Isn't the fl_xid(const Fl_Window*) function (documented
in the OS issues section) enough ?
first_window, btw., is a static member of Fl_Window in FLTK2 (or
rather fltk::Window). I find
What do folk think?
I'd say don't expose, because it's internal and can be changed.
If we really need to expose some of the internals that are not
available now, then we should write accessor methods that do it
in a defined way.
Except that we used to expose it on all hosts, and now
This is bad. The xid should be available to the user.
Isn't the fl_xid(const Fl_Window*) function (documented
in the OS issues section) enough ?
I tend to agree, and that's what I've used in my code (where I have
needed this functionality) but it may still be a change that has side
On Jan 10, 2011, at 1:14 PM, imacart...@gmail.com wrote:
On 10/01/11 20:42, Greg Ercolano wrote:
I haven't tried this myself, but can the FLTK html viewer
even show our doxygen docs correctly?
Short answer: Not it can not.
Neither the frames or the non-frames versions of the
On Jan 11, 2011, at 1:21 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote:
I just updated to the head of 1.3, and my app failed to compile,
complaining that Fl_X was undefined. Looking at FL/mac.H, it looks
like it's intentionally hidden when compiling against an application.
Hiding system
Michael Sweet wrote:
Would it make sense to provide a separate help file for FLUID, and then use
that as the test file for the help_viewer demo?
That sounds good, as I don't think the FLTK doxygen docs
cover fluid anyway.
___
fltk-dev
Albrecht Schlosser wrote:
Thus, we shouldn't bother to provide a main.html file, but rather
add a sample html page for the html viewer test (as Greg volunteered
to do already) and add appropriate browser links where needed.
Mike might have a point about making separate simple fluid
Greg Ercolano wrote:
Michael Sweet wrote:
Would it make sense to provide a separate help file for FLUID, and then use
that as the test file for the help_viewer demo?
That sounds good, as I don't think the FLTK doxygen docs
cover fluid anyway.
..or I guess I never read them!
On 11.01.2011, at 18:15, Greg Ercolano wrote:
Albrecht Schlosser wrote:
Thus, we shouldn't bother to provide a main.html file, but rather
add a sample html page for the html viewer test (as Greg volunteered
to do already) and add appropriate browser links where needed.
Mike might have
I'm thinking of making the online docs version-specific, i.e.
instead of having
http://www.fltk.org/doc-1.3/index.html
we should probably have
http://www.fltk.org/doc-1.3.0/index.html
http://www.fltk.org/doc-1.3.1/index.html
...
Reasoning: The doxygen'erated HTML docs change their
On Jan 11, 2011, at 10:09 AM, Albrecht Schlosser wrote:
...
Mike, what about server space and... ?
Server space isn't an issue - about 500GB free on our RAID at the moment.
I would probably limit what is shown/linked to on the documentation page to the
most recent version - that will make
Mike:
Would it make sense to provide a separate help file for FLUID,
and then use that as the test file for the help_viewer demo?
Greg:
That sounds good, as I don't think the FLTK doxygen docs
cover fluid anyway.
Greg:
..or I guess I never read them! Well bite my tongue,
On 10.01.2011 19:35, Boris Mayer-St-Onge wrote:
I did some test on Fedora 10 and 14 with current svn(8241). No major
problem.
Thanks.
Here are some suggestions:
1- When compiling fltk, at the end one have
=== making documentation ===
This making ... specifies the directory that is
On 11.01.2011 18:48, Greg Ercolano wrote:
Greg Ercolano wrote:
Michael Sweet wrote:
Would it make sense to provide a separate help file for FLUID, and then use
that as the test file for the help_viewer demo?
That sounds good, as I don't think the FLTK doxygen docs
cover fluid
On 11.01.2011 21:05, Albrecht Schlosser wrote:
On 10.01.2011 19:35, Boris Mayer-St-Onge wrote:
Also, there is 2 copyright in this page
with year 2010. Maybe change it to 2011?
Sigh. We just changed all copyright dates to 2010, but now it's already
2011. Time goes by... I'll see what I can
Duncan Gibson wrote:
Greg:
..or I guess I never read them! Well bite my tongue, apparently
there /are/ doxygen fluid docs: http://fltk.org/doc-1.3/fluid.html
The problem with this page is that it's too complicated for new users
learning fluid. If someone is going to write a fluid
Albrecht Schlosser wrote:
In that doc it could link to the local and/or website docs,
eg:
FLTK Docs:A
HREF=file://path/to/localdocs/html/index.html(local)/A
The above would be an autoconfigured path, or optional an expanded
environment variable?
Good
hi all,
i am having a bit of a 'mare' navigating around my help files
using the help view (help dialog linking still failing so am sticking
with the help view while i get the files actually written at least)
I am pretty au fait with linking around documents, hyperlinks etc but
the paths
Some remarks:
1. There is no âfltk.pdfâ in the documentation subdir bundled with the FLTK
software, although it is announced in the README (as far as I understood).
2. Calling the âprogrammers manualâ from the FLUID GUI (via Helpâ¦) fails
as it is looking for a file âmain.htmlâ;
-Wall
-ansi
-pedantic
-ggdb
Do you know which option is triggering the noise? I'd guess pedantic
but I don't know for sure.
Of those only Wall and ggdb are options I use often... What do you gain
by using ansi and pedantic here? I'm just wondering...
SELEX Galileo Ltd
Registered
Some remarks:
1. There is no fltk.pdf in the documentation subdir bundled
with the FLTK software, although it is announced in the
README (as far as I understood).
The docs are no longer bundled with the source, as it was becoming too
large - there are now separate docs tarballs for the
I see you've had a couple of answers already,
but if the paths you're using are in the form shown above, you're doomed to
failure.
The Windows API only works properly if you use standard forward slashes
i.e. c:/program/myprog/helpfile/index.htm
Having established the top of the HTML
Oh, now I get it.
FL_ENTER and FL_DND_ENTER do not have the mouse coordinates set at all. All you
need to do here is return 1, so that FLTK knows that you are interested in
FL_MOVE and FL_DND_DRAG events respectively. *Those* events then contain the
mouse coordinates until FL_LEAVE,
My only issue with this is that if the path reported by the program
as the working directory is c:\dir\dir2\dir3\prog.exe which it
almost always is in (local) start scenarios, how does that relate
to what you are saying? You mean that i should be converting this
to a forward slash veersion
You can't reliably use \ as a separator in URL's (or indeed as a path
separator in posix system calls, though many MS API's allow it for
backwards compatibility to the old DOS way of things) so if you are
getting a DOS-style path you will need to fix it before you use it or
the behaviour is
Yes i can see that they would not be good for URLs and was going to
take that on seperately, once my path to the helpview first loadfile
opened then all subsequent links 'internal' to the documents were
to be url style...but i didnt even get that far haaha.
Try fixing the paths from the
if you get into win-centric ways of doing
things it may hurt more in the long term!
Can you expand on this? I see that it would be better for me to be able
to design for other platforms also, but at the moment i had to leave
that well alone, I had a bit of a bury head in the sand moment and
On 11.01.2011, at 09:48, Rainer Rinke wrote:
1. There is no �fltk.pdf� in the documentation subdir bundled with the
FLTK software, although it is announced in the README (as far as I
understood).
Thanks for the report, this is fixed now (svn r8256).
Your points 2. and 3. have been
On 11.01.2011, at 05:14, Adam Preble wrote:
What you'll see when building is that the receiver's window will accept drag
and drop operations right up at the top of the window; the box will turn blue
there instead of when moving the dnd cursor over the box itself. Eliminate
resize() and
OK, I have tested the code on OS X, and I get correct
coordinates for *all* events. The blue highlighting does not
work when i DND from my own window (which can be fixed by
adding Fl::flush() right after the redraw() in the FL_DND_
event code), but works when DNDing from another app. The
Well, there is somnething about over-riding the resize() method of the
Rx window.
If I make a point of calling the base class resize from the over-ridden
method, everything seems to be just lovely again;
Fl_Window::resize(X,Y,W,H); //imm
So... I guess the win32 Fl_Window::resize(X,Y,W,H)
On 11.01.2011, at 16:03, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Well, there is somnething about over-riding the resize() method of the
Rx window.
If I make a point of calling the base class resize from the over-ridden
method, everything seems to be just lovely again;
Before I continue I should say I am running FLTK 1.3 on Ubuntu 10.10. I am
building it like so:
g++ -o dnd_broke dnd_test.cpp -g -L/usr/local/lib -lfltk_gl -lGLU -lGL -lfltk
-lXft -lfontconfig -lpthread -ldl -lm -lX11
Well, there is somnething about over-riding the resize() method of the
g++ -o dnd_broke dnd_test.cpp -g -L/usr/local/lib -lfltk_gl
-lGLU -lGL -lfltk -lXft -lfontconfig -lpthread -ldl -lm -lX11
Though I'd hazard that:
fltk-config --use-gl --compile dnd_test.cpp
Might be simpler...
Yes indeed. If you get rid of that call them I'm ok. It
uses the
MacArthur, Ian (SELEX GALILEO, UK) wrote:
2. Calling the programmers manual from the FLUID GUI (via
Help...) fails as it is looking for a file main.html; but
there is only index.html. I think fluid should look for index.html
This is being discussed in another thread, but it seems that
Paul R wrote:
if you get into win-centric ways of doing
things it may hurt more in the long term!
Can you expand on this? I see that it would be better for me to be able
to design for other platforms also..
I've found I can do most stuff I need (opening/reading/writing files)
Adam Preble wrote:
I hope to have some words tonight about what might have worked for resize().
I was hoping my reply from yesterday would have addressed that..
http://fltk.org/newsgroups.php?gfltk.general+v:32003
___
fltk mailing list
As I said, I would haven't yet tried compiling FLTK with those options ---
personally I don't think it would even make it.
-Wall
-ansi
-pedantic
-ggdb
Do you know which option is triggering the noise? I'd guess pedantic
but I don't know for sure.
Yes ---
-pedantic
Adam Preble wrote:
I hope to have some words tonight about what might have worked for resize().
I was hoping my reply from yesterday would have addressed that..
http://fltk.org/newsgroups.php?gfltk.general+v:32003
Indeed it did. I just received it this morning I couldn't act on
Hello everyone:
I will use VxWorks instead of linux,but It seems that FLTK can't support
VxWorks.If I want to use FLTK on VxWorks ,what shall I do?
Thanks!
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
68 matches
Mail list logo
