Matthias Melcher wrote:
On 15.11.2010, at 22:35, fltk-dev@easysw.com wrote:
Attempt at fixing the XFT problem. Will be testing on Linux shortly.
[r7853]
... but on Ubuntu during the link phase, it complains:
cannot find -lXext
Ah well, that's what I get for touching outdated code :-/
MacArthur, Ian (SELEX GALILEO, UK) wrote:
What aspect of the tablet is/is not supported?
I use Wacom tablets all the time, with fltk-1.1 and fltk-1.3, and never
had any problem, so...?
I'm wondering if he means stuff like pressure sensitivity,
pen orientation, etc..
MacArthur, Ian (SELEX GALILEO, UK) wrote:
What aspect of the tablet is/is not supported?
I use Wacom tablets all the time, with fltk-1.1 and fltk-1.3, and never
had any problem, so...?
I'm wondering if he means stuff like pressure sensitivity,
pen orientation, etc..
Matthias Melcher wrote:
On 18.11.2010, at 19:21, Greg Ercolano wrote:
MacArthur, Ian (SELEX GALILEO, UK) wrote:
What aspect of the tablet is/is not supported?
I use Wacom tablets all the time, with fltk-1.1 and fltk-1.3, and never
had any problem, so...?
I'm wondering if he means
Matthias Melcher wrote:
Or something to that effect?
It uses the FL_PUSH, MOVE, DRAG, and RELEASE events. Additionally, we have
Fl::event_device(): DEVICE_MOUSE, DEVICE_STYLUS, DEVICE_ERASER,
DEVICE_CURSOR, DEVICE_AIRBRUSH, DEVICE_TOUCH
float event_pressure ()
float
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2454
Version: 1.4-feature
Fl_Tree is supposed to allow FLTK widgets to be added to the tree as
children.
But currently keyboard navigation of the tree doesn't integrate
Noticed these warnings while verifying doxygen docs this morning:
* * *
$ svnversion
7877
$ doxygen
/usr/local/src/fltk-1.3.x-svn/src/Fl_Printer.cxx:82: Warning: no uniquely
matching class member found for
void Fl_Printer::set_current()
have to find out how to *request* the desired font height
That all should give use a better result, but it still does not guarantee
that the *width* and layout will be the same on every platform... .
Sigh.
--
Greg Ercolano, e...@seriss.com
Seriss Corporation
Rush Render Queue, http
Getting these with r7930 on OSX Tiger (10.4.11):
Compiling Fl_Text_Display.cxx...
Fl_Text_Display.cxx: In member function 'int Fl_Text_Display::handle_vline(int,
int, int, int, int, int, int, int, int) const':
Fl_Text_Display.cxx:1750: warning: converting to 'int' from 'double'
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1944
Version: 2.0-feature
I'll try to make a patch for this.. should be easy.
If it looks OK, maybe we can sneak it into 1.3.x.
Seems all we need to do is add a flag to
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2466
Version: 1.3-feature
This STR is basically a 1.3 equivalent of STR#1944,a 2.x RFE
asking for the same thing.
Quoting Craigd's request, with content modified for
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1944
Version: 2.0-feature
Just realized this is a 2.x request.
Albrecht: I've added STR#2466, the 1.3.x equiv of this STR.
Will follow up there.
Link:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2010
Version: 2.0-feature
Devs: this STR is similar to #1944.
http://fltk.org/str.php?L1944
Link: http://www.fltk.org/str.php?L2010
Version: 2.0-feature
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1944
Version: 2.0-feature
Note: STR #2010 offers a 2.x patch for this same issue.
http://fltk.org/str.php?L2010
Link: http://www.fltk.org/str.php?L1944
Version:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2466
Version: 1.3-feature
Suggesting attached patch copy-tooltip.patch to solve this.
Link: http://www.fltk.org/str.php?L2466
Version: 1.3-feature
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2466
Version: 1.3-feature
Attaching v2 with doc mods/clarification.
Link: http://www.fltk.org/str.php?L2466
Version: 1.3-feature
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2466
Version: 1.3-feature
Link: http://www.fltk.org/str.php?L2466
Version: 1.3-featureIndex: src/Fl_Tooltip.cxx
I'd like to fix up some details in the CMP regarding doxygen commenting,
as we seem to have evolved a slightly different technique from what the
CMP shows.
Things I'd like to address specifically:
--- CHANGE #1 ---
BEFORE:
/**
* The
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2466
Version: 1.3-feature
Fix Version: 1.3-current (r7940)
Fixed in Subversion repository.
As per Albrecht's request, moved docs to Fl_Tooltip.cxx.
Committed slightly modified versino of patch as r7940.
Exercised variations of the
Albrecht Schlosser wrote:
[..]
It would be nice if you could also move the docs to Fl_Tooltip.cxx, where
they should be. Thanks
Done.
In the beginning, wasn't sure where to put the docs,
because Fl_Widget's docs seemed to follow its own rules.
I assumed this
Manolo Gouy wrote:
+1
MacArthur, Ian (SELEX GALILEO, UK) wrote:
+1
OK, I'll update this.
Question: Is updating the website just a matter of:
1) Doing a checkout of http://svn.easysw.com/public/fltk/www
2) Modifying trunk/cmp.php
3) Checking it back in
I
Michael Sweet wrote:
SUGGESTED:
switch(var) { // braces follow CMP rules
Missing space between switch and (var)... :)
Yes, caught that myself and fixed before I checked it in ;)
I noticed you have a special sentence just for that in the CMP.
NOTE: I documented this extra usage of single line doxygen commenting
that is prevalent in the FL/*.H files:
int my_variable1_; /** A brief description of the member/variable. */
int my_variable2_; /// A brief description of member/variable
..added that last line. I count 632
While reading Fl_Preferences, I noticed a few indent problems
and quite a few bracing variations that I'd like to fix for readability.
Fl_Preferences has had recent activity (Matt, Manolo), so thought
I'd ask before making any changes, in case such changes would create
unwelcome diffs.
imacart...@gmail.com wrote:
On 03/12/10 17:57, Greg Ercolano wrote:
(It's a weird programming tick I have when typing switch() and
esp. return(), but not with if or for.. not sure why)
Hmm, I guess I'm more the other way - I always get the space after
switch, but seem to leave
[manolo/albrecht/matthias] And yes, please reformat Fl_Preferences.
Great; checked in as r7949.
Took a pass at Fl_Table* as well, r7950.
Caught some docs were being left out due to an #if DOXYGEN
instead of #if FL_DOXYGEN.
* * *
Only (3) STRs left for
A few things I noticed about the docs.. maybe I'm late to the party
and this has all been discussed before:
1. We have eps files under svn management (documentation/src/*.eps)
which are just huge eps versions of our gif and jpeg files.
2. The documentation/Makefile has the
Greg, I think you missed to 'svn add' tree-elements.gif, and
tree-elements.png should probably be deleted after this change.
Could you please check? TIA
Yes; thanks for pointing that out.
Actually did the add, but not the commit, and in fact I was..
non-committal (bad pun).
I'd thought the
Greg, I also noticed that there are some 0-sized .eps files: [..]
If you know how to convert them, could you please give it a try
and commit the corrected files? TIA.
Sure.
Yes, I noticed those too.. wasn't sure what to make of that.
With the Makefile rules I mentioned (not yet in
Greg, I also noticed that there are some 0-sized .eps files: [..]
If you know how to convert them, could you please give it a try
and commit the corrected files? TIA.
Sure.
Done; r7956.
The only one I couldn't fix is FL.eps, because it seems to have
no source file, and is not
0-sized .eps files: [..]
Done; r7956.
Huh, that seemed to also fix all those 'bounding box' warnings
that 'cd documentation; make pdf-dist' used to show.
So /that's/ what it was bitching about.
___
fltk-dev mailing list
1. We have eps files under svn management (documentation/src/*.eps)
which are just huge eps versions of our gif and jpeg files.
[..]
unless there's a compelling reason to have the eps files in SVN,
it seems we could make the distro a bit lighter if we took the eps
files out, and
I noticed that Chapter 1 of the fltk.pdf is the TODO list.
We should probably have something more user friendly in Chapter 1
(the intro?) and have things like the TODO list and Deprecated list
at the end of the document.
We should probably really carefully check the layout of the
fltk.pdf file..
Albrecht Schlosser wrote:
So I'd suggest:
a) src/FL.eps be removed from SVN
b) removed from the documentation/Makefile
Yep, looks okay.
Done: r7957
Also: added rules to the documentation/Makefile that allows it
to automatically create the EPS files using
Matthias Melcher wrote:
On 07.12.2010, at 12:30, Albrecht Schlosser wrote:
I propose to replace all .gif (and maybe also .jpg) files in our
docs with converted .png files. These can be used in both (html
and pdf) versions.
+1
Amen to anything that gets rid of the eps files.
File sizes:
*.eps: ~ 12 MB
*.gif + *.jpg: ~ 380 KB
*.png: ~ 485 KB
Maybe we can compress the .png files better; I used 'convert' w/o
any options to convert them. Suggestions ?
Compared to gif, I've noticed png is often much smaller
for colormap versions of images. I guess
Greg Ercolano wrote:
But I don't think we have to do /any/ conversions;
according to some tests I tried, png, gif and jpeg
all work fine in the \image latex line, eg:
\image html tree-elements.png
\image latex tree-elements.png
Albrecht Schlosser wrote:
On 07.12.2010 21:18, Greg Ercolano wrote:
Sure; I assume by that you mean remove all references to
the EPSFILES and IMAGEFILES macros and their definitions.
Remove EPSFILES: yes; remove IMAGEFILES: no, maybe not.
Hypothetically, dependencies are used
FL/filename.H
# define FL_PATH_MAX 256 /** all path buffers should use this length */
Yikes, I have lots of customers who regularly have pathnames
a /lot/ longer than 256 chars.
I think windows has some small limit for local file systems of 255,
but the
Greg Ercolano wrote:
This is kinda bad; doxygen and the pdf generators aren't
warning us if our docs refer to images that don't exist :/
[..]
I'll sniff around tonight..
No flags or Doxybook settings seem to affect this.
We seem to have everything set correctly to warn
Albrecht Schlosser wrote:
Thing is, I just tried removing all the src/*.gif images,
and then ran doxygen.. no errors! Also, make pdf-dist
made no complaints either. 'make html' does complain though,
but only due to the missing dependency it seems.
Hmm, maybe after you
imacart...@gmail.com wrote:
On 07/12/10 23:40, Greg Ercolano wrote:
# define FL_PATH_MAX 256 /** all path buffers should use this length */
[..]
Should our max be larger?
I'd say yes, nowadays - though I think the 256 limit may have been true
for Win95? I think it was true
1) svn remove *.eps
2) convert all gifs - png
3) svn remove *.gif
4) svn add *.png
5) For jpeg/png images, change all \image latex foo.eps .. -
\image latex foo.[jpg,png] ..
6) For gif images, change all \image
Greg Ercolano wrote:
1) svn remove *.eps
2) convert all gifs - png
3) svn remove *.gif
4) svn add *.png
[..]
Done..!
Oh, and that's r7981.
___
fltk-dev mailing list
fltk-dev@easysw.com
Albrecht Schlosser wrote:
Meanwhile I changed the image name in documentation/src/html_footer,
but the IMAGEFILES variable in the Makefile still needs an update
( s/\.gif/.png/ ?).
Ah, missed that. Thanks; done!
___
fltk-dev mailing list
Albrecht Schlosser wrote:
FYI: I updated the FLTK 1.3 online docs to the current
version (svn r7987). Please check and correct the docs
if you find something...
Page 256 of the fltk.pdf.. O_o
http://fltk.org/doc-1.3/fltk.pdf
I don't think that color swatch is big
Greg Ercolano wrote:
Page 256 of the fltk.pdf.. O_o
http://fltk.org/doc-1.3/fltk.pdf
I don't think that color swatch is big enough ;)
Fixed the doxygen code for this in r7988.
Also, fixed a stray \code in the docs for Fl_Align
and some rather large
While using the latest 1.3.x fluid, the code editor, I noticed a problem
where keyboard selection didn't work (eg. SHIFT-DOWNARROW wasn't
highlighting lines), even though hitting 'Delete' showed the lines
were indeed selected, as the 'invisibly selected' lines went away.
When I first noticed it,
Ben Stott wrote:
Hi all,
I put in a request for developer status a few weeks ago so I could
attempt to work on the 2.0 branch (all this work on 1.3 has given me
this a renewed drive! :-P), and was just wondering who I should prod to
get it approved/declined (and/or wondering what else I would
Domingo Alvarez Duarte wrote:
- A compiler flag CTRL_A_SELECT_ALL to allow ctrl+a do select all text
instead of go to begining of the line.
This should probably be /default/. (^A = select all)
Also, Fl_Input should probably have a default popup menu off the right
mouse
'
Or just stick with 'default' and abandon emacs style edit keys altogether.
Albrecht +1
Manolo +1 to abandon emacs style edits.
Matthias+1
OK, I'll see if I can do this.
Opened STR# 2479.
___
fltk-dev mailing list
Or just stick with 'default' and abandon emacs style edit keys altogether.
Albrecht +1
Manolo +1 to abandon emacs style edits.
Matthias+1
OK, I'll see if I can do this.
Opened STR# 2479.
___
fltk-dev mailing list
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2480
Version: 1.3-feature
Including your description of what the proposed client_area() method
does here, so that the folks who write the doxygen docs will know
what it
Domingo Alvarez Duarte wrote:
Here you are pointing one of problems of Fl_Tabs Guess work, When adding
a group to Fl_Tabs the label of the group isn't adapted to the labelsize
of Fl_Tabs resulting in strange tabs.
I see, this is handy.
So the proposed client_area() makes it easier
I've got Fl_Input almost ready with the de-emacsification,
and 'standardization' of the key bindings across all platforms.
One thing that we should probably address while we're at this:
The Tab key.
Tab and Shift-Tab are almost exclusively used for field navigation.
The only exception
On 13.12.2010, at 22:25, Greg Ercolano wrote:
The behavior seems obsolete with the advent of Fl_Text_Editor.
(Arguably an app expecting Tab from users should use Fl_Text_Editor)
It's not the same, and Fl_Multiline_Input has both the advantage
and drawback that it doesn't have scrollbars
Personally I would say +1, but I believe that there may be *users*
that depend on this Tab-in-Fl_Multiline_Input feature, thus my
vote is
-1 (for now, i.e. FLTK 1.3).
I see.
Curious how you feel about a global 'normal key nav' option
eg. Fl::normal_key_nav() which:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2482
Version: 1.3-feature
The devs will chime in here on the addition of the three glut functions.
Meanwhile, let's take your separate question regarding the use of
A note to developers:
When you're developing a text input widget's key bindings
and verifying the various modifier keys work as expected
(eg. verifying Ctrl-Backspace does left-word-delete),
particular care should be taken when testing random
modifier combos, especially for the Backspace key,
or
Greg Ercolano wrote:
Curious how you feel about a global 'normal key nav' option
eg. Fl::normal_key_nav() which:
a) changes tab behavior
b) prevents left/right edit keys from accidentally key nav'ing
into other fields, so that only Tab/ShiftTab will shift
Albrecht Schlosser wrote:
Fl::option(OPTION_ARROW_FOCUS)
Yes, this is already there, but I was surprised that I discovered
recently that the old macro NORMAL_INPUT_MOVE was still in use in
Fl_Input.cxx and Fl_Text_Editor.cxx.
Greg, I fixed these by removing the obsolete and unused
Albrecht Schlosser wrote:
I made the methods 'private' so that we don't change the
public api.
Hmm, maybe protected would be useful (but then we must document
them, too). Oh, and maybe also virtual...
We could always open them up.
I just didn't want to get into an
Albrecht Schlosser wrote:
Yes, this is already there, but I was surprised that I discovered
recently that the old macro NORMAL_INPUT_MOVE was still in use in
Fl_Input.cxx and Fl_Text_Editor.cxx.
Greg, I fixed these by removing the obsolete and unused macro from
Fl_Text_Editor and by
Albrecht Schlosser wrote:
test/navigation raison d'etre is to show predictable
up/dn/lt/rt arrow key nav, so it probably [..] needs
a toggle button added to allow toggling Fl::option(OPTION_ARROW_FOCUS)
to still be useful.
+1 for the toggle button
IIRC arrow key
Albrecht Schlosser wrote:
Sure, that's fine if we want to support an option from now on in the
future. But we do also say that Fl_Multiline_Input is deprecated,
and we shouldn't add options over options to control something
that is deprecated.
Oh, I didn't know FMI is deprecated.
Domingo Alvarez Duarte wrote:
I've updated my code to latest svn and noticed that the new key navigation
with the TAB key first select all on the first press and need a second
press to move to another widget.
Why we need two key presses ?
Indeed.. not sure offhand what's causing
Greg Ercolano wrote:
Domingo Alvarez Duarte wrote:
I've updated my code to latest svn and noticed that the new key navigation
with the TAB key first select all on the first press and need a second
press to move to another widget.
Why we need two key presses ?
I agree
Greg Ercolano wrote:
I see it; this patch (below) removes the offending code.
Albrecht; if that patch looks OK to you, I'd like to check it in.
The code I'm removing in the patch makes no sense at all
given the current behavior of the widget.
This actually sounds familiar; I
Manolo Gouy wrote:
I've fixed (locally) the changes required by this proposal
in CMake files and in file fluid/ide_maketools.cxx,
so only the IDE's remain to be fixed.
Thanks for the fixes to FNFC .cxx - .mm
Not sure if you missed it, but current svn won't build on macs
due to the
Albrecht Schlosser wrote:
And what happens if you apply your patch? Any side effects?
If normal tab focus is enabled (for multiline), there's no side
effect,
and it works as expected.
Ahh, but if normal tab focus is /disabled/ (ie. old FLTK behavior)
then yes,
Greg Ercolano wrote:
(2) check if the 'normal tab focus' is disabled
+ if (Fl::event_key() == FL_Tab mark() != position()
+ input_type() == FL_MULTILINE_INPUT// only do this for
multiline input fields
+ /* ! normal_tab_focus
OK, a few things added tonight:
1) Fl_Input -- removed emacs keys, made editing functions react more
'natively'. (r8067)
2) Fixed Domingo's request to get rid of/limit 'double tap' Tab key
behavior. (r8067)
3) Added new tab_nav() flag (r8068) to control the behavior of Tab in
Getting these while building the ide/VisualC6/fltk.dsw on VS7.
Seems it doesn't like this code inside the method
Fl_Text_Display::draw_string() (which is const):
if (Fl::focus() == this) ..
.for some reason the compiler thinks testing against 'this'
somehow breaks const:
-- Build
Albrecht Schlosser wrote:
Yes, I'd say, let's remove 'em all.
+1 for removing the dependencies and shorten docs/Makefile.
Did I overlook anything ?
I agree; I'm for removing it completely, as we currently
don't seem to have a need for it. We can always add it later.
imacart...@gmail.com wrote:
So if I vote +1 on NewtonScript does that make it the winner then?!
;-)
In the unix tradition, I propose a hopelessly random mixture of
sh, awk, sed, perl and python scripts :D
___
fltk-dev mailing list
Good catch; thanks!
fltk-dev@easysw.com wrote:
Author: manolo
Date: 2010-12-23 00:13:18 -0800 (Thu, 23 Dec 2010)
New Revision: 8111
Log:
Doc change: fix error in Mac shortcut for delete word left.
Modified: branches/branch-1.3/FL/Fl_Input.H
be useful if we ever automate doc creation.
If it weren't for the automation with find(1), I'd be all for
removal of the macro, as manual maintenance is bad, given
there's no feedback for omissions.
Greg Ercolano wrote:
Albrecht Schlosser wrote:
Yes, I'd say, let's
Albrecht Schlosser wrote:
On 26.12.2010 19:12, Greg Ercolano wrote:
Opinions on automating the creation of the IMAGEFILES
via IMAGEFILES=$(shell find ..) vs. removing the macro completely?
+1 for removing.
OK, I'm +1 too.. less is good.
Will check that in.
Only
Greg Ercolano wrote:
Albrecht Schlosser wrote:
+1 for removing.
Will check that in.
Done; r8116
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
No bugs against 1.3-current I think.
I'm seeing this minor issue on ubuntu 8.04 with my slightly substandard
doxygen config:
$ make html
Generating HTML documentation...
/meade/net/tmp/fltk-1.3.x-svn/FL/Fl_Paged_Device.H:105: Warning: unable to
resolve reference to
It seems the main issue with the main distro is to avoid redundant docs.
If we package either the PDF or HTML along with the doxygen
documentation/src dir, there's redundant data for the images.
(html, pdf, and documentation/src each have their own copy of images)
So it seems to make sense to
imm wrote:
On a related note - what to do about the html_view demo in the test
folder, and about fluid?
Both attempt to load the html version of the fltk docs, but on many
platforms now with 1.3, these html files will not exist at all.
For fluid I think we could fl_open_uri() the
Greg Ercolano wrote:
imm wrote:
On a related note - what to do about the html_view demo in the test
folder,
For the help demo, I think we need to make a 'test page'.
I'm not sure our HTML viewer is capable of displaying
the doxygen docs, which have CSS and frames..
Oh
Hmm, the fltk.org main page (upper left) is showing 1.3.0rc1
as the current stable release, eg:
Quick Info
Stable Release: v1.3.0rc1
It's not really stable while it's a candidate, is it?
___
fltk-dev mailing list
Thanks for the patch.
Your fix to Fl_PostScript should *definitely* be included in 1.3.0.
There was also a problem in Fl_Postscript that wouldn't compile with
Visual C++ 2010 - it is resolved in the patch also.
--- src/Fl_PostScript.cxx (revision 8140)
+++
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2503
Version: 1.3-feature
-1 for dropping 10.4 support.. it's still a very viable platform for many
of my end users.
Link: http://www.fltk.org/str.php?L2503
Version:
Matthias Melcher wrote:
On 04.01.2011, at 19:57, Greg Ercolano wrote:
While thinking about this, it occurs to me that example programs
should maybe be licensed differently from the rest of FLTK, due
to how their source code can (and should) be able to be used to
begin a potentially commercial
Michael Sweet wrote:
On Jan 4, 2011, at 1:57 PM, Greg Ercolano wrote:
...
I'm thinking the examples should probably be 'public domain',
to prevent the GPL/LGPL restrictions which require 'derived works'
to be given back to the lib. I can see where pedantic interpretation
of the LGPL could
s...@sjssoftware.com wrote:
Yes, reading more carefully I see I may have misled you. If
you only use the .PHONY label there may be problems with
non-GNU make. Try this though:
foo: .PHONY
build foo
.PHONY:
I'm pretty sure that leads GNU make to build foo no matter
what, and make's
Albrecht Schlosser wrote:
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Just thought you should know that the file main.html is
missing from the RC3 documentation tarball.
I'm just wondering, as I assume this is about the help demo
bringing up our html docs.
I haven't
Matthias Melcher wrote:
On 10.01.2011, at 22:14, 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.
Can we make some silly test page
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
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
MacArthur, Ian (SELEX GALILEO, UK) wrote:
There seem to have been quite a few posts direct to fltk.bugs recently
by users unfamiliar with our ways... Some of these even seem to have
been of some merit (so it's good that Matt reads them!)
However, I still wonder why fltk-bugs is not just made
Final opinions and votes, anybody? Should we (Mike ;-)) do it?
+1 from me (see above)
+1.
For emails, an autoreply.
For NNTP posts, I'm not sure, but you /might/ be able to configure
a custom message to be shown when someone attempts to post.
If not,
Compiling Fl_JPEG_Image.cxx...
Compiling Fl_PNG_Image.cxx...
Fl_PNG_Image.cxx: In member function 'void Fl_PNG_Image::load_png_(const char*,
const unsigned char*, int)':
Fl_PNG_Image.cxx:108: warning: 'fp' may be used uninitialized in this function
Compiling Fl_PNM_Image.cxx...
/usr/bin/ar cr
Yuri P. Fedorchenko wrote:
I want to tell that not all warning are needed to suppress.
I think that for examle commit [Library] r8275 - branches/branch-1.3/FL
seams
strange for me
one of changes.
- virtual const char *item_text(void *item) const { return 0L; }
+ virtual const char
501 - 600 of 938 matches
Mail list logo
