www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - WildCAD - a simple 2D drawing application

reply Johann Lermer <johann.lermer elvin.eu> writes:
Hi,

I'd like to announce a little project of mine that started some 
years ago as a C++ application and which I finally managed to 
port to D. It's called WildCAD and it's a simple 2D drawing 
program (you know - lines, circles and so on). It uses a command 
line interface inspired by AutoCAD and features a very immature 
DXF im- and export.

The application uses a DIY widget set (which comes as a sub 
project) called WildWidgets. Both can be found at 
https://gitlab.com/elvin.eu/wildcad.git and 
https://gitlab.com/elvin.eu/wildwidgets.git

Currently both are restricted to DMD and Linux/X11 only. Sorry 
for that. On the plus side just very limited dependencies are 
needed - mostly X11, Cairo and Cups. It's still very rough and 
using it can be a bit of a challenge.

Any feedback or help is appreciated ;-)
Jan 25 2023
next sibling parent reply Dadoum <dadoum protonmail.com> writes:
On Wednesday, 25 January 2023 at 14:36:54 UTC, Johann Lermer 
wrote:

 Hi,

 I'd like to announce a little project of mine that started some 
 years ago as a C++ application and which I finally managed to 
 port to D. It's called WildCAD and it's a simple 2D drawing 
 program (you know - lines, circles and so on). It uses a 
 command line interface inspired by AutoCAD and features a very 
 immature DXF im- and export.

 The application uses a DIY widget set (which comes as a sub 
 project) called WildWidgets. Both can be found at 
 https://gitlab.com/elvin.eu/wildcad.git and 
 https://gitlab.com/elvin.eu/wildwidgets.git

 Currently both are restricted to DMD and Linux/X11 only. Sorry 
 for that. On the plus side just very limited dependencies are 
 needed - mostly X11, Cairo and Cups. It's still very rough and 
 using it can be a bit of a challenge.

 Any feedback or help is appreciated ;-)


Hello, cool work.

Just a small tip: add screenshots in your readmes. It will make 
people more interested  because when there are none, usually 
people will not take the time to fetch the project to check it 
out.
Jan 26 2023
parent Johann Lermer <johann.lermer elvin.eu> writes:
On Thursday, 26 January 2023 at 13:23:46 UTC, Dadoum wrote:


 Just a small tip: add screenshots in your readmes.


Good idea. I'll do that.
Jan 27 2023
prev sibling next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
I briefly played around with it, not bad at all. I did see the 
menus popped up in the wrong place though, something to note is 
that ConfigureNotify is a bit complicated in how it works. Let me 
copy/paste a comment from my simpledisplay.d:

/+
         The ICCCM says window managers must send a synthetic 
event when the window
         is moved but NOT when it is resized. In the resize case, 
an event is sent
         with position (0, 0) which can be wrong and break the dpi 
calculations.

         So we only consider the synthetic events from the WM and 
otherwise
         need to wait for some other event to get the position 
which... sucks.
+/
if(event.send_event) {
         win.screenPositionKnown = true;
         win.screenPositionX = event.x;
         win.screenPositionY = event.y;
}



You can also request the window position with 
XTranslateCoordinates:

int x, y;
Window dummyw;
XTranslateCoordinates(dpy, window.nativeHandle, RootWindow(dpy, 
DefaultScreen(dpy)), x, y, &x, &y, &dummyw);



Which is what I do when it is time to pop up a menu.


Your thing works ok when maximized tho, it is kinda nice how you 
got the rest working.

But as a fellow DIY widgetset author it is always fun to compare 
and contrast :)

And since some of these X things are a bit obscure it helps to 
steal tips from each other lol
Jan 26 2023
next sibling parent Johann Lermer <johann.lermer elvin.eu> writes:
On Thursday, 26 January 2023 at 14:31:55 UTC, Adam D Ruppe wrote:


 I briefly played around with it, not bad at all. I did see the 
 menus popped up in the wrong place though, something to note is 
 that ConfigureNotify is a bit complicated in how it works. Let 
 me copy/paste a comment from my simpledisplay.d:


