On 07/04/11 20:06, Greg Ercolano wrote:
> Sounds like an STR should be made with a small test program with "\xc2\xb1"
> as the tooltip (or perhaps even a regular label string could trigger it).
Oh, there's a thing - when I was looking at this before, I was thinking
about 0xc2 and 0xb1 as distinc
On 05/04/11 18:08, Zoltán Lengyel wrote:
> the window looses it's header and resizes itself correctly, but does
> not cover the taskbar on the bottom of the screen. I was just
> wondering is this the way it supposed to work, or is there a
> workaround to make it covering everything, like a game?
On 27/03/11 13:39, Janus wrote:
> thanks Ian, i'll probably keep 1.1.10 then until 1.3 is stable (i
> like the new stuff in 1.3).
FWIW, I find 1.3 is already stable for general use.
Though I note that you are having problems with tooltips that I've not
seen, so.. YMMV...
__
On 21/02/11 18:06, Greg Ercolano wrote:
> Slightly OT, but I just wanna say:
> what the hell is up with these new mac minis, they kick ass.
>
> I've never seen any machine build FLTK so frigging fast.
>
> I did a 'make clean; make' (a clean build of all of fltk)
> and time(1) clocked it at 11.2 sec
On 20/02/11 11:18, testalucida wrote:
> I got a problem with "simultaneous" drawing two different areas and
> can't find a clue how to come along with.
> The app consists of a class hierarchy like so:
>
> Fl_Double_Window
> Group (derived from Fl_Group)
> Bar (derived from
Note that the example, as posted, does not even compile for me here...
ian@immpc9:~/src/test$ fltk1-3-config --compile lucida-1.cxx
g++ -I/home/Shared/fltk-1.3 -I/usr/include/freetype2 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT
-o 'lucida-1' 'luc
On 15/02/11 21:42, Vitaliy wrote:
>> Have a question.. What exactly X11 libs do fltk2 need?
>> I type configure and have an error:
>> _
>> checking for X... no
>> configure: error: Configure could not find required X11 libraries
>> _
>>
>> Thx for your attention :-)
> Installed xorg-dev and that so
On 14/02/11 19:55, corvid wrote:
> I wrote:
>> Ian wrote:
Is there a deep need for fl_encoding to be "iso8859-1" in
fl_font_x.cxx? Just as an experiment, I set it to
"iso10646-1", and it seemed to work well for me.
>>>
>>> Assuming you are referring to 1.3.x, then I'd say that settin
On 11/02/11 14:28, CIB wrote:
> When compiling a fltk program with MinGW, I'm suffering two
> problems.. The first is that no output to stdout will work, a printf
> at the start of the program will simply output nothing.
What shell are you invoking from?
If from an Msys shell (and if not, why not?
On 05/02/11 02:49, Mike Werner wrote:
> Why are my labels so ugly on my new system compared to my old system?
> It happens when I use large, italicized, fonts. My old system was
> Windows XP 32 bit running FLTK 1.0.11. The new system is XP 64 bit
> running FLTK 1.3. Both systems have pretty good gr
On 04/02/11 15:56, Miklos Espak wrote:
> class UserInterface {
> public:
>UserInterface();
>Fl_Double_Window *consoleWindow;
>void show();
> };
>
> UserInterface::UserInterface() {
>{ consoleWindow = new Fl_Double_Window(345, 175);
> consoleWindow->user_data((void*)(this));
>
On 31/01/11 21:14, Mike Werner wrote:
> Should FLTK 1.3.0rc3 build on a Windows XP64 bit computer? I'm
> trying to compile it with VC Express 2008 using the project files
> provided, but am running into cairo-related problems. First it
> couldn't fine cairo-win32.h. So I went out and got it from t
On 25/01/11 13:01, DIT wrote:
> Sir,it still doesn't work,i have unpacked FLTK and put them to drive
> C or C:\cygwin\bin\FLTK,and then type make...
Did you see Albrecht's reply here:
http://www.fltk.org/newsgroups.php?gfltk.general+v:32180
As he suggests, it is probably easier to get mingw/Msy
On 18/01/11 22:16, Ish wrote:
> Hi guys I am making a very simple graph widget. It has a window for a
> graph constructed by iterating through a vector of points and calling
> fl_line on two consecutive points.
>
> Additionally I have a text that indicates the coordinate i am pointed
> at and a cro
On 15/01/11 21:57, Percy wrote:
> This is a little hard to explain, but I'll give it a go:
>
> I have 3 windows, two that are modal inside eachother, like this:
> Window -> ModalWindow1 -> ModalWindow2
>
> Everything works fine, but when I hide() ModalWindow2 and
> ModalWindow1 (so that only Wind
On 15/01/11 09:50, Denton Thomas wrote:
> I should have suggested removing a couple lines, however -
>
> XFree() must happen at the end of fl_init_xim() whether or not the
> if condition fails at 564, so the new/final XFree() call is basically
> replacing line 567. I suggest we cut the XFree() at
On 14/01/11 13:22, Denton Thomas wrote:
> Agreed, setting to NULL at declaration is pointless! Line 546 is
> fine.
>
> Also agreed that it is smart to check xim_styles before use, and to
> set it to NULL after. The xlib doc does not specify whether XFree
> will or won't set incoming values to NULL
On 14/01/11 16:46, Paul R wrote:
> hi all,
>
> I have decided again to try and add the help dialog but cannot build
Did the example I posted not work for you? Worked OK for me...
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/li
On 20/12/10 22:07, John Hoare wrote:
> One thing that has occurred to me, is to do something like what SDL
> does: It renames the user's main() function to SDLmain using a #define,
> and then calls that main function after it has done its own setting up.
> I could do something similar, but call th
On 20/12/10 22:22, Matthias Melcher wrote:
>
> On 20.12.2010, at 23:07, John Hoare wrote:
>> The reason I've ran into this problem is I wanted to use fltk using
>> the native windows gui rather than the cygwin fltk which relies on
>> running an X-server on top of windows.
>
> The Cygwin version of
On 20/12/10 20:42, John Hoare wrote:
> I feel that I should also mention that the "robot" in question is
> essentially a toy, and this library in question is used for students who
> have never written code before. (Introduction to Computer Science).
>
> The user of the library (the CS1 student) wr
On 13/12/10 23:19, nigo wrote:
> While in theory you can use Fl::set_boxtype() to retheme your app you
> will be very limited.
Yes, that's probably fair - the various hooks for over-riding the
boxtypes and so forth work quite well, if you only want to change the
basic boxtypes.
But if you reall
On 13/12/10 05:12, s wrote:
> I have a whack-a-mole type game using FLTK and I have compiled/run
> the game on a linux server. I need to compile/run it on a sun machine
> (putty) and cannot figure out how to do so. I use the following on
> linux:
Is fltk installed on the Sun box? If so, how was it
On 12/12/10 20:18, Matthias Melcher wrote:
> The issue was that only on SGIs you could treat a regular X11 window
> as an OpenGL window without troubles. This is now again possible on
> OS X, but not on other platforms, where you either draw with native
> calls *or* with OpenGL calls. The demo pro
On 11/12/10 23:20, Greg Ercolano wrote:
>
> You can re-theme individual widgets by wrapping them in a C++ class
> in the app code.
This is what I'd advise, except that...
> I also have some vague memory of there being a way to hook into
> FLTK's drawing routines from an ap
On 11/12/10 08:00, Sparkaround wrote:
> Is it possible to create a custom theme without patching fltk?
What version of fltk?
And what do you actually mean by theme? There seem to be variant
interpretations of just whet is meant by theme...!
Anyway, all that aside, and discounting the theme suppo
On 10/12/10 09:22, Paul R wrote:
>
>>
>> Try using an Fl_Return_Button instead of a regular button.
>> Spacebar is normally the keynav way to trigger a button when it has
>> focus.
>> When you want the Enter key to do it, us an Fl_Return_Button.
>>
>> See also: the 'ask' progra
On 10/12/10 12:19, Paul R wrote:
> How can i get a window with border, but without the
> maximize/minimize icons?
Window decorations are the responsibility of the window manager (WM),
not of fltk, so there's no direct way in fltk to select which (if any)
of the window controls are shown (though
On 08/12/10 18:06, Greg Ercolano wrote:
> Anna wrote:
>> I am trying to load fltk using Visual C++ express.
>> I have tried the various versions, but I cannot find
>> the file fltk.dsw.
>
> Probably your file browser is stripping off the .dsw extension
> because recognizes it as a Visua
On 08/12/10 15:29, Alvin wrote:
> I have attached a very very old DND example program. You can use this to
> test DND. I can confirm that it does work with SVN 1.3.x r7881 (the WC
> revision before I just updated).
Didn't get the attachment, but used the simple DnD example from Greg's
cheat-shee
On 08/12/10 15:21, Alvin wrote:
> Hello all,
>
> I have updated my working-copy of 1.3.x to r7979. Since doing that I am
> experiencing a segfault when I drag 'n drop a file (from Dolphin in KDE
> 4.5.4) onto my app.
>
> I have managed to track down the location of the segfault using
> KDevelop4+GD
On 07/12/10 22:39, Slick Dealer wrote:
> I think I tested Fl_Image resizing but realized that image rendering
> is much better if I use Fl_Help_View to display/resize the image. Has
> anyone had a similar experience?
Hmm, that's odd because Fl_Help_View just uses the fltk copy() method to
do it
On 07/12/10 20:00, Albrecht Schlosser wrote:
> On 07.12.2010, at 19:26, Slick Dealer wrote:
>
>> If I could easily resize PNG images using FLTK, I wouldn't be using
>> Fl_Help_View.
>
> You can, but it's a low quality resizing algorithm. The key is
> Fl_Image::copy(int w, int h). You should load t
On 03/12/10 18:58, Slick Dealer wrote:
> Hello there,
>
> I am using FL_Help_View to render png images in my app. It works fine
> for small images, but for anything more than a 3 MB PNG image,
> Fl_Help_View takes 10-15 seconds to display it. Is there any way to
> speed image rendering through Fl_H
On 19/11/10 15:17, Paul R wrote:
> Demos are super yes, well chuffed, nice to have those examples.
>
> Regarding command line programming in general i have always thought
> it would be a bit of a pain when using lots of files in a project
> how does it work there? You type in a big line of them and
Greg Ercolano wrote:
> Marc Levoy wrote:
>> For an important but infrequently used program based on FLTK, I have suddenly
>> found that it is able to obtain only 5-bit color buffers (5+5+5 instead of
>> 8+8+8), causing my application to mis-perform. (I read back the frame
>> buffer,
>> so the bit
md houssy wrote:
> I am using a Fl_Gl_Window and I want to set an image to the
> background ! the Fl_Tiled_Image does not return anything !
If it's a GL window, you need to do all drawing in that context via GL
calls - fltk drawing into a GL context doesn't work (or at least, not
reliably!) Thi
md houssy wrote:
> I have make two Fl_Choice widget ; I wnder to know wether I nedd a
> handle method to show the list ?
No, that should not be necessary.
> If some one have a simple example I
> will be so greatful !!!
Have you looked at the examples in the test folder? Some of them show
how t
dirac wrote:
> Hi FLTKers,
> I'm writing a little app where a series of buttons "do something" when the
> corresponding key is pressed (and when is released too), displaying a
> graphical status when the button is on (e.g. a black square inside it); 'q'
> handles the first button, 'w' the second
Anton Deguet wrote:
> I am using fltk 1.3.x-r7677. I wanted to try FLTK on Mac OS (10.6)
> compiled for x86_64. I used "configure" (not CMake) to compile fltk
> itself with a modified configure.in (replaced i386 by x86_64, a
> temporary hack). fltk compiles and the tests run well as far as I
>
md houssy wrote:
> I am sorry but I couldn't manage that, this is my class , where B is
> the box I would like to be changed any suggestions ?
Actually, looking at this again, I notice that your box B is not defined
as actually having a box, only a frame:
> B(FL_BORDER_FRAME,(w/2)-400-h/35,(h
md houssy wrote:
> I am sorry but I couldn't manage that,
Why not? Brian's example looks sensible, and a callback driven by
Fl::add_timeout() is surely the correct way to handle this.
What does not work for you?
> this is my class , where B is the box I would like to be changed any
> suggestion
secretdude...@gmail.com wrote:
> This is really simple...I was just wondering what kind of Windows
> compatibility FLTK 1.1.10 (The stable one, if I got the number wrong)
> had. I couldn't find any documentation saying either way, so forgive
> me if I just missed it somewhere.
>
> Mostly I just wa
Roman Kantor wrote:
> Another possibility to generate postscript or pdf through CAIRO as a
> backend.
This is a good point actually - Cairo works pretty well for this, I used
it to generate PDF output from my music editor program, and that
worked very well, and could handle utf8 text (Japanese
md houssy wrote:
>
> I try to have a transparent background for my GUI, but setting the
> boxtype of the window to FL_NO_BOX just display the last image and
> it isn't dynamic !
That seems about right - as I said in my previous post, the FL_NO_BOX
type does not make the window elements transpar
Albrecht Schlosser wrote:
> So, what we would need is a way to specify a user font (e.g. a
> cyrillic one) and a way to specify the font mapping (UTF-8 to font
> character codes). Neither is implemented currently, and there's no
> API defined for this. :-(
>
> Any ideas and/or code would be appre
>> in fltk-1.3 and all should be well. Probably...
>
> But the point is, even if the widget itself will display non-ASCII
> characters using UTF-8 encoding, the Fl_Postscript_Printer won't
> print them :( If I'm not mistaken, I saw it in the 1.3.x docs: by now
> only Latin chars are supported...
Unregistered FLTK User wrote:
> If this message shows up in the mailing list, please reply to
> it in fltk.general, so that we (I) can see it (one reply
> would suffice, of course).
Hi Albrecht - I saw this message on the 24th - you posted it on the 22nd
I think.
_
Elijah wrote:
> Hey there! I'm new to FLTK, and I got some Linux code that uses an
> ancient version of FLTK (v1.0).
OK - that's *old*... I guess porting from 1.0 to 1.3 will be mostly
straightforward, though there are probably a few gotcha's in there...
> I need to add printing to the
> appli
md houssy wrote:
>
>> 2/ for the class Fl_Input how can we get the string passed into the
>> Fl_input ? Fl_input->value returns a const char*; so how can I get
>> all the text typed into the Fl_Input label ?
>
> I don't understand the question - a char* is a text string, it holds all
> the cha
md houssy wrote:
> hi, I am workin on a GUI and I have 4 simple questions
>
> 1/ I wonder to have a window with a background which is transparent,
> is it possible with fltk??
That depends on what you are trying to do. If you simply want to create
a window that does not draw it's background, th
Boris Mayer-St-Onge wrote:
> FlTK 1.3.x (snapshot 7677)
>
> I'm using a Fl_Help_Dialog widget and I would like to know if the file
> that I'm loading is loaded successfully. Unfortunately, the function
> Fl_Help_Dialog::load(const char *) doesn't have a return value, while
> the function Fl_Hel
Greg Ercolano wrote:
> dimatura wrote:
>> So I'm wondering if there's a way to find out at runtime the width of a label
>
> There's a few:
>
> fl_measure():
>
> http://fltk.org/doc-1.3/group__fl__drawings.html#gccd92d0c0521b0aac30dcb856d438dcd
>
> fl_text_extents()
>
md houssy wrote:
> I have to use icons so I found FL_File Icon class, but I don't know
> how to use it, shall I use the constructor or load directly? for the
> constructor I didn't understand the parameters needed ?
>
>
> Fl_File_Icon::Fl_File_Icon(const char *p,/* I - Filename pattern
> */ i
md houssy wrote:
> how can we resize the image we have already downloaded?
Flt does not provide any tools for image manipulation beyond the actual
displaying of the image. You can use the image copy() method to do basic
resizing of an image (see the pixmap_browser demo for the basics of
that) b
dimatura wrote:
>
> Ok, great. Fortunately the callback functions are pretty fast so the
> GUI remains responsive.
It's generally good practice to make all the callbacks as short as possible.
If you need to do some really *looong* processing, don't do it from a
callback, find some other way to
Matthias Melcher wrote:
> FLTK *does* support multithreading through locks and awake signals,
> but there is always only one single GUI thread (which additionally
> must be the main thread of the application - a requirement by one of
> the underlaying platforms).
Actually, I *think* this was orig
md houssy wrote:
>> You must link with the fltk images and fltk jpeg libraries as well.
>
> how can I do this on code::bloks
>
> I have already set the global variable and I have set the path lib to
> the fltk/lib
No - it appears from the errors that you get, that you have not set the
paths to
newgen wrote:
> I try to compile fltk 1.3 under osx snow leopard. however I fail due to
> several reasons:
Which version of fltk-1.3 do you have? What release number etc.?
All the recent versions, and current svn, seem to build just fine.
>> make
>
> It builds nice until I get:
>
> [ 64%] Bui
59 matches
Mail list logo
