-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate code from aseprite to laf #2
Comments
Any update on this one; "Move the ui library from aseprite to laf::ui namespace." ? I'm currently using SDL with Skia, but considering using LAF. As far as I can see, it needs the ui modules and perhaps some more. Am I correct? |
Hi @YumaTheCompanion, the Anyway there are no short-term plans to move the |
Other thing I forgot to mention, is that the |
Hi @dacap , I checked (actually read the library from top to bottom) the LAF library and yes there are some things that needs to be done, true. However, as a starting point, maybe we can add simple functionality? By that I mean this: normally, I use SDL and GPU render the skia surface into SDL window. However, as far as I can see, LAF uses native Cocoa to create the window. Am I right? So basically, if you can create a simple and functionaly LAF library that just generates native window handles (Windows, *nix, MacOS) and passes them to Skia with GPU rendering, a lot of people would be able to experiment and even contribute. |
So as of now, just a basic window handle is more than enough for most people. I generally develop on a mac, and I'd much prefer cocoa+metal window rather than an SDL+opengl window (OpenGL is deprecated with OSX 10.14). |
There are some progress for the GPU renderer (search for SK_SUPPORT_GPU), and at least I do have plans to provide what you said 👍 I'll start creating some examples in the project so we can start finally adding/fixing the GPU support. Then, it would be great to expose more of the Skia API (or a way to expose the Skia API directly, anyway I'm not a big fan of this, because the Skia API changes from time to time too). |
Ah great, I think GPU support is a good place to start finishing. Some examples would be nice, as you said. And yes, Skia API has changed over time, even the official website of theirs have deprecated api. Perhaps we can come up with some sort of a wrapper? Let me know if there is anything I can help. |
The first step I'll make is creating a simple example, for this I want to remove pixman, freetype, and harfbuzz as direct dependencies (and use all the Skia API for drawing text). The idea is to create a Skia wrapper little by little (some examples of wrappers are os::ColorSpace or os::Surface:: drawSurfaceNine()). |
A simple example, as you mentioned, could be nice. For example, you could make a working version of the sample code about text manipulation, residing in skia/samplecode. Most of them requires adjustment, as of now. We definitely need to create a Skia wrapper. Because, almost none of the sample code on Skia library works out-of-the-box. All has either deprecated API or some weird data structure. I haven't checked much, but "Chromium" has some rather up to date Skia usage. Maybe that'll help? I'm working on a project, it's basically a lightweight cross-platform, cross-language IDE. The current options are: use wxWidgets or Qt (too restrictive or large), or use Skia (too much DIY). I think there is an opportunity there, to give rise to a new open-source UI framework, that resides in the middle of both parties. I bet a lot of people could be interested in developing it as OSS, if the right steps are taken. |
I'm preparing a basic "helloworld" example as a first step so I can get rid some dependencies (so maybe we can depend on Skia only, and not on freetype/harfbuzz/pixman) and improve the compilation of the library alone. I've no plans to provide a full Skia wrapper on |
I've created a project to keep track of the progress: https://github.com/aseprite/laf/projects/1 |
I've pushed some code in the refactors branch. |
Evolving API sounds good, as providing a full wrapper would be cumbersome and kind of hard to direct.
Yes, that'll be most perfect. |
Nice. If I can, ill test on my mac 10.14 mojave and report issues if any. For one thing, on my system, I had to compile with This is because I cant somehow use Skia with my Xcode on my custom project without the debug symbols. Anyway, if you can put up the "HelloWorld" example, I'll immediately try it with your official Skia branch and build instructions and report back. |
👍 Yeah, no problem, actually we should be able to use different Skia compilations (and try to support as many different compilation switches as possible)
A simple helloworld example is already published in the refactors branch. Check it out and see if it does work 👍(I've compiled it on macOS and Windows). (It doesn't support OpenGL yet.) |
I've checked the HelloWorld example. Here are my results: Step 1) First, it did not compile, complaining that
This generates cmake files successfuly. Step 3) Used An warning at 67/128 After a couple more warnings: But, the file is there on the filesystem. What can be the problem? |
🤔 Just in case check your
|
Did you check out the branch |
No, I was using the official one. Let me try m71 branch of yours. Also, I've checked the CMakeCache.txt file, everything seems okay. |
Okay, downloaded and built m71 branch as instructed on your page. It builds successfully, without errors. After that, tried to compile LAF with the following cmake flags:
I needed to turn off tests because of some library error : Anyway, with that, I compile with this return value: I assume this is a successful compile? I'm asking because there is no "helloworld" example and no "example" folder. What could be wrong? |
Ah okay, I was working on master branch, not refactor branch. There's still a compile error though, probably some dependency is missing. I'll try to figure it out and get back to you. 👍 |
My plans for the UI part of the laf library are:
laf::os
namespace.laf::ui
namespace.The text was updated successfully, but these errors were encountered: