Re: [fltk.development] C API experiment
Hi Sanel Thanks for responding to my post. Your ideas are terrific. I know a little about swig and pyFLTK but I didn't know anything about the other two options. So I have been going around it circles on and off for two years with GUI tookkits. I have tried virtually all of them now. I don't want to code in C/C++. I have been obsessed with Ada for about 15 months and the GUI options for it are horrible. Bindings for other languages are available but I couldn't figure out how to call back to and forth from Ada with them without somethign whacked liked using D-Bus. I have realized that pretty much everything I like about Ada is available from Cobol too and I have recently switched my focus. Open Cobol compiles to intermediate C. I was trying to figure out how to call back into C++ from C but then I finally realized I could just run the C code through a C++ compiler and have code at the same level as C++ and now I don't think I need to figure out a way to call up into C++. Having said that, I think that a C binding would really help the project and I would like to help, please let me know if I can. Thanks again-Patrick P.S have you tried chicken scheme? Is it suitable for you? You could also run it's intermediate C code through a C++ compiler and then you would be able to call into FLTK C++ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] C API experiment
Hi Albert I can start in C++ or Cobol but I have to be able to call back into C++ to change widget properties during callbacks. I am not proposing anything that would change FLTK itself, just a seperate wrapper. I don't like C++ but that does not mean it is not very useful, virtually every widget toolkit is written in it and the gobject world changes GTK into an object oriented language. Cobol 2002 supports object oriented programming , exceptions, user defined types etc but I don't think anyone has to worry about their C++ code being eclipsed by Cobol :) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] C API experiment
Hi Greg I seriously considered using X forms and read through the source. There is significant overlap between the two. I don't think it is viable for me though. Thanks again On 13-02-22 03:03 PM, Greg Ercolano wrote: On 02/22/13 06:46, Patrick wrote: Having said that, I think that a C binding would really help the project and I would like to help, please let me know if I can. IIRC, FLTK started as a C++ rewrite of C based xforms (and by extension, forms) xforms is still around: http://xforms-toolkit.org/ http://en.wikipedia.org/wiki/XForms_%28toolkit%29 So if you like FLTK but prefer a C interface, xforms will probably seem very familiar. I used to use xforms daily in the mid 90s until FLTK became solid, then I switched to FLTK and never looked back to C. ___ 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
[fltk.development] reworking examples folder
Greg's post reminded me of something I wanted to bring up. His examples here: http://seriss.com/people/erco/fltk/ Are really good, why are they not in the examples folder? In addition there are some really cheesey bitmaps in the test folder that came from X forms. Would anyone like me to find some nicer bitmaps? The test folder is still a tutorial source for people but some of it is butt ugly and might turn people away. -Patrick ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] reworking examples folder
Yes, something compatible with whatever we come up with for our examples (zlib license, etc) would be fine. I can also draw stuff if something custom is needed. I have an under utilized BFA in animation, which means I can draw silly things on the backs of scrap paper such as envelopes, paper bags, and art degrees, lol: http://seriss.com/people/erco/sketches/view-2010-2012.php http://seriss.com/people/erco/sketches/view-2003.php Actually the drawings are pretty good! your multi-talented :) I only use Linux but I would like to learn a little more about developing on Windows. Could you tell me where the necessary Visual Studio files are. Maybe I will try a suicide mission and give it a try in the next couple of months. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] C API experiment
I've only been using Fltk in pure C++ applications so far. Fltk is worth programming in C++ but I am not crazy about it. I don't like C either actually but it's easier to work with from other languages. I have read some other posts in the past about creating a C API and it looks like the main issue is that it would bloat FLTK. I was thinking that if I was able to find a way to auto-generate a whole bunch of C functions that contain calls to all the C++ methods I could create the C binding and that if each was in it's own C++ file that contained the extern C brackets then there would be a mechanism to mitigate bloat. All of these files could be included from bloat.cxx during the early development stages and then bloat.cxx could be removed and the headers containing only the functions used could be included. It would be tedious to include 20-30 header files manually but I think that it would provide a lot of benefits too. I am wondering if GTK's gobject introspection feature will give non-C/C++ languages a boost as many languages bindings can be created much easier. It might increase Fltk's market share. I doubt that GTK would have been this popular if it was written in C++ from the start. Any similar efforts or pitfalls or general comments? -Patrick ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] C API experiment
Sorry everyone When I said It might increase Fltk's market share. I meant to say A C API might increase Fltk's market share ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] C API experiment
Hi Ian I hadn't thought about C++ overloading, that pretty much kills this. I will keep experiment where I can though. Cheers-Patrick ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Keyboard Extension with function keys
HI Albert I am not sure if I have the skills to help here or not but I am facing the same sort of situation. I made my own keyboard in Linux by altering configuration files. keys like QWERTY map to underlying identifications that can be assigned to a different map. Did you want the keys to type a different character only while in a FLTK app ? This is my case and I have to work through it. I work with scientific instruments. I have been teaching myself to program for 8 years to move the business towards selling software to control scientific instruments. Your project sounds interesting. Are you colony counting? I looked into a keyboard with LCD keys but it was $1K. What about creating an application that uses a touchpad. My main concern with this, would be the difficulty in locating the parts of the screen to push. Perhaps a plastic mask could be applied over the touchscreen that might even have braille like protrusions. My interest in this is for my son who was autism and a severe speech delay. I believe that the English language's defective spelling system is complicating the recovery of people suffering from autism. Many can read quite well but struggle with speech. I am hoping to make a program for him that will show pictures, how they are spelled and then will prompt him to type a phonetic representation so he can practice organizing the sounds in a visual way I move very slowly but I can offer 40-100 hours of work over the next 3 months if there is something that will lead us both to a solution. -Patrick On 12/06/2012 11:23 AM, Albrecht Schlosser wrote: Hi, FLTK users, I'm looking for a keyboard extension or a special function keyboard that can be used to type special keys normally not found on a standard computer keyboard, or maybe a keyboard extension that can be used with FLTK. I'd appreciate if someone who has experience with such a keyboard could share her/his experiences ... The task is to create an application or widget that can be used to count something (maybe more than 20-30 different items) by typing one-handed and blindly (i.e. w/o moving one's eyes off a microscope). This special keypad should be easily moveable to the microscope near the PC. Normal keyboards could probably be used, but the numeric keypad doesn't have enough keys, and other keys couldn't be reached and typed blindly easily. I imagine something like those keyboards you can find in shops where each product has its own key, maybe with a USB or radio (bluetooth, WiFi?) connection, or whatever. It would be ideal, if this additional keyboard could be integrated with FLTK in an easy way w/o driver programming, but the latter would be possible as well (if not too complex). A simple keyboard layout could be twice the numeric keypad side-by-side or similar. It would be optimal if the key labels could be changed, or if there was a programmable (LCD?) display near each key, but that's all not that important. There used to be special devices that did the task and transmitted end results (counted values) to a computer, but these devices are hard to get today and they are very specialized... I've seen a commercial keypad with 20 keys (5 rows with 4 keys), but this is maybe not enough keys, and it's sold by a manufacturer with their own software (which should be avoided). Does anybody have ideas how to solve this problem or experiences with such input devices? All facts and links welcome... Thanks in advance Albrecht ___ 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 ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] thinking about FLTK touchscreen project
Hi Everyone It's the OS that is handling the interaction with touchscreen displays right? Does anyone think a FLTK app might not run on a touchscreen based system ? -Patrick ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Pure C Bindings
Hi Deech Your exact question came up in a thread I started a couple of weeks ago, FLTK ANSI C API HTH-Patrick On 11/27/2012 04:08 PM, Deech wrote: Hi all, I'm looking to make pure C bindings to FLTK. I'm pinging the group in case anyone knows of any completed or ongoing efforts. If not I'd appreciate some advice on the best way to go about it since I'm a C (and C++) newbie. I've read some generic articles on binding C++ to C but am also seeking any FLTK specific advice. The end goal is a complete FLTK-binding for Haskell. SWIG unfortunately doesn't support Haskell and while I could go through an intermediary language I'd like to have the fewest dependencies possible. Thanks! -deech ___ 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
[fltk.general] how is build system designed ?
Thanks to all the help I have received from this list, I am off and running using fltk. I want to fiddle with the sources a bit but I don't really understand how the build system is laid out. It appears there is a fltk.list.in file that contains all the files and it has descriptive information too. It appears to be designed to be used with the epm distribution manager. Is epm creating all the makefiles and cmake files. I don't understand the relationship between the build tools. Is there some documentation I could read to understand this or if someone has time to jot down a quick overview, that would be appreciated. Thanks for reading-Patrick ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] pointers scope, questions and confirmation
Hi Everyone
Apologies if these questions are really more C++ then FLTK
In the test folder of the source there is a program called inactive.cxx.
I will copy and past the full program at the end of the email.
There is this line:
Fl_Group *the_group=(Fl_Group *)0;
and this one:
static void cb_active(Fl_Button*, void*) {
the_group-activate();
}
The object the_group is also instantiated here:
the_group = new Fl_Group(25, 25, 375, 295, activate()/deactivate()
called on this Fl_Group);
I don't fully understand what is happening here. It looks like they are
both pointers to a group that will become deactivated by the callback
initiated by clicking on another button, they look to be in different
scopes.
Is the global one a pointer to a group or all of the groups instantiated
by the Fl_Group constructor? I am really mixed up.
In my own code I tried to make one button deactivate a spinner. I tried
to create a global pointer to the one that will be deactivated:
Fl_Spinner *fc2_num_tubes=(Fl_Spinner *)0;
but I get a segmentation fault when the callback is called. Please help
me to understand what is going on in the inactive example so I can debug
my own code.
I hope it's okay to create a digest of questions? I don't want to spam
the list..
I would also like to double check that I understand what is happening here:
{ Fl_Check_Button* o = new Fl_Check_Button(50, 170, 105, 25, red);
o-type(102);
o-down_box(FL_DIAMOND_DOWN_BOX);
o-selection_color((Fl_Color)1);
o-labelcolor((Fl_Color)1);
} // Fl_Check_Button* o
{ Fl_Check_Button* o = new Fl_Check_Button(50, 190, 105, 25,
green);
o-type(102);
o-down_box(FL_DIAMOND_DOWN_BOX);
o-selection_color((Fl_Color)2);
o-labelcolor((Fl_Color)2);
} // Fl_Check_Button* o
By enclosing each snippet in curly braces, each instantiation is created
in it's own scope right ? and each instance can can access callbacks
defined in it's parental scope right?
Thanks for reading-Patrick
---
// generated by Fast Light User Interface Designer (fluid) version 1.0300
#include inactive.h
Fl_Group *the_group=(Fl_Group *)0;
Fl_Menu_Item menu_menu[] = {
{item, 0, 0, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{item, 0, 0, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{item, 0, 0, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{item, 0, 0, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{item, 0, 0, 0, 0, FL_NORMAL_LABEL, 0, 14, 0},
{0,0,0,0,0,0,0,0,0}
};
static void cb_active(Fl_Button*, void*) {
the_group-activate();
}
static void cb_inactive(Fl_Button*, void*) {
the_group-deactivate();
}
int main(int argc, char **argv) {
Fl_Double_Window* w;
{ Fl_Double_Window* o = new Fl_Double_Window(420, 369);
w = o;
{ the_group = new Fl_Group(25, 25, 375, 295,
activate()/deactivate() called on this Fl_Group);
the_group-box(FL_ENGRAVED_FRAME);
the_group-align(Fl_Align(FL_ALIGN_TOP|FL_ALIGN_INSIDE));
{ new Fl_Button(50, 50, 105, 25, button);
} // Fl_Button* o
{ Fl_Light_Button* o = new Fl_Light_Button(50, 80, 105, 25,
light button);
o-value(1);
o-align(Fl_Align(FL_ALIGN_CENTER|FL_ALIGN_INSIDE));
} // Fl_Light_Button* o
{ Fl_Group* o = new Fl_Group(50, 130, 105, 125, Child group);
o-box(FL_DOWN_FRAME);
{ Fl_Check_Button* o = new Fl_Check_Button(50, 170, 105, 25,
red);
o-type(102);
o-down_box(FL_DIAMOND_DOWN_BOX);
o-selection_color((Fl_Color)1);
o-labelcolor((Fl_Color)1);
} // Fl_Check_Button* o
{ Fl_Check_Button* o = new Fl_Check_Button(50, 190, 105, 25,
green);
o-type(102);
o-down_box(FL_DIAMOND_DOWN_BOX);
o-selection_color((Fl_Color)2);
o-labelcolor((Fl_Color)2);
} // Fl_Check_Button* o
{ Fl_Check_Button* o = new Fl_Check_Button(50, 210, 105, 25,
blue);
o-type(102);
o-down_box(FL_DIAMOND_DOWN_BOX);
o-selection_color((Fl_Color)4);
o-labelcolor((Fl_Color)4);
} // Fl_Check_Button* o
{ Fl_Check_Button* o = new Fl_Check_Button(50, 230, 105, 25,
white);
o-type(102);
o-down_box(FL_DIAMOND_DOWN_BOX);
o-selection_color((Fl_Color)55);
o-labelcolor((Fl_Color)55);
} // Fl_Check_Button* o
{ Fl_Check_Button* o = new Fl_Check_Button(50, 130, 105, 25,
check);
o-down_box(FL_DOWN_BOX);
} // Fl_Check_Button* o
{ Fl_Round_Button* o = new Fl_Round_Button(50, 150, 105, 25,
round);
o-down_box(FL_ROUND_DOWN_BOX);
} // Fl_Round_Button* o
o-end();
} // Fl_Group* o
{ Fl_Slider* o = new Fl_Slider(165, 50, 24, 205, Fl_Slider);
o-value(0.5
[fltk.general] status bar in FLTK ?
Thanks again to Ian for answering my last post. I would have been stuck on that for a long time but now it's so obvious. I was creating two pointers with the same name. I hope I am not wearing out my welcome... I have another question... if someone can even spare a yes or no response it will help a lot. I am wondering if I am on the right track regarding status bars. I found this post here: http://www.gidforums.com/t-26030.html?highlight=status This person was using a button for a status bar. There does not seem to be a native status bar in FLTK but is this the best way to simulate one? Thanks ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Create_Fixed_Group, suggestion from noob
So I have not even built one presentable GUI, just little experiments. Please take this suggestion for what it is.. If Ian did not point me to the resizing tutorial, I would have read through 1K+ pages of the manual and still not understood the layout system. Last night I made a non-resizable group: Fl_Group* no_resize = new Fl_Group(0, 0, 100, 100 ); ... add widgets here no_resize-resizable(0); Now I can control what gets resized and what does not. I think I am off and running now. I think it would be nicer for newbies like me to have a utility function to help out with this. While the C++ subset of FLTK is not so hard, I still have some catching up to do. I don't know how to set up a function to take multiple typedef'd arguments but once I figure that out, it might not be hard to make a little function that took took the maximum X and Y of it's arguments and created a non-resizable group from them. The name of this group could be an argument too. Is this silly ? -Patrick ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] help understanding layout management
Hi Everyone Callbacks and creating instances of widgets is really straightforward in FLTK but I am finding the layout management quite confusing. I have some gtk, tk and some html/css background. With css there is absolute positioning and relative positioning(and others likely). It's my understanding that with css it's a bad design practice to set everything by absolute position. With gtk there is hbox and vbox(from what I remember) that will position widgets within the container implicitly based on whether it is a vertical box or horizontal one. I am playing with Fl_Group right now. I thought that widgets inside groups might behave similar to css relative position but it appears it is still absolute. Is there a list of best design practices with fltk ? Is it best to think it terms of absolute positioning for everything ? If this is the case, is Fl_Group more of a declared region on the screen as opposed to a container that can move widgets around like a div would be in html ? Thanks for reading-Patrick ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] help understanding layout management
Hi Ian Thanks once again for all the help. This article was excellent. I read through a few hundred pages of documentation and didn't understand the layout system. This article really should be part of the main documentation. This system looks quite different from what I have seem elsewhere. It's hard to explain using other projects/languages terminology. It looks like I could pretty much layout my whole gui out with everything defined in absolute pixels and then encapsulate various widgets in a resizable group or the opposite, a non-resizable group. This seems so strange but I guess if you think about it, you know exactly where things will be before resizing. -Patrick On 11/06/2012 04:25 PM, Ian MacArthur wrote: In case it helps, there is a howto... http://www.fltk.org/articles.php?L415 Might help. If not, well, ask again...! On 6 Nov 2012, at 15:03, Patrick wrote: Hi Everyone Callbacks and creating instances of widgets is really straightforward in FLTK but I am finding the layout management quite confusing. I have some gtk, tk and some html/css background. With css there is absolute positioning and relative positioning(and others likely). It's my understanding that with css it's a bad design practice to set everything by absolute position. With gtk there is hbox and vbox(from what I remember) that will position widgets within the container implicitly based on whether it is a vertical box or horizontal one. I am playing with Fl_Group right now. I thought that widgets inside groups might behave similar to css relative position but it appears it is still absolute. Is there a list of best design practices with fltk ? Is it best to think it terms of absolute positioning for everything ? If this is the case, is Fl_Group more of a declared region on the screen as opposed to a container that can move widgets around like a div would be in html ? Thanks for reading-Patrick ___ 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
[fltk.general] dumb question double checking assumptions
So I have been practising with fltk and most of it is straight forward. I was just hoping to get some clarifications. I am still a bit weak with C/C++ in this snippet: Fl_Window *window = new Fl_Window(340,180); is window actually a child struct that is initialized by the FL_Window struct and then partially propagated with values be the new FL_Window call? In this case is Fl_Window referring to both a struct and a method ? There are lots of includes in fltk programs: #include FL/Fl.H #include FL/Fl_Window.H #include FL/Fl_Box.H Is this so that we only have to pay for what we use? Is the libfltk.a archive a small piece of glue code to tie together the functionality of the various includes. It's 2 mb, so i am guessing there isn't so much in there. When we do this: Fl_Box *box = new Fl_Box(20,40,300,100,Hello, World!); Are we again creating a struct? does the geometry manager actually fill in values in it's parent struct or is it living a separate life but tied together via libfltk.a ? Sorry for the dumb questions -Patrick ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] FLTK ANSI C API
Hi Ian Wow you do have a lot of experience, I knew that from your other posts though I have 23 Ada books now. I have been studying diligently for a year now and am totally in love with the language. i know I am in a tiny minority If worst-comes-to-worst I could code in the FLTK subset of C++ and call Ada from there. I have learned a lot about C++ by studying Ada. It scares me that you say that the strict Ada compiler did not stop as many bugs as expected. Hopefully it will help me but I guess I can always convert to C++ later if it doesn't. Thanks again-Patrick ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] FLTK ANSI C API
Hi Everyone I am daydreaming about writing an Ada FLTK binding or more likely part of one. GNAT. bundled with GCC. can interface with both C and C++ but there are apparently some issues with C++ likely due to namespace mangling. Accessing FLTK from vanilla C would make it easy to create bindings for many languages. I found this short post: http://comments.gmane.org/gmane.comp.lib.fltk.devel/2265 The only real feedback was that it would bloat FLTK. However, FLTK is already tiny and the other thing is, what if I only used extern C on the widgets I actually needed or the most popular ones? I can export my Ada code as plain C as well and then call Ada functions from FLTK but I would prefer Ada to be the main loop due to it's easy threading model. Thanks for reading ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK ANSI C API
Thanks for responding to my post Ian It doesn't sound like it's a totally insane thing, so I am going to go for it. Even if I fail, I will learn something. I really love Ada! Yep, I hope things will turn around but right now it looks like it's best days are behind it. It does have very good support, built right into the language, for threading. Maybe this will be a draw in the age of multicores. I've been servicing scientific instruments for 13 years now, about 7 self employed. 8 years ago I knew absolutely nothing about computer programming. I have been studying diligently and might have past the threshold were I could call myself a programmer but I am not like you. I don't have years and years of experience under my belt. I think Ada is the perfect tool for me, the police-state compiler will help me ship less bugs and I love the language itself. Thanks again, i will report back-Patrick On 12-10-27 05:53 PM, Ian MacArthur wrote: On 27 Oct 2012, at 17:52, Patrick wrote: Accessing FLTK from vanilla C would make it easy to create bindings for many languages. The only real feedback was that it would bloat FLTK. However, FLTK is already tiny and the other thing is, what if I only used extern C on the widgets I actually needed or the most popular ones? It is possible, of course, to create wrappers for the widgets you want, but the difficulty can be where there are (for example) overloaded methods or etc. - then the plain C somehow has to distinguish between the two (or more!) differing methods since they must have names that are unique in C, where they would have the same name in C++. And of course derived widgets are less easy in C than in C++. And so on. However, if there is a distinct set of widgets and their methods that you want to use, then you can export C wrappers for those, and it can Just Work. Maybe...! I can export my Ada code as plain C as well and then call Ada functions from FLTK but I would prefer Ada to be the main loop due to it's easy threading model. Threading like that may prove to be non-trivial; many host OS are sensitive to making GUI operations from non-main threads and that can lead to unusual effects. Using fltk with threaded code works but care must be taken with the locking / unlocking of the GUI context, and fltk provides methods to do that. My worry would be that threading from beyond the fltk context might not handle the GUI state in a fashion that keeps the host OS happy. Are you strongly tied to Ada? Maybe it would be easier just to do the GUI code in C++ and interface the GUI to the actual worker code through an interface layer, or even via some form of IPC? For my part, after many years working in and around the aerospace and defence business, I've been through the whole Ada thing and back out the far side; we don't see much (if any!) new work in Ada now, its time seems to have passed. I assume you are still seeing work for Ada then? ___ 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 ANSI C API
I created an FLTK binding to haskell using C, but I took a different approach. Since my app has a simple GUI but complicated logic, I did the GUI in C++ and exported a small higher level interface as C. If you want a complicated GUI then this won't be satisfying because you'll wind up doing lots in C++. But if the app is complicated while the GUI is simple, then it's a lot less work to export a specialized C interface than try to bind all of fltk. Even if you still want to bind at the low level, you'll still probably want to start off by binding only the small subset that you need. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev Hi Evan That's exactly what I will do, thanks -Patrick ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Building 1.0 for study
Hi Greg I got it built! Thanks so much! I wouldn't have been able to do this without your advice. Thanks Ian falling back on 1.3 is good advice and that's what I want to study after 1.0.11 Have a great day guys-Patrick ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Building 1.0 for study
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. I am on Xubuntu and I have complied 1.3 from source without issue. If I run configure, this message is in there: X11/extensions/Xdbe.h: present but cannot be compiled Is my x library too new and not backwards compatible by chance? Here is the tail end after typing make: Compiling Fl_x.o... Fl_x.cxx: In function ‘int fl_handle(const XEvent)’: Fl_x.cxx:494:16: warning: ‘KeySym XKeycodeToKeysym(Display*, KeyCode, int)’ is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations] Fl_x.cxx:494:55: warning: ‘KeySym XKeycodeToKeysym(Display*, KeyCode, int)’ is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations] Fl_x.cxx:523:31: warning: ‘KeySym XKeycodeToKeysym(Display*, KeyCode, int)’ is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations] Fl_x.cxx:523:70: warning: ‘KeySym XKeycodeToKeysym(Display*, KeyCode, int)’ is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations] Fl_x.cxx:524:61: warning: suggest parentheses around ‘’ within ‘||’ [-Wparentheses] Fl_x.cxx: In function ‘int can_boxcheat(uchar)’: Fl_x.cxx:892:70: warning: suggest parentheses around ‘’ within ‘||’ [-Wparentheses] Compiling filename_absolute.o... Compiling filename_expand.o... Compiling filename_ext.o... Compiling filename_isdir.o... Compiling filename_list.o... 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] make[1]: *** [filename_list.o] Error 1 make[1]: Leaving directory `/home/patrick/fltk-1.0/src' If anyone has some tips, that would be great. Thanks for reading-Patrick ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Building 1.0 for study
Hi Greg Thanks for you detailed answer I was using 1.0 but tried again with 1.0.11 based on your experiences. I made all the changes you outlined but I don't fully understand what the underlying issue was. Does the older version have trouble with type casting with more current compilers? This is the offending line I am trying to resolve now in filename_list.cxx: return scandir(d, list, 0, (int(*)(const void*,const void*))numericsort); In the FLTK archives it mentioned changing the line to this: return scandir(d, list, 0, (int(*)(void*,void*))numericsort); but it did not seem to help. I believe the function this is a return for is prepping arguments for scandir. I have tried searching for the error /usr/include/dirent.h:256:12: error: and scandir but I have not located anything I can understand, mostly just snippets from pastebin etc. I am using svn, version 1.6.17 (r1128011) If you could help me understand the underlying type casting issues, I hope I won't have to bother you again. Thanks again for your previous answer-Patrick ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] smallest possible C++ subset for C programmers?
Not quite what you had in mind, you might want to consider looking at Programming: Principles and Practice using C++ by Bjarne Stroustrup (Addison Wesley, 2008, ISBN 978-0321543721) in which he explains how to write GUI applications in C++ and FLTK-1. Obviously he describes C++ as a whole and not just the subset of features that are used in the FLTK core libraries. I can recommend the free online book Thinking in C++ by Bruce Eckel. Use your favourite search engine to find it by its title. It's a little outdated now, but still useful (particularly for FLTK's use of c++). It comes in two parts, where the first part covers almost all needed in FLTK (IIRC), whereas the 2nd part covers things like templates and other advanced topics in more detail. Albrecht Thanks Albrecht I tried to thank you in private but my email got kicked back. I found volume 1 and 2 online for free. I will read much of volume 1 but I may also use the topics outlined in it as a reading guide for another C++ book I have a hard copy of. Hopefully once I catch up I can mentor new users as people have done for me. Have a great day-Patrick ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] smallest possible C++ subset for C programmers?
Hi Ian, Hi List Indeed I should have referred to functions of a class as methods. It looks to me that someone coming from ANSI C needs to learn classes with inheritence and overloading. Actually the class stuff is not going to be so hard as I have experience with some dynamic languages, so it looks like overloading is the only topic that I will have some trouble with. Do you guys think there are many people out there that know C but not a dynamic language such as Ruby/PHP/Python? Even learning OO in Lua and Javascript I bet a lot of people end up learning about classical programming vs prototypical. Maybe once I get up to speed I could write a tutorial, FLTK for C programmers, does that sound like a good idea? Thanks again to everyone-Patrick On 11-07-20 05:08 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote: FLTK is tiny(and fast) I am hoping that if I stick to the smallest possible subset of C++ then I will be able to handle it's native API and if I want to look under the hood then the small code base would make this a reasonable thing to do. Could anyone please correct or add to the following: Some C++ features are already not used: templates, exceptions, RTTI, namespaces Fltk uses a fairly simple subset of C++ internally, to aid portability. (You can, of course, use as much or as little C++ as you like in your own code using fltk...) Versions of fltk from the 1.x series (I suggest you use 1.3.0 for now) do not use namespaces (though note that fltk2 does, and fltk3 probably will...) templates, exceptions or RTTI. It's possible to write code that looks just like C in C++, of course, and that does tend to be the most portable subset... We call functions from classes: return(Fl::run()) Not quite sure what you are stating/asking here, can you clarify? Being pedantic, I'd say that classes do not have functions they have methods, though the distinction is not important here (functions would be just like C functions, not a member of any class, in general. You can write C-style functions in C++, and they behave much as you'd expect.) I don't really know much about the standard library, friend functions, overloading and exceptions but should I care? If I understand the C++ subset that deals with the above code am I pretty much ready good to go? You don't need to know about exceptions for fltk. Overloading is probably not too important though might come in handy down the line. You may need to learn about friend classes at some point, though probably not initially. You will need to learn about inheritance though as that's a key way of extending your own widgets derived from fltk widgets... For stdio you can just use the C functions, you don't need to deal with the C++ stream classes or etc. You do not need to know about STL, BOOST or... Etc... Though all are useful once you get up to speed! 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] smallest possible C++ subset for C programmers?
Maybe it's a better idea, to use a search engine for c++ for c programmers. FLTK- C++- C, so it doesn't make sense, to jump from C to FLTK, but learning C++ makes FLTK very easy. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk Hi Edzard Perhaps I should have said introducing FLTK's C++ subset to C programmers. If FLTK is using let's say half of C++, then could someone new to C++ start writing FLTK apps sooner by only sticking to the FLTK C++ subset? They could always learn the other have of C++ later, no? Thanks for your feedback-Patrick ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] smallest possible C++ subset for C programmers?
Hi Everyone
I am just an enthusiast programmer. I have been using dynamic languages
for years now and recently I have started to write reasonable C
programs. I would like to be able to create GUIs as well. I know I could
use GTK and just stick with C but if I ever wanted to look under the
hood the massive code base might as well be in Klingon.
FLTK is tiny(and fast) I am hoping that if I stick to the smallest
possible subset of C++ then I will be able to handle it's native API and
if I want to look under the hood then the small code base would make
this a reasonable thing to do.
Could anyone please correct or add to the following:
Some C++ features are already not used:
templates, exceptions, RTTI, namespaces
We call functions from classes:
return(Fl::run())
We propagate new abstract data types by calling constructor functions:
menu-add(Edit/Submenu/Bbb);
We create our own classes and use them for constructors:
class MyTimer : public Fl_Box {
void draw() {
static long start = time(NULL)
MyTimer(int X,int Y,int W,int H,const char*L=0)...
I don't really know much about the standard library, friend functions,
overloading and exceptions but should I care? If I understand the C++
subset that deals with the above code am I pretty much ready good to go?
Thanks for reading-Patrick
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] smallest possible C++ subset for C programmers?
Thanks Matthias! Thanks Greg! Greg, you have a lot of tutorial information on the net, thanks very much. I have fooled around with glade a bit, fluid seems really nice. I like that it generates C++ code rather then XML. I hope I can catch up and one day do some tutorials of my own :) -Patrick ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
