Topic says it all, really.

This is the first release in the 4.3 series of WIPs that will eventually lead to Allegro 5.0, with a new cleaner API, al_ prefixes, GUI and the like in addons and more. Needless to say there is a long way to go still, and this release is probably not yet suitable for development. Some new features are only partially implemented so far.
However, if you feel like getting a first taste or want to help out by seeing if things compile and run (old code should still compile and run through the compatibility layer), then check it out!
You can grab the release from the download page on SourceForge.
Please note that the documentation and examples have not been updated yet.

For reference, here is a list of new functions and the header files where you can find their prototypes:

• al_current_time

• al_rest

• al_create_video_bitmap

• al_create_system_bitmap

• al_scroll_display

• al_request_scroll

• al_poll_scroll

• al_show_video_bitmap

• al_request_video_bitmap

• al_enable_triple_buffer

• al_create_display

• al_set_update_method

• al_destroy_display

• al_flip_display

• al_get_buffer

• al_get_update_method

• al_enable_vsync

• al_disable_vsync

• al_toggle_vsync

• al_vsync_is_enabled

• al_blit

• al_blit_region

• al_blit_scaled

• al_event_source_set_mask

• al_event_source_mask

• al_create_event_queue

• al_destroy_event_queue

• al_register_event_source

• al_unregister_event_source

• al_event_queue_is_empty

• al_get_next_event

• al_peek_next_event

• al_drop_next_event

• al_flush_event_queue

• al_wait_for_event

• al_wait_for_specific_event

• al_install_joystick

• al_uninstall_joystick

• al_num_joysticks

• al_get_joystick

• al_release_joystick

• al_joystick_name

• al_joystick_num_sticks

• al_joystick_stick_flags

• al_joystick_stick_name

• al_joystick_num_axes

• al_joystick_axis_name

• al_joystick_button_name

• al_get_joystick_state

• al_install_keyboard

• al_uninstall_keyboard

• al_get_keyboard

• al_set_keyboard_leds

• al_keycode_to_name

• al_get_keyboard_state

• al_key_down

• al_install_timer

• al_uninstall_timer

• al_start_timer

• al_stop_timer

• al_timer_is_started

• al_timer_get_speed

• al_timer_set_speed

• al_timer_get_count

• al_timer_set_count

Those interested in such things may also want to look at allegro/src/compat, which contains the compatibility layer.

Enjoy!

Woohooo!!

I'll be hoping that this leads to a version where some keyboard issues are gone.

Great work guys!

How did the vtables change? Is there a plan for making AGL work with AL 4.3.x?

Congrats

Great show. Have you managed to change round the function parameters so they are all the same, e.g. al_blit to match draw_sprite?

One would hope that it gets merged into 4.3 at some point. Hopefully that would bring more eyes to AllegroGL and keeping it synced with allegro.

Some suggestions about the API that some A.ccers and I were discussing on IRC:

• There needs to be some consistancy with the naming api. Some of the suggestions that have been floating around IRC are namespace_module_action (or, if there are multiple levels, they are listed in increasing specifity.) So, for example,

• Module installation/uninstallation:

• Setters for module-wide variables: (VSYNC EXAMPLE)

• Getters for module-wide variables

I know the API isn't complete, but I thought I should put these ideas up for some discussion.

It seems to follow a consistent pattern of: al_module_verb_noun, where module is optional. The noun-verb versions, while maybe more "orderly," aren't as nice to type or say.

I like alot of these ideas..
Its really making it more OO, but focusing on the object first, then the action.

It would also reduce the number of functions, which is a good idea.. allegro can seem awfully messy at times, with so many functions.

A J: Exactly. Those were some of the ideas behind it. The other goal was to attempt to make the code as potentially modular as possible, while retaining a common interface.

