Murga-Projects Forums

Full Version: Future plans ...
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

JohnMurga Wrote:
Maybe some of the mem, io and event stuff may be interesting ... But I want to shy away from providing functionality that is too complex of troublesome ... Threads for instance, they are cool, but will prove VERY problematic when used with FLTK and other things, so I rather leave them out.

Actually I don't think it makes much sense to do multi-threaded fltk programming. But being able to spawn other threads for async io an co. would be a real plus. I think it would be not such a big problem if it is clearly documented what is possible and what not. Also the threading API could reflect this. Maybe it would also be possible to have an API where the threads use a different Lua states, which don't show the fltk functions. Maybe a rings/thread combination. It would be really cool to have multiple treads that could handle network and file io independently from the main flkt thread, especially since synchronous I/O multiplexing is currently non existent in murgaLua. Although with alien on Linux this shouldn't be a problem any more ;-)

JohnMurga Wrote:
Better memory/buffer handling is on the list.

The immutable string as buffer was not the brightest idea of the Lua designers. This is one thing where it becomes really clear that Lua was mainly designed as embedded scripting language.
The sys.handle and io functions from luasys would be a really cool thing.
I really miss the simple "while fd:read(buffer, buffersize) > 0 do .. end" loops.

JohnMurga Wrote:

Juergen Wrote:
I also still can't add anything to the main fltk event loop (Fl.add_idle() and co. are missing).

Let me know what other functions you need are missing.

I hope that I tomorrow more time to look into this. But it is mainly add_idle() and co. Oddly remove_idle() is already available.

JohnMurga Wrote:
That would be nice for quite a few things, but currently it would require me to profoundly change things, although I'll have a think about how I'd go about doing that ... Without making things too complex.

While I have my doubts that it is (performance wise) a good idea to route some of the virtual functions (like draw()) through Lua code, I think it would be really cool to have something like that:

copy_class(Fl_XY, My_New_XY_Class)
function My_new_XY_Class:resize() ....... end

This would of course only work for some selected virtual functions. But there aren't that much that are really necessary to manipulate.
BTW.: I'm really missing a real table class and the labels that are positioned on the box and not above or below. The current fltk labels really suck big time.

JohnMurga Wrote:
The dynamic binaries in the "otherBuilds" should have readline enabled ... At least, they did when I last tested.

You are right. I haven't looked into that directory, since I have at least on system, where I can't use the dynamic build.

JohnMurga Wrote:
So get any requests you may have in now ;-)

I doubt it would be hard to come up with a ton of suggestions ;-)
The ex API has also some functionality that would greatly improve murgaLua (like os.pipe, os.setenv, os.environ() and os.spawn. But as I said, with alien support it shouldn't be that hard to get this functionality anyhow ;-)


what the heck is "alien"?

It's also the name of a Linux script to convert various software package types, which can make a google search kinda hard if you have a habit of using

So get any requests you may have in now ;-)

FLTK 1.1.8 final was released a few days ago...I haven't looked at it yet.
It looks like future "stable" devel will be 1.3.x

I think all I'm hoping for in the near future is documentation for all the stuff I don't understand =o)
Some things I can copy from John's examples, but it would be better to know *why* certain things are done the way they are rather than just *how* they're done.

All the code for 0.6.8 is complete and tested ...
And I think out of everyone Juergen and any Windows users out there will be happiest.

I just want time for more examples and testing, but I am REALLY happy with this release (Linux and Mac users will be happy too!).

I'll say it'll be released this weekend, but you know I cannot stick to a deadline, so we'll have to see.

Either way, the murga-projects WIKI has also been set up, and once I put some introductory content on there I'll be inviting people to join ... That should help with the documentation as it'll make it easier for myself and others to contribute :-)

Furthermore, if mikshaw or others post stuff on there I can explain the why and how ...

The next step after that will be defining the 0.7.0 road map, which goes along the lines of :

+ Examples and documentaion.
+ No new extensions (if possible).
+ A list of about 30 FLTK functions I want to implement.
+ Performance work (size and speed).
+ Fl_Table and tree controls.
+ Async mechanism for "some" tasks (not threads).
+ BSD port, AMD64 work and other build improvements.
+ Some other stuff I don't remember ...

Please feel free to comment.

I forgot to say, I am not planning to upgrade beyond the FLTK 1.1.X family in the 0.8.X releases.

The 3.X branch looks interesting, but we have to wait and see what the FLTK world does (and they take a long time) ... But 1.1.X is without a doubt the most stable and well supported place to be, and I want my binding to be the best available ;-)

sqLite ... Well, it is getting bloated for my liking, and I will be providing drivers for other DBs as a separate download, but it is CORE functionality, and it'll stay and be upgraded as long as it doesn't grow too much.

The other APIs will be upgraded and worked on with backwards compatibility, stability and performance in mind.

I also have some home grown APIs, the "no APIs" rule did not apply to those ...

Pages: 1 2
Reference URL's