> pre-configured
> framework with all the standard bells and whistles for your average
> forms-based application: E.G. - Main Window - Menu (File, Open, Save,
> Help - all functional)
I know this kind of frameworks from Microsoft and Borland and one of my
reasons to use fltk was, that they doesn'
Howard Rubin schrieb:
> Thanks for the quick reply. Here's what I have now. It's reporting the
> opposite of of the Caps Lock state. In other words, (Fl::event_state() &
> FL_CAPS_LOCK) is zero when Caps Lock is on, and nonzero when it's off.
>
> Is that what you meant in your last message?
Yes, i
>> virtual int handle(int event) {
> if (event== FL_SHORTCUT)
if (event== FL_SHORTCUT && Fl::event_key()== 65509)
Without check of key every shortcut signals caps lock, thats wrong. And
it seems, the real state establishs after the events had run through,
but because of binary sta
> #include
> #include
> #include
> #include
>
> class myWindow : public Fl_Window {
> public:
> myWindow(int x, int y, const char* l) : Fl_Window(x, y, l) { }
>
> virtual int handle(int event) {
if (event== FL_SHORTCUT)
{
> static int n = 0;
> if (F
> and that was last thing preventing me from publishing it.
http://www.edzeg.net/pt100/
Not sure, whether there is any interest, because this is a german tool
for solving a particular electronic problem, now published in an
electronics group. And I failed in writing a fltk-config-makef
MacArthur, Ian (Selex ES, UK) schrieb:
> As a hackaround, it looks like replacing with seems to do
> something... Any good?
Thank you, that solves my problem. I tried to make a little "all
inclusive" tool - one file containing program, helpfiles, info and a
picture - and that was last thing p
I tried to show some html-text for help, but Fl_Helpview doesn't take
care of and mucks up formatting. Doc tells, Fl_Helpview should take
care of , shouldn't it?
Is there a way to get linefeeds, as aspired in the following example. My
system shows no distance between the two lines:
#include
> 3. When the add menu item is clicked, a new button appears, but has garbage
> text.
Garbage text sounds like a well known problem:
> void set( string str ) { label(str.c_str()); }
label() doesn't copy the string (but there is a copy_label()), but just
saves the given const char*. But yo
memoryl...@tin.it schrieb:
> My app is multithreaded ; the main() loop and some other working
> threads, receiving / sending data and doing calculations.
>
> The question: what is the correct way to fire a graphics update from
> a thread ?
We see, there are several correct ways. For measurements m
> #include
> #include
> #include
> #include
>
> int main() {
>
> Fl_Window win(400, 600, "TestWindow");
>
> win.begin();
>
> Fl_Output test(50, 50, 300, 500, "Test");
This is wrong, you must create widgets dynamically when inserting them
to a window. This might work better:
Gonzalo Garramuno schrieb:
> I would like my application to have only one instance of it running at a time.
> How would I go about coding this? Pipes? Sockets? None of the above.
AFAIK mutex or semaphore are ment to realise this.
___
fltk mailing lis
Ups, forgot to initialise, must be:
> Fl_Resize_Window(int w, int h, const char* l= 0):
> Fl_Double_Window(w, h, l),
mp_Callback(0)
> {}
>
> Fl_Resize_Window(int x, int y, int w, int h, const char* l= 0):
> Fl_Double_Window(x, y, w, h, l),
mp_Callback(0)
> {}
> How can I detect Window resizing since
It's a virtual method of the window. My way to use this method directing
resize to a main program:
struct i_callback
{ // main program should be inherited: class main: public i_callback
// and overwrite Resize():
virtual void Resize(int x, int y
> [OK, but only as long as the the menu_item name is not modified... :-( ]
It's also possible to use callback pointer or userdata value entry:
//
// Menu using additional "foo" name:
//
Menu.add("&File",0,0,0,FL_SUBMENU);
> By default in ask popup, ENTER is the shorucut for YES and ESC
> is the shortcut to NO. How can I change. My requirement is focus should be
> on NO and ENTER should for NO only. When I pressed ESC button then YES
> should be done.
You could use fl_choice, rename the buttons and inve
Albrecht Schlosser schrieb:
> On 06.12.2012 13:23, Edzard Egberts wrote:
>>> I'd like to add something like this to the README files for FLTK.
>>> However, I'm not using eclipse myself, so I'd depend on your knowledge
>>> to do it right. Would you mind
>> The main problem would be the pcb and the keys, for controller today I
>> would use one of them http://arduino.cc/en/Main/Products (for little
>> amount of pieces) - they are very easy to program (C++!), so there is no
>> "controller development" to do.
>
> Thanks for this info. If we can't find
Edzard Egberts schrieb:
> Albrecht Schlosser schrieb:
>> I'm looking for a keyboard extension or a special function keyboard
>> that can be used to type special keys normally not found on a standard
>> computer keyboard, or maybe a keyboard extension that can be us
Albrecht Schlosser schrieb:
> I'm looking for a keyboard extension or a special function keyboard
> that can be used to type special keys normally not found on a standard
> computer keyboard, or maybe a keyboard extension that can be used
> with FLTK.
For a vending machine I once designed an addit
> I'd like to add something like this to the README files for FLTK.
> However, I'm not using eclipse myself, so I'd depend on your knowledge
> to do it right. Would you mind if we'd take your text for a README
> file? Could you maybe help to make it even more clear?
Yes, at home I can try Linux, W
siaswar tompani schrieb:
> How can I compile my projects in eclipse. It can't find th fl librarys.
> I can Compile in command line so it is not mingw issue
Select your project, than go to [File]->[Properties]->"C/C++ Build" ->
"Settings":
"GCC/MinGW C++ Compiler - Includes" there must be a path
Howard Rubin schrieb:
> I'm used to windows where a call to DoModal() doesn't return until you
> close the popped up window. Is there a way to do that in fltk?
void popup()
{
pWindow->show();
while (pWindow->visible() && Fl::check()) Fl::wait();
}
This should work, when window can
David Allen schrieb:
> parent()->redraw() works! thank you so much!
When the redrawn content is inside of you box, you should set a
box-style and not a frame-style to this box, eg. FL_DOWN_BOX instead of
FL_DOWN_FRAME. This will the box will redraw it's background before
drawing some content.
_
Thank you, problem solved.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Ian MacArthur schrieb:
> Here's a thing; I've been using the 1.1.x svn, are you? Or are you
> using the last tarball? I just wonder of maybe the svn has had some
> minor tweaks subsequently, that fix the configure or something?
Yes, the svn builds all libraries, also fluid and test apps execute.
Ian MacArthur schrieb:
>
> Here's a thing; I've been using the 1.1.x svn, are you? Or are you
> using the last tarball?
The last tarball from the download side (fresh download ;o).
> I just wonder of maybe the svn has had some
> minor tweaks subsequently, that fix the configure or something?
May
Ian MacArthur schrieb:
>
> On 11 Nov 2012, at 10:44, Edzard Egberts wrote:
>
>
>> Now the main libraries are built, but there is a problem regarding
>> fluid:
>>
>> Linking fluid... /usr/bin/ld: ../lib/libfltk.a(fl_font.o):
>> undefined reference to symbol
Ian MacArthur schrieb:
>
> On 10 Nov 2012, at 16:37, Edzard Egberts wrote:
>
>> Ian MacArthur schrieb:
>>>
>>> On 10 Nov 2012, at 10:46, Edzard Egberts wrote:
>>>> So, how to solve the png.h problem, or how to build without
>>>> using syst
> I am wondering if I am on the right track regarding status bars. I found
> this post here:
> http://www.gidforums.com/t-26030.html?highlight=status
>
> This person was using a button for a status bar. There does not seem to
> be a native status bar in FLTK but is this the best way to simulate one
Ian MacArthur schrieb:
>
> On 10 Nov 2012, at 10:46, Edzard Egberts wrote:
>> So, how to solve the png.h problem, or how to build without using
>> system files?
>
> Anyway, I tried two trees, one with the system png and one with the
> local fltk png; both built just fi
For older projects I need fltk 1.1.10 and tried to compile it at new set
up system. Compiling fltk-1.3.0 works, but 1.1.10 tells about an error
in "png.h" and doesn't create libfltk_images.a (libfltk.a and
libfltk_forms.a it creates):
/usr/include/png.h:722:16: Fehler: forward declaration of »p
Klaus Rudolph schrieb:
> Stupid beginner question:
>
> I have a main window with a menu bar. One of the menus should be "&Exit"
> and the callback should terminate the application.
>
> As I read, I should delete the main window. If I do a
> Fl::delete_widget(win) my application crashes with double
w. szukalski wrote:
>>> The solution is adding the widgets to the main window.
>>
>> All widgets must either be created within the "begin/end" scope of their =
>> container widget, or must be explicitly "add"ed to their container =
>> widget (window or group) for them to function, so I'm not sure w
w. szukalski schrieb:
> The HelpView.cxx does not allow to add() or insert() a widget.
> I have tried to do that. No visible result either using add()
> or insert().
>
> The number of children() is incremented by one. That is all
> I see.
>
> Is there a way to add() or insert() a widget ?
Yes, you
> This is in menu..
> {"&Close ",FL_CTRL+'X',(Fl_Callback *) window_cb},
> so CTRL+'X' should work.. but it doesn't work ?
I just took a look by the way and I wonder about uppercase 'X' - maybe
FL_CTRL + 'x' works better?
___
fltk mailing list
flt
Edzard Egberts schrieb:
> Fl_Native_File_Chooser chooser(Fl_Native_File_Chooser::BROWSE_FILE);
> if (!chooser.show())
> {
> m_Log.Load(chooser.filename());
> if (m_Log.Error.empty())
> {
> for (unsigned i= 0; i< 3; ++i)
> { // Clear graphi
I had some problems regarding offscreen drawing - sometimes it worked,
sometimes not. I found modal loops causing the problem, e.g. dialogues
or menus. They seem to catch the graphic and offscreen drawing starts to
work, when those windows are totally cleared:
Fl_Native_File_Chooser chooser(Fl_
Gonzalo Garramuno schrieb:
>> Gonzalo Garramuno schrieb:
window must be shown before setting the icon.
>>>
>>> Thanks, that prevents the crash but the icon is not shown in the window.
>>
>> Yes, to show the icon, it must be set, before the window is shown.
>>
>> Maybe this helps:
>>
>>> i
Casey schrieb:
> So I am trying to replicate my own version of mspaint with fltk. I
> have two problems, my first problem is that I am limited to a certain
> number of points. My current method is using a predetermined amount
> of points(line 46: point points[1000]; ) Is there a better method
> tha
Gonzalo Garramuno schrieb:
>>
>> window must be shown before setting the icon.
>
> Thanks, that prevents the crash but the icon is not shown in the window.
Yes, to show the icon, it must be set, before the window is shown.
Maybe this helps:
> int main( int argc, char** argv )
> {
> fltk::Win
> Thank you Edzard for the files you posted, I was going that way anyway, but
> your posts will save me a lot of time!
Just forwarding help.
> Is there a real need to have the fl_read_image() call at a
> specific place? or is the only important thing that drawing be finished?
You might want to
MacArthur, Ian (SELEX GALILEO, UK) schrieb:
> of course.
Finally I found what causes my problem - it is because of the menu!
When I call my offscreen-drawing from a button, it works, when I call it
from the menu, it fails "X_FreePixmap: BadPixmap (invalid Pixmap
parameter) 0x340001e". This is ea
MacArthur, Ian (SELEX GALILEO, UK) schrieb:
>> Now I wonder, how to draw a window taller than screensize:
> I create my own group widget, that draws into the offscreen, and use
> that as my outer window, and also I can grab the "full" oversized
> "window" from the offscreen, of course.
"of course
Rajesh Kumar schrieb:
> Hi all,
>
> When I clicked on a button, am incrementing a variable. If that
> variable reaches to some number lets say 50 then a popup window showing the
> value of that variable should appear. After 2 secs the popup window should
> hide. This should happen untill
#ifndef HAVE_WRITE_JPEG_H
#define HAVE_WRITE_JPEG_H
#ifndef WRITE_DATA_ERROR
# define WRITE_DATA_ERROR -1
#endif
#ifndef WRITE_DATA_OK
# define WRITE_DATA_OK 0
#endif
#ifndef MAX_JPG_COM_LENGTH
# define MAX_JPG_COM_LENGTH 65000L /* must be <= 65533 in any case */
#endif
/* Allow C++ Port
/*
* write_png.h
*
*/
#ifndef WRITE_PNG_H_
#define WRITE_PNG_H_
extern int write_png(const char *file_name, /* Name of file to be
written */
unsigned char *datap, /*
pointer to image data array */
int
Simon schrieb:
> Hi there,
>is there a quick and simple way to save a window's drawn contents to a
> file (like a screenshot but clipped to the fltk window)?
there is a way, but "quick and simple" seems a bit euphemistic to me.
You can get the windows content out of the draw-function and then
Now I wonder, how to draw a window taller than screensize:
When I'm using fl_offscreen, I can define a drawing area much taller
than the real screen resolution and draw to it, using the
fl_draw-functions. This works fine and I used it, to export png images
of plots.
But this morning $BOSS was
> is there a "C" gui Designer out there?
http://www.free-soft.org/guitool/
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Greg Ercolano schrieb:
> On 05/04/12 02:36, MacArthur, Ian (SELEX GALILEO, UK) wrote:
>>
>>> Hmpf - the default is text and I know this, but forgot to take care
>>> about. Very stupid, of course it works now...
>>
>> For what it's worth, I just use "rb" and "wb" regardless of
>> platform since the
MacArthur, Ian (SELEX GALILEO, UK) schrieb:
>
>> Hmpf - the default is text and I know this, but forgot to take
>> care about. Very stupid, of course it works now...
>
> For what it's worth, I just use "rb" and "wb" regardless of platform
> since the *nix versions ignore the "b" anyway...
This doe
Albrecht Schlosser schrieb:
> On 04.05.2012 09:53, Edzard Egberts wrote:
>> I'm not sure, whether this problem comes from fltk, but maybe someone
>> knows it:
>> Where could the problem come from? Maybe related to utf8? How to go on?
>
> How did you open the file?
I'm not sure, whether this problem comes from fltk, but maybe someone
knows it:
I'm using a write_png() function and it works under Linux. But after
compiling it for MS-Windows, the software also writes png-files, but
it's not possible to open them - "PNG file corrupted...".
The only differenc
MacArthur, Ian (SELEX GALILEO, UK) schrieb:
>
>> Is there a special way to connect fl_read_image() to offscreen
>> buffer? Maybe the real problem comes from this function? Do I need
>> some make_current()? But I'm using the offscreen inside of draw(),
>> so drawing should work.
>
> You need to "beg
Albrecht Schlosser schrieb:
> On 02.05.2012 15:51, Edzard Egberts wrote:
> I don't think that this has anything to do with the screen_xywh()
> functions. You're calling:
>
> Fl_Offscreen OF= fl_create_offscreen(1000, 1000);
> fl_begin_offscreen(OF);
> Fl_Window::dra
Matthias Melcher schrieb:
>
> On 02.05.2012, at 14:27, Edzard Egberts wrote:
>> Is it a known problem, that offscreen drawing doesn't work for
>> both screens of dual screen systems? I'm using Fedora 14, Kernel
>> 2.6.35.14, GNOME 2.32.0
>
> No. I hear this
Matthias Melcher schrieb:
>
> On 02.05.2012, at 12:03, Edzard Egberts wrote:
>
>> Edzard Egberts schrieb:
>>> Must be something more basic.
>>
>> I just found out - it was a problem of x-/y- coordinates. Need to
>> tell fl_read_image() the position of the
Edzard Egberts schrieb:
> Must be something more basic.
I just found out - it was a problem of x-/y- coordinates. Need to tell
fl_read_image() the position of the window, otherwise it is out of
drawing area.
Sorry, I was looking for some hours for this problem, but just when I
posted
I missed to tell using FLTK 1.3 this time.
> fl_rect(100, 100, 100, 100, FL_BLACK);
This is from a test, I also tried to draw inside of offscreen and I
tried to provide a buffer to fl_read_image(). Must be something more basic.
___
fltk mailing list
fl
I really don't understand, what's wrong with this code, but I never "Got
Image". Think it worked before this way, but what is it missing now? To
me it seems, fl_read_image() doesn't find the offscreen:
#include
#include
#include
#include
#include
#include
using std::cout;
Albrecht Schlosser schrieb:
> or will we move to FLTK 3 with styles and such soon???
Anyway you are right, this is the way to go. I just took a look to the
code and "Style *style_;" is exactly what I need to realise my concept.
Okay, we will see...
___
Greg Ercolano schrieb:
> On 04/16/12 11:14, Edzard Egberts wrote:
>> I'm in doubt of Exceptions, but I love using STL and I don't like char*.
>> To me it's not C++ without STL, at the very most a C+.
> However, FLTK 3.x might be an opportunity to draw
Albrecht Schlosser schrieb:
>> I know this working (using another approach, see my template example)
>> and it's fine - when there is a high resolution monitor, you just need
>> to resize the window, save size and the whole software is adjusted to
>> the current resolution.
>
> Probably only if al
Albrecht Schlosser schrieb:
> in general, we *can* now add ABI-breaking features if we're convinced
> that they will/should be in a future version of FLTK and that they are
> not too big a change so that we can maintain the code with all the
> necessary #ifdef's.
In general it is possible, but you
Albrecht Schlosser schrieb:
> On 15.04.2012 12:26, Edzard Egberts wrote:
>>> (1) Adding data to Fl_Widget would change the ABI, and we probably
>>> wouldn't do this, because this would only become generally usable in
>>> a new FLTK version (1.4 or 3.0), but
Albrecht Schlosser schrieb:
> On 14.04.2012 14:22, Edzard Egberts wrote:
>> Fl_Fontsize textsize() const { return h0 ? (l0 * h())/h0 : l0; }
>> void textsize(Fl_Fontsize s) { h0 ? l0= (s * h0)/h() : l0= s; }
>>
>> So the origin values will be kept and it is only possible
Domingo Alvarez Duarte schrieb:
> We don't need to remember the original sizes at widget level, a better
> place is at group level like it is now and add the font sizes to this
> structure (look at this thread
> http://www.fltk.org/newsgroups.php?s1+gfltk.development+v5+T0+Qst_widget_sizes).
I nee
Edzard Egberts schrieb:
>
> Harhar - I just went through the examples...
and I wondered, why some texts are wrong sized. It's because there is no
redefinition of starting values l0 and t0. So this approach is too basic.
To make a version, that would work fine for existing code,
Edzard Egberts schrieb:
> Edzard Egberts schrieb:
>
>> The appended patch realises this for Fl_Widget and after rebuilding FLTK
>> all widgets will zoom their fonts, until h0 is cleared
>> (pWidget->H0(0);).
>
> There was a little bug - the resize() should use new
Edzard Egberts schrieb:
The appended patch realises this for Fl_Widget and after rebuilding FLTK
all widgets will zoom their fonts, until h0 is cleared
(pWidget->H0(0);).
There was a little bug - the resize() should use new H, not current h().
Fixed patch appended.
--- ./fltk-1.3_Original/
Ian MacArthur schrieb:
> That still does not address the more general issue of being able to
> "zoom" the entire app on the fly
You also asked how to realise it for FLTK 1.3 and I thougt about it.
It is not a real problem to add this functionality, but it is a problem
to keep it light:
There i
David Lopez schrieb:
> I would like to get boxes #90 and #91 to be redrawn but not the other 98
> boxes.
Where is the problem to redraw 98 boxes?
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
David Lopez schrieb:
> Hi, I have the following problem: Suppose that you have two widgets,
> let's say Fl_Boxes, overlapped in a window. You need to redraw the
> one in the back.
parent()->redraw();
> Is there any way to get FLTK 1.3
> to keep track of the widgets that are above a given widget t
Edzard Egberts schrieb:
> fl_basic_font_size< Fl_Window > Window(400, 200);
> Window.resizable(&Window);
> new Fl_Box(100, 100, 100, 25, "Hello World");
> Window.end();
> Window.show();
I should test examples before posting - I forgot the format!
#in
Edzard Egberts schrieb:
He also could wait until tomorrow
not really necessary.
fl_basic_font_size< Fl_Window > Window(400, 200);
Window.resizable(&Window);
new Fl_Box(100, 100, 100, 25, "Hello World");
Window.end();
Window.show();
return Fl::run();
If you don't w
Greg Ercolano schrieb:
> On 04/12/12 17:53, David Topham wrote:
> Still, I'll bet you can either zoom your screen or change
> the display's resolution to make the application larger.
> A Mac is best at this, since you can zoom in and out easily
> with keyboard shortcuts.
He
Edzard Egberts schrieb:
> There is no problem, but you just want to use FLUID to set some
> different fonts to some widgets?
sorry, forget about it - now I figured out, what you are talking about.
___
fltk mailing list
fltk@easysw.co
David Topham schrieb:
> I searched around and found the place where
> I think it is this section since the title of the
> input box where I am entering code is "Code Properties";
> yet even though I changed it from "textsize 11" to
> "textsize 15" here
> (and did the write code and rebuilt fltk/f
Edzard Egberts schrieb:
> Edzard Egberts schrieb:
http://www.edzeg.net/komponenten/FLTK/font_size/
> Yes, it works, but for the moment there is a bug remaining
I think it is fixed.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/m
Edzard Egberts schrieb:
> David Topham schrieb:
>> One feature I would like to see added (or add myself) is some way to
>> make the fonts much larger.
>
> What's about this?
>
http://www.edzeg.net/komponenten/FLTK/font_size/
>
> It worked for FLTK 1.1 and I t
David Topham schrieb:
> One feature I would like to see added (or add myself) is some way to
> make the fonts much larger.
What's about this?
http://www.edzeg.net/komponenten/FLTK/font_size/
It worked for FLTK 1.1 and I think it will also work for FLTK 1.3. There
is a readme and an exam
Ian MacArthur schrieb:
> What I am trying to say is that if you draw all the things you want
> to capture, into the fl_offscreen, then you can use fl_read_image()
> to get a pointer to the raw offscreen data, that you can then write
> out to a PNG or etc.
Thank you, that's it! I really didn't unde
Ian MacArthur schrieb:
>
> On 19 Mar 2012, at 14:43, Edzard Egberts wrote:
> Sorry - I think you have misunderstood my intent; if you have the
> data, and I took to from your original post that you did
Maybe that's the problem, let me repeat with other words:
I'm using f
Ian MacArthur schrieb:
>
> On 19 Mar 2012, at 13:34, Edzard Egberts wrote:
> What I did was just read back the data from the offscreen, repack it as RGB,
> then write it to a PNG using the stock PNG API directly.
>
> Getting the data out was done as per this howto:
>
>
This is a FAQ, but I missed to keep track of this.
I need to save a plotted graph as a picture, e.g. png, bmp, jpg. I
think, I should use Fl_Offscreen and something like
Fl_Offscreen::Save_Png() is what I need.
I found an existing function "write_jpg()" which needs "unsigned char
*datap; // po
> The thing is that when it's a double click you will first print 1 and
> then 2. Could you post an example that prints "single" when it's a
> single click and only prints "double" (without printing "single" as
> well) when it's a double-click ?
The thing is, that a double click really is meant a
Richard Sanders schrieb:
> What has recently started is that the field that should be hidden is
> not, with the resulting mess on the screen. Switch back and forth 2-3
> times and things then get back to normal
> Has anyone beat this or a simular problem to death.
Maybe it's a common problem - so
Albrecht Schlosser schrieb:
> On 21.02.2012 09:34, Domingo Alvarez Duarte wrote:
>> Yor proposed solution doesn't address the resolution problem.
>
> And why do you think so? What if Edzard's "window" has a width of
> 10.000 and a height of 30.000 ?
No, this is not, why I posted the code:
in
Greg Ercolano schrieb:
> On 02/20/12 10:45, Domingo Alvarez Duarte wrote:
>> The actual printing capabilities of fltk is a great advance, but the
>> quality of image printing isn't all good because it's using screen
>> resolution to print, there is a way to allow higher resolutions for
>> printing
MacArthur, Ian (SELEX GALILEO, UK) schrieb:
> Rather, you (we all...) need to think differently about how the user
> interacts with large lists in a touch environment. Basically, a
> choice-style widget, a drop-down box, menus, all these things we are
> used to on the desktop no longer make any sen
> My choice box will contain large list . Am not
> getting scroll bar in choice box. So that itbecame too difficult to select
> items. Can anybody suggest me how to get scroll bar in choice box.
Maybe there is another solution - do you know, that a choice can be used
like a menu with a tree-struc
> Is there any other way doing it? I don't have to used jpeg.
> Could provide as well a raw bitmap (in rgb?). Its actually for a logo
> so it won't be very big.
You should consider to use xpm format, maybe using GIMP to create it out
of a jpeg. xpm is ASCII text and you can include it directly to
MacArthur, Ian (SELEX GALILEO, UK) schrieb:
>
>> Wasn't that a difference between FLTK 1.1 and 1.3?
>>
>> 1.3 works this way, but 1.1 needs some pWindow->x() + pWidget->x() to
>> meet the coordinate?
>
> Um, I don't *think* so - the example I posted was originally a fltk-1.1
> example I made, but t
MacArthur, Ian (SELEX GALILEO, UK) schrieb:
>
>> I try to create a Fl_Group derived widget, which redirects pixels
>> by means of a fl_offscreen buffer for manipulation.
>> fl_offscreen works fine, pixel manipulation is fine, but drawing is
>> displaced.
>
>
> Hmm, I dunno - this seems to work OK f
Johan R schrieb:
> seems this is a very primitive forum
> :).
This is not a forum, but a newsgroup. A forum is the very primitive
successor of a newsgroup, designed to be usable by every ordinary
person, who can click around with a browser.
> I have considered making my own widget since i feel
Edzard Egberts schrieb:
>You should try a linux group.
There must be a group related to X.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Barry Branham schrieb:
> So kmod-nvidia + twinview on el6 give the problem.
>
> Any suggestions?
I think it is more a linux problem, than fltk related, because it works
without twinview. You should try a linux group.
I started using Fedora 13 on a twin view system and there always was
some trou
Greg Ercolano schrieb:
> void ShowWidgets_CB(Fl_Widget *w, void*) {
> Fl_Window *win = w->window(); // get button's parent window
> for ( int i=0; ichildren(); i++ ) { // walk all window's children
> const char *classname = "?";
> Fl_Widget *w = win->chil
Greg Ercolano schrieb:
> On 01/16/12 14:28, ORL wrote:
>> I need to get the parent of a Fl_Box type to determine what the handle
>> method does.
>> To be more accurate, I need to check if the parent class is light_xyPad
>> (which is a class I've written, quite close to Fl_Group, but with some
>>
fltkgui schrieb:
> I have an odd mingW 'make' error, with a portable version.
> MingW 4.5.3, GCC 4.6.1. FLTK v1.3.x.
>
> Fl_JPEG_Image.cxx:158:33: error: 'boolean' was not declared in this scope
> Fl_JPEG_Image.cxx:158:41: error: expected ';' before 'FALSE'
It's a problem of jpeglib and to me it
1 - 100 of 282 matches
Mail list logo
