alephmodular-devel

Re: [Alephmodular-devel] 0.3 Progress update... ints done

[Br'fin <br...@ma...>]

On Sunday, December 29, 2002, at 10:04  PM, Aaron Davies wrote:

> On Sunday, December 29, 2002, at 07:17  PM, Br'fin wrote:
>
>> OBSOLETE CODE REMOVAL
>>
>> In the code we have, we currently have parts of coded surrounded by  
>> #if 0, #ifdef NEW_AND_BROKEN, #ifdef OBSOLETE, #ifdef CYBERMAXX as  
>> well as code for Classic Mac APIS (Non-carbon) and Valkyrie video  
>> accelerators.
>>
>> Chris suggested dumping all pre-carbon support. I myself am  
>> ambivalent, but I can't support it. I don't have the compilers for  
>> making a PPC MacOS 9 build, nevermind even attempting any kind of 68k  
>> build.
>>
>> If you want or need MacOS 9 support, don't just ask for it, try to  
>> find someone to   get this project building under MacOS 9 and then  
>> ask this project to continue to support it. Now is the best time as I  
>> haven't tried to remove anything yet. So everything should still be  
>> available.
>
> What about making the Carbon build OS 9 compatible? I know of dozens  
> of apps that have "fat carbon" versions that run equally well on OS X  
> and OS 9.

Unfortunately it comes down to the same problem. I, personally, only  
have the ability to compile Mach-O binaries for MacOS X. Project  
Builder doesn't appear to be able to create applications that can run  
as "fat carbon" applications.

If we could find someone to maintain builds for MacOS 9 then we could  
debate with them whether it uses all the classic APIs or uses Carbon  
APIs in all the applicable spots.

Right now it's simply out of my hands. :/

-Jeremy Parsons

--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------

Re: [Alephmodular-devel] 0.3 Progress update... ints done

[Nick R. <nr...@nt...>]

Br'fin wrote:

>>
>> What about making the Carbon build OS 9 compatible? I know of dozens  
>> of apps that have "fat carbon" versions that run equally well on OS 
>> X  and OS 9.
>
>
> Unfortunately it comes down to the same problem. I, personally, only  
> have the ability to compile Mach-O binaries for MacOS X. Project  
> Builder doesn't appear to be able to create applications that can run  
> as "fat carbon" applications.
>
> If we could find someone to maintain builds for MacOS 9 then we could  
> debate with them whether it uses all the classic APIs or uses Carbon  
> APIs in all the applicable spots.
>
> Right now it's simply out of my hands. :/
>
> -Jeremy Parsons


How about just having OS X support for now, but when it's modular enough 
to have support for any OS, add OS 9 support (in the same way you might 
add Win32 support). Am I right in thinking that you're aiming for a 
setup where you have support for any number of systems, not just Mac & 
SDL? I have suspicions that SDL is somewhat flaky in Windows, and using 
the Windows API instead of SDL is a better option (if there's someone to 
maintain it), although I could easily be wrong.

On another topic, thought I'd mention the GUI issue (only just joined 
the list so I missed the discussion). I think that at some point in the 
future, it would be nice to have a separate graphics module with a layer 
of abstraction, so that we can write a custom GUI not limited to any one 
OS/graphics API (as is the case in A1 now), and no matter what system 
someone runs AM on, they'll have the same interface.

I've experimented with my own custom GUI (admittedly it used only 
OpenGL, but it ran on windows & mac), and it's not the easiest of tasks, 
especially as I allowed widgets to contain widgets which contain widgets 
etc... A custom GUI is much more suitable for a game, but it'll only be 
worth it if it's powerful enough, as people seem to prefer A1's mac 
dialogs to the SDL dialogs...

Nick.

Re: [Alephmodular-devel] 0.3 Progress update... ints done

[Michael A. <mdm...@ya...>]

--- Nick Rolfe <nr...@nt...> wrote:
> Br'fin wrote:
> 
> >>
> >> What about making the Carbon build OS 9
> compatible? I know of dozens  
> >> of apps that have "fat carbon" versions that run
> equally well on OS 
> >> X  and OS 9.
> >
> >
> > Unfortunately it comes down to the same problem.
> I, personally, only  
> > have the ability to compile Mach-O binaries for
> MacOS X. Project  
> > Builder doesn't appear to be able to create
> applications that can run  
> > as "fat carbon" applications.
> >
> > If we could find someone to maintain builds for
> MacOS 9 then we could  
> > debate with them whether it uses all the classic
> APIs or uses Carbon  
> > APIs in all the applicable spots.
> >
> > Right now it's simply out of my hands. :/
> >
> > -Jeremy Parsons
> 
> 
> How about just having OS X support for now, but when
> it's modular enough 
> to have support for any OS, add OS 9 support (in the
> same way you might 
> add Win32 support). Am I right in thinking that
> you're aiming for a 
> setup where you have support for any number of
> systems, not just Mac & 
> SDL? I have suspicions that SDL is somewhat flaky in
> Windows, and using 
> the Windows API instead of SDL is a better option
> (if there's someone to 
> maintain it), although I could easily be wrong.

