Hi Team,
I would again like to work on LibreCAD this GSoC, I look forward to work on LibreCAD v3 again and bring it to a much more developed and mature stage. Would like to hear on this. |
First, we are not accepted yet.
If that's a yes, you are welcome to explore interesting ways to work on the project again.
|
Administrator
|
dli,
I didn't sign up for mentoring at all, and I am not sure if that's possible at this stage. Either way, I am happy to help for LC3 Gaganjyot, LC3 hasn't been touched in a while which is sorta sad... But what sort of functionality do you think we should add? DLi, I am asking you the same :) I am personally like to see a framework for a UI starting to see + saving of files, this will give us a head start to working on something usable. Kind Regards, R. van Twisk Freelance Software Engineer Tel:+31.6.820.53.703 Tel:+1.803.426.3350 Skype:<a href="callto:r.vantwisk" style="font-family: 'Avenir Book', 'Lucida Grande', Verdana, Arial, sans-serif; font-size: 11px; color: rgb(96, 111, 120); text-decoration: none;" class="">r.vantwisk Chat:[hidden email] web:http://riesvantwisk.com
|
I think it would be useful to work on reproducing the boost functions / classes we use in LC2.
Then we could drop boost as a dependency. |
I feel we should rely on boost more :)
as I'm still very interested to see boost geometry (voronoi) in LC.
|
Oh right...
What are the generic systems that LC3 is lacking? |
In reply to this post by R. van Twisk
@Ries, exactly my thoughts,
We should focus this time on building some sort of user interface, My be using Qt, Web ( GL/ HTML Canvas ) ( POC Needed yet ), when we are able to create the entities via mouse interactions and save them to files, we will be able to test LC in a better way, Further, enabling actions like snapping, trimming, cut, extend and others. With web, I just wonder if Web Canvas could handle about 1 Million entities or not. My thoughts are involving sockets to send and receive data ( HTML Canvas to our LC kernel and vice versa ). http://electron.atom.io/ is a good option if we go web way. Otherwise we have Qt. |
hi gagan,
I have been talking about HTML5 for a while, but only talking so far. JavaScript has been highly optimized nowadays, and we talking about running tens of millions of JS lines/second. I suppose we can limit usage to canvas 2D for the time being. what about file saving? do we need cloud (NoSQL)?
|
@Dli,
Thanks for the support on Web side, what I thought was as follows, Creating LibreCAD kernel as a server. That could listen on sockets ( Preferably ) other option being JSON. Creating a Frontend using something like Electron Or may be even directly using Chrome/Chromium. The frontend will note the points and send it to our LibreCAD kernel and LC will process it and send back the information. I wonder a few questions, Do we keep all data in LibreCAD kernel only? I mean lets say we want to zoom in/zoom out, at that moment will we be sending the zoom command request to LC kernel which will decide what will be drawn and how much etc or that will be done at front end by some replicated code in JS. Regarding your thought on Files/Data storage method, Since I think we are including the LibreCAD v3 Kernel as backend, we can use DXF too. TBH I didn't thought it as a web based cloud service at the moment ( although I thought that in past ). I thought it as both services running on a users computer ( server and frontend both ), It removed the Qt and also opened door for even a web based service also just as you are thinking now. So since my thought was limited to single machine for the moment, I thought using DXF format only. But if we move towards cloud platform, we can use NoSQL too, Mongo seems pretty much good for this. Instead of writing it to a DXF file, we can just write it to Mongo. Will be fine in both the ways. |
In reply to this post by gaganjyot
I've been using Atom and GitHub Desktop, which I believe are both using electron.
They work a lot better on OS X 10.11.3 than on Windows 7, but honestly the performance is not great. If it has performance issues with a text editor... I have two main concerns regarding web based CAD: - performance will be less than that of LC2 - GUI customization will be less than that of LC2 And the question would be: Why do I want to "upgrade" to LC3? I still think we need to make a separate "LibreCAD Engine" repository, if the intention is to make something independent of a GUI. LC3 needs to be the name of our next generation program as a whole. Personally I think Qt's drag and drop toolbars and dockwidgets are really valuable. I also think http://doc.qt.io/qt-5/graphicsview.html will make things much easier. Ries commented about some zoom issues, but the QGraphicsView is based on QWidget which is what we use in LC2... so theoretically we can achieve the same results. Otherwise it's a bug that needs to be reported to Qt. |
Administrator
|
Sorry, I have no idea what that is :)
Do not forget that current LibreCAD isn't optimised at all to support large number of entities. DLI know's this also very well when it compes to intersection calculations and doing this in polylines. LC3 has this already solved in such a way that we can modify and extend based on interfaces.
I am not worried abotu the GUI (buttons, menu's etc...)
it's both a development question aswell as getting rid of a lot of legacy code that's now GPLv2, if we move to a MIT style then it open's ope development towards company's that cannot include GPLv2/v3. Since CAD is more of a pro tool, this 'might' help.
We have a separate repository for LC3
For UI of LC only I don't have a problem, as long as the core engine doesn't need Qt
The QGraphicsView of Qt is really bloated and make a strong dependency towards Qt. The idea of LibreCAD 3 is that it can be loaded in other applications in such a way that they don't have to include such a large Library as Qt.
|
"Sorry, I have no idea what that is :)"
https://atom.io/ "Do not forget that current LibreCAD isn't optimised at all to support large number of entities." I'm currently looking at various optimizations in general. Although, optimizations being equal, compiled C++ code will outperform JavaScript as far as I know. "We have a separate repository for LC3" Yes, but LibreCAD 3 is logically a single program that people use to produce drawings. That doesn't seem to be what you are talking about. We need another name for this "core engine" and logically a separate repository. What are the elements of this core engine? Which of those elements have already been created? "The QGraphicsView of Qt is really bloated and make a strong dependency towards Qt. I wouldn't disagree that it is bloated; however, much of that "bloat" is useful for a CAD program. "The idea of LibreCAD 3 is that it can be loaded in other applications in such a way that they don't have to include such a large Library as Qt." And that is why "LibreCAD 3" is not appropriate as the name of this project. We need to offer LibreCAD 3 as a replacement program for our current users of LibreCAD 2. Additionally we will have a LibreCAD Engine to offer to developers. |
Administrator
|
The Engine itself is currently called lckernel (LibreCAD Kernel) see https://github.com/LibreCAD/LibreCAD_3/tree/master/lckernel this is the core engine that hold's the geometry and does the hard work. We have a pluggable viewer called lcviewerqt (https://github.com/LibreCAD/LibreCAD_3/tree/master/lcviewernoqt) And a VERY simple UI (https://github.com/LibreCAD/LibreCAD_3/tree/master/lcUI), used for debugging perpose. the current system is designed such that you can have a display remote from the kernel. You can communicate with the kernel via a API to add entities and manipulate them. The kernel will send out message you can subscribe into to show the kernel's state, eg, view drawing and follow all changes. Currently it's just naming of items, and I am ok for better namings but that's the least of the priorities. If you look at the code you will see that the lcUI contains Qt code and dependencies, however the kernel and the viewer are not. We already have a command line version of LibreCAD with limited functions that can create drawings and spit out a image, this all without the need for Qt. That also means that if we design it correctly other applications can include LibreCAD without having to worry about using Qt. THis include any javascript eg web based applications. I believe this will create more freedom. This version of LibreCAD also contains it's own version of a QuadTree to optimise various operations that can be used for re-drawing quickly a limited set of entities or returning all entites very quickly within a specific bounding box. Something that QGraphicsView also use, except now we have full control over it and we don't have to put widgets in a graphics view anyways.
|
Thanks :-]
The repository could benefit from information like that in the README. If we know what has been accomplished and what needs to be accomplished then we can more easily find where to start. |
In reply to this post by ravas
On Thu, Feb 25, 2016 at 2:24 AM, ravas [via LibreCAD] <[hidden email]> wrote: Well using Qt allover doesn't bugs me enough if I am getting a very good software to use, If people are working on CAD they definitely have good machines and loading Qt won't be enough of issue. But I agree with Ries too on the part that Kernel should be Qt free, I think LC running over servers, people communicating to LC engines running on servers, via web app, via Qt app or even via console mode ( a REPL mode for LC ). So I am fine with Kernel Qt Free and frontend can be anything, Qt, Web or anything else.I've been using Atom and GitHub Desktop, which I believe are both using electron. Agreed on this. That's why I asked others. For the same. But point also lies that whole atom is built on JS whereas we just want our front renderer in JS. Rest we will be having is LibreCAD Kernel which is already built to some extent and that in C++. So there's hope for performance improvement. I totally agree with you that it might not be as performing as Qt/GTK+ or such thing. But look at other benefits, we could have web based CAD from the same. I have two main concerns regarding web based CAD: Can't say on this but, web CAD possibly will be slower than pure native QT/OpenGL - GUI customization will be less than that of LC2 Could you give some example with respect to this? Actually I didn't get this one, I think it would be heavily customizable if properly designed. And the question would be: Why do I want to "upgrade" to LC3? Better answered by Ries + Further I look it as collaboratively editable CAD. Kernel is thread safe, we believe we could enable multiple users work on same drawing. May be via sockets on Qt desktop or may be via web. Personally I think Qt's drag and drop toolbars and dockwidgets are really valuable. Thanks
Gaganjyot "Jai Sai Naath" |
This post was updated on .
"Could you give some example with respect to this? Actually I didn't get this one, I think it would be heavily customizable if properly designed."
QDockWidget and QToolbar can be dragged and dropped to the top, bottom, left or right of the screen. They can also be arranged and resized. They can also be floating, as if separate from the program. "Further I look it as collaboratively editable CAD. Kernel is thread safe, we believe we could enable multiple users work on same drawing. May be via sockets on Qt desktop or may be via web." That does sound like something useful. --- To be clear: I'm not opposed to a web based version. I just want LibreCAD 3 to surpass LibreCAD 2 in all areas. What will be offered to developers is a different topic; and that is why I'm an advocate for at least two repositories. I'm not sure I fully understand what the "kernel" is. Is it supposed to act as the model of a MVC pattern? Let's pretend I am a developer who has decided to use the Qt Graphics View Framework. How can I use this "LibreCAD Engine" (developers package)? Is the kernel equivalent to the QGraphicsScene? Is the view equivalent to the QGraphicsView? Does your engine provide mouse, keyboard and other device handling (the controller aspect)? If the answers to all of those is "Yes", then it seems like I wouldn't really benefit from this project, in the sense that it's mostly redundant to the Qt framework. Are there other generic elements that I could use? |
Thinking more about it from the perspective of someone already using the Qt Graphics View Framework,
I would be more inclined to use Qt as much as possible, and make things "Qt generic". Therefore, I drop my advocacy for using it. Generic: - geometry / transformations - unit conversion - fonts - hatch patterns - cad file templates / blocks Qt bound: - scene (model) - canvas (view) - customization / plugins - hotkeys / commands - toolbars & other widgets - objects - actions - device event handling - cross-platform - layers - hatch - block - reading / writing files - documents - undo stack - snapping - printing - dimensions - text |
Free forum by Nabble | Edit this page |