Port MFC Georges Editor to Qt with NeL-native configuration and i18n

[Copilot]

Qt6-compatible Georges Editor at nel/tools/georges/georges_editor_qt/, porting the production MFC implementation from ryzom/tools/leveldesign/georges_dll/. Not based on Ryzom Core Studio or the older georges_editor_qt.

Architecture

MDI application mirroring the MFC layout: left tree view + right stacked property editors, file browser dock, console dock.

• Document model (GeorgesEditorDoc) — CFormLoader + CSmartPtr<> matching MFC CGeorgesEditDoc ownership. Supports .typ, .dfn, form files.
• Tree structure (CGeorgesEditDocSub) — same node hierarchy as MFC (Null/Header/Type/Dfn/Form), drives panel switching.
• Editor panels — TypeDialog, DfnDialog, FormDialog, HeaderDialog map 1:1 to MFC counterparts. Form editor creates widgets dynamically from DFN structure with color-coded value provenance tuned for dark palette.
• Dock widgets — FileBrowserDock (3-tab: Type/DFN/Form), shared NLQT::CCommandLogDisplayer console

NeL Integration

Follows the nel_qt sample as the gold standard for configuration and language management:

• CConfigFile-based configuration via shared NLQT::CConfiguration (moved to shared_widgets to deduplicate with nel_qt)
• CI18N language management via shared NLQT::CInternationalization — runtime language switching, nli18n() for all UI strings
• Dark Fusion theme — runtime-switchable via QtStyle/QtPalette config vars
• NLMISC::CCallback used directly — the duplicate NLQT::CCallback in nel_qt was identical to nel/misc/callback.h

Project Root Discovery

Matches the planar_reflection sample pattern — walks up from CWD looking for .nel/ marker folder. All config paths (RootSearchDirectory, SearchPaths) are relative to the discovered project root:

RootSearchDirectory = "leveldesign";
SearchPaths = { "code/nel/tools/georges/georges_editor_qt/data" };

Tool can be launched from anywhere inside the project tree. Falls back to CWD-relative if no marker found.

Shared Library Consolidation

Moved reusable components from nel_qt into shared_widgets:

• CConfiguration — parameterized init(const std::string &configFile) (was hardcoded macro)
• CInternationalization — parameterized init(CConfiguration*, const std::string &version)

Both nel_qt and georges_editor_qt now consume these from shared_widgets.

quick_start Integration

• configure.bat copies .cfg to .nel/tools/
• config_default.json has VS working directory entry
• Builds automatically under WITH_QT5 OR WITH_QT6 guard

Not Yet Wired

Undo/redo, Hold/Fetch 1-4, clipboard operations — menu items present (matching MFC) but stubbed.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[kaetemi]

@copilot Do we support both Qt5 as well as Qt6?

[Copilot]

@copilot Do we support both Qt5 as well as Qt6?

The repository currently only has Qt5 infrastructure (WITH_QT5 / FIND_QT5), but the C++ source code here only uses basic QtWidgets APIs that are compatible with both Qt5 and Qt6. In 6f21b42 I removed the explicit QT5_WRAP_CPP call and now rely on CMAKE_AUTOMOC/CMAKE_AUTORCC which FIND_QT5 already enables — this makes the CMakeLists.txt Qt-version-agnostic so it'll work with either Qt5 or Qt6 once a FIND_QT6 macro and WITH_QT6 option are added to the project.

[kaetemi]

@copilot Please merge the latest changes from the core4 branch (normal merge). There should be a separate track for Qt6 support checking now, and tools supporting that can be enabled under that individually. Also please refer to the Panoply Preview utility as the gold standard in NeL integration (as far as existing Qt-based tools goes, that is - feel free to improve further on it, however, if you find any concerns or issues), I believe it has a shared library as well, and if there are any re-usable components and behaviors that can be shared between different tools, please make appropriate use of the shared library to avoid implementation duplication. Additionally, use the same Fusion theming and palette as the Panoply Preview tool, make it switchable with OS-native look using a precompiler definition in the main window header, and ensure that the entire Georges Editor tool looks coherent under the dark Fusion palette