I have been running A1/SDL under Windows for quite
some time and SDL doesn't seem to be a problem. 
Either that or the A1 team wrote the code so well that
I never noticed.  Do you have a specific reason to
think that SDL is flaky on Windows or was that just a
"suspicion"?

> On another topic, thought I'd mention the GUI issue
> (only just joined 
> the list so I missed the discussion). I think that
> at some point in the 
> future, it would be nice to have a separate graphics
> module with a layer 
> of abstraction, so that we can write a custom GUI
> not limited to any one 
> OS/graphics API (as is the case in A1 now), and no
> matter what system 
> someone runs AM on, they'll have the same interface.
> 
> I've experimented with my own custom GUI (admittedly
> it used only 
> OpenGL, but it ran on windows & mac), and it's not
> the easiest of tasks, 
> especially as I allowed widgets to contain widgets
> which contain widgets 
> etc... A custom GUI is much more suitable for a
> game, but it'll only be 
> worth it if it's powerful enough, as people seem to
> prefer A1's mac 
> dialogs to the SDL dialogs...
> 
> Nick.

I have to agree with you on this.  A foundation of
"safe" crossplatform function calls needs to be
established (e.g. anything in ANSI is safe, but not
POSIX), then *everything* is written to those function
calls.  Otherwise, the #ifdef's will never be in sync.
 We all know how much that happened with A1.  We could
write this foundation our selves, but like you said
that can be a very major headache.  Our best bet is to
find a foundation that already exists, with maybe a
few additions of our own for those things that people
just insist on being native (e.g. file dialogs).

Personally, I don't care what foundation is used, just
so long as some foundation is established and used all
the time (no cheating).  You could use MacApp for all
I care!  At least it would eliminate #ifdef poisoning.
 Just to get you started here are some foundations
that I know of: wxWindows <www.wxwindows.org>, FLTK
<www.fltk.org>, PLIB <plib.sourceforge.net> (PUI is
the GUI part), and of course SDL <www.libsdl.org>.

I have to laugh at the irony of my situation. 
Usually, the non-Windows person is the one promoting
crossplatform, but here I am a Win guy promoting
crossplatform to Mac people.  I want to help, but
since I only have a WinXP machine (maybe a GNU/Hurd
soon) I can't help until it's ported.  Porting would
be a big task probobly as much as a full 0.X release
(e.g. 0.4 -> 0.5).  If it is done adhoc then I will
require continual maininance, but if it is ported to a
single foundation that we all agree to use exclusivly,
then the port only needs to be done once and only one
codebase needs to be maintained.

Michael D. Adams
mdm...@ya...



__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Alephmodular-devel] 0.3 Progress update... ints done

[Nick R. <nr...@nt...>]

>
>
>I have been running A1/SDL under Windows for quite
>some time and SDL doesn't seem to be a problem. 
>Either that or the A1 team wrote the code so well that
>I never noticed.  Do you have a specific reason to
>think that SDL is flaky on Windows or was that just a
>"suspicion"?
>
Not much more than a suspicion :) I'll take your word for it then, I've 
never used SDL myself, I was just thinking of the problems that A1Win 
has had with running in fullscreen (of which I'm sure you're aware), and 
assuming that it was SDL at fault. If it is robust, then I have no 
problem with it, as long as only having Mac & SDL support doesn't lead 
to the current A1 situation.

Re: [Alephmodular-devel] 0.3 Progress update... ints done

