FLTK logo

STR #2361

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File | SVN ⇄ GIT ]

STR #2361

Application:FLTK Library
Status:5 - New
Priority:5 - Critical, e.g. nothing working at all
Scope:2 - Specific to an operating system
Summary:Hacker's Version of 2.0 (compiles with debug info, demos fixed)
Created By:rainbowsally
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size  
#1 rainbowsally
03:33 May 07, 2010
#2 rainbowsally
03:33 May 07, 2010
#3 rainbowsally
15:43 May 09, 2010
#4 rainbowsally
16:14 May 09, 2010

Trouble Report Comments:

Post Text ]
Name/Time/Date Text  
#1 rainbowsally
10:27 May 02, 2010

Anyone interested in fixing the Makefiles for the test folder can diff the current makefile and the one I created.  But keep the libs line, I disabled the static linkage.

Also, if you're only a librarian (and thank you if you are), in Makefiles TABs must be TABs.  If you open and save a makefile in an editor that replaces tabs with spaces you'll get lots of errors like "missing separator". 

Other than that, it shouldn't be too terribly difficult to figure out.

To others.  This is stock FLTK code with the option of overwriting the exising code with my modifications.  You can do it, undo it, and redo it as many times as you like, to compare how it works or doesn't work.  :-)

And maybe, if you get some insights of your own, we can help these folks in their next adventure: Living In The Future!