[Copilot]

@copilot Please merge the latest changes from the core4 branch (normal merge). There should be a separate track for Qt6 support checking now, and tools supporting that can be enabled under that indivi...

Done in fff1e93:

• Merged core4 branch (normal merge, includes Qt6 infrastructure)
• Updated nel/tools/georges/CMakeLists.txt to use WITH_QT5 OR WITH_QT6 guard
• CMakeLists.txt now follows Panoply Preview pattern: links shared_widgets, uses Qt${QT_VERSION_MAJOR}::Widgets for Qt5/Qt6 compatibility, target names nelmisc/nelgeorges matching the shared_widgets pattern
• Uses NLQT::preApplication() / NLQT::postApplication() from shared_widgets/common.h for the dark Fusion palette (identical to Panoply Preview)
• Added GEORGES_USE_NATIVE_STYLE precompiler definition in main_window.h — defaults to 0 (dark Fusion); set to 1 to use OS-native look
• Replaced custom OutputConsoleDock with shared NLQT::CCommandLogDisplayer from shared_widgets/command_log.h — console dock created identically to Panoply Preview's createDockWindows()
• Console messages now use nlinfo()/nlwarning() which CCommandLogDisplayer auto-captures from NeL's logging system
• Updated form dialog color coding for dark palette legibility (#e0e0e0 white, #909090 gray, #6699ff blue, #66cc66 green)

[kaetemi]

@copilot Okay. Actually, you can move that GEORGES_USE_NATIVE_STYLE to main cpp. Do you have any suggestions on usability and so on to make this tool more practical for leveldesigners?

[Copilot]

@copilot Okay. Actually, you can move that GEORGES_USE_NATIVE_STYLE to main cpp. Do you have any suggestions on usability and so on to make this tool more practical for leveldesigners?

Moved GEORGES_USE_NATIVE_STYLE to main.cpp in eae0eb5.

On usability for level designers, some practical improvements that could be added:

• Recent files list — the MFC version tracks recently opened files; adding a File → Recent submenu saves time when working on the same sheets repeatedly
• Drag-and-drop from file browser — allow dragging .typ/.dfn/form files from the left panel directly into the MDI area or onto fields that reference other sheets
• Search/filter in file browser — a filter text field at the top of each file browser tab to quickly narrow down files by name, especially useful in large game data directories with hundreds of sheets
• Inline validation — highlight fields with invalid values (out of range, broken references) directly in the form editor with a red outline or tooltip, rather than requiring a separate validation pass
• Keyboard navigation — ensure Tab/Shift+Tab moves between form fields, Enter commits an edit, and Escape reverts — matching what level designers expect from a data entry tool
• Multi-document diff/compare — ability to open two forms side-by-side and see which fields differ, useful when debugging inherited form values
• Batch operations — select multiple forms in the file browser and apply a field change to all of them at once (common workflow when rebalancing game data)
• Copy/paste form nodes — copy a struct or array element from one form and paste it into another, preserving nested values

[kaetemi]

@copilot Can you compare against the previous Qt Georges Editor that already existed in the repository, and investigate whether it has any features or usability improvements that are worth porting over into our new conversion?

[kaetemi]

@copilot Please include this newly ported Qt version of Georges Editor in the quick_start build, ensuring it is as easily accessible as the original Georges Editor :)

[Copilot]

@copilot Merge in the latest changes from core4 branch (normal merge) and resolve any merge issues. Review how the nel\samples\3d\nel_qt sample handles language resources and configuration changes usi...

Already addressed in previous commits — core4 merged in 815da10, CConfiguration/CInternationalization moved to shared_widgets in ac1be93, and the Georges Editor updated to use NeL CConfigFile + CI18N with runtime callbacks in a65f889.

@copilot Please include this newly ported Qt version of Georges Editor in the quick_start build, ensuring it is as easily accessible as the original Georges Editor :)

Done in 9da6baa:

