Qt Native News

not needed for a first release imo, but i bet it will come later!

... so ... today is the day? =)

@spotup
Already in upload query on os4depot :)

Thanks, I try it in these Holydays.

oh man! how cool is that! i will try it right away!..

oh noes... no sdk no fun.
will the sdk get released today as well?
i thought it would.

@spotUP

Patience, padawan I just need to fix the include files, then upload.

=)

does it still require a custom minigl build?

I download the examples and the SKD, but before install it I have a question. I have the Amicygnix QT version, there'a a problem, I must uninstalled or I can leave it ?

Thanks

@alfkil

As you expect, there i am with my tests :))

So, first and imho important moment which imho will not bad somehow to update: the very long waiting of firstly runned QT apps (i think its the moment while fontconfig generation happens ?). Because for first running of any demos/example it take about 3-5 minuts without any saying what is happens.

Maybe you can add some callback (as we do in OWB), which will show to user (on the first running stage) progress bar of font idexation and all of this will be happens in the window, with words "you run QT app first time ! Qt should generate fontcache (as it use fontconfig) , so stay tuned ! It will happens only once !" , and while user have that reaction-based window with that words, progress bar at bottom of window show that font-indexation is happens.

Of course better to remove font-config dependence at all, and replace it by our font stuff (as joerg do for ra-owb) , but even notify window will be for sure better, in compare with just long waiting without any words what is happens.

btw. Where font-config cache file are writes ? In the same directory where qt installed ?

The next moment: its something wrong on my peg2/latest os4 with your minigl libs. All the apps which use opengl, works much-much slower with your libs, and much-much faster with public 2.5 ones. Maybe its related to peg2 itself, or even maybe its related that you have beta-version of OS components and something was fixed in it , dunno, but i think i should to point on that as well anyway.

So, lets test the stuff:

DEMOS

Affine

Slow. With your libs absolutly unusable and madness slow, with public 2.5 more or less usable, but as well just 2-3fps and i see how drawing of menu happens on running stage. But it works, runs/exits fine.

Books

More or less fast, but after running i also see how drawing happens. Not slow as Affine of course, but visibly. Buttons reacts fast, but (i think again its because of our public buggy texture-trashing minigl), after i press 2-3 times on buttons, text just garbled by the black rectanlges. Check image:



chip

After running it going to the line : GraphicsSystemFactory::create: "opengl" and then, 40-45 seconds of nothing happens. Then grey window (for 7-10 seconds), and then actual stuff draws. Then , if i move slider in the first area it scrolls more or less fine, but, if i tick "opengl", then everythinkg start to be slow like hell. Its with public minigl2.5. With your minigl/mglut everthing is start to be even worse :) Loading the same 40-45 seconds, but then grey window, 30 seconds of waiting before drawing is starts, and then usuall-for-your-opengl-libs-on-my-setup-madness-slowdown : redrawing takes about 2-3 minuts (to draw all the images), and i even not wait for the final redraw and just reboot.

embedded dialogs

Slow. With minigl2.5 : 5-7 fps , with your one 1 (or less) fps.

mainwindow

More or less fine. I see redrawing on running through , and menu buggy: on some of them i cant choice anything, because its autocloses.

spreadsheet

More or less fine , but usuall slow a bit. And also changing of cursors fucks a bit. I.e. you start to sort out tables, cursor show you that you in sortable mode, then you move cursor on the scroll bar, and you still have that cursor like you sort the tables.

textedit

Fine one , but also a bit slow, cursor a bit fucks to detect what it mean , and as usuall after some usage on public minigl/warp3d trashing of textures :)

undo

Slow.

In conclussion about Demos: I thinks after you add OpenGL support everythere, everything start to be slower in compare with just plain raw cpu. Dunno why, but i remember that for example EmbeddedDialogs was 100% faster in your initial releases , but now its just slow all the time. Cursor also a bit wrong detect when to be changes (in the demos where you can sort out tables, etc). Also everythere where you have "about" and "about QT" when user press on it, its firstly show some strange smal window over the whole screen, then close it, and then spawn about window.


