mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-20 23:44:13 +02:00
Wiki Page Revisions
10 Commits
10 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 ispyisail
|
b0c030f682 |
Fix fabricated shortcuts and behaviors across four pages
Audited every English wiki page against source this session. Pages already citing specific source files (variables.md, autonumbering.md, element_editor.md, preferences.md, collection_browser.md and others fixed earlier) held up under spot-checking. The four pages here had none of that discipline applied and each repeated the same class of fabricated claim, now checked and corrected: - **Rotate is Space, not R.** R isn't bound to anything in the diagram editor -- checked ShortcutManager's registry directly. - **Zoom in/out is the platform's standard zoom key, not bare +/-.** QKeySequence::ZoomIn/ZoomOut, not a literal + or - keypress. - **Double-click on an element or wire opens its Properties dialog, not an inline text box.** Checked directly: QetGraphicsItem::mouseDoubleClickEvent() and Conductor::mouseDoubleClickEvent() both call editProperty(). Type |
||
|
ispyisail
|
c640b69f6d |
Verify the forum's wire-label-printing workflow and document it properly
The user pointed at forum mentions of a "wire printing feature" -- checked the actual QET forum (viewtopic.php?id=1496, "Discussion sur la liste des fileries") rather than re-grepping source, since that's a source of truth grep can't see. It confirms the earlier correction rather than contradicting it: QET has no built-in wire-marker/ferrule label printer. What the forum actually discusses is exporting the wiring list as CSV (Joshua's own words, quoted on the thread: "Project menu -> export the list of conductor names") and feeding it into a label printer's own software -- Brady, WAGO Smart-Printer, Phoenix Contact tools, and Cembre's SW-code/.FNR system were all named. A professional panel builder reported the export lacks quantity consolidation (duplicate rows instead of one row with a count), costing him real time on a large job. Verified the exact menu wording against source rather than trusting the forum's paraphrase: qetdiagrameditor.cpp's Project menu has "Exporter la liste des noms de conducteurs" (-> ConductorNumExport, the CLI's --export-wires) and "Exporter le plan de câblage" (-> WiringListExport, the CLI's --export-cables/--export-wiring) -- so the GUI menu items and the CLI verbs already documented in api_reference are the same underlying export, not two different things. Enriches api_reference (EN/FR/DE) with this as a "Worth knowing" bullet: the real menu names, the real printer brands people actually feed this into, and the verified duplicate-row limitation. Tightens the user_manual.md printing-diagrams note (which already correctly said QET has no such feature) to point here for the concrete workflow instead of just gesturing at "an external tool." |
||
|
ispyisail
|
60807be235 |
Correct Printing Diagrams: no Print Preview action, no scale/colour settings
Same unverified-filler pattern as the rest of user_manual.md, missed in the earlier correction pass because it wasn't in the sections the survey had flagged. File -> Print (Ctrl+P) opens the OS's native QPrintDialog first (paper size, colour/greyscale -- driver options, not QET settings), then, on confirm, ProjectPrintWindow -- a window with a genuinely live embedded QPrintPreviewWidget, a folio picker, a keep-conductor-colours checkbox and a separate Page Setup button. File -> Export to PDF skips the OS dialog and opens the same window. There is no separate "Print Preview" menu action (the preview IS the window) and no manual scale mode -- a folio is auto-fit via ProjectPrintWindow's own fit.scale() call, traced in source. Answers the wire-label-printing question directly, since it came up: conductor text is ordinary diagram content with no dedicated print toggle (unlike terminal markers, which do have one, documented in preferences.md), and QET has no built-in generator for a sheet of physical wire-marker/ferrule labels -- the wiring list export (--export-wiring, already documented in folio_links/api_reference) is the nearest thing, as data to feed an external label tool. EN/FR/DE. |
||
|
ispyisail
|
b4c9b0e3f5 |
Document managing collections: folders, writability, the two-tab panel
sources/ElementsCollection/ is the largest undocumented chunk found this session -- separate from elements_XML (the file format) and element_editor (drawing one element), nothing covered day-to-day collection management. The finding worth having written down: the common collection's read-only status is not a filesystem permissions check. ElementsLocation::isWritable() refuses anything under commonElementsDirN() unconditionally, by path -- that's why New folder/New element/rename/delete are greyed out there even running as an administrator, and why dragging an element out of the common collection copies it (there is no source to remove) while nothing can be rearranged inside it. Custom and company are genuinely writable; an embedded (project-internal) element follows the project's own read-only state. Also documents the panel's second tab -- Templates/macros, a reusable diagram-fragment mechanism distinct from single elements, drag-dropped onto a folio as a group -- and the full context-menu action set (new folder/element, edit, delete with a real not-undoable warning, reveal in file manager, reload from disk, the solo-folder filter, folder properties). Updates the Element Collections & Libraries stub in user_manual (EN/FR/DE) to link here instead of the placeholder bullets from the correction pass. EN/FR/DE. |
||
|
ispyisail
|
27d2e2b3d6 |
Correct user_manual and add a preferences reference
user_manual.md read as confident-sounding but unverified filler, the same failure mode already found and fixed in api_reference this session. Checked every concrete claim in Projects & Folios, Working with Elements, Drawing Wires, Reports, Preferences and the shortcuts table against the actual source, and found roughly a dozen fabrications, not one or two: - File -> New Project has no dialog at all (QETDiagramEditor::newProject() creates the project and calls addNewDiagram() immediately) -- not a three-step page-size/orientation/margin wizard. - There is no "folio type" concept anywhere in the source -- no single-line/multiline/control-diagram selector. Adding a folio (addNewDiagram()) is likewise instant, no dialog. - No per-folio "scale" property exists. - "Auto-save, configure in Preferences" doesn't exist; there is a 20-minute crash-recovery backup timer with no exposed interval setting. - The claimed element categories (01_Misc/03_Control/04_Energy/ 10_Electrical) don't match anything in the collection -- real top-level trees are 10_allpole/20_logic/30_hydraulic/50_pneumatic/60_energy. - Every one of Rotate=R, Flip=H/V and Fit-to-page=Ctrl+0 in the shortcuts table is wrong against ShortcutManager's actual registrations: rotate is Space, fit-to-page is Ctrl+9, and flip doesn't exist at all for an element placed on a folio -- flip (F) is element-editor-only, for redrawing the symbol itself. - No element-locking or persistent-grouping feature exists on current master; removed rather than described. - No wire-splitting mechanism exists (grep for split/conductor turns up nothing); "wires only connect at terminals" already said correctly elsewhere in the same file. - No "Project -> Reports" menu or "I/O Documentation" report type exists; nomenclature/wiring-list generation is File -> Export or the CLI (--export-bom etc.), already documented in api_reference. - The dynamic-text variable list (%id = "element ID", %label, %comment...) contradicts this session's own verified variables.md -- %id is a folio index, not an element reference number. - No in-app "community element repository" browser exists. - The claimed Preferences categories (Display/Projects/Grid) don't match the five real pages (General, New project, Export, Print, Shortcuts). Corrected or removed each, linking to the real mechanism where one of this session's other pages already covers it (variables, api_reference, project_database, element_editor, title_blocks, folio_links) rather than re-describing it. Softened Multi-User Workflows with an actual caveat -- project_database.md already established there's no shared-state mechanism, so "merge changes when working in parallel" needed the warning that a merge conflict there is a raw XML conflict, not a structured one. Applied identically across EN/FR/DE, not just the English source. Adds a new preferences reference page (EN/FR/DE) covering what the real five pages actually control, built from configdialog.cpp and sources/ui/configpage/ directly: the six collection/title-block path pickers on General (and why relocating one without a trailing slash used to silently break IEC 81346 prefixes -- bugtracker #671), the New project/New folio page's dual identity (same class, title and target change depending on whether a project is open), and that Export and Print share one underlying widget rather than being separate implementations. |
||
|
ispyisail
|
1bf1740fc0 |
Document using the element editor -- drawing tools, not just the resulting XML
sources/editor/ is ~22,900 lines and the only wiki coverage was a stub telling readers to see the elements_XML reference for 'designing element graphics' and 'defining connection terminals' -- which documents the file format an element becomes, not how to use the editor that draws it. element_linking already covers the master/slave/terminal semantics; this covers the tool itself. The finding worth having written down: width, height and hotspot have no input dialog at all. ElementScene::toXml() derives them from the drawn geometry on every save -- bounding rect rounded up to the next multiple of 10 (with a quirk: a remainder over 6 rounds up an extra ten, which is exactly the 42-to-50 example elements_definition_attribute.md already used without explaining where the number came from), hotspot centered in that box. And if the drawing doesn't straddle the scene origin, centerElementToOrigin() actually moves every primitive on save, not just the saved coordinates -- draw far from the crosshair and a save visibly shifts everything. Also: the checkElement() validation that runs before every save (0 terminals warns but doesn't block, except folio-report and conductor-definition elements, which must have exactly one or the save is refused); the Save vs Save As vs Save As File distinction (opened-from location vs a collection picker vs a raw file picker); and the terminal placement shortcuts (Space rotates through the four orientations while placing, the tool re-arms at the same orientation for a row of pins). Replaces the empty 'Creating Custom Elements' stub in user_manual (all three languages) with links to this page, element_linking and elements_XML instead of a four-bullet list pointing at one reference page. EN/FR/DE. |
||
|
ispyisail
|
c1b47381b2 |
Document DXF: two unrelated features reduced to one bullet each
sources/createdxf.*, sources/dxfpaintdevice.*, sources/dxf/dxftoelmt.* total ~1,780 lines. The only wiki coverage was a single repeated bullet -- 'DXF -- CAD format for collaboration' -- across features, faq and user_manual, in all three languages, describing neither direction accurately: it reads as one feature, and it's actually two that share nothing but a file extension. Export (File -> Export, alongside PDF/PNG/SVG, in-process) reuses every item's existing paint() code through a custom QPaintEngine (DxfPaintEngine) rather than a separate DXF renderer -- documented from that class's own thorough header comment, including the real fidelity table it specifies: rectangles and filled paths lose their fill (no HATCH primitive in this DXF dialect), arcs become straight-line chords, and images become position-preserving placeholder rectangles since DXF has no raster entity here. No CLI verb exists for it, unlike PDF/PNG/SVG. Import (element editor only, not the diagram editor -- File -> Import a DXF file) is a symbol-authoring tool: it shells out to dxf2elmt, a separate third-party program QET does not bundle, the same external-tool pattern as qet_tb_generator already documented in api_reference. Traces the actual call: , stdout read as .elmt XML, pushed onto the element editor's undo stack as one operation. Makes explicit what neither direction is: not a way to place a DXF drawing on a folio, not round-trip safe (export's own limitations rule that out before even considering the code is entirely separate), and not a full CAD interchange path -- no layers, blocks or metadata, just primitives. Links the existing one-line mentions in features/faq/user_manual (all three languages) to the new page instead of rewriting them, since they are fine as list bullets. EN/FR/DE. |
||
|
ispyisail
|
4854c314f0 |
Correct the automation docs: QET has no Python scripting and no plugins
api_reference stated "QElectroTech supports Python scripting" and "QElectroTech supports plugins for deep integration", and told readers to install plugins into ~/.local/share/QElectroTech/plugins/ and platform equivalents. None of it exists: there is no QPluginLoader anywhere in sources/, no plugin ABI, and every Python reference in the tree is the launcher for qet_tb_generator -- a separate PyPI program QET starts as an ordinary child process. QET never reads those plugin paths. cli_reference had the mirror-image error, calling the shipped headless export "Future CLI Features (QET 2.0)" and sending readers to the scripting that does not exist. The FR/DE CLI pages additionally invented a --dpi option and QET_PLUGIN_PATH / QET_ELEMENT_PATH, and documented an argument order the parser cannot accept. Rewrites api_reference (EN/FR/DE) around what is actually there: the 13 CLI verbs with their real positional syntax and exit codes, the real .qet and .elmt XML (the old skeletons were invented -- no <diagrams> wrapper, element has no id, uuid is an attribute), qet_tb_generator, and the C++ source. Adds a section naming what does not exist, so the claim does not come back. Also corrects the same claims where they had spread: features, history, faq, user_manual (EN/FR/DE) and the sidebar. |
||
|
ispyisail
|
3c794eb8c8 |
Complete Tier 1: Quick Start Guide, User Manual, and FAQ
Quick Start Guide (10-minute onboarding): - Platform-specific installation (Windows, macOS, Linux) - Step-by-step project creation and first diagram - Interface overview and toolbar guide - Adding elements and drawing wires - Labeling and saving - Common first-time tasks and shortcuts User Manual (comprehensive reference): - Basics and interface overview with diagram - Projects and folios (pages/diagrams) - Working with elements (find, place, select, move, rotate) - Drawing and editing wires/conductors - Text, labels, and dynamic fields - Editing, alignment, zoom, snap-to-grid - Reports, export, and printing - Preferences and settings - Keyboard shortcuts table - Troubleshooting section - Links to advanced topics FAQ (60+ questions with practical answers): - Installation and setup for all platforms - Getting started with projects and diagrams - Common beginner questions about elements, wires, labels - Creating and saving projects - Organization and sharing - Performance and troubleshooting - File compatibility and advanced topics - Platform-specific guidance - Active community support pointers Research gathered from: - qelectrotech.org official manual structure - GitHub releases and documentation - Forum activity analysis - Official example projects - Official element collections Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GtMZqGEiUMvDBqcFvVG2vb |
||
|
ispyisail
|
6242ac4458 |
Redesign wiki home page for end-users; add structure and stub pages
- Reorganize Home.md with end-user-first structure - Add Getting Started, User Documentation, Development sections - Create stub pages for Quick Start Guide, User Manual, FAQ, Tips & Tricks - Add developer stubs: Building, Contributing, Development Roadmap - Add About section: History, Features, License, Community The stubs provide structure and placeholders ready for content to be filled in. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GtMZqGEiUMvDBqcFvVG2vb |