Then again, it is my opinion that as much as possible should be put into addons (whether or not these addons are distributed with standard distribution is a non-issue). From a design standpoint, streamlining the seams in the library is advantegous because it reduces undesired conflicts, and allows us to update addons independantly of the "core" library with minimal breaks. I mean, pretty much all (if not all) of the input, graphics, geometric primatives, audio, config, datafile, gui, 3d, fixed point, etc. routines could be seperated from the core, allowing updates of them individually (to a certain point, at least) without requiring all of the other modules to be updated.

This is one reason (the main reason), IMHO, that the current allegro release cycle is at least a year between major versions; no matter the changes to the module, you have to wait for the updates on all of the other modules to be completed in order to have the library rolled up to the next stable version. I might be wrong, but this is my opinion. Through better modularity you also gain the ability to completely exclude portions of the library that are not being used. Don't need FOO support? Don't #include them, link against them, al_install(ALA_FOO) (ALeggro Addon FOO), whatever.

The drawback to addons is that they tend to get neglected. For that reason, I think official addons are the way to go, even for things as simple as loading bitmaps.

However, keep in mind that the complexity of support goes through the roof when you have to deal with a dozen shared DLLs or whatever. That's the main problem to consider.

I am sorry for my "critical" post, but I still have troubles in compiling Allegro with DJGPP under DOS. Now I trying lastest Allegro 4.3.0 from SVN (revision 7395) and lastest DJGPP packets:
djdev 2.03
gcc 4.1.0
g++ 4.1.0
make 3.79.1
binutils 2.16.1
Texinfo 4.8
sed 4.1.5
But unfortunately I get error and warning messages again.
For this time they are:
==============================================================================
In file included from ./include/allegro/internal/alconfig.h:65,
from ./include/allegro/base.h:39,
from ./include/allegro.h:25,
from src/allegro.c:23:
./include/allegro/platform/astdbool.h:29: error: two or more data types in declaration specifiers
./include/allegro/platform/astdbool.h:29: warning: useless type name in empty declaration
make.exe: *** [obj/djgpp/alleg/allegro.o] Error 1
==============================================================================
Can anybody help me to build any version of Allegro without any error or warning messages at last? Thanks a lot.

No, it just doesn't happen that way. Development is slow because we don't have enough people and time.

In response to djgpp question: 4.3.0 doesn't work on djgpp, at all. Nor on BeOS or QNX.

Weeee. I'm gonna test it right away.

Well, I guess I just thought updating a few smaller addon APIs independantly from one monolithic API would be a bit easier, especially because we have few developers on the project.

When you state it in such terms, of course the "independent" addons are going to be viewed in a better light. But if they aren't really independent there's actually more work involved because now you have to maintain an unofficial interface as well. Consider AllegroGL and what they have to go through.

So about my original question: What happened to the VTABLEs? How does this affect AGL?

In MINGW i had to copy some include files manually, but its just minor thing.
Except that, it work good for now, thanks a lot for this release

Bob, I will check when I get home.

But even if AGL works with 4.3.0, it likely won't work for long after that. I think there is no point making AGL work with 4.3 if we're going to integrate the functionality. I think the best thing to do is just to merge AGL code into 4.3 and take out what we don't like later, rather than bringing in bits and pieces. Also, AllegroGL API compatibility would be nice but treated as less essential than 4.2 API compatibility (since there are far fewer AGL programs).

Izual: which ones?