[Echoed to bugz as I understand it was probably appropriate this time.  Thanks, everyone!  Now I'm off to "layout", "show", "draw", "flush"... to see why updating certain widgets seems to be a little TOO "deferred". ;-) ]
#2 rainbowsally
09:43 May 03, 2010
Mod patch 01 for the dev/hacker version of 2.0.  (add the file(s) to
the mods folder, not to the base system files.)


Here's what the patch does...

In Fluid_Image.cxx

around line 152 of the mod(ification) file, after this...

  // the user is responsible for add_handler() for unknown
  // image types. rs->
  char imagetype[32];
  char datasname[32];
  strcpy(datasname, "0"); // null$ in case ext is not found below

add this...
  imagetype[0] = 0;


You may get some strange Image class names if you don't initialize
the imagetype name for some reason.

This patch only applies to the mod files, not to the stock system

Also, you might want to
in config.h if you want to keep mess around with the fluid help docs
in your HOME folder.  I put a little 'goto' in fluid to allow that.

#3 rainbowsally
01:45 May 05, 2010
Mod patch 02 is ready.

Reminder: Get the base installation (stock fltk 2.0 r7513 files) and pop the mod files in on top of them to see where we're at.

Here's the base 2.0 r7513 files including the first set of mods.


This then plops in on top of the original mods.


This corrects my alleged bug-fix for Fluid_Image.cxx and also fixes the Makefile for themes.  Three will currently compile (and install, but you have to install from the themes directory).

What they do?  Well, that's still anybody's guess, but the latest mod patch does fix Fluid_Image so it will compile inlined png and jpg images properly (as shared images that can be reloaded by name), and for that reason alone should be worth the download.
#4 rainbowsally
01:46 May 05, 2010
Uh... and another reminder.

Don't use ./configure with the mods.  It won't give you the shared libs.

instead type

    sh go

#5 rainbowsally
05:13 May 05, 2010
The problem with themes...

Themes rely on two functions, one is hard coded and the other is
a pointer that can never change because it relies on the hard
coded 'result' of a call to fltk_theme on the fltk side, which
does NOT do the same thing as the same named function on the
plugin side.
      theme(Theme f){ theme_ = f; }
should not set theme_, but instead it should set fltk_theme
which should be changed to a pointer.
    extern "C" bool fltk_theme();
    extern "C" bool (*fltk_theme)() = no_theme_present;

where bool no_theme_present() does what fltk_theme() used to do.
Currently testing.  It seems to be working.  The other certainly
The windows.theme using these mods is loading and doing something
but it doesn't seem to be doing much and the KDE.theme is crashing
at INIFile::load(kderc) on the plugin side.
But it's coming along.  Stay tuned.

#6 rainbowsally
22:56 May 05, 2010
mod-patch-03 (linked below) fixes KDE.theme not finding the kde

INIFiles still do not parse the configs properly though it no longer crashes and it DOES find the configs and generates the sections.

Here's the README for the dev/hackers version as it now stands.


1. Stock system. 
  Unpack the files tarball,
  make, and
  make install.
  Superuser privileges will be required.  You'll end up with fltk 2.0
2. Modified dev system. 
  Unpack the files tarbal, the mods tarbal and the latest mod-patch
  tarball.  (Currently mod-patch-03. 
  Add the files from the mod-patch directly to the mods folder
  overwriting any old ones.  Then add some or all the files from
  the mods folder to the files folder. 

  i.e., mod-patch-NN -> mods -> files

  type 'sh go' to configure,
  make, and
  make install
  then to compile and install the themes
  cd themes
  make install

With all the mods, this will (read "should") install into your
$HOME/usr32 folder, no superuser privileges required but you'll
have to add

~/usr32/bin to your PATH and ~/usr32/lib to your LD_LIBRARY_PATH in
~/.profile or ~/.bashrc so that the files can be used.

See the 'go' script in the mods folder.

Sorry about the name of the path but that's what I use on my 64-bit
machine to allow me to compile this as a 32-bit app, which is what I
personally need it to be though yours will compile as 32 or 64 bits
(shared, with debug) if you use the files as I have them set up.

A couple of the test files are still broken and currently HelpView
and another app aren't laying out properly until second pass.
\ Formatting ok now, but images are still not showing properly until
\ second pass.



To use help docs in fluid, manually add


and copy the files in documentation (but not the documentation folder
itself) into ~/usr32/share/doc/fltk

in config.h

Good luck.


Here's the base system (merged to r7513).

The latest mod-patch as of today.

All files to date (hopefully this will be up to date).

Disclaimer: This is a dev version for people interested in
debugging the official version.  You will find it much easier to
work on your system in a folder isolated from any global
installations you may have.  I think that was the problem with
fltk 2.0 in the first place.  Stuff that worked on one system
didn't work on another because the originating system included
files not present in the commonly available file set.

In any case, for stand-alone apps you'll probably want a static-
linked system.  This is not that, though you might be able to
figure out how to do that if you play around with the files a
bit (add one at a time to see what they do... sort of thing).

I think I have gotten where I want to go with the themes.  They
now DO load.  They DO modify the Styles and I CAN see what they
were supposed to do.

This MAY be the end of the line for me with fltk 2.0 unless I can
add my own box drawing routines to the stock version (via plugin/
themes).  I need to incorporate "pixies" into the system, which I
had working but not integrated into my fltk 1.3x version when I
switched to 2.0.

"Pixies" are easy to edit mini-boxes used to generate semi-transparent
sprites used for "character graphics" box drawing and highlight overlays.

More on this later.

#7 rainbowsally
21:45 May 06, 2010
mod-patch 04
  test/adjuster added test files Makefile so it will build
  fluid debug -- forces fluid to compile with debug info (it wasn't)
  KDE.theme no-crash (restored lost mod?) whatever.
  KDE.theme find kde directory fixed.
  KDE.theme still not parsing values correctly though.  Prob ini
  Group function tab_order() was crashing on 64-bitter, now using
   va_list instead of simple stack pointer variable. 
re. the tab_order function.  This doesn't fix a crash in fluid when you
try to load themes (on my 64-bit stock fltk 2.0 system which I never
intend to use).  There may be another place I address the stack directly
with a pointer variable.  A null pointer might be crashing it, because
the paths aren't set up.  Fixing this is quite low on my list of
priorities tho.

#8 rainbowsally
03:21 May 07, 2010
v 2.0 r7513 (or thereabouts) mod-patch 05

  Fixed bug in x11/readimage.  Wasn't allocating the array when input
  array pointer was null.

  Added a kinda-sorta browser2 test/demo that pretty much follows
  the v1.3x browser demo, but may require a subclass to render colored
  text.  This was just a test to see how close we could get to the
  retro version.  ;-)  Pretty close.  But not close enough... more
  on this later.  (...probably.)

Note: These mod patches were tested on a "personal installation" that
compiles and installs in your home folders.  See notes above on how to
set your paths to get it to work.

I'm currently working on my own projects, not fltk's.  Whenever it
involves correcting or adding to the code base to make it more backward
compatible, I'll upload the mod patches (while that remains economical).

Get the files download at the link at the top.  It will be the stock
base system plus initial mods.

Add those mods (just copy the files on top of the base system) and then
add the mod patches (again, just copy over the existing files) to get
the latest and greatest, fluid that compiles shared (linked by name)
images, debug info in shared libs, and uninstallation that is as easy
as -- just delete the folders.  No superuser.  No root privileges.  NO

This is a dev/hacker version.  Your own fixups and additions can be
compiled by anyone who has the same system setup.. oh, what am I saying.

Those days are already gone as of about mod-patch... 01.

But if anyone was interested, 2.0 now finally works!  And we have the
demos to prove it.  Even the first batch of files (after you add the
first set of mods, all the test files compile and run though one or
two still evade me.

What the heck were they supposed to do????  ;-)

Multi_image comes to mind.

You'll like the responsiveness to the button clicks too.  Try fluid
without the mods.  Double click on a widget to open the property
editor. Icky or what?


Again, this mod patch adds to the base files and initial mods linked
in the first article above.  You won't need any of the other patches,
they are all included in 05 except those already overwritten with new

#9 rainbowsally
03:40 May 07, 2010
The screen shots (attached files) of browser2 (the demo added in mod-patch05) are mostly self evident but the shot of the quit button
in 'readimage.png' might be a little confusing.

I grabbed a screen shot of the area used by the Quit button and created
a new tmp (Image*) and set the central widget image to that tmp, like


Not to terribly unlike version 1.x but Image now acts more like
RGB_Image and Symbol handles images, text and glyphs (small drawing)
instead of the way Image only handled images.

The name changes are confusing but the functionality is quite nice.

Come along Igore... the moon is right, the weather is going wild and
the electricity bills are paid...

#10 rainbowsally
22:25 May 07, 2010
Trade with your friends.  Collect them ALL!



Having probs with mod patches?  ME TOO!  I forgot to add the first set
of mods first, THEN the latest patch.  (Only the latest is req'd but it
should not be a problem copying it over other patches.)

Ok.  Here's what's up today.

v 2.0 r7513 (or thereabouts) mod-patch 06

* Fixed FileChooser2.cxx which, when the user cleared the input field
  and began typing, reinserted the path before the first char typed
  but left the cursor at the beginning of the text so that addiional
  text was prepended instead of appended to the path though the first
  character was at the end. 
  Now placed the cursor at the end and keeps all the typed text
  connected together.  ;-)
* Added FLTK_THEMEDIR path (literal string) to cflags and cxxflags as
  -DFLTK_THEMEDIR="\"$libdir/fltk\"" in the fltk2-config.in but it
  didn't stick!  Sorry about that.
  Here's what I did to get mine to work.
  in fltk2-config around line 72 add the makefile define for
  FLTK_THEMEDIR as -DFLTK_THEMEDIR=\"${libdir}/fltk\"" like this.
  CFLAGS=" -I/usr/X11R6/include -DUSE_X11=1 -DFLTK_THEMEDIR=\"${libdir}/fltk\""
  CXXFLAGS="-I/usr/include/freetype2  -I/usr/X11R6/include -Wno-non-virtual-dtor"

  I do not grok this fltk2-config file, so that's it for the time
  being.  (I know he's around here somewhere.  The "time being".  I was
  talking to him this morning.)  :-)
  BTW those are squirrely braces not parens around the libdir name.
  ALSO, we don't yet use the paths thus created in my mods, but you
  might in your own work.  That's where the themes live in the