True, although here it works. But X11 is a beast and sometimes I 
loose the fight.


 You can also request the window position with 
 XTranslateCoordinates:


I'll try that, thanks.


 And since some of these X things are a bit obscure


no one ever spoke a truer word :-))
Jan 27 2023
prev sibling next sibling parent reply Johann Lermer <johann.lermer elvin.eu> writes:
On Thursday, 26 January 2023 at 14:31:55 UTC, Adam D Ruppe wrote:


  I did see the menus popped up in the wrong place though


sorry to bother you again. But I can't reproduce this error, here 
the menus are always on the spot. Where exactly does this happen 
to you and what window manager do you use?
Jan 30 2023
parent Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 30 January 2023 at 13:51:14 UTC, Johann Lermer wrote:

 Where exactly does this happen to you and what window manager 
 do you use?


I use old Blackbox. But it happens always, you click the window 
and it pops up as if the window is at (0, 0) instead of where it 
actually is.

Probably due to the configure notify message not including 
location data (which window managers don't have to send)
Jan 30 2023
prev sibling parent reply Johann Lermer <johann.lermer elvin.eu> writes:
On Thursday, 26 January 2023 at 14:31:55 UTC, Adam D Ruppe wrote:

 I did see the menus popped up in the wrong place though


That at least should be fixed now.
Feb 03 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 3 February 2023 at 08:30:55 UTC, Johann Lermer wrote:

 That at least should be fixed now.


Confirmed, works here now!

BTW I did `time make -j6` this time and it said 10 seconds, so 
still think the dmd -i approach better but if your incremental 
builds are smaller it might be better, I did git pull so of 
course that meant a lot of things were changed anyway.
Feb 03 2023
parent Johann Lermer <johann.lermer elvin.eu> writes:
On Friday, 3 February 2023 at 21:05:36 UTC, Adam D Ruppe wrote:


 BTW I did `time make -j6` this time and it said 10 seconds, so 
 still think the dmd -i approach better but if your incremental 
 builds are smaller it might be better, I did git pull so of 
 course that meant a lot of things were changed anyway.


I tried -i as well but ran into a problem with X11 functions that 
are not defined (I didn't convert every X11 header to D and 
obviously some dependency  is missing - maybe I converted too 
much for my purpose. I just wonder that you did't run into the 
same problem. Mysterious...) so for the time being I'd like to 
focus more on the program than on the build system. But it's only 
delayed, not forgotten.

Btw. about the C libraries, I also tried using the new C header 
import but failed quite miserably - too many errors with macros 
and so on. So that is delayed as well.
Feb 03 2023
prev sibling next sibling parent reply Ferhat =?UTF-8?B?S3VydHVsbXXFnw==?= <aferust gmail.com> writes:
On Wednesday, 25 January 2023 at 14:36:54 UTC, Johann Lermer 
wrote:

 Hi,

 I'd like to announce a little project of mine that started some 
 years ago as a C++ application and which I finally managed to 
 port to D. It's called WildCAD and it's a simple 2D drawing 
 program (you know - lines, circles and so on). It uses a 
 command line interface inspired by AutoCAD and features a very 
 immature DXF im- and export.

 The application uses a DIY widget set (which comes as a sub 
 project) called WildWidgets. Both can be found at 
 https://gitlab.com/elvin.eu/wildcad.git and 
 https://gitlab.com/elvin.eu/wildwidgets.git

 Currently both are restricted to DMD and Linux/X11 only. Sorry 
 for that. On the plus side just very limited dependencies are 
 needed - mostly X11, Cairo and Cups. It's still very rough and 
 using it can be a bit of a challenge.

 Any feedback or help is appreciated ;-)


this reminded me of KediCAD[1]. The author used the Gambas 
programming language. A long time ago, I chatted with the author, 
and he was thinking of an alternative language for development. I 
knew nothing about d at that time. I have just noticed that the 
author closed the source, or I failed to find it. I think D has 
great potential for creating CAD software. I will give it a try, 
but I wish it would use dub as a build system.