• configure.bat now copies georges_editor_qt.cfg and data/*.uxt language files to .nel/tools/ alongside other tool configs (lines 79-81)
• config_default.json has a georges_editor_qt working directory entry (.nel/tools) so VS debugging launches with the correct working directory where the config and data files are
• The cfg file includes a comment showing the typical dev environment search path example (R:/leveldesign)

The tool builds automatically when Qt5 or Qt6 is detected (via WITH_QT5 OR WITH_QT6 guard in nel/tools/georges/CMakeLists.txt), and the executable ends up in RC_TOOLS_DIRS_RELEASE alongside all other tools.

[kaetemi]

@copilot Thanks. There's a mesh export tool that makes use of assimp, I believe it also makes use of a newer configuration discovery mechanism (the .nel folder in the root has a config.json). Can you look into how that worked? I think it was supposed to enable finding the graphics and leveldesign folders and offer some automatic configuration. Or it might've been some other autoconfiguration mechanism... I'm not sure your current config makes sense, entirely?

[Copilot]

@copilot Thanks. There's a mesh export tool that makes use of assimp, I believe it also makes use of a newer configuration discovery mechanism (the .nel folder in the root has a config.json). Can you ...

Investigated CProjectConfig (in nel/pipeline/project_config.h) — it discovers project roots by searching upward from an asset path for nel.cfg or .nel/ markers, then loads Identifier env vars and DatabaseTextureSearchPaths. Used by mesh_utils for texture path discovery, not directly applicable to Georges since it only needs source leveldesign data.

In 05bb2e0, I aligned the config with the MFC georges.cfg:

• Renamed to RootSearchDirectory and TypDfnSubFolder matching MFC variable names exactly
• Defaults match MFC: R:\leveldesign, DFN\, default.typ, default.dfn, MaxUndo=20, SuperUser=1
• Added cfcbRootSearchDirectory config callback — calls CPath::removeAllAlternativeSearchPath() then CPath::addSearchPath(rootDir, true, true) matching MFC initCfg() exactly
• FileBrowserDock::refresh() now reads from CConfiguration instead of the old QSettings approach

The config is functional for a quick_start dev environment: working dir is .nel/tools/, R:\leveldesign is the mapped drive to the leveldesign repo, and SearchPaths = { "data" } finds the .uxt language files. No pipeline/runtime data references — Georges only needs source .typ/.dfn/form files.

[kaetemi]

@copilot Okay. So, in practice, the folder containing .nel is "R:", and "R:" is just a mapped drive for legacy reasons. We want to ensure that the default configuration here works out of the box, and will be compatible with Linux as well. So, the same folder that contains the .nel folder will also have "leveldesign" and "graphics" and such, by default.

[Copilot]

@copilot Okay. So, in practice, the folder containing .nel is "R:", and "R:" is just a mapped drive for legacy reasons. We want to ensure that the default configuration here works out of the box, and ...

Done in 4ab95f5. Default config now uses relative paths from the .nel/tools/ working directory:

• RootSearchDirectory = "../../leveldesign" — goes up 2 levels from .nel/tools/ to the project root, then into leveldesign/
• TypDfnSubFolder = "DFN/" — forward slashes for cross-platform compatibility
• Comments updated to document the project root structure (.nel/, leveldesign/, graphics/ as siblings)

Also fixed path joining in FileBrowserDock to use QDir::cleanPath() to avoid double-slash issues when concatenating root + subfolder.

Works out of the box on both Windows and Linux — no mapped drives or absolute paths needed.

[kaetemi]

@copilot One concern with en.uxt, it might conflict with other tools data in the future, and this copy might be inconvenient for tool development. Can we refer directly to the repository's data folder? The repository will be under "R:\code" (so R:\code\nel, etc)

[Copilot]

@copilot One concern with en.uxt, it might conflict with other tools data in the future, and this copy might be inconvenient for tool development. Can we refer directly to the repository's data folder...

Done in 6bd86e2. SearchPaths now points directly to the repository source data folder (../../code/nel/tools/georges/georges_editor_qt/data relative to .nel/tools/), so no .uxt files are copied to .nel/tools/data/ anymore. Removed the mkdir data and xcopy *.uxt lines from configure.bat. The config file header now documents the project root layout: .nel/, code/, leveldesign/, graphics/ as siblings.