Michael Sweet wrote:
One more time, this time for sure (bad permissions on the script...)
Still trouble:
# svn propset svn:log --revprop -r 7517 'Added new methods to Fl_Menu_:
insert(), clear_submenu(), find_index(). Updated CHANGES.'
svn: DAV request failed; it's possible that the
Duncan Gibson wrote:
to pull these changes into the main build, I would very much appreciate
it if some kind users out there could check that the equivalent of:
gcc -c src/xutf8/fl_wcwidth.c
compiles without errors on Windows and Mac, as I don't have either.
No errors on Snow
Default build of fltk 1.3.x current fails on a Power PC (non-intel)
machine running 10.4.11 with gcc 3.3 (gcc_select 3.3).
*** Here's the section where it fails:
/usr/bin/ar cr ../lib/libfltk_forms.a ...
Compiling Fl_Gl_Choice.cxx...
Compiling Fl_Gl_Overlay.cxx...
Compiling
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2351
Version: 2.0-feature
I asked rainbowsally to package up all mods to date the FLTK2 test files
into a single STR as a tar file. (instead of as separate fixes that
I'd like to take on STR#2352, which involves changing all references to
using fltk-b...@fltk.org to using the STR form instead.
http://www.fltk.org/str.php?L2352
Seems like it would just involve simple text edits.
This would touch ~38 files.
___
manolo gouy wrote:
Don't you have kCGBitmapByteOrder32Big defined in your file
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Headers/CGImage.h
Hi Manolo,
Nope, not defined:
# grep kCGBitmapByteOrder32Big
Michael Sweet wrote:
Greg, what version of Xcode do you have installed? I checked and it is
listed as 10.4 and higher...
I ran 'open /Developer/Applications/Xcode.app',
and went into the menu Xcode - About, and it says 2.0.
___
I'd like to take on STR#2352, which involves changing all references to
using fltk-b...@fltk.org to using the STR form instead.
Currently the FLTK 1.3.x COPYING file says:
* * *
The authors do request that such modifications be
contributed to the FLTK project - send all
Michael Sweet wrote:
Yes, let's go ahead and update the contact link.
Done.
I didn't change the date at the top of the license files
(December 11, 2001); I'm assuming that would change only
if the legal content were to change in some way.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2351
Version: 2.0-feature
Note that FLTK 2 was never released, it's a dev version that was far along,
but was still in dev when it went dormant. So expect to find things
Emil Cataranciuc wrote:
Hello!
Do you guys have some coding conventions for FLTK project?
I am looking at the code and it is all messed up. At least when editing in
vim indentation is bad, but of course that is not the biggest problem.
I'd suggest reporting indent issues with an STR.
Just tried to download the latest r7565 snapshot (gz or bz2) from the downloads
page,
but the link fails during the download stage:
* * *
Not Found
The requested URL /pub/fltk/snapshots/fltk-1.3.x-r7565.tar.bz2 was not found on
this server.
* * *
___
I think VS 2008 will fail to build FLTK on multiproc machines due to
Microsoft's default to try to start several builds in parallel.
I find that to get FLTK to build successfully in the Microsoft IDE,
I have to set the parallel builds to '1', eg:
Go into Tools - Options - Project
Greg Ercolano wrote:
I find that to get FLTK to build successfully in the Microsoft IDE,
I have to set the parallel builds to '1', eg:
Go into Tools - Options - Project Solutions - Build and Run
..and set maximum number of parallel project builds to 1.
[..]
I'm guessing
or so, I don't think I could ever change the download mirror,
it /always/ seems to pick the default.
Michael Sweet wrote:
Which server?
On Apr 30, 2010, at 3:10 PM, Greg Ercolano wrote:
Just tried to download the latest r7565 snapshot (gz or bz2) from the
downloads page,
but the link
Clarifications in *BOLD CAPS*:
The cause seems to be, when building in 'Release' mode, the intermediate
files (vc90.idb) are written to the same pathname, eg. Release\vc90.idb.
Not a problem when building *SERIALLY* (they get re-created for each
project),
but during a
Greg Ercolano wrote:
# PROP BASE Intermediate_Dir $(ProjectName)_
# PROP Intermediate_Dir $(ProjectName)_
# PROP BASE Intermediate_Dir $(ProjectName)_
# PROP Intermediate_Dir $(ProjectName)_
Actually, better is to change it to:
# PROP BASE Intermediate_Dir Debug/$(ProjectName
Another bit on this subject; spent a good bit of time poking at the
.dsp files.
Seems to make sense to have both the Output_Dir and Intermediate_Dir
settings in *.dsp to be modified similarly.
I'd recommend for Debug builds:
# PROP BASE Output_Dir
Emil Cataranciuc wrote:
I was reading Configuration Management Plan I have found that Version
numbering
guidelines are not respected.
Specifics?
Also I was wondering, wouldn't it be easier to use tabs instead of spaces for
indentation? I am asking this because at least in VIM a 4
Emil Cataranciuc wrote:
Emil Cataranciuc wrote:
I was reading Configuration Management Plan I have found that Version
numbering
guidelines are not respected.
Specifics?
Version numbering rules are not respected at all:
MAJOR.MINOR.PATCH
MAJOR.MINORbBUILD
MAJOR.MINORrcBUILD
But
Currently the 'tree.cxx' demo is in the fltk 1.3.x test directory.
This demo is actually a fluid generated file, and I'd like to
add the fluid file, tree.fl, to the code base so that it's easy
to change the interface.
I figure the easy thing to do is just add the .fl file to the
code base, but
Hmm, sounds weird.. is that a clean checkout/rebuild of at least 7601?
(Current is 7604)
I tested on linux/osx, but not windows.. I'll check out a clean
current and do a build on windows to see.
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Greg et al,
Rebuilding latest svn on win32 (Msys/mingw)
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Rebuilding latest svn on win32 (Msys/mingw) I'm getting a segfault when
I try to run the tree demo.
Yep -- I can replicate on windows with VS7 as well,
but can't replicate on linux or mac.
I get a similar calling stack to yours.
Rebuilding latest svn on win32 (Msys/mingw) I'm getting a segfault when
I try to run the tree demo.
Yep -- I can replicate on windows with VS7 as well,
but can't replicate on linux or mac.
I get a similar calling stack to yours.
The problem is OS specific, so it
Greg Ercolano wrote:
Manolo, can you take a look?
He hasn't posted in a few weeks, so I pinged him off list.
If we need to, we can apply my mods as a temporary fix
until he can check it.
For the quick fix, I'd definitely recommend /both/ changes:
o Check transparent_c
MacArthur, Ian (SELEX GALILEO, UK) wrote:
I agree - in the meantime, let's just do that anyway, as it has no
downside.
I'll do it now, unless you want to?
Manolo replied that he's taking a look, so let's see what
he finds over the next day or so.
Manolo replied that he's taking a look, so let's see what
he finds over the next day or so.
Oh - OK.
I pushed your workaround already anyway, works fine for me now.
manolo gouy wrote:
I believe to have fixed this issue in the svn.
(Sorry for leaving you battle with this, but I'm
Domingo Alvarez Duarte wrote:
Here is a patch that shows several places where FL_EXPORT is missing plus
some structs changed to classes.
If you make an STR for this patch, I'll join the STR and apply the
Fl_Tree related FL_EXPORT mods.
I don't mind changing Fl_Tree's
Fl_Table's docs cite some example programs that were in the original
standalone Fl_Table library, but weren't carried over to the tests/ directory
because they aren't really tests, most likely.
This kinda demonstrates the need for a separate 'examples' directory with files
that would help
manolo gouy wrote:
Greg:
do you still have an error compiling FLTK-1.3 on your Mac ?
Yes -- just tried r7612 and got:
/usr/bin/ar cr ../lib/libfltk_forms.a ...
Compiling Fl_Gl_Choice.cxx...
Compiling Fl_Gl_Overlay.cxx...
Compiling Fl_Gl_Device_Plugin.cxx...
Fl_Gl_Device_Plugin.cxx: In
manolo gouy wrote:
manolo gouy wrote:
Greg:
do you still have an error compiling FLTK-1.3 on your Mac ?
Yes -- just tried r7612 and got:
I believe this compilation error is fixed in r7613.
Yep -- builds just fine now.
___
fltk-dev
rainbow sally wrote:
They appear to be arrays of parameters for tabs and it looks
like the upper limit of the number of tabs is 128. That's really
unrealistic in v. 2.x, however, because we don't have a way to scroll the tabs
so we end up missing some stuff after about 5 to 10 pages.
I haven't seen anyone in the FLTK community submit a scrollable tab
widget [..]
Matt has one, IIRC.
Yes, here:
http://www.fltk.org/wiki.php?V241+TC+Q
Cool -- that's an interesting solution I haven't seen;
a little pulldown menu button to let one access the tabs that
Cross-posting this from fltk.bugs:
From: Csaba Biegl
Date: Sat, 29 May 2010 06:02:00 -0700
Subject: fltk-1.3.x-r7626 breaks image drawing on X
Csaba Biegl wrote:
Simple test: create a window in Fluid, add a single image (PNG, JPEG,
etc, does not matter which one), then drag an other window
Greg Ercolano wrote:
Would this be a good time to introduce a new 'examples' directory?
I'd suggest the examples dir would differ from the 'test' dir:
OK, sounds like the votes are in favor of this, so to start it,
I'm going to commit the new dir and some initial files. Comments welcome
Duncan Gibson wrote:
2. Readme should maybe say that these are provided as-is because
if it takes off, there could be dozens, [hundreds?] of examples
and keeping them up-to-date with every minor change could prove
to be a nightmare.
Done -- I've added a DISCLAIMER section to
Michael Sweet wrote:
Use:
svn propset svn:log --revprop -r 7517 bla bla bla
Still having trouble getting this to work.
Never was able to change the old comment myself,
and just needed it again with a different file comment:
$ pwd
/usr/local/src/fltk-1.3.x-svn/test
$ svn
Michael Sweet wrote:
On Jun 7, 2010, at 12:42 AM, imacarthur wrote:
Hmm, it occurs to me: should the example programs have
LGPL headers same as the FLTK code does, or should they have regular
*GPL* headers since they're not really library code?
For instance, the end user
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2341
Version: 1.3-feature
If moving Fl_Tree oriented preferences code into the Fl_Tree module will
solve the problem, can (someone) provide a patch and I can bless it?
acr's fix in STR#2366 seems to solve several STRs.
The fix seems to ensure the keysym setting below the change
is processed by XKeycodeToKeysym(), but seems like it may also
short circuit a lot of UTF8 related work above it.
So I'm guessing either the fix is correct, or the UTF8 related code
Currently the 'tree.cxx' demo is in the fltk 1.3.x test directory.
This demo is actually a fluid generated file, and I'd like to
add the fluid file, tree.fl, to the code base so that it's easy
to change the interface.
should we really switch it around so that it's built from the fl?
On
Greg Ercolano wrote:
It might be good if the CMP covered how to add files to FLTK, eg:
1) How to add new widgets to FLTK (svn, build system, dox)
2) How to add new test programs (svn, build system)
..which would include everything from the svn
No, sorry, I don't have such a tool. I'm using the tool 'brain' +
svn log, svn diff, svn blame, ... ;-)
I was referring to your comment from yesterday regarding some
merging tools Mike wrote:
And we need a documentation how to branch and merge correctly with
subversion
Albrecht/Mike, feel free to add the bits about how to check for
code regression (I think A. mentioned some 'tools' for this)
Albrecht Schlosser wrote:
No, sorry, I don't have such a tool. I'm using the tool 'brain' +
svn log, svn diff, svn blame, ... ;-)
I was referring to
MacArthur, Ian (SELEX GALILEO, UK) wrote:
No, it doesn't make any difference, I have the same slow
menu_bar with or without this patch.
OK - that is a pity, then.
Good catch that the patch had been reverted, though, but it doesn't seem
to be the cause of the problem you are seeing.
imacarthur wrote:
This is one of those weird things; when I was having trouble with
compiz animating my menus, Albrecht was not seeing the effect, even
though we had broadly similar settings in the ubuntu WM.
So I guess it is possible that the WM on Domingo's machine is doing
something
Michael Sweet wrote:
http://www.easysw.com/~mike/svn-cheat.html
Thanks -- I've added a link to that in the google doc for now
and will try to integrate its contents into the doc a bit later.
___
fltk-dev mailing list
Pablo Stickar wrote:
Where do you find r.7657?
From SVN, eg:
svn co http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3/
fltk-1.3.x-svn
..which will pull the latest 1.3.x from SVN and put it in the current
directory
as ./fltk-1.3.x-svn/*
My system is
I think some recent changes to 1.3.x have broken image redrawing.
Manolo/Albrecht/Matt, have a look at STR#2397:
http://fltk.org/str.php?L2397
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Manolo Gouy wrote:
I think some recent changes to 1.3.x have broken image redrawing.
Manolo/Albrecht/Matt, have a look at STR#2397:
http://fltk.org/str.php?L2397
No problem here under Debian 32-bit with your demo program.
If I can't reproduce the bug, I don't see how to debug.
Matthias Melcher wrote:
On 23.06.2010, at 21:10, fhools wrote:
Hi,
I am trying to get Fl_Table to update a particular cell after the model data
has changed. I tried do_callback(Fl_Table::CONTEXT_RC_RESIZE, r,c) but that
didn't work. I had to resort to calling the redraw method on the
Matthias Melcher wrote:
You could keep a redraw rectangle that contains all cells that need
refreshing. This may be efficient because updates in large tables
are typically pretty local. For example minRefreshCol, maxRefreshCol,
minRefreshRow, maxRefreshRow, and set the damage flags
Greg Ercolano wrote:
You can see the problem with the test/tree demo program. If you
clear a tree item while it (and thus its widget) is shown, then
the widget stays at its current position forever.
[[Example 1]]
Right; I think some extra code added to the Fl_Tree_Item
Domingo Alvarez Duarte wrote:
If you are going to revise Fl_Tree why not look at keyboard navigation
too, remember from another post of mine, there is no keyboard navigation
on Fl_Tree as well on Fl_Table mentioned in some recent posts.
Yes, I actually spent quite a bit of time a
Albrecht Schlosser wrote:
On 11.07.2010, at 20:28, Greg Ercolano wrote:
The tree.fl will need the final fixes, and at some point tree.cxx will
need to be removed from svn and replaced with just tree.fl.
Greg, please be careful with tree.cxx. You're looking at a stale svn
copy
Greg Ercolano wrote:
Just checked out a fresh FLTK and I see the new tree.fl, so I'll
make a new patch against that just to see if all makes sense.
New patch will have the remove(Fl_Widget*/) override.
This new combo patch against r7677 with remove() override (attached
The thing that's a bit ugly API-wise is that with these changes,
remove()'s behavior becomes inconsistent with itself:
remove(item) removes the item from the tree AND deletes it,
similar to the behavior of Fl_Browser::remove().
Similarly, any FLTK widget associated with
I find a need for a draw_focus() method that takes an Fl_Color as an argument.
There are cases where the background color of the focus box is not the widget's
color().
One such case is Fl_Tree, where items can each have a different background color
(eg. the selection color)
Unless I'm missing
Albrecht Schlosser wrote:
Is this what you mean?
Yes -- that's it.
Just being able to specify the color to contrast against (the bg color),
not the actual color to draw.
However, in actual practice, it seems widgets like Fl_Browser use
a two step
BTW, holding back an SVN checkin of Fl_Tree for the 'public scrollbar' RFC
(large thread of patches to Fl_Tree in fltk.general) didn't want to check in
public scrollbar stuff only to have to retract it if there's a better way.
Greg Ercolano wrote:
I've been fleshing out Fl_Tree's API
Andreas Ekstrand wrote:
Hi again,
I am trying to update to the latest 1.3 revision to get solutions to other
problems but I keep bumping into other things not fixed yet, of which this
slow Fl_Group::clear is one of the more serious. It really keeps us from
using the latest revision and
.
It should probably be done anyway, cause it's definitely coded in
the worst-case way right now wrt to remove()'s implementation.
Greg Ercolano wrote:
Offhand I'd say say clear() seems to be doing the slowest thing possible
wrt to how remove() currently operates.
remove
Schlosser wrote:
Greg Ercolano wrote:
Offhand, I can't see how this change could break anything otherwise.
If this change *sounds kosher to the devs* and *OP can verify it helps*,
I'll check this mod into fltk 1.3.x.
No, please don't do that. There are reasons why I did it this way
Andreas Ekstrand wrote:
I still have my test environment in place, but didn't find the time to
continue this since weeks. Sorry, Andreas :-(
No problem, Albrecht. I haven't looked into it either lately, but now it's
becoming more urgent. So if there's anything I can do to help, if you need
Albrecht Schlosser wrote:
@Greg: That would be helpful, thanks.
I've made an STR for this; STR #2409.
Will post the patch there; it'll be a simple one.
___
fltk-dev mailing list
fltk-dev@easysw.com
Preparing to make a large checkin of Fl_Tree to 1.3.x that implements
many of the features/capabilities discussed to date.
This will affect:
Fl_Tree.{cxx,H}
Fl_Tree_Item.{cxx,H}
Fl_Tree_Prefs.H
test/tree.fl
test/unittest_scrollbarsize.cxx
Manolo Gouy wrote:
Please, see new material in:
http://www.fltk.org/str.php?L2378
(I don't understand why new material does not get posted to
fltk.development)
Your changes to 2378 are in fltk.bugs.
Depends on the category (Priority) of the STR I think.
IIRC if the
Albrecht Schlosser wrote:
Well, we *have* a patch, and I think that it is so far okay, but
I'd like to have someone else check it. Ian, Greg, could you maybe
take a look at it? There are two different patches in STR 2405.
Any comments welcome. I'd like to commit the patches, but not before
Greg Ercolano wrote:
-char al = (scrollbar.align()FL_ALIGN_LEFT!=0);
-char at = (scrollbar.align()FL_ALIGN_TOP!=0);
+char al = (scrollbar.align()FL_ALIGN_LEFT)!=0;
+char at = (scrollbar.align()FL_ALIGN_TOP)!=0;
Comments welcome.
Oh, and arguably an extra set
Albrecht Schlosser wrote:
BTW, that's what the compiler warning was intended for.
Yes, I think the warnings did help us here, as getting precedence
wrong is apparently easy to do.
Quite honestly, I was surprised myself that '!=' took precedence over
''.
I would
If anyone is familiar with the XChangeProperty() call wrt
fl_XaUtf8String
please take a quick look at STR #2419 and weigh in if you see a
solution.
Appears to be a 64 bit specific problem:
http://www.fltk.org/str.php?L2419
___
Ian MacArthur wrote:
s...@sjssoftware.com wrote:
[..] On any other platform,
sizeof(long) == sizeof(void*)
When I worked on the AS/400, sizeof(void*) was 256. I don't recall
if longs were 4 or 8 bytes long.
OK - fair point. I was only thinking of host platforms on which I know
fltk
An old STR #2199 brought up an issue where regular letter keys
can trigger buttons with label shortcuts, ie. a button declared as:
Fl_Button but(x,y,w,h, Button);
..could be triggered by someone just typing 'b' or Shift-'b'.
It's been discussed that
Albrecht Schlosser wrote:
On 12.10.2010, at 18:28, Greg Ercolano wrote:
Currently the docs for Fl_Button (under 'Description') says this:
Buttons can also generate callbacks in response to FL_SHORTCUT events.
The button can either have an explicit shortcut() value
*or a letter shortcut
Duncan Gibson wrote:
Greg replied:
Don't forget to set the font ;) eg. fl_font().
FLTK will crash if the font isn't set before the fl_draw() call.
Is there some reason why this is acceptable behaviour and not an STR?
You don't need to call fl_font() before setting titles and
You don't need to call fl_font() before setting titles and labels, so
why is it needed before fl_draw()? Can't the same font be used?
Oh, and with titles, FLTK isn't used; the window manager handles titles.
With labels, widgets have a default font, so when the label is drawn,
the
s...@sjssoftware.com wrote:
[..]
One could argue fl_draw() should call fl_font() if no font was set,
to avoid problems. Probably should be discussed, though I think this
has come up before.. can't recall the reason it wasn't changed.
Or argue instead that the font should be a
Is it just me; seems like fluid's 'shell command' output dialog
(eg. when you hit ALT-G to run an external build command like gmake/nmake)
shows error output in a very funky font?
Here's what I see on both WinXP and Win7 with builds of fluid
under Vis Studio 7 and VS Express 2008:
Albrecht Schlosser wrote:
On 20.10.2010, at 08:55, Duncan Gibson wrote:
OTOH, if you call fl_draw() and didn't set a font before calling
it, then we could probably set a default font ...
I think the simplest would be to have an assert or other check that
a font has been set, so that the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2434
Version: 1.3-feature
The FNFC and Fl_Table widget's docs should have some example screenshots
showing what the widgets look like in their various forms;
o FNFC
On 24.10.2010, at 16:33, Duncan Gibson wrote:
5. complex character sets (Chinese, Japanese, Korean...)
Manolo Gouy wrote:
As for level 5, we need a developer who's a user of CJK. Without,
there's little hope to achieve this goal. Do we have that ?
1.3.x already does complex character
Greg Ercolano wrote:
On 24.10.2010, at 16:33, Duncan Gibson wrote:
5. complex character sets (Chinese, Japanese, Korean...)
Manolo Gouy wrote:
As for level 5, we need a developer who's a user of CJK. Without,
there's little hope to achieve this goal. Do we have that ?
1.3.x already
I noticed all the recent VC commits.
Is it the case that ide/VisualC6/fltk.dsw doesn't compiler
under VSE2008? I could almost swear I tested that a few times
recently and it worked OK.
But I haven't been taking VSE updates, so maybe there's something
new that I'm missing.
I thought for sure
Matthias Melcher wrote:
VisualC 2008 and VisualC 2010 are free in their Express version and have been
out in the field long enough to be the state of the art. I would like to
suggest to drop support of any IDE files older than two major releases of
that IDE.
I know that there are still
Boris Mayer-St-Onge wrote:
With FLTK 1.1.10 or one of 1.3.x snapshot (7677), I can't change the
position of widgets Fl_Input and Fl_Output.
You can, you just have to beware of the name collision,
and code accordingly.
We should have some clear docs that describe the
Matthias Melcher wrote:
I have come to the conclusion that it is probably easier to keep
virtual machines with Xcode 3 and 4, VC9 and 10, and Linux
(Makefile, cmake), and update them manually.
All the other IDE's are based around gnu tools (Code::Blocks, etc.),
so there is no need to
Matthias Melcher wrote:
So position() with two arguments (assuming they are not equal) actually sets
the primary selection. So maybe
select(from, to)
would be the right name.
Yes, I always think of that function as setting the text selection,
so select() might be the
Michael Sweet wrote:
FWIW, if we just rename the Fl_Input method then existing code
that uses position(start,end) will have a very visible effect
when the program is run.
That's assuming position(int,int) is called during normal
operation of the app.
The program might
I always try to use Fl_Menu::add() myself.. avoids weirdness.
Domingo Alvarez Duarte wrote:
Looking at the menu_generated code a bit more it seems that use of any
static structure isn't a good solution at all because it prevents derived
classes to work properly, because if we
Albrecht Schlosser wrote:
Do we officially (want to) use bool in FLTK 1.3 ?
There are some places in the code where it's used already [1], but
AFAICT bool was not used in FLTK, or at least it was not the
*usual* way to define boolean values. FLTK 2.0, however, uses bool
frequently.
If we
Matthias Melcher wrote:
Developers, user, I want to release 1.3.0 ASAP!
I want this baby out before the end of the year!
Sounds good to me.. I've been trying to do what time permits.
___
fltk-dev mailing list
fltk-dev@easysw.com
Something changed in the last few weeks that's causing
IRIX builds to crash the native compiler while building
the FLTK test/editor.cxx program.
I've filed an STR for this problem:
http://www.fltk.org/str.php?L2439
The SGI compiler has always
There appears to be a good fix in STR#2366 that I think affects
several other STRs as well.
Can one of you familiar with X11 input event handling have a look at:
http://fltk.org/str.php?L2366
acr submitted a very cool one liner patch that appears to be correct.
And while I was looking at this
Hi Matt,
I know you've been in heavy active dev on Fl_Text_*.cxx.
I'm working on solving STR #2428 (silencing compiler warnings on Tiger).
Is it OK for me to check in fixes for these, or are you still
in dev on the text editor widgets?
I figure I
Thanks! Done: r7838
Matthias Melcher wrote:
By all means, please, go ahead.
On 15.11.2010, at 05:43, Greg Ercolano wrote:
Is it OK for me to check in fixes for these, or are you still in dev..
___
fltk-dev mailing list
fltk-dev@easysw.com
http
Someone should probably look at all the window manager standards on these pages:
http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html
..and make sure FLTK makes use of them.
(I'm exhausted, otherwise I'd make an STR)
These are the
Matthias Melcher wrote:
Hi guys,
there are three bugs in FLTK 1.1.10 that can cause a crash in some
configurations. All of these have a working and somewhat verified patch.
Please vote +1, if we should take the time to release 1.1.11, or -1 if we
should focus on 1.3.0 only. I assume it
Matthias Melcher wrote:
pass[ing] the address (or ID) of an X-window [seems] suspicious.
FWIW, while solving an X related STR last night,
I noticed 'xwininfo -id' takes hexidecimal ID numbers
on its command line, replete with the 0x prefix and everything.
So I
Matthias Melcher wrote:
On 15.11.2010, at 19:06, Albrecht Schlosser wrote:
Maybe we should also update (some of) the image libs, because
there are some security updates, but we need to check this.
I'm not keen on finding out that we need to update FLTK's image
libs because of
Matthias Melcher wrote:
On 15.11.2010, at 19:06, Albrecht Schlosser wrote:
Maybe we should also update (some of) the image libs, because
there are some security updates, but we need to check this.
I'm not keen on finding out that we need to update FLTK's image
libs because of
401 - 500 of 938 matches
Mail list logo