1: https://sourceforge.net/projects/parduscad/
Jan 26 2023
parent reply Johann Lermer <johann.lermer elvin.eu> writes:
On Thursday, 26 January 2023 at 14:48:17 UTC, Ferhat Kurtulmuş 
wrote:

 I will give it a try, but I wish it would use dub as a build 
 system.


Well, I tried dub and wasn't convinced - maybe due to a lack of 
documentation but I couldn't get it running the way I wanted 
(that is, with my directory structure and having wildwidgets as a 
subproject). So I decided, that I'll stick with what I know and 
that is good old make ;-)

But maybe someday someone can do something about it?
Jan 29 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
dub isn't the issue, people who fight it like this, fight the D 
compilers and end up having issues.

You're fundamentally doing something that D compilers are not designed 
to handle. The problem is with -I flag. Being able to set a directory to 
look modules up in.

Problem is it needs to match the packages to directories.

I.e.

wildwidgets/lib/source/wcw/clipboard.d

Not:

wildwidgets/lib/source/clipboard.d

Also note: you should not use symlinks with VCS, there are 
cross-platform problems with it.
Jan 29 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 29 January 2023 at 13:55:41 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 dub isn't the issue, people who fight it like this, fight the D 
 compilers and end up having issues.


dub fights D compilers. This is why it forces me to write 600 
lines of ugly configuration file for something that just works in 
dmd.


That said, the directory layout here is indeed not optimal, and 
the makefile build takes *forever* which is disturbing. This 
program should probably build in < 3 seconds, not the... minute 
or two it took running make here.

Proof:

$ time dmd -i wildcad.d -I../../widgets/lib/source/ 
-I../../widgets/include -version=X11 -L-lX11 -L-lcups 
-L-lfontconfig -L-lcairo

real    0m2.703s

Fully operational executable created in under 3 seconds.
Jan 29 2023
next sibling parent reply Johann Lermer <johann.lermer elvin.eu> writes:
On Sunday, 29 January 2023 at 15:01:40 UTC, Adam D Ruppe wrote:


 Fully operational executable created in under 3 seconds.


right - but isn't one of make's features, that it compiles code 
only when the source changes? When you just compile the whole 
thing at once, I would expect that you get longer times than when 
you change just one source file and compile just that.

Well, that's the theory. It seems, that in the meantime 
everything depends on everything and so even small changes in the 
code lead to a recompiling of quite a few files and now every 
time even a small change takes even longer to recompile than your 
approach.

Maybe it's just better to remove the whole make stuff - but it 
seemed to be a good idea at the time...
Jan 29 2023
parent Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 29 January 2023 at 17:14:40 UTC, Johann Lermer wrote:

 right - but isn't one of make's features, that it compiles code 
 only when the source changes? When you just compile the whole 
 thing at once, I would expect that you get longer times than 
 when you change just one source file and compile just that.


When your whole rebuild is fast enough, it doesn't really matter 
anymore.


 Well, that's the theory. It seems, that in the meantime 
 everything depends on everything and so even small changes in 
 the code lead to a recompiling of quite a few files and now 
 every time even a small change takes even longer to recompile 
 than your approach.


Yeah, for an incremental rebuild to work well, you need to have 
pretty strict dependency discipline so chances actually can be 
isolated, and in D as well, you need to make sure your modules 
don't do much work just by being imported (just being referenced 
can trigger some compile time functions, for example, and if you 
compile things separately that depend on this, it gets done 
multiple times instead of just once like in the all-at-once 
build). This can be done, but it takes attention and often just 
isn't worth the hassle compared to the simple build, especially 
when the simple build does a decent job out of the box.


 Maybe it's just better to remove the whole make stuff - but it 
 seemed to be a good idea at the time...


I often make makefiles just cuz im used to typing `make`... but 
the contents are often:

