my feedback and suggestions

First impression (talking about lc master 2.0.0rc2 on Debian/sid):

wow, clean, unpretentious (it it's best, positive meaning) surface. That is what I am mostly missing on other progamms. Worst counterexample: open-/libreoffice. But generally there a few exeptions from program (tool-) bars being overloded with a nightmere of colored icons. LC is one of thoses exceptions (the "simple" iconset for opera, available only for older versions and the "plume"-skin for xmms are the only other exceptions that I know off). Thank you for careing about what is important and what not. And I know it is much more difficult to stick to frugalness, plainness (here, too, I am not sure I use the right wording, I didn't want to write "simplicity" because it may have a derogatory connotation. I here too mean it in its best, positive meaning) then to throw around multi-coloured icons in the hope to solve ... I don't know what. It is pure distraction.
Why so many words about this simple fact? Because it *is* important to me, to my work. I do not want the program surface to distract me with colour noise. "Keep it simple, stupid" is a saying to which I can see the lc-programmers stick. And I say you help me (and hopefully not only me) to create clear layouts ("Keep it simple, you tasteless pal").

In the same categotry belongs the introduction of architectural ticks. As far as dimensions are concerned that's what I want . Points/drops may be acceptable as well, but filled (with black colour) arrows are to heavy. So thanks for adding ticks.
I'd appreciate it, if you would find a way to seperate the picking of edges of a construction element from  the beginning of the "helping line" (I don't know the right wording; I mean the orthogonal line to the dimensioning line pointing to the elements edge). I wonder If you can't make it possible to create a "mask" around the floor plan which would mark the beginning of the "helping line" independently from where it is picked (I could work around this shortcoming, but this inceases the amount of needed lines in the background and thus makes it harder to stay on top of things).

A thing which I find irritating (but I am afraid it may not be easy to circumwent) is the shifting of the drawing when an optional submenu opens in the side bar. This unwanted jumping of the drawing makes me nervous.  I may get adapted to it, but I'd preferre the drawing remaining where I put it.

The hatch dialog seems somewhat instable. I was able to hatch (in my case fill it completly) all elements of a layer. But I was/was not able to hatch a single of the same elements. I got error messages like: "element has to be atomic" which I did not even understand. The respective elements were closed polylines and a rectangle (which seems one can hatch).

So far, so good.

I used to use qcad (which was ls's predecessor in Debian). I have no real insight what were the reasons for the fork. Yes, open source is freedom of choice (more with Linux, less with MS/Mac), but it often is also a waste or profusion of ressouces. Yes, users like me want *not* all, but many things for free, programmers don't want to slave-drive themselves, enterprises want and need to earn money.

What little I am willing to donate (from that little I earn with my last drawing, created with lc) I can not. Because I have no credit card and no paypal account (and *no*, I won't create one; I strongly detest it).
Is there no way you have some european bank account to which (beginning 2014) one could assign money for inland charges within the SEPA countries. I'd ok with being remided to donate part of what I earn with using lc (but only *if* I earn something). I'd support a campain of people being asked to recall what they have earned using lc and giving a part of it, each time they get something.
I have no clue if there is a way for lc and qcad coming together agian. The solution (in the long run) cannot be all for free for some and slave-driving themselves for others.
I wonder if showing numbers openly ($,€) could be salubrious.  

Thanks.

hey,

The fork of librecad started when i needed some CNC futures, so i could generate gcode straight from qCAD. When i discovered that qcad was still based on qt3 i decided to start a port to qt4 so it could be compiled on more modern distro's because they where dropping support for qt3. One thingled to a other and after a couple of weeks digging into the code i could build windows, osx and linux versions of qcad. This gained some attention and i decided to make a more official fork and called it librecad.

About the bank account, i do have a personal account, but we have enough money to keep the servers running and pay for the monthly fee's. Please remember you can also support on just being active on the forum, work on documentation etc. for us at the moment far more important then raw $$$.

Lastly, i want to thank you for you kind words., btw, where you zzz on irc? When i came to my computer zzz user left already from the channel.

Can you explain the jumping with more details? I can not see an issue with drawing positions by the CAD sidebar(or you are talking about other side bars?).

hatching is quite ugly due to a bad algorithm in use.

I plan to get a clean/robust algorithm for 2.1 (after form release of 2.0.0).

please register an account and add new ideas for useful features for your need.

mhld wrote

A thing which I find irritating (but I am afraid it may not be easy to circumwent) is the shifting of the drawing when an optional submenu opens in the side bar. This unwanted jumping of the drawing makes me nervous.  I may get adapted to it, but I'd preferre the drawing remaining where I put it.

The hatch dialog seems somewhat instable. I was able to hatch (in my case fill it completly) all elements of a layer. But I was/was not able to hatch a single of the same elements. I got error messages like: "element has to be atomic" which I did not even understand. The respective elements were closed polylines and a rectangle (which seems one can hatch).