Who's Online |
66 user(s) are online ( 36 user(s) are browsing Forums)
Members: 1
Guests: 65
kas1e,
more...
|
|
|
|
|
Re: Porting more interesting stuff
|
Posted on: 2010/7/30 16:39
#141
|
Just popping in 
|
@Rigo
Well, reaction is at least still boopsi based and doesn't provide a too different experience (except improved functionality).
I have nothing against QT. It's quite good, even. But I don't see how you could preserve the famous "amiga feeling" by switching to a generic toolkit like that. And we all know OS4 users are really attached to this "amiga feeling" above all, so I'd expect some disappointment there. The slightest changes in workbench or preferences seems to scare them already, so imagine a completely new toolkit... :) I understand the will is to go forward and improve the OS since the current tookits indeed have flaws (though the major one i see in MUI is just the lack of unicode support, but whatever), but you certainly don't want to alienate the users..
But well, that's not my choice anyway.
|
|
|
|
|
|
Re: Porting more interesting stuff
|
Posted on: 2010/7/30 16:23
#142
|
Just popping in
|
@Rogue
Well, if you plan to turn OS4 in a random linux distribution (with all the flaws without the advantages) by integrating all kind external components and concepts that will just alter the original amigaos experience, then it's surely the way to go...
I can see some remote interest in QT for some applications, but making it the OS toolkit, seriously? Well, at least you didn't choose GTK...
Seriously, where's the "Amiga feeling" in that? Doesn't anyone feel there's something wrong there?
|
|
|
|
|
|
Re: Porting more interesting stuff
|
Posted on: 2010/7/29 23:54
#143
|
Just popping in
|
@Snuffy
That Pegasos 2 was suitable hardware, unlike Amigaone? :)
|
|
|
|
|
|
Re: Porting more interesting stuff
|
Posted on: 2010/7/29 17:30
#144
|
Just popping in
|
@KimmoK
Zune is a reimplementation of MUI, just like AROS reimplements the rest of AmigaOS. Still the best way if they don't want to be tied to any kind of license or individuals.
|
|
|
|
|
|
Re: Porting more interesting stuff
|
Posted on: 2010/7/29 16:36
#145
|
Just popping in
|
@number6
Don't try to bring facts in this discussion, it's generally not well received. :)
|
|
|
|
|
|
Re: Help Joerg
|
Posted on: 2010/7/29 4:24
#146
|
Just popping in
|
@LiveForIt
I can't really check, but i suppose Reaction also uses similar macros to MUI.
String() in particular might conflict severely with the internal Webcore String class.
You can either #undef String macro somewhere at the top of this file (and redefine it with another name if it's really needed for Reaction purpose in that file) or deal with namespaces.
|
|
|
|
|
|
Re: Porting more interesting stuff
|
Posted on: 2010/7/28 20:30
#147
|
Just popping in
|
@KimmoK
Well, i didn't want to bring this to the table, but with your kind of comment, it's tempting. If you think the MorphOS team blocks MUI somehow, then you might want to know that RoadShow has been restricted to OS4 by a contract several years ago even though a 68k version would have been possible at that time. The same more or less happened with directory opus magellan. So do you feel good to have registered OS4 now? :)
|
|
|
|
|
|
Re: Porting more interesting stuff
|
Posted on: 2010/7/28 17:10
#148
|
Just popping in
|
@ssolie
Well, that's the point yes (if i understood your post correctly). Each OS obviously must have its own identity and added value. Giving any key element to the competitors is hardly an option in this regard.
On the other hand, API aren't really affected the same way, and you can try to make them as much interoperable as possible, hence my suggestion of implementing some of the missing MUI classes, the alternative being to adapt them in applications using them, not sure what would be more work there. Another example of this is AROS currently implementing some of the cybergraphx/intuition MorphOS extensions. They also implemented some MUI4 features for dtpic.mui in Zune, for instance.
|
|
|
|
|
|
Re: Porting more interesting stuff
|
Posted on: 2010/7/28 16:12
#149
|
Just popping in
|
@ChrisH
This statement is 5 years old, as you noticed, so many things changed too. Anyway, it's still up to stuntzi to answer about this. The problem is stuntzi is on bike trips most of the time, so good luck to get an answer from him. :)
It has also to be noted MUI4 isn't only developped by stuntzi these days, which makes the situation more complex too (though i don't know what the license says about this).
This is obviously a difficult topic. MUI4 has become one of the key technologies of MorphOS, part of its identity, and its current incarnation uses lots of MorphOS specific features too (whether it was made conditionally or not, so that a "68k" build is still possible, i don't know). So it's not really likely that such a technology is given just like that. Besides, what answer do you think MorphOS users would receive if they asked for OS4 Reaction (or anything else) port? I suspect that would be a no, without further explanation. :)
That being said, I agree it would surely be a good thing to have some of the MUI4 new classes and methods available to other OSes for easier ports. The new classes/methods just make it easier. So maybe the easiest solution would be to implement some of the most commonly used extensions, like list or tab objects, text/picture alpha extensions and a couple others (there are really many more enhancements, but not all are that often used in current 3rd party applications).
Edited by Fab on 2010/7/28 16:38:03
|
|
|
|
|
|
Re: Help port GStreamer
|
Posted on: 2010/7/28 15:42
#150
|
Just popping in
|
@LiveForIt Quote:
OWB supports a lot of things that?s not currently supported by AmigaOS4 or MorphOS port, like dragging pictures and objects, and lots things, I think OWB as a lot of potential.
It's not really OWB itself having a lot of potential, but WebKit itself. OWB is just an API layer over it, showing how easy webkit can be integrated, basically (and sometimes OWB additions are even more a burden than helpers :)). WebKit as an engine supports the most recent stuff, even more than Gecko, and is an insanely active project. See the history of just a couple days at: http://trac.webkit.org/. And it's true both OS4 and MorphOS ports don't support all the engine features, like the new HTML5 drag'n'drop feature (i'll implement it soon), websockets, webgl, JIT javascript, accelerated composition (i don't mean hw cairo here, but something else), and a couple more. So, even if Firefox is a good thing to have, WebKit is at least equally good, but it obviously requires more work on the UI side (which is trivial work in comparison of what the engine does in the first place).
|
|
|
|
|
|
Re: Porting more interesting stuff
|
Posted on: 2010/7/24 18:38
#151
|
Just popping in
|
@ChrisH
No, i don't know, i can only think Hyperion wasn't interested in getting or porting it, or that they agreed with stuntzi only for MUI3.9. I really don't know about this.
|
|
|
|
|
|
Re: Porting more interesting stuff
|
Posted on: 2010/7/24 16:31
#152
|
Just popping in
|
@porthan
What also comes to mind is these opensource amigaos applications like YAM, MUI classes and co that were several times broken (OS3.x and/or MorphOS builds) when OS4 specific changes were added.
|
|
|
|
|
|
Re: Porting more interesting stuff
|
Posted on: 2010/7/23 22:19
#153
|
Just popping in
|
@samo79
I didn't mean OWB, but rather MAME, for instance. I know OWB OS4 is not using SDL at all since a long time now. ;)
Edited by Fab on 2010/7/24 1:09:53
|
|
|
|
|
|
Re: Porting more interesting stuff
|
Posted on: 2010/7/23 22:09
#154
|
Just popping in
|
@Samo Quote:
Problem is not only the number of developers, but sometimes the "head" of certain developers, IMHO we need to share knowledge, opinion and sources with other "Amiga clone" devs, it's quite strange having 3 different MPlayer version, 3 different OWB and so on ... :-/
Regarding MPlayer, there are only 2 versions, not 3. The AROS version is basically the same as MorphOS (including the integrated MUI GUI). The only difference is they couldn't use overlay, since their graphic system doesn't support it yet. But it's indeed silly there are so many independant ports when the API are so close. I offered my help and code for MPlayer, MAME and a couple others: AROS people showed some interest and ported them successfully, but it seems some OS4 coders prefer recompiling plain SDL ports from scratch instead of reusing native amigaos code. Their loss, I guess. @Chris Quote:
In my experience, MorphOS developers seem to take it upon themselves to port or re-port something which has been ported to OS4, without involving or even telling the original porter, or the project's own admins.
I have seen so many things I've ported pop up on Aminet as MorphOS versions afterwards (usually I don't realise until months later as my filters are set to ignore MOS files)
There's some "interesting" hackery in the Fuse code from where it has been ported to MorphOS. If I had been told in advance I would have said to #define __USE_INLINE__ rather than #ifdef'ing the native OS4 interface-style code and adding almost exactly the same code without the interface pointers.
I can't remember whether I cleaned up all that nonsense or just left it.
It's indeed just your experience, because the opposite also happened just the same way, which is quite normal: MorphOS was there years before, so many ports were obviously (re)ported for OS4 several years after MorphOS. Some ports reused MorphOS code and others just ported programs again from scratch, especially the developers who chose to ignore anything MorphOS-related. Now, about Fuse itself, from what i can see, the MorphOS port is listed on the website, and you're credited in the MorphOS readme. ssolie: Edited out the "evil" comments.
Edited by Fab on 2010/7/24 1:08:50
Edited by ssolie on 2010/7/24 22:23:52
|
|
|
|
|
|
Re: Help Joerg
|
Posted on: 2010/7/21 14:39
#155
|
Just popping in
|
@Daniel Quote:
Always found MUI programs to be the least stable. For example, the Voyager browser was always problematic. Then there's the various MUI libs and making sure you have the latest or most stable for the various MUI programs you use, which is thankfully very few these days.
Really a bad example with Voyager, though: the toolkit doesn't automagically fix application-specific bugs. And about the eternal mcc argument, well, there would be this problem as well if Reaction had a large 3rd-party class development. But good MUI applications avoid using all the exotic mcc classes, and also avoid enforcing the very latest version of a mcc just for the sake of it, when they use them.
Edited by Fab on 2010/7/21 15:26:09
|
|
|
|
|
|
Re: Help Joerg
|
Posted on: 2010/7/21 3:16
#156
|
Just popping in
|
@Hans
I wrote an input protocol that hooks to ffmpeg with a registered url-protocol, that takes care of buffering incoming data through the regular OWB network layer. It supports "fast seeking" by resuming (something that GStreamer backend didn't until a few weeks ago). Media data is then demuxed in another thread, which itself passes packets it to video and audio decoder threads. And since cairo rendering for such video needs isn't blazingly fast, i provided a fast overlay output mode that is enabled when fullscreen mode is enabled (it's actually a fullwindow mode, but whatever).
Of course, the whole thing is more simple than a full-blown GStreamer layer, but it does as much in this HTML5 context, and was much more interesting for me. Chrome also has a similar approach, using ffmpeg directly and implementing their own stream layer.
But having GStreamer for other things would still be interesting, of course.
Edited by Fab on 2010/7/21 3:41:18
Edited by Fab on 2010/7/21 3:42:08
|
|
|
|
|
|
Re: CMake
|
Posted on: 2010/7/20 15:50
#157
|
Just popping in
|
@alfkil
I had replaced fork() with vfork() in hope it would work, but it didn't exactly help. :)
So, i think a cmake port will really need some special attention. Since i only needed it for OWB and that OWB compiles much faster on a crosscompilation machine anyway, i didn't bother.
|
|
|
|
|
|
Re: CMake
|
Posted on: 2010/7/19 23:22
#158
|
Just popping in
|
@Hans
I tried a quick port but gave up because CMake needed a working fork(). That said, with more attention, maybe it's possible to work it around. In some cases it's easy, sometimes much less.
|
|
|
|
|
|
Re: FFmpeg 0.6
|
Posted on: 2010/7/4 19:22
#159
|
Just popping in
|
@MickJT
Two hints for you:
- Fully qualify the URL with file: prefix. For instance, "file:ram:blah.avi"
- Implement is_dos_path() in ffmpeg so that it also works for amigaos paths. Originally, it only works for Windows 1-letter drives.
|
|
|
|
|
|
Re: Very, very, very very very slow star of Timberwolf
|
Posted on: 2010/7/2 21:40
#160
|
Just popping in
|
Could you tell which filesystem you're using, too?
If it's FFS without long filename support, fontconfig might fail to create the cache file, since it exceeds 31 (or so, i don't remember FFS old limit there) characters. If that's the case, it would recreate the cache each time, which would be extremely painful, of course.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