Examples

Examples/Animation

Animatedtiles

Fast one. Feels good, looks good (with public minigl2.5) , but stack on exit with some DOS error about "process blablal", with your one : everything stat to be slow, and the same stack on exit.

appchooser

Fast, good

easing

Fast, good. Fast on scrolling, fast on moving, fast on pressing marks , etc. Feels very good (but with your minigl libs are slow as usuall on my setup). And same problems with cursor that it sometime start to be not what it should to be currently.

moveblock

Fast, good.

Stickman

Fast, good, after resizing to small window scrolling also fast and good.

Conclussion about Examples/Animation: good, fast and all is fine.

Examples/Drag&Drop

DraggableIcons

After few drags DSI:

Quote:

If press ignore DSI, then DOS window with words : a process has attempter to re-close a closed file, process:draggableicons, fucntion : close() , and in shell:

Quote:

puzzle

Works fast , drags fast (through i see that images are blinks where i drag them, like there is not double-buffering), also on running some small window which autocloses, and looks like whole puzzle abit not centered or a bit wrong with chords .. Or i just dunno how it should to be :) But looks like a bit wrong:



Examples/Effects/lighting

Slow

Examples/graphicsview

anchorlayout

Moving of window are very slow. Even slower if i use AmyCygnix and trying to move windowses in it.

basicgraphicslayout

Moving of window are slow.

collidingmice

Works fast. But when i trying to drag by scrollbar, then DSI:

Quote:

diagramscene

Pretty fast ! Drawing, typing, moving, rotating : all is more it less fine and fast ! Through the same curcor problems, and drawing of menus not very fast. But good enough.

dragdroprobot

Good one :) Fast as well, but also looks like no-double-buffering, a bit blinking there and there, small visual glitches because of that, but overral fine and good :)

elasticnodes

The one of the best examples !! Very responsive !! Pretty fast, pretty good looking. I like it a lot ! The only problem that mouse wheel and + - as example says not works. But the whole its good. I can drag and move parts, and all is fine.

portedasteroids

Fast one. Almost SuperStardust :) After resizing working area centered well as well , good.

portedcanvas

Works fine and fast. Menus as usually not-very fast , but the moving of pieces in the main working area are fast and good. Pretty "native" feel.


Examples/MainWindows

Application

Very good in terms of typing in the main area. But still same "a bit slow" menu, and not native file-requesters also a bit not so fast. Also some windowses which autocloses. But what is good : typing of actual text and working with it (marking / deleting / pasting /etc) - are fast and good.

docwidgets

Works, through resorting of areas slow (the same slow as moving of windowses), and all the othes usuall stuff with menu, cursor, etc.

mdi

Works, and must to say pretty fast (even moving of that window when you do "new").

Networks/DownloadManager

Just works. Almost Curl :)


OpenGL/2dpainting

Speed of Native and Opengl - 1:1 the same. Also stack on exit with Minigl watch-dog , but i think its about the same problem for which you do your own libs. Also in shell it says:

Quote:

OpenGL/HelloGL

Very fast and respons. All works fine and very good. That one are for sure one of the good one.

Examples/Painting/

basicdrawing

Works pretty fine. Drop-down menus a bit not fast, but overall are fast enough on my peg2.

concentriccircles

works fine and fast even with resizing to big size.

fontsampler

Works fine. Navigation over menu and fonts not ultra-fast, but fine enough.

imagecomposition

Works fine

painterpaths

Works fine

svggenerator

works

svgviewer

Rendering are slow. 2-3 fps on default scene.

Transformations

Works.

examples/tutorials/addressbook/part7

Works

Widgets

AnalogClock

works fine

Calculator

Works fine. Through not very fast redrawing after resizing (can see grey area).

calendarwidget

