I have just tested easyimagesizer, and I cannot reproduce your problem with the ASL requester. If I can't reproduce it, it is going to be very hard to solve...
Nothing much to report. I took a little time off from the project, because my mind was going crazy, but now I'm back. Currently I am trying to get my grips on Warp3D, so that I can fix the problems with minigl.
Btw, i think you know from last posts on aw.net and on hyperion's blog, that Karlos are the one of the best persons currently to talk about warp3d problems and stuff. He write new permedia2 driver for w3d , as well as he already do some fixes in r200 w3d driver. So if you will have any problems in w3d terms, i am almost sure that he will help you (he help me a lot with w3d back in the past).
Good, did you found also the remaining minor issue on the installer and so on ?
To sum them, they are:
- LibIntl.so are not copied by the installer so you need to check it manually
- After a reboot you always need to add a manually assign when you start the first example (a unique assign is then enough for start all examples you want) (but this need to be fixed at 100% i think)
- Some graphics corruptions here and there and a couple of not working examples (Charactermap example is DSI affected AFAIK) see my report at page 14
After that i think we can consider it 100% stable, then we may (as betatester) can concentrate on the "big" things
- The "cygnix:" assign problem seems to come from fontconfig, I might not be able to fix it.
- About graphics corruption, we are talking about two different issues: a) texture corruption and b) blocked text. I have solved b), and I have been told that a) should be fixed with the upcomming update for the os.
EDIT: Also "charactermap" doesn't seem to crash any more, it is horribly slow, but doesn't crash .
- The "cygnix:" assign problem seems to come from fontconfig, I might not be able to fix it.
Are you sure ? I use fontconfig for mui-owb, and have no assigns problems related to cygnix. Looks like you compiled fontconfig over cygnix, and it just automatically put some crap in the fontconfig.a (imho)
- The "cygnix:" assign problem seems to come from fontconfig, I might not be able to fix it.
Maybe a new reason to switch to the native fonts ?
Very good that you fix the others, hopefully update 3 will resolve all the remaining issue, i'm crossing finger expecially about the problem on the windows's autoallineaments !
Fresh version has been dropped in the upload queue at os4depot. Highlights include
- delayed opening of windows to avoid the "window alignment" issues - "blocked text" bug has been fixed
Other than that, not much new... I must admit, that I have somewhat given up fixing the speed issues, there are simply too many things involved with it, and too much is depending on opengl features, that we do not have. I was able for a minute to improve speed of the "demos/affine" example, but the price I was paying was, that the whole interface rendering was totally destroyed. I'm betting, though, that a proper MESA implementation is going to help a lot.
Also, the alignment issue means, that windows are sometimes _very_ slow at opening, but there is only so much I can do about it. It's either or for annoying alignment or late opening...
Thanks Alfkil, i didn't retry yet all examples in archive but i fell they are ok as we did an extensive test before
The installer also seems finally good, no error or missing libs and i appreciate a lot the correct mouse wheel behaviour and the fact that QT doesn't seems to ask for an assign when you start your first example, excellent !
All great ? No yet IMHO, while is good that you are working on the resize issue, now we can't resize that windows at all even if the resize gadget still present graphically in GUI, this is a bit annoying expecially when certain window (such the one using for the calculator are too big and the font are enourmous)
So how about permit a resize but only in a delimited area that doesn't change too mutch the "prefixed" dimention ?
For example permit any type of resize only when this doesn't hide the text (the numbers talking about the Calculator example) or make graphical corruptions
I think that time arrive to use native fonts instead of FontConfig expecially now that on some examples we can't resize that windows at all
Finally some internal QT resize gadget may be eliminated (?)
About "window opening is now delayed to avoid the irritating alignment issues"
It's ok but they need to mutch time to be opened, except on a few examples.
But If i choose "About" from Demos/TextEdit example all seems quite fast, on the other examples they take 4 or 5 seconds before opening their about window so maybe there is a way to improve here
To the end some graphical corruptions still but maybe we can solve it automatically when Update 3 will be released
A couple of features request for the next release:
- An iconify gadget for all examples - Adding mouse wheel support also for all the various dropdown/choose gradgets ! - An option in Prefs program to kill the shell output ?
Many thanks and congrats for all what you have done
The reason, that the calculator example has fixed size but still has a size gadget is, that the fixed size is given to the widget after the window has been created. If you try the "animation/animatedtiles" example, you will see, that the size gadget is off. This is because the code does something like this:
...where the last line creates and opens the window. This would of course be very easy to implement in the calculator example, but I have choosen not to beacuse I want as little change to the example code as possible.
Here the "demos/textedit" about window is as slow as the other ones, don't know why it would appear faster on your system...
About your requests:
- Iconify gadget: Should be possible - Mouse wheel for popups: Maybe, I will see what I can do - Kill the shell output: This will of course be removed entirely when I do the "final" release
I must admit, that I have somewhat given up fixing the speed issues, there are simply too many things involved with it, and too much is depending on opengl features, that we do not have. I was able for a minute to improve speed of the "demos/affine" example, but the price I was paying was, that the whole interface rendering was totally destroyed. I'm betting, though, that a proper MESA implementation is going to help a lot.
I don't know how it is implemented, but would it perhaps be possible to rip out all the graphics drawing code and replace it with your own implementation? You could then use graphics.library and/or Cairo and drop MiniGL entirely. I imagine it is a lot of work though.
Yep i understand your point of view and the reason but while this solution can solve one problem it open the door of various other "limitation" on the framework IMHO !
That's why i ask about making (if possible) an intelligent and delimited window resize that stop resizing (only) at some point.
You may stop resizing when the delimited area will reach the "fonts area" for example stopping the window resize on the Calculator example only when user reach the buttons area or somethings similar
That's of course just an idea, maybe there will be other solutions out there
The reason, that the calculator example has fixed size but still has a size gadget is, that the fixed size is given to the widget after the window has been created. If you try the "animation/animatedtiles" example, you will see, that the size gadget is off. This is because the code does something like this:
...where the last line creates and opens the window
Bearing in mind I don't know QT yet (I assume the "widget" is the window?), I don't see why that causes the window to be un-resizable. Surely you avoid creating the Intuition window until the window's show() method???
If QT has no clear-cut distinction between "building" & "in-use" phases for the window (unlike say my OOP GUI system), then surely you avoid building anything (like Intuition windows) until the window is first shown?
edit: added "un" infront of "resizable", doh.
Edited by ChrisH on 2011/6/26 23:26:29 Edited by ChrisH on 2011/6/26 23:26:59
I don't know how it is implemented, but would it perhaps be possible to rip out all the graphics drawing code and replace it with your own implementation? You could then use graphics.library and/or Cairo and drop MiniGL entirely. I imagine it is a lot of work though.
Actually, that was what I was doing in the very beginning. You can see how it looks, in the very first screenshot I posted:
I don't think it would be feasible to follow that path, as everything is going to be fine with the current path as soon as we have mesa. Just be patient .
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
.
