> "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 su
> > > 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
> > > ...
> > > array = new(std::nothrow) char[xxx];
> > > if (!array) longj
> 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
> ...
> array = new(std::nothrow) char[xxx];
> if (!array) longjmp(xxx, 1);
>
> which violates the C
> 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 yo
> 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...
>
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 fltk3image
> 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, B
> 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 usual
> > > 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"
> Your suggestion to use the FLTK name of the font was promising.
> I went ahead with it and tried to make it more general.
>
> But I think it can be used only with Fl::set_font() afterwards.
OK, but is that a bad thing necessarily?
I tend to do something like this anyway... (pseudo-code warnin
> 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.
> 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
> w
> > 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,
> 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...
> 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
>
> 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
T
> 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,
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()':
../include/fltk3/Browser
> > 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 ../includ
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,
> > ...
> > 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 awa
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 would
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):
>
> 2>jpeg : warning PRJ000
> 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 Ho
> 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 are
> 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 i
> 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_exten
> 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 o
> 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..
> 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
> > 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
> 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
> > 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 p
All,
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
Compiling fltk3/utf8.cxx...
Compiling fltk3/vertex.cxx...
../include/fltk3/Device.h: In member function `vi
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 subcl
> > 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.
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 the
> And no, they decided to roll their own, with their own package
> description format (manifest, aka catalogue files), etc. The
> command line and functions are intended to be similar to apt-get,
> but that's it...
Oh joy...
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin R
> Thanks Ian for the info. I --enable-local*'ed everything anyhow and it all
> (Ubuntu'd) ok.I still have some related questions, but I will post again
> later after I have a look.
> Pause...
Did OpenGL build OK? Last time I started with a "fresh" Ubuntu install I had to
faff about for a while g
> > 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
> 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:
- Befor
> 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
> 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
> > 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
> 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
> > 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 y
> > 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
> 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 t
> 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 environmen
> > 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: v
> 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
>
> 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
> 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, Basildo
> 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
aroun
> 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, a
> I'm still not entirely sure what that ideal situation is supposed to
> be...
> The only thing that's holding me back from trying to render into a
> cairo_image_surface instead of a cairo_xlib_surface is that I'm
> still using XFT for text. I expect the practical performance of
> double buffe
> 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 b
> How do I called it (the widget?, Hint? ...?), Represented in the figures.
> I want to try to implement this for fltk. Who has the thread has any ideas
> on this subject (hint, algorithms, etc.)?
> http://img268.imageshack.us/img268/230/79021471.jpg
> http://img196.imageshack.us/img196/4518/pic1h
> 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
> rea
> 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
> 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 t
> aWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKi
> oq
> > KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg==
> >
>
> hard to read!
Blimey!
OK - no idea why that happened. Pretty sure I had plain-text set on the M$ POS
mail client...
> The fix
Fails with:
Compiling Fl_Pixmap.cxx...
Fl_Pixmap.cxx:157: error: conflicting declaration 'COLORREF
Fl_Pixmap::pixmap_bg_color'
../FL/Fl_Pixmap.H:66: error: 'Fl_Pixmap::pixmap_bg_color' has a previous
declaration as `UINT Fl_Pixmap::pixmap_bg_color'
make[1]: *** [Fl_Pixmap.o] Error 1
make: *** [a
> > > OK, more details; fails in the same way on OSX and Linux so I guess it
> =
> > > is something generic in what we are doing and not a bug peculiar to
> the
> > > win32 code...
>
> > This is now fixed with r.9304, that repairs function
> > void Fl_Group::add(Fl_Widget&) of the FLTK 1 compatib
> > OK, more details; fails in the same way on OSX and Linux so I guess it =
> > is something generic in what we are doing and not a bug peculiar to the
> > win32 code...
> This is now fixed with r.9304, that repairs function
> void Fl_Group::add(Fl_Widget&) of the FLTK 1 compatibility layer.
C
Here's a thing...
Playing about with the fltk-1 compat layer in fltk3, I notice that when running
the fullscreen test app (at least on Win32) then the GL subwindow that shows
the shape is not drawn.
However, if I remove the window.end(); call at line 196 of fluscreen.cxx
(r9302) then all is we
> > OK. I know I said I was going to go work on something useful... Well, I
> > lied.
>
> No, you didn't ;-)
>
> > I made a pretty set of Cairo-native boxtypes instead. Behold:
> >
> > http://non-mixer.tuxfamily.org/non-mixer-cairo-theme.png
>
> That was *very* useful! Looks really pretty good.
Hi Bill,
> I think I had better respond to some of this.
You know better than anyone what's going on with this stuff, so it's great to
get your input.
I (for one) always think that your ideas and understanding are really sound.
We need more of that...
Cheers.
SELEX Galileo Ltd
Registered O
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
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
> 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?
(Before
> 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 gi
> > 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 U
> On 19.02.2012 00:39, Bill Spitzak wrote:
>
> > I believe changing the scope of non-virtual methods is also ok. The
> > mangled name does not change.
>
> That's not true, according to the articles referenced below (see link).
> It seems to be true for gcc, however, but not for MSVC.
Actually,
> I believe the split of libraries in fltk can be removed. This was
> initially done so that the libraries can be shared while avoiding the
> problem that shared libraries don't work (at least on Linux, and I think
> on Windows too) unless *all* symbols in them can be resolved, whether or
> not the
> It appears on Linux that compiling 3.0 will link the "local" copies of
> these libraries, no matter how much I try to stop it with config switches.
I think this is just a WIP issue - linking against the system libs (or the
shared libs) works fine on 1.3.x and others so presumably will in fltk3
> I very much dislike all the "fltk3" stuff everywhere in the code.
Hmm, I'm OK with it I think. I like it better than just "fl".
> It sounds like the most popular solution is to call the namespace "fl"
> (all lowercase). This avoids collisions with fltk2 and fltk1 names. The
> assumption is tha
> The biggest question is exactly what to do if such rewriting is
> attempted. Is there a plan to stop contributions to the fltk1 branch, or
> to carefully reproduce any and all fixes in fltk3, even if the base code
> diverges a lot? The loss of all fixes to fltk1 in fltk2 is what killed
> it, app
> 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 ans
> > > I have a simple large window, it contains nothing, only display
> black,
> > > but it will consumes lots of memory (totally w * h * 4 Bytes), ps:
> my
> > > platform is 32bpp.
> > > =
> >
> > > Why such a simple window consume so much memory? How to reduce the
> > > memory consume. Thanks.
>
> I have a simple large window, it contains nothing, only display black,
> but it will consumes lots of memory (totally w * h * 4 Bytes), ps: my
> platform is 32bpp.
>
> Why such a simple window consume so much memory? How to reduce the
> memory consume. Thanks.
How much memory would you expect
> Now the fltk is running on XWindow, can we set the fltk running on
> DirectFB?
I don't think so - there were ports for DirectFB, but the main fltk core
does not include that. You might be able to use some of the patches if
you want, though I would recommend against it, since X11 just is not
tha
> Now, we were used Qt 4.6.2 version in our embedded device. It is going
> to be licences very soon. so we plan to switch over fltk. We would
like
> to make sure that software is free or license. We would like to know
> whether we have to satisfy any licensing agreement to make the
software
> free
> I did click to all of them. Most of them take you to webpages
> not related to the software they should be pointing to.
Hmm, I just tried this, and apart from the ones that are marked stale
(by Greg I think), they all seemed to be OK.
Are you sure you aren't getting DNS redirects or something
Greg, Albrecht,
Should we put a version of FLTK_ABI_VERSION in Enumerations.h, maybe set
to 10300 or such, and a commented out version set to 10302, along with
some comments outlining their purpose?
And maybe Albrecht's suggestion for an FLTK_ABI_LATEST key as well?
--
Ian
SELEX Galileo Ltd
R
> 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 lib
> > I really need to check these Fl_Tree ABI features to get it off
> > my plate, otherwise I fear I'll forget to get around to it.
> >
> > In the interest of time, I'm going to go with Albrecht's idea
> > of using FLTK_ABI_VERSION with a release number, eg:
> >
> > FLTK_ABI_VERSIO
> 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 he
> 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 [1m and I think "Bold", [0m and I
> think "attributes off"...
> > Maybe that's
> 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 boldbold
> italic" and so on.
>
> The version I am thinking o
> I'm proposing to add a second changed flag to Fl_Widget, this
> second one
> will not be reseted after a callback like the actual one is.
>
> I'm working with windows with several Fl_Inputs and some of
> then uses
> callback to allow calculations when the value changes, but at
> the end
> >
> >> Talking about copy/paste on windows at least apparently
> the clipboard can
> >> hold a reference for the original source and in case the
> receiver can't
> >> handle the original code it's converted somehow to plain
> text sometimes.
> ...
>
> > I think the fltk core just basically s
> On Sat, 10 Dec 2011, Domingo Alvarez Duarte
> wrote:
> > I found this link about Flterm
> http://www.9edgedown.talktalk.net/flterm.html
Well, there's a thing.
I was just flushing the backlog that builds up in this inbox over the
weekend, and I noticed the URL on that link.
Now, that U
> 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 l
> 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
> 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 copy_labe
Jens,
First off, you are posting in the wrong list (the dev list is for
development *of* fltk, not *using* fltk) so you will more likely get a
constructive answer over in fltk.general, which is also more active
anyway...
> I want to draw comlex geometries and keep hitting this one in
> the doc
1 - 100 of 871 matches
Mail list logo
