The random numbers are needed for GUID creation. We use the new RANDOM device since it uses a real entropy collector for the random data, not pseudo-random numbers.
Very very good. quite daily i visit the tracker to see what is fixed and what's not and i note that lately there are been some interesting progress, i know that there are a lot of work to do, however my main problems are currently 3:
- Program tend to crash, expecially at startup, see bug:
I want to ask about the extensions. Somewhere I read that you can be able to install any extensions for Firefox into Timberwolf, is that right?
If that's the case, current Firefox is at version 13, while Timberwolf is based on 4.0 version. Is this going to be an obstacle installing extensions in Timberwolf or it's a different matter?
To Be A True Adventurer, You Ought To Play Real Text Adventures
Me too check nearly daily, however it appears the Friedens only update the list when a new Beta is about to be released - which is fine by me - more development time.
Clipboard support (ok and the occasional freezing) is the only thing preventing me from using Timberwolf now, so this is great news
It appears that stuff marked as "Minor" tends to not be fixed (which is fair enough), but unfortunately I wrongly marked one of my reports as Minor although I subsequently decided it was actually important :( so I hope "Minor" reports also get read fully.
@samo79 Quote:
A more "native" GUI still essential
Maybe "essential" to you, but I see that kind of thing as "nice but not functionally necessary" (i.e. it won't allow you to do anything you couldn't do before).
Quote:
- Program still really really slow on my Sam440 so i can't use it as i want,
You DID read the documentation right? It's *supposed* to be slow, because debugging is enabled. (Only the X1000 is so fast that it's already quite usable anyway.) Debugging will be disabled once it runs correctly & stably (i.e. no serious bugs), at which point I presume it will run much faster.
Me too check nearly daily, however it appears the Friedens only update the list when a new Beta is about to be released - which is fine by me - more development time.
I note this aswell even if yesterday that new fixes were marked as "fixed in beta 4" but now are not so clear, that new fixes reference are a bit "mixed" with the oldest fixes so you need to check it carefully to see exactly what was changed in Beta 4
Aniway it's not so important at the end
Quote:
oday there have been changes, here's an intriguing one regarding sound
Yep !
@ChrisH
Quote:
Maybe "essential" to you, but I see that kind of thing as "nice but not functionally necessary" (i.e. it won't allow you to do anything you couldn't do before).
But you maybe know that the real hardest part with the Firefox port (after the port in itself of course) still the user interface adaptation and the user interaction in general, don't you ?
Just look at the current QT implementation and relating port, look how hard it was for Alfkil just to make his Amiga'QT implementation more clean as possible, and even after all that relating hard work we can't really say that QT apps are really "usable" because that and that ..
Of course no one will say or hope that TW or QT apps must have a 1:1 look with any Reaction program (at the end even MUI is different and no one will complain) but when you need 2 or 3 seconds of wait just to open a menu, well is a real problem for an application and after 2 or 3 "waiting-click" the story finish with you closing the entire program and start somethings else ..
Excellent for testing but not good to use !
So yes GUI is essential because Gecko is now ported and the program is more or less ported aswell, but to make it usable for real and not just to say "wow we have Firefox" we need an Amiga like GUI (when possible of course) and more important normal speed
Quote:
You DID read the documentation right? It's *supposed* to be slow, because debugging is enabled. (Only the X1000 is so fast that it's already quite usable anyway.) Debugging will be disabled once it runs correctly & stably (i.e. no serious bugs), at which point I presume it will run much faster.
Sure i read it, i'm also very positive about it because there are many possibility to see real speedup in a near future, even having latest Cairo can help a lot (see how fast is the new Odyssey on MorphOS using Cairo 1.12) but also removing any debug code, adding an hardware acceleration support or even the JIT from the TenFoourFox project ..
So i'm not complain at all, i just say thanks to the Friedens bros because this is an hard and difficult port and when finished it will be a real killer apps
For anyone having trouble registering bugs on os4depot. This is probably due to your user not being validated properly after registering to the site. Please log into http://bugs.os4depot.net for further instructions on how to validate your user.
tfrieden wrote: Regarding the storing of bookmarks: If you are unable to save bookmarks, make sure the "RANDOM:" device is mounted. Either add "mount random:" to the Timberwolf script, or move the file RANDOM from workbench:Storage/DOSDrivers to workbench:DOSDrivers. You might need to delete the profile directory again, or at least the file "places.sqlite" in your profile directory.
Excellent tip! Thanks.
I did have RANDOM: activated, so that was not my problem here, but I deleted (renamed) the places.sqlite file, and now I can save bookmarks at last!
Happily back to using TW - and looking forward to the pending update (hoping maybe the back/forward buttons have been made working).
Never had this problem, but it seems to point at an issue with FontConfig. You may need to rebuild the font-config cache. I know there is an issue with OWB-MUI, the fontconfig clashes with Timberwolf's for some reason. Try to rebuild the cache, and see if that fixes the problem.
Quote:
- A more "native" GUI still essential and maybe this is the biggest part to do, a not easy job i think
Not likely to happen I'm afraid. The GUI is the same on all platforms, the only thing that could be done would be to have a theme that more closely resembles AmigaOS/Reaction. Not going to be Thom or me, though :)
Quote:
- Program still really really slow on my Sam440 so i can't use it as i want, so when i start it i start it only for general testing.)
Not likely to change until after the final release. The first thing is stability, and a straight port of the codebase. Optimizations come later. Hardware acceleration would make it necessary to implement a completely new layer manager from scratch. We'll revisit this issue after the final release; either we'll wait for OpenGL to be available in AmigaOS 4.2, or we'll reimplement the layer manager using compositing. Either way, this will not happen for the first release version. I'm aware it is a bit slow on the SAM, it's perfectly usable on the X1000 though.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Clipboard support (ok and the occasional freezing) is the only thing preventing me from using Timberwolf now, so this is great news
Clipboard support is in, but it works for Text only ATM. Which isn't really a big issue, but image clipping will be added later.
Quote:
It appears that stuff marked as "Minor" tends to not be fixed (which is fair enough), but unfortunately I wrongly marked one of my reports as Minor although I subsequently decided it was actually important :( so I hope "Minor" reports also get read fully.
Everything gets looked at eventually. Any issue in particular that you have in mind here? If this is about the GUI element updating, I *think* it has been fixed in the meantime. There where some refresh problems that have been tackled. I'll verify.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
But you maybe know that the real hardest part with the Firefox port (after the port in itself of course) still the user interface adaptation and the user interaction in general, don't you ?
While the user interface stuff in Firefox was an initial hurdle, I wouldn't put it as the hardest part of the port. The hardest part is finding out what is called. The Mozilla platform is very modular, with components being used for almost everything. That means that a lot of calls are done indirectly via generated interfaces, and this generally means there is no real connection or obvious static call graph that can be used. Finding out what gets called when (or whether it is C++ code or Javascript) is the real challenge.
In the end, with the transition to Cairo, user interface code boils down to "simple" hierarchical window/widget handling. All in all this comes down to about 10k lines of code for the user interface/widget stuff. But there are more subtle issues.
For example, threading uses pthreads, but condition variables in pthreads used with more than one mutex yields "undefined behavior" according to the specification. Yet, the threading in NSPR assumes that it works. This is a hidden side effect that never even popped up until we started with the audio playback code.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Never had this problem, but it seems to point at an issue with FontConfig. You may need to rebuild the font-config cache. I know there is an issue with OWB-MUI, the fontconfig clashes with Timberwolf's for some reason. Try to rebuild the cache, and see if that fixes the problem.
Yep now i also think that problem is related to MUI OWB, infact i note this problem when i start TW having MUI OWB already opened in background, i will check
Quote:
Not likely to happen I'm afraid. The GUI is the same on all platforms, the only thing that could be done would be to have a theme that more closely resembles AmigaOS/Reaction. Not going to be Thom or me, though :)
Well as i said no one think to have a TW GUI that resamble at 100% the usual standard Reaction GUI, this is normal but .. for example look at this Firefox screenshoot under MacOS X
- Menu aren't inside the program like Windows/Linux but they are accessible on top (standard menu in MacOS but also on AmigaOS of course)
- The vertical scrollbar at the right are embedded like any other OSX "native" program, instead current Timberwolf's scrollbar (under AmigaOS4) is showed inside the window and not as a part of it ... it look like an owner Firefox widget instead ..
That are only a couple of examples .. sure not all can be adapted as it should but some work can be done i think, look at the current QT port by Alfkil, menus are now in a parfect AmigaOS style
Quote:
Not likely to change until after the final release. The first thing is stability, and a straight port of the codebase. Optimizations come later.
Yep is understandable, aniway for example any attempt to try a more recent version of Cairo ?
I note that since it was ported for a few projects outside our specific area (Odyssey Web Browser port under MOS and AROS) a lot of progress in term of speed was done (in certain case the speed increase was up to 40%!)
Maybe it could also help Timberwolf ?
Quote:
While the user interface stuff in Firefox was an initial hurdle, I wouldn't put it as the hardest part of the port. The hardest part is finding out what is called. The Mozilla platform is very modular, with components being used for almost everything. That means that a lot of calls are done indirectly via generated interfaces, and this generally means there is no real connection or obvious static call graph that can be used. Finding out what gets called when (or whether it is C++ code or Javascript) is the real challenge.
In the end, with the transition to Cairo, user interface code boils down to "simple" hierarchical window/widget handling. All in all this comes down to about 10k lines of code for the user interface/widget stuff. But there are more subtle issues.
For example, threading uses pthreads, but condition variables in pthreads used with more than one mutex yields "undefined behavior" according to the specification. Yet, the threading in NSPR assumes that it works. This is a hidden side effect that never even popped up until we started with the audio playback code.
- A more "native" GUI still essential and maybe this is the biggest part to do, a not easy job i think
Not likely to happen I'm afraid. The GUI is the same on all platforms, the only thing that could be done would be to have a theme that more closely resembles AmigaOS/Reaction. Not going to be Thom or me, though :)
Surely you will add some proper menus rather than those inline abominations that TW now has ?
That should be a minimum requirement for any Amiga application.
As should an Arexx interface, is this planned or not ?
Everything gets looked at eventually. Any issue in particular that you have in mind here? If this is about the GUI element updating, I *think* it has been fixed in the meantime.
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
Donate
