Maybe its better just do it all internally, so no themes needs when new one will be done. I mean maybe some parsing of os4 configs and apply the same on. Any change then in system settings in that terms, will lead to automate change of look of qt to be the same as system apps which is good.
Don't know, i will not play too mutch with the internals because we will never know the side effect of such operation
In that case integrate a theme and make it selectable from QtPrefs could be pretty enough imho .. but still personally i like the current graphics, expecially the Plastique theme
@alfkil Should to say that its pretty cool how far you got with QT. I was in fear it all will drops soon or later until it will reach usable state. But now, when i test smTube and qpdfview, and have no single crash with any of them while use them both at one time for a hour already, i can say that it was worth of it 100%. Some bugs and improvements still need it, but its really usable. If only our sobjes was real shared ..
Sadly he won't be able to do anything about a "theme". You have to program it. I already had a look at the Qt style mechanism and we have three possible solutions:
- .css/style sheet: more or less useless, because you have to do this on per application basis and everyone porting an app has to do this more or less from the scratch - except by pure chance the original was programmed with style sheets in mind. AFAIK 99% of Qt apps don't use this feature.
- libamigaosstyleplugin.so: This has to be programmed and must be implemented by the porter of any Qt app - but is far easier than the above mentioned style sheet option.
REMARK: I already have some basic libamigaosstyleplugin.so on my hard disk - maybe this could be the starting point...
- libQtGUI.so: The style could be part of the standard styles in the central GUI component and the user can change this through the Qt prefs program. But it's more or less the same as with the plugin option: Some one has to program the stye.
REMARK 2: Just for info - the source code for one style is somewhere around 2000 (motif) - 3500 lines (plastic) of pure C++ code with very few incorporated data sets (icon images etc.).
REMARK 2: Just for info - the source code for one style is somewhere around 2000 (motif) - 3500 lines (plastic) of pure C++ code with very few incorporated data sets (icon images etc.).
The imagery should be able to be nicked from Intuition - all the little cycle gadget, frames, etc are constructed using image subclasses (sysiclass etc) and frameiclass. If you can read the GUI prefs (there's a function for that) and get a BOOPSI Image into a QImage, it should be "easy" to make a native theme.
I have some tools and applications, that compile (and run) just nicely but always come back with "(unexpected) unfreed signals" errors after they quit. Is this a known issue of the framework or an application specific behavior? I must admit that I'm not sure how I should go after this error and how to do a usable debug to find the culprit...any tips are welcome!
The signal errors you are seeing are definetely from Qt interally, as there are no signals allocated in the app specific code. I know some of these issues, and I have a hard time judging where they come from. For one thing, they were not always there, so something I did invoked them. I will try and look into it.
Styles: Qt on MacOS, Windoze and Gnome has built in system specific styles, that use system gadgets instead of rendering functions. These styles are pretty complicated, though, so just finding out, if it would ever in face be possible with ReAction or MUI is a monstrous task, let alone implementing the eventually conceived solution. I am not too keen on going into this, since I believe (as many do) that the now offered basic styles look "nice". One thing also, that could tip the bucket in favor of not going into this project at all is the intuition, that the Qt gui environment is very rich compared to ReAction and MUI, which are, to say the least, limited. On that account, it seems from the beginning like an impossible task.
Of course there is, as mentioned, the solution of doing a basic rendered style that "looks like" Reaction or MUI, but since this task require a combination of graphics and programming skills, it is doubtful whether anyone would be willing, let alone able, to take it up.
Indeed looking somewhat deeper into the sources for the standard Qt styles rose some horror inside... I wouldn't say it's impossible, but it's a HUGE task (read: make something that *looks* like the standard MUI/Reaction classes).
Quote:
For one thing, they were not always there, so something I did invoked them. I will try and look into it.
That's what I saw as well - sometimes this happens, sometimes not. Thanks for your efforts.
//: Please replace by file name of localized help if available, e.g. "help_fr.html". m_textBrowser->setSource(QUrl(tr("help.html")));
It sets the search paths for QTextBrowser, and the source is set to a URL (presumably something like file:///help.html - hence why it tries to find help.html: ), but then it just uses this verbatim rather than searching all the paths for it.
So I think that's a Qt bug but I'm not entirely convinced, and I don't think I can fix it within qpdfview in a way that would be acceptable (I don't want to keep hacking it in, or lose the multiple language support).
I am not sure how Qt is supposed to do that. There seems to be different versions of standard paths for different things on different platforms. Have you got any idea, where it is *supposed* to look for that file? I mean "QUrl(whatever)" is a pretty broad term...
By the way, I announced my availability for Qt updates and other Amiga related bussiness next week. That is a truth with modfication, because tomorrow (monday) is completely swamped with other stuff. So if you want to reach me, go for tuesday or later. Cheers! :)
I'm not sure how it is supposed to do it either (on any platform). The path is in the line above (setsearchpath - there are two paths, DATA_INSTALL_PATH is actually the correct one), although I doubt QUrl uses that, it seems to only be for QTextBrowser.
I just happened to find the "open containing folder" feature in qpdfview, and it tries to open a directory as a file:// address in MUI-OWB, which doesn't support such a thing. I've just knocked up a little script to open these in WB, but of course it only works when using launch-handler.