all:
    dmd -i main.d

and i let the compiler do its thing.
Jan 29 2023
prev sibling parent reply bachmeier <no spam.net> writes:
On Sunday, 29 January 2023 at 15:01:40 UTC, Adam D Ruppe wrote:


 dub fights D compilers. This is why it forces me to write 600 
 lines of ugly configuration file for something that just works 
 in dmd.


I don't want to get sucked into another discussion of the pros 
and cons of Dub, but yeah, if you put your code in directories 
that match the modules you want to import, there's no need for 
Dub and the corresponding poorly documented configuration.
Jan 29 2023
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Monday, 30 January 2023 at 02:44:50 UTC, bachmeier wrote:

 if you put your code in directories that match the modules you 
 want to import,
 there's no need for Dub and the corresponding poorly documented 
 configuration.


What is poorly documented? Can you suggest some documentation 
improvements?
Jan 29 2023
parent reply bachmeier <no spam.net> writes:
On Monday, 30 January 2023 at 04:40:48 UTC, Siarhei Siamashka 
wrote:

 On Monday, 30 January 2023 at 02:44:50 UTC, bachmeier wrote:

 if you put your code in directories that match the modules you 
 want to import,
 there's no need for Dub and the corresponding poorly 
 documented configuration.


 What is poorly documented? Can you suggest some documentation 
 improvements?


