On 02.06.2011 17:08, MacArthur, Ian (SELEX GALILEO, UK) wrote:
The header file Fl_Font.H has always been in the src/ folder, rather
than in FL/ since it provides private low-level stuff about the
platform specific font handling.
...
We could put it in FL/ for example (so it then would be
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2651
Version: 1.3-current
I still can't replicate the problem. My MinGW version(s) on both Win7
(64-bit) and WinXP (32-bit) both work w/o problems.
autoconf --version
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2651
Version: 1.3-current
Looking at your posted error message: it says that strtol is defined twice
in the same file, effectively:
c:\mingw\include/stdlib.h:521:36:
On 31.05.2011 20:20, Chao Han wrote:
I downloaded FLTK-1.3.0rc6, built on VS2008 Professional version, and got the
following messages:
1Creating library ../../test/fltkdll.lib and object
../../test/fltkdll.exp
1Fl_JPEG_Image.obj : error LNK2019: unresolved external symbol
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2651
Version: 1.3-current
Fix Version: 1.3-current
That does not happen here with latest MinGW(32) on Win 7 *64-bit*. Maybe a
32-/64-bit issue (long long int vs. long
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2651
Version: 1.3-current
Fix Version: 1.3-current
Roman, you wrote that you configured with --enable-debug. Does it change it
you don't use --enable-debug ? What are
On 30.05.2011 17:19, Matthias Melcher wrote:
On 30.05.2011, at 17:10, Albrecht Schlosser wrote:
...
But... why should all this thread stuff be in the fltk3 namespace
at all? I *removed* all that fltk3 namespace stuff from threads.h,
and here is my patch (some lines may wrap):
Well, noe
On 30.05.2011 09:39, Edzard Egberts wrote:
As far as I understood meaning of Fl_Overlay_Window, it seems to me,
that buffering doesn't work, but maybe there is a mistake of mine?
Please see following test program, built using FLTK 1.1.3rc6:
I hope you mean FLTK 1.3.0rc6 (changed title
On 30.05.2011 11:45, Albrecht Schlosser wrote:
this is likely to be system-dependent, and ISTR that I read somewhere
that FLTK would simulate the overlay if it isn't available on the
particular system.
Okay, I should have tested it before I replied...
I can see the effect you describe on my
svn r8758 compiled with a few warnings on Windows with MinGW, except
test/threads.cxx.
Wow, well done !
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
I don't know what that revision was. But I now tried again with 1.3.x-r8744,
doing only 1) configure, and 2) make, and *ignoring* the various readmes,
with following outcome:
Compiles and links most (all?) necessary files, but fails on making the man
pages:
=== making documentaion ===
On 27.05.2011 10:43, MacArthur, Ian (SELEX GALILEO, UK) wrote:
As I was reviewing the recent commits, I was looking at this line of
code:
+ if (num_screens 0 n= 0 n num_screens screens) {
[...]
It's not just me - recent versions of gcc whine on about this too!
Really? I can only
On 26.05.2011 15:48, fltk-dev@easysw.com wrote:
Author: matt
Date: 2011-05-26 06:48:00 -0700 (Thu, 26 May 2011)
New Revision: 8738
Log:
#2646: improved queries for screen sizes.
Modified:
branches/branch-1.3/src/screen_xywh.cxx
Modified: branches/branch-1.3/src/screen_xywh.cxx
On 26.05.2011 15:25, Matthias Melcher wrote:
On 25.05.2011, at 23:58, Ian MacArthur wrote:
Well, it's been a while, but yes, I have programmed for all of the above.
Though not using fltk
I used to support a whole programming department on 3 PDP-11's (two 11-24's
and an 11-73.)
11/24
On 25.05.2011 08:56, asif saeed wrote:
An MFC App, by default, runs in its own thread - even if your application is
single threaded. If you link to MFC using Multi-threaded MFC DLL (which is a
Visual C++ 2010 IDE option) then your GUI app runs in a separate thread of
its own. Any callback
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2637
Version: 1.3.0
Fix Version: 1.3.0 (r8731)
You're welcome, and thanks for confirmation.
Link: http://www.fltk.org/str.php?L2637
Version: 1.3.0
Fix Version: 1.3.0 (r8731)
___
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2643
Version: 1.3-current
That doesn't happen here. Can you tell us more about your configuration?
Is Xinerama active?
What does grep XINERAMA config.h show?
How many
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2643
Version: 1.3-current
I should have added: I tested on two different Ubuntu systems, one with
Xinerama disabled (one monitor), and one with Xinerama enabled (two
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2643
Version: 1.3-current
Fix Version: 1.3.0 (r8733)
Please check out rev. 8733, this ought to fix it.
Link: http://www.fltk.org/str.php?L2643
Version: 1.3-current
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2643
Version: 1.3-current
Fix Version: 1.3.0 (r8733)
Manolo, line #232 (in latest svn) has been changed in r8724 to
if (num_screens 0) { // was: 1
I can see the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2645
Version: 1.3.0
Lowered priority to 3 (moderate) since this is not a general problem and
occurs only under special circumstances and when linking shared (DLL).
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2645
Version: 1.3.0
Fix Version: 1.3.0 (r8736)
Fixed in Subversion repository.
Applied the fix to Fl_Hold_Browser, Fl_Select_Browser, and
Fl_Multi_Browser.
Link: http://www.fltk.org/str.php?L2645
Version: 1.3.0
Fix Version: 1.3.0
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2643
Version: 1.3-current
Fix Version: 1.3.0 (r8733)
Fixed in Subversion repository.
Manolo, if you have any ideas WRT the question above, please reply here or
in fltk.development.
Closing this now, since it is fixed.
Link:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2642
Version: 1.3-feature
Just some thoughts:
We can easily change one or more test programs to link with the dll, and
we should then document these as examples. I
On 24.05.2011 10:29, MacArthur, Ian (SELEX GALILEO, UK) wrote:
OK, first off, be assured that threaded code compiled on one version of
Windows does (usually!) work on other versions.
I have threaded code compiled on Vista that runs just fine on XP, and
that should be very similar to your test
On 24.05.2011 10:35, MacArthur, Ian (SELEX GALILEO, UK) wrote:
One solution would be to link additionally with fltk.lib, so
that the same
applies as with our FLTK project test programs: they pull
WinMain() from
the static lib. I don't know whether this is good style,
however, since it
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2644
Version: 1.4-feature
Bumped to 1.4-feature. No more new features now, please, until 1.3.0 is
out.
Link: http://www.fltk.org/str.php?L2644
Version: 1.4-feature
On 24.05.2011 at 11:47, MacArthur, Ian (SELEX GALILEO, UK) wrote:
I have never had problems with the DLL and mingw (Though I
do not use it
all that much now.)
Have I just been lucky, or is it actually different in this respect?
I *believe* yes. I think that the MinGW runtime doesn't call
On 24.05.2011 00:49, Matthias Melcher wrote:
On 24.05.2011, at 00:12, Albrecht Schlosser wrote:
Ready to go...
Awesome. It's too late tonight, but I hope I'll make it tomorrow afternoon
(CET).
New status:
2639Fl_Pack resizes hidden widgets, which it doesn't touch ...
Looks
On 23.05.2011 08:12, asif saeed wrote:
I think that main() can be extern-declared and WinMain can be included
verbatim in a standard header for subsystem:Windows release builds. I think
this can be done through compile-time pre-processor macro magic. Then users
will be able to use main().
On 24.05.2011 11:32, asif saeed wrote:
FL/winmain.h:
#ifdef FL_DLL
#includeWindows.h
// int main (int, char **); // should probably not be here ?
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow) {
return
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2637
Version: 1.3.0
Working on a solution now...
Link: http://www.fltk.org/str.php?L2637
Version: 1.3.0
___
fltk-bugs
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2632
Version: 1.3-current
Fix Version: 1.3.0 (r8726)
Fixed in Subversion repository.
If this doesn't work for *anybody*, please open another STR with an exact
description of your build environment and the error message(s).
... or
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2637
Version: 1.3.0
Part 1 (screen_init) is fixed now (svn r 8727).
I decided to fix the vertical resolution (dpi) as well, since this was
obviously a cut'n'paste
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2637
Version: 1.3.0
Fix Version: 1.3.0 (r8731)
Csaba, thanks again for the test cases and the patches. I modified both
patches, but they were very helpful.
Can you
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2639
Version: 1.3-current
I can't replicate your problem. Your example program behaves well in my
tests on Linux and Windows (G2 keeps its size). I also tried to comment
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2639
Version: 1.3-current
Side note to Matt: it is not clear if we have a bug or not. If yes, then
its severity is minor, hence it shouldn't stop the next RC.
Link:
On 23.05.2011 at 13:56, Ian MacArthur wrote:
Compiling Fl.cxx...
Fl.cxx:41:1: warning: WINVER redefined
In file included from
d:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windows.h:48,
from D:/msys/1.0/local/include/cairo/cairo-win32.h:44,
On 23.05.2011 at 16:44, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Please try this patch instead:
No, that does not work. I just get:
=== making src ===
Compiling Fl.cxx...
In file included from Fl.cxx:1709:
Fl_win32.cxx:754: error: `VK_BROWSER_BACK' was not declared in this scope
[...]
On 23.05.2011 14:51, pepe.b...@gmail.com wrote:
I have developed an application using FLTK 1.1.10 with DEV-C++ under windows
7, it has no problems running under windows 7 but when I execute it under
windows XP it crashes very time and doesn't work properly.
Anyone can tell me if there is a
On 23.05.2011 at 18:16, MacArthur, Ian (SELEX GALILEO, UK) wrote:
OK, I've pushed a mod to Fl.cxx and fl_font.cxx that I think covers it.
Builds ok with/without enable-cairo and appears to operate fine.
Thanks, compiles well here on my XP / MinGW system.
Albrecht
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2641
Version: 1.4-feature
Changed priority to RFE.
Many thanks for your patch, this looks interesting.
However, this proposal is too big to make it in release 1.3.0,
On 20.05.2011 18:20, Matthias Melcher wrote:
OK, there are at least three worthy fixes in the STR page for 1.3.0. Could
the contributors or rather the maintainers please apply those until Monday
midnight? I will then compile RC6 and wait another week for all additions to
be thoroughly
On 23.05.2011 08:05, asif saeed wrote:
It looks like it cannot be done easily. This is an import library. I would
suggest that you change the name to something like fltkdll_import.lib or
something like that to avoid confusion.
No, sorry, this is not going to happen. The part 'dll' implies
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2632
Version: 1.3-current
Please see attached file FL_EXPORT_v1.diff for a patch. This contains all
FL_EXPORT statements for Fl_Input-derived classes and one for
On 22.05.2011 14:27, asif saeed wrote:
On Sun, May 22, 2011 at 1:55 AM, Albrecht Schlosser...
wrote:
...you can add something like this code to
your main program (after your main() function):
#includeWindows.h
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2632
Version: 1.3-current
Mathieu, thanks for the project demo. I can use it, and I can see the
problem as you described it.
I'm working on it, and I made some
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2632
Version: 1.3-current
Yep, I was thinking of the former (your 2nd version: add the constructor
definition to an existing .cxx filem, and maybe a d'tor as well, if
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2635
Version: 1.3-feature
Fix Version: 1.3.0
Surprise, surprise ;-)
The proposed patch was not sufficient, since we have two definitions of
fl_xid() depending on the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2635
Version: 1.3-feature
Fix Version: 1.3.0 (r8706)
Fixed in Subversion repository.
svn r8706 fixes this on Linux, as requested. I also checked the Windows
On 21.05.2011 22:53, Ian MacArthur wrote:
On 21 May 2011, at 20:00, Bill Spitzak wrote:
A quick test here shows that metacity, at least, is showing the X for
modal windows.
...
That aside, what do others think?
Should we go with Nikita's tweak?
Maybe not for 1.3.0, but it could be easily
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2635
Version: 1.3-feature
Fix Version: 1.3.0 (r8706)
Fixed in Subversion repository.
Thanks for testing, Ian, and the fix, Manolo.
Closing this now, fully solved!
Link: http://www.fltk.org/str.php?L2635
Version: 1.3-feature
Fix
On 21.05.2011 12:42, asif saeed wrote:
I am no longer testing FLTK with my static MFC lib. I am simply testing the
tests/examples provided in fltk-1.3.x-r8514\test one by one. I have tested
the same thing in release mode with the same result - I get an ugly DOS
(debug, if that's what you call
On 21.05.2011 15:24, asif saeed wrote:
I built in release configuration (with multi-byte character set) the
following projects in order:
fltkjpeg
fltkpng
fltkzlib
fltkdll (I built fltkdll separately)
On 21.05.2011 17:01, asif saeed wrote:
Hello Albrecht,
This time,after defining FL_DLL as a preprocessor symbol, I got the
following errors:
Did you *also* define WIN32 ?
1tt.obj : error LNK2019: unresolved external symbol __declspec(dllimport)
public: static int __cdecl Fl::run(void)
On 21.05.2011 18:20, asif saeed wrote:
I get the following errors:
1MSVCRT.lib(crtexew.obj) : error LNK2019: unresolved external symbol
_WinMain@16 referenced in function ___tmainCRTStartup
1E:\scratch\tt\Release\tt.exe : fatal error LNK1120: 1 unresolved externals
We've been there already
On 21.05.2011 22:25, Greg Ercolano wrote:
We need some MS specific instructions on how to compile eg.
hello.cxx against DLL versions of the lib.
Yep, that's more than true (although these questions don't seem to
come up very often).
I have a question to the devs, as I don't
On 21.05.2011 18:16, asif saeed wrote:
I didn't add fltkdll.lib in Properties/Linker/Input/Additional
Dependencies. Why do I need to add this lib file. I am going to do this
anyway but I'd be thankful if you could tell me the reason it needs to be
added.
Asif, I explained this all before in
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2637
Version: 1.3.0
The first part of the patch (padding the allocation) seems /wrong/ to me.
This would only fix the (valgrind) symptoms, but don't take care of
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2637
Version: 1.3.0
Thanks for the example program and your comments about what you found out
so far. For others that want to test: I had to add these 3 lines to
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2637
Version: 1.3.0
You'll have to wait another 1 or 2 hours until I'm sitting at my 64-bit
Linux box. Until then you /may/ try it with another image (icon) with an
odd
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2637
Version: 1.3.0
Sorry, it took a little longer ... but now I can confirm everything Csaba
found out. Many thanks for reporting the bug and for your thorough
testing.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2635
Version: 1.3-feature
+1 for doing it, patch looks reasonable and simple enough.
+1 for doing it now.
I would't even call it an RFE, since it's really a bug if a
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2635
Version: 1.3-feature
From src/Fl_win32.cxx line 1944:
Window fl_xid_(const Fl_Window *w) {
Fl_X *temp = Fl_X::i(w);
return temp ? temp-xid : 0;
}
The previous
On 20.05.2011 15:51, asif saeed wrote:
I am trying to use the fltkdll project's DLL build for a very simple example
extracted from the programmer's manual Basics section. It looks like the
linker cannot find FLTKDLLd.DLL. How can I make it find the dll?
There are two different dll's,
On 20.05.2011 16:30, asif saeed wrote:
I build fltkddl using the debug configuration. I got an FLTKDLLD.DLL file in
the TEST directory. But the compiler cannot seem to FIND that FLTKDLLD.DLL
file in the TEST sub-directory of FLTK - E:\libs\fltk-1.3.x-r8514\test. I
specified this directory in
On 20.05.2011 16:58, asif saeed wrote:
I am trying to use E:\libs\fltk-1.3.x-r8514\test\fltkdlld.dll (that I built
using the debug config) with my own application that I initially created as
an empty Win32 project. The application gives me the following error:
Unhandled exception at
On 20.05.2011 at 19:13, Greg Ercolano wrote:
There's an #ifdef clause that encloses it, which might be causing
the problem, not sure:
#if defined(WIN32) !defined(FL_DLL) !defined (__GNUC__)
yep, that's it.
If that #if becomes false, it seems FLTK won't define WinMain.
Since you're using
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2632
Version: 1.3-current
Mathieu, thanks for your analysis and the MS link. I think most of us FLTK
developers are confused by this MS-specific dll_export and dll_import
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2632
Version: 1.3-current
Manolo, I believe that FL_EXPORT (and FL_DLL) is only used with the MS
tools, MinGW doesn't use it this way, but I'm not sure about this. I
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1784
Version: 2.0-current
Fix Version: 2.0-current
Ben, I'll reply to your last message in a more general way in
fltk.development later, since I think that we should
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2632
Version: 1.3-current
Good question - I assume: yes. Sigh.
A build of test/device.cxx with DLL would probably show...
Link: http://www.fltk.org/str.php?L2632
On 17.05.2011 20:18, Francesco wrote:
Override your widget s draw() function. In there, set the clipping =
to your widget size. Then call parent()-draw(). Then draw you widget.
Be careful with this! Although Matt should know, maybe he was in a
hurry, or I may be wrong...
Calling parent-draw()
On 17.05.2011 23:59, Ian MacArthur wrote:
If you are OK with building on *nix at the command line, then there's a howto
here:
http://www.fltk.org/articles.php?L598
It refers to fltk-1.1.7 (that's how old it is) but the process remains the
same.
... and it is a little outdated as of how
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1784
Version: 2.0-current
Fix Version: 2.0-current
I agree that the general problem isn't so much to do with the labels as it
is with the actual positioning of
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1784
Version: 2.0-current
Fix Version: 2.0-current
Typo correction: Of course, the following sentence should contain the word
box instead of boy:
Imagine using the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1784
Version: 2.0-current
Fix Version: 2.0-current
Ben wrote:
I've reopened the STR, because it's a poor bug that should
be fixed; chances are someone forgot to
On 16.05.2011 00:42, Ben Stott wrote:
As for the XP theme, I'm aware it demolishes button colours. What occurs
is FLTK fills the background rectangle with a colour, but the image is
placed *on top* of the button, thus hiding any colours.
Thanks for the explanation.
For the moment, if a
X11 Window.
This program has been posted to fltk.development by Kurt van Dijck
and modified slightly and commented by Albrecht Schlosser.
*/
#include X11/Xlib.h
#include stdlib.h
int main(int argc, char *argv[])
{
Display *dpy;
dpy = XOpenDisplay(getenv(DISPLAY) ?: :0);
XDestroyWindow
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2627
Version: 1.4-feature
I like your proposal !
Although I didn't test it myself yet, this seems to combine all we need
(no hanging, no circumventing of close
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L1784
Version: 2.0-current
Fix Version: 2.0-current
Ben, I can reproduce it, please see the attached modified file scroll2.cxx
for better visibility of the RED labels. The problem manifests only with
*outside* labels.
I marked two
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2627
Version: 1.4-feature
Agreed.
One more point, though, for later reference: Kurt (the OP) mentioned in
fltk.development that some other application (in his case a WM,
On 15.05.2011 17:42, Nikita Egorov wrote:
Hi, I'm sorry for bad news - yesterday I had found one more bug. After
my fast glance at new RC5 I see this bug has remained.
I don't know how about level of the bug, please judge about it yourself.
The method Fl_Menu_::remove() doesn't remove last
On 15.05.2011 19:22, Albrecht Schlosser wrote:
I did this, and what you write is correct, but what is the *last* item
in a menu array? I think that your assumption is wrong, because size()
returns the number of Fl_Menu_Item structures that make up the menu,
correctly counting submenus
On 12.05.2011 17:20, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Manolo has added:
r8653 | manolo | 2011-05-11 19:09:43 +0100 (Wed, 11 May 2011) | 3 lines
On Mac OS, FL_HIDE is now sent when a window is minimized or the
On 02.05.2011 11:55, Albrecht Schlosser wrote:
FWIW, I found a regression in Doxygen versions 1.7.2...
It turned out that there is another bug that generates wrong
links in Doxygen versions up to 1.7.4, but this one is already
fixed in Doxygen's subversion repository. You will need the
current
On 13.05.2011 10:05, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Eduardo Suarez schrieb:
I'm trying to compile some software which links to another
library built over fltk-1.
It seems to need some destructors defined, but fluid is not
generating them.
Any hint?
Why should fluid generate
On 13.05.2011 10:47, Matthias Melcher wrote:
Ah, yes, I remember. That was an optimization that we did: empty definitions
doe not get written as functions anymore. It seemed useful at that time.
Please see my note about generating a c'tor declaration (header), but no
definition (code) in the
On 13.05.2011 11:10, Stephan Effelsberg wrote:
Let me also vote for the 28th. Alternatively, 29th would also be fine as well
as the long weekend from 2nd to 5th June.
28th/29th would be okay, but 2nd to 5th of June is not possible for me.
Albrecht
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2622
Version: 1.3-current
Fix Version: 1.3.0 (r8644)
Closing now, since RC4 is out and this STR is solved.
Link: http://www.fltk.org/str.php?L2622
Version: 1.3-current
Fix Version: 1.3.0 (r8644)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2627
Version: 1.3-feature
Simply sending FL_CLOSE is probably not the correct event.
Documentation of FL/Enumerations.H [1] says:
quote
FL_CLOSE
The user clicked the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2627
Version: 1.3-feature
I found this in
http://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.pdf
on page 23 (DestroyWindow):
If the argument window is mapped, an
On 11.05.2011 21:03, Matthias Melcher wrote:
Dear users,
this is a quick poll to see which languages (natural languages, not computer
languages) you speak. It would be great to know if some of you could maybe
cross-translate for users who are not good at English.
I for one
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2622
Version: 1.3-current
Fix Version: 1.3.0 (r8644)
Fixed in Subversion repository.
Set to pending, in case there may be more comments, but IMHO this STR
can be
On 11.05.2011 01:49, Greg Ercolano wrote:
So if you want to make a simple little .exe that can be dropped
on a file server and invoked by numerous workstations without
running 'an installer' on each machine, is it possible?
Yes, use MinGW. Seriously. At least for FLTK programs
On 08.05.2011 22:01, Matthias Melcher wrote:
At this point, I would like to do another RC soon, seeing that there are only
six bugs.
Looks like we're on a good way to zero bugs, having only two now. :-)
#2622 can probably be closed w/o further action. Ian?
I don't know how far #2500 is
On 11.05.2011 12:45, Matthias Melcher wrote:
I guess I must fix Doxygen then for me as well.
I found it easy to compile, and you can pull it from svn,
and I thought you did this since you used 1.7.3 already
(or which distro is so up-to-date that you can install a
binary version 1.7.3
On 11.05.2011 13:11, ZeburRehman wrote:
Hi everyone, I have have a little problem.I want to show a vtk console window
resulting from interactor-start(); in a Fl_Window.
I'm sorry, but I can't help you because I don't know vtk, and
this is the wrong forum/group/mailing list for such questions,
On 11.05.2011 14:16, Matthias Melcher wrote:
On 11.05.2011, at 13:16, Albrecht Schlosser wrote:
Question to all developers: would it be okay to update the online
docs NOW (means: in the short term, when I can find the needed time),
or is anybody planning doc updates before the next release
On 11.05.2011 15:21, Albrecht Schlosser wrote:
I began fixing the layout and updated the html stylesheet file:
documentation/src/html_stylesheet.css.
This was really necessary to fix the layout of the new style docs.
This is the default doxygen version (for 1.7.4) now, and I am aware
501 - 600 of 2485 matches
Mail list logo