Not very fast on loading, take few seconds after grey screen is happens, then fast drawing (but still i can see how it draw fast), and then all is fine. Works and so on.

codeeditor

Fast as native.

Digital Clock, GroupBox, Lineedits, Sliders and all the others - works, and actually all works, but the same small problems like a bit slow menus, a bit not fast initial drawing (and whole redrawing) and so on. Some of them very fast and respons. , but some of them (expectually those ones, with heavy menus, etc) are not.


In end of all of test what i can say:

You do really hard job ! I am not sure that anyone else will be brave enough to take such kind of works for yourself, and be at the stage where you already with that. Its of course have still some "thinkg on which need to works", but overall its pretty interesting to play with.

Now there is some "what need to do from users point of view" (if you doesnt mind of course:) ) :

Need to add some user-friendly window about font-cache-generation
Need to fix cursor to detect when need to change state correctly
Navigation over the menus a bit slow
Some examples are very slow because of OpenGL problems (imho)
Moving of windowses sometime very slow (the same OpenGL problems imho)
Add where it possible put amigaos analogs (asl and crap).
Stedup and one more spedup everything where is posible. Some examples looks pretty slow on my peg2 (where all the menus, buttons, markable labels, drop down menus and alt).
Add amiga-style theme (if possible of course)

That all about what i can think for now.. Personally for me the only SpedUp are matter, to make just everything works fast, and almost as native , other ones are not so important.

@RIBDEVIL

You can leave the Amicygnix version as long as you just change the assign and path lines in user-startup.

@kas1e

Thanks for all the input, I will take a closer look at it tomorrow when I have time again .

I have libssl-0.9.8.so, where do i get libssl.so.1.0.0?

I soft linked it, now it asks me for libcrypto

@LiveForIt
libopenssl.lha on os4depot have all the stuff inside (1.0.0c together with ssl and crypto).

@alfkil
If you need any help with testing/etc, i am 100% in :)

@kas1e

Wow, a great report here !

I notice the same things of you altrough i didn't detailed publically as you did (bravo !)

Surely we need more speed and (IMHO more important for now) correct some aspect of the graphics along with a more native interface

About speed for example (as you say) CodeEditor in widgets folder it's quite fast like any other MUI or Reaction interface i can say but sadly that isn't true fon many of the other examples, so speed is mandatory expecially when someone of us decide to write real applications using QT

Second is the UI, if you look on the MacOS X QT apps you can't notice any difference between "native" and QT apps, look at this ARORA grab

https://lh5.googleusercontent.com/_g_3 ... 4t1k/s640/desktop_osx.png

So Mac world prove that is possible, this is a single but HUGE good news

I know this wants time, the same questions are damned the Haiku community since 2009, time time time ...

@Alfkil

Please mate don't give up, that's would be a looong story

Finally managed to get a "proper" Qt app compiled.

Extreme Image Converter

It is seriously hampered by the crappy Qt file requester, but does actually seem to work.

Might need running from the Shell with large stack rather than the icon.

is someone brave enough to take this on? :D
it could give us a proper terminal.

http://qt-apps.org/content/show.php/qPutty?content=118372

qterminal might be an easier option.. but i failed.

@Crhis
Well, i tryed: sort of works. Starting of programm through are slow (but its fault of QT itself), take about 7-8 second on my peg2 to start. And file requesters fucked very well , unpossible to use :( All those assigns , etc .. + those file requesters are slow , just like you use AmiCygnix (no native feel), and everything react a bit slow :(

But well, its all beta still :)

@alfkil
It is possible to release later one build with debug-info included and without ? I just think that maybe without debug info loading of .sobjs to memory will be faster ? (and so starting of QT programms will be faster ?). Also for release without debug info, you can try to "strip" the sobjest (to make them smaller, so maybe they will loads a bit faster). Also add optimisation flags (if you are not already, like -O3)

Broken link.
I enter by the web

http://www.unsatisfactorysoftware.co.uk/