Administrator
|
Hey Ravas, one of my very early versions ov LC3 did use graphics view but I abandoned for a couple of reasons: 1) It had drawing inaccuracies at higher zoom levels, this was also shown in tools like Draft Sight 2) It lacked some features we where needing in CAD, I cannot remember what exactly though (it's has been some years) 3) Qt is a very large library and I didn't want other applications that wanted to include LC3 to depend on such a large library as Qt, Also license of Qt might be a issue for such applications. 4) QTGraphicsView is a bit heavy by the way it works (memory consumption wise) and although I don't have seem deep understanding how the how's and why's, I just didn't want to take the risck to make that dependency because once you go that route, it's hard to go back from it. All in all there where a couple of point that made me decide to not use Qt for LC3's core libraries. I want to make a more Library based CAD tool rather then one application. Just to make it clear, the test UI of LibreCAD3 is build around Qt and that's perfectly fine and Qt is a great tool for that! Ries
|
Dankjewel!
Are you considering options other than Qt for the UI? |
Administrator
|
Yes, I have been looking into more lightwight UI's for the UI but also for in-drawing popups. For the same reason I states before is that when other applications (freecad/brlcad) include LC3 it would be nice if it's possible they have the same capabilities in terms of creating/modifying entities. I came across some UI frameworks but non that would me really wanted to try yet. Usually with UI framework they are targeted to one graphics framework so it makes UI frameworks less portable if you want to stick to one graphics framework.
|
In reply to this post by ravas
we talked (only talks, no code) about the possibility to use html5 for UI. In other words, it would be a web based 2D drawing/CAD.
It's doable, but a project too big for our available development time.
|
I'm enjoying working with Qt. The documentation and Qt Creator are both excellent.
Some part of my mind is against C++ to javascript conversion. I would start from scratch with paper.js, if I really wanted to make a web CAD. What do you think about these? http://www.fltk.org/doc-2.0/html/index.html http://cegui.org.uk/features http://www.wxwidgets.org/about/ (on github) |
we have been talking about a web based app by the same c++ code base, optional with Qt as well, based on "source-to-source" compiling.
This approach allows the idea of the same CAD engine in C++ used by different drawing engines: Qt: as in V2; cairo: headless example in V3; HTML5 canvas: PoC needed.
|
Two more projects worth noting for a web based version:
http://jsxgraph.uni-bayreuth.de/wp/home/features/ http://raphaeljs.com/ |
worth knowing about: http://blend2d.com/
|
Administrator
|
Very interesting find. I have gotten questions about OpenGL aswell. Do keep in mind that we need a bit of both with some control. For example like Graphics View Framework in Qt doesn't give you a lot of control (when I looked into it at least) when trying to display over 100K entities. Sure the demo's of Qt perform very well thank's to it's quadtree (or similar) style implementation but when you try to zoom out (display all) it's not fast anymore because it needs to render everything. So we need control over what we render, unless there is a system that doesn't have any issues rendering lots and lot's of entities at high res and +10 frames/sec. I also felt that Qt's Graphic View is a bit bloated, eg, the more entities you render, the more you blow up memory, just my opinion, and at the time I had issues with accuracy at high zoom levels, I also found that issue on DraftSight. In the end we need something plugable, like how LibreCAD 3 handles the rendering such that we can exchange one render engine for a other. Keep in mind that for us fast selections of entities is also very important, but this is I feel easer because this cna be handled using a quadtree very efficiently. just my 0.2 cents |
today's find: https://github.com/google/skia
|
Administrator
|
One big problem with Skia was, and I am not sure if it's still a issue that it's been in beta for long time and it's API keeps changing. Skia was developed for Chrome and google folk's just change skia whenever they feel Chrome needs a specific API. So it's hard to keep currently. One developer (GSoC student) tried to make a skia painter but it turned out not easy to get it going. Ries
|
Free forum by Nabble | Edit this page |