It turned out to be just one (first time i copied all files that wasn't there >.<)

allegro\platform\astdbool.h

Indeed. If we break AGL API compatibility, then we have a good chance of fixing a lot of the existing flaws.

How is it not consistent?

Ack!
Am I really the only one who finds the latter completely backward? The first reads more or less like natural language, afterall, you say `create me a bitmap', not `a bitmap create for me', right?
I understand that the latter reads more like bitmap.create(), which I personally don't find a convincing argument because that reads equally unnatural.

Have a look at al_blit() and your question will be answered.
(Which reminds me, there was some discussion for putting the flags as the first parameter; after playing around with that, I find that I like the idea and it does feel more natural. Did we reach a consensus when discussing this?)

That's the idea. Not in the least so that a change to the graphics driver doesn't affect the GUI (say), or such that programmes don't pull in all code.
Takes time though, so patience!

You are indeed wrong, and it's not clear to me how you can have an opinion on something that is falsifiable.
As Peter said, the problem is workload. We all have work and lives outside from work and programming. I seriously hope no one is willing to compromise their social life for working on Allegro; that means, however, that things sometimes go a bit slower than one would want. In addition, doing an Allegro release is more work than just tar -cvfz allegro.tar.gz allegro/*. The directory tree has to be cleaned, pending patches have to be commited, the result has to be tested (more so for stable versions than for WIP releases), the change log and credits need to be updated, packages need to be made for Windows and *nix and uploaded, an announcement has to be written and posted. This is all rather tedious and when taken together, time consuming as well.

I don't think the graphic VTABLEs have cchanged at all, which means that the current display API is sitting on the old drivers, that don't really accomodate the new API nicely. So that will have to be changed.
Anyway, merging AllegroGL with Allegro 4.3 should take care of that problem.

Confirmed. There are exactly zero differences between include/allegro/gfx.h in 4.2.1 (SVN) and 4.3.0.

However, the AGL (SVN) examples tend to crash with 4.3.0, at least on X. I haven't investigated (and won't).

Unless of course you're Yoda or something But yes, I like it the way it is. It sounds exactly how you'd actually say it.

Can I just clarify about merging AllegroGL and Allegro?

I'm currently using OpenLayer and pretty much all primitives, drawing and images are done directly with OpenLayer. I think I'm only using Allegro itself for the mouse, keyboard and sound code.

Since 4.3.0 is going to break with old versions, would it not be worthwhile cosidering using a similar DirectX / OpenGL route for primitives and images? Or at least providing a way to compile the lib without the Bitmap, Palette and Primitive code..

This way people could use 4.2.0 for traditional methods and the new allegro for totally hardware accelerated coding.

Personally after using OpenLayer I don't see any need to go back to using software gfx apart from for compatability reasons.

You do not load any bitmap ? tga ? pcx ?

I think it is a big good and nice reason to keep any support for non-accelerated graphics. You can not imagine how many people do not have their graphic card drivers installed, and how many drivers who are not happy with opengl ( here I think to nvidia & laptop graphic drivers ).

I load PNG's with OpenLayer.

I understand what you are saying GullRaDriel, but at the moment Allegro is aimed more at software drivers than Full Gfx card acceleration. In the future Gfx cards are going to become more powerful and Allegro won't be able to compete unless it either provides full acceleration as well as the software routines now, or goes completely hardware 'native'.

That's just my opinion.

I'm not sure what you're asking.
However, if you mean `will Allegro have hardware accelerated primitives when using the OpenGL driver, just as OpenLayer does now', then yes, it will. There's no reason not to.

Simply:

Remove all video-memory primitive related code and replace with directX / OpenGL instructions to draw primitives directly.

Do the same thing with allegro code for allocating video memory buffers, instead use OpenGL / DirectX directly.

Optionally.. remove support for memory bitmap primitives and 8-bit colour depths.

That would make some things a bit difficult, mostly I mean the things that need CPU access to bitmaps.

Though I think these things can be done with PBO's or what ever was the name of the extension

If you are doing a full accelerated game everything pretty much will be in video memory (textures, buffers, etc..). You won't draw to a memory buffer and then upload it (apart from when changing screenmode). While there are cases where these may still be needed I'd like a way to only link more detailed memory bitmap code in if you need it.

Well, 'action' functions type has the verb first method, e.g. al_get_joystick but the methods that set/return state have it the other way round, e.g. al_joystick_num_sticks

Don't know, but some of the function names are just silly, it sounds like you're talking to the computer not calling a function

for example:
al_wait_for_specific_event()

would be much better as:
al_event_wait()

not only is it smaller to write, it's easier to remember and more importantly it makes it easier to pass in a state, thus making two functions (in the case of the event wait functions) into one.

I guess the other advantage is it makes it easier to guess functions, e.g. If I wanted to do something with a bitmap I know I could type: al_bitmap_xxx and if xxx verbs/adjectives/adverbs were consistent across the objects then we'll be coding twice as fast

But hey, I'm easy.

I'm all for the current API wording. I find it more readable, more natural, understandable. We're not computers. We don't need the noun to be at second place just to know it's a noun. I even find al_wait_for_specific_event() better, or al_wait_specific_event(). Programming is talking to a computer.

Not in Japanese
And Japanese is a cooler language than English.

I personally disagree (though I haven't been using Allegro recently so I don't know how valid it is), but I like namespaces (at least, in C#) and they seem to clean up the API to me.

I'd strongly support that, though some people still like to make retro games and also can't work in 3D... Perhaps a compromise?

You would use Japanese words in Japanese, not English words with garbled grammer.
Allegro uses English to name functions and variables, and in English you say `create a bitmap for me', not `a bitmap create for me'.
If you want to rewrite Allegro using Japanese names and choose a naming convention that is natural in Japanese, go ahead.

The idea is that Allegro's 2D API can use OpenGL for doing hardware accelerated stuff, similar to the way you would use OpenLayer. For doing 3D things, you would use normal OpenGL.
Just because Allegro uses an OpenGL driver doesn't mean you have to do things in 3D.

Nobody responded to this:

I was under the impression that dos support was being dropped. If anyone wants to use allegro with dos/qnx/mac os classic/whatever then they should use the last MAJOR release (4.0?). Is that correct?

Looks like the sourceforge page may need to be updated to reflect the changing nature of allegro...

Yes, but then you'd have primitives for memory bitmaps, primitives for video bitmaps and primitives for OpenGL/DirectX (direct drawing with trianglestrips as such).

I'd like to have the option to compile the lib with just using the OpenLayer style method.

The last stable release is 4.2.0, with 4.2.1 probably being release in some time, which will likely be the final 4.2 version, and final version to support DOS, BeOS, QNX.

4.3 only is planned to support Windows, Linux, OSX initially, but implementation for additional platforms are always welcome. 4.3.0 itself is just a very early WIP version not ready for any production use.

From previous discussion I don't think we will provide lots of separate DLLs where selective things (like memory bitmap access) will be cut out. So that means, you would distribute an allegro.dll along with your game, which indeed would have those functions in it.

But if you static link, the linker will not included unused functions, so I don't see a problem either way.

If no one maintains the DOS version and updates it, it is dropped. If someone wants to keep it up to date, I don't see a problem with that. Same for QNX and BeOS.
MacOS Classic is another problem. That port never actually worked to begin with.

I really don't see how that's a problem! Maybe DOS and BeOS people are going to complain that they've lost support, but I'm sure the 10 remaining Classic OS users can cope with not getting brand new code.

Would it be ok to do a big "svn rm" statement, getting rid of DOS/QNX/BeOS/MacOS9, in the 4.3 branch? It would be the best commit ever I think

Maybe problem wasn't the proper word to use. `matter' was probably closer to what I meant.
But I agree, the person using MacOS Classic can go on without Allegro.

But, why? You could just have one primitive: a bitmap. Let Allegro figure out how best to allocate it.

No. I meant if you were drawing a circle you'd have different methods for drawing. Either drawing to a video buffer an image of a circle, or using OpenGL/DirectX to draw triangles to make up the circle.

I vote for putting flags last - besides that it feels a whole lot more natural to me, it's closer to how the standard C library does things (the object being operated upon should always be the first argument to the function).

Or call the al_draw_circle() function and let it pick whichever is best.

The problem with that is that flags are an important part of the operation being performed. It's not some optional thing at the end that twiddles with some knobs in the algorithm. It changes the algorithm altogether.

Yes.. and it picks from 2-3 different methods internally. It just seems a bit unneccessary to me.

That was my exact initial reaction. However,

This is quite right. It's not like selecting flags, really. It's specifying the mode of operation. Maybe flags is a bit of a misnomer and we should instead call the parameter `mode', or something like that.

But that's now just the opposite effect of al_subsystem_function. Putting the flags last just looks more naturally. al_create_display(640, 480, 32, AL_OPENGL);

If you go by importance, then it should be: al_display_create(640, 480, 32, AL_OPENGL);

And actually, I'm not sure the dimenstion isn't just as important as the selected driver here.

I agree, putting the flags last makes perfect sense. Putting the mode of operation first also makes perfect sense.

Hehe, well, this wasn't about something like set_gfx_mode.
More al_blit(MASKED, ...) versus al_blit(..., MASKED).
The first one does feel more natural to me after having played around with it.

Can you give a couple of complete al_blit examples for those of us (me) that don't know what it looks like?

The namespace_module_action form reads more naturally to me. al_bitmap_create reads as "Allegro, ask the Bitmap module to Create an instance". Of course it doesn't work well with code-completion so I'd keep it as it is anyway.

The event queue stuff looks interesting. I'm not sure how where to get the event sources from though. Is it something like this?

AL_EVENT_QUEUE* events = al_create_event_queue();
al_register_event_source(events, &al_get_joystick(0)->es);

or

AL_EVENT_QUEUE* events = al_create_event_queue();
al_register_event_source(events, (AL_EVENT_SOURCE*)al_get_joystick(0));

or am I way off?

I think I should wait for examples before I start switching to 4.3.

Yes, like this.

Nice:). I like the idea of choosing what goes into the each event queue. I assume it is possible to have multiple event queues at the same time but can you register the same source to multiple queues?

Yes and yes

There's one very simple example called exnewapi so far, using the new API. But I think we will have a directory with all new examples, and move the old ones somewhere else, soon.

Well, having flags/mode sometimes last (al_set_display), sometimes first (al_blit), would be worse in my opinion than having it either always last or always first, since you would then have to remember for each function where it has the flags/mode.

Also, in C++, you would have the mode of al_blit as last parameter and default to AL_MASKED, so that's another reason to have it last I think.

Please don't move things. It makes merging changes harder and we (I) still have to do that for now.

Yeah, which reminds me.. when will 4.2.1 be out, so we can (mostly) stop with the merging?

I dunno about that, some fixes may be needed to 4.2.x in the future, we shouldn't immediatly drop all support, just say that all you get for the next little while is bug fixes, and all the interesting stuff will go into 4.3+.x

Of course, there will be a 4.2.1, and possibly a 4.2.2. But after 4.2.1, we should stop holding things back for 4.3 just to make merging easier I think, so we can finally start cleaning up the code.

Well, once the merges can't be merged in due to parts of the code just not existing, sure. but a fix that makes sense for both, should go in both, even if its just the 4.2 compat layer (if needed).

Why not have both al_bitmap_create AND al_create_bitmap? let the users vote with their fingers

Personally I would have the first in the code (for ease of grepping, and congruence with OOP), with the second as a natural-language compatability layer similar to the one with create_bitmap.

Well, we need one in the source code though, so which one should call the other, and which one have the code? And once we decide that question, I say the redirecting one could go into an external layer

Is there a precompiled documentation file (.chm or html) to browse the new API?

The list I gave in that post is it, for the moment.

Actually, the former would read like "Allegro: create me a bitmap", and the latter "Allegro: Bitmap create". With the module included, it would be "Allegro graphics: create me a bitmap", and the latter "Allegro graphics: Bitmap create"

As far as natural languages go, not all of them are limited to the Action (or Subject) - Verb - Object (AVO) form that English uses ("Allegro create bitmap"). Many languages use the AOV format (eg. "Allegro bitmap create"), and some even use other formats. I personally favour AOV. That way, you think of the Subject as the do-er of the action, then think about the object it is operating on, and use the verb as the command. Think of it as Reverse Polish notation where you're placing the Agent and then the noun (Object) on the stack, and using the verb as a means of popping the Agent and Object off the stack. For further reading on this topic, I recommend the Wikipedia article on linguistic typology and read the linked articles to do with combinations of Agent, Verb, Object to see the advantages and disadvantages of each method.

Anyway, here are other arguments in this thread that have been put forward for the AOV format and some oter comments:

-

Not always - sometimes, flags really just do nothng more than twiddle knobs. The function is meant to be a black box, so the user is not supposed to care whether flags tweak the algorithm or make it use a different algorithm. I personally think that the Object (the thing being operated on) should be the first paramater. The mode of operation could come after the important paramaters, and flags could be last or near the end (flags can sometimes be different from the mode of operation - the MOO could sometimes be an enum (it would be an enum if all modes of operation were mutually exclusive)).

Actually, it's currently 4.2.0, and 4.2.1 is imminent (although it's been imminent for several months now).

Going by the current track-record of previous release-timelines of Allegro, 4.4 won't be released for at least two years. At the moment, I get the impression that 4.3 still has many changes to undergo before it even resembles what the final 4.4 will look like. For now, I think that the changes in the 4.3 branch that are possible to implement in the 4.2 branch should be ported to the 4.2 branch. Once the code-cleaning gets underway, fewer changes will make it through. Once 4.3 gets to a more or less stable state, development on 4.2 should be restricted to bugfixes only. If 4.3 is dropping support for a few osses, 4.2 should still have some sort of maintainance - even if it is only bugfixes (at least until 4.4 beta 1 comes out).

Is the reason these ports are being dropped because the new core is incompatible with these operating systems (or would require a major rewrite), or just because nobody is willing to maintain one? Is support for a certain platform going to be implemented like some sort of 'add-on'?

Just out of interest, does MacOsX work on the 68K Macs?

And for that matter, what about alBitmapCreate and alCreateBitmap for those of us who like Hungarian notation.

AE.

Both.

Even with new code, I think it'd be best to just not include new patches if the code won't be maintained.

http://s95084514.onlinehome.us/images/blog/scotty.jpg

Corelian:

The thing I want to see dropped is the Allegro "fix" data type.

Depends where you stop really. If fix should go then I guess with the merging of allegrogl, all the polygon drawing and matrix stuff too, and while you're there all the DOS code and retrace stuff, 8 bit graphics, bitmap fonts, GUI .....

Neil, Those are completely diffrent thing, the fix class is C++ code in a C library. I shouldn't of been include in the first place.
As for DOS, I have no argument.
Retrace... I don't know what the retrace stuff is.
8-bit How dare you suggests getting ride of 8-bit support!!
Bitmap fonts, first Allegro need defalt built-in for TT fonts for some time before even consider getting rid of Bitmap fonts.
GUI, that already planed

Who needs 8-bit support? Especially with the merging of AllegroGL, there won't even be support for 8-bit in that driver.

I prefer the al_bitmap_create form, it seems more natural to me. Programming isn't supposed to be pretty english, or else anybody else could do it. al_bitmap_create is more OO, al.bitmap.create. I like it.

I say drop the whole fixed numbers thing. All it does is cause confusion and problems, especially for noobs.

I also think we should have a screen update layer in here too, which can be interfaced to the DX/GL/etc stuff. So if you end up using software rendering, it can manage that too, and suport page flipping, triple/double buffering, etc.

And lastly, why are we keeping 4.2 API support? If we always try to support the older API we will never make it to Allegro 5. We are dropping DOS/BeOS/QNX support, so why not drop 4.2? Then for games that don't update there can be a drop in compatiblity filter that isn't part of the main library. This will help stop the major pollution of the main namespace, requiring winalleg and similar hacks. If games are old enough and not updated, why should we try to support them anymore? They can use an older version of Allegro..

There are things that do not need more than 8-bit color depth, like fonts. More colors would be a waste of space. Let's keep allegro simple, intuitive, fast, all-on-one programming library.

Font's only need 2 colors. I think using bitmaps for fonts is a horrible waste, when TT fonts or even a 2 color bitmap could be used, saving space.

Then they should use a different driver for 8-bit. While I doubt anyone would want to make a 3D game using 8-bit graphics, it's still useful for creating things that rely on colour-cycling effects. And besides, for monochrome graphics, all you need is 8 bits anyway.

I say we should keep support for fixed numbers. AFAIK, in plain C, there is no standard for fixed numbers so we might as well be the ones that provide one to people programming with Allegro. Floats aren't always faster than fixeds on all platforms.

Because Allegro wouldn't be Allegro otherwise.

On the whole, I agree that Allegro should be simple and intuitive to use. As for backwards compatibility, the compatibility layer could be an addon rather than a core part of the library. If we're trying not to pollute the namespace, we just need to #include a file with #defines for various 4.2 functions that are being renamed. For things that are more complicated than a simple renaming of a function, we would create a wrapper.

As for bitmap fonts, it's nice to be able to design a font based on bitmap-graphics. AFAIK, TrueType fonts only have one colour.

AE.

Agreed, but I don't think placing the fixeds directly in the core library is necessary at all (in MOST modern cases, floats should be quite a bit faster, if you need the fixed type, just download allegro-fixed-type or something).

Agreed, to a certain point. The 8-bit graphics have a huge advantage, on the memory side of things, over your higher color depths. However, drawing 8-bit graphics to the screen is questionable at best. Great idea if you are using an older graphics driver with palette switching; probably a bad idea if you are using OpenGL or any other hardware accelerated rendering. So, I could see it going either way (maybe have OpenGL have an 8-bit "psuedo-mode" where all of the blits to it are automatically converted to 16-bit (which is what OpenGL is probably running at), while the other drivers can have a "true" 8 bit mode where it makes sense).

From the posts above I understand that Allegro will have a new GUI subsystem at a specific point. Since writing a proper GUI library is a big task, I ask you: should allegro include a GUI library? my feeling is that it should not. I think the GUI library belongs in another domain, not in the main system...and so do the tools.

um no. the GUI will be split off into a addon lib that gets distributed with allegro, just so allegros current tools continue to work.

I agree with this opinion; in fact, I would take this to another level... If pretty much everyone isn't going to use a feature, put it into an "addon" (whether it is officially maintained or not is a different matter). Fixed Point Arithmetic, 3d Rendering routines, and GUI are the primary candidates for this. If you go to the extreme, the datafile routines, geometric primitives, etc. could also qualify (this could be mixed blessing. On the one hand, you can make very slim releases that don't include redundant code, and the individual parts are much more self sufficient (so you don't end up with "Well, you can't compile without support for X because Y,Z, and Sink rely on it." and "Well, you can't update X without testing Y, Z, and Sink because they use it through the unofficial API."; but on the other hand, you end up having 10+ different pieces that developers must grab.). Separation of the code would be major improvement (especially if by the separation, we force use of documented interfaces and gain a dependency listing). I'm not saying allegro is this way currently, but it is a potential problem that we should avoid; code that becomes "intertwined" over time through the usage of unofficial interfaces and hacks really sucks, especially when through the intertwining it becomes next to impossible to remove A or B because they both depend on each other (or update A or B individually because they depend on each other).

Who is responsible for the GUI add on? how can I help?

Noone is responsible for it. And its only likely to be changed in any large way if all of the tools and whatnot are ported to any new version

If you arn't on the AD list, get on it and make some suggestions.

Is DJGPP and Watcom support completely removed from Allegro 4.3.0 (revision 7467 from SVN)?

Not unless you or someone else wants to implement it themselves...

4.3 will be changing the internals quite radically, meaning all of the code that was "removed" (its still in svn, just swept up from around 4.3), won't be of much use in due time. And will need to be totally replaced. unfortunately no one has worked on that code in a long time, much of it wasn't even working in 4.2, and no one on the current "team" has the knowledge or time to replace it.

If and once someone can provide patches for any of the removed platforms/code and can provide some actual support for it for a while, then I think it'll be warmly accepted by the allegro team. If its a one off patch for a large subsystem or a port, with no future up-keep, I can see it not being accepted.