> Please look at the "basic" code from FLTK1 and FLTK2 (x, osx, > Widget/Fl_Widget). It's inherently small, and coupled with base classes. I copied source files that seem to me containing "basic" code(I chose them quickly, mainly basing on filenames, so it's unprecise). it's fltk-1.1.8 [EMAIL PROTECTED] src % ls src_basic filename_absolute.cxx fl_draw_image_win32.cxx fl_overlay.cxx Fl_Window_iconize.cxx filename_expand.cxx fl_draw_pixmap.cxx fl_overlay_visual.cxx Fl_XBM_Image.cxx filename_ext.cxx fl_encoding_latin1.cxx fl_read_image.cxx Fl_XColor.H filename_isdir.cxx fl_encoding_mac_roman.cxx fl_read_image_mac.cxx Fl_x.cxx filename_list.cxx fl_font.cxx fl_read_image_win32.cxx Fl_XPM_Image.cxx filename_match.cxx Fl_Font.H fl_rect.cxx freeglut_geometry.cxx filename_setext.cxx fl_font_mac.cxx fl_set_font.cxx freeglut_stroke_mono_roman.cxx fl_color.cxx fl_font_win32.cxx fl_set_fonts.cxx freeglut_stroke_roman.cxx fl_color_mac.cxx fl_font_x.cxx fl_set_fonts_mac.cxx freeglut_teapot.cxx fl_color_win32.cxx fl_font_xft.cxx fl_set_fonts_win32.cxx freeglut_teapot_data.h Fl.cxx Fl_GIF_Image.cxx fl_set_fonts_x.cxx gl_draw.cxx fl_dnd.cxx Fl_Gl_Choice.cxx fl_set_fonts_xft.cxx gl_start.cxx fl_dnd_mac.cxx Fl_Gl_Choice.H fl_vertex.cxx glut_compatability.cxx fl_dnd_win32.cxx Fl_Gl_Overlay.cxx Fl_visual.cxx glut_font.cxx fl_dnd_x.cxx Fl_Gl_Window.cxx Fl_Widget.cxx scandir.c Fl_Double_Window.cxx fl_gtk.cxx Fl_win32.cxx scandir_win32.c fl_draw.cxx Fl_Image.cxx Fl_Window.cxx screen_xywh.cxx fl_draw_image.cxx Fl_lock.cxx Fl_Window_fullscreen.cxx vsnprintf.c fl_draw_image_mac.cxx Fl_mac.cxx Fl_Window_hotspot.cxx [EMAIL PROTECTED] src % cat * | wc cat: src_basic: Is a directory 69437 264514 1976186 [EMAIL PROTECTED] src % cat src_basic/* | wc 29120 105978 797569
So it's about half. Having such amount of code be shared between fltk1 and fltk2 would be very good itself. Moreover, containing system-specific in one place would be nice too(now it's spread in many files; I think that's not good; same with fltk2 - maybe the problem is in me, but I believe that if I have a class and similar-named file, the file must contain all of the class; and if we have run.cxx and x11/run.cxx, that implies that all X11- specific code is in x11/run.cxx; also I believe that you don't need grep if you want to find something in well-organized code) > Moreover, FLTK2 uses a different style. This would make both FLTK1/2 > inconsistent with fltk-base and/or hinder FLTK2 c++ support. why? I meant designing fltk-base fltk2-like, with the *most* consistent interface we can think up. fltk2 could use it The destination point as I think of it: having stable fully documented library with consistent interface, serving as complete abstraction layer. I mean, no OS-specific code in both fltks. In my opinion, OS-abstraction and providing usable widget hierarchy - are separate tasks, and to uncouple their implementations is both more logical and more good-designed solution. > I tried both FLTK1 and 2 for a short time, and I like very much FLTK2. I > find that the API gets cleaner each time I take a small peek at it. I find > it exquisite that this kind of refining is still in progress and I'm > absolutely certain that _this_ experience is NOT wasted at all, and it will > come back at full speed in 1.3 (because we already know what to do). > The API designing phase takes very long, and often requires large rewrites. > You don't want to do that while tracking bugs (well, you COULD, if you had > a huge amount of blind manpower). > To me, it would make much more sense to generate header wrappers to expose > FLTK2 api while using 1.3 once we have good api consistency. We will get > stable code and good APIs without wasting time. That's why I'm working with > 1.3 while I praise for those that still file RFEs and smooth/out FLTK2. Have I got your point right, that fltk2 is a playground for new concepts and somehow working surrogate for fltk3? > Also, please look at the code. Really. FLTK1 and 2 have diverged very much. > It's almost impossible to backport a fix easily from 1.1.x. I realise that. But - it was already suggested by somebody to get the drawing backend separate from ftlk. Take a look at my suggestion in this way - we just reorganize fltk1(that's *not* a waste of time itself). As a side-effect we get some stability for fltk2. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
