fling has quit [Remote host closed the connection]
fling has joined #openscad
LordOfBikes has joined #openscad
qeed_ has joined #openscad
qeed has quit [Ping timeout: 264 seconds]
anoblet has quit [Quit: Client closed]
noonien has joined #openscad
mmu_man has joined #openscad
mmu_man has quit [Ping timeout: 268 seconds]
Guest17 has joined #openscad
Guest17 has quit [Client Quit]
L29Ah has quit [Ping timeout: 264 seconds]
J79 is now known as J23k
Guest3 has joined #openscad
peepsalot has quit [Ping timeout: 256 seconds]
<Guest3>
I've noticed, that not only .ui files are invisible in Qt Creator project tree. There are also multiple .h file, which are not indexed by Qt Creator. Only Header-only files, which are stored in **GUI_HEADERS** variable are shown.
peepsalot has joined #openscad
<Guest3>
Qt Creator shows only ones, which are used in add_executable sources.
<Guest3>
The reason of not pointing .h and .ui files before is AUTOUIC cmake feature. It automatically searches for .h and .ui files, but Qt Creator is not getting them to show in project tree.
<Guest3>
I have one important question. Does added by hand .h and .ui files in **Source** variable in CMakeLists.txt affect build time in case of using AUTOUIC? After all, **Source** variable is used in **target_sources** for **OpenSCAD** target.
<teepee>
Guest3: I'm not sure, I would assume no impact on build time as cmake is not actually running the build itself but generates the build files
<teepee>
but if you propose a change that would help making the project structure better for qtcreator, that's still useful
<guso78[m]>
Could Qt creator BE an Alternative to cmake+make ?
<teepee>
no
<teepee>
it's an IDE, we need something to build headless on the CI servers too
<teepee>
I'm not even sure it has a native built-in build mechanism, the official build *was* qmake which is dead now
<teepee>
and I think the official Qt build is now cmake
mmu_man has joined #openscad
<Guest3>
Qt can vary between cmake, qmake and Qbs.
<Guest3>
----------
<Guest3>
teepee
<Guest3>
I mean, may my changes to Source variable cause to recomopile .ui files after AUTOUIC makes it first?
<guso78[m]>
Qt creator would have the Advantage to openscad because Developers could graphically edit ui Files. But they need to Be visible First 😄
<Guest3>
guso78[m]
<Guest3>
That is on what I am working on. =)
<teepee>
I can edit UI files graphically just fine from Netbeans :P
<teepee>
but I'm totally happy if we get a change in that makes it obvious and easy for QtCreator too
<teepee>
I would not expect any problems with recompiles, but I guess we can only try
<teepee>
I doubt there's a clear documentation describing exactly the difference. But if there's a documentation on how qtcreator expects things we can see if that has problems with other tools
<teepee>
Netbeans just shows the UI file in the tree and double click runs the external tool assigned to *.ui files which happens to be the qtdesigner
<Guest3>
Do I understand correctly:
<Guest3>
I should create new branch fetaure_branch for my change in fork on github.
<Guest3>
Work on it.
<Guest3>
Then create a PR: from fork's fetaure_branch to original's master branch.
<teepee>
yes, that's the general workflow for most cases
<teepee>
in theory you could use your master branch too, but that would restrict to a single change and cause issues updating with new stuff from the main repo
<teepee>
so following the master branch in the fork in your account and having a feature branch is safer
<Guest3>
> but that would restrict to a single change and cause issues updating with new stuff from the main repo
<Guest3>
May you give an example of such problem or "further reading"? =)
<Guest3>
Which restriction do you mean? Only one change by PR?
<teepee>
lets imagine you just freshly cloned the main repo, so both are in sync
<teepee>
now you start working on a change in your master branch and commit that to the fork in your account
<teepee>
in parallel someone pushes a change in the main repo to master via a PR
<teepee>
still all good, you could create a pull request from your master branch to the main repo and there are no issues with that
<teepee>
but
<Guest3>
Got it! I'll need to stash before synch, right?
<teepee>
1) you can't easily update you repo with the changes from the main repo anymore
<teepee>
2) if you want to work on a second thing, it gets messy
<teepee>
so it's not like it's impossible or *wrong*, but there's a good amount of potential trouble
<Guest3>
Also if other people's changes affect on my feature implementation.
<Guest3>
Thanks for explanation!
<Guest3>
Why src/gui/SparkleAutoUpdater.h is located here? It is not a GUI widget header.
<guso78[m]>
If you want To PR many Features, you will never BE able to publish a single Feature alone ....but this IS required because you cannot know in which Order your PR will BE accepted
<teepee>
Guest3: not GUI in sense of Qt, but in sense of "only compiled in when we compile with GUI support" I think
<teepee>
it's possible to build "HEADLESS" meaning no Qt, no GUI at all
<Guest3>
> it's possible to build "HEADLESS" meaning no Qt, no GUI at all
<Guest3>
Already noticed that while reading CMakeLists. Isn't it better to split Widget headers and other "gui-required" headers?
<guso78[m]>
This IS good Input! I never Tried to Compile my Branch with Headless. I am wondering If my QSettingsCached stuft will still Work.
<guso78[m]>
Teepee IS QSettingsCached available ad ITS Qt but nothing to Display ?
<teepee>
Guest3: maybe, this split is fairly new even. for a long time it was just all in one folder :)
<teepee>
guso78[m]: headless really means no Qt at all, e.g. for the WASM build we don't even try to build Qt for web (even though it's supposedly possible)
<Guest3>
guso78[m]
<Guest3>
> If you want To PR many Features, you will never BE able to publish a single Feature alone ....but this IS required because you cannot know in which Order your PR will BE accepted
<Guest3>
Do i understand correctly, that I should always push multiple dependent features together, in one PR?
<guso78[m]>
Guest3 you can make even trees of branches with Always Master Branch being root
<guso78[m]>
This IS how can do dependencies
mmu_man has quit [Ping timeout: 264 seconds]
mmu_man has joined #openscad
<Guest3>
@teepee
<Guest3>
> I'm not sure, I would assume no impact on build time as cmake is not actually running the build itself but generates the build files
<teepee>
yes, it's better if it can be avoided, but that's not always possible
<Guest3>
I mean, what if it causes to compile those files twice on lower level. I mean, when make will call compiler.
<teepee>
that would not be ideal, but in the grand theme of things it might not even be noticable overall
mmu_man has quit [Ping timeout: 265 seconds]
<teepee>
I would hope cmake knows how to deal with the GUI stuff in a reasonable way by now though
mmu_man has joined #openscad
<Guest3>
Okay. I'm just trying to make things less overhead. Thanks!
<teepee>
that's a good goal for sure
<Guest3>
Is it usual?
<Guest3>
Some non-fatal warnings and problems when compiling language files.
<teepee>
is there some nested repo going on, like having cloned somewhere up in the directory tree?
<InPhase>
craftmaster1231: Ah good, you got a real IRC name. I was about to suggest that when you returned. :) Hanging out here and keeping track of discussions is a very effective way to get integrated into the development process. (And a name registered with nickserv will help with this, for a consistent discussion identity.)
<InPhase>
craftmaster1231: So it's helpful to look directly in your .git/config files whenever you're having trouble with that setup.
<InPhase>
The stream of commands to modify state can get confusing, so just look at the file and see what's actually setup.
<InPhase>
You'll see things like a [remote "origin"] and sometimes a [remote "upstream"], with a url set. And that will tell you when you have used ssh (push and pull) vs https (pull only).
<InPhase>
You'll also see entries for submodules and branches in there depending on what you've done.
<craftmaster1231>
> So it's helpful to look directly in your .git/config files whenever you're having trouble with that setup.
<craftmaster1231>
Do you mean local git config?
pa has quit [Ping timeout: 240 seconds]
<InPhase>
Yes, the ./.git/config under each repository clone.
<teepee>
yeah, did it really put the https url into /tmp/x/openscad/.git/config ?
<teepee>
that would be really puzzling, I've never seen it doing something like that before
<teepee>
well, one possible last idea would be checking $HOME/.gitconfig
<InPhase>
craftmaster1231: There's a user level ~/.gitconfig that has a few global settings you should put like name and email, but if you ever need to customize it by repository, those go in ./.git/config for each repository.
<InPhase>
In the future for OpenSCAD because we have so many submodules, you can clone with --recurse-submodules Since you have skipped it, you can do: git submodule update --init --recursive
<InPhase>
I bring it up because I can see in your config you have missed this. :)
<craftmaster1231>
Thanks, teepee.
<craftmaster1231>
InPhase, don't need submodules in case of testing remote -v, but thanks!
<InPhase>
I think that's the thing kintel was working on the other day.
<craftmaster1231>
Do I understand correctly, that I can surely create PR to original project with no building it somehow by-hand using git hub actions or whatever?
<InPhase>
Yes you can, but it is going to be a far better experience doing local builds.
<InPhase>
It really just takes too long to get feedback using the PR building. This is for fixing final touches or cross-platform issues.
<craftmaster1231>
So, what should i do? Set up multiple VMs and compile on them, then proove it somehow in PR?
<InPhase>
craftmaster1231: Typically you only build and test locally on your own platform, and then let the CI confirm the other platforms.
<InPhase>
There are very rare cases where you would really need a second platform for local testing.
<craftmaster1231>
> There are very rare cases where you would really need a second platform for local testing.
<craftmaster1231>
For example, in case of changing CMakeLists.txt '=D
<craftmaster1231>
When does CI confirm the other platforms? Should I do it somehow in my github clone?
<craftmaster1231>
fork*
<teepee>
I think it's somehow possible in your repo, but usually it's just done with the PR
<teepee>
as soon as the PR is created some of the actions trigger
<teepee>
some may need confirmation, but that's only the first time
<craftmaster1231>
Okay, ill PR then. Will be glad for your reviews!
<craftmaster1231>
> craftmaster1231: You should link in your PR text to the issue this is addressing, since you said it addresses an open issue.
<craftmaster1231>
I didn't said that. There is no associated feature. Am I missing something?
<InPhase>
Oh, I remembered from earlier in the scrollback you had said, scrolling up.... "For example, i want to work on Issue #4458."
<InPhase>
But I guess that is not this one. :)
<craftmaster1231>
InPhase, yes I did. I'll close a PR, commit, and open a new one then.
<InPhase>
I was going to click and see if it addressed it correctly, but then didn't see the link, so I was asking. But I see you selected a different thing to address first.
<craftmaster1231>
> But I guess that is not this one. :)
<craftmaster1231>
Yeah, nothing more than example. =)
<InPhase>
craftmaster1231: So if that line 89 edit of CMakeLists.txt was not an intentional edit (which it looks like it wasn't), then first, I push a fix for that. And then second, after having done too many of those, the way I guard against it is by always doing a "git diff" before I add and commit, and manually reviewing the lines that I'm changing to verify I'm committing only the things I intended to. It's
<InPhase>
It's not necessary to close a PR for this, as it will automatically pick up every additional commit you make to the same source branch.
<craftmaster1231>
Sure, I did visual git diff before. Just missed, but thanks!
<InPhase>
I spent an awkward 30 seconds trying to figure out what the new cmake "cutable()" function might do. Then I realized what probably happened. :)
<craftmaster1231>
> It's not necessary to close a PR for this, as it will automatically pick up every additional commit you make to the same source branch.
<craftmaster1231>
Why don't (or do we?) we have WIP labels on Issues?
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
<InPhase>
The first PR linking to it indicates it's being worked on, as that link is visible from the issue page.
<craftmaster1231>
> s/I push a fix/push a fix/
<craftmaster1231>
InPhase, I can't get all of your expression here.
<InPhase>
craftmaster1231: Oh, that's me indicating I made a typo in the line above, and you should remove the "I " from that.
<InPhase>
substitution syntax. It seems to be understood pretty well on this network. :)
<craftmaster1231>
Owh, vim-like. Got it!
<craftmaster1231>
InPhase
<craftmaster1231>
> The first PR linking to it indicates it's being worked on, as that link is visible from the issue page.
<craftmaster1231>
Do I understand correctly, that it is better to wait for comment on Issue from one of the development "bosses" here, and only then start to work on it, if not sure?
mmu_man has quit [Ping timeout: 256 seconds]
<InPhase>
Nope. If you have a clear vision of how to fix something simple, then go ahead and make your PR as a proposal! Where you want to definitely open up a discussion, is on things like language changes or things that can have broader implications to future maintenance. It really helps to discuss with other project devs who have been around a while to see what all the implications and consequence might be
<InPhase>
of the bigger changes.
<InPhase>
If you go ahead and make a PR about a new language feature without discussing it with anybody, it's verrrry likely it would need major changes to get accepted. It's just really hard to see all the consequences, and we kind of have to talk it all out for a while.
<InPhase>
But fixing some issue with the gui, or fixing a bug, these are "just do them" things. Likewise for almost everything marked as a good first issue.
<craftmaster1231>
Thanks! It is important to know info. I'm sure, it will be useful for any newbie.
<craftmaster1231>
Btw, did project started to fail build on Mac after 3rd party update, or after someone's PR? If PR, why did it got merged then?
<teepee>
sometimes PR build goes green and merge build does not
<teepee>
multiplatform builds with floating versions can be quite annoying
<InPhase>
Yeah. It has been flittering back and forth randomly between working and not, it seems.
<craftmaster1231>
That sound not happy. =(
<teepee>
the specific issue on master is caused by macOS upgrade on the build machines, it's not an actual build failure
JakeSays has quit [Ping timeout: 240 seconds]
<teepee>
that's something we don't have much control over
JakeSays has joined #openscad
<teepee>
Reason: Incompatible library version: git requires version 12.0.0 or later, but libintl.8.dylib provides version 10.0.0
<teepee>
so it seems fail running git
<teepee>
that is the macos build for the versions provided on the website
<teepee>
on the plus side, the macOS test suite run on github did go green, so it's not that macOS does not work at all
<guso78[m]>
Inphase i understand , Python. Requires more discussion to get accepted. However, there were No New concerns from your side
<craftmaster1231>
Well, builds and test on my PR are successful. 8)
<craftmaster1231>
eck src/gui directory in QtCreator on your system.
<craftmaster1231>
If not visible immediately, just try to build after getting submodules.
<InPhase>
guso78[m]: Well, I'll need to give your Python work a good testing and give a good try at breaking it before I can draw a definitive conclusion.
<InPhase>
guso78[m]: Have you gone through your own adversarial usage testing, where you try really hard to do the stupid things it wasn't designed for, and see what happens?
<InPhase>
guso78[m]: Like, return the wrong stuff, pass in misformatted things, try to end-run around or sneak around the security safeguards, and so on.
<InPhase>
guso78[m]: We want graceful failures.
<InPhase>
guso78[m]: All that you could possibly think of to do wrong, plus three times that, someone eventually will.