#11 rainbowsally
15:47 May 08, 2010
v 2.0 r7513 (or thereabouts) mod-patch 07


* Fixed KDE.cxx (kde theme) which wasn't finding values correctly. (It
  was including the open brace but not the closing one in the section
  name.  It should include neither.)
* Larger font in piped shell window for fluid.  (courier 12, was a bit
  small changed to 14, though 13, if supported might be better).  And
  changed tab order for the widgets so they don't retrogress on the
  save fluid and code checkbuttons. 
* Yet another Fluid_Image fixup.  As it turns out xpmImage class
  doesn't have the normal get() method though it IS a shared image
  type.  It should, but for now we'll make fluid play along with
  xpmImage/xpmFileImage nomeclature which is a non-intuitive and
  harder to remember relic from version 1.x days.  Whatever. Fluid
  handles it easily enough, but adding a "get()" method to xpmImage
  that does xpmFileImage::get() will not break anybody's code.
  Adding doesn't break stuff.  Only removing methods or changing
  how they behave breaks stuff.

* Well, well, well... HelpView problem solved.

  This is a temp fix because we need a standard method of dealing
  with images we need fully loaded and ready to show, like
                            right NOW!!
  Time to celebrate.  That was a tough one.

  [It probably won't work on your system, even with the mod patches
  because something is wrong in the paths or there's a bum 'size'
  in the code somewhere.  But if you have a native 32-bitter, try
  test/help.  It may just work.  If it does, fluid docs can be
  recreated where fluid expects to find them.  Get the paths from the
  error message.  Good luck.]
