Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support to allow to change to quad view at runtime #17

Merged
merged 2 commits into from
Feb 23, 2022
Merged

Support to allow to change to quad view at runtime #17

merged 2 commits into from
Feb 23, 2022

Conversation

ddreeves70
Copy link
Member

I think I may have commit access but I wasn't 100% sure about this change. This was more just an educational exercise to get my environment setup and make a small code change. Before I commit to the main I wanted to make sure:

  1. I was on the right track with this change. This is the way to do this.
  2. the change was compliant with all the rules for committing code outlined in the HACKING document
  3. This was a change we are interested in.

I did some very minor code clean up of the code that was already there. Mostly I just added the capability to change back and forth to single view and quad view. There is preexisting code that is not compliant with HACKING document. If I'm on the right track I will clean up some of the other issues I have seen.

@starseeker
Copy link
Member

@ddreeves70 Taking a look now - impressed you dug into this, it's very experimental code!

@starseeker
Copy link
Member

This is looking good - the only issue I've noticed is that the embedded raytrace isn't working. To see this feature in action you can open moss.g with a main build of qged and run the following three commands:

e all.g
view faceplate fb 2
ert

For this to work ert needs some information about the display manager, and in the current pr it's reporting "no current display manager set".

I think this just means we probably lost a line or two informing the gedp of the display manager somewhere in the refactor, so it should be an easy fix - after that I'd say merge it - nice work!

(Note that ert doesn't quite work correctly with quad-mode even in main - it will always render to the upper right quadrant even if another is selected, which obviously isn't right, so the quad switching code needs to be updating the dm and isn't somewhere - but it does display. You don't have to fix that in this pull request - although there's certainly no objection to doing so! - just want to be sure that we don't regress ert's behavior.)

@ddreeves70
Copy link
Member Author

ddreeves70 commented Feb 23, 2022 via email

@starseeker starseeker merged commit 25ddce1 into BRL-CAD:main Feb 23, 2022
@starseeker
Copy link
Member

Very cool - nice work!

@ddreeves70
Copy link
Member Author

ddreeves70 commented Feb 24, 2022 via email

@starseeker
Copy link
Member

@ddreeves70 Sounds good - appreciate it! Out of curiosity, were you looking to make other enhancements to the Qt code? I've got a laundry list of TODOs to get things up and running on the Qt side, if that's of interest.

@starseeker
Copy link
Member

@ddreeves70 Probably worth checking to see if any of the more recent changes clear the adc crash - I don't seem to be able to reproduce it here, so I'm not sure, but one or two of them might impact that logic.

@ddreeves70
Copy link
Member Author

ddreeves70 commented Feb 25, 2022 via email

@starseeker
Copy link
Member

@ddreeves70 Sean may have a different take, but I would definitely vote for qged - for me at least that is definitely the more pressing concern.

@starseeker
Copy link
Member

@ddreeves70 nevermind, I see on the zulip chat he agrees. As far as the adc crash, it's quite possible there's some issue I'm not seeing - either in the view hashing, or some aspect of the interface not fully considered yet. Linux can be very forgiving on such things, which is occasionally rather maddening when it "works for me" but everybody else is seeing issues. (This happens a lot with Sean's Mac, for example.)

@starseeker
Copy link
Member

@ddreeves70 As for areas to focus on... it kinda depends on if you want to start big or small. My "next step" pieces were to look into what's involved with being able to interactively edit primitives, but that's going to pull in a lot of issues - how to generate and manage updating wireframes for editing without hitting the disk (for example, when altering the radius of a sphere or ell), how to suppress the non-editing wireframes in the view when the editing wireframes come up (MGED doesn't solve that problem well, which is why it will error out if it detects an edit attempt with multiple instances drawn), custom event filters for the editing operations (some of that has been figured out for the polygon editing, but each primitive will likely need its own version), etc.

For a smaller bite, my immediate "next step" was to design a customization of QLineEdit with a QValidator for .g object names, that would check the current text as a db_lookup name and color code it accordingly. The initial thought for behaviors is coloring it with small stylesheet snippits - green if it matches a "selected" name (either stashed in the widget or pointed to), red if it matches a db object that is not the "selected" object, and orange if it doesn't match anything in the database. The behavior could switch if the "selected" name is NULL, and highlight green if db_lookup finds a match and red if it doesn't.

@starseeker
Copy link
Member

I was thinking to define that as a QgLineEdit or some such in libqtcad as a general purpose widget, that would then get used when defining editing widgets and other GUI components that work with .g object names.

@starseeker
Copy link
Member

A bigger but still somewhat self-contained piece would be to work on translating Archer's sketch editing capabilities into a Qt widget (it doesn't have to be an exact re-implementation of what Archer has, just something that reproduces its capabilities.)

@starseeker
Copy link
Member

Translating the HUD capabilities into the lower level C libraries out of MGED would probably be good as well, if you want to do that - I've not looked at that much yet, so I don't have a real sense of how difficult it will be.

@starseeker
Copy link
Member

starseeker commented Feb 25, 2022 •
edited
Loading

(for the sketch editing piece, https://github.com/peizhan/psketcher might have some code that would be useful - it's quite an old project now though, so I don't know if it'd be a net win to extract usable pieces from there or start clean. The advantage of this as a project is the sketch editing widget can be developed independently of the rest of qged in its own small app, and then once the widget it ready it can be moved to libqtcad.)

@starseeker
Copy link
Member

(if we were going to go for a properly constrained sketch editor I'd probably also go back and investigate https://github.com/cmerrill/sketchsolve but IMHO right now that'd be a distraction from QGED - if we can duplicate what Archer can do that's enough to start with, and once we're over the "replace Archer and MGED" hurdle we'll be well placed to go back and look at those capability-expansion type mods.)

@ddreeves70
Copy link
Member Author

ddreeves70 commented Feb 26, 2022 via email

@ddreeves70
Copy link
Member Author

ddreeves70 commented Feb 27, 2022 via email

@starseeker
Copy link
Member

My intent was to convey whether the name in the field is valid or invalid in the .g database. I'm not a usability expert, so I'm open to other ideas, but this is the scenario of concern:

I'm wanting to rename a primitive in the tree view or in an editing dialog. I start typing a new name, but won't know until I press enter whether the name I want to select is already in use in the database. db_lookup calls are generally quite fast, compared to human typing speed, so it seemed to me we could give immediate feedback on the name on a per-character basis as to what its significance is in the database, rather than having to wait for them to press return. If there's some better mechanism for indicating an invalid name than color coding that'd be fine too.

If you want to proceed with some other approach on the editing that's fine - I'm not overly tied to the QLineEdit idea, it just struck me as a logical incremental step.

zhuodannychen pushed a commit to zhuodannychen/brlcad that referenced this pull request May 9, 2023
@allyhoskinson
Merge pull request BRL-CAD#17 from SP23-CSCE482/ally_branch
ec4e408 
PPI parameter addition, header and footer changes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@ddreeves70 @starseeker