Software releases shall be generated for each successfully completed
software trouble report.
although this is not like the current (past) practice.
Well, I suppose we *could* sort of claim that the weeklies fulfil that role...
Shall we change the CMP?
Maybe; though evidence suggests
Fixing STR #2881 (Check image bounds before allocation) requires
to check for failed memory allocation. Without exception handling,
I believe the only way to do it is:
#include new
...
array = new(std::nothrow) char[xxx];
if (!array) longjmp(xxx, 1);
which violates the CMP
Fixing STR #2881 (Check image bounds before allocation) requires
to check for failed memory allocation. Without exception handling,
I believe the only way to do it is:
=
#include new
...
array = new(std::nothrow) char[xxx];
if (!array) longjmp(xxx, 1);
=
If worst-comes-to-worst I could code in the FLTK subset of C++ and call
Ada from there. I have learned a lot about C++ by studying Ada.
In your position, I'd maybe favour that; do the GUI in fltk/C++ and the working
logic in Ada called from the GUI...
Well, maybe...
It scares me that you
2682HIGHNew ALL Vertical scrollbar of Fl_Text_Editor
have a
strange behavior. Or is bug? 1.3-current Dec 10, 2011Unassigned
Probably survivable for now? It looks like a real bug, but it doesn't seem to
be fatal, more just annoying when it happens...
Reawakening this thread.
+1 for 1.3.1 release, with the ABI breaking stuff turned off by default,
and calling it 1.3.1 (not .2)
Yes. I probably voted before (!) but I'm +1 on just pushing out what we have...
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road,
Hi Greg,
Just pulled r9698 to check on a 3.x question on fltk.general,
but could not run a default build on linux centos 5.6:
--- snip
[..]
Compiling fltk3images/GIFImage.cxx...
Compiling fltk3images/HelpDialog.cxx...
Compiling fltk3images/images_core.cxx...
Compiling
I know how to cross compile stuff (using cmake), but I'm having
trouble cross compiling fltk-1.3.x-r9683 from a x86 linux host to an
ARM target.
Not really; we don't generally construct our build tools to support
cross-compilation, and that can make it tricky at times.
Personally, I usually
But I think it can be used only with Fl::set_font() afterwards.
OK, but is that a bad thing necessarily?
Of course not generally, but it may not always be possible or
useful in a certain context.
For example if you are in the draw method of a string with
escape codes like
There is some code in FLTK e.g. in the browser widget, that uses
the method of OR'ing the constants FL_BOLD, FL_ITALIC,.. to the
current Fl_Font (which is just an index into the font table) to
get the font index of the bold, italic,.. font of the current font
family.
In Enumerations.H the
OS: MacOSX Mountain Lion.
Revision: 9678
Using CMake and generators Xcode and Unix Makefiles.
Stops in scandir.c:
/* This warning added to help identify any non-WIN32 hosts that actually
try to use
* our private implementation of the scandir function, which was
suspect... */
#if
Thirdly, I wanted to see if the behaviour had been fixed in recent
versions so I did an svn update, but it looks like the build is
broken, coincidentally also with a bunch of screen-related symbols:
You may have a version that includes local changes or that's not up
to date. Here, the
My first intention was to build ftlk using regular makefiles, but seems
that after I upgraded to Mountain Lion and upgraded Xcode the autotools
are no longer present in MacOSX (even installing the command line tools
from Xcode). So as CMake was already in my system I tried to build fltk
with
Thanks for the long and detailed mail. The errors you describe below
remind me of an issue more than halve a year ago, which was fixed. I am
very surprised that it reappeared, but I also know that Subversion (or its
users ;-) can sometimes mess things up. Jenkins also show that the OS X
1.3
Matt,
I got this from my recent build:
Compiling Fl_Type.cxx...
In file included from ../include/fltk3/Browser.h:38:0,
from WidgetBrowser.h:32,
from Fl_Type.cxx:45:
../include/fltk3/Browser_.h: In destructor 'virtual Fl_Type::~Fl_Type()':
Weird! It works here. I knew the change was too big ;-)
Well, FWIW, it fails if I build with mingw gcc-4.7.0 but is OK with mingw
gcc-3.4.2...
Also, I can't seem to egt through to Jenkins to see what it thinks about things!
Cheers,
--
Ian
SELEX Galileo Ltd
Registered Office: Sigma House,
Seems to work now. It was a namespace issue.
Yup, cheers!
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England Wales. Company no. 02426132
I notice that the fltk3 build is currently borked on linux and winXX:
For example, from a Win32/Msys/mingw build I get:
$ make
=== making src ===
Compiling fltk3/CheckBrowser.cxx...
In file included from ../include/fltk3/run.h:39:0,
from ../include/fltk3/CheckBrowser.h:34,
I notice that the fltk3 build is currently borked on linux and winXX:
For example, from a Win32/Msys/mingw build I get:
$ make
=== making src ===
Compiling fltk3/CheckBrowser.cxx...
In file included from ../include/fltk3/run.h:39:0,
from
...
Since we already provide an API that lists a directory contents, should
we provide other information about directory entries as well? I added this
to FLTK2 many years ago because the FileChooser need a sort-by-date
function.
CUPS has code for this already and abstracts away from
Buidling fltk-3 current (r9619) I find that fluid crashes *on exit*. Haven't
had much of a chance to look at why.
When building the test folder, it croaks on every call to ../fluid/fluid -c
whatever.fl, though not until after succefullt generating the .cxx/.h output
files.
The GUI version of
Yes. I am focussing on what has now become a rewrite. It was too late when I
realized I could have done this in an svn branch instead and just add an
experimental build.set to Jenkins.
So. Sorry about the mess. It should be fixed by Sunday.
I started to look at fixing up the issues so it
Is fltk-3 broken on linux just now? I got a choke trying to build, complaining
abouyt box issues...
Wonder what Jenkins says...
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England Wales. Company no. 02426132
Hi. I´m having some problems when trying to build from the latest archive
on the web site (fltk-1.3.0-source.tar.gz).
When building with VC2008 (Microsoft Visual C++ Express Edition under
Windows XP) I get this error (right at the beginning of the process):
2jpeg : warning PRJ0009 :
I'm in the process of moving the site over to Torsten's server, so he
would be the one to ask...
Ah - Can anyone remember the syntax for the svn relocate command? I never
remember it; sounds like we'll be needing it soon!
Cheers all,
--
Ian
SELEX Galileo Ltd
Registered Office: Sigma
I'd like to make a few additions to Fl_Spinner; comments?
Fl_Spinner is a group with an Fl_Input and a few buttons; looks like this:
_
| | ^ |
| input area |---|
|_|_v_|
In my application, I need to change the color of the input
Curious if there's any objections to adding the following controls
to the Fl_Tooltip API. Would like to be able to have more control
over global tooltips:
// Set/get the left/right and top/bottom margins for all tooltips
// These allow the app to control the margin area
I believe the same goes for vertical white space as well,
ie. \nTesting\n\n\n and Testing would I think return
the same vertical size.
Yes - that is what I expect/believe it does!
fl_text_extent() does, however, give you the offset from the
string origin, so
Okay, so if we'd look directly at the label on a higher level draw
function, then wrapping and symbol expansion would be needed, and
fl_measure() would be appropriate, but here in the given context
we're probably looking at broken-up strings ready to be rendered,
and then fl_text_extents()
Question: How expensive would measuring the text before doing
the real output in X11 be?
I do not know.
It is likely that the correct answer will be That depends I guess.
If the code is running on a local server, the round-trip will be a lot quicker
than a transaction over the network... And
I can't check Jenkins from here (due to my ongoing inablility to sneak
around the security firewall here at work...) to see what it says, but
when I do a build here it dies with
There's no MinGW build for FLTK 3 yet on Jenkins, but it fails here with
the same errors:
OH! Good
Can you connect to my server directly? This does not use mooo.com at all,
but just my current IP:
http://93.201.233.111/jenkins/
Yes - that seems fine. How static is that IP address? Redirecting via some
dynamic dns service seems the most flexible option, but the security here
seems to be
Yes - that seems fine. How static is that IP address? Redirecting via
some dynamic dns service seems the most flexible option, but the
security here seems to be blocking anything in the mooo.com space.
I have no idea. But there are web sites out there that convert a give host
name into
This error is fixed in r.9442.
Sorry, that was my mistake.
That seems good now... Cheers.
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England Wales. Company no. 02426132
All,
I've shifted this out of the STR and into the group so that brains smarter than
mine can join in and say what's what...
Link: http://www.fltk.org/str.php?L2834
Version: 1.3-feature
@Ian,
I don't think calling ((Fl_Widget *)this)-draw() will work
in my Fl_Help_View subclass's
Is anyone (other than me!) having trouble accessing the fltk svn repos just now?
I can't get in...
I'm using https to allow webdav access through the secure firewall here, so
that may be relevant... though it has always Just Worked in the past.
Anyway, is it just a problem at my end, or is
It works for me right now, using command line svn.
And so it does for me. Just svn up'd my sources.
OK - something at my end then. Ho hum...
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England Wales.
Try http://evbuilder.de/ . It's just an alias, but maybe enough to fool
your firewall?
Worth a try, but no - it resolves the URL to mooo.com and then blocks... I'll
just have to live without the Jenkins access from work I guess.
Though, here's a thought; does it support https at all? If so,
Also, I got MinGW running. Only caveat: if the script fails, the .BAT
still does not fail, hence the result is alway success. Maybe anyone has
an idea?
I see Greg has some suggestions, but I wonder if we can get away with something
really crude here...
What I'm thinking is that:
- Before we
Ah, OK. This whole package manager thing is new to me under mingw... I
guess it is modelled apt-get on debian? (With which I am not all that
familiar...)
Yes, I think so (is there another one?).
I was thinking of the whole rpm/yum/whatever stuff, which is a possible
alternate model for
Somebody (might have been Greg?) had a widget for interpreting ANSI
terminal sequences, that could presumably set foreground and background
colours,
Yes, not so much a widget, but a patch to Fl_Browser to support
ANSI sequences that can change both fg + bg color as well as
OK, on my VM that has current mingw I did mingw-get update to make
sure all was current,
That's not true, mingw-get update only loads the new manifest files,
i.e. the package definitions and dependencies (mingw-get is modelled
like apt-get). It's not yet full-featured, but you can now
Please note, I am currently moving from Windows to Ubuntu and am new to
many protocols.I notice from the main websites that there are various
versions and their weekly snapshots (1.3.x ??).
Yup - many versions. 1.3.x is the current stable tree, 1.1 is the old stable,
2.x is an experimental
For those following along at home who may not know, the only IDE's we do
support are Xcode and some of the more or less sort of compatible with
each other VS variants.
For OSX only? That's a strange choice. What about Windows?
Huh? Wha...?
Dude - VS means Visual Studio.
That's, you
Oh, sorry, dude, I didn't get the word and right after Xcode in
your message :D I thought you're talking about things in OSX, ^_^
OK, so I should leave Dev-C++ *at the bottom of my drawer* and go to
VS 2010 Express, right?
Probably - it's not a toolchain I'm all that keen on, but others
On 23.04.2012, at 23:53, Matthias Melcher wrote:
I added the OS X command line build for FLTK 1.3 to Jenkins. I also
added all jobs for FLTK 3.0.
Ooops:
http://matthiasm.mooo.com/jenkins
Matt (et al)
Two things:
1: I accidentally triggered a fltk3 Ubuntu rebuild last night - I was
I downloaded MinGW-get from mingw.org and ran it (it seems that they
uploaded it only 24 hours ago - should I use a different version). Using
the included package, it does not install the C compiler (it does compile
C++ though). Using the option to download the newest version, I get tons
of
Their GUI reporter is cute, which apparently parses gcc's error
output and gives a condensed report and lots of cute bar graphs.
Looks like r9390 gave these non-fatal warnings:
Fl_x.cxx: In function �int fl_handle(const XEvent)�:
Fl_x.cxx:1292:9: warning: variable �len�
One more note: although some people recommend changing the Windows
system PATH environment variable, I never do this for MinGW. IMHO
it is much better to change the path only in the MinGW environment.
I also *remove* some Windows path components which I don't like in
the MinGW environment,
By using repeated replaces the entire display's colours can be
controlled BUT NOT THE BACKGROUND. Why can't each Style_Table_Entry
contain background color information somehow?
Sorry - it just wasn't designed that way...
Somebody (might have been Greg?) had a widget for interpreting ANSI
I am using FLTK Version 1.3
Can Fl_Text_Display text have a background color ?
It seems to me it should be in Style_Table_Entry somewhere.
eg : I would like my Fl_Text_Display to look like
--
- This line has yellow background black
AFIAK, drawing pretty much anything 'interesting' in OpenGL is only
fast if you cache things in textures on the card and then just use
OpenGL to move them around.
Yeah, and now I think of it, I'm pretty sure that the X11/GL text rendering in
fltk-1.x doesn't have the caching I described, and
I don't know how community devpaks servers are organized, but I see
that:
Nor do we...
1. the 1.1.9 package was done by www.bibosoft.de Do you recognize
this webiste? Some active contributor to FLTK?
Don't know - maybe that was Dejan's stuff? (Though that's a guess.) He's not
around
Perhaps you can use Fl_Browser for your needs?
There you can set the background color of lines individually:
Oh yes - that's an idea: might suit the OP's needs just fine...
Wonder what is really needed?
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon,
It should be possible to have a coding style flag in each widget that -
among other things - makes a widget window or group relative. The code is
all there already because OS X has no convept of subwindows and implements
group-relative coordinates in FLT 1 already.
I'm liking the sound of
Bill mentio.ed that some engines reneder into RAM and copy a single
rectangle to the screen. Also, converting everything to ARGB internally
seems like a good idea. Future 'beautiful' widgets will likly be drawn
with scaled images instead of lines anyway, so FLTK compositing should be
really
Cairo support on 1 was quite limited. On 2 it was better, but never
complete IIRC. Sinc 1.3/3.0 we have a driver system for rendering which
means that any frontend can be added to FLTK in a somewhat ordeely
fashion. I suggest to add Cairo support as an optional library. This
allows for the
This way, approximately the same amount of work as fixing all FLTK2's bugs (and
trust me; I only fixed four or five in the file chooser and it took me a month)
is done but we have an almost-working 3.0 where *everyone* can work on the same
thing, rather than some of us on 1.3 and some of us on
Yeah, I'd say it's pretty good. And it has backends for Win32, Quartz,
and Wayland (not that I care) and also *OpenGL*--hello awesome--and
who knows what else in the future. Which is why I think it might be
perfectly valid to just do what GDK did and rip all that crap out and
leave it to
Of course, it looks amazing. Especially for the Control Sequence polygons
in Non-DAW and the Ambisonics panners in Non-Mixer, as they're quite curvy.
It is indeed slightly slower (but I expected that because it's still going
through FLTK's double buffer).
Cool. Screenshots at all?
Sure. Before and after can be found here: http://non.tuxfamily.org/cairo-test
Pretty.
How did you handle text?
Is that still the stock fltk/XFT text interface? I struggled with the Cairo
text interfaces!
The vector knobs and the spatializer widget benefit the most. Ordinary
rectangular FLTK
I ported FLTK to uCOSII, and found FLTK never release CPU therefore other
tasks in uCOSII can't run.
Is there any way can make FLTK release CPU to other tasks?
This sounds like it may be a feature of your port, as fltk does release the
CPU on every system I've ever tried... Can you give
end to that this endless confusion with
users starting new development with FLTK 2 would have an end...
I think this could be solved by changing the php code
in software.php to highlight the FLTK2 and FLTK3 releases
*IN RED* with a header that says DEVELOPMENT USE
hi I made a a spreed sheet and I want to make the labels of rows not
to move
by horizontal scroll bar and labels of columns not to move by vertical
one
what should I do?
The first thing you should do is post over in fltk.general, since it is
more suited to questions of this nature.
In
We are using the FLTK Fast Light Tool Kit (FLTK) Version
1.1.7 in our embedded system application.Now currently
exploring the Cyrillic script support for our application.Can
the above version of FLTK support Unicode or Cyrillic script?
Do we need to migrate to the latest FLTK
Is there a toolbar like CToolBar in MFC? Can be dragged,docked.
Thank you!
There's no dockable toolbar widget built-in to fltk but it is pretty
easy to make your own.
A quick search through the Links page on the fltk site should find
several you could try.
FWIW, my own hack attempt is
On 12/14/11 13:26, Ian MacArthur wrote:
#define BOLD_ON \e[1m
#define BOLD_OFF \e[0m
const char *msg = BOLD_ON Alert! BOLD_OFF \nYour
printer is on fire;
Ah, but I see ESC[1m and I think Bold, ESC[0m and I
think attributes off...
Maybe that's just me...
If such changes are being considered, I would MUCH prefer changing to
the limited pseudo-html syntax that is used by Qt and Pango
and possibly
a large number of other pieces of software.
This would let users write foo bboldibold
italic/i/b and so on.
The version I am thinking of
This was done with a different function, Widget::copy_label()
in fltk 2.
Hi Bill,
I don't think that's what the OP is asking for - the fltk2 copy_label()
method was added to later 1.1 and is in 1.3, but *I think* what the OP
wants is a global control to make *all* labels behave as
I think the isdigit() and similar functions are required to work with
the result of char-int conversion, so they should already be
doing this
sort of masking.
Yeah, that's what I thought, it seems like the sensible thing, but
Mike pointed me at some other resources, and I did a few tests,
In fltk2 a flag was added to the widget and to the arguments
to the draw
functions that disabled all interpretation of '@'.
I think that's in fltk-1 also.
There was also an @ command (I forget which)
which disabled interpretation for the rest of the label.
I think it was @., at least
I am a new user of FLTK3 who is migrating from using Tcl/Tk
for GUI development. My software development is in Common
Lisp (SBCL). I have some tests successfully running using
FLTK3 in combination with OpenGL.
Maybe a bit premature for fltk3 - expect a lot of change before we put
it
I can think of two approaches to doing this, which I've attached
to STR #2728 http://www.fltk.org/str.php?L2728
Curious which you think is better.. I kinda like (A) the most:
A. Have the test/Makefile automatically generate a
shadow_variables.cxx
file on the fly via a
The fltk3 build is bailing on me right now, with r9175.
This is on WinXP with mingw/Msys.
$ make
=== making src ===
Compiling fltk3/ShapedWindow.cxx...
fltk3/ShapedWindow.cxx: In function `HRGN__*
unnamed::bitmap2region(fltk3::Image*)':
fltk3/ShapedWindow.cxx:66: error: `ALLOC_UNIT' undeclared
Should I create a new branch and do the updates to it, try to
do incrementally, because some of the files change a few
times for different things. Do I have access to branch?
Subversion is not git, so the workflow if different. In general, no you
should not branch, and you probably don't
Yes write, to create a branch so you guys can see the
incremental updates easily (I presume svn keeps a history
that can be used to see various versions). If I just did
diff's you'd only see the changes combined with the other changes.
We need unified diff patch files - these allow us
...
Fair enough, seems like a Good Thing To Do.
(Though possibly redundant in this case? Are there char values that
would sign extend for which isidigit() holds true?)
The issue is how isdigit() is implemented, as a macro in many
cases that does a table lookup... Out-of-range
measure_label() works after set, but I'd like to know before
setting, without knowing the font/size used. fl_measure
didn't work for me, weird values, plus requires knowning font
and font size, that's why having one that can just be called
with NULL/0 as font and/or size would use
+-- label --+
| |
| |
+---+
Seems like one could create a mask just before drawing
the border box so it leaves a 'hole' where the label() is.
This way the background
OK - I'm feeling particularly stupid now: how does masking
a byte with 0xFF help? Is it that isdigit() thinks it gets an
int, or...
I'm missing something key here, obviously...
C doesn't define whether a char is signed or unsigned, so
masking makes sure that you don't pass in a
You need to ask over in fltk.general.
This list is specifically for development *of* the library. Development
*using* the library comes under fltk.general.
Also - you are going to have to clarify the question; there's not enough
context there to begin to know what you are asking...
e, how?
This is not to say that there *is* a problem, just flagging up that I
think something odd happened...
I was rebuilding fltk3 on my OSX host, and svn had pulled in a few
revisions (e.g. Manolo's cocoa_font commit etc.) but some of the files I
thought were touched did not get rebuilt.
This seemed
There are also some Mac OS bug fixes in the svn version
that would be good to be present in 1.3.1. Is that possible ?
Sure. I will do an svn diff to figure out what is needed. Any
suggestions welcome.
There was a probvlem with opening the native file_chooser on OSX, that I
tripped over
What's interesting is that even when the new lib
calls a() and b(), the new lib runs the OLD code.
This seemed surprising to me, even for the 'inline' method!
Yup - though I think that's normal; the build *usually* emits a
callable version of the inline function if it thinks
I have changed (r.9055) the Doxygen doc of fl_draw() functions
to state explicitly that all involved strings are UTF-8 encoded
and all lengths are in bytes.
Good idea.
I would suggest to use the fl_utf8decode() function in your case.
It will successively compute the byte length of each
But in UTF-16 all symbols have size two bytes. There is no problem to
set specified size of string as opposed to UTF8 where every symbol can
have own size (from 1 up to 5?) .
Not true I'm afraid - only glyphs from the BMP are sure to be two bytes
in UTF16.
Any glyph from a higher plane will
The only reliable way to get the width of whatever is printed
is using fl_width() after setting the font and size.
Or my preferred option of fl_text_extents()
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in
Your post is off-topic for this list; you would get more useful feedback
posting over in fltk-general.
(This list is for development of the library itself, not for use or
development using the library.)
Also, whenever possible, please post in plain text, not html or rtf, as
it makes it more
I had some time this weekend to make a variation that works
with interactive programs like gdb(1). It's unix only,
but handles stdin, stdout, and stderr asynchronously:
http://seriss.com/people/erco/fltk/unix-bidir-dumb-terminal.cxx
It uses pthreads and
All right. All who commented seem to be just as undecided
about this as I was. Clearly neither solution is clean. So
I went with the one that does not break the ABI: just add one
more -parent() in the fluid code generator.
Patch and a simple fluid test program are coming up in two
Hmm, currently I can't follow what the new scheme means exactly,
but I'd say that config.h should _not_ be in the include directory,
i.e. it shouldn't be in any directory used for building user code.
It's only an include dir in the local-to-the-fltk-build-tree sense, so
probably does not
PS: with Ian's correction to makeinclude (adding -I.. three times),
everything except CubeView built now with MinGW. Errors:
That's odd - I just built r8998 on mingw with the following mods:
- add the -I.. paths to makeinclude
- hand-edit test/makedepend to sort some paths (has
Hmm, I think I lean the other way.
What we learn from the ongoing trickle of posts from users asking about
fltk2 is that the users see a number, and think that bigger is better.
So we *should* number our releases, and (in future) try to ensure that
biggest is the latest and most current...
And last but not least, all GL demos still fail to run.
Ian, do they work for you with MinGW?
Hold on... Still building...
OK, done:
$ svnversion .
8999
$ svn stat
? test1\preferences.h
? test1\tabs.cxx
? test1\keyboard_ui.h
? test1\inactive.cxx
? test1\inactive.h
?
OK, I made a design decision here that will haunt me for a
while. I figured it would be useful to compile jpeg, png, and
zlib from scratch always. This will reduce special cases at
compile time and simplify the autoconf/configure process. It
will ensure that these libraries exist, even
Ah, no. I removed all the signed/unsigned warnings from OS X,
changing the APIs for shortcut keys (and basically for
characters and modifiers in general) form signed int to
unsigned int. Xcode only finds teh OS X files, so win32 and
X11 files may be behind in this change. I only test
Is it best I just hold off for now, or are trivial fixes OK?
Please hold off until Wednesday. I am currently shuffling
files around a lot. I am relatively certain that all files
will then be in their final position, and unless there are
grave concerns, will remain there.
After that,
The Makefile generator still leaves a lot to be
desired,
I'm impressed it works at all...
but yes, link order is currently just copied from
the order of dependencies in the .flw framework file. SO it's
really easy to fix in Fluid.
Longer term, is the plan to make fluid know the right
On 19.08.2011 02:18, Csaba Biegl wrote:
Consider a fluid class containing an Fl_Input_Choice
widget. If this widget has Fl_Menu_Item-s that have their own
callbacks then these will crash the program.
Reason is that Fl_Input_Choice itself is a group containing
an FL_Input and a
Does it fix it with my test ( -g 600x400+0+0 ) for you?
Yes, but I only have access to single-head systems now, so my testing is
not indicative for the multi-head case...
In my case
it still positions the window on the 2nd screen, just as I found
during my tests before (this is as expected,
1 - 100 of 668 matches
Mail list logo
