Re: [fltk.general] FLTK Platform
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't match my needs. That means, I didn't use the framework, but I worked aroud it, because most of my applications doesn't match this standars scheme. Lately I have found myself writing quite a few new FLTK based apps and I always seem to be reinventing the wheel. Is there an out-of-the-box skeleton framework I can re-use for this purpose? So you can copy your own projects. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
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, it shows every time the wrong of of two states, so you know for sure the right one - it's !state. I'm less than enthusiastic about displaying the 'Caps Lock is on' message when the test in the code says it's off. Is there really no alternative? It seems, that caps-lock handling starts to work after key handling and I think there might be other problems, like switching caps lock, when there is another window in focus. I think a better way is, to use a timer and to check for change of state e.g. all 0.25 seconds. For humans this is fast enought to appear as instantly. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Secret_Input.H
#include iostream
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 (Fl::event_state() FL_CAPS_LOCK) {
std::cout caps lock ++n std::endl;
} else {
std::cout caps unlock ++n std::endl;
}
return 1;
}
else
return Fl_Window::handle(event);
}
};
int main(int argc, char* argv[]) {
myWindow* win = new myWindow(300, 200, );
new Fl_SecretInput(20, 20, 100, 15, );
win-end();
win-show();
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
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 state it's no problem.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
I tried to show some html-text for help, but Fl_Helpview doesn't take
care of br and mucks up formatting. Doc tells, Fl_Helpview should take
care of br, 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 FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Help_View.H
const char* cHTML=
!DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01 Transitional//EN\
html
head
meta http-equiv=\content-type\ content=\text/html;
charset=ISO-8859-1\
/head
body
First Linebr
br
br
Second Line after 3 times lt;brgt;br
br
/body
/html;
int main()
{
Fl_Double_Window Win(400, 200, Helpview);
Fl_Help_View* pHV= new Fl_Help_View(10, 10, 380, 180, );
Win.end();
pHV-value(cHTML);
Win.show();
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
MacArthur, Ian (Selex ES, UK) schrieb: As a hackaround, it looks like replacingb withp/p 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 preventing me from publishing it. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
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-makefile, so it's plain source. :o/ ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Correct way to fire graphics updates from abackground thread
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 made by threads
I'm using a list for buffering data. Some pseudocode:
struct point {
int x;
int y;
point(int px= 0, int py= 0): x(px), y(py) {}
};
std::list point Buf
critical_section CS;
void Incoming(int x, int y)
{ // Buffering incoming data:
CS.lock();
Buf.push_back(point(x, y));
CS.unlock();
}
std::list point Outgoing()
{ // Calling buffered data
std::list point OBuf
CS.lock();
OBuf.swap(Buf);
CS.unlock();
return OBuf;
}
while(!OBuf.empty())
{ // Read points in original sequence:
Use_Point(OBuf.front().x, OBuf.front().y);
OBuf.pop_front();
}
So data are coming in in threads speed and GUI is updated in user
speed, evaluating several data at once. This basic mechanism I'm using
with several objects, from points to system states.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Linker problem with Fl_Output
#includeFL/Fl.H
#includeFL/Fl_Window.H
#includeFL/Fl_Input.H
#includeFL/Fl_Output.H
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:
Fl_Output* pO_Test= new Fl_Output(50, 50, 300, 500, Test);
It is not necessary to keep pO_Test, because the window grabbed the
Fl_Output, but you can use it for more initialisation, e.g. setting
pO_Test-callback(), or something like that.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
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 list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Detect Resizing
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, int w, int h)= 0;
};
class Fl_Resize_Window: public Fl_Double_Window
{ // Window with extended resize() method to replace Fl_Double_Window
public:
Fl_Resize_Window(int w, int h, const char* l= 0):
Fl_Double_Window(w, h, l)
{}
Fl_Resize_Window(int x, int y, int w, int h, const char* l= 0):
Fl_Double_Window(x, y, w, h, l)
{}
virtual ~Fl_Resize_Window() {}
inline void Callback(i_callback* pC){ mp_Callback= pC; }
protected:
i_callback* mp_Callback;
virtual void resize(int x, int y, int w, int h)
{
Fl_Double_Window::resize(x, y, w, h);
if (mp_Callback) mp_Callback-Resize(x, y, w, h);
}
};
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Detect Resizing
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)
{}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Menu_Item offset calculation
[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);
Menu.add(File/Konvert1, 0, 0, (void*) Konvert1);
Menu.add(File/Konvert2, 0, 0, (void*) Konvert2);
Menu.add(File/Calc Linear, 0, 0, (void*) Linear);
Menu.add(File/Quit,0, 0, (void*) Quit);
//
// Subroutines to get menuitem by value or by foo (also usable for
Fl_Choice):
//
Fl_Menu_Item* Choice_Value(Fl_Menu_* pChoice, void* Val)
{
if (pChoice) for (int i= 0; i pChoice-size(); ++i)
if (pChoice-menu()[i].user_data_== Val)
{
pChoice-value(i);
pChoice-redraw();
return const_cast Fl_Menu_Item* (pChoice-menu()[i]);
}
return 0;
}
//--
Fl_Menu_Item* Choice_Foo(Fl_Menu_* pChoice, const char* Foo)
{
if (pChoice Foo) for (int i= 0; i pChoice-size(); ++i)
{
const char* pFoo= (const char*) pChoice-menu()[i].user_data_;
if (pFoo strcmp(pFoo, Foo)== 0)
{
pChoice-value(i);
pChoice-redraw();
return const_cast Fl_Menu_Item* (pChoice-menu()[i]);
}
}
return 0;
}
//
// Examples of using subroutines:
//
void dlg_main::Menu_Toggle(string Foo, bool An, bool Only)
{
if (Fl_Menu_Item* pMI= Choice_Foo(pMenu, Foo.c_str()))
{
if (Only) pMI-setonly();
else if (An)pMI-set();
elsepMI-clear();
}
}
//
bool dlg_main::Menu_Value(string Foo)
{
if (Fl_Menu_Item* pMI= Choice_Foo(pMenu, Foo.c_str()))
return pMI-value();
else return false;
}
//
void dlg_main::Menu_Deactivate(string Foo)
{
if (Fl_Menu_Item* pMI= Choice_Foo(pMenu, Foo.c_str()))
pMI-deactivate();
}
//
void dlg_main::Cb_Menu()
{ // Callback of Menu:
string Foo;
if (const Fl_Menu_Item* pV= pMenu-mvalue())
{
if (const char* pU= (const char*) pV-user_data()) Foo= pU;
else return;
}
else return;
// Evaluate valid callback:
if (Foo== Quit)Close();
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Need help for ask popup
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 invert the return value. This is normal use of fl_choice: if (fl_choice(Are you sure?, No, Yes, 0)) He_Is_Sure(); This might serve your needs better: if (!fl_choice(Are you sure?, Yes, No, 0)) He_Is_Sure(); ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] how Do I Compile fltk in eclipse
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 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, Windows, FLTK 1.1, FLTK 1.3. I'd appreciate that, and if you'd share what you find, I'd be willing to add it to the docs. I'm sorry - but it's only a time delay, not forgotten. I hope to realise it this week. ;o) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Keyboard Extension with function keys
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 a complete solution, I would also consider building an own device, but that is probably not what my customer (a software development company) want to do. However, if it was possible to find someone who builds a case with the keys and puts the controller inside, then ... maybe. Every engineering office using microcontrollers should be able to do this for you - it is a just to do thing, nothing special. It's a standard problem to design special keyboards for devices, e.g. plastic foil keyboards. But for your application you should use single keys, because they are more tactile and durable. Anyway - did you think of keyboard beeps for distinguish blind keypressing? This is also a thing, a microcontroller could do for you (okay, much sophisticated). And regarding to the software development company - selling own hardware saves a dongle. ;o) Do you know whether there are better ways to do it, maybe with a direct USB driver and an API that makes it more direct to use the key presses? Most of the USB solutions create a virtual RS232 port for communication to software. Also the Arduino does - there is a usb connection, but you can access it as a serial device. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] how Do I Compile fltk in eclipse
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, Windows, FLTK 1.1, FLTK 1.3. wsock32 is deprecated, it should be ws2_32 (at least starting with FLTK 1.3), but fltk 1.3 itself doesn't need it added explicitly Okay, I copied these settings for years. ;o) I just tried fltk-config --ldflags (it works ;o) and will fix unnecessary libraries. Thoughts and comments, anybody? You are thinking of a general guide, I saw along this thread. This makes sense, because often IDE users don't know, how the system works. But regarding to Eclipse the options are hard to find, even when you know, they must be somewhere. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Keyboard Extension with function keys
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 additional customers keyboard: I used single keys on a pcb and a controller to send the keys by RS232. The software (yes, uses FLTK ;o) opens the RS232-Port and reads the keys different from main keyboard to a special application (POS). ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Keyboard Extension with function keys
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 used with FLTK. For a vending machine I once designed an additional customers keyboard: I used single keys on a pcb and a controller to send the keys by RS232. The software (yes, uses FLTK ;o) opens the RS232-Port and reads the keys different from main keyboard to a special application (POS). 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. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] how Do I Compile fltk in eclipse
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 to FLTK header files, e.g. c:\fltk, /usr/local/include. GCC/MinGW C++ Linker - Libraries there must be the Libraries filled in (eg. fltk, fltk_images), also the library search path, e.g. c:\fltk\lib, /usr/local/lib. Also there must be some additional libraries entered (more or less depends from you project): Linux: Xft, fontconfig, Xinerama, Xext, freetype, pthread, dl, m, X11, Xpm Windows: pthread, ole32, uuid, comctl32, wsock32 For MS-Windows you need to enter in addition: MinGW C++Linker - Miscellaneous - Linker flags: -mwindows ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Modal windows in fltk?
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 hide itself (by callback).
But there is no advantage in doing it this way, kick you habit.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] want immediate update
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. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] libpng-problemwhencompilingfltk-1.1.10usingFedora17
Thank you, problem solved. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] libpng-problem whencompilingfltk-1.1.10usingFedora17
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. But there is a problem of thread configuration: One of my apps started after a clean built, the other app tells about undefined reference to 'Fl::lock(), undefined reference to 'Fl::unlock(). Okay, maybe I should enable threads, but there is no ./configure? I started svn just by make... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] libpng-problem when compiling fltk-1.1.10usingFedora17
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 system files? Anyway, I tried two trees, one with the system png and one with the local fltk png; both built just fine and appear to be working correctly. I configured with: $ ./configure --enable-threads --enable-xft and with: $ ./configure --enable-threads --enable-xft --enable-localpng --enable-localzlib In each case. One moment, I don't think Yes, I think so. ;o) I'm sorry, I totally missunderstood meaning of options. You are right, the second line configures without using system libpng. 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 'FcPatternAddDouble' /usr/bin/ld: note: 'FcPatternAddDouble' is defined in DSO /lib/libfontconfig.so.1 so try adding it to the linker command line /lib/libfontconfig.so.1: could not read symbols: Invalid operation This is not a problem to me (an old version of fluid works), but maybe this problem will also appear to other users. I think, that's it: I installed libpng-2:1.5.10-1 and now I see, there is a Old version of libpng, needed to run old binaries, libpng10-1.0.59. I simply need to switch the library and it will work (I think). Hmm, I would worry that 1.0.x would be too old, though. We are currently using 1.2.x, and IIRC the png API changed a bit between 1.0 and 1.2, though I may well be talking nonsense of course! To me it looks like a new major version - libpng-2, not libpng(-1). ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] libpng-problem when compilingfltk-1.1.10usingFedora17
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 'FcPatternAddDouble' /usr/bin/ld: note: 'FcPatternAddDouble' is defined in DSO /lib/libfontconfig.so.1 so try adding it to the linker command line /lib/libfontconfig.so.1: could not read symbols: Invalid operation Hmm, that does seem odd though - certainly I seem to be fine with the fltk-1.1.x fluid that I build from svn on my ubuntu-12.10 test box... FWIW, that box has libfontconfig.so.1.4.4 (and libfontconfig.a of course) in the system folders (at /usr/lib/i386-linux-gnu/ in this case) and the fluid code appears to be linking against the .so and working normally, so I wonder if maybe there's something awry in your build? On my system there is a /usr/lib/libfontconfig.so.1.4.4 and two links in the same directory - libfontconfig.so.1 and libfontconfig.so., so this seems to be okay. Please remember, that fltk-1.3.0 builds without problems on the same system. A single undefined reference maybe points to a problem of library sequence? Maybe some libs must be shifted around to cause some magic? I guess a quick make clean ; make might be worth a shot though I doubt it would really help! It reproduces the problem. Other than that, not sure what might be going wrong there - is it only fluid that is borked? Other apps built with that fltk are OK? The app I wanted to maintain, works after a clean build. And I checked the paths - the new libraries are in use. That seems really odd... It's a common computer problem - just when something works, people are changing the rest. ;o) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] libpng-problem whencompilingfltk-1.1.10usingFedora17
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? Maybe it has, I could try this evening. But I think it depends on Fedora. Your Ubuntu might be a current version, but it's a complete different distribution (Debian vs. RedHat) and Fedora is bleeding edge of software. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] libpng-problem when compiling fltk-1.1.10 using Fedora17
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 »png_info {aka
struct png_info_def}«
I think it must be a problem of header-sequence or something like that.
To work around I tried ./configure --disable-localpng and ./configure
--enable-localpng=no but this doesn't work - configure finds system
files and uses them, even when disabled or =no.
So, how to solve the png.h problem, or how to build without using system
files?
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] libpng-problem when compiling fltk-1.1.10 usingFedora17
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 fine and appear to be working correctly. I configured with: $ ./configure --enable-threads --enable-xft and with: $ ./configure --enable-threads --enable-xft --enable-localpng --enable-localzlib In each case. One moment, I don't think, these cases are different, because the first line will auto recognize system libraries and use them. On my system second line leaves config unchanged. What pnglib version does your system have? Mine appears to be 1.2.46 on the system and 1.2.40 in the fltk built-in pulled from svn. I think, that's it: I installed libpng-2:1.5.10-1 and now I see, there is a Old version of libpng, needed to run old binaries, libpng10-1.0.59. I simply need to switch the library and it will work (I think). But because it works for fltk 1.3, I continue to be interested in how to ./configure --disable-localpng. Does this work for you? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] status bar in FLTK ?
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? It depends on what in detail a status bar is ment to be and to do. Maybe it's a line of space at the bottom of the window. You can fill this space by an output, showing status working (hope so ;o). Also a button is okay - the button label show last message and pressing the status bar button may open the message log. Also you could use a group, containing several specialised status objects, like light-buttons, buttons, outputs, timers and so on. So there is no native status bar in FLTK, because there is no best way of being a status bar. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] how to leave Fl::run
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 free corruption. Any hints? win-hide(); Fl::run exits, when all windows of the application are closed (hidden). ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] add or insert a widget
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 added to their container = widget (window or group) for them to function, so I'm not sure what is = different about this? Am I missing something here? class FL_API HelpView : public Group But neither 'add(InputWidget)' nor 'Group::add(InputWidget)' show a widget. But they do not show anything except free space for a widget. Did you add the widget to a group, but outside of groups area? E.g. a group(10, 10, 100, 100) and a widget(120, 120, 50, 100) was added to this group? I think this would show the widget, but prevent it from working. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] add or insert a widget
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 are using it successful. I think you miss to show() the new widget and will see more by new_widget-show(). ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] How to wait for window or menu clearance?
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_Native_File_Chooser::BROWSE_FILE);
if (!chooser.show())
{
m_Log.Load(chooser.filename());
if (m_Log.Error.empty())
{
// while (Fl::modal()) doesn't work:
for (unsigned i= 0; i 3; ++i)
{ // Clear graphic
Fl::check();
os_fkt::Sleep(100);
}
Do_Eval_Log(m_Log); // offscreen drawing!
}
}
When debug stops at for loop, the whole dialog is shown on screen. First
loop deletes it content, second loop removes window, third loop might
not be necessary, but can I be sure? Is there a better way to check for
graphical clearance and make sure it also works on other/slower computers?
In the moment I'm using Linux, but I think this problem is FLTK (1.3)
related and also appears on Windows.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] How to wait for window or menu clearance?
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 graphic
Fl::check();
os_fkt::Sleep(100);
}
m_Do_Eval_Log= true;// Call offscreen drawing by timer
The previous code doesn't work, I just found out, that there are two
items: It is not only necessary to clean the dialog, it is also
necessary to leave the Fl_Menu callback before calling
offscreen-drawing. There is a timer running, an when flag m_Do_Eval_Log
was set, the timer clears it and calls offscreen-drawing. This way it
works now für Linux and Windows-XP, but my initial question remains.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] FLTK - memory leaks
I found that
Fl_Window window(340,180);
int ret = Fl::run();
delete window;
causing program to crash.
That actually *IS* a known bug in MSWindows
I think, it is more basic and regarding to local variables:
void Crash()
{
int A;
delete A;
}
This will always crash when leaving Crash(), because A will be released
twice. The only difference to example above is local scope inside of a
function and not inside of main function.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK - memory leaks
Mikhail Tchernychev schrieb: Apparently static variables in files like fl_utf8.cxx just never got freed, only re-allocated all the time. What in detail do you mean? Static variables will be allocated at start of software and freed at end of software. It is not possible to free them, that's why they are called static. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] FLTK X11 icon
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:
int main( int argc, char** argv )
{
fltk::Window window( 120, 220 );
Pixmap p, mask;
fl_open_display();
if ( XpmCreatePixmapFromData(fltk::xdisplay,
DefaultRootWindow(fltk::xdisplay),
viewer_xpm,
p,mask, NULL) == XpmSuccess )
window.icon((char*) p);
window.show();
Thanks, but the icon is still not shown under Kubuntu.
You must set icon before calling window.show().
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] MS Paint Replication
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
that just adjusts the amount of points according to the user's input
instead of limiting the number of points to 1000??? This presents
another issue where the color is changing every point, instead of the
current point the user is working on.
int color_num = FL_BLACK;
struct point { point(){ x = 0 ; y = 0; } int x; int y; };
Your point is missing any colour, isn't it?
Maybe you could get rid of both problems, by using an Fl_Image for
drawing area. You can define the size of the image (so there is no
special limit of points) and you can define number of colours by the
depth of the image. Now you can change pixel of the image and copy it to
screen, also you can save and load images. This is half way to paint
functionality! ;o)
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK X11 icon
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::Window window( 120, 220 );
window.show();
Pixmap p, mask;
fl_open_display();
if ( XpmCreatePixmapFromData(fltk::xdisplay,
DefaultRootWindow(fltk::xdisplay),
viewer_xpm,
p,mask, NULL) == XpmSuccess )
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Screenshots draw
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 read threads Another item of using fl_read_image and fl_read_image from offscreen?. I think, I met all possible problems, now it really works fine. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Popup window
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 I pressed quit button. Any Ideas? Am using fltk1.3 on ARM processor based linux embedded system. To me this seems to be straight forward - show() the popup window (should be nonmodal to cover other windows), start timer, hide() the window in timer-callback. Which part of this is in detail your problem? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Another item of using fl_read_image
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! You are right, it doesn't work for just one program, but in
general it works. And I found an easy way to realise a screenshot with
adjustable resolution and without any subclassing:
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Button.H
#include FL/fl_draw.H
#include FL/x.H
#include write_png.h
Fl_Window* pMW= 0; // Pointer to window for export
void Cb_Bn(Fl_Widget* o, void* v)
{
enum { ow= 4000, oh= 4000 };
if (Fl_Offscreen OF= fl_create_offscreen(ow, oh))
{
Fl_Widget* pW= dynamic_cast Fl_Widget* (pMW);
// Fl_Widget::draw() is public!
fl_begin_offscreen(OF);
int x0= pW-x(); int y0= pW-y();
int w0= pW-w(); int h0= pW-h();
pW-damage_resize(0, 0, ow, oh);
pW-draw(); // calls virtual Fl_Window::draw()
if (unsigned char* pImage= fl_read_image(0, 0, 0, ow, oh, 0))
{ // Get image
write_png(/home/ed/temp/test.png, pImage, ow, oh, 3);
delete[] pImage;
}
fl_end_offscreen();
fl_delete_offscreen(OF);
pW-resize(x0, y0, w0, h0);
}
}
int main()
{
Fl_Window Win(100, 100, 640, 480, Offscreen Image);
pMW= Win;
Win.resizable(pMW);
Fl_Button* pB= new Fl_Button(10, 10, 100, 100, Export Png);
pB-callback(Cb_Bn, 0);
pB-when(FL_WHEN_RELEASE);
Win.end();
Win.show();
return Fl::run();
}
This also works using pointer to groups or widgets, but for these
pointers it is necessary to use damage_resize(), not resize().
There is an interesting effekt: I went through the program, using the
debugger and after leaving the routine - after resizing back and forth
and window was exported - the program resizes back and forth on screen.
I tried to clear_damage() and to do the resize offscreen by setting
x/y to coordinates outside of screen, but it remained to be 0/0.
Okay, it's not a problem, just ugly. Now I will go on to find out, where
the initial problem comes from...
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Another item of using fl_read_image
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 easy to solve (timer), but was hard to
find...
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Button.H
#include FL/Fl_Menu_Bar.H
#include FL/fl_draw.H
#include FL/x.H
#include write_png.h
#include w_time.h
Fl_Window* pMW= 0;
void Cb_Bn(Fl_Widget* o, void* v)
{
enum { ow= 400, oh= 400 };
if (Fl_Offscreen OF= fl_create_offscreen(ow, oh))
{
fl_begin_offscreen(OF);
fl_rectf(0, 0, ow, oh, Fl_Color(w_time().Seconds()% 15));
for (int i= 10; i 100; i+= 10) fl_rect(i, i, ow -2*i, oh -2*i,
Fl_Color(i%15));
if (unsigned char* pImage= fl_read_image(0, 0, 0, ow, oh, 0))
{ // Get image
write_png(/home/ed/temp/test.png, pImage, ow, oh, 3);
delete[] pImage;
}
fl_end_offscreen();
fl_delete_offscreen(OF);
}
}
int main()
{
Fl_Window Win(100, 100, 640, 480, Offscreen Image);
pMW= Win;
Fl_Menu_Bar *pMenu= new Fl_Menu_Bar(0, 0, Win.w(), 25);
pMenu-add(Draw-Demo,0,0,0,FL_SUBMENU);
pMenu-add(Draw-Demo/Export, 0, Cb_Bn);
Fl_Button* pB= new Fl_Button(10, 100, 100, 100, Export Png);
Win.resizable(pMW);
pB-callback(Cb_Bn, 0);
pB-when(FL_WHEN_RELEASE);
Win.end();
Win.show();
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Screenshots draw
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 save
it, when you know how. :o)
First a point out how to use the draw:
#include FL/Fl_Double_Window.H
#include FL/fl_draw.H
#include FL/x.H
#include write_png.h
class Fl_Screenshot_Window: public Fl_Double_Window
{
public:
Fl_Screenshot_Window(int x, int y, int w, int h, const char*l= 0):
Fl_Double_Window(x, y, w, h, l)
{}
Fl_Screenshot_Window(int w, int h, const char*l= 0):
Fl_Double_Window(w, h, l)
{}
protected:
void draw()
{
Fl_Double_Windwo::draw();
if (unsigned char* pImage= fl_read_image(0, 0, 0, w(), h(), 0))
{
write_png(/home/ed/temp/image.png, pImage, w(), h(), 3);
delete[] pImage;
}
}
};
When you use this window-class, it will copy every draw to image.png.
Beside this code you need to include libpng.a or libflt_kpng.a.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Screenshots write_png
/*
* 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 width,
/* Image width */
int height,
/* Image height */
int depth
/* Image depth, valid values 1(mono), 3(RGB) */
);
// return zero for success, -1 for error
#endif /* WRITE_PNG_H_ */
/*
* write_png.cpp
*
*/
#include fstream
using std::fstream;
using std::ios_base;
#include stdlib.h
#include zlib.h
#include png.h
#include write_png.h
typedef unsigned char uchar;
//===
/* structure to store PNG image bytes */
typedef struct
{
uchar *buffer;
size_t size;
size_t size_allocated;
} mem_encode;
static void my_png_write_data(png_structp png_ptr, png_bytep data,
png_size_t length)
{
mem_encode* p=(mem_encode*)png_get_io_ptr(png_ptr);
size_t nsize = p-size + length;
/* allocate or grow buffer */
if(nsize p-size_allocated){
int alloc_size = nsize * 2;
if(p-buffer)
p-buffer = (uchar*)realloc(p-buffer, alloc_size);
else
p-buffer = (uchar*)malloc(alloc_size);
if(!p-buffer) {
png_error(png_ptr, Write Error);
return;
}
p-size_allocated = alloc_size;
}
/* copy new bytes to end of buffer */
memcpy(p-buffer + p-size, data, length);
p-size += length;
}
/* This is optional but included to show how png_set_write_fn() is called */
static void my_png_flush(png_structp png_ptr){}
int write_png(const char *file_name,/* Name of file to be written */
unsigned char *datap, /* pointer to
image data array */
int imgw,
/* Image width */
int imgh,
/* Image height */
int imgd
/* Image depth, valid values 1(mono), 3(RGB) */
)
{
//outlen = imgw * imgh * imgd;
png_structppp; // PNG data
png_infop info; // PNG image info
mem_encode state;
/* initialise - put this before png_write_png() call */
state.buffer = NULL;
state.size = 0;
state.size_allocated = 0;
if( !((imgd == 1) || (imgd ==3) || (imgd ==4))) return -1;
pp = png_create_write_struct(PNG_LIBPNG_VER_STRING, 0, 0, 0);
if(!pp) return -1;
info = png_create_info_struct(pp);
if (!info){
png_destroy_write_struct(pp, 0);
return -1;
}
if (setjmp(png_jmpbuf(pp))){
png_destroy_write_struct(pp, info);
return -1;
}
//png_init_io(pp, fp);
/* if my_png_flush() is not needed, change the arg to NULL */
png_set_write_fn(pp, state, my_png_write_data, my_png_flush);
png_set_compression_level(pp, Z_BEST_COMPRESSION);
png_set_IHDR(pp, info, imgw, imgh, 8,
imgd == 1 ? PNG_COLOR_TYPE_GRAY :
imgd == 3 ? PNG_COLOR_TYPE_RGB : PNG_COLOR_TYPE_RGB_ALPHA,
PNG_INTERLACE_NONE, PNG_COMPRESSION_TYPE_DEFAULT,
PNG_FILTER_TYPE_DEFAULT);
png_set_sRGB(pp, info, PNG_sRGB_INTENT_PERCEPTUAL);
png_set_sRGB_gAMA_and_cHRM(pp, info, PNG_INFO_sRGB);
png_write_info(pp, info);
int iwd = imgw * imgd;
for (int y = 0; y imgh; y++)
{
png_write_row(pp, (png_byte *)datap);
datap += iwd;
}
png_write_end(pp, info);
png_destroy_write_struct(pp, 0);
if (state.buffer state.size)
{
fstream Out(file_name, ios_base::out | ios_base::binary);
if (Out.good()) Out.write((const char*) state.buffer,
state.size);
Out.close();
}
/* cleanup */
if (state.buffer) free(state.buffer);
return 0;
}
//
// End of $Id$.
//
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Screenshots write_jpeg
#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++ Portability */
// #ifdef __cplusplus
extern C {
// #endif
/* write a JPEG file */
extern int write_jpg (const char *file_name,/* Name of file to be
written */
unsigned char *datap, /* pointer to
image data array */
int width,/*
Image width */
int height, /*
Image height */
int depth,/*
Image depth, valid values 1(mono), 3(RGB) */
char *keyword,/*
Keyword to use in COM chunk (may be NULL) */
char *description); /* String to
use in COM chunk (may be NULL) */
// return zero for success, -1 for error
/* NOTE: As a special case, setting quality to 0 just uses the default
settings */
extern void set_jpg_quality (int quality); /* Set image quality param (0
- 100) */
extern int get_jpg_quality (void); /* Read current quality setting */
/* Allow C++ Portability */
// #ifdef __cplusplus
}
// #endif
#endif /* HAVE_WRITE_JPEG_H */
#include cstring
using std::strlen;
#include cstdlib
using std::malloc;
using std::free;
#include cstdio
using std::fopen;
extern C {
#ifdef WIN32
#include jpeg/jpeglib.h
#else
#include jpeglib.h
#endif
}
#include write_jpg.h
/* Holds Global quality setting - accessed only by the accessor methods
provided */
static int quality = 0; /* Image quality param (0 - 100) (0 uses lib
defaults) */
/***/
void set_jpg_quality (int iv)
{
if (iv 0) iv = 0;
else if (iv 100) iv = 100;
quality = iv;
}
//
int get_jpg_quality (void)
{
return quality;
}
//
int write_jpg (const char *file_name, // Name of file to be written
unsigned char *datap, // pointer to
image data array
int width,//
Image width
int height, //
Image height
int depth,//
Image depth,valid values 1(mono), 3(RGB)
char *keyword,//
Keyword to use in COM chunk (may be NULL)
char *description)// String to
use in COM chunk (may be NULL)
{
struct jpeg_compress_struct cinfo;
struct jpeg_error_mgr jerr;
FILE *outfile; /* target file */
JSAMPROW row_pointer[1];/* pointer to JSAMPLE row[s] */
introw_stride; /* physical row width in image
buffer */
char *com_block_txt; /* Used to hold any COM block we write
out */
/* Only handle RGB or Greyscale images for now */
if ((depth != 3) (depth != 1))
{
return WRITE_DATA_ERROR;
}
com_block_txt = NULL;
/* Setup jpeg error handling */
cinfo.err = jpeg_std_error (jerr);
/* Now we can initialise the JPEG compression object. */
jpeg_create_compress (cinfo);
/* Open the output file */
if ((outfile = fopen (file_name, wb)) == NULL)
{
//fprintf (stderr, can't open %s\n, file_name);
return WRITE_DATA_ERROR;
}
jpeg_stdio_dest (cinfo, outfile);
/* Setup compression parameters */
cinfo.image_width = width; /* image width and height, in
pixels */
cinfo.image_height = height;
cinfo.input_components = depth; /* number of bytes per pixel */
if (depth == 3)
{
cinfo.in_color_space = JCS_RGB; /* RGB input image */
}
else
{
cinfo.in_color_space = JCS_GRAYSCALE; /* Greyscale input image
*/
}
/* Now use the library routine to set default compression parameters. */
jpeg_set_defaults (cinfo);
j_compress_ptr pI= cinfo;
/* Do we want to override the default compression quality? */
if (quality 10) jpeg_set_quality(pI, quality, TRUE);
/* Start compressor */
jpeg_start_compress (pI, 1);
/* Now we have started the compressor, do we have a
Re: [fltk.general] Does fltk work for C, as well as c++?
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
Re: [fltk.general] PNG file corrupted by ASCII conversion
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 *nix versions ignore the b anyway... I like to put the #ifdef in there just so that, someday, the code could read: // OBSOLETE //Microsoft was purchased by Apple, and replaced with Unix. - 02/24/2016 I don't think, Steve Jobs will come back to save Apple a third time. Anyway Windows 8 will be an operating system for mobile phones (that's funny, we will need to boot and shutdown our phones :o), so Unix/Linux will be the last remaining PC operating system (Matthew 20:16 So the last will be first, and the first will be last. :o) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2834: Make Fl_Help_Viewdraw()andhandle()public
Matthias Melcher schrieb: For composite widgets, I would like to propose something else though. It should be possible to derive a new widget from any other widget, based on the data that widget provides, not on the UI. For example, InputChoice is derived from Group. That is silly, because Group does not normally handle text. It should rather be derived from Input, right? But currently only a Group can have children. So what I would like to do is keep the children in Group (no need to move them to Widget - that would be a waste), but add something to Widgets that I call Nephew for lack of a better word. Is it necessary, that a group is a widget? What do you think of this: class Fl_Group: public Fl_Widget, public Fl_Basic_Group class Fl_Composed_Widget: public Fl_Input, public Fl_Basic_Group The approach is not to derive, but to assemble. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.general] PNG file corrupted by ASCII conversion
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 difference regards the libraries for #include zlib.h and #include png.h. For Linux it uses the libraries from system and includes libpng.a and libz.a. For MS-Windows it uses the header files from fltk/png and fltk/zlib and it includes libfltk_png.a and libfltk_zlib.a. Where could the problem come from? Maybe related to utf8? How to go on? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] PNG file corrupted by ASCII conversion
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? On Windows you must open a file explicitly as text or binary - one of them is the default, but who knows ? ;-) Hmpf - the default is text and I know this, but forgot to take care about. Very stupid, of course it works now... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] PNG file corrupted by ASCII conversion
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 doesn't seem to work for me. I'm writing scientific software for 1,5 years now and all the files had been textfiles. So normally the same code works for Linux and MS-Windows, but if using b option, the line end is wrong for MS-Windows (just tried it). Anyway it's my job to take care of such details and I should have seen it for myself. :o/ ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_read_image from offscreen?
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 begin the offscreen just before you call fl_read_image() and end it once the read is complete. fl read image() Reads an RGB(A) image from the current window or off-screen buffer. The or off-screen buffer part of the documentation should mention the required sequence and possible environment. I didn't find any hint and I went the docs up and down to find what's wrong. You can do that pretty much anywhere, not just in a draw method, and that's one of the advantages of using the offscreen approach... Yes, it works like a charm now, without dependency on screen. But it seems to me, it works better outside of draw(), than inside. First I started with exporting from draw(), but this doesn't work reliable, sometimes the draw appears, more often the picture stayed black. But this is no problem, because to me it's a lot more comfortable, to work outside of draw() method. Really nice. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] fl_read_image from offscreen?
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 FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Input.H
#include FL/fl_draw.H
#include FL/x.H
#include iostream
using std::cout;
using std::endl;
class Fl_Test_Window: public Fl_Window
{
public:
Fl_Test_Window(int w, int h, const char* l= 0):
Fl_Window(w, h, l)
{
new Fl_Input(100, 100, 100, 25, Input);
end();
resizable(this);
}
protected:
void draw()
{
Fl_Window::draw(); // draws window on screen
fl_rect(100, 100, 100, 100, FL_BLACK);
Fl_Offscreen OF= fl_create_offscreen(1000, 1000);
fl_begin_offscreen(OF);
Fl_Window::draw(); // draws window off screen
fl_end_offscreen();
if (unsigned char* pImage= fl_read_image(0, 0, 0, 1000, 1000, 0))
{ // pImage stays NULL
cout Got Image! endl;
delete[] pImage;
}
else cout No Image! endl;
fl_delete_offscreen(OF);
}
};
int main()
{
Fl_Test_Window Win(640, 480, Offscreen Image);
Win.show();
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_read_image from offscreen?
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 fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_read_image from offscreen?
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 it... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_read_image from offscreen?
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 window, otherwise it is out of drawing area. Ah yes. The default coordinates are a magic value that tells the WM to position the window when it is mapped. Until then, the window is at some outlandish position. Oh no, it doesn't depend on coordinates, it depends on screen! I just figured out, that on my left screen I get the whole window, but when moving the test window to the right screen, the offscreen drawing starts to get cut and when totally on right screen (my main screen) it vanishs. Offscreen drawing was first step to save a jpeg screenshot and now I can see, how it changes. It's the same, when using Fl_Window(x, y, w, h). 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 ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_read_image from offscreen?
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 for the first time. I wonder if this is related to
the FLTK screen_xywh() function calls, or if this is some feature of
the underlying OS. If you have a few minutes, could you try to set a
breakpoint in the screen_xywh functions and the retrieve the snapshop
again?
It's not so easy, does it work for you, to test the functions? I called
them inside of fl_offscreen and all looks okay. This is my example code,
followed by output:
virtual void draw()
{
Fl_Window::draw(); // draws window on screen
cout count Fl::screen_count() endl;
int sx, sy, sw, sh;
Fl::screen_xywh(sx, sy, sw, sh);
cout onscreen sx ' ' sy ' ' sw ' ' sh endl;
Fl_Offscreen OF= fl_create_offscreen(1000, 1000);
fl_begin_offscreen(OF);
Fl_Window::draw(); // draws window off screen
Fl::screen_xywh(sx, sy, sw, sh);
cout offscreen sx ' ' sy ' ' sw ' ' sh endl;
Fl::screen_xywh(sx, sy, sw, sh, x(), y());
cout position sx ' ' sy ' ' sw ' ' sh endl;
Fl::screen_xywh(sx, sy, sw, sh, x(), y(), w(), h());
cout rectangle sx ' ' sy ' ' sw ' ' sh endl;
Fl::screen_xywh(sx, sy, sw, sh);
cout onscreen sx ' ' sy ' ' sw ' ' sh endl;
Fl::screen_xywh(sx, sy, sw, sh, 0);
cout screen 0 sx ' ' sy ' ' sw ' ' sh endl;
Fl::screen_xywh(sx, sy, sw, sh, 1);
cout screen 1 sx ' ' sy ' ' sw ' ' sh endl;
cout x() ' ' y() endl;
fl_end_offscreen();
:
count 2
onscreen 1920 0 1920 1080
offscreen 1920 0 1920 1080
position 1920 0 1920 1080
rectangle 1920 0 1920 1080
onscreen 1920 0 1920 1080
screen 0 0 0 1920 1080
screen 1 1920 0 1920 1080
2322 197
No Image!
Two screens are right and there is no difference from on-screen to
off-screen. Also the within functions are okay - all functions
recognise, that window is on second screen. So when there is an error
related to screen_xywh() it might be an error of not regarding the
x-offset when calculating the whole screen area (or clipping something).
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_read_image from offscreen?
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::draw(); // draws window off screen fl_end_offscreen(); This creates a 1000x1000 pixel offscreen image and draws the window contents into this image. However, your window has its own x/y coordinates (based on its position on your workstation), and hence all drawings are translated by these x/y coordinates. If your window happens to be more than 1000 pixels shifted to the right or bottom, nothing will be drawn /inside/ your offscreen image. That would mean, when moving the window, it should change it's position on screenshot, shouldn't it? But it doesn't, it was always drawn starting at (0,0) and when window is leaving first screen, then parts on second screen are cut off. Anyway I just found out, that there is no offscreen drawing at all - the fl_read_image() always catches the whole window, not the part written inside of offscreen. When there is a part of the window covered by another window, this will be black in the screenshot. And it is not a Linux problem, because this test was made using MS-Windows. 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. Unfortunately I don't understand what you're testing in your demo program (how can you see whether you got a _valid_ image?), so I can't it test myself... I'm testing, whether fl_read_image() returns a valid pointer, Got Image! when a pointer was returned, No Image! when pointer is zero. Okay, finally there is a funktion, that saves pointer as jpeg-image, but this part works: When there is an image, it will be saved and can be loaded and viewed. But the problem is, that often fl_read_image() doesn't deliver a pointer. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] Package 1.1.9 in community devpaks has problem
STF schrieb: In Dev-C++ and wxDev-C++, I open their package manager to get a list of devpaks from community devpaks site. When I tried to install version 1.1.9, I got the error message that The following files were not downloaded due to errors: Could not start transferring remote file. Go on without it. You should use FLTK 1.3. Download it. Read Readme and make the fltk library. Then tell your project, where fltk libraries and headers are located. Have fun. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Gereral issue of zoom and change of font and fontsize for FLTK
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... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Gereral issue of zoom and change of font and fontsize for FLTK
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 need to be convinced of it. So to me the best way to proceed seems to be, that I realise my detailed concept and come back, when it works for all examples. Then you can decide about too big a change. But before that, there is a basic question - do you in general think, it should be implemented? You told me, that would break your own system of realising that. Mine too, but to me it is not a problem to delete something and replace it by built in solution. The point is, that the changes should be compatible to existing solutions. Does being convinced just depend on code, or are you not convinced at all, that the effort makes sense? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Gereral issue of zoom and change of font and fontsize for FLTK
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 all widgets are (and should be) resized in the same way. Do we use the same terms? I want to make some definitions: zoom - resizing of a window, when all content of the window follows the resizing. Similar to looking through a magnifying lens or changing the resolution of the whole monitor, but higher resolution is kept for e.g. for graphics. scaling - changing the size of all fonts, not necessarily as a result of resizing, but for better match of font type and font size (I used this term in another way). Maybe scaling can be used also for changing the font type? This also might cause user to change ratio of window. What I wanted to say is that you can have some widgets that do resize, and others that don't. The former would auto-resize their fonts, the latter wouldn't. So, in the example where you want to /zoom/, you'd have some widgets that still have smaller fonts. Yes, this is the point, where my assigning a format started. It is not always wanted, that the whole window zooms e.g. a list should keep a smaller font. To manage this, it must be possible to assign a format definition to the list. I see your point, but it's a general problem of resizing and depends on the specific application. So you are right - there are cases, such a feature doesn't work without adjustment to current application, but I don't see the problem, because all must be optional. Anyway, I hope now it is plain to see, where the problems are, how to solve them and what it would achieve - rescaling of fonts on the fly, changing fontsize on the fly. But only in a relative way, as widgets resize... No, by setting h0 different to real starting height, you can scale the fonts without resizing anything. (2) The pointer version looks like the Style approach we had in FLTK 2 and that *is* already in FLTK 3 [1], so this would be the way to go anyway. Probably. I think none of them is ready for productive use? Regarding to FLTK 3 I wasn't sure - I also used FLTK 1.3 before it was released. This question is rhetorical, isn't it? The real problem is, that I neither know FLTK 2, nor FLTK 3. Is there a brief overview about Style approach possible, or should I look to the code? Are textsize and textfont members of style right now? However, since the next step forward should be to FLTK 3, we should probably not add new API's (methods) to FLTK 1.3 that become obsolete if (when) we use the Style approach in the next version. It realises scaling and zoom? What does next mean in real time? but I wanted to point out the problems that need to be solved I think, I know them and my FLTK patch was not meant as *solution*, but as proof of concept and check for general problems - I needed it to enlighten the way. I also believe that such auto-resizing of fonts could be added to FLTK - the question is, however, which way? Will there be FLTK 1.4, or will we move to FLTK 3 with styles and such soon??? What does soon mean in real time? Is FLTK 3 the reason, why I'm missing Matthias? ...very nice, just met your developer warning, when downloading FLTK 3! :o) It works, but it doesn't zoom. Are there serious problems? Looks good! Do you want to tell me to use FLTK 3 for detailed proof of concept? [1] http://www.fltk.org/cmp.php Oh yes, very interesting! Since FLTK is targeted at platforms which often lack complete ISO C++ support or have limited memory, all C++ code in FLTK must use a subset of ISO C++. What's about today, are these restrictions state of the art? Exceptions Namespaces Standard C++ headers and library Templates static_cast, dynamic_cast, const_cast 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+. We'd need one or the other to add ABI-breaking changes FLTK_3.unrestricted.playground? I really don't like char*. ;o) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Gereral issue of zoom and change of font and fontsize for FLTK
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 the line between 'ancient' compilers, and semi-modern ones. I really would acclaim to that. Arguably, a C++ compiler that doesn't support templates isn't a C++ compiler, so why should we continue to limit FLTK's development. Yes, that's it! These things are not exotic extensions, but integral parts of the programming language and they are very useful. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Gereral issue of zoom and change of font and fontsize for FLTK
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 to save h0.
As you can see above, even if I'd set h0 to 0, then your modified
textsize() method (above) would always return l0 (the initial size)
and not the font size that has been set later. Maybe this could be
fixed by setting l0 (or some other variables) in labelsize(int),
but there can be lots of different problems. One example is that I
use different labelsize() and textsize() values for some widgets.
Sorry, I mixed up minimum example code and final solution. I want to
restart by explaining, how it should work and then, why it doesn't work
and what changes would be needed:
Fl_Fontsize labelsize() const
{ return h0 ? (label_.size * h())/h0 : label_.size; }
void labelsize(Fl_Fontsize s)
{ h0 ? label_.size= (s * h0)/h() : label_.size= s; }
This is almost original code, just the h0-thing was added.
When h0 is equal to zero, just original code works, when it real
starting height of the window, it will cause labelsize() to follow hight
of the window (better would be to respect ratio, but it doesn't really
matter).
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.
Another problem: we can have resizable widgets and non-resizable widgets
in windows/groups
This is no problem, because scaling of fonts depends on current widgets
size, so there is no scaling, when there is no resizing. And also if you
change local fontsizes they will keep their ratio to current window resize.
If we changed the font sizes by resizing in general,
then non-resizable widgets would keep their font sizes, and this would
lead to different font sizes in one window. This could be annoying.
This is the h0= 0 case - must be deactivated, if unwanted. Okay,
better solution would be - must be activated, if wanted. ;o)
(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 ... see (2).
What's about a private pointer? Or a private pointer inside of Fl_Label?
It could keep e.g. h0, so there is no other change to data of Fl_Widget.
But there are other problems, now the changes would be needed part:
The Widget provides method labelsize(), but the label doesn't use it
itself. Method is:
Fl_Fontsize labelsize() const { return label_.size; }
Method should be:
Fl_Fontsize labelsize() const { return label_.size(); }
And the h0 thing inside of label_.size().
This would break code, but I also think, this would improve code.
The next problem is textsize, because the textattributes are not methods
of Fl_Widget.
E.g. Fl_Input implements
Fl_Font textfont_;
Fl_Fontsize textsize_;
And provides methods:
Fl_Fontsize textsize() const {return textsize_;}
void textsize(Fl_Fontsize s) {textsize_ = s;}
This is reimplemented e.g. for Fl_Browser_.
I think, the textsizes should either be moved to Fl_Widget, or use
something like
Fl_Fontsize textsize() const { return label_.textsize(); }
I don't think, this would external break code, but would affekt several
FLTK classes.
Anyway, I hope now it is plain to see, where the problems are, how to
solve them and what it would achieve - rescaling of fonts on the fly,
changing fontsize on the fly.
(2) The pointer version looks like the Style approach we had in
FLTK 2 and that *is* already in FLTK 3 [1], so this would be the way to
go anyway. Probably.
I think none of them is ready for productive use?
(3) Templates - we don't use templates in FLTK, and I don't think
that we will in the near future.
I use templates and they are a perfect way to attach subsystems to
existing classes. Also very easy to use.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Gereral issue of zoom and change of font and fontsize for FLTK
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 ... see (2).
The label (struct Fl_Label) is part of Fl_Widget, hence the ABI would
change anyway.
Fl_Fontsize labelsize() const { return label_.size(); }
I don't think that this would break code (i.e. change any API or
semantics), since the Fl_Label struct is private in Fl_Widget
Fl_Fontsize textsize() const { return label_.textsize(); }
The former. The latter would mean that you can't have different text
and label sizes, which would definitely be wrong.
No, the latter means, that there are is additional Fl_Fontsize
textsize_; inside of Fl_Label. The new data were not added to
Fl_Widget, but to Fl_Label.
Probably okay for the API, but not for the ABI. We'd need to add new
members (at least one) to Fl_Widget. Adding the textsize() method to
Fl_Widget wouldn't harm, though.
I think it's possible to push all changes into Fl_Label, so there are no
changes of API. But would this break ABI? That would mean, there is no
possibility remaining to realise it without breaking ABI.
This is first answer, but comments to the rest of your posting would
depend on this ABI question.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Gereral issue of zoom and change of font and fontsize for FLTK
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 is a basic problem - when resizing back and forth, the sizes start
to drift, when they are replaced by new resized values. It is necessary
to keep the original values and calculate the current value out of
current ratio of widget sizes:
Sn= (S0 * hn)/ h0
Because of integer division it is important to use brackets!
So at first glance it seems to be necessary to add new data. But there
is a way to avoid this, when pushing calculation of current size to
query of current size:
Fl_Fontsize Fl_Widget::textsize() const
{ return h0 ? (l0 * h())/h0 : l0; }
Now it is only necessary to remember initial height. h0 can be used to
switch off zoom or to change current factor.
But another problem remained - Fl_Label is an own object, that doesn't
use method Fl_Widget::labelsize(), so it still remains necessary to
remember l0 and update the Fl_Label::labelsize_ when resizing.
Also the derived classes don't use textsize of Fl_Widget and if adding
textsize_ to Fl_Widget, it is necessary to patch all classes using
textsize_.
So it is necessary, to use the existing methods the way they are and to
update the existing values when resizing.
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);). This is very basic (e.g. doesn't take care of ratio),
but it is also very easy to realise.
But this is to start discussion and was not my final goal. I wanted to
use format objects every widget is pointing to. This might make FLTK
lighter, because it would get rid of every widgets formats - normally
all widgets inside of a group use the same format, so they all could use
the same format object. The trick is, when you change the format, all
related widgets will change too at once and wherever they are.
I was going to realise this, using a template, but should I figure out,
how to change FLTK this way? This might be more useful, than creating my
own single solution.
--- ./fltk-1.3_Original/FL/Fl_Widget.H 2011-04-24 19:09:41.0 +0200
+++ ./fltk-1.3/FL/Fl_Widget.H 2012-04-14 12:39:30.70440 +0200
@@ -113,6 +113,7 @@
Fl_Callback* callback_;
void* user_data_;
int x_,y_,w_,h_;
+ int h0, l0, t0; // Initial heigth, initial labelsize, initial
textsize
Fl_Label label_;
unsigned int flags_;
Fl_Color color_;
@@ -130,7 +131,6 @@
Fl_Widget operator=(const Fl_Widget );
protected:
-
/** Creates a widget at the given position and size.
The Fl_Widget is a protected constructor, but all derived widgets have a
@@ -503,6 +503,17 @@
*/
void labelsize(Fl_Fontsize pix) {label_.size=pix;}
+ /** virtual text methods to access methods of derived widgets
+ *
+ */
+ virtual Fl_Font textfont() const {return label_.font;}
+ virtual void textfont(Fl_Font f) {label_.font=f;}
+ virtual Fl_Fontsize textsize() const { return label_.size; }
+ virtual void textsize(Fl_Fontsize pix) {label_.size=pix;}
+
+ void H0(int val) { h0= val; }
+ int H0() const { return h0; }
+
/** Gets the image that is used as part of the widget label.
This image is used when drawing the widget in the active state.
\return the current image
--- ./fltk-1.3_Original/src/Fl_Widget.cxx 2010-12-02 18:58:58.0
+0100
+++ ./fltk-1.3/src/Fl_Widget.cxx2012-04-14 12:41:59.516501000 +0200
@@ -132,12 +132,16 @@
color_= FL_GRAY;
color2_ = FL_GRAY;
when_ = FL_WHEN_RELEASE;
-
+ h0= H;
+ l0= FL_NORMAL_SIZE;
+ t0= FL_NORMAL_SIZE;
parent_ = 0;
if (Fl_Group::current()) Fl_Group::current()-add(this);
}
void Fl_Widget::resize(int X, int Y, int W, int H) {
+ labelsize(h0 ? (l0 * h())/h0 : l0);
+ textsize(h0 ? (t0 * h())/ h0 : t0);
x_ = X; y_ = Y; w_ = W; h_ = H;
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Gereral issue of zoom and change of font and fontsize for FLTK
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/src/Fl_Widget.cxx 2010-12-02 18:58:58.0
+0100
+++ ./fltk-1.3/src/Fl_Widget.cxx2012-04-14 12:41:59.516501000 +0200
@@ -132,12 +132,16 @@
color_= FL_GRAY;
color2_ = FL_GRAY;
when_ = FL_WHEN_RELEASE;
-
+ h0= H;
+ l0= FL_NORMAL_SIZE;
+ t0= FL_NORMAL_SIZE;
parent_ = 0;
if (Fl_Group::current()) Fl_Group::current()-add(this);
}
void Fl_Widget::resize(int X, int Y, int W, int H) {
+ labelsize(h0 ? (l0 * H)/h0 : l0);
+ textsize(h0 ? (t0 * H)/ h0 : t0);
x_ = X; y_ = Y; w_ = W; h_ = H;
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Gereral issue of zoom and change of font and fontsize for FLTK
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 H, not current h(). Fixed patch appended. Harhar - I just went through the examples... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Gereral issue of zoom and change of font and fontsize for FLTK
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, it would be
necessary to move textsize_ to Fl_Widget and to make Fl_Label use the
labelsize() method. After that all methods can be changed like that:
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 to save h0.
My original approach works better, because the template comes top down
and overwrites methods, but the Fl_Widget is at bottom and existing code
overwrites changes.
Okay, I think that shows the basic requirements. Should I finish the
basic system, adding data to Fl_Widget, should I try my pointer version,
or go on with templates - what do you think?
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Gereral issue of zoom and change of font and fontsize for FLTK
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 need to see a working example to believe this. My propose is to have something like this. Maybe I should mention, that I don't talk about ideas or things that might work, but I started with a ready made framework, which handles scaling (resizing not only window, but also fonts), choice of fonts type and basic size, saving and restoring window position and size and a whole subsytem, which provides a comfortable method of live translation and general administration of strings inside a software. I'm experienced in this, now it works since 2003. I wanted to simplify it, make it more reusable and publish it, but anyway monday the next application using it, will be delivered. But the most reusable solution would be an integration to FLTK. I also want to tell, that there is a lot of details, I didn't mention yet, but anyway I would prefer to mention them by code. So what do experienced FLTK developers think of the ways to solve this. When resizing a window with mouse or keyboard if CTRL (or SHIFT or both) is pressed then the operation to perform is SCALE otherwise the normal RESIZE. That's okay, but the user interface is a final step, not the basic problem. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLUID fonts
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 also could wait until tomorrow, when my new template is published. It's defined like template T f_basic_font_size: public T and it should be used like: 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(); When resizing this window the label- and textsizes follow the size of the window - looks really great (my boss was very fond of that ;o). It works using a pointer to a dt_format class and I'm just figuring out, how to set groups with own fonts and fontsizes. The template also works using Fl_Widget and derived, so every part of a FLTK window can be enlarged with format informations. Also this is a good base to load and save window position and size. It's work in progress, but not far from finish. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLUID fonts
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 want to apply the template directly:
typedef f_font_size::f_basic_font_size Fl_Double_Window
Fl_Double_Resize_Window;
This is current state and I think it is almost finished. There are some
additional classes missing, like a FL_Font_Dialog() for changing fonts
and I want to figure out some additional details, but for the OP this
should work:
//
// Projekt Code by Ed
//
// i_fonts_dialog.h
// - Interface f�r Fl_Fonts_Dialog
//
// Copyright � 2003 by Edzard Egberts
//
// This library is free software; you can redistribute it and/or
// modify it under the terms of the GNU Library General Public
// License as published by the Free Software Foundation; either
// version 2 of the License, or (at your option) any later version.
// Static linking of this library (or any modified version) to your software
// is explicitly allowed.
//
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// Library General Public License for more details.
//
// You should have received a copy of the GNU Library General Public
// License along with this library; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
// USA.
//
#ifndef i_fonts_dialog_h
#define i_fonts_dialog_h
#include iosfwd
#include string
#include FL/Enumerations.H
#include FL/Fl_Widget.H
class Fl_Window;
class Fl_Group;
/*
Overview:
The following interfaces are ment to adjust labelfont/textfont and
labelsize/textsize of FLTK dialogs.
For realising these adjustments there is a dialog Fl_Fonts_Dialog,
which uses interface
i_fonts_dialog to access the dialog to be changed.
When adjusting for each widget the fonts and sizes must be set. Because
these methods
are only for sure defined for labels and not for texts there is an
interface i_font_size. You
can use it to add adjustment interface to self defined widgets.
Because the adjustment should not only affekt the main window, but also
subwindows and
other windows without adjusting each of them, there is an interface
f_basic_font_size
for transfer of current settings. It will be queried by interface
i_local_font_size,
which takes over the settings to another dialog. The dialog must be
inherited by the
i_local_font_size, or must be given to an i_local_font_size and a
pointer to
f_basic_font_size must be delivered to it. After that it takes over the
settings,
when Update_Font_Size() is called.
In speciality the windows size must be cared of. When a window was
resized and also get
taller textsizes, also the subwindow must be resized, because otherwise
the taller texts
won't fit into the small window. Because of that the textsize refers to
original window size.
*/
namespace f_font_size
{
//
// General Functions for Widgets
//
// cast to text
int Get_Text_Size(Fl_Widget* pWdg);
bool Set_Text_Size(Fl_Widget* pWdg, int TS);
void Set_Text_Font(Fl_Widget* pWdg, Fl_Font Txt_Font);
Fl_Font Get_Text_Font(Fl_Widget* pWdg);
// Resize and fonts of all pWdg and all widgets inside
void Resize_Fonts(Fl_Widget* pWdg, int Labelsize, int Textsize);
void Set_Fonts(Fl_Widget* pWdg, Fl_Font Lbl_Font, Fl_Font Txt_Font);
// Operate all existing windows:
void Resize_Fonts(int Labelsize, int Textsize);
void Set_Fonts(Fl_Font Lbl_Font, Fl_Font Txt_Font);
//
class dt_font_size
{ // font size data
public:
dt_font_size(Fl_Font Lbl_Font= FL_HELVETICA, Fl_Font
Txt_Font= FL_HELVETICA, int Lbl_Size= 14, int Txt_Size= 14):
m_Lbl_Font(Lbl_Font), m_Txt_Font(Txt_Font),
m_Lbl_Size(Lbl_Size), m_Txt_Size(Txt_Size)
{}
inline Fl_Font Lbl_Font() const
{ return m_Lbl_Font; }
inline Fl_Font Txt_Font() const
{ return m_Txt_Font; }
inline int Lbl_Size() const
{ return m_Lbl_Size
Re: [fltk.general] FLUID fonts
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!
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Box.H
#include f_font_size.h
using namespace f_font_size;
int main()
{
dt_font_size FS;// Format
f_basic_font_size Fl_Window Window(400, 200);
Window.resizable(Window);
Window.pFormat(FS);// Format activates resize!
new Fl_Box(100, 100, 100, 25, Hello World);
Window.end();
Window.show();
return Fl::run();
}
Tomorrow I will start my own thread. ;o)
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Redrawing overlapping wigets
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 to get them redrawn without having myself to keep a list of widgets whose coordinates intersect with the widget being drawn? That already works for list of children() the front widget must be sorted to be drawn as last. But the trick is, not to redraw the single widget, but parent() group or window, to keep track of order. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Redrawing overlapping wigets
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
Re: [fltk.general] FLUID fonts
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.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLUID fonts
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 think it will also work for FLTK 1.3. Yes, it works, but for the moment there is a bug remaining and I think, I will do some more work on it. But now there is a documentation, which makes it easy to use the code. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLUID fonts
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/mailman/listinfo/fltk
Re: [fltk.general] FLUID fonts
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 example, but when there are problems, please tell me. Anyway I want to use it for 1.3 myself. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] [FLTK 1.3] How to save image from offscreen?
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; // pointer to image data array and which I created before, to save images from Fl_RGB_Image. Seems to be easy to use this for my screenshot, but what in detail is Fl_Offscreen? ./FL/mac.H:39:typedef void* Fl_Offscreen; // this is really a CGContextRef ./FL/mac.H:116: Fl_Offscreen other_xid; // pointer for offscreen bitmaps (overlay window) ./FL/win32.H:134:typedef HBITMAP Fl_Offscreen; ./FL/x.H:95:typedef ulong Fl_Offscreen; This sample code crashes on write_jpg(): Fl_Offscreen OF= fl_create_offscreen(1000, 1000); fl_begin_offscreen(OF); draw_plot(); fl_end_offscreen(); unsigned char* pImage= (unsigned char*) OF; write_jpg(/home/ed/temp/test.jpg, pImage, 1000, 1000, 3, 0, 0); fl_delete_offscreen(OF); I'm sure pImage is wrong, but how can I change Fl_Offscreen to plain RGB pointer (for Linux Windows)? Or is there somewhere existing code to achieve this? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] How to save image from offscreen?
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: http://www.fltk.org/articles.php?L468 Is this the right link - Display Arbitrary Data as an Image? I don't understand, what this should tell me, because my problem is to get the Fl_Offscreen image array and I didn't found Fl_Offscreen mentioned at all: ./FL/win32.H:134:typedef HBITMAP Fl_Offscreen; ./FL/x.H:95:typedef ulong Fl_Offscreen; There is a HBITMAP and ulong, how can I use this to get the image array? It's the part just read back and repack. ;o) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] How to save image from offscreen?
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 fl_draw.H functions for plotting and scaling some measured data. The resulting graph (curve, chart - I'm not in detail sure of the differences) should be inserted to a document. So I want to repeat the plot to offscreen data area for higher resolution and then save it as image (jpeg, png). If you do go the offscreen route, the solution is to make the offscreen current then use fl_read_image(...); to get the raw data. There is no image, until now the software used only libfltk. For creation of my plot-image I need to include libjpeg/libpng. That, more or less, is what I meant with the link to the howto - you can use the fltk mechanisms to get the data in the same fltk format regardless of platform, you don't need to grok the underlying implementation. Which fltk format can I use to get fl_offscreen data? By function I only found a copy to screen. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] How to save image from offscreen?
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 understand - I was sure, read_image reads to buffer, not from buffer. %) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] double-click vs. click example
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 as a two stage process - first click selects (use this!) second click enters (proceed this!). ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] hide and show problem
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 - sometimes it is necessary to redraw the background, this can be a problem, when objects are grouped in a frame. Changing the frame-style of group to box-style often solves the problem. Anyway you can put the messy part of the screen inside of a group using a boxstyle (e.g. flat box) and redrawing the group the get rid of artefacts. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Printing images with resolution higher than screen resolution?
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 ?
Think, I posted it before, but this is the way I used, to map output
from screen resolution to printed sheet resolution. This is for
printing a data sheet with a graph, all realised with fl_draw-functions
(so no widgets are drawn). This works fine for me.
Fl_Printer * p = new Fl_Printer();
int ww= pWindow-w();
int wh= pWindow-h();
int pw, ph;
if (!p-start_job(1))
{
p-start_page();
if (!p-printable_rect(pw, ph))
{
int left, top, right, bottom;
p-margins (left, top, right, bottom);
pw-= 2* left;
ph-= 2* top;
left*= 2;
top*= 2;
float sw= float(pw)/float(ww);
float sh= float(ph)/float(wh);
if (sw sh)sw= sh;
p-scale(sw);
p-print_widget(pWindow, left, top);
}
p-end_page();
p-end_job();
}
delete p;
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Scroll bar in Choice box
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 sense. I don't think so, to me the use of mouse and use of touch (monitor mouse) is not so different. Fingers are more clumsy than a mouse and need bigger areas to touch, but I think, this is the main difference. When they are big enough, it is no problem to open menus/drop down boxes and to choose entries. And a little patch of dragging - not to open the entry, where dragging stops - even would make it possible to use long choices. This would be the same effect like wiping on a smartphone. Okay, buttons are the most easy interface for touch, but I don't think, the other widgets will be outdated... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] jpeg image data from blob
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 your
code (#include logo.xpm). When you take a look to the xpm by text
editor, it must start like static const char * pIcon_Xpm[] = {. If
there is only char * you should change ist to static const char*
because you will get rid of warnings. After including it, you can
display it using Fl_Pixmap* mp_Pic= new Fl_Pixmap(pIcon_Xpm); and
overwriting the draw() method:
void draw()
{
if (mp_Pic)
{
Fl_Image* Scale= mp_Pic-copy(w(), h());
Scale-draw(x(), y(), w(), h());
delete Scale;
}
else Fl_Box::draw();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_offscreen drawing and widget offsets
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 for me... 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? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_offscreen drawing and widget offsets
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 the behaviour (as of right now, anyway) with fltk-1.1 and fltk-1.3 seems to be the same. Maybe... I took a look to Migrating Code from FLTK 1.1 to 1.3 and you are right, no such difference mentioned. I remember there sometimes was a problem of coordinates, but I'm to old for the details, might have been a private problem. ;o) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Clickable URLs in text
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 Fl_Text_Display is a bit of a cpu hog. Any ideas are very welcome. Maybe you should start realising it? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] XRequest.137: BadWindow
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 trouble related to twinview, from 13 to 16. Sometimes display crashed completely, sometimes views overlap, and so on. Now I switched to CentOS, but I also must state, that CentOS 6.2 is the first version, that uses twinview correctly. So when there are some twinview problems, I never would think they are caused by a fltk software. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] XRequest.137: BadWindow
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
Re: [fltk.general] getting parent class
Greg Ercolano schrieb:
void ShowWidgets_CB(Fl_Widget *w, void*) {
Fl_Window *win = w-window(); // get button's parent window
for ( int i=0; iwin-children(); i++ ) { // walk all window's children
const char *classname = ?;
Fl_Widget *w = win-child(i);
// Determine the class name of each widget
if ( dynamic_cast Fl_Button*(w) ) { classname = Fl_Button;
}
else if ( dynamic_cast Fl_Box*(w) ) { classname = Fl_Box; }
else if ( dynamic_cast Fl_Input*(w) ) { classname = Fl_Input; }
else if ( dynamic_cast MyClass*(w) ) { classname = MyClass; }
printf(child #%d: %s\n, i, classname);
}
}
You forgot, that programmers *love* recursions!
void Recur(Fl_Group *pG)
{
for ( int i=0; ipG-children(); i++ )
{ // walk all groups children
const char *classname = ?;
Fl_Widget *w = win-child(i);
if (Fl_Group* pR= dynamic_cast Fl_Group* (w)) Recur(pR);
// Yes, that's it! :O)
else
{
// Determine the class name of each widget
if ( dynamic_cast Fl_Button*(w) ) { classname =
Fl_Button; }
else if ( dynamic_cast Fl_Box*(w) ) { classname = Fl_Box; }
else if ( dynamic_cast Fl_Input*(w) ) { classname =
Fl_Input; }
else if ( dynamic_cast MyClass*(w) ) { classname =
MyClass; }
printf(child #%d: %s\n, i, classname);
}
}
}
I'm not sure, wether all the brackets are right, but even if not
compilable this should show the idea.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] getting parent class
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
private variables).
AFAIK, FLTK doesn't use RTTI;
But most of the modern compilers use RTTI as default (and even the older
ones can activate it) and so it works, when regarding classes, derived
from FLTK.
When there is a class My_Fl_Group, derived from Fl_Group, it is easy to
get the information:
if (My_Fl_Group* pG= dynamic_cast My_Fl_Group* (parent()))
{
// use your Group pG-do_something();
}
This also works, when widget is inside of some structures:
Fl_Group* pP= this-parent();
while (pP)
{
if (My_Fl_Group* pG= dynamic_cast My_Fl_Group* (pP))
{
// use your Group pG-do_something();
// Terminate loop:
pP= 0;
}
else pP= pP-parent();
}
This will crawl up the parents, until the special group was found.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] MingW make error
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 seems, the include files of jpeglib are not found or not existing. On my system the definition of boolean comes from jmorecfg.h which is included from jpeglib.h. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK compile error
Coder schrieb: Hi, I get an error trying to compile with mingW on windows. $fltk-config --compile myfirstwindow.cxx g++ -I/usr/local/include -I/usr/local/include/FL/images -mwindows -DWIN32 -DUSE_OPENGL32 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -o 'MyFirstWindow' 'MyFirstWindow.cxx' -mwindows /usr/local/lib/libfltk.a -lole32 -luuid -lcomctl32 c:/mingw/bin../lib/gcc/mingw32/4.5.2/../../../libmingw32.a(main.o):main.c(.text+0xd2): undefined reference to 'WinMain@16' collect2: ld returned 1 exit status How can I solve it? Looks like there is no main function in your project, something like int main() or int main(int argc, const char* argv[]). ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Howto prevent Fl_Window from closing by Escape?
I want to prevent Fl_Window from being closed by button escape [Esc].
I found window is closing because of Fl::Fl::handle_():
// make Escape key close windows:
if (event_key()==FL_Escape) {
wi = modal(); if (!wi) wi = window;
wi-do_callback();
return 1;
}
Should I rebuild FLTK without this, or is there a way to deactivate?
Writing a callback like
void Cb_Close(Fl_Widget* o, void* v)
{
if (Fl::event_key()!= FL_Escape)Test.hide();
else Fl::event_key(0); // No effect!
}
leaves the problem, that window doesn't close by mouse, when Escape was
pressed before.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
