Quote:

Yes that's what I'm going to do, but that's a bit sad to do that... Anyway that's not a big deal.

Quote:

In fact I noticed that using IUtility->SNPrintf()

Quote:

No my application wants to display frequencies in Hz with two fractional digits. Calculus is done using lib fftw3 which might (probably) use C runtime functions but my application is only trying to display this into a string gadget and don't use any C runtime functions until now.

Quote:

Hmm too bad I try not to mix C runtime calls and native calls :(
I don't understand what can block inclusion of %f and %g into RawDoFmt now

I just realised that RawDoFmt() does not have a %f formating command. How are we supposed to deal with double and float ?

@Mrodfr

http://www.google.fr/images?hl=fr&q=e ... nintelligible%20questions

bad skills or complex mind process what do you think ?


[mode mimetic off]
I cant' really understand which question you are asking (was it really a question?) anyway what I can see on your link is that Google classified the Addison-Wesley RKM (without any online excerpts) and that copyright is given to "Commodore-Amiga" (as stated on the cover of those books, i.e. they just quoted them)

@tonyw

On the other hand, having a (standard) key to close a window is really a feature I wouldn't want to loose.
Should it be ESC or another shortcut? I don't know.
But I must admit that not being required to use the mouse to close a window is really a power feature (especially when you think that AmigaOS was able to be wholly controlled by keyboard only out of the box since years if not the beginning).

@interrogative

The problem is due to the physical storage media not to the software itself. Some of the storage solutions you are referring to have limited number of rewriting cycles by physical area (just call them cells or sectors if you want), problem is that generally a FileSystem aims at limiting fragmentation. While doing this it ends on rewriting more often on the first cells(sectors) draining out their rewriting counter faster than for the more far cells. When a cell's rewriting cycle is approaching its end the cells starts to wrongly retain information giving read and/or write errors.
Hence the problem you were referring.

Solutions exists especially under Linux there are specialized FileSystems that, contrary to common ones, tries to statistically evenly use every cells of the medium. This augment the life of the medium but won't magically transform them into immortal medium.

@328gts

Doing this from memory, I'm currently not near my A1.

- First make sure the script has an icon;
- open its information (RA+I on the WB);
- make it a script by checking the corresponding box;
- go to the other tab;
- choose "ARexx" from the droplist;
- click save

Now having Mixer open, double click the script you must see your card changing to the one you put in the script.

@cha05e90

Maybe but shouldn't one owns StormC first ? Moreover it hasn't be updated with latest Reaction updates that took place since AOS 3.9 up to AOS 4.1...

@nexus

I didn't say Emperor does not work, only it had some issues.
I only used it as a GUI builder in order to gain time (because of the possibility to see almost real-time what action an attribute has to the GUI). And if I had read the manual I might have understood some things that aren't obvious when you haven't (for example rules/constraints that apply to gadget level in the hierarchy).
Once I had considered I reached the point were the GUI was OK I generated the code and improved from that, coding the rest by hand. Emperor seems to have possibilities to add/write user code but my goal wasn't to fully use Emperor but rather gain time on the GUI building.

A quick search on OS4Depot gave me :
* MindGUI;
* GUI designer

I tested both of them at the time they emerged but can't remember how good they were...

@nexus

Lately I tried to use Emperor to help me design a GUI (advantage being to see almost real-time what it will look like). But I found that Emperor has some issues/bugs in plenty of its area. One of this problem is that Emperor insists on opening its own screen but after two or three actions, it finally stops opening its windows on it and opens them on the WB making you think it does nothing...

I ended generating the code and improved the generated GUI from that totally stopping using it...

Too bad it wasn't updated for so long it might have been a good thing, now unless you manage to use the old ReActor (from the OS 3.9 NDK) we have no solution except waiting for the GUI Builder from Jamie Krueger.

PS: I vaguely remember there was some Proof Of Concept program that emerged on OS4Depot 2 or 3 years ago but can't remember the name nor the author (TSK maybe ?)

@328gts

you realized this is an ARexx script and not a DOS script, didn't you ?

@Raziel

About wxWidgets the port is advancing really slowly for many reasons (hardware breakage, real-life...). I must find motivations back and for this I decided to look at other things (i.e. projects) in order to regain the fun.
I think that it was in fact a too big projects for me alone and I contacted another experienced programmer to get help, I hope this will kick me a bit...

@Varthall

Quote:

No in fact the second option might prove to be slower (because you'll have to *manually* apply AmigaOS 4 changes). While with the first option everything will be automatic, only conflicts (if there are some) would need to be reviewed.

@Snuepye

I guess KISS royalties required to include one of their song on OS4 CD are not on the same level than the Hirasawa ones...

Just a thought

@Chris

I don't understand why you are saying that IDLTool is not doing what we are wanting (BTW what do you want ? Personally it *is* doing what I want) or why you are saying it doesn't help for stub (what are you calling stub ? the glue code needed to access a 68k library from a PPC program ? the stub functions required to have a 68k vector table in a PPC library ? some some of wrapper to a .a of .so library ? something else ? ) ?

@Chris

As you said doing this on a simple library is not a big deal, but try to do it with a bigger library and you'll be gone for an annoying job. Converting a C definition to the XML format is real a pain an error prone. Being able to automate the writing of the XML file would be really a great advance.
I don't understand why you want to invent yet another format we already have this IDL why change again, all it needs is a a tool above it for porters to help them.
And about your critics about XML not being "sane format", come on it's not 1990 anymore it's 2010 and despite not being an all-XML fanatic I really think that here it's rightly used. It's just that the format used forbid a straigth copy/paste from C include but if you want to be language independant you don't have the choice.

@Varthall

In fact merging is automatic in CVS or SVN as long as changes didn't happen on the same line. In such cases one would have to manually resolve the conflicts (which would be automatically detected at merge time).
That's why I'm saying we need the official sources afxgroup worked on this way SVN will be able to automatically detect changes specific to AOS4 and differenciate them from hte one done on the offcial sources. In the end that would mean SVN automatically detecting AOS4 diffs and automatically applying them to the official sources. This shouldn't be that much time consuming and even easy...

@Fab

I'm not against having a single repository that would be really great to be able to acheive this !

@afxgroup

Why ? I don't see the problem. If they don't want our patches what is preventing us from doing it locally. Having a dedicated branch for the official sources tree and updating it from time to time to merge the changes into the trunk is easy...

@Varthall

In a sense yes, but not really. In fact SVN (or CVS, and any other revision control software) can work on what is called 'branches'.
A branch is some sort of fork of the whole source tree in which you can do changes without perturbing the base source tree. The good thing in revision control softs is that they keep track of any changes done between two distinct revisions (not necessarily two immediate following ones, there can be any number of revisions in the between). Add to this the ability to merge changes into a given revision and you have the perfect way to handle forked projects (which in the end is our version of MPlayer). At first it seems dangerous or even risky but finally it proves to work really good and when you are used to revision control systems you don't want to work without anymore. Those notions might need a little more in depth learning, I can advise you partialy read the PDF book that is included in the Subversion archive (called "The Read bean book") you might learn some interesting things. Don't focus on the details at first just look at the main notions: command line and details can be learned at the time they are required, no need to get afraid by the ton of possibilities such kind of softwares are offering.

So basically I would import official MPlayer sources (corresponding to the one the actual AfxGroup's ones are based upon, not necessarily the latest (this is very important)) into a branch (let's called it 'Official') then I would put it into the trunk, then I would check out a working copy, replace all files by the one from the AfxGroup's one and commit the result. At this point we can already know which files were modified for our version and where. After that it's easy to update to latest official version it's only a matter of importing into the 'Official' branch latest files, then merging changes that occurred between this new revision and the previous one into the trunk (possibly resolving some conflicts).

We can discuss this privately or here if other people are interested in following/learning the process with more details. I would only states that I'm more experienced with CVS's branching/merging process than with Subversion's one but the concepts are there.