That ship has sailed. I've given up on Dub because those who 
promote it aren't interested in criticism. I'll just link to 
[this page](https://dub.pm/package-format-json) and if anyone 
thinks that's acceptable documentation for someone new to the 
language, there's no point having a conversation about it.
Jan 30 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 31/01/2023 9:39 AM, bachmeier wrote:

 On Monday, 30 January 2023 at 04:40:48 UTC, Siarhei Siamashka wrote:

 On Monday, 30 January 2023 at 02:44:50 UTC, bachmeier wrote:

 if you put your code in directories that match the modules you want 
 to import,
 there's no need for Dub and the corresponding poorly documented 
 configuration.


 What is poorly documented? Can you suggest some documentation 
 improvements?


 
 That ship has sailed. I've given up on Dub because those who promote it 
 aren't interested in criticism. I'll just link to [this 
 page](https://dub.pm/package-format-json) and if anyone thinks that's 
 acceptable documentation for someone new to the language, there's no 
 point having a conversation about it.


It isn't. WebFreak has an on-going project to replace it.

https://forum.dlang.org/post/ojoiwbcftqsxbsvivghz forum.dlang.org

https://docs.webfreak.org/
Jan 30 2023
parent reply bachmeier <no spam.net> writes:
On Monday, 30 January 2023 at 20:51:59 UTC, Richard (Rikki) 
Andrew Cattermole wrote:


 It isn't. WebFreak has an on-going project to replace it.

 https://forum.dlang.org/post/ojoiwbcftqsxbsvivghz forum.dlang.org

 https://docs.webfreak.org/


That's quite an improvement. Perhaps it should be announced 
again, because I don't remember seeing the original post.
Jan 31 2023
parent reply WebFreak001 <d.forum webfreak.org> writes:
On Tuesday, 31 January 2023 at 15:03:50 UTC, bachmeier wrote:

 On Monday, 30 January 2023 at 20:51:59 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:


 It isn't. WebFreak has an on-going project to replace it.

 https://forum.dlang.org/post/ojoiwbcftqsxbsvivghz forum.dlang.org

 https://docs.webfreak.org/


 That's quite an improvement. Perhaps it should be announced 
 again, because I don't remember seeing the original post.


I already posted it twice on two separate dates and tried to bump 
them after some time too, I think there is just not much demand 
in improved DUB docs, people probably think it's kinda fine 
already.

However for newcomers I think it's very worthwhile to do more 
stuff on there.
Jan 31 2023
parent Hipreme <msnmancini hotmail.com> writes:
On Tuesday, 31 January 2023 at 21:14:04 UTC, WebFreak001 wrote:

 On Tuesday, 31 January 2023 at 15:03:50 UTC, bachmeier wrote:

 On Monday, 30 January 2023 at 20:51:59 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:


 It isn't. WebFreak has an on-going project to replace it.

 https://forum.dlang.org/post/ojoiwbcftqsxbsvivghz forum.dlang.org

 https://docs.webfreak.org/


 That's quite an improvement. Perhaps it should be announced 
 again, because I don't remember seeing the original post.


 I already posted it twice on two separate dates and tried to 
 bump them after some time too, I think there is just not much 
 demand in improved DUB docs, people probably think it's kinda 
 fine already.

 However for newcomers I think it's very worthwhile to do more 
 stuff on there.


I'll try writing recipe projects in future as dub examples. 
Although I'm nearly dropping dub in favor of my own build system, 
I think I've already played a lot into writing different kind of 
projects with different use-cases, such as using optional 
dependencies, building for various platforms, using custom 
runtimes. From the projects I've seen on dub.pm I think most 
usually only stick to the basics which is acceptable for small 
projects
Feb 01 2023
prev sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, Jan 30, 2023 at 08:39:33PM +0000, bachmeier via Digitalmars-d-announce
wrote:

 On Monday, 30 January 2023 at 04:40:48 UTC, Siarhei Siamashka wrote:

 On Monday, 30 January 2023 at 02:44:50 UTC, bachmeier wrote:

 if you put your code in directories that match the modules you
 want to import, there's no need for Dub and the corresponding
 poorly documented configuration.


 
 What is poorly documented? Can you suggest some documentation
 improvements?


 
 That ship has sailed. I've given up on Dub because those who promote
 it aren't interested in criticism. I'll just link to [this
 page](https://dub.pm/package-format-json) and if anyone thinks that's
 acceptable documentation for someone new to the language, there's no
 point having a conversation about it.


+1.  What we need is a dub tutorial that leads you step-by-step how to
set up a project, what to put in the config file, explain what each
config item means (at least for the basic cases), and a FAQ explaining
commonly encountered issues and how to resolve them (or why a particular
use case is not possible).

Yes, all of this information is already there on the linked page. But a
newcomer (1) does not know 80% of what the items there even mean, (2)
does not understand how dub uses this information and what effects they
have, and (3) does not know which 5 of the 100 or so pieces of
information on the page are relevant to him, right at this moment. The
linked page may arguably be useful as a reference for someone who
already knows dub well, but it's completely obtuse to something who
doesn't know what dub is.

Even as a reference, the information isn't organized in an easily
navigable way. It's basically one giant infodump of the absolute bare
minimum information you need to remind yourself how to do a particular
task, but to someone who doesn't already know dub, it looks disorganized
and thrown together in a completely arbitrary, opaque order.

For example, the very first section talks about "global scope". What's a
"global scope" and why do I need it?  Who knows, who cares, here are all
the settings that go into "global scope", you go figure it out yourself.
Immediately following is the section "sub packages". There is no
explanation of what's a "sub package" and why I might want one until the
second paragraph, which contains a single sentence that's supposed to
magically make me understand why I might want a sub package.  I
basically have to read through the whole thing, digest it, connect the
dotted lines myself, before I can even have an answer to the most basic
of questions, "what is this and why should I care about it?". In the
meantime there's all kinds of random statements aimed at experienced
users, recommendations for best practices without any context or
explanation of why they're recommended (you're expected to figure it out
yourself).

The paragraph before the last code block in this section ("Sub
packages") is a typical example: "It is also possible to define the sub
packages within the root package file, but note that it is generally
discouraged to put the source code of multiple sub packages into the
same source folder." In one sentence the document has managed to (1)
introduce a possible configuration without any explanation of why one
might want to do that and (2) contradict itself by saying this is
generally discouraged. Then (3) the remainder of the paragraph goes on
to completely negate the first part of the first sentence, complete with
a code example of, I guess, what not to do? Why is all of this even
here?!  If something is a discouraged practice, it sholdn't be smack in
my face right in the middle of the docs, occupying at least half of the
entire section(!).  First document what I *should* do, then in a
footnote or a separate page explain what to avoid.  And explain why I
might want a "sub package" instead of assuming I already know what it
is.

And on and on and on. The order of sections is, to put it mildly, hard
to follow.  As an infodump, it's not suitable material to introduce
someone to dub. There's no explanation of common use cases, zero
hand-holding, and poor or missing motivation for anything. There's no
explanation of how to handle common use cases that one might encounter.
Maybe the explanation *is* in there somewhere, but I've no idea where it
is and have to essentially read through the entire thing to find it (and
hope I don't miss it).

As reference material, it's incomplete and could use better navigation.
And clearer explanation and definitions of what each config item does,
instead of 1-sentence descriptions that the reader has to collect then
somehow piece together in his head and magically guess the intent of
each feature. Also ALL corner cases must be covered thoroughly (if it's
to be a reference, it better be thorough!), as well as conceivable use
cases that someone might want but isn't supported. (And an explanation
of why it isn't supported would also be nice.)


T

-- 
Real men don't take backups. They put their source on a public FTP-server and
let the world mirror it. -- Linus Torvalds
Jan 30 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
Like this? https://docs.webfreak.org/getting-started/first-steps/
Jan 30 2023
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Tue, Jan 31, 2023 at 11:25:02AM +1300, Richard (Rikki) Andrew Cattermole via
Digitalmars-d-announce wrote:

 Like this? https://docs.webfreak.org/getting-started/first-steps/


Not bad!  Looks much more promising than the original page for sure.

Still ran into some issues though. The linked "recipes" page contains
tables that are far too wide for the width of the text block, forcing me
to have to scroll left and right to see the rest of the columns. This
makes it very painful to use.  The Build Settings section, for example,
has a table with overly-wide Name and Arguments column, such that the
description is invisible. The table is so long that at first glance
there's not even a scrollbar, leaving me wondering what's up with all
that blank space in the page.  The description column is also far too
narrow for the amount of text it contains; this makes it needlessly
cramped and the table longer than necessary.

I realize this is a WIP, but still missing is a page that explains dub's
operational model: what it does exactly, and how this relates to the
basic config items.  The "DUB Reference" tab AFAIK still links to that
1-page infodump I referred to in my other post (or at least some version
of it), so the points I raised still apply to that page.  Needs a lot
more work before this is usable as the official reference.



T

-- 
Кто везде - тот нигде.
Jan 30 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
I've gone ahead and pinged Jan on this. They didn't receive much 
feedback when first announced :)

Part of the problem is dub in general didn't receive much work done on 
it for the better part of 10 years. It has speed up within the last 
couple of years :) The registry and with that docs hasn't had that 
attention put towards it yet though.

I'm horrible at writing documentation, so I'm not much help here sadly.
Jan 30 2023
prev sibling parent Johann Lermer <johann.lermer elvin.eu> writes:
On Sunday, 29 January 2023 at 13:55:41 UTC, Richard (Rikki) 
Andrew Cattermole wrote:


 You're fundamentally doing something that D compilers are not 
 designed to handle. The problem is with -I flag. Being able to 
 set a directory to look modules up in.


I admit that's something I never fully understood. In the end I 
just fiddled around with make until I made it compiling...
Jan 29 2023
prev sibling parent Ulrich <kuettler gmail.com> writes:
On Wednesday, 25 January 2023 at 14:36:54 UTC, Johann Lermer 
wrote:

 Hi,

 I'd like to announce a little project of mine that started some 
 years ago as a C++ application and which I finally managed to 
 port to D. It's called WildCAD and it's a simple 2D drawing 
 program (you know - lines, circles and so on). It uses a 
 command line interface inspired by AutoCAD and features a very 
 immature DXF im- and export.

 [...]


Very very sweet. Works like a charm. It is the simple things that 
bring joy and happiness. Great work!
Jan 28 2023