Graphics driver arc and pie - any suggestions/algorithims?

[Mark Olesen]

I am working on an Allegro 4 driver (DJGPP) and am having difficulties implementing arc and pie. The attached screenshot is similar to FLTK unit tests circles and arcs. As you can see it is just plotting circles. The code used is basically ripped from src/drivers/OpenGL/Fl_OpenGL_Graphics_Driver_arci.cxx, except I am using putpixel.

I was wondering if anybody had any suggestions or algorithms available for this already?

The graphics primitives allegro 4 has can be found at:

https://www.allegro.cc/manual/4/api/drawing-primitives/

prototypes for easy reference

Fl_Graphics_Driver::pie(int x, int y, int w, int h, double a1, double a2)
Fl_Graphics_Driver::arc(int x, int y, int w, int h, double a1, double a2)

Sorry for my lack of knowledge in this area.

Thanks in advance,
Mark J. Olesen

[Ian MacArthur]

This is the sort of thing they (used to, anyway!) teach in computer graphics courses  - I'm sure I remember text books on it way back when (not that I ever actually did a CG course...)

FWIW, our void fl_arc(double x, double y, double r, double start, double end) function is "similar" to the allegro arc() function so a bit of jiggling about with parameters might make it fit.

But our void fl_arc(int x, int y, int w, int h, double a1, double a2 is rather trickier.in that it fits the arc into the bounding box, so does not just draw circles, it also can draw elliptical curves and so on, which allegro does not appear to have primitives to support.

There used to be, I thought, in the fltk code some implementations of these "by hand", just doing the maths and setting the pixels; so if that code is still in there... I guess, copy it!

The pie() stuff is a wee bit trickier - basically it is the same as the arc() stuff, but once you have drawn your arc you then draw two lines from the endpoints of the arc to the centre, then floodfill the enclosed region.

The allegro lib doesn't seem to have anything quite like pie(), but it does support a floodfill.

A lot of "modern" graphics interfaces provide these primitives now, so for the most part fltk just calls the OS provided primitives these days..

[Mark Olesen]

Thanks for the help and reply Ian.

I admit I am in over my head with these routines. This is going to be a challenge. It is too bad my local library does not have graphics books that covers the topic. However, I will try to look into winehq and microwindows to see how they implement the primitives. I will also scan earlier versions of FLTK. Maybe I can hit pay dirt?

Incidentally, flood fill only works when there are solid borders. Round button does shading to make it look like it has an impression. So, when I used flood fill on it the entire window gets painted.

[imm]

On 20 December 2017 at 02:47, Mark Olesen  wrote:
>
> I admit I am in over my head with these routines. This is going to be a
> challenge. It is too bad my local library does not have graphics books that
> covers the topic.

Last time I needed some of this stuff (which was

​quite ​

a while go) google came up with some good references, along with the usual references to Bresenham's and all that...

> However, I will try to look into winehq and microwindows
> to see how they implement the primitives. I will also scan earlier versions
> of FLTK. Maybe I can hit pay dirt?

It used to be something that you commonly had to do, so there must be lots of code for it lying around I guess

​? Surely.​

>
> Incidentally, flood fill only works when there are solid borders. Round
> button does shading to make it look like it has an impression. So, when I
> used flood fill on it the entire window gets painted.

Ah, yes... I guess we've all been there...

​ floods that leak out through a pixel gap...​

 

[Duncan Gibson]

Mark Olesen wrote:
> I am working on an Allegro 4 driver (DJGPP) and am having
> difficulties implementing arc and pie. The attached screenshot is
> similar to FLTK unit tests circles and arcs. As you can see it is
> just plotting circles. The code used is basically ripped from
> src/drivers/OpenGL/Fl_OpenGL_Graphics_Driver_arci.cxx, except I am
> using putpixel.

Maybe I'm misremembering, but there was some discussion a couple
of years ago, just before or as Manolo's great driver rewrite was
starting, about creating a minimal implementation for porting FLTK
to new hardware and operating systems.

I vaguely remember that as long as you could open a window or a
drawing surface and draw a single pixel in a given colour, then
lines, arcs, boxes, etc. were all drawn using repeated calls to
draw single pixels, so at least you could get the port started.
Once you had that, then you could work your way up by overriding
the drawline() method, etc.

Or was this just one of Matt's proposals or private code branch?

D.

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

[Ian MacArthur]

On 20 Dec 2017, at 14:49, Duncan Gibson wrote:

Mark Olesen wrote:

I am working on an Allegro 4 driver (DJGPP) and am having
difficulties implementing arc and pie. The attached screenshot is
similar to FLTK unit tests circles and arcs. As you can see it is
just plotting circles. The code used is basically ripped from
src/drivers/OpenGL/Fl_OpenGL_Graphics_Driver_arci.cxx, except I am
using putpixel.

Maybe I'm misremembering, but there was some discussion a couple
of years ago, just before or as Manolo's great driver rewrite was
starting, about creating a minimal implementation for porting FLTK
to new hardware and operating systems.

I vaguely remember that as long as you could open a window or a
drawing surface and draw a single pixel in a given colour, then
lines, arcs, boxes, etc. were all drawn using repeated calls to
draw single pixels, so at least you could get the port started.
Once you had that, then you could work your way up by overriding
the drawline() method, etc.

Or was this just one of Matt's proposals or private code branch?

No, that’s a real thing - sort of.

That’s what the “Pico” driver does, or would do. It’s not a working driver per se, but it’s written so that all the lowest level rendering primitives ultimately call 

void Fl_Pico_Graphics_Driver::point(int x, int y). 

(See the file Fl_Pico_Graphics_Driver.cxx and others for details.)

In fact, that method is empty, but if you implement that one method, then all the rest just ought to work.

I guess Mark could duplicate the Pico driver in a new folder tree, and then implement a point method in allegro and see what works. As a starting point!

Of course, allegro already implements many of the lower level functions that are in Fl_Pico_Graphics_Driver et al, so once the base was working at all, it should be feasible to have the fltk methods call the analogous allegro primitives and go from there.

Note that Fl_Pico_Graphics_Driver has basic implementations for many functions, including arcs and circles (which is what I think Mark originally asked about) - though it actually draws these as many short line segments, which is fine for large circles but not so great for very small circles.

[Duncan Gibson]

I wrote:
> > I vaguely remember that as long as you could open a windowor a

> > drawing surface and draw a single pixel in a given colour, then
> > lines, arcs, boxes, etc. were all drawn using repeated calls to
> > draw single pixels, so at least you could get the port started.
> > Once you had that, then you could work your way up by overriding
> > the drawline() method, etc.

Ian wrote:
> That’s what the “Pico” driver does, or would do. It’s not a working
> driver per se, but it’s written so that all the lowest level
> rendering primitives ultimately call
> void Fl_Pico_Graphics_Driver::point(int x, int y).

Ah, OK, I didn't realise that the Pico driver was the example
code. I hadn't looked at it at all until a quick scan last night.

I thought that this minimal driver code might exist on someone's
experimental code branch and might actually have the arc/pie logic
that Mark was looking for. I didn't realise that Pico doesn't yet.

Sorry for the noise

[imm]

On 21 December 2017 at 09:13, Duncan Gibson  wrote:

I wrote:
> > I vaguely remember that as long as you could open a windowor a
> > drawing surface and draw a single pixel in a given colour, then
> > lines, arcs, boxes, etc. were all drawn using repeated calls to
> > draw single pixels, so at least you could get the port started.
> > Once you had that, then you could work your way up by overriding
> > the drawline() method, etc.

Ian wrote:
> That’s what the “Pico” driver does, or would do. It’s not a working
> driver per se, but it’s written so that all the lowest level
> rendering primitives ultimately call
> void Fl_Pico_Graphics_Driver::point(int x, int y).

Ah, OK, I didn't realise that the Pico driver was the example
code. I hadn't looked at it at all until a quick scan last night.

I thought that this minimal driver code might exist on someone's
experimental code branch and might actually have the arc/pie logic
that Mark was looking for. I didn't realise that Pico doesn't yet.

Sorry for the noise

​No, I think you were right - Pico is that example code, and it pretty much has all the bits an implementer of a new driver might need.

Really the "only" bit missing​ (caution: gross simplification!) is the implementation of point() to actually draw a pixel.

Once point() is implemented, then there are basic implementations of arc(), pie() etc. within Pico that work by repeatedly calling point() to draw the shapes.

Which is probably "sub-optimal", shall we say, but gets it done. 

The idea is, as I understand it, that someone can take the Pico driver and implement "just" the point() method to get up and running, then progressively replace the "higher level" render functions with more sophisticated (aka faster!) platform specific versions over time.

Well, something like that!

[Mark Olesen]

Awesome.  I have been going over all the different driver code for a week or so. Not sure how I missed that?  

void Fl_Pico_Graphics_Driver::arc(int xi, int yi, int w, int h, double a1, double a2) is present and the rendering looks ok.

Unfortunately, pie is not implemented.

void Fl_Pico_Graphics_Driver::pie(int x, int y, int w, int h, double a1, double a2)

{

  // FIXME: implement this

}

The implementation in Fl_OpenGL_Graphics_Driver_arci.cxx draws circles.

Thanks for all the feedback. I really appreciate it.

[Mark Olesen]

screen shot of boxtypes ---

[Ian MacArthur]

On Friday, 22 December 2017 00:30:43 UTC, Mark Olesen wrote:

screen shot of boxtypes ---

OK: I'm impressed that much of it works! Cool...

 

[Mark Olesen]

Thank you. I appreciate the comments and suggestions. There are allot of quirks to iron out.

I put aside fl_pie and started work on menus.  Pulldowns and Popups seem to work fine. However, the menubar allows navigation from one menu bar item to another (left right arrow or by moving mouse pointer). Currently, it is not erasing (see attached image) the current item before drawing the next one.

I also had to inject some code to scare and unscare the mouse. I am unsure if a window driver should be instantiated and draw_begin/draw_end called in the draw method? This is how it is done in Fl_Window. Comments?

[Greg Ercolano]

On 12/27/17 14:35, Mark Olesen wrote:
> I put aside fl_pie and started work on menus. Pulldowns and Popups
> seem to work fine. However, the menubar allows navigation from one
> menu bar item to another (left right arrow or by moving mouse pointer).
> Currently, it is not erasing (see attached image) the current item
> before drawing the next one.

Sounds like the redraw isn't being triggered.

IIRC, menus are simply separate, borderless windows.

Do you find that when other windows overlap your
ported application and are then moved away, does it
have the same problem of leaving behind garbage after
the obscuring window is moved away?

BTW, since this thread is about doing a low level graphics driver
platform port, and is discussing fltk's internals, this thread
should really be moved to the fltk.coredev group.

[Mark Olesen]

After the grab ends, I redraw everything (overkill). Clicking on something like a menu button and then selecting an item or pressing the mouse outside the bounds will restore the screen. So, I do not have a problem with overlap when the grab ends.

void Fl_Allegro_Screen_Driver::grab(Fl_Window* win)
{

    if (win)
    {
        Fl::grab_= win;
        grab_bounce= true; // debounce the mouse - wait for release
    }
    else if (Fl::grab_)
    {
        grab_bounce= false;
        Fl::grab_= 0;
        fl_fix_focus();
        Fl::redraw();
    }

    return;
}

For popup's with a sub menu, going back to the primary pop-up the sub menu will not get erased either.

I am studying FL_Menu.cxx but am unable to find where it is supposed to redraw the window.

I reckon once I get the code to work, I can get rid of the redraw in the grab code.

[Mark Olesen]

On the next cycle of issues, I will post to fltk.coredev. Thanks.

[Greg Ercolano]

On 12/27/17 16:16, Mark Olesen wrote:
> I am studying FL_Menu.cxx but am unable to find where it is supposed to redraw the window.

I might be wrong, but I would think the window manager would originate
sending the redraw event to the application when another window exposes
your app's window.

With some hardware a redraw might not be necessary, for instance if there's
sufficient screen buffering/bit planes to manage the two windows separately,
or if the window manager took a screenshot of the window before it was
obscured, just so it can put back pixels when the obscuring window is moved
away.

However I defer to the other devs that know more about this part of
the code.

> I reckon once I get the code to work, I can get rid of the redraw in the grab code.

Yes, surely you'd want to avoid that if the problem lies elsewhere.

[Mark Olesen]

There might be some underlying window manager magic going on. I am not working with one (this is Allegro 4 --- DOS). I was thinking there might be some place to inject code to redraw in Fl_Menu_Item::pulldown. That is, do a redraw right before a popup changes. Unfortunately, I am not having any luck so far....

[imm]

That's a point; there are a range of actions the driver layer is probably"assuming" the underlying WM makes, that will not happen in this case.

Might be worth checking out what Georg did (Georg Potthast) with his fltk-dos port work, as he presumably must have addressed the same issues along the way?

The last time (and it was long ago) that I built fltk to run on a system with no WM, (vxWorks + X11) it worked fine as a display with fixed window objects, but once I started adding menus I got so bogged down, that in the end I added a WM anyway (aewm and flwm both worked for me on the target.)

Not sure that's helpful in this case though!

--
Ian
From my Fairphone FP2

[Manolo]

On Wednesday, 27 December 2017 23:35:59 UTC+1, Mark Olesen wrote:

Thank you. I appreciate the comments and suggestions. There are allot of quirks to iron out.

I put aside fl_pie and started work on menus.  Pulldowns and Popups seem to work fine. However, the menubar allows navigation from one menu bar item to another (left right arrow or by moving mouse pointer). Currently, it is not erasing (see attached image) the current item before drawing the next one.

The menu code merely deletes the menu and returns to te event loop when a menu in the menubar is closed

(the menu is made of 2 windows with a small one at top for the title).

Then, events depend on the platform.

With classical X11 (that is, not with XQuartz nor with some modern compositing X window managers),

when a window is deleted, the window manager generates an expose event that

makes part of the window that was behind the menu to redraw itself.

With MacOS, there's no need to redraw a window when another one that was above it

is deleted.

When the right button is pressed, a popup menu appears, then if you click outside the menu,

the popup is deleted but the mouse-up event is received and processed by the Fl_Menu_Button

object as requiring a redraw of the window containing this button, that is, the main window.

That is, I believe, why the main window appears correct after menu deletion in that situation.

It seems that Allegro requires, as classical X11, to redraw a newly exposed window

after deletion of one in front. If so, this should be put in

     double Fl_Allegro_Screen_Driver::wait(double time_to_wait)
in charge of receiving system events and transforming them if FLTK events,

if Allegro has an equivalent of the Expose events.

Alternatively, you could put code in

    void Fl_Allegro_Window_Driver::hide()

in charge of deleting the OS part of an FLTK window,

that would call redraw() on all other windows that are covered

by the deleted window.

 

I also had to inject some code to scare and unscare the mouse. I am unsure if a window driver should be instantiated and draw_begin/draw_end called in the draw method? This is how it is done in Fl_Window. Comments?

You should normally have a window driver object for each FLTK window object, and its

makeWindow() , show() and hide() methods should have been implemented, to create, map

and delete windows, respectively.

Its draw_begin() and draw_end() methods are only useful for non-rectangular windows which require

some code before, and sometimes after, the platform independent part of Fl_Window::draw().

[Mark Olesen]

I initially looked into microwindows/nano-x. I never did not compile or test it, however. It's been in the back of my mind.

 

The track I am on may wind up with too many dead ends. If it does, no big deal, it is a great learning experience. As I go deeper I do question the utility of a FLTK port to DOS. The resulting binaries are incredibly huge and currently not very stable (PM exceptions that I have no clue how to debug). It is getting better though. Anyway... 

[Mark Olesen]

Yes, I think this put me on the right track. Thanks. 

I am creating a bitmap (backing store) in the constructor of menuwindow and then in the destructor restoring it. Works great until it crashes here and there. I am in the process of debugging.

I don't think I am going to create a window driver for menuwindow. The driver has no idea it is a popup and requires a backing store for show/hide. 

[Manolo]

On Thursday, 28 December 2017 12:41:03 UTC+1, Mark Olesen wrote:

Yes, I think this put me on the right track. Thanks. 

I am creating a bitmap (backing store) in the constructor of menuwindow and then in the destructor restoring it. Works great until it crashes here and there. I am in the process of debugging.

I don't think I am going to create a window driver for menuwindow.

All of the platform-independent part of FLTK expects a window driver to exist for any window.

 

The driver has no idea it is a popup and requires a backing store for show/hide. 

You can call

     pWindow->menu_window()

in the window driver to detect whether the corresponding window is a menu window.

[Mark Olesen]

Sounds like your right about using the window driver code as a route. Thanks.

After some observation:

Fl_Window_Driver has an erase_menu and show_menu:

virtual void erase_menu() {}

virtual void show_menu(); 

void Fl_Window_Driver::show_menu() { pWindow->Fl_Window::show(); }

menuwindow and menutitle are both derived from Fl_Menu_Window, which has a pWindowDriver.

Would have to figure out where they will be called.

As a side note, I set clipping on to the backing store and that appears to stop seg faults.

Another qurik is the menu title for the menu bar acts like a popup and draws beneath the title bar in blue. 

[Mark Olesen]

UPDATE: I implemented Fl_Allegro_Window_Driver  show_menu and erase_menu. Works great. Except for text rendering, the quirks are gone. I really appreciate the tips that set me in the right direction.

I am not sure if some of the changes should be made upstream?

in Fl_Window I made member pWIndowDriver protected.

In Fl_Menu.cxx, I made the following changes:

void menutitle::draw() {

  pWindowDriver->draw_begin(); // ALLEGRO:

  menu->draw(0, 0, w(), h(), button, 2);

  pWindowDriver->draw_end(); // ALLEGRO:

}

void menuwindow::draw() {

  pWindowDriver->draw_begin(); // ALLEGRO:

...

  pWindowDriver->draw_end(); // ALLEGRO:

}

[Manolo]

On Friday, 29 December 2017 00:52:39 UTC+1, Mark Olesen wrote:

UPDATE: I implemented Fl_Allegro_Window_Driver  show_menu and erase_menu. Works great. Except for text rendering, the quirks are gone. I really appreciate the tips that set me in the right direction.

The need for window redraw after deleting/moving another window placed above

is, I believe, general: for menu windows but also for any kind of window.

Consider a main window and a dialog window above it. When the dialog s closed, the

main should redraw what was below the dialog. When the dialog is moved, same need.

That's why a special implemenation of show_menu() and erase_menu() may not be

the good solution.

[Manolo]

On Friday, 29 December 2017 00:52:39 UTC+1, Mark Olesen wrote:

I am not sure if some of the changes should be made upstream?

in Fl_Window I made member pWIndowDriver protected.

This public member function of class Fl_Window

     Fl_Window_Driver *driver() const { return pWindowDriver; }
 gives public readonly access to pWIndowDriver.

[Mark Olesen]

show_menu and erase_menu seemed like a natural fit for the menu code.

I have not gotten to dialogs and other windows. Good point.

I am open to suggestions...

[Mark Olesen]

Thanks.

I changed it to driver()->draw_begin() and driver->draw_end()

Do you think I should suggest adding the code upstream?

The default implementation does nothing. So, adding the code in Fl_Menu.cxx menuwindow::draw and menutitle::draw is a NOOP.

void Fl_Window_Driver::draw_begin()
{
  // nothing to do
}


void Fl_Window_Driver::draw_end()
{
  // nothing to do
}

[Manolo]

Best way: find in the Allegro doc the equivalent of what is the Expose event

under X11. There, the X server informs its client that part of a window became

exposed, because another window moved or was closed, and needs redraw.

Function Fl::wait(double) calls screen_driver()->wait(time_to_wait);

which is Fl_X11_Screen_Driver::wait(double) in charge of receiving events

for the X11 platform and transforming them into FLTK events or commands.

All X11 events arrive into function fl_handle(const XEvent&) of src/Fl_x.cxx

which, for an Expose event, calls

      window->damage(FL_DAMAGE_EXPOSE,

           xevent.xexpose.x, xevent.xexpose.y, xevent.xexpose.width, xevent.xexpose.height);

meaning that the given window rectangular area needs redraw. That's the

end of the platform-specific code. The successive code path which makes FLTK redraw

whatever widgets intersect with that area, is totally platform-independent.

The very same logic applies to Windows XP (but no longer in 10).

Alternative (worse) way: in Fl_Allegro_Window_Driver::hide(),

scan all windows and detect those that intersect on the screen the closing window

and call window->damage() for them. You would also have to do the same

in Fl_Allegro_Window_Driver::resize() to react to window moves.

[Albrecht Schlosser]

On 30.12.2017 00:49 Mark Olesen wrote:
>
> I changed it to driver()->draw_begin() and driver->draw_end()

Good move.

> Do you think I should suggest adding the code upstream?

Upstream would be here or better, as someone else suggested, in
fltk.coredev (for discussion) and eventually in our STR forms as RFE
(preferred with patch).

I believe it's too early in your development to suggest anything to be
included in FLTK. When your code has settled down and you still think
you need the calls to draw_begin() and draw_end() we can discuss (in
fltk.coredev) if this is really useful or if there is a better way to
achieve what you want to achieve (see also Manolo's post from this
morning for advice).

My general opinion on how additional drivers should be included is that
we should not (have to) touch much of the existing code. There may be
points where drivers are loaded and such that must "know" of some
existing drivers (if at all), but everything else should be encapsulated
and hidden by virtual methods.

> The default implementation does nothing. So, adding the code in
> Fl_Menu.cxx menuwindow::draw and menutitle::draw is a NOOP.
>
> void Fl_Window_Driver::draw_begin()
> {
>   // nothing to do
> }
>
>
> void Fl_Window_Driver::draw_end()
> {
>   // nothing to do
> }

The mentioned draw_begin() and draw_end() are such virtual methods, so
their use and addition at points where it is really necessary to support
a new driver would be okay. But a call is a call, and calls to virtual
methods can probably not be inlined, so it is always a minimal overhead,
even if it is in most cases an empty function. So we should wait and see
if it is necessary in your final solution...

PS: do you host your development anywhere publicly so we can see (and
maybe even test) it? A good starting point would be a clone of our
GitHub FLTK mirror and a new branch with your work that can be rebased
from time to time to follow the development. See

https://github.com/fltk/test-only

Be sure to read and understand the warnings about not using this mirror
for "real work" - you can safely ignore the warning if you know what
you're doing and how to recover if we finally move to our *real* GitHub
repository. If you have questions, feel free to ask iin fltk.coredev.

[Mark Olesen]

The project is not hosted anywhere. Since it is in it's infancy, I was not planning on putting it up until I was confident that it would work. However, you made a good point. It will be helpful to others to be able to grab the code. So, I submitted a request to GNU Savannah:

https://savannah.gnu.org/task/?14793

A tarball has been attached: https://savannah.gnu.org/submissions_uploads/fltkal.tar

Please note, FLTK files have been renamed to 8.3 conventions. Some files have been omitted. Remember, this is a PORT to FreeDOS with no long file name support. 

Approval takes time and there is a small probability that it may not get approved. Time will tell. If not, github can be a secondary.

 draw_begin hides the mouse and sets drawing offsets. 

 draw_end shows the mouse.

For upstream changes, I can wait. I stamp changes to FLTK with an 'ALLEGRO:' comment. So far they have been minimal. Most of the development is in the driver code, which is nice. I sure appreciate the tips. Everyone has been very supportive and helpful so far.

[Mark Olesen]

I am digesting your post. (Free)DOS does not have a window manager and I am not aware that Allegro provides that type of functionality.

[Greg Ercolano]

On 12/30/17 16:29, Mark Olesen wrote:
> If not, github can be a secondary.

Github is great. It has its own bug tracking system which can
be used for threads like the one going here, only better, as it
goes along with the code and commits.

One thing that might help, not sure; you might be able to manage
your port better in unix/linux, and use a script that translates
the long names into shorts for DOS compiling.

Or perhaps you can cross compile for FreeDOS on linux, and then
provide /just/ the .H files with the short names, so DOS apps can
compile + link against it.

I can possibly help you with that, as I know my way around
scripting pretty well, and DOS's 8.3 limitations and such.

It'd probably be a lot easier to use the linux development
environment, and use a Makefile that converts to DOS when
you want to do test runs on the freeDOS system.

[Mark Olesen]

Thank you.

Having 8.3 filenames has a disadvantage of porting requires an ifdef block for including headers. Also for maintenance.

I changed all the includes in FLTK cxx files for 8.3 names too. 

The source compiles on GNU/Linux. That is the only way to debug the code. When something happens in DOS but not on Linux it becomes a tedious task of writing to a log file.  

Sure, have at it. Slice and dice. Everything at this point is rudimentary. I am completely open. 

A script showing differences between FLTK and FLTKAL would be very helpful for patching.

[Albrecht Schlosser]

On 31.12.2017 01:29 Mark Olesen wrote:
> The project is not hosted anywhere. Since it is in it's infancy, I was
> not planning on putting it up until I was confident that it would work.
> However, you made a good point. It will be helpful to others to be able
> to grab the code. So, I submitted a request to GNU Savannah:
>
> https://savannah.gnu.org/task/?14793
>
> A tarball has been
> attached: https://savannah.gnu.org/submissions_uploads/fltkal.tar

Thanks for doing that. It will be helpful to be able to view the code

> Please note, FLTK files have been renamed to 8.3 conventions. Some files
> have been omitted. Remember, this is a PORT to FreeDOS with no long file
> name support.

That's a pity. I mean the lack of long filenames and the necessity to
rename existing files - with the consequence to have to edit other
(.cxx) files just to change the #include statements. That sounds really
bad for inclusion in the FLTK sources at a later time.

> Approval takes time and there is a small probability that it may not get
> approved. Time will tell. If not, github can be a secondary.

As Greg already said, GitHub is a great platform for open source
hosting. Git's ability to rebase a branch (rather than merge) is IMHO a
great advantage for such development as you are doing it. Since you can
use git for your own development it should also be easier to "commit
often" on your local server. But I'm not sure that git would be able to
rebase flawlessly if you renamed and modified lots of existing files.

>  draw_begin hides the mouse and sets drawing offsets.
>  draw_end shows the mouse.

Why do you want to hide the mouse (cursor) for menu windows? Or did I
miss anything?

> For upstream changes, I can wait. I stamp changes to FLTK with an
> 'ALLEGRO:' comment. So far they have been minimal. Most of the
> development is in the driver code, which is nice.

That was the intention of our move to the driver model in FLTK 1.4.0,
and it's fine if this is true for your development.

I'd be interested in all necessary changes in FLTK, i.e. changes in
non-driver code (or in existing driver code as well) for the following
reason: if you need modifications in the existing driver model, i.e. in
virtual methods or in the general code, then there is a certain
probability that other drivers would also need such modifications.

Hence it would be an option to verify the existing driver model for
future development. I'll take a look at your tarball and search for you
ALLEGRO marks to see what you did. Thanks.

> I sure appreciate the
> tips. Everyone has been very supportive and helpful so far.

We're a small team, but we try hard to help users and other developers.
Unfortunately we don't make much progress with our bug reports and
feature requests though because of our lack of working power. :-(

[Mark Olesen]

It was a tough architectural decision to rename the files. Unfortunately, the target  has severe limitations. Renaming the files makes it easier to do native development. So forking seemed like a natural path to evolving the code for (Free)DOS.

The mouse has to be hidden prior to drawing or you get residual pixels where the mouse is. This is done prior to drawing anything (not just menus). The other thing it does is set drawing offsets. Since there is no Window management, x y placement has to be faked.

GNU Savannah is an ideal about free software. The project must meet strict guidelines. They have several SCM tools, git being one of them. It does seems antiquated to something like github. However, I am not sure I need all those features. I also doubt this project will pickup much traction and attention. Most likely not enough to build a strong community like this one. (Fades into obscurity).

FLTK might be small team but I am impressed on the willingness and responsiveness to help out. Thanks again.

[Ian MacArthur]

> On 31 Dec 2017, at 11:19, Mark Olesen wrote:
>
> Thank you.
>
> Having 8.3 filenames has a disadvantage of porting requires an ifdef block for including headers. Also for maintenance.
>
> I changed all the includes in FLTK cxx files for 8.3 names too.

This may not be very helpful, but reading through this thread, the 8.3 name limitation stirred some ancient memories... (anecdote of olden times follows...)

The talk of “fixing” the #includes to be 8.3 compliant reminded me of some code I’d seen way back (probably early to mid 80’s) when I was running code ported to a system with limited names. (It wasn’t DOS, I think it was most likely RSX-11M on PDP-11’s. Not really sure, except that there was a problem with short names and porting code...)

Anyway: At the time we had a variety of PDP’s, running various *nix ports or RSX, and porting C-code from the *nix’s to RSX involved a variety of filename hacks (the basic one being short names on all hosts, of course.)

For code obtained from “elsewhere” (which meant 1/2" 9-track reels and the postal service in those days) you couldn’t enforce the "short names" rule, but we had some sort of hack based on using #defines to replace the “long names” with compatible short names at compile time, without changing the source files contents (the source and header files themselves suffered some renaming of course, but at least the content could remain mostly unchanged...)

Well, that’s what I remember, but it was a wee while ago now...

>
> The source compiles on GNU/Linux. That is the only way to debug the code. When something happens in DOS but not on Linux it becomes a tedious task of writing to a log file.

Is the intent to host on *nix and cross-compile for (Free)DOS, or do you intend to make it DOS-hosted down the line? I guess the answer to that affects what constitutes a sensible file naming choice here?

[Mark Olesen]

Ha! Fantastic. I enjoyed that story.

The intent is to compile and run on DOS with no long file name support.