Re: [fltk.general] Widget ordering in group
The Tab navigation is in the order on which the widgets were created. The arrow navigation takes their position and size into account. MacArthur, Ian (Selex ES, UK) ian.macart...@selex-es.com schrieb: I have a window with full of widgets made with fluid. Some of them are text fields to be user filled in order. When I hit the tab key to change widget focus, the ordering is haphazard. Do widgets in groups have a tab-key ordering ? How do you change the order? Can you change the ordering between two widgets. I think they are navigated in the order that they are added to their parent group, are they not? So, if they are ordered in fluid in the way you want them, that ought to pretty much do it. Does that not work? Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk -- Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail gesendet. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.development] My DSL is back and I have 300 mails in my box.
Hi guys, sorry that I have been offline so long. We finally moved (still over 80 boxes to unpack), and we got our new internet connection yesterday. Phew. I will try to jump back into the subjects discussed. Some licensing issues flew by. If there is urgent stuff, please send me a PM: mm at matthiasm punkt com. Cheers, Matthias ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: decision on license to use forfltk/examples source code
Fine. Matthias, currently with almost no internet :×) Michael Sweet m...@easysw.com schrieb: I'm OK with MIT. On 2013-02-27, at 10:47 PM, Greg Ercolano e...@seriss.com wrote: Would like to hear from Albrecht, Matt, and Mike on this as well. Greg: Zlib or MIT with exceptions to relax use and not require citations Ian: Zlib, add exception to relax code use Recommendations of other licenses are fine too. I think all we really want people NOT to do is attempt to declare ownership to themselves, then try to leverage others with it, as well as including a limited warranty and liability waiver. As an example of usurping ownership, say someone at Company A uses some of our example code, then he leaves the company. Years later, Company A thinks our examples were taken from their code (due to the similarity) and attempt to take us, or others to task about it. I did some research trying to figure out what license books use for their examples, but couldn't find much. O'Reilly has the following general policy for reuse of code examples from his books, but it's not really a license, it's just a FAQ response from Tim O'Reilly: http://oreilly.com/pub/a/oreilly/ask_tim/2001/codepolicy.html In general, all books have copyright notices at the front, but don't generally discuss the use of example code.. the implication is to of course use them, and people usually reference the source if they want when appropriate, but are certainly not forced. It'd be nice if our example code didn't need paragraphs of license prologue, and could just reference a file (eg. README-License.txt) that comes with the examples. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev -- Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail gesendet.___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Event-Handling
On 12.01.2013, at 15:00, Christian Hufnagel ch_...@web.de wrote: How can I react on all events which are got at a widget how a button? As an example, I have an button, and I would like to react on an other event as click how mouseover, on which could be reacted with the callback-method. Sorry for the bad english, it is not my mother language. Every widget has a callback. The callback is called when the event happens, that is important for that widget. For example, the Button callback is called when the users clicks a button. If you need more events, you must write a new event handler for your widget. This is easy, but you must derive a new class and overwrite SomeWidget::handle(int);. Here you get all mouse events and so much more. This is all explained in detail in the documentation. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Event-Handling
Depending on what you define a /special/ event, yes. Do you have a specific example where we can help you? Christian Hufnagel ch_...@web.de schrieb: On 12.01.2013, at 15:00, Christian Hufnagel ch_...@web.de wrote: How can I react on all events which are got at a widget how a button? As an example, I have an button, and I would like to react on an other = event as click how mouseover, on which could be reacted with the = callback-method. =20 Sorry for the bad english, it is not my mother language. Every widget has a callback. The callback is called when the event = happens, that is important for that widget. For example, the Button = callback is called when the users clicks a button. If you need more events, you must write a new event handler for your = widget. This is easy, but you must derive a new class and overwrite = SomeWidget::handle(int);. Here you get all mouse events and so much = more. This is all explained in detail in the documentation. Thank you for the fast answer. To be sure: If I want to react on special events, I can't do that with the normal widgets, I must derive a own class? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk -- Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail gesendet. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Time out Reentrance on Windows
On 02.01.2013, at 23:08, Ian MacArthur imacart...@gmail.com wrote:
On 2 Jan 2013, at 18:50, Greg Ercolano wrote:
o Don't call Fl::wait(), Fl::flush() or any related methods that will
handle system messages
..which I take to mean Fl::run() as being 'related'.
Perhaps, though, the list should explicitly mention Fl::run(),
as it's the most common thing to call.
Devs: shouldn't we add Fl::run() to that short list?
I'd vote yes, though we probably need someone who really understands that
code (Matthias?) to pitch in with an opinion...
Yes, absolutely. Fl::run() is basically: for(;;) { Fl::wait(); }
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] Amalgamation
On 31.12.2012, at 00:38, Ian MacArthur imacart...@gmail.com wrote: JUCE's Infojucer seems to have the ability to generate a list of files to place in your build, based on which widgets are actually used in your code, so something akin to that might work for us. Fluid3 can do that for FLTK itself, and is very close to be able to do that for any FLTK based application. You can add modules (fltk3gl, fltk3connect etc.) and configure some aspects of the build. After installing FLTK3, the first binary can exist within a minute or two. But back to amalgamation/modularization: technically, there is no difference between g++ myApp.cpp fltk/Window.cxx fltk/Widget.cxx fltk/run.cxx -o myApp and g++ -c fltk/Window.cxx g++ -c fltk/Widget.cxx g++ -c fltk/run.cxx ar WIndow.o Widget.o run.o -o fltk.lib g++ myApp.cpp -l fltk -o myApp And while the second version seems more involved, it is actually much faster because it only needs to run those lines that are associated with files that actually changed. Setting the linker correctly will remove all unused code from the final executable, so there is no harm in adding more files. FLTK does require a pre-compile configuration pahse though, simply because it supports so many configurations, especially for X11. The advantage is that FLTK will run on even the smallest embedded Linux device, to a certain degree even without X11. There is simply n way to do that at compile time only. To me, it's fine if users want to compile fltk cxx files instead of using the library. We could provide a default configuration that just works for current machines, but for older systems, we still need autoconf. - Matthias ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Text dragdrop within Fl_Text_Editor
On 28.12.2012, at 23:40, Ian MacArthur imacart...@gmail.com wrote: On 28 Dec 2012, at 21:27, Manolo Gouy wrote: Both the Fl_Text_Editor and Fl_Input widgets support dragdrop of text, but only Fl_Input draws the cursor while dragging text around from the same widget to indicate where the drop would act. There's code in Fl_Text_Editor (case FL_DND_DRAG of Fl_Text_Editor::handle(int)) that moves the insertion point while text is dragged around, but the code for drawing cursor in Fl_Text_Display::draw() disables cursor drawing when there is a text selection. Thus, when doing a dragdrop of text within an Fl_Text_Editor widget, the user does not get an indication of where the drop would act through cursor drawing. Is this difference between the two text widgets a desired behaviour? I don't think it is intended: more consequential... The text editor is complex, and I suspect it is tricky (sometimes) to figure out where the insertion point really is... (or something like that?) I believe I can fix that though, time permitting. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Text dragdrop within Fl_Text_Editor
On 29.12.2012, at 13:03, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: On 28.12.2012, at 23:40, Ian MacArthur imacart...@gmail.com wrote: =20 On 28 Dec 2012, at 21:27, Manolo Gouy wrote: =20 Both the Fl_Text_Editor and Fl_Input widgets support dragdrop of text, but only Fl_Input draws the cursor while dragging text around from the same widget to indicate where the drop would = act. =20 There's code in Fl_Text_Editor (case FL_DND_DRAG of Fl_Text_Editor::handle(int)) that moves the insertion point while text is dragged around, but the code for drawing cursor in Fl_Text_Display::draw() disables cursor drawing when there is a text selection. Thus, when doing a dragdrop of text within an Fl_Text_Editor widget, the user does not get an indication of where the drop would act through cursor drawing. =20 Is this difference between the two text widgets a desired behaviour? =20 I don't think it is intended: more consequential... =20 The text editor is complex, and I suspect it is tricky (sometimes) to = figure out where the insertion point really is... (or something like = that?) I believe I can fix that though, time permitting.= I have fixed it (before reading this offer). I wrote the offer before seeing your check-in. Thank you very much! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Amalgamation
On 29.12.2012, at 02:06, Domingo Alvarez Duarte mingo...@gmail.com wrote: Here http://rawmaterialsoftware.com/juce.php it has an amalgamtion for his c++ cross platform gui library. It's not a so crazy propose. I am sitting here with my mouth open. Now I see even lees advantage to all this. So this developer went through all the work to somehow avoid a configuration script. But you still have to include the C++ source file for every module you want? How does that make life easier? So to compile the simpelest push button app in FLTK, instead of g++ button.cxx -o button -lfltk using his styl, you'd have to do: g++ button.cxx fltk/Button.cxx fltk/Window.cxx fltk/Group.cxx fltk/run.cxx fltk/boxtypes.cxx fltk/fonts.cxx (...) -o button This discussion reminds me very much of the suggestion to create extensive debug output to the console, so that FLTK was easier to debug. It turned out that this idea was based on the fact that the user never bothered to learn to use a debugger. He wrote huge programs by adding hundreds of printf() lines instead of simply setting a breakpoint. Maintaining the existing number of build environments (make, cmake, VisualC6/2008/2010, Xcode3/4) is hard work and time consuming. So much, that FLTK3 automates this task, so we can get back at improving FLTK itself instead of spending 80% of our time keeping the build environments compatible. I personally will not take on another build environment unless it opens up an entire new platform for us (iOS, Android come to mind). But that should not keep you from writing this script, if you feel like doing so. I'll be interested to see if this monolithic source concept works out. And I'll be happy to test it for OS X. - Matthias ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Amalgamation
On 29.12.2012, at 17:18, superbem super...@gmail.com wrote: Like to add that amalgamations are Fast Light to compile also :D I compile the 5mb sqlite amalgamation with gcc in 5sec (debug mode) on my pc. OK, I downloaded and used Juce a bit on OS X. What a wonderful piece of software! So it seems they went from amalgamation to modularization in which the source files are included into the main build. It did compile everything without trouble and the app ran just fine on OS X. I did get a linking error for Android, which I am sure they will fix pretty soon, too. In the end, it really made no difference if I include source code or libraries (which simply are precompiled and packed source files). So, yes, it works. Does it make life simpler? Probably depends on the user. - Matthias ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] FLTK community on Google Plus
On 28.12.2012, at 23:24, Ian MacArthur imacart...@gmail.com wrote: On 28 Dec 2012, at 07:36, Sepehr Aryani wrote: Hi, I wanted to ask you to create a FLTK community on G+ so that those who are interested in FLTK can constantly follow it. FLTK forum is not very good and collaboration is a little bit slow in it. Note that the forums are not, in fact forums: rather they are a web front-end to a mailing list. If you want something more akin to the immediate push nature of social media then signing up for the mailing list is probably the closest you'll get. Try it, you might even like it. Or use a news reader. The mailing list in turn is a front end to the very useful and great Usenet news system. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] Amalgamation
On 26.12.2012, at 20:47, superbem super...@gmail.com wrote: With this we can do compilation cross-platform very trivial. No. This works for SQLite because it is relatively small and does not depend on many external files at all. FLTK depends on a large number of configurable items that are determined at configuration time - before compile time. In C, it is not possible to conditionally include a header file, for example, which may be required for advanced machines, but not for older OS's. At build configuration time, there is absolutely no difference between including one single source file into a project, or one single static library. Just add the one source file, change the compiler, whatever the ide, whatever the platform, always so easy to compile with the working project. Just add the source file to project, no linking headaches when we want avaiable x64 or x86 and so on. I think you can see the vision and get why is so straightforward. Think about it, with all source in one source file, you can be 100% compatible with all platforms in a very simple way. Another advantage FLTK will get is the audience will expand, as Amalgamations are so easy to implement. For the core developers, this would be a complete disaster. Compile time would increase tenfold or more, we would loose modularity, the source code would no longer be manageable at all. I doubt that my editor would even be able to keep this single file in memory (I frequently edit a 120MB assembler file - impossible in Xcode, but just fine in vi). The disavantages about the time to compile all source of Amalgamations are so trivial nowadays, as computers are very fast in present. And there is allways cache. I don't think this is a good idea. But maybe I am missing some point. As I see it right now, this is only useful for users who shy away from compiling FLTK once and linking a static library. Please let me know if I am missing a point. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.general] Fwd: [fltk.bugs] Mac OS: bug in make_current
Please do not post to FLTK bugs. Post to General instead. Thanks.
Begin forwarded message:
From: claude roux claude.ro...@free.fr
Subject: [fltk.bugs] Mac OS: bug in make_current
Date: 19. Dezember 2012 13:39:52 MEZ
To: fltk-b...@easysw.com
Reply-To: Mirror of fltk.bugs Newsgroup fltk-b...@easysw.com
Hello,
I have been using FLTK for quite a while now (about a year), and with some
success. I use the 1.3.2 version, which I have integrated in projects on
Windows, Mac OS and Linux.
However, I have a real problem on Mac OS, a crash which happens in certain
cases when I mix a (non FLTK) modal window and an FLTK window. When I destroy
the FLTK window, I have a crash...
I traced the error back to Fl::make_current in Fl_cocoa.mm, with a lockFocus,
which is where the bug is perpetrated...
For the moment, the only way for me to bypass this problem is to add a
@try/@catch around the lockFocus and I destroy the window...
void Fl_Window::make_current() {
..
NSView *current_focus = [NSView focusView];
// sometimes current_focus is set to a non-FLTK view: don't touch that
@try {
if ( [current_focus isKindOfClass:[FLView class]] )
[current_focus unlockFocus];
[[i-xid contentView] lockFocus]; -- CRASH HERE
}
@catch(NSException* e) {
delete this; -- VERY HORRIBLE, but it does not seem to matter
return;
}
It works, but I do not feel very comfortable to modify the code of a library
which I use on many platform.
Do you have any idea how I could bypass this error in a more acceptable way?
Thank you in advance...
___
fltk-bugs mailing list
fltk-b...@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Problem creating a second modal dialog
On 18.12.2012, at 19:18, Chris Shearer-Cooper cshearercoo...@intio.us wrote: We are using fltk 1.3.0rc2; I'm displaying a modal dialog by calling set_override() and set_modal(), then while that modal dialog is being shown I want to show a second modal dialog as a child of the first. The problem is that no matter what I do, the second dialog always shows up _under_ the first. Any suggestions how I can force fltk to display the second modal dialog on top of the first? Have you tried without set_override() ? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] MacOS X 10.7.5 + fltk 1.1.10
On 28.11.2012, at 20:11, Andrea Orlando budus...@gmail.com wrote: When I try to compile fltk, I get this message: make[1]: *** [Fl.o] Error 1 make: *** [all] Error 1 Where I wrong ? FLTK 1.1.10 is long outdated. I think it was released just after the Playstation I was released ;-). It uses the Apple API Carbon which Apple no longer supports. Please use 1.3.1 instead. It is highly compatible to 1.1.10 with many *many* improvements, and it should compile and run with no problems on current (and older) OS X systems. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] MacOS-specific bug in FLTK 1.3.1for unbundled applications
On 26.11.2012, at 10:12, MacArthur, Ian (SELEX GALILEO, UK) ian.macart...@selexgalileo.com wrote: Software releases shall be generated for each successfully completed software trouble report. although this is not like the current (past) practice. Well, I suppose we *could* sort of claim that the weeklies fulfil that role... Shall we change the CMP? Maybe; though evidence suggests that no one would notice the changes anyway! ;-) LOL, yes. In the past, we would generate new patch releases whenever *all* STRs were fixed. Hence the enormous time between patches. I would suggest to release a new patch whenever a critical STR (preferable several critical STRs within a short period, say a week) has been fixed. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] MacOS-specific bug in FLTK 1.3.1 for unbundled applications
No problem. Once fixed, we can release 1.3.2. However, we should put more fixes into a release than one... Ian MacArthur imacart...@gmail.com schrieb: On 23 Nov 2012, at 13:58, Manolo Gouy wrote: MacOS-specific bug in FLTK 1.3.1 for unbundled applications I have noticed with STR #2890 a Mac OS X-specific bug present in FLTK 1.3.1: unbundled applications don't appear in the dock and don't show their system menu. [For developers unfamiliar with Mac OS X: a standard Mac OS application with GUI is normally bundled, that is, made of a number of files, among which the executable program, all belonging to a directory. Non GUI-using applications are usually unbundled, that is, made of a single executable file. A GUI-using, unbundled app is nevertheless possible, but suboptimal.] The configure+make and CMake build systems of FLTK currently produce (mostly) unbundled applications (fluid and most example apps), whereas the Xcode build system produces bundled versions of the same applications. STR #2890 is a bug that applies only to the unbundled versions of FLTK apps. It was introduced by myself at r.9684, between FLTK 1.3.0 and 1.3.1, in an attempt to remove deprecated system calls from the code base. It's fixed with a 2-line change in r.9729 (http://www.fltk.org/newsgroups.php?s7053+gfltk.commit+v7062+T0). Unfortunately, I didn't check the unbundled form of FLTK apps, but only the bundled one, so it was not detected before 1.3.1 was out. My idea would be to change the current 1.3.1 archive from the download page of the FLTK web site, putting in it the 2-line fix. This is an unstandard procedure, but the bug concerns only Mac OS X for which, I believe, there's no third party source of diffusion of FLTK 1.3.1. My own feeling is that I'm not comfortable with changing the released tarball once it is out... If this is a real serous issue we should opt for a 1.3.2 I guess. However, I suspect that anyone who is making a serious app on OSX is probably creating a bundle anyway, so I doubt that many people will be hit by this. Though I could be totally wrong... I'm very sorry for this error of mine, and in need to know the opinion of other devs. Ah, whatever; don't worry - stuff happens... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Release 1.3.1 ?
On 09.11.2012, at 19:28, Albrecht Schlosser ajs856s...@go4more.de wrote: Absolutely, well put. But I see that Matt already did the release, so I'm late with my comment, but anyway, FWIW. Are the changes correct the way they are? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Release 1.3.1 ?
On 07.11.2012, at 06:02, Greg Ercolano e...@seriss.com wrote: Looks like Matt released 1.3.1 -- thank you! Don't forget to post on fltk.announce as well. I tried. Either I forgot how, or I don't have access anymore. Tsts. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.general] FLTK 1.3.1 maintenance version released!
Even though 1.3.1 does not fix all STRs, we decided to release FLTK 1.3.1 as it contains a few substantial features, fixes, and adaptations to new compiler releases. CHANGES IN FLTK 1.3.1 • Fixed utf_strncasecmp and utf_strcasecmp • Moved all inline constructors into source file to avoid bad DLLs • Fixed Fl_Widget::copy_label() and Fl_Window::copy_label() when called with the old label() (STR #2836) • Fixed Fl_Input_::maximum_size() documentation and replace() method to honor maximum_size() as number of allowed characters (STR #2747). • Fixed a potential crash if Fl_Double_Window::flush() was called before show() • Fixed regression (in FLTK 1.3.0) that could clear a radio button by using the keyboard (space or shortcut) (STR #2748) • Fixed fl_pie() drawing too small on X11 (STR #2703) • Fixed Fl_Menu issue with unusual menu flags (STR #2680) • Fixed Windows DLL import of fl_xid() (STR #2670) • Added Fl::screen_work_area() functions that compute the work area of a screen. These functions improve the positioning of menus. Changed Fl::x(), Fl::y(), Fl::w(), Fl::h() functions to return the origin and size of the work area of the main screen (STR #2695 + 2697) • Created the FL_SCREEN_CONFIGURATION_CHANGED event that is triggered when a screen is added, removed, moved or when resolution is changed (STR #2600) • Improved the description of page size and orientation by Fl_PostScript_File_Device. • Added support for horizontal wheel movement under X11 and MSWindows Vista and above (STR #2644). 1.3.1 ABI FEATURES (To enable the following ABI features, put: #define FLTK_ABI_VERSION 10301 at the top of your FL/Enumerations.H and rebuild FLTK and your app) • Fl_Tree optimized to support large trees (eg. 100k items): Added _next_sibling and _prev_sibling to Fl_Tree_Item class, and support methods. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] Release 1.3.1 ?
On 16.10.2012, at 10:42, MacArthur, Ian (SELEX GALILEO, UK) ian.macart...@selexgalileo.com wrote: Reawakening this thread. +1 for 1.3.1 release, with the ABI breaking stuff turned off by default, and calling it 1.3.1 (not .2) Yes. I probably voted before (!) but I'm +1 on just pushing out what we have... OK, I will have a little bit of time for a release. What needs to be turned off? - Matthias ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Comparing Colors in an if statement
On 05.11.2012, at 20:58, Laszlo Antal lzan...@gmail.com wrote: Hi, On Nov 5, 2012, at 9:06, Doug Parks marickstemp...@yahoo.com wrote: Is it possible to compare the color of a widget in an if statement? If so how would I go about doing it. I have tried using a standard comparison but it says it is unable to do it. Thanks Doug I figured it out. Sorry for the inconvenience. And your solution is? Colors are unsigned int's (32 bit). The components are encoded RGBI where I is an index, or , if that is 0, RGB are 8bit color components. To get the RGB value from any color, use: static void Fl::get_color (Fl_Color i, uchar red, uchar green, uchar blue) Returns the RGB value(s) for the given FLTK color index. and compare components ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Test, ignore
___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] fl_scroll not copying all channels on OS X?
Probably some color correction. We need to check if source anddestination are both in RGB color space. Cant do it right now - i am on the road. Greg Ercolano e...@seriss.com schrieb: On 09/14/12 13:07, Evan Laforge wrote: For a long time I've had a bizarre bug where things that scroll slowly change color, but only on an external monitor. I ignored it because I'm usually not using an external monitor :P But recently I upgraded from OS X 10.6 to 10.8 and now it's doing it on the main monitor (macbook pro) as well, so I investigated further. I can confirm I get weird behavior on mountain lion that I don't get on snow leopard. In my case, during the 'scroll' operation the entire window gets progressively darker, like someone took a screenshot of the window, decreased its brightness, moved it down a few pixels and pasted. Which is probably what's happening; seems like there's a transparency or darkening effect or some such being applied during each scroll. Perhaps the behavior is different because some percentage brightness or transparency value is left uninitialized, causing its value to be random, and causing the brightness shift for all or some channels. Here's a few screenshots of my results on mlion: one at program start, one halfway into the scroll, and one at the end: http://seriss.com/people/erco/fltk/tmp/mlion-scroll-issue.jpg Note the top of the window has a gradient towards the end of the program's execution, which seems to show each scroll operation darkens all the pixels a little bit each time, causing the gradient falloff. So in my case the transparency might be 10% for r/g/b. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] getting usable space per screen? also compilation failure on OS X
Thanks for the long and detailed mail. The errors you describe below remind me of an issue more than halve a year ago, which was fixed. I am very surprised that it reappeared, but I also know that Subversion (or its users ;-) can sometimes mess things up. Jenkins also show that the OS X 1.3 build fails. I will try to fix things in the next days. screen_xywh is supposed to give you the screen size in pixels of each individual attached screen. Fl::w() and h(), x() and y() should give you the usable area of the main screen (so for the Mac, that would be the desktop minus menu bar and tool bar). Creating and resizing of a window should not change the size (by FLTK). This is because the user could have multiple screens with higher resolution. As long as the title bar is visible, the window can still be dragged somewhere else. We do not interfere with whatever the window manager will do to the window. So if the OS X window manager reduces the image on creation, we will let it do so (I'd have to look into the source to verify that this is actually so). The stroy is different with popup menus where we make sure that the window fits and uses only a single screen. On 12.09.2012, at 00:38, Evan Laforge qdun...@gmail.com wrote: So in OS X one of the screens has a 22 pixel menu bar. But due to reasons I haven't fully figured out, the maximum vertical size you can make a window before it goes off the bottom of the screen is the screen height - 44. I don't have a dock at the bottom, but if I did it would probably subtract some more pixels. But anyway, when I create an Fl_Window apparently there's code that figures how much room is available and reduces the height as necessary. But that same code apparently doesn't apply to the resize method, since it will happily resize past the edges of the screen. It seems to make it buggy too, since it can then jump about randomly when I drag it. So firstly, Fl_Window::resize on the mac should probably clip to the screen size as it does on creation, right? Secondly, is there a portable way to find out the usable space on a screen? Fl::screen_xywh() just gives the resolution which isn't enough to create or maximize windows. Thirdly, I wanted to see if the behaviour had been fixed in recent versions so I did an svn update, but it looks like the build is broken, coincidentally also with a bunch of screen-related symbols: Compiling Fl_Native_File_Chooser_MAC.mm... Fl_cocoa.mm: In function ‘void -[FLDelegate windowDidResignKey:](FLDelegate*, objc_selector*, NSNotification*)’: Fl_cocoa.mm:1046: error: ‘class Fl_Window’ has no member named ‘fullscreen_active’ Fl_cocoa.mm: In function ‘void -[FLDelegate windowDidBecomeKey:](FLDelegate*, objc_selector*, NSNotification*)’: Fl_cocoa.mm:1057: error: ‘class Fl_Window’ has no member named ‘fullscreen_active’ Fl_cocoa.mm: At global scope: Fl_cocoa.mm:2039: error: no ‘void Fl_Window::fullscreen_x()’ member function declared in class ‘Fl_Window’ Fl_cocoa.mm: In member function ‘void Fl_Window::fullscreen_x()’: Fl_cocoa.mm:2040: error: ‘_set_fullscreen’ was not declared in this scope Fl_cocoa.mm:2045: error: ‘FL_FULLSCREEN’ was not declared in this scope Fl_cocoa.mm: At global scope: Fl_cocoa.mm:2048: error: no ‘void Fl_Window::fullscreen_off_x(int, int, int, int)’ member function declared in class ‘Fl_Window’ Fl_cocoa.mm: In member function ‘void Fl_Window::fullscreen_off_x(int, int, int, int)’: Fl_cocoa.mm:2049: error: ‘_clear_fullscreen’ was not declared in this scope Fl_cocoa.mm:2053: error: ‘FL_FULLSCREEN’ was not declared in this scope Fl_cocoa.mm: In static member function ‘static void Fl_X::make(Fl_Window*)’: Fl_cocoa.mm:2171: error: ‘class Fl_Window’ has no member named ‘fullscreen_active’ Fl_cocoa.mm: In function ‘NSImage* imageFromText(const char*, int*, int*)’: Fl_cocoa.mm:3228: error: ‘create_offscreen_with_alpha’ is not a member of ‘Fl_Quartz_Graphics_Driver’ Fl_cocoa.mm: In function ‘NSImage* defaultDragImage(int*, int*)’: Fl_cocoa.mm:3257: error: ‘create_offscreen_with_alpha’ is not a member of ‘Fl_Quartz_Graphics_Driver’ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [CRIT] STR #2870: fltk 1.1 can't be built on Ubuntu12.04
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2870 Version: 1.1.11 I need a lot more information to help you here. 1: FLTK 1.1 is outdated. Is there a reason for not upgrading to 1.3? 2: if so, which revision of 1.1 are you referring to? 3: what error messages do you get? 4: Again, can't you move up to 1.3? There are hundreds of bug fixes in 1.3. Link: http://www.fltk.org/str.php?L2870 Version: 1.1.11 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] [fltk.general] Drag and drop a file to a window
On 08.09.2012, at 10:00, guyingpinming 392077...@qq.com wrote: On 08.09.2012, at 08:46, guyingpinming 392077...@qq.com wrote: Until now ,I know how to react to a certain event,but judging form the = information provided by the help documentation FL_DND_* events cannot = be used in widgets derived from Fl_Group or Fl_Window,does it means = that it's impossible for FLTK to make a window support drag and drop = file event?I am trying to make a window accept dargging and dropping a = file then open it by certain method.Can anybody help me. Thanks a lot! By the way,the advice from Herman and Greg Ercolano helps me a = lot,here,I want to say thank you for your help! Drag'n;drop works in all widgets, including groups and windows. Could = you please point me at the documentation where it says otherwise? = Thanks. - Matthias Thank you,Matthias,here is the url http://fltk.org/doc-1.3/events.html;, you can find the sentence at the contents about Drag and Drop Events. According to svn, engelsman put this in the docs: FL_DND_* events cannot be used in widgets derived from Fl_Group or Fl_Window. Is there any specific platform or any reason for this? Or is the sentence itself wrong? - Matthias ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Drag and drop a file to a window
On 08.09.2012, at 08:46, guyingpinming 392077...@qq.com wrote: Until now ,I know how to react to a certain event,but judging form the information provided by the help documentation FL_DND_* events cannot be used in widgets derived from Fl_Group or Fl_Window,does it means that it's impossible for FLTK to make a window support drag and drop file event?I am trying to make a window accept dargging and dropping a file then open it by certain method.Can anybody help me. Thanks a lot! By the way,the advice from Herman and Greg Ercolano helps me a lot,here,I want to say thank you for your help! Drag'n;drop works in all widgets, including groups and windows. Could you please point me at the documentation where it says otherwise? Thanks. - Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Drag and drop a file to a window
On 08.09.2012, at 10:00, guyingpinming 392077...@qq.com wrote: On 08.09.2012, at 08:46, guyingpinming 392077...@qq.com wrote: Until now ,I know how to react to a certain event,but judging form the = information provided by the help documentation FL_DND_* events cannot = be used in widgets derived from Fl_Group or Fl_Window,does it means = that it's impossible for FLTK to make a window support drag and drop = file event?I am trying to make a window accept dargging and dropping a = file then open it by certain method.Can anybody help me. Thanks a lot! By the way,the advice from Herman and Greg Ercolano helps me a = lot,here,I want to say thank you for your help! Drag'n;drop works in all widgets, including groups and windows. Could = you please point me at the documentation where it says otherwise? = Thanks. - Matthias Thank you,Matthias,here is the url http://fltk.org/doc-1.3/events.html;, you can find the sentence at the contents about Drag and Drop Events. According to svn, engelsman put this in the docs: FL_DND_* events cannot be used in widgets derived from Fl_Group or Fl_Window. Is there any specific platform or any reason for this? Or is the sentence itself wrong? - Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] whats the latest?
On 08.09.2012, at 19:24, Ian MacArthur imacart...@gmail.com wrote: On 7 Sep 2012, at 23:59, Paul R wrote: Hi all, I have not logged in for a while, Have barely programmed in C family languages for over a year, bin mired in horrible vba flaky land - but on the back of that i am in a postion to sell a (extndable) piece of work to my employer - which has fltk dependancy - can i do this? Hi Paul, Um... not really sure what it is you are asking, to be honest... I understand that he needs a Visual Basci interface to be able to use FLTK for a new project? Sorry, we don;t have that. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Einstein and Xcode 4
This drives me nuts! I just had the one Eureka moment I was waiting for: how to move Einstein from being an Emulator (slow, interpreting the ROM, inflexible) piece by piece to become a simulator (running native code at full speed, rebuilding the OS, being copyright free). And then this: using the newest version of Xcode, Einstein barely compiles, and if it does, it will not run beyond the boot sound anymore. WTF? It's Apples idiotic pressure on developers to always use the newest API, so our apps become incompatible to older hardware. Anyway, end of rambling, start of question: can anyone help me to get Einstein back to life using Xcode 4.4.1? If so, I would love to implement Fibers to acheive the jump to simulation. - Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Einstein and Xcode 4
Sorry, I clicked the worng address field. This was of course supposed to go to the Einstein Newton emulator group. ;-) On 05.09.2012, at 10:54, Matthias Melcher m...@matthiasm.com wrote: This drives me nuts! I just had the one Eureka moment I was waiting for: how to move Einstein from being an Emulator (slow, interpreting the ROM, inflexible) piece by piece to become a simulator (running native code at full speed, rebuilding the OS, being copyright free). And then this: using the newest version of Xcode, Einstein barely compiles, and if it does, it will not run beyond the boot sound anymore. WTF? It's Apples idiotic pressure on developers to always use the newest API, so our apps become incompatible to older hardware. Anyway, end of rambling, start of question: can anyone help me to get Einstein back to life using Xcode 4.4.1? If so, I would love to implement Fibers to acheive the jump to simulation. - Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] DLL problem with Fl_Window-show() or Fl::run()
On 05.09.2012, at 10:37, MacArthur, Ian (SELEX GALILEO, UK)
ian.macart...@selexgalileo.com wrote:
FLTKInstance = GetModuleHandle(fltkdll.dll); //access count is N
(assumed 0)
while (FLTKInstance)
{
BOOL fi = FreeLibrary(FLTKInstance);
if (fi) FLTKInstance = GetModuleHandle(fltkdll.dll);
elseFLTKInstance = NULL;
}
//completely unloaded now.
FLTKInstance = LoadLibrary(fltkdll.dll); //
//we get to here, and the DLL is loaded, but it doesn't matter. No UI
will come up the second time
I wonder if we need to explicitly unregister the fltk window classes from the
Windows context and then re-assert them, or maybe register them with a
different name each time, or something...?
I am not sure if the entire endeavor will ever work. It's a long time ago that
I used the PS plugin API, and it was quite limiting. I believe that there is a
good reason for that: it is close to impossible to have independent UI systems
running within one application.
Even though FLTK is of course based on the same core libraries as Photoshop,
there can be only on master. This master captures all the events sent from the
OS and decides if they are sent on or not. FLTK requires a lot of events to
function correctly, but if Photoshop snaps those events away before they reach
FLTK, FLTK will never function correctly.
My approach would be to separate the math and the UI into two processes - not
just threads, but independent programs. This sounds like a lot of work, but it
doesn't have to be. There are tons of APIs out there that make interprocess
communication less of a pain.
For example, you can use a simple pipe to send commands back and forth. You can
use file mapping or shared memory to quickly exchange image data for previews,
and much more.
I know, this adds a layer of complexity, but depending on how you write your
app and filter, you can use this separation as a benefit, for example:
- offer a filter without a UI as a cheaper support tool without giving away the
full functionality
- have a standalone version with the UI only, so you can sell to users without
photoshop
Missing re-initialization should not be a problem IMHO because no resources
have been freed either. At the next call of you plugin, you should be able to
simply continue where you left off, minus the limitations in the event loop, as
describe above (note; opening a window also uses and causes events, meaning
that a limited event loop may make it impossible to open windows!).
- Matthias
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Einstein and Xcode 4
On 05.09.2012, at 11:03, MacArthur, Ian (SELEX GALILEO, UK) ian.macart...@selexgalileo.com wrote: Sorry, I clicked the worng address field. This was of course supposed to go to the Einstein Newton emulator group. ;-) Though there are folk here too who would like to see a native Einstein/Newton... That said, I doubt I can help - I can't get on with Xcode at all, still have 3.2.6, and am only using the CLI anyway... This is implementing your idea of creating a clean room native code object that presents the same API as the Newton ROM, but with your own code inside it so it can build on any host, and duck around the Apple license issues? Does sound interesting though - would love it if it worked! Though... IIRC the Newton ROM presented some API in C++ (or ObjC?) based on the calling convention of some obscure obsolete compiler... so creating code to the same ABI might be, um, tricky...? Yes, it is tricky. I need interfaces between the Just In TIme compiler and the native code. Those interfaces convert from register notation into a correctly formed C+ call, also taking care of the return value. But all that has been working for a year now. The major issue is the extensive use of the MMU by Newton OS: a memory access fault can happen at any time. The JIT takes care of that very well, but native code would need to call the JIT, causing a recursion in the JIT system. But then I found this neat thing call fibers. A fiber is a thread without the ability to run at the same time as another thread (Since NewtonOS was never meant to run on multiple cores, it has very limited thread protection). Or, looking at it from the other side, the ability to have two or more stacks and environments inside a single C program. The solution now is using a fiber when changing into native code. If a memory violation happens, we simply jump back to the original fiber, handle the exception, and jump back to the native fiber. To the JIT, the whole procedure appears just like two instructions, not knowing anything about all the native stuff going on in the other fiber. Is it easy to tell by the long EMails today, that I try to avoid work? - Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] DLL problem with Fl_Window-show() or Fl::run()
On 05.09.2012, at 11:28, MacArthur, Ian (SELEX GALILEO, UK)
ian.macart...@selexgalileo.com wrote:
I wonder if we need to explicitly unregister the fltk window classes
from the Windows context and then re-assert them, or maybe register them
with a different name each time, or something...?
I am not sure if the entire endeavor will ever work. It's a long time ago
that I used the PS plugin API, and it was quite limiting. I believe that
there is a good reason for that: it is close to impossible to have
independent UI systems running within one application.
Even though FLTK is of course based on the same core libraries as
Photoshop, there can be only on master. This master captures all the
events sent from the OS and decides if they are sent on or not. FLTK
requires a lot of events to function correctly, but if Photoshop snaps
those events away before they reach FLTK, FLTK will never function
correctly.
Agree.
But the kicker here is that it (at least appears) to work perfectly the
*first* time that the fltk window is shown. Then subsequent attempts to show
the fltk context fail...
So I do wonder if there's something we can do to make every time just like
the first time, and hence at least give the appearance of working Just Right
(even if under the covers it is all a bit suspect!)
Has it been tested that the dll is not unloaded? Maybe PS *does* (partially,
thanks to MSWindows) during calls to the plugin? A simple debug breakpoint in
the DLL initialization and deinitialization should clarify that.
On WIN32, this should help:
BOOL APIENTRY DllMain(HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved)
{
switch( ul_reason_for_call ) {
case DLL_PROCESS_ATTACH:
...
case DLL_THREAD_ATTACH:
...
case DLL_THREAD_DETACH:
...
case DLL_PROCESS_DETACH:
...
}
return TRUE;
}
Maybe the original code needs to be replaced in the DLL to avoid destruction of
some statics?
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Einstein and Xcode 4
On 05.09.2012, at 15:21, MacArthur, Ian (SELEX GALILEO, UK) ian.macart...@selexgalileo.com wrote: Though... IIRC the Newton ROM presented some API in C++ (or ObjC?) based on the calling convention of some obscure obsolete compiler... so creating code to the same ABI might be, um, tricky...? Yes, it is tricky. I need interfaces between the Just In TIme compiler and the native code. Those interfaces convert from register notation into a correctly formed C+ call, also taking care of the return value. But all that has been working for a year now. The major issue is the extensive use of the MMU by Newton OS: a memory access fault can happen at any time. The JIT takes care of that very well, but native code would need to call the JIT, causing a recursion in the JIT system. OK - that sounds even more complicated than I'd imagined though; I was just envisaging something analogous to what the Haiku folk seem to have (at least, as it seems to me) where they build with one ABI that matches the C++ compiler that BeOS used, so that older code and existing BeOS binaries will run, but they have an alternate ABI based on more recent C++ compilers that presents the same API in a more modern way... and some sort of wrapper to map the ABI's so that old code can run wrapped up on the new hosts, or something... Ah, I see what you mean. The beauty of NewtonOS is, that there is almost no app out there that uses native code. All existing apps are compiled into NewtonOS byte code which can we already compile and run. So it is actually a bit less work because in the end we need only the modern API. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Einstein and Xcode 4
On 05.09.2012, at 18:25, MacArthur, Ian (SELEX GALILEO, UK) ian.macart...@selexgalileo.com wrote: Ah, I see what you mean. The beauty of NewtonOS is, that there is almost no app out there that uses native code. All existing apps are compiled into NewtonOS byte code which can we already compile and run. So it is actually a bit less work because in the end we need only the modern API. Oh, right, I see (maybe...) So what is needed is: 1) An interpreter for the NewtonOS byte code 2) A mechanism to run the Newton ROM and execute the bytecode And (1) you already have, and (2) is done by running a real Newton ROM in an emulation of the Newton h/w environment - this works, but is slower than we'd like. So the plan is to replace (2) with a native re-implementation of the Newton ROM, based on the known API, and then it will all run much faster and be (I assume) free of Apple IP? Is that about right? The ROM has about 3MB of ARM machine code generated from C++ (10% hand coded in assembler). That part is emulated and about the factor 20-100 slower than the original. This is the part I want to recreate in C++. Another 3MB is written in NewtonOS, compiled into Byte Code. These need only be recreated if want to run without a licensed ROM, but make no difference in speed. The remaining 2MB are graphics, sounds, and word libraries, which again are (C) Apple and need to be recreated to be copyright free, or injected using an existing ROM. Running the byte code is one thing, but having the total Newton experience includes hand writing recognition, a smart database, and a complete UI library. UI library? Yes indeed. And here we are back on the subject. Yes, I considered writing an interface for the compiler to FLTK for a while. This would work pretty well, made easy by the wrapper layer of FLTK3, but it would not be NewtonOS. There are some great ideas in NewtonOS. If FLTK ever supports pen base devices, it could get a lot of inspiration from it. For touch devices, not so much. - Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Shortcut keys are not working, how to make shortcut keys work?
On 31.08.2012, at 14:27, Furqan fur...@real3d.pk wrote:
After spending so many days, finally I got it. Unintentionally I pressed the
shortcut key when the menu was opened. It worked. So, the issue was menu was
not selected or opened.
But this seems awkward, anytime and anywhere shortcut keys should work. I am
using OpenGL, the full window is covered with opengl display except the upper
part of menu.
Shortcut key does not work until I open that specific menu in which the key
is specified.
For example, the menu FILE has New(Ctrl+n) and Save(Ctrl+s). Ctrl+n or
Ctrl+s do not work until I open the FILE menu.
What is this strange issue and how to solve it ?
This is not the intended behavior and this is not how it works for me. I use
shortcuts in all my apps and they behave exactly as you would like them to
behave in your app. There must be something else going on.
Did you write you own handle(int event) function for your OpenGL view? If so,
did you make sure that all events are also handled by the base class (unless
you don't want them to propagate)?
int MyGlWidget::handle(int event)
{
switch (event) {
case FL_PUSH:
return 1;
...
}
return Fl_Gl_Window::handle(event); unless the event is handled above
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Shortcut keys are not working, how to make shortcut keys work?
On 31.08.2012, at 17:04, Furqan furqan...@hotmail.com wrote: No I am not using any kind of GlWidget of fltk for OpenGL display. I am using the traditional OpenGL subroutines and added into Fl_Double_Window. In this way, I created a menu bar in Fl_Double_Window. So you create an OpenGL window using functions from the operating system, and you use FLTK to stitch another window into or next to the OpenGL window? I am not clear how you get both to work together, in particular event delivery is a problem, just like you encounter. Do you have two event loops? The OpenGL one and the FLTK one? How did you create the OpenGL window exactly and when in the process? FLTK expects to receive ALL events from the operating system and then distributes those to the correct windows and widgets. Having a second even delivery systems makes it hard or impossible to know what event is delivered where. Have you considered using Fl_GL_Window in your application? This would make all the window layering and event delivery work correctly. A working and copilable source code file that exhibits the bug would be extremely helpful. - Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] discretionary construction order
On 25.08.2012, at 21:40, Marc Cunning marc.cunn...@gmail.com wrote: Hi, I need to create dynamically (at run-time with callbacks) widget groups, but when adding buttons and sub-windows in the same group, the buttons are shown ok, but the window not. What's wrong here..? Below, Using the program example provided by greg, with an little variant, to sample this question. Any idea..? In FLTK, you normally create your widgets from the outside in. You start with the main window, then add groups, and then add widgets to those groups, using end() to go back up in that hierarchy. Using a window inside a window is the exception and only needed if you require a native window ID, for example for OpenGL context or for media players. Instead, you should use a group. You can us a window, but if you add it to the group later, you need to call show() on it. - Matthias PS: assuming this is 1.3. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Compile Errors filename_list.cxx
Yes, the interface to that call was changed on some platforms just recently. Can you try the current 1.3 from Subversion? On 23.08.2012, at 05:12, Paul Englebretson pa...@gebogroup.com wrote: I downloaded version 1.3.0 and attempted to install it. I followed the instructions provided and during the make process the following error appeared: Compiling filename_list.cxx... filename_list.cxx: In function ‘int fl_filename_list(const char*, dirent***, int (*)(dirent**, dirent**))’: filename_list.cxx:122:73: error: invalid conversion from ‘int (*)(const void*, const void*)’ to ‘int (*)(const dirent**, const dirent**)’ [-fpermissive] /usr/include/dirent.h:256:12: error: initializing argument 4 of ‘int scandir(const char*, dirent***, int (*)(const dirent*), int (*)(const dirent**, const dirent**))’ [-fpermissive] make[1]: *** [filename_list.o] Error 1 make: *** [install] Error 1 Pertinent OS information follows: Linux Mint 13 Maya Linux x 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux The system is up to date according to aptitude. Unfortunately I do not currently have the experience to debug this problem in a short time frame. If one of greater knowledge and experience in this product can address this issue and resolve the problem, it would be greatly appreciated. THANKS in advance for your help! PaulE ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Compile Errors filename_list.cxx
On 23.08.2012, at 18:34, Paul Englebretson pa...@gebogroup.com wrote: I downloaded the SVN version of fltk 1.3, went through the process described and it went through successfully. THANKS to Matthias Melcher for his timely response and suggestion! THANKS also goes to Ian MacArthur for his response! PaulE I am really glad that this worked well. 1.3.1 is overdue... . Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] A fltk 1.3 widget browser
On 19.08.2012, at 19:58, Roland Schwemmer roland.schwem...@googlemail.com wrote: Hi! I'm somewhat new to fltk and I like it a lot! I was in need of a widget browser and needed some exercise, so I wrote one. It works for me, however I'd like to have some feedback on it. Feel free to use it or change it. The package attached comes with a simple cmake-buildfile that you probably have to adapt to your system. (Unless you're on Unix. You might just get lucky then.) A main.cxx is included as an example. I can run the example with about 1.000.000 value-spinners on my netbook and while not being snappy anymore, it's still usable. Sorry, you can't attach files here. You need to either store this somewhere and send the link. Or you need to file an STR as an RFE and attach the file. Best is probably to simply include the ASCII files into the EMail if they are not too long. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Callback on Fl_Menu_Item (FL_SUBMENU)
On 17.08.2012, at 22:22, David FLEURY dfleu...@free.fr wrote: Hi, In the Fl_Menu_Bar, when adding an item which has a FL_SUBMENU flag on, can I have a callback called (using a specific when) ? I have try callback available on Fl_Menu_Item, but it's seems to work only on regular Fl_Menu_Item. I am trying to recompute the submenu when the user will open the submenu (An open previous file list ( in a Nedit way) No, AFAIK, the callback on a submenu item is never called. It could be changed in the library code though. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Text_Display::xy_to_rowcol
On 18.08.2012, at 09:24, David FLEURY dfleu...@free.fr wrote:
Hi,
(I starting to use Fl_Text_Display/Editor to do something like NEdit, so
I have a lot of questions)
I was wondering why xy_to_rowcol is protected ?
or is there a way to have the current line displayed ?
For column, there is position_to_xy and x_to_col, but found nothing for
y_to_line ?
Congratulations on scraping the paint on the most complex and convoluted widget
in FLTK (besides HelpView, maybe) ;-)
TextDisplay and TextEdit are based on an old version of NEdit with permission
of the authors. Originally it was a source code editor wfor ASCII characters
and monospaced fonts. Proportional font support was added later and has
generated a lot of special cases and places where we need to measure and count
instead of just ,ultiplying the number of bytes by a character width to get
pixel positions.
A couple of years ago, I made it worse by adding UTF8 support to this widget,
generating a lot of byte counting on top of pixel counting. You are welcome ;-)
What I want to say is, that a lot of interfaces or non obvious, and a lot of
methods may take more time than it is obvious. However, I think that there is a
pretty complete set of methods for this class. You are probably looking for
this function:
/**
\brief Translate pixel coordinates into row and column.
Translate window coordinates to the nearest row and column number for
positioning the cursor. This, of course, makes no sense when the font is
proportional, since there are no absolute columns. The parameter posType
specifies how to interpret the position: CURSOR_POS means translate the
coordinates to the nearest position between characters, and CHARACTER_POS
means translate the position to the nearest character cell.
\param X, Y pixel coordinates
\param[out] row, column nearest row and column
\param posType CURSOR_POS or CHARACTER_POS
*/
void fltk3::TextDisplay::xy_to_rowcol( int X, int Y, int *row,
int *column, int posType ) const {
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2866: FLTK performace is too low?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2866 Version: 1.3-feature Please use the mailing list/news group/forum general.fltk here: http://www.fltk.org/newsgroups.php FLTK uses X11 to draw on your screen. The rendering speed will depend greatly on the X11 server that you use. The biggest time waster is usually related to fonts. There are tools out there that will measure this for you. You can accelerate rendering of widgets by changing the box types. Currently, a button is drawn raised with shading. If your display is blackwhite only, use FL_BORDER_BOX as your default box type, or draw your own boxes, which may be much faster. You can somewhat reduce the size of you final program by linking statically and enabling all size optimizations and all stripping commands. If you linker can do that, let it remove all unused functions. The best combination of optimizations depend on you tools and on your target processor. Link: http://www.fltk.org/str.php?L2866 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] [RFE] Style Table Entry - bg color
On 17.08.2012, at 10:45, David FLEURY dfleu...@free.fr wrote: Hi, else I am wrong, there is no bgcolor property in the Style_Entry_Table for the Fl_Tex_Display. Is it possible to allow this feature in the future ? That is correct. You can use two different selections, but that is obviously quite limiting. FLTK 3 will use the fltk3::Style field which does include a second color. If you like, you can file an STR so we don;t forget about that feature. Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FTLK performance on Linux.
On 17.08.2012, at 14:06, MacArthur, Ian (SELEX GALILEO, UK) ian.macart...@selexgalileo.com wrote: Just in case anyone fancies playing along at home, and did not see the original posts in the STR, here's the version of the test code I'm currently using, based on the OP's post but tweaked to build on my system, and a small Makefile to build it with... Just for kicks'n'giggles I ported the code to WinXP using the QueryPerformanceCounter() API to get timings, and I get... $ ./qix New control cost 0.02(ms) Show window cost 20.73(ms) ian.macarthur@DESDAF599172 /d/examples/qix-win-times I get 0/166ms on OS X which is not surprising though because OS X allocates multiple buffers for each window and calculates animation and transparencies. 121ms are spent in Fl::show 96ms to open the connection to the display 25ms to create and show the OS window 45ms spent in Fl::run/flush Time spent inside the app alone is almost none. It's the calls to the OS that are costly. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] Parent element in a fltk::browser
On 16.08.2012, at 11:00, Daniel daniel.fa...@mp-ndt.de wrote: I found my mistake (so it's not a bug): In the callback method I receive the clicked item by: Widget* selected(browser-goto_index(browser-value())); goto_index(int) and value() are only working for non-hierarchical browsers and thus always refer to the top level. This does the job in my hierarchical browser: const int level(brSender-current_level()); const int* indexes(brSender-current_index()); Widget* selected(brSender-goto_index(indexes, level)); Just saw your post in this mailing list. This list if for our bug tracking system only. Please use general.fltk instead. You'll get help a lot faster. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2711: FL_NORMAL_SIZE and menus
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2711 Version: 1.3-current Fix Version: 1.3.1 (r9668) STR 2711: another try at fixing the text position in Menu_Button. The label does move a little bit to the left, so it may be necessary to make these buttons larger for long text. It does reduce the risk of overlapping text though. Link: http://www.fltk.org/str.php?L2711 Version: 1.3-current Fix Version: 1.3.1 (r9668) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2836: Fl_Window::copy_label() misbehaviour in special case
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2836 Version: 1.3-current Fix Version: 1.3.1 (r9452) Link: http://www.fltk.org/str.php?L2836 Version: 1.3-current Fix Version: 1.3.1 (r9452) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2858: Need a fix to build 1.3 on cygwin with no x11
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2858 Version: 1.3-current Fix Version: 1.3.1 (r9670) STR 2858: include statements were wrong If the X11 support is needed and broken, please open another STR. The given patch seems to be correct for the given problem. Link: http://www.fltk.org/str.php?L2858 Version: 1.3-current Fix Version: 1.3.1 (r9670) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] [RFE] STR #2866: FLTK performace is too low?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2866 Version: 1.3-feature It's probably much faster to post into the general.fltk mailing list than the STR bug tracking system. But anyway, here we go: Depending on the embedded X11/Microwindows, whatever, your system loads 6 full fonts for FLTK. Especially with unoptimized servers and full international character set, this takes quite long. Try to tell your interface to load characters only on demand. FLTK itself does next to nothing when launched, so it really should not take more than a few microseconds to launch. There is no need to disable any of this stuff if you link statically and tell you linker to remove all dead code, preferably on a function level. FLTK 1 was programmed with this in mind and tries really hard to avoid linking to things you don;t use. If you link dynamically, however, the entire library will be generated and loaded, in case you run multiple FLTK app simultaneously. Link: http://www.fltk.org/str.php?L2866 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2780: Fl::delete_widgets do not check if an widget is already on the queue
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2780 Version: 1.3-feature Fix Version: 1.3.1 (r9666) STR 2730: avoid putting widgets into the delete list twice Link: http://www.fltk.org/str.php?L2780 Version: 1.3-feature Fix Version: 1.3.1 (r9666) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 r9661 build errors on centos 5.6 x64
Thanks for testing this. Yes, the Makfiles may have suffered somewhat in the conversion. Even though the additional include paths seem annoying, I have been quite happy with the setup. Combined with the Fluid Makefile generator, it is possible to add many features as modules without the risk of double include names. I'll see if I can fix that soon... . On 13.08.2012, at 21:06, Greg Ercolano e...@seriss.com wrote: Just updated fltk3 to current (9661), and am getting these build errors on a default 'make distclean; make': * * * [..] Compiling fltk3gl/glut_font.cxx... /usr/bin/ar cr ../lib/libfltk3gl.a ... Compiling fltk3images/BMPImage.cxx... Compiling fltk3images/FileIcon2.cxx... Compiling fltk3images/GIFImage.cxx... Compiling fltk3images/HelpDialog.cxx... Compiling fltk3images/images_core.cxx... Compiling fltk3images/JPEGImage.cxx... Compiling fltk3images/PNGImage.cxx... Compiling fltk3images/PNMImage.cxx... /usr/bin/ar cr ../lib/libfltk3images.a ... Compiling fltk3png/png.c... fltk3png/png.c:14:21: error: pngpriv.h: No such file or directory fltk3png/png.c:17: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Your_png_h_is_not_version_1_5_10' fltk3png/png.c:559: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PNGAPI' fltk3png/png.c:649: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PNGAPI' fltk3png/png.c:680: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PNGAPI' fltk3png/png.c:687: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PNGAPI' fltk3png/png.c:695: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PNGAPI' fltk3png/png.c:762: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PNGAPI' make[1]: *** [fltk3png/png.o] Error 1 make: *** [all] Error 1 * * * I turned off .SILENT so as to see the build flags: * * * === making src === make[1]: Entering directory `/usr/local/src/fltk-3.0/src' echo Compiling fltk3png/png.c... Compiling fltk3png/png.c... gcc -I../include -Os -Wall -Wunused -Wno-format-y2k -fno-exceptions -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/usr/include/freetype2-c fltk3png/png.c -o fltk3png/png.o * * * Looks like -I../include/fltk3png might be needed to make that include resolve. I added that to the .c.o rule in makeinclude just to get past this error, but not sure what the right solution is. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 r9661 build errors on centos 5.6 x64
On 13.08.2012, at 22:10, Ian MacArthur imacart...@gmail.com wrote: Yup, I think I reported that a while back; might even have flagged an STR now that I think of it... Um... 2833 is the one. Comments there please, I guess. Yes, now I remember. The crux appears to be that if you build fltk3 with the system PBG (etc.) libs the Makefile still tries to build the private PNG lib too, but on many systems the system PNG headers do not match (are older, in my case) than the fltk byult-ins and so compilation fails... Now, I tweaked the Makeinclude to do the right thing, so I guess we could make a similar change in the makeinclude.in and it would stay fixed. Or... maybe not. Actually, no. Some of the *.in files are written by Fluid. It needs to be changed in fluid/file_make.cxx - Matthias ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] simple threads example
On 12.08.2012, at 23:43, Amadeus W.M. amadeu...@verizon.net wrote: I'm trying to create my first threaded application with fltk. I have two threads: one that produces stuff and the gui thread. For simplicity, the producer thread just generates random rectangles and tells the gui thread to draw them via Fl::awake(). See code below. The problem is I have to put the producer thread to sleep() for a few seconds right at the beginning of the thread function, to allow for everything else to get going. See makeRectangles() below. I imagine this is not the proper way to make sure all threads have started, so what's the right way? Also, the threads.cxx example from fltk-1.1 locks/unlocks in the producer thread, but that's because it adds rows to the browsers. I'm not accessing any fltk widgets, so I don't have to lock, is that correct? Finally, there seems to be another way of drawing from a non-gui thread in the gui thread, using Fl::add_fd(), as explained here: http://www.angelfire.com/linux/tzptech/fltk/fltk-mt.pdf Is this what Fl::awake() does behind the scenes? FLTK is aware of threads and offers sufficient support. There are a few things that you can't do in threads, not because FLTK does not want to, but because the OS or libraries that FLTK uses, don;t allow that. You can't create or delete windows in a thread and you can't call Fl::wait(), Fl:flush(), or Fl::run(). This implies that you can not call Fl::message() and friends. But in your example, you are running into an entirely different limitation. If you want to draw things - not only in threads - it should be done within a virtual widget draw() function, derived from another widget. This is important, because the OS tells FLTK when it is a good time to draw. FLTK will then set the environment so that drawings will be sent to the correct window with the correct coordinates, color, patterns, etc. . There are two ways around this limitation. I have not tested them in threads, but they doe work in non-threaded apps. There is a good chance that they will work here, too: 1: use an offscreen buffer. Create an offscreen buffer using f;_create_offscreen(). Then, whenever your thread wants to draw something, use lock(), fl_begin_offscreen(), draw, the fl_end_offscreen(), and unlock(). Then have the main thread copy the offscreen buffer into the main window during a draw(). 2: use Fl_Window::make_current(). As above, use lock(), make_current(), draw, unlock() Please not the begin_offscreen and make_current are relatively expensive calls. Using those to draw a single rectangle is probably not very efficient. The recommended way to write you app would be to use the thread to calculate the rectangles, and use a derived class with its own draw() function to draw the rectangles from within the main thread. That implies that you need to store the location and color of rectangles in a way that both threads an access them without conflict. - Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk3 and connect()
On 13.08.2012, at 19:06, w. szukalski szukw...@arcor.de wrote: The program connect() in the test directory of FLTK3 seems to have flaws. Can these be cured? winfried Sure. Please give me some more information. Which OS, which compiler and what did you test? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [OT] JPL C language coding standards..
On 13.08.2012, at 20:51, Greg Ercolano e...@seriss.com wrote: JPL's C language coding standards: http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf Many items some will find obvious, and some are specific to embedded hardware and real time hardware control. Still, and interesting read. 31 rules in approx. 18 pages. Interesting. However, I have seen the rule of never use heap memory been used in an FLTK program. Due to the nature of callbacks, this does not work. http://spinroot.com/p10/rule3.html Then again, JPL forbids callbacks and demands IPC instead. Phew. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk3 and connect()
On 13.08.2012, at 22:15, Greg Ercolano e...@seriss.com wrote: On 08/13/12 13:03, Ian MacArthur wrote: On 13 Aug 2012, at 18:06, w. szukalski wrote: The program connect() in the test directory of FLTK3 seems to have flaws. Can these be cured? Though as you know, fltk3 is still alpha, so the quickest way to cure them might be if you have working patches...! FWIW, the connect test program ran OK for me on centos 5.6 x86 once I got the latest FLTK 3 to build past that png error. OP needs to report platform specifics. Since it's complaining about internet URLs, I wonder if the issue is related to internet connectivity? fltk3connect lacks most error handling. It would help finding the issue at hand. At least fltk3connect prooves that it is relatively easy to add new libraries to FLTK3 using Fluid. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Position and get position of window
On 11.08.2012, at 18:56, Herman dokinc...@gmx.net wrote: What Greg meant is this (in your case, where you obviously have a pointer to a Fl_Window class): pWindow-x() pWindow-y() pWindow-w() pWindow-h() pWindow-position(x,y) pWindow-resize(x,y,w,h) Cheers, Herman On 08/11/2012 06:22 PM, Coder wrote: Than I get: error: request for member 'x' in 'window', which is of non-class type 'Fl_Window*'. And for the position(): error: request for member 'position' in 'window', which is of non-class type 'Fl_Window*'. In the original post, you mentioned that you do not want to do any C++ Class stuff. I am afraid that classes are the most basic concept of the C++ language. FLTK uses a subset of the capabilities of C++. Classes is one of them. You can solve a lot of user interface projects without deriving from a class - something that a lot of new C++ users seem to shy away from. However, you will not get around learning the basic concepts of classes. Please send us the source code that you have up until now and we will try to help you implementing what you need. If you are not at that point yet, I suggest you use the hello example from the FLTK source code as astarting point. - Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Building 1.0 for study
On 12.08.2012, at 02:01, Patrick patr...@spellingbeewinnars.org wrote: Hi Everyone I guess 1.0 does not get much use these days but the code base was only 17K lines of code back then. I would like to build it but I am getting errors. You will hit problems. One reason for continuous development is to adapt to new compilers and libraries. filename_list.cxx: In function ‘int filename_list(const char*, dirent***)’: filename_list.cxx:56:74: error: invalid conversion from ‘int (*)(const void*, const void*)’ to ‘int (*)(const dirent**, const dirent**)’ [-fpermissive] /usr/include/dirent.h:256:12: error: initializing argument 4 of ‘int scandir(const char*, dirent***, int (*)(const dirent*), int (*)(const dirent**, const dirent**))’ [-fpermissive] This is a quite common issue. The function scandir is defined differently on different systems. FLTK 1.3 takes care of that for you. - Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] ipad?
On 07.08.2012, at 13:49, MacArthur, Ian (SELEX GALILEO, UK) ian.macart...@selexgalileo.com wrote: The simplest way to get FLTK working on modern day mobile devices would be to write a new back-end for MoSync (see: http://www.mosync.com/). The MoSync C/C++ API has everything FLTK needs - basic drawing primatives, event handling etc. I'm currently using it to make SmallBASIC run on android. Harking back to MoSync, I wonder if fltk's modified LGPL would be compatible with their GPLv2 requirement for free use? MoSync really does look interesting. The license is no problem at all since we would only use MoSync as a tool and use their API as a socket. I will look further into that. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] ipad?
On 04.08.2012, at 14:15, Ian MacArthur imacart...@gmail.com wrote: Oh yes - me too! I'd love that. Not sure Apple will go for it though App Store Review Guidelines from 2010, excerpt. I believe they went more strict, but I don;t have dev access anymore... . 10. User interface • 10.1 Apps must comply with all terms and conditions explained in the Apple iPhone Human Interface Guidelines and the Apple iPad Human Interface Guidelines ?? For FLTK, this would currently be hard to achieve. • 10.3 Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple iPhone Human Interface Guidelines and the Apple iPad Human Interface Guidelines may be rejected May be rejected. So if FLTK annoys Apple, they could ban our users. • 10.6 Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good it may be rejected Of course, all FLTK user interfaces are fantastic... . I have spent a few sleepless nights on this a while ago. Not sure if I publishd this before, but here are my thoughts: FLTK needs almost no OS resources to run! At the minimum, FLTK needs a way to wait for an event (sleep, timer), some kind of input, like a touch screen or a bunch of buttons, and some array of pixels. Almost all other functionality is derived from these four basic functions: - sleep until event - timer - read some keyboard and/or positioner device - set a single pixel to some color 1: These functions are all available on the simplest graphics devices, even with NO OS available at all! This is enough to run a single app in a single window. Find a Microcontroller with one 512k or ROM and 200k of RAM and you can run a graphical FLTK app already ;-) 2: Assuming we can set up a driver system for Fl_Windows, just as we did for drawing, we could allow multiple windows, managed by the app, not requiring a window manager on the host. Think about running FLTK apps on a Raspberry using only the BIOS - no need to load Linux. Embedded development on very small devices ;-) 3: Now if we have an OS available, and the ability to fork and to do interprocess communications. With a setup as above, FLTK could provide a window manager (Bill wrote one ages ago) *and* the application interface. So after all this theory: if we write the code needed to reach (1), we can port FLTK easily to any platform available, as long as we can find those four minimal interfaces! My example would be running on Android. Android requires apps to be in Java (up until Android 4, IIRC), but Java can call native libraries. A minimal Java app would provide the four interfaces discussed above, and the FLTK app would be wrapped together with FLTK itself inside a native library, called from Java. In true FLTK fashion, the app programmer would never touch a single line of Java code. The same would work for iOS, or PalmOS, or PocketWindows, or whatever else is out there. OT In other news - I recently acquired a brand new, still in the retail packaging, been sitting in a warehouse for over a year, Palm (aka HP) Pre3: Matt, any chance of an Einstein port, then? ;-) If you can run FLTK on it, you can run Einstein ;-P . ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Einstein, Newton
On 04.08.2012, at 17:39, Ian MacArthur imacart...@gmail.com wrote: OT In other news - I recently acquired a brand new, still in the retail packaging, been sitting in a warehouse for over a year, Palm (aka HP) Pre3: Matt, any chance of an Einstein port, then? ;-) If you can run FLTK on it, you can run Einstein ;-P . Sure, if I can run FLTK... the crunch here being whether or not I can be bothered to do the porting work, rather than just having it magically appear... I'm thinking maybe not, not right now... Ah, but there is a much more challenging option: the Newton ROM comes with all C and decorated C++ function names (the Driver Developer Kit has a ROM with all debug information). Knowing the API, it would be much more fun to natively implement NewtonOS instead of emulating it. It's only 3.5 MBytes of ARM assembler code that need to be rewritten... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [MOD] STR #2864: FLTK 1.3.0 does not compile under Mac OSX Mountain Lion
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2864 Version: 1.3.0 Fix Version: 1.3-current (r9649) In 3.0.0, I did this for listing files: #ifndef HAVE_SCANDIR // This version is when we define our own scandir int n = fl_scandir(dirloc, list, 0, sort); #elif defined(HAVE_SCANDIR_POSIX) !defined(__APPLE__) // POSIX (2008) defines the comparison function like this: int n = scandir(dirloc, list, 0, (int(*)(const dirent **, const dirent **))sort); #elif defined(__osf__) // OSF, DU 4.0x int n = scandir(dirloc, list, 0, (int(*)(dirent **, dirent **))sort); #elif defined(_AIX) // AIX is almost standard... int n = scandir(dirloc, list, 0, (int(*)(void*, void*))sort); #elif defined(__sgi) int n = scandir(dirloc, list, 0, sort); #elif defined(__APPLE__) # if MAC_OS_X_VERSION_MAX_ALLOWED = MAC_OS_X_VERSION_10_8 int n = scandir(dirloc, list, 0, (int(*)(const struct dirent**,const struct dirent**))sort); # else int n = scandir(dirloc, list, 0, (int(*)(const void*,const void*))sort); # endif #else // The vast majority of UNIX systems want the sort function to have this // prototype, most likely so that it can be passed to qsort without any // changes: int n = scandir(dirloc, list, 0, (int(*)(const void*,const void*))sort); #endif #ifndef __APPLE__ free(dirloc); #endif Link: http://www.fltk.org/str.php?L2864 Version: 1.3.0 Fix Version: 1.3-current (r9649) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2864: FLTK 1.3.0 does not compile under Mac OSX Mountain Lion
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2864 Version: 1.3.0 Fix Version: 1.3-current (r9649) Ah, no, my soution does not work for Lion and earlier anymore. Manolo to the rescue? Link: http://www.fltk.org/str.php?L2864 Version: 1.3.0 Fix Version: 1.3-current (r9649) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2865: Missing X11 headers from SRC zip (Visual Studio 2010 builds)
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2865 Version: 1.3.0 Fix Version: None X11 is the graphics library in Unix/Linux and the mentioned files are part of the Linux developer files. If you are on a Linux machine, please read the README file and do: sudo apt-get install g++ sudo apt-get install gdb sudo apt-get install subversion sudo apt-get install autoconf sudo apt-get install libx11-dev sudo apt-get install libglu1-mesa-dev If you are not on Linux, or the above does not fix it, please use the mailing list/newsgroup fltk.general for direct and quick support. Thanks. Link: http://www.fltk.org/str.php?L2865 Version: 1.3.0 Fix Version: None ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] fltk-3 fluid mods broken on mingw?
Weird! It works here. I knew the change was too big ;-) On 03.08.2012, at 10:57, MacArthur, Ian (SELEX GALILEO, UK) ian.macart...@selexgalileo.com wrote: Matt, I got this from my recent build: Compiling Fl_Type.cxx... In file included from ../include/fltk3/Browser.h:38:0, from WidgetBrowser.h:32, from Fl_Type.cxx:45: ../include/fltk3/Browser_.h: In destructor 'virtual Fl_Type::~Fl_Type()': ../include/fltk3/Browser_.h:174:10: error: 'void fltk3::Browser_::deleting(void*)' is protected Fl_Type.cxx:482:52: error: within this context In file included from ../include/fltk3/Browser.h:38:0, from WidgetBrowser.h:32, from Fl_Type.cxx:45: ../include/fltk3/Browser_.h: In member function 'void Fl_Type::move_before(Fl_Type*)': ../include/fltk3/Browser_.h:177:10: error: 'void fltk3::Browser_::inserting(void*, void*)' is protected Fl_Type.cxx:534:36: error: within this context make[1]: *** [Fl_Type.o] Error 1 make: *** [all] Error 1 ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-3 fluid mods broken on mingw?
Seems to work now. It was a namespace issue. On 03.08.2012, at 13:50, MacArthur, Ian (SELEX GALILEO, UK) ian.macart...@selexgalileo.com wrote: Weird! It works here. I knew the change was too big ;-) Well, FWIW, it fails if I build with mingw gcc-4.7.0 but is OK with mingw gcc-3.4.2... Also, I can't seem to egt through to Jenkins to see what it thinks about things! Cheers, -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FL_Tree horizontal scrollbar?
On 03.08.2012, at 20:45, Cliff Yapp cliffy...@gmail.com wrote: On 08/03/12 09:26, Greg Ercolano wrote: On 08/03/12 06:24, Cliff Yapp wrote: What do devs currently do to work around the lack of a horizontal scrollbar when trees get too deep? BTW, one way to work around this is to make the tree resizable with a splitter. So if you have a typical situation where the tree is on the left and a viewer of some kind on the right, you can put both into an Fl_Tile, such that they abut. Then the user can horizontally resize the tree by gliding over the splitter between them to resize the tree larger while shrinking the viewer Awesome! (Amusingly, I think that's the current workaround for Tk's ttk tree widget as well.) That's a resize ability we'd probably want to allow even with the horizontal scrollbar available, so that's how we'd want to set it up regardless. Have you guys tried to simply put it inside an Fl_Scroll? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Term license?
On 03.08.2012, at 22:48, Ian MacArthur imacart...@gmail.com wrote: On 3 Aug 2012, at 20:46, Greg Ercolano wrote: On 08/03/12 12:31, Cliff Yapp wrote: In looking around at available FLTK widgets, I came across this page: http://www.9edgedown.talktalk.net/flterm.html Pretty sure this is Ian MacArthur's work.. He's still active on the list, so I'm sure he can weigh in. Yes, I did that as a hack way back when, but no work has been done on it since. I've PM'd the OP (Cliff Yapp) saying basically he can use the code if he likes; I posted it on the web with no explicit license, which in retrospect was a mistake I guess. Anyway, I guess I had the fltk license in mind, though if CY wants the use of the flterm code then he's basically welcome to it. If I had more time, I'd probably be all over this project, as working on vt100 emulation (and xterm) has always been an interest since my early days, but never had the time to follow through. Yup. me too... Like a lot of projects, I worked on it until it *nearly* worked the way I wanted then lost interest...! FLTK2 has an ANSI widget. OK, it's by no means an XTerm, but there may be some overlap?! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Term license?
On 03.08.2012, at 23:20, Cliff Yapp cliffy...@gmail.com wrote: Since you guys are knowledgeable about terminal emulation issues, I'd be curious if you have a sense on how hard it would be to implement (using FTGL + GTerm's core functionality + whatever additional bits make sense) an actual cross-platform terminal emulator that would (say) allow console emacs and vim to operate on Windows platforms the same way they do on Linux/BSD/OSX? The only open source Windows terminal emulator I know of is the one built into cygwin - cygwin is a) a very big dependency to require if you're just after one or two apps and b) GPL, which unfortunately doesn't work in some situations (like mine). In some sense, that would be one of my primary interests in Fl_Term - whether it can serve as a standardized terminal emulator on Windows, Linux/BSD, and OSX that provides a cross platform for apps needing a terminal... but I don't know what would be involved in emulating that on Windows... Oh boy! For a terminal emulation, you need io streams (stdin, stdout, stderr), and means of asynchronous notifications. On Unix, that would be signal() to tell the client that the window size changed, for example, and ioctl(), so the client can control the terminal (receive current window size, for example, but much MUCH more). The ANSI simulation is the simpelest part in comparison. So for vi to work, you need to implement a device drive that simulates a TTY. Unix makes that relatively simply by providing pseudo terminals. MSWindows has few of these things. I am quite sure that this is possible, but it is not simple. I would love to have a widget like that, but, as Ian said, it should never be part of the core library. - Matthias ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Stability of Fl_Menu_Bar::find_item(const char*pathname)
On 03.08.2012, at 19:39, David FLEURY dfleu...@free.fr wrote: IMHO best practice is to use FLUID. You can assign variable names to each menu item and use thos later to change labels or shortcut, query values, anything you need. It seems, is it not possible to have these variables names available directly in the Fl_Menu_Bar for example ? No. C++ can not provide this kind of interface (assuming I understand you right). In FLTK3, MenuItems will be regular widgets, just like everything else. Adding a menu item will not change the address of any other item. This code will be copied from FLTK2. If you are in a hurry and willing to try FLTK3, I will give these menu style a high priority... ;-) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] ipad?
On 04.08.2012, at 03:39, Greg Ercolano e...@seriss.com wrote: So what the hell, I thought I'd ask. FLTK on the ipad -- is that even possible? Anyone tried? I know Apple has some kind of rule outlawing graphics libraries like FLTK for ipad/iphones, but perhaps someone has at least tried and failed..? Yes, technically that is not a big issue. iOS is quite similar in some respect to the OS X interface. We ported the Newton emulator Einstein from OS X to iOS in a relatively short time. I considered this for FLTK, but Apple would not allow you to publish anything with FLTK. They insist that you use their UI libraries. It's not always enforced (games often come with their own UI), but I have never seen a UI library offered. The Newton emulator btw was also kicked out of the Apple store before it ever saw the light of day. It's now available via Cydia for hacked devices - very disappointing. Actually, so disappointing for me, I sold my iPone and iPad and moved to Android/Samsung. - Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [fltk.commit] [Library] r9646 - in branches/branch-3.0: include/fltk src/fltk3
On 27.07.2012, at 15:14, Michael Sweet wrote: I'd recommend against providing strcasecmp and strncasecmp functions in the library - too much chance for name collisions from other projects, instead define fltk-prefixed versions or go back to defining strcasecmp to stricmp, etc. Sent from my iPad Yes, you may be right. I will think about this and probably fix it when I have a better internet connection. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-3 build broken on linux and winXX
On 25.07.2012, at 15:27, MacArthur, Ian (SELEX GALILEO, UK) wrote: I notice that the fltk3 build is currently borked on linux and winXX: For example, from a Win32/Msys/mingw build I get: $ make === making src === Compiling fltk3/CheckBrowser.cxx... In file included from ../include/fltk3/run.h:39:0, from ../include/fltk3/CheckBrowser.h:34, from fltk3/CheckBrowser.cxx:32: ../include/fltk3/utf8.h:190:20: error: expected primary-expression before 'const' ../include/fltk3/utf8.h:190:20: error: expected ')' before 'const' ../include/fltk3/utf8.h:193:20: error: expected primary-expression before 'const' ../include/fltk3/utf8.h:193:20: error: expected ')' before 'const' make[1]: *** [fltk3/CheckBrowser.o] Error 1 make: *** [all] Error 1 Also, looking at Jenkins, I notice that the OSX MacBook target is offline. I guess Matt took it on his travels with him! :-) Ahh, the MacBook probably barfed. I can't reach it ATM though. Hmm, is there something wrong about the 'const'? Is it a newer C dialect? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] fltk-11,fltk-13,fltk-20 and fltk-30
On 22.07.2012, at 23:57, Ian MacArthur wrote: If it helps, there are a fair number of native German-spaeakers on this list (though I'm not one of them!) so if that's a better option for you, it might allow for a clearer description of the issue to be created? Ja, schreib's ruhig auf deutsch. Zu 1: Butons sehen ein wenig unterschiedlich aus in den verschiedenen FLTK versionen. Was benutzt Du denn für ein Symbol oder Text im Button? Zu 2: das hängt davon ab, wie Du die Bildrate im PLayer konstant hältst, also Thread, timer, callback, oder wie? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Sys_Menu_Bar: About.. screen
/** * \brief Attaches a callback to the About myprog item of the system application menu. * * \param cb a callback that will be called by About myprog menu item * with NULL 1st argument. * \param user_data a pointer transmitted as 2nd argument to the callback. * \param shortcutoptional shortcut to attach to the About myprog menu item (e.g., FL_META+'a') */ extern void fl_mac_set_about( Fl_Callback *cb, void *user_data, int shortcut = 0); On 23.07.2012, at 10:31, MacArthur, Ian (SELEX GALILEO, UK) wrote: I've not used Fl_Sys_Menu_Bar before, and have a question. On macs, how does the app take control of the default Appname/About menu in the Fl_Sys_Menu_Bar? The Sudoku test program has a similar problem to my app in that there ends up being two About menu items that are different: 1) A default one under sudoku/About 2) Another one under Help/About Sudoku #2 is the one that the Sudoku app has populated with data, but the one most Apple users will click on is #1 which shows little info. Is there a way to take control of #1 in a portable way? It'd be good if we could just hook the Mac About with a function pointer and userdata. I'm pretty sure Manolo had set it up in sort of that way - I think I even used it... but that code is elsewhere right now... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] How to swtich between two interface?
Please reduce the xode to the bare minimum and post it here. I won't be available for a while. kaixuan306 csu.gao...@gmail.com schrieb: Not using a timeout will alraedy reduce lag. For everything else you need t= o send some code that i can compile, and where i can see what's using up th= e time. kaixuan306 csu.gao...@gmail.com schrieb: hello,everyone. = Now I am using fltk 1.3.0 and nano-x,nxlib to develop program to wor= k on ep9315 arm linux system. I have solve the problem about the font. Now= I commit a new difficulty: (1): there are many keys(array) on my ep9315= board, now I detect the key push by query in add_timeout's callback funti= on. I fint that in fltk there are key event, my problem is how to use the = key event to detect the key push. my key's ascall code is the same as PC. = (2):when I push one key such as 1, I want to display some widgets, wh= en push another key such as 2, to display another group of widgets, no= w I build some groups of widgets by Fl_Group, such as group1 and group2, p= ush key1, to display group1 and push key2, to display group2.But it se= ems that the LCD screen of EP9315 update is a little slow. Is there any go= od idea to realize this? Thank you very much for reply,I will have a try. = But for the second question, some suggestion? ___= fltk mailing list fltk@easysw.com http://lists.easy= sw.com/mailman/listinfo/fltk It is very nice of you, could you give me your email?The code is too long to paste here? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Run-Time Check Failure #0
It seems like you have mixed multiple versions of FLTK. Did you previously install a different version? Also, fltk 1.1 is rather old. I suggest that you use fltk 1.3 which comes with better VisualC support and many new features. Simon simon.ha...@gmx.de schrieb: Dear all! I build FLTK 1.1 in Visual Studio 2010 and used Debug. After building FLTK I tried to start fluid but I get the following error: Debug Error! Tools\FLTK_bin\bin\Debug\fluid.exe File: \fltk 1.1\src\sceen_xywh.cxx Line 59 Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention. Could you pleade help me? With best regards Simon ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] How to swtich between two interface?
Not using a timeout will alraedy reduce lag. For everything else you need to send some code that i can compile, and where i can see what's using up the time. kaixuan306 csu.gao...@gmail.com schrieb: hello,everyone. Now I am using fltk 1.3.0 and nano-x,nxlib to develop program to work on ep9315 arm linux system. I have solve the problem about the font. Now I commit a new difficulty: (1): there are many keys(array) on my ep9315 board, now I detect the key push by query in add_timeout's callback funtion. I fint that in fltk there are key event, my problem is how to use the key event to detect the key push. my key's ascall code is the same as PC. (2):when I push one key such as 1, I want to display some widgets, when push another key such as 2, to display another group of widgets, now I build some groups of widgets by Fl_Group, such as group1 and group2, push key1, to display group1 and push key2, to display group2.But it seems that the LCD screen of EP9315 update is a little slow. Is there any good idea to realize this? Thank you very much for reply,I will have a try. But for the second question, some suggestion? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Performance problem with FLTK 1.3.0 ??
It seems to me like your event management is somehow messed up. This is either in your code, or somewhere in the x11 server that you are using. It would help tremendously if you could sen us some minimal code which exhibits the bad behavior which we can compile and test. If the problem can be fixed by adding Fl::flush() calls after changes in th UI, then one of the reasons above os to blame. Jayaram jayara...@in.bosch.com schrieb: On 07/18/12 04:39, Jayaram wrote: DQo+IEnigJltIHJ1bm5pbmcgdGhlc2Ugb24gYW4gYXJtIHRhcmdldC4gVGhlIGRlbGF5IGFtIHNl ZWluZyBpcyBpbiBnZW5lcmFsIHdpdGgNCj4gcmVuZGVyaW5nIHdpbmRvd3MgYW5kIHRleHQuDQo+ IEkgdXNlZCBGTFRLIDEuMS43IHdpdGggdGhlIGxhdGVzdCBOYW5vLVggYW5kIE54bGliIGFuZCBm [..] Hi Ian , This message is not readable. Can you post this message again I can read Ian's message via the NNTP interface to the group, so I'm posting a copy as clear text below. Indeed, his message looks entirely like encrypted text if I hit 'View Source'; it appears that message is in Microsoft's TNEF format, which many interfaces to the group probably can't decode properly. Another message he wrote 10 minutes earlier was clear text, so it appears to be something his MS mail reader is doing specific with that one message. Anyway, here's what he wrote in reply to your msg: * * * I���m running these on an arm target. The delay am seeing is in general with rendering windows and text. I used FLTK 1.1.7 with the latest Nano-X and Nxlib and found the performance to be the same as when I was using FLTK1.1.7 + Nano-X0.92 + Nxlib 0.45. This would eliminate Nano-X and Nxlib as being the problem area wouldn���t it ? I'm not sure it does - though also see Micha's post (and my response) about the behaviour of the IM system, and fltk's interaction with it, in the 1.3.x series. WHat he proposes may be a credible workaround for you, if that is the problem. I'm assuming that in your embedded target the IM probably is not useful to you? But then, you may be entering complex scripted languages, so maybe you do need the IM to work? But with FLTK 1.3.0 and latest Nano-X, Nxlib delay seems to be considerable especially in windows where a sizeable amount of utf-8 text need to be rendered. If it depends on the amount of text to be rendered, it maybe NOT the IM problem then... This really sounds more like a rendering issue perhaps? Do you have any metrics for how fast your Nano-x system is rendering text? Can you run a kdrive-style X server on your target for comparison and see how that compares to Nano-x for performance? I have disabled xft and don���t have any problem displaying utf-8 characters except the delay issue am seeing. Would enabling Xft and using a ttf font make any difference ? I doubt that XFT with a TTF font would render faster than a simple Xlib bitmap font, though I may well be wrong. I much prefer XFT, but because it looks better, not because it is faster! There is a fair bit of logic in fltk to try and cope with unicode text in a simple Xlib context so there shouldn't be any need to use XFT to get unicode fonts rendered. With respect to performance am seeing this behavior (not quite sure how i can explain this behavior). So am using FLTK+Nano-X+Nxlib on an Arm target with a touch screen dislay. On the press of a button on the touch screen i populate some random text in a FL_Box. I pres the button and take my hands away from the screen there is a delay for the information box to appear and the text to be displayed. But after pressing the button, if i keep it pressed on the touch screen, the box appears a lot quicker and text is displayed. Am unable to understand the reason for this behavior !! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] How to swtich between two interface?
On 19.07.2012, at 08:33, kaixuan306 wrote: hello,everyone. Now I am using fltk 1.3.0 and nano-x,nxlib to develop program to work on ep9315 arm linux system. I have solve the problem about the font. Now I commit a new difficulty: (1): there are many keys(array) on my ep9315 board, now I detect the key push by query in add_timeout's callback funtion. I fint that in fltk there are key event, my problem is how to use the key event to detect the key push. my key's ascall code is the same as PC. (2):when I push one key such as 1, I want to display some widgets, when push another key such as 2, to display another group of widgets, now I build some groups of widgets by Fl_Group, such as group1 and group2, push key1, to display group1 and push key2, to display group2.But it seems that the LCD screen of EP9315 update is a little slow. Is there any good idea to realize this? Using a timer is not efficient at all. Instead, use either the handler for urecognized events: http://www.fltk.org/doc-1.3/group__fl__events.html#gae2d39bda7362e444afa41166c478b904 This handler is called after all other handlers were tried. If no widget is interested in the keystroke, it should end up here. OR: use the first event handler of them all: event_dispatch http://www.fltk.org/doc-1.3/group__fl__events.html#gafc8bd62d8fdacef87c56ed3a22cdcebc This handler receives events *before* any widget does. If you use '1' and '2' as keys, no other widget will ever receive a '1' or '2' keystroke. OR : this is probably the best solution: derive your own class from Fl_Window and write a new handle(int) function. http://www.fltk.org/doc-1.3/classFl__Window.html#a9c0eb1c55a1a62ef3d3d87676f936187 - Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] How to swtich between two interface?
On 19.07.2012, at 11:08, MacArthur, Ian (SELEX GALILEO, UK) wrote: See Matt's detailed reply, but along with that, I *very strongly* suggest you spend some time playing around with fltk on your desktop system, get a proper feel for how the widgets behave and experiment with the handle() methods and how the events are propagated. It is a lot easier to do these tests on the desktop system, and so much easier to debug and to understand where things are going awry. Then, once you have that and can make a demo prototype of the GUI you plan to put on your embedded target, it will be much easier to create the code for the real system, and the design you cerate at that stage will be more robust and correct as it will benefit from the experience gained whilst doing the desktop testing. I second that. This is one of the great benefits of FLTK: you can write your app on the desktop, test it, debug it, and then later compile it for another machine, usually without any changes. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Some confusion pertaining to Fl_Menu_Bar and Fl_Menu_Items
On 18.07.2012, at 11:29, M3taSpl0it wrote: Quote from fltk 1.3.0 , 30.77.2.4 : **int Fl Menu Item::add ( const char mytext, int sc, Fl_Callback cb, void data = 0, int myflags = 0 ) Adds an item. The text is split at ’/’ characters to automatically produce submenus (actually a totally unnecessary feature as you can now add submenu titles directly by setting SUBMENU in the flags)** As you can see fltk documentation calls '/' actually a totally unnecessary feature. Can you explain me above para in easy word and how does SUBMENU (did he mean FL_SUBMENU ? ) in flags does that? Well, the documentation is written by many people, who may have entirely different ideas on what is useful and what not. If you like the '/' feature, by all means, use it. Also I could'nt understand what's use of flag FL_SUBMENU_POINTER? . Please teach with an easy example? Fl_Menu_Item is a construct that is very different to the rest of FLTK. It only exists in this way for compatibility with Forms. A complete pulldown menu hierarchy can be created using a single array. Submenus (and susb-sub menus, etc.) are started by marking a menu item with FL_SUBMENU. All following menu items will be part of the submenu until a menu item with a NULL label appears. But sometimes, it is better to hold submenus in their own array. This can be done by using FL_SUBMENU_POINTER. User_data() then points to another array with the submenu. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Performance problem with FLTK 1.3.0 ??
On 17.07.2012, at 16:33, darren legge wrote: I am using Xfbdev (tinyx / kdrive) on an arm target and am just moving an fltk 1.1.7 application to fltk 1.3, using utf8 and pcf fonts. For me, the speed of drawing is not perceptibly different so maybe the slowness you see is a nanoX issue. My issue is the time it takes the fltk application to start up the first time after boot - 37 seconds ! If I re-compile fltk to not use xft then it starts much quicker (4 seconds) but utf8 characters do not show correctly. I thought xft was just anti-aliasing (which won't work with pcf fonts anyway). It seems xft is required for utf8 to work though - is this true ? I can reduce the startup time by removing some fonts but even with just a couple of chinese fonts the startup time is the wrong side of 10 seconds. Is there a trick to improve this - can fltk somehow cache the fonts it is scanning over a reboot ? Hmm, that is too long. 34 seconds. In the OS X implementation, FLTK loads only the characters that are actually needed. It used to load pages of characters (1024, IIRC), but that would delay a popup menu for three seconds the first time it opened (OSX uses special characters in popup menus). By caching single characters, the delay became unnoticeable. Maybe this can be ported to X/Xft? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Performance problem with FLTK 1.3.0 ??
On 16.07.2012, at 15:43, Jayaram wrote: I was using FLTK 1.1.7 with Nano-X 0.91 and nxlib 0.45. I upgraded these to FLTK 1.3.0, Nano-X and Nxlib to the latest development head to add utf-8 support. I see that there is a degradation of performance in displaying screens on the same target that I was running the earlier versions on. I am using pcf font files. Is the newer fltk slower with the utf-8 support added ? FLTK 1.3 uses larger data types for some basic variables. Graphics coordinates are now 32 instead of 16 bits. UTF8 rendering should not have any impact for ASCII text. Only when massive amounts of glyphs are required for large fonts, initialisation may be slower than usual. There is one additional indirection for all graphics calls, but that is in todays CPU terms close to nothing. In return we get multiple rendering contexts, including printing. Other than that , the code is very similar. Can you specify what exactly seems slower now than it has been? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Hex dump png files
On 13.07.2012, at 01:28, Greg Ercolano wrote: I added a little example to the cheat page to show how to use Fl_PNG_Image to output PNG pixel data in C/C++ readable hex format: http://seriss.com/people/erco/fltk/#Fl_PNG_Hex_Dump I find it often useful to 'inline' PNG files into apps for the same reason .pixmaps are useful, only PNGs are great in that they handle 8bit alpha, useful for smooth overlays. I always find it a nuisance to have to look around for ways to get a hexdump of pixel data, so having this kinda saves the trouble. Can probably be easily modified to support all the FLTK image formats, but I almost always find myself working with PNGs when it comes to images containing transparency. Starting with FLTK 1.3 (svn?), Fluid has a new type that allows to store arbitrary files as binary data in C source code. It's in New - Code - Binary Data. Enter any filename, and a binary dump will appear in the source code. By assigning a variable name, the data can then be read using Fl_PNG_Image *img = new Fl_PNG_Image(someName, myBinaryData, sizeof(myBinaryData)); This is also supported for Fl_JPEG_Image. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] No internationalization in Fluid - generated menus in fltk- 1.3
On 13.07.2012, at 17:09, Roman Kantor wrote:
I am not sure if it is a bug or something changed in fltk-1.3
If I design window as a widget class in fluid, it generates a static menu
like
Fl_Menu_Item My_Window:menu_ctl[] = {
{File, ... }
}
instead of
Fl_Menu_Item My_Window:menu_ctl[] = {
{_(File), ... }
}
as it used to in fltk-1.1 if _() was set as a gettext function. Is that a
regression/bug or did something change in fltk-1.3?
Also in fltk-1.3 there is newly an additional widget constructor generated
which uses w() and h() and label from fluid entries, this constructor would
be very
useful, unfortunately it disregards internalization settings too...
Shall I fill an STR?
Well, in C++ there is no predefined order in which static variables are
initialized. Both, MenuItems and i18n use static initialization. So it used to
be a hit-or-miss situation if menu items were internationalized or not. This is
why i18n for menu items must be done manually to be reliable (IIRC, we have
added a function for just that somewhere - but I don't know where anymore).
In FLTK 2 and soon in FLTK 3, Menu Items will be derived from Widgets and
initialized the same way as all widgets, making them fully compatible with i18n
(and many more FLTK features, removing the Fl_Menu_Item special case).
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] How to create a hyperlink in about window ?
On 13.07.2012, at 23:42, Greg Ercolano wrote: On 07/13/12 13:41, Furqan wrote: I want to create a hyperlink of my website link in my about window which is created by fl_double_window. how can I do that ? Info-add(@C1 - ); Info-add( http://www.real3d.pk;); Info-add(@C1 - ); Use Fl_Help_View with your URL. Or create a regular button, set the box type to FLAT, set the text color to Blue, and in the callback, call fl_open_uri(http://www.fltk.org;); ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] No internationalization in Fluid - generated menus in fltk- 1.3
On 14.07.2012, at 01:03, Roman Kantor wrote: PS: Sorry for the rant, but I feel quite frustrated and I do not know what to do - maybe I will use fluid from 1.1 but I am little bit worried that mixing the two will bring compatibility problems ;( Understood. I only repeat what was given as a reason, and I do remember that someone had issues. To find out who changed this, use svn blame and ask that developer directly. He'll have the details. I have never used i18n, but I strongly believe that it should work for all aspects of FLTK. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK font rendering Problem
You need at least FLTK 1.3.0 to render UTF-8. Also, as Nikita said, some
compilers do not like UTF-8, so make sure that yours does . Last but not least,
right-to-left scripts do not always render correctly on all platforms. There is
not much FLTK can do about it, but we have added a function that may help you:
void rtl_draw(const char* str, int n, int x, int y)
That would look something like this:
#include FL/Fl_Box.h
#include FL/draw.h
class RTLBox : public Fl_Box
{
public:
RTLBox(int x, int y, int w, int h, const char *l=0)
: Fl_Box(x, y, w, h, l) { }
void draw() {
draw_box();
rtl_draw(label(), strlen(label()), x(), y()+h()/2);
}
};
...and then the rest of your code, using RTLBox instead of Fl_Box.
Let me know if that worked. Also, a screenshot would be very helpful.
On 10.07.2012, at 09:34, Nikita Egorov wrote:
Hi. First, what are your OS and compiler/IDE?
I need to display the hindi word हिंदी in a Fl_Box label. That hindi word
gets altered while displaying.
Fl_Double_Window* make_window() {
Fl_Double_Window* w;
{
Fl_Double_Window* o = new Fl_Double_Window(500, 500);
w = o;
{
Fl_Box *box = new Fl_Box(25, 25, 400, 400, हिंदी);
I think your problem is here ^
Many compilers don't like such UTF8 strings in text of program.
Try to use instead wide char string and convert it to UTF8 via some system
calls or via fl_utf8fromwc().
Simple example:
#include FL/fl_utf8.h
..
char dst[32];
fl_utf8fromwc(dst, 32, Lहिंदी, length_of_src);
Fl_Box *box = new Fl_Box(25, 25, 400, 400, dst);
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Paid FLTK improvement projects (under OS)?
On 09.07.2012, at 19:00, Greg Ercolano wrote: On 07/09/12 07:24, Roman Kantor wrote: I just like to ask if I can post here propositions for paid development of new/improved FLTK widgets - if not, please let me know ant I will stop post it here. Sounds cool to me. Perhaps adding '[JOB]' to the subject line would make it clear it's a commercial request; this is what I've seen in similar mailinglists/newsgroups. Sure. We have done two bounty hunts before, and they were a great success. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK on Mac OS X - Window Style Problem
On 04.07.2012, at 09:16, Herman wrote: I am currently trying to make an FLTK window on Mac OS X with rounded bottom corners. Unfortunately I have been unsuccessful so far. In both cases the resize strips in the lower right corner are drawn by FLTK and by the the OS which looks pretty ugly, since they are not drawn at exactly the same location. FLTK 1.3 stops drawing the resize patch for OS X Lion and above. I was not aware that Cocoa ever drew one for 10.6 and below? You can remove the drawing code in Fl_Window::draw(), assuming you are using FLTK 1.3. I am no Cocoa expert, but AFAIK it should be Cocoa that takes care of the rounded corners by clipping them away for any kind of drawing. FLTK should not be able to draw into that area. There would be another solution to initialize the window borderless and completely transparent and then do all the drawing and handling myself. Before I do that I would like to explore simpler alternatives. Transparent windows will be a feature of FLTK 3. But that does not solve you current problem. Does anybody of the MacOS X gurus here have any ideas what else I could try? Can it be done at all with FLTK? FLTK has no calls to change the way the borders of windows are drawn. You either must change the FLTK source code, or change the style afterwards using fl_xid, just as you did. I can;t say anyting for the Cocoa side of things as I am no expert there. Manolo? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.development] build farms and trade secrets
I found a great tool on the web that I wanted to use on my Mac. Unfortunately, the tool was only available for MSWindows. I contact the author and offered to convert the tool from .net to FLTK/C++. For various reasons, he declined. One issue was, that he does not have access to a Mac and could not compile a version for me. Well, easily fixed, I thought, and offered him to use my build farm. But now he would have to send the source to my build farm, which is obviously an issue for commercial projects. Searching for a solution, I came across this amazing tool: objconv. It takes object files that were compiled by one compiler and transcodes them into object files for another platform/compiler. For example, instead of sending the source code for myEncription.c to the build farm, one can build it on the local machine (OS X, Linux, or MSWindows, doesn't matter) and send the binary to the build farm. objconv then takes the object file and converts it into any other object file format where it can be linked into the executable. There are two limitations: the object file should come from C, not c++, and must be 32 bit Intel. Nevertheless, I find this tool absolutely genius. Thanks to Agner Fog for writing this smart piece of code. http://www.agner.org/optimize/?e=0#objconv - Matthias ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Bug in fl_offscreen() on X?
On 03.07.2012, at 18:24, fltk.orib wrote: Note that the usual place to create the offscreen is in a draw method, so the gc will always be valid in that case. Not sure what to do in your example though. Indeed, I'm actually using fltk for generating server side images (jpeg, bmp, png) for a backend. FLTK is really easy to use, and fits the bill perfectly. I'm using it on the client side for similar uses, so right now it is easier for me to run the server side with a virtual X framebuffer session (to provide the gc), then e.g. switch to gd. But I hope there's a way around it. I suspect getting rid of the X framebuffer requirements is going to be a problem, but I still hope. Which reminds me again of the render plugin that I wanted to write for RGB buffers - sigh ;-) never enough time. It's not very hard to do, but very handy, and it would solve your problem without relying on X11 (or any other UI for that matter). ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] FL_WHITE changed from 7 to 255?
I think that it is a mistake. Even though i show up using Blame. Makes no sense to me and should be xhanged back. It may have been a search/replace error. Greg Ercolano e...@seriss.com schrieb: Does anyone remember why FL_WHITE was changed from colormap #7 (fltk 1.1.x) to colormap #255 (in fltk 1.3.x)? Just curious. Seems this changed happened in STR#2208 but can't tell from the comments on the commit why it was done. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK - memory leaks
The /M flag must be changed for *all* linked modules. It must be the same in
each and every module that you link. If you change the flag, you must make sure
that FLTK and all other modules are build from scratch, or you will get exactly
the heap corruption that you described.
We chose the /M flag very carefully. It i set to multithreading with dll
support. IMHO the only correct setting if you want to do any kind of run-time
linking, or link with any dll at all.
On 30.06.2012, at 00:37, Mikhail Tchernychev wrote:
Here what I just did to reproduce:
Downloaded latest r9631;
Changed code generation to /MTd
for hello, fltkdll, fltkjpeg, fltkzlib, fltkpng
Explicitly changed it to /MTd for file jmemobs.c from JPEG
Changed project reference for hello to fltkdll
Removed fltkd.lib from link
changed subsystem for hello to console (if not, it expects
WinMain)
Compiled.
Now it runs. Added destructor. Now it crashes.
I used static linking at home and /MDd at home and I recall
it worked.
I hope it helps.
Best Regards,
Mikhail
Hmm, Mikhail, it works absolutely correctly without any errors on my system
(Windows Seven 64, VC2010 Express, Debug, latest svn rev 9631).
I'm afraid it's problem with your machine only. Which version of FLTK do you
use? Do you use something else? Be sure you don't mix headers and .lib files
from different versions of the library.
This is happens in Debug build. It's actually
Debug Assertion Failed showing that heap is
corrupted. Stack is not useful. Going step by step
I found that it happens after ~Fl_Window();
xclass in Fl_Window is set to NULL.
The program is here:
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Box.H
//#include vld.h
int main(int argc, char **argv) {
// Fl_Window window(340,180);;
Fl_Window *window = new Fl_Window(340,180);
Fl_Box *box = new Fl_Box(20,40,300,100,Hello, World!);
box-box(FL_UP_BOX);
box-labelfont(FL_BOLD+FL_ITALIC);
box-labelsize(36);
box-labeltype(FL_SHADOW_LABEL);
window-end();
window-show(argc, argv);
int ret = Fl::run();
delete window;
return 0;
}
Nikita Egorov
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