[Br'fin <br...@ma...>]

On Monday, December 30, 2002, at 06:01  PM, Michael Adams wrote:

>> On another topic, thought I'd mention the GUI issue
>> (only just joined
>> the list so I missed the discussion). I think that
>> at some point in the
>> future, it would be nice to have a separate graphics
>> module with a layer
>> of abstraction, so that we can write a custom GUI
>> not limited to any one
>> OS/graphics API (as is the case in A1 now), and no
>> matter what system
>> someone runs AM on, they'll have the same interface.
>>
>> I've experimented with my own custom GUI (admittedly
>> it used only
>> OpenGL, but it ran on windows & mac), and it's not
>> the easiest of tasks,
>> especially as I allowed widgets to contain widgets
>> which contain widgets
>> etc... A custom GUI is much more suitable for a
>> game, but it'll only be
>> worth it if it's powerful enough, as people seem to
>> prefer A1's mac
>> dialogs to the SDL dialogs...
>>
>> Nick.
>
> I have to agree with you on this.  A foundation of
> "safe" crossplatform function calls needs to be
> established (e.g. anything in ANSI is safe, but not
> POSIX), then *everything* is written to those function
> calls.  Otherwise, the #ifdef's will never be in sync.
>  We all know how much that happened with A1.  We could
> write this foundation our selves, but like you said
> that can be a very major headache.  Our best bet is to
> find a foundation that already exists, with maybe a
> few additions of our own for those things that people
> just insist on being native (e.g. file dialogs).

I'm not quite sure what you mean by #ifdef poisoning.

A1 makes a harsh example just because so little time seems to have been 
spent on cross platform issues. (It's Mac code and someone hacked in 
SDL support to the side) And when someone had  a good idea, like the 
File Objects... they still implemented it's interface differently for 
each platform! D'oh. Thus forcing much code that dealt with file 
objects to still do checks for which platform...

> Personally, I don't care what foundation is used, just
> so long as some foundation is established and used all
> the time (no cheating).  You could use MacApp for all
> I care!  At least it would eliminate #ifdef poisoning.
>  Just to get you started here are some foundations
> that I know of: wxWindows <www.wxwindows.org>, FLTK
> <www.fltk.org>, PLIB <plib.sourceforge.net> (PUI is
> the GUI part), and of course SDL <www.libsdl.org>.

wxWindows seems good on paper. Looking to have support for the 
platforms we care about and leaning towards a native look and feel. SDL 
I'm not sure of. (It was functional in A1/SDL OSX, but I can't say I 
was happy with it) though there are apparently projects within the SDL 
realm to put an even better gui forward within SDL.

My current leaning is to aim for allowing any number of different 
GUIs/platforms with a set way of communicating with the underlying 
systems. OSX would simply be one implementation of a GUI. At that 
point, if someone can implement an alternate GUI that works well and 
looks good across platforms, then we can consider standardizing on that 
one for all platforms.

I agree with your points. But I'm being conservative and I'm not 
currently ready to commit to the One GUI to rule them all and throw all 
the GUIs we have entirely. Certainly not until the One GUI goes from 
being a good idea to something that can prove itself.

-Jeremy Parsons

Re: [Alephmodular-devel] 0.3 Progress update... ints done

[Mark L. <hav...@ma...>]

> Unfortunately it comes down to the same problem. I, personally, only 
> have the ability to compile Mach-O binaries for MacOS X. Project 
> Builder doesn't appear to be able to create applications that can run 
> as "fat carbon" applications.

And besides, if the promise of modularity is fulfilled, it should be as 
easy or easier to add OS 9 support back into AM in the future than try 
to preserve it through all possible transformations at all times.

--Mark

"There is nothing so absurd that some philospher has not said it."

Re: [Alephmodular-devel] 0.3 Progress update... ints done

[Chris B. <zzk...@uq...>]

I'm not sure that i'd totally agree with that.. there are a number of 
programming techniques which are simply not available on Mac OS 9. The 
most obvious example is preemptive threading. If OS 9 support is 
deliberately dropped, there is no reason to avoid such techniques. If 
code is written (eg. networking code) which requires preemptive 
threading, it may take a complete rewrite to make it work with OS 9.

Of course, it's possible that AM move forward with the "don't do 
anything that we know is going to break OS 9 support" mentality - in 
which case we wouldn't be supporting OS 9, but it shouldn't take too 
much work to fix the old OS 9 code.

My personal view is that OS 9 isn't worth supporting; if we can't find 
anyone to maintain an OS 9 version then i'd prefer to see it dropped 
permanently. The opinions of those who still use OS 9 may differ ;-)

chris



On Monday, Dec 30, 2002, at 16:15 Australia/Brisbane, Mark Levin wrote:

>> Unfortunately it comes down to the same problem. I, personally, only 
>> have the ability to compile Mach-O binaries for MacOS X. Project 
>> Builder doesn't appear to be able to create applications that can run 
>> as "fat carbon" applications.
>
> And besides, if the promise of modularity is fulfilled, it should be 
> as easy or easier to add OS 9 support back into AM in the future than 
> try to preserve it through all possible transformations at all times.
>
> --Mark
>
> "There is nothing so absurd that some philospher has not said it."
>