DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2479
Version: 1.3-current
Fix Version: 1.3-current (r8067)
Great work, Greg !
Your research of behavior in other tools and apps. is awesome !
Thanks a lot !!!
I have 3
On 22.12.2010 16:38, Manolo Gouy wrote:
[ ... text about clipboard and selection buffer ... ]
I fully agree. The problem is that this is the doc of a function
which prototype is
void Fl::copy(const char *stuff, int len, int clipboard = 0)
so the doc uses the word clipboard to relate to the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2479
Version: 1.3-current
Fix Version: 1.3-current (r8067)
I see that item 1 (documentation) is fixed. Thanks to Manolo. Looks perfect
to me.
Item 3 is also fixed.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2493
Version: 2.0-feature
Did you take a look at the FLTK 2 Roadmap?
http://www.fltk.org/roadmap.php#2.0
Unfortunately there are currently no active developers for FLTK
On 22.12.2010 08:09, fltk-dev@easysw.com wrote:
Author: manolo
Date: 2010-12-21 23:09:25 -0800 (Tue, 21 Dec 2010)
New Revision: 8097
Log:
Fix STR #2474. This allows an FLTK application to be started at X startup and
to respond to
X input methods even if the XIM server starts after the
On 20.12.2010 20:48, fltk-dev@easysw.com wrote:
Author: matt
Date: 2010-12-20 11:48:09 -0800 (Mon, 20 Dec 2010)
New Revision: 8081
Log:
Merged README.win32 into README.MSWindows.txt...
Modified: branches/branch-1.3/README.MSWindows.txt
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2480
Version: 1.3-feature
Fix Version: 1.3.0 (r8101)
Fixed in Subversion repository.
The drawing bug is fixed (svn r8053), and the client_area() method has
been added (svn r8101). The latter includes allocating the tab_pos and
I think that some of the so-called fixes in FLTk 1.3's CHANGES file
are due to changes that we introduced with FLTK 1.3. Should these
appear in the CHANGES file, or should we remove them?
Examples:
- Fixed crashes when detecting illegal UTF-8 sequences
in Fl_Text_* widgets (STR
On 22.12.2010 15:04, Michael Sweet wrote:
On Dec 22, 2010, at 7:30 AM, Albrecht Schlosser wrote:
...
Can we remove this old and obsolete link ?
Yes.
I thought so. Done (svn r 8104).
Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http
On 20.12.2010 22:44, Matthias Melcher wrote:
Removed IDE support from Fluid because it never got finished
and seemed more like a race against windmills.
I may pick this up again later - maybe.
Currently I see a problem with the VisualC6 ide files that were
only managed with the fluid option.
On 21.12.2010 10:09, fltk-dev@easysw.com wrote:
Author: greg.ercolano
Date: 2010-12-21 01:09:15 -0800 (Tue, 21 Dec 2010)
New Revision: 8091
Log:
Added doc screenshot for Fl_Native_File_Chooser.
Added:
branches/branch-1.3/documentation/src/Fl_Native_File_Chooser.png
Should be added to
On 21.12.2010 18:09, Greg Ercolano wrote:
Albrecht Schlosser wrote:
Added:
branches/branch-1.3/documentation/src/Fl_Native_File_Chooser.png
Should be added to doc/Makefile, shouldn't it ? ;-)
LOL, yes, forgot that.. fixed.
Easy to forget, since nothing breaks if it's left
On 20.12.2010 23:23, Matthias Melcher wrote:
On 20.12.2010, at 23:07, John Hoare wrote:
The reason I've ran into this problem is I
wanted to use fltk using the native windows gui rather than the cygwin
fltk which relies on running an X-server on top of windows.
The Cygwin version of FLTK on
On 20.12.2010 23:52, imacart...@gmail.com wrote:
Though I'd caution that in my testing (way back when) I found that the
cygwin build of my code was Really Slow, whereas the same code built
with VC6 (at the time and currently Msys/mingw) was notably faster.
Yes, Cygwin itself is slow, forking
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2437
Version: 1.3.0
Fix Version: 1.3-current (r8071)
I backported the fix to FLTK 1.1 (svn r 8077). Tested and works well on
Ubuntu 9.10.
For the record. Test case used: test/gl_overlay. Before the patch moving
the slieder Sides
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2490
Version: 1.1.10
I can't replicate this on Ubuntu 9.04 and 9.10 with gnome.
Matt, can you replicate the effect, and if yes, did your patch (FLTK
1.3/r8076) fix it
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2490
Version: 1.1.10
Thanks for sustaining pain and anguish... ;-)
You confirmed what I suspected, and I assume that you didn't change
anything else. So we can rule out
On 20.12.2010 10:10, Ian MacArthur wrote:
If 1.1 is open for a 1.1.11 release, do we need to back-port Yuri's GL
overlay copy patch from 1.3 into the 1.1 tree?
I do not know if the relevant bug is also present in the 1.1 tree or not, but
if it is we presumably ought to fix it?
I can see
On 20.12.2010 13:20, Matthias Melcher wrote:
On 20.12.2010, at 10:10, Ian MacArthur wrote:
If 1.1 is open for a 1.1.11 release, do we need to back-port Yuri's GL
overlay copy patch from 1.3 into the 1.1 tree?
I do not know if the relevant bug is also present in the 1.1 tree or not,
but if
John Hoare wrote:
Is there an example of an fltk program that does not always have a window
open, and exists beyond that of the fltk window's life. (All the examples
seem to end once the window is closed.)
use test/hello.cxx with this patch:
$ svn diff hello.cxx ; make hello.exe ./hello
John Hoare wrote:
I am the author of a simple robot control software library. Under normal
operation, a graphical window will only show up if users request to display
an image taken by the robot's camera.
Right now, I have the drawing being handled by a separate thread, which does
all
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1929
Version: 1.4-feature
Yes, this is fixed in 1.3 as far as I wanted (and could) do w/o touching
all drawing primitives. All usual box drawing functions for frames and
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L1819
Version: 1.3.0
Fix Version: 1.3.0
Fixed in Subversion repository.
The problem does not exist any more since the removal of the character
composition function from all input widgets. Tested and confirmed on
Windows and Linux.
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
It's not yet committed - I wanted to wait for a little feedback. Please see
also fltk.development: RFC: STR #2480: permanently allocated tab
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
Well, I wouldn't say that it is *absolutely* necessary, but the offending
code was introduced recently in r (Oct. 30, 2010) to fix the
On 18.12.2010, at 22:06, Domingo Alvarez Duarte wrote:
On my FLTK working source I have in all places where Fl:visible_focus()
is used like in:
if (!Fl::visible_focus() visible_focus()) return
Fl_Group::handle(event);
This looks *really* wrong, because you probably missed a ! before
On 19.12.2010, at 10:17, Manolo Gouy wrote:
While reading in the CMP how a new release is prepared, I have run
./makesrcdist 1.3.0
and discovered that it has committed tags/release-1.3.0/ and a full
source tree below that.
Fortunately a tag is very cheap and is only a tag, you only /see/ the
On 19.12.2010, at 10:23, Matthias Melcher wrote:
No worries. Yes, I got surprised by that too on my first release attempt ;-)
Just leave it there: Subversion never forgets... .
But if you delete it (I did), then you can only find it if you
know where (which svn release) to look for it, or if
On 19.12.2010 23:10, imacart...@gmail.com wrote:
On 19/12/10 21:14, Greg Ercolano wrote:
I think we've agreed to add this, but not on the name.
Proposing API addition:
void Fl_Multiline_Input::tab_focus(int val) { .. }
int Fl_Multiline_Input::tab_focus() const { .. }
Default would be off
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
I picked the part correct the drawing of selection_color border when the
tabs labels are at the bottom from the patch and committed it in svn
/*
-
Demo program to test Fl_Tabs::client_area().
Thanks to Greg Ercolano for the first version.
This version is modified by Albrecht Schlosser.
compile:fltk-config --compile client_area.cxx
run:./client_area [ pos ]
Use optional argument pos to position the tabs
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
I posted Greg's test file from fltk.development (client_area.cxx), modified
to be used with my patched version (see client_area.diff).
I removed
This is a question of /fast/ vs. /light/ ;-)
I'd like to hear your comments about a feature of Domingo's proposed
patch for STR #2480. This patch allocates two arrays of positions and
sizes, resp., for Fl_Tabs' tabs (or riders) permanently. They are only
reallocated, if the number of children
On 17.12.2010, at 00:19, Matthias Melcher wrote:
Dear users, developers, friends,
I know some of you online now for over ten years, few of you I have met, but
most of us know each other via mailing list only! How about we all meet up
close and in person?
Great idea, I like it.
I would
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2486
Version: 1.3-current
Fl_Multiline_Input can't handle long wrapping lines with tabs correctly.
There are drawing artifacts when moving the cursor in long lines that
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2486
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2486
Version: 1.3-current
___
fltk-bugs mailing list
On 16.12.2010 02:53, Greg Ercolano wrote:
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
On 16.12.2010, at 17:18, 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 ?
On 16.12.2010 18:35, Greg Ercolano wrote:
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.
I don't know...
The code I'm removing in the patch makes no sense at all
given the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2387
Version: 1.4-feature
I decided to commit the existing and working patch that improves
fl_read_image() on Windows significantly, so that we get the benefits of
On 14.12.2010 18:31, Manolo Gouy wrote:
(2) IMHO the so-called bad behavior is normal, and I often use it in
other applications, e.g. xterm.
This behavior is not found with gedit. The new code allows to paste
several times the current selection at various places, but stops
recording the
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2483
Version: 1.1.10
Fix Version: 1.1.10
Please do not use CMake, this is not officially supported by the FLTK team
(although FLTK includes CMake files).
FLTK contains ready-to-use IDE files for Visual C++. If you want to use
VC++
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2437
Version: 1.3.0
Fix Version: None
I can confirm that r8026 fixes the issue in test/gl_overlay on my Ubuntu
system (in a Virtualbox VM).
However, I want to bring
On 15.12.2010 01:59, Greg Ercolano wrote:
Oh, it looks like we have (b) already:
Fl::option(OPTION_ARROW_FOCUS)
..which is documented as:
/// When switched on, moving the text cursor beyond the start or end of
/// a text in a text widget will change focus to
On 15.12.2010 17:07, Greg Ercolano wrote:
If it's easy for you to incorporate an option (IIRC you mentioned that
this would only be a few lines of code), then I wouldn't object to
add an option in FLTK 1.3...
Yes; the change in Fl_Input is tiny for adding that.
However, the
On 15.12.2010 22:44, Manolo Gouy wrote:
It has been noted a few months ago that hiding an objective-C++
file inside a .cxx file is not a very good practice.
I would like to propose to stop this practice, and thus to
compile, specifically for Mac OS X, three .mm files
Fl_cocoa.mm
On 15.12.2010 22:50, Greg Ercolano wrote:
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
On 15.12.2010 21:02, Greg Ercolano wrote:
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
On 16.12.2010 00:07, Greg Ercolano wrote:
OK, then some of the examples need tweaking.
Good point. I don't think that anybody thought of the examples.
test/navigation raison d'etre is to show predictable
up/dn/lt/rt arrow key nav, so it probably either needs
a toggle
On 16.12.2010, at 00:34, Matthias Melcher wrote:
Thanks for bringing this up. Please let's not get hung up on API's and
implementation details. FLTK 1.3 is already a huge step over 1.1. Please
let's try to make it public ASAP, so we can learn from it. We should not plan
on having 11 patch
Nigo, many thanks for your valuable comments about the problems
you had. This can be very helpful to improve FLTK in the future.
On 14.12.2010 00:19, nigo wrote:
While in theory you can use Fl::set_boxtype() to retheme your app you will be
very limited.
Some months ago I attempted a
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2481
Version: 1.3.0
Yes, I saw this too, and I think that we should try to get rid of them, but
I didn't look into it yet. We should definitely avoid them if these are
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2484
Version: 1.3-current
(1) It appears to work for me _somehow_, but in an unexpected way. If you
select text and middle-mouse-click somewhere else, then the text
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. This
On 13.12.2010, at 20:11, Greg Ercolano wrote:
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.
On 13.12.2010 10:42, imacart...@gmail.com wrote:
Matt - the revised Preferences demo; does it really change system wide
prefs, or is that just for the demo? (I have not looked...)
Yes, it does, if you are root (on Linux) or maybe have administrator
rights (on Windows). And it doesn't work for
On 13.12.2010, at 06:12, s wrote:
I have a whack-a-mole type game using FLTK and I have compiled/run the game
on a linux server. I need to compile/run it on a sun machine (putty) and
cannot figure out how to do so. I use the following on linux:
Compiling the Code:
==
g++
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2472
Version: 1.3-current
Fix Version: 1.3.0 (r8000)
Yes, my testing shows that all bugs reported so far are fixed now.
Character encoding and CR/LF looks all good
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2472
Version: 1.3-current
Fix Version: 1.3.0 (r8000)
No, sorry, we can't close it...
After posting my last comment I found that I can't drag text from one FLTK
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2478
Version: 1.3-current
When testing DND (STR #2472) I found the following weird behavior that is
slightly different on Windows and Linux. Not tested on Mac.
Edit text
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2472
Version: 1.3-current
Fix Version: 1.3.0 (r8000)
Thanks, I'll test again later...
Link: http://www.fltk.org/str.php?L2472
Version: 1.3-current
Fix Version:
On 12.12.2010 15:05, Domingo Alvarez Duarte wrote:
Here there is most of my diffs to fltk 1.3 trunk hoping they can be
incorporated on the official distribution.
It was tested and seems to work fine with fltk 1.3 trunk as of today,
I'm using it on my applications too.
I took a quick look at
On 12.12.2010 18:24, Greg Ercolano wrote:
Or just stick with 'default' and abandon emacs style edit keys
altogether.
+1
why? I believe that emacs style edit keys is something for
software developers, but software is /written/ for /users/.
Personally I never used emacs (although
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2472
Version: 1.3-current
Fix Version: 1.3.0 (r8000)
I did some testing, and now it looks as if almost all is well. I won't be
able to test more and/or look at the
On 10.12.2010, at 20:16, Duncan Gibson wrote:
The discussion in STR 2348 (http://www.fltk.org/str.php?L2348) with
the title test/editor fails to displaymisc/cp1252.txt and can hang
seems to have reached some agreement, for the short term anyway, that
bytes that have their top bit set but are
On 10.12.2010 15:23, Paul R wrote:
Just to put my mind at ease, as I feel certain this must be a system
specific bug:
There often seems to be a slight lag in the mouse being 'available'
inside my FLTK windows after a button click to start or whatever.
What actions does a button click start,
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2472
Version: 1.3-current
Manolo, thanks for the fix in r7992. First tests showed that it is much
better, but I found some minor issues and a potential crash with an
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2472
Version: 1.3-current
I've seen weird effects when dragging text between different apps and
between different windows of FLTK applications on Windows and Linux. I
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2472
Version: 1.3-current
For all testing, we should always compare drag'n'drop operations with
cut'n'paste of the same text. The character encoding should be converted
Greg Ercolano wrote:
One weird thing that must be on my end; when I use 'make clean
pdf-dist',
I end up with a ~800 page fltk.pdf, while the online fltk.pdf is1000.
Mine seems to be missing everything from Preface on thru Example
Source Code
in the index. (Which
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2308
Version: 1.3.0
Thanks to HenryN for the suggested fix for src/fl_open_uri.cxx - this is
really a better solution.
I committed this one separately in svn r7976,
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2308
Version: 1.3.0
Fix Version: 1.3.0 (r7978)
Fixed in Subversion repository.
I committed the changes in svn r 7978 and hope that this fixes all
warnings and
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current
I fixed the *Windows* CR/LF problem, as discussed in fltk.general (svn
r7979). This is compatible with FLTK 1.1: all files written will be
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2471
Version: 1.3.0
+1 for the nice program and the needed feature. I like it.
However, I suggest not to replace test/preferences with this program but
to keep it as a
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2308
Version: 1.3.0
Fix Version: 1.3.0 (r7978)
Yes, that (unnecessary casting) is correct, thanks for pointing this out.
I'll fix this...
Link:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2308
Version: 1.3.0
Fix Version: 1.3.0 (r7982)
Done: svn r7982.
Link: http://www.fltk.org/str.php?L2308
Version: 1.3.0
Fix Version: 1.3.0 (r7982)
On 08.12.2010 00:17, Greg Ercolano wrote:
I can leave IMAGEFILES, but it might not be accurate,
because I don't think it's automatically generated.
Yes, but it's the best we can do. Let's do one step after the
other. I'm aware that we don't have dependencies on all the
source files
There's an optional #define to use winsock 1 (winsock.h, wsock32.dll)
instead of winsock 2 (winsock2.h, ws2_32.dll) that's used somewhere
in the source files. Should we really still try to support winsock1?
I propose to remove winsock1 support, since this is long outdated.
Comments?
Albrecht
On 08.12.2010 16:39, imacart...@gmail.com wrote:
I propose to remove winsock1 support, since this is long outdated.
I thought we already had, and switched to winsock2 ?
Yes, /we/ (FLTK 1.3) have switched, but you can compile with
#define USE_WSOCK1 / -DUSE_WSOCK1
and then FLTK will #include
On 09.12.2010, at 01:11, Greg Ercolano wrote:
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.
Thanks, that's great! Looks wonderful!
Slick Dealer wrote:
If I could easily resize PNG images using FLTK, I wouldn't be using
Fl_Help_View.
You can, but it's a low quality resizing algorithm. The key is
Fl_Image::copy(int w, int h). You should load the original image
and keep it in the background, then use copy() from the
On 08.12.2010, at 16:21, Alvin wrote:
I have updated my working-copy of 1.3.x to r7979. Since doing that I am
experiencing a segfault when I drag 'n drop a file (from Dolphin in KDE
4.5.4) onto my app.
...
I guess a fix would be to check that list_count 0 before calling strlen(),
however,
Am On 08.12.2010 16:43, schrieb Alvin wrote:
Albrecht Schlosser wrote:
...
Your description looks as if the fix for STR #2470 was not complete.
Can you roll back to svn r7969 and try again? If this works, does
the error appear with r7970?
Ok, I will get r7969 and test it. I post back what
Alvin wrote:
I tried r7969 and I still get a segfault. Having tested using r7969, it
looks like Xutf8TextPropertyToTextList (line 959) is not doing what it
should be or for some reason, setting 'list_count' to 0 and 'text_list' to
contain a NULL item.
Perhaps the fix should be:
if
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2308
Version: 1.3.0
We have 4 votes against changing the API - thanks to all that took the time
to read and vote. I'll go ahead and finalize my patch and commit it
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current
Just a note: we can't add null-bytes to Fl_Text_Buffer, and we never could
before. All strings added to Fl_Text_Buffer are null-terminated.
I did some tests to find out why we would need the .eps files,
and my conclusion is that they are useless, unless I've missed
something important.
I found out that the only image format that doxygen doesn't display
in the latex/pdf version is .gif. This is probably the reason why
the .eps files
On 07.12.2010, at 00:25, fltk-dev@easysw.com wrote:
Author: matt
Date: 2010-12-06 15:25:52 -0800 (Mon, 06 Dec 2010)
New Revision: 7968
Log:
Ooops, Fl_Text_Buffer::insertfile must read in binary format, or it will
screw up line endings! (Actually, this could be debated, but by reading and
Matthias Melcher wrote:
On 07.12.2010, at 14:42, Albrecht Schlosser wrote:
On 07.12.2010, at 00:25, fltk-dev@easysw.com wrote:
Author: matt
Date: 2010-12-06 15:25:52 -0800 (Mon, 06 Dec 2010)
New Revision: 7968
Log:
Ooops, Fl_Text_Buffer::insertfile must read in binary format
On 07.12.2010, at 16:50, Albrecht Schlosser wrote:
... But (just looking
at Fl_Text_Buffer::outputfile()) there seems to be the same problem
if we write in text format (line 1559: if (r != n) ...).
Just tested this. There's no problem with this whether we write in
binary or text format
On 07.12.2010, at 17:15, imacart...@gmail.com wrote:
I still can't find the source files for my old editor, but I think what I did
was this:
- If the file was originally in DOS-mode when I read it in (determined by
sniffing the raw binary for CR/LF pairs or, as Albrecht pointed out, checking
On 07.12.2010, at 18:58, Greg Ercolano wrote:
Actually, it seems png + jpg work fine, but gif doesn't seem to.
Yes, that's what I see, too. Although I *think* that I once saw gif
working as well - but then again it didn't...
So I guess if we convert *.gif - *.png, that'd work.
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 to trigger making the docs,
so
On 07.12.2010, at 16:39, Paul R wrote:
I have a problem i noticed when switching my widget labels around on
an output browser.
The label changes between three strings depending on what is
occurring.
The problem is when i write the longer label, and then change
back to a shorter string
On 07.12.2010, at 19:24, Greg Ercolano wrote:
devs: is there a doxygen tag that can pull example code
straight from a directory into our docs e.g. as a \code block?
I'm sure there's probably Makefile hacks to do this with sed(1),
but I imagine doxygen might have
On 07.12.2010, at 19:26, Slick Dealer wrote:
If I could easily resize PNG images using FLTK, I wouldn't be using
Fl_Help_View.
You can, but it's a low quality resizing algorithm. The key is
Fl_Image::copy(int w, int h). You should load the original image
and keep it in the background, then
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L2468
Version: 1.3-feature
This is a duplicate of STR #2469. Closed.
Link: http://www.fltk.org/str.php?L2468
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
I'd like to make progress with STR #2308 [1]. It's almost solved,
but there are two different opinions about one detail.
Please take the time to read this, maybe have a look at the
patches in question, and give your votes.
To make it short: there are two patches that are almost identical,
but
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current
Manolo, thanks for this valuable patch. I'm sure that the part that fixes
broken UTF-8 characters when reading a file is something we need
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current
Without commenting Manolo's proposal (looks interesting)...
I remembered that I had read something about encoding unknown characters
in the
901 - 1000 of 2485 matches
Mail list logo
