Install on Mac OS
Tags:
None
KDE Developer 
|
The main reason why Mac support is bad is that most developers don't have a Mac. Since we don't have the hardware it's practically not tested on OS X. Considering that it's quite surprising that it runs so good. Your screenshot was the first since this http://bsarempt.home.xs4all.nl/krita_osx.png from 2008.
For testing with Linux there are no big differences. Kubuntu had a few problems with tablet pressure recently. OpenSuse should work fine as far as I know. Looking at memory usage is always helpful. It's often a trade-off between performance and memory, so in some cases we cache data which cause more memory usage but speeds up some things. If you want to work on that there is lots of stuff to do, like improving painting performance or working with big images. Following the Apple HIG is a mixed thing. Of course we want the application to behave as native as possible. At the same time we also have to support other plattforms with different HIGs and introducing special case increases the maintainance work. If you want to change something you can of course make suggestions. Beside that it would be interesting to find out what exactly crashes and what let's it feel sluggish. |
|
KDE Developer
|
Could you post a screenshot with maximized Krita that we could use to blog about it?
|
Registered Member
|
Yes! Pretty amazing that it runs so smoothly actually. Hopefully this can spur some more interest for OS X
Ok. I happen to have an old Wacom tablet, would be interesting to see if it works...
I'll start looking into profiling the application. What would help is a sample workflow that your team uses to run quick regression tests. I'm not an artist, but if someone could outline some common steps/activities that I could script, it would help.
Yes it would definitely mean more maintenance and I'm actually not a big proponent of following Apple HIG to the letter. However, there may definitely be some areas that would benefit from finer OS X adjustments with very little pain. I think we're really talking about the underlying Qt/KDE platform here (and its support for the Mac), so a little more familiarity with the architecture is a must for me...I'll get back to you on that.
Again, surprisingly crash free once I got the build/install/paths/configuration down right. Still a little bit to do, but it's holding up quite well. I enjoy breaking things (smile) so I'll keep you posted. P |
|
Registered Member
|
Ok! Gimme a sec ... |
|
Registered Member
|
Two fullscreen shots:
With OS Stamps and About Krita Window...(BTW how do you get rid of the layer doc preview/info window? - may be a bug on the Mac - also affects the top Krita menu bar as all the menu items dissapear - and doesn't update itself when one switches layers or hovers over another layer thumbnail...)  Krita 2 On Lion (FullScreen) by pkouame, on Flickr Just a nice pic...  Krita 2 on Lion (Leonardo) by pkouame, on Flickr |
|
Registered Member
|
An update testing...
I get very consistent crashes on some tools: -fill -gradient -move layer immediately after clicking the icon. Here's a short backtrace ... they all seem to hang in exactly the same place:
Before I delve into the QT call, just wanted to know if this seems familiar. Also, I've built with qt-kde per the instructions here http://techbase.kde.org/Getting_Started/Build/Qt. However, the Mac Os X specific help page http://techbase.kde.org/Getting_Started/Build/Mac_OS_X recommends building from the Qt official open source package. I have them all, but a little confused at this point. The qt-kde distribution has been patched and tailored for KDE. (larger backtrace is available if it helps - but the snippet above is the crux of it) Thanks, Patrice |
|
KDE Developer
|
That's not a known problem so far. Backtrace looks like debugging symbols are missing.
|
KDE Developer
|
Hm, indeed. It definitely doesn't crash on Linux. As Sven says, without debug symbols it's hard to guess what's going on, and I'd like to see the whole stacktrace, not just the bit inside Qt.
|
|
Registered Member
|
Ok - promised myself no knew posts without results...and I have some...
My Lion development environment was still a little unstable, but I think I've actually figured out the whole dbus (definitely a little alient o the Mac) and coca deal ... good for another informative post. Since I'm slowly figuring the whole Qt+KDE+Calligra geography on the Mac, I have an idea to write a little Mac "sanity checker" script one could run after slogging through the whole builds. Something that would make sure the coca mime db was up-to-date (source of endless frustration), dbus was set up correctly, and all the critical environment variables are set correctly. Researching this bug with the Krita tools on Mac Lion forced me to test a whole variety of C/C++ IDEs and debuggers. I'm glad to say that Eclipse and Netbeans seem to run like champs. So those QtCreator from the development pack. Unfortunately KDevelop4 is VERY unstable. Can't get the darn thing to last more than 5 minutes without crashing. Same thing goes with Kdbg. Anyways, the last thing I need now is yet another piece of unstable code, so I'm glad to have a CMake friendly toolchain set up and alternatives. Back to the bug... The bug: The following tools ALL spin and die on Mac Lion after creating their respective option widgets: fill, gradient, measure, move, crop, and curve. How to reproduce: simple, bring up any document and hit those icons in the tool dock. After a few seconds you get the spinning ball of death. Results so far: I noticed a peculiarity with all those tools: they ALL call QWidget::SetFixedHeight() How did I come to this conclusion? Well, after a day of stepping through the code, I noticed some sort of infinite loop(?) during what seemed to be geometry related Qt calls. This occurs right after the respective option widget emit, which seems to work like a champ. The trace right after the successful emit is :
Then the infamous Qt setupLayout is called with the crash:
Qt seems to get hung up calling updateScrollbar and sizing calls repeatedly ... spins... and dies a miserable death. Which led me to suspect the same in Krita and finally the aforementioned hypothesis. Confirmation of bug: So I commented out the offending QWidget::setHeight() calls in all the respective QWidget* KisToolXYZ::createOptionWidget() and lo! Got my tools back and operational to boot! Even the ones with long scrollable option widgets work fine (at first blush...) Conclusion: Obviously just a workaround, but I'm wondering why the calls are even needed. So it would seem that something stinks in Qt or most likely the Qt Mac interface on Lion (?) I have not had a chance to test this on Leopard or Snow Leopard (even though I am building against 10.6sdk - Lion sdk 10.7 seems to break qt-kde...another indication that something stinks along that path?). Nor have I swapped out qt-kde with a more stable distribution (e.g. the latest QT Sdk 1.1.2 binaries and libraries for Mac which seem pretty stable) just for kicks. Lack of stamina I guess. My aim is to make the underlying Krita platform on Mac as solid as possible, so I WILL delve into this further. I desperately want to focus on Krita code proper, but first things first. A few answers to the following questions would simplify my life at the moment: Question 1-Is qt-kde up-to-date with the latest Qt development? Sure, I can look through the patch branches, but your insight may facilitate this task. Question 2-What are the salient points behind the KDE modifications to Qt. At a high level... Question 3-Will Krita/KDE simply not work with the out-of-box Qt for Mac? Either the official Nokia distro or the macports one (which is currently broken on Lion - I will file a bug by the way) ? I have the following on my critical Mac TODO list:
TODO 2- I get the following messages in my full debug log of a quickie Startup/Load Document/Quit: The FULL log of that session is below. If you see anything else of note, please advise! TODO 3-Fixing odd UI artifacts TODO 4-Tracing and performance profiling on Mac TODO 5-Build against Lion 10.7sdk (currently breaks) TODO 6-Developing a full automated regression test. Do you guys have one? TODO 7-An install script a la Kubuntiac's Kubuntu one. Maybe even using other installer packages. I know one is being built for Windows... TODO 8-Automating periodic builds TODO 9-Mac tuning for paint ops TODO 10-Mac specific plug-ins etc.... I hope this spurs on more support for me and my efforts. It's an adventure...especially since none of you have Macs to test with. I honestly believe that Krita can't ignore the Mac platform, it is growing in popularity as you all know. Darwin has its quirks, but at least it's Unix. There is also a lot to learn from the Mac HIG. At least in the US, a large number of digital artists have adopted the Mac as their platform of choice. One of the things that attracted me to Krita was the "User Centric focus" you guys have, you work with artists a lot and that's great... Nuff said about that... Tell me what you think... Regards, Patrice NB: something in my full debug session log breaks this post...will figure it out and post an addendum |
|
KDE Developer
|
Okay... The setFixedHeight thing is interesting: it's most likely a bug in Qt. We use it to make sure some option widgets don't grow, iirc. If would be okay to put #ifndef Q_WS_MAC around those statements.
The layer preview box sounds like another Qt bug on OSX: it's supposed to be a popup panel that automatically disappears. Does the preview disappear if you click on the canvas? Does the brush editor popup panel disappear if you click on the canvas? The kshareddatacache message is potentially serious: we need to ask Dmitry to make sure, but I think we need some special OSX code here. The next two messages aren't important, I think. All in all, great detective work! I wouldn't have guessed it to be this innocent setFixedHeight thing. If you have patches ifdeffing those out for OSX, please send them to me (boud@valdyas.org), and I'll make sure they get committed. |
KDE Developer
|
Great work! Feel free to pop-up on IRC too (irc.freenode.net, #krita)
Daylight is coming...
Krita developer | http://lukast.mediablog.sk/log |
|
Registered Member
|
Yes - kinda funny about the setFixedHeight thing. You know what? I just found and interesting piece of test code in the qt-kde test library: tests/auto/qlistview/test_qlistview.cpp . It has a suspicious function :
I may just be paranoid, but it would seem like this bad boy may have caused some problems in the past - deserving of its own stress test? Anyway, what a find. Guess I'll be able to fully test my hypothesis and make some progress. I DO suspect its either my "bleeding edge" configuration issue - the way I built qt-kde - the Mac sdk I am using...Any number of things before I call the Qt hotline! (smile) And yes, I'm sure the Krita call was there for a reason so I'm not pleased with the workaround. I'll hold off on an official "patch" until I am 100% sure. Seems like other panels are dismissed properly when clicked outside...will look into this further. Some of the interface bugs you had mentioned 3 years ago are popping up, so my TODO list is growing...he he .... Otherwise Krita is holding its own... @Lukas - thanks for the irc invite.... |
|
KDE Developer
|
|
|
KDE Developer
|
Hi! How you're doing? If you have any patches for Krita for OSX, don't hesitate to send them to me. I've seen that there's been lots of things happening on the kde-mac mailing list List (https://mail.kde.org/mailman/listinfo/kde-mac) recently -- Intevation is sponsoring a build server for kdepim on OSX and that means that some of the system bugs we've seen in this thread are being worked on!
|
|
Registered Member
|
Have you considered using Macport in order to get Qt and KDE framework working on your Mac ? Do you plan to distribute your work on the OSX version to Macport ? I'm currently using KMyMoney4 on my mac with Macport and it is very effective, compiling is very easy !!
|
Bookmarks
Who is online
Registered users: Bing [Bot], gfielding, Google [Bot], markhm, sethaaaa, Sogou [Bot], Yahoo [Bot]