#12 rainbowsally
15:52 May 09, 2010
Where to from here?  The final bug-fix for Version 2.0 is now pretty well done and I don't want to do this anymore because I don't use the stock files setup or paths.

Here's where it stands, though, for anyone that wants to see what 2.0 could have and should have been.  (Set up your paths per the readme and run a few demos.)

v 2.0 r7513 (or thereabouts) mod-patch 08 is included in the final version.


And here's the history, in case anyone is interested.

About the latest mod-patch:

* fluid undos were exceeding the expected 1000 file limit.  One
  project I was working on had over 1700 undos.  Changed the
  undo cleaning process to read actual files in the undo buffers
  (directories) instead of just generating names sequentially and
  seeing if they existed.
* Gave fluid a more descriptive title to make it easier to pick it
  out on a grouped taskbar.  "Fluid - FLTK UI Designer"

* Increased number of undo buffers to 8.  This is likely the final
  number.  Was 4 to simplify debugging.
  The undo buffers are basically fluid "sessions" containing undo
  info for the project currently being worked on.  The individual
  files saved are actual fluid files and can be reloaded if they
  exist, though several operations will clean them out, including
  a 'save' operation.  It's best not to mess with them unless it's
  a dire emergency, but they do exist and are readable.
  The number of buffers determines how many sessions can be open
  concurrently, basically.  Eight should be enough for even the
  most radical of scenarios -- and they DO get cleared out every
  8 sessions now.  In the original 2.0 they do not clear out at
  all.  There was a bug in the algorithm which we changed to
  ensure nobody ends up with 130 megs of undo data -- so much that
  it crashed my konqueror trying to delete them all.  :-)

  To see the buffers and the undo files look in the system folder

  There you will see the index file containing the next buffer
  to use and the folders where the undos are saved, restored,
  and now, at long last, completely cleaned up next time we come
  around. ;-)


I don't know if you're having as hard a time as I am keeping
all these mods straight but if you're having as much trouble as
I am you can understand why I'm going to start uploading my own
system instead of this one.

Take a look at the screenshot 'uninstaller.png'.  That's the
system I have going on my side.

Return to Bugs & Features | Post Text | Post File ]


Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.