Booguie : Developer's Manual
Design / Internals
Code organisation / hierarchy
From an organisation point of view there are 3 layers:
- your application code (ex.: MainWindow.cpp/h)
- the Booguie generated code (ex.: MainWindowGUI.cpp/h)
- the Kiss layout library (KissLib.so)
and of course the InterfaceKit lies below.
You app calls the Booguie-generated GUI building routines (via gui.BuildTo())
and interfaces with the GUI via
- the pointers
- the names (BView::Name()).
The Booguie g'ed code consists of calls to the KissLib API (see the
related page).
Data format
- Project persistency:
-
Most of the InterfaceKit (IK) widgets are archived thanks to
their class Archivable inheritance, class KissBox adding
more attributes on its own. See it for yourself, Booguie .uidefs
files are just flattened BMessages.
- Code generation:
- C++, relative to the KissLib API.
You can of course generate code from a saved project, but not [easily]
recreate a project from generated code.
The editor's GUI
Menus
- File:
-
nothing special here. "Save" only saves the project, it doesn't
generated code in addition.. Do it in the Code menu..!
- Code
-
- Generate UI code:
-
This will overwrite the *GUI.cpp and *GUI.h files matching your
current project with the C++ code that creates the
widgets and menus, which you have to call in your
application.
I.e. if the project you're editing is MainWindow.uidefs,
this will write KissLib calls in MainWindowGUI.cpp and
MainWindowGUI.h will contain the gui pointers and stuff.
The confirmation requester is only a paranoid thing: what if
you have hand-written sources files with the same names
as the ones about to be generated (ie, clobbered) ? I might
make this requester an optional preference in the future..
- Generate skeleton:
-
If you're not familiar with the "branching to the Booguie routine"
explained above (see the first part, gui.BuildTo()) then this generates a .skel file for you
(".skel" as to not overwrite any of your files hopefully) that contains
sample code you can save into the relevant .h and .cpp files.
- View
-
-
Reveal Hidden boxen:
-
because it's WYSIWYG, the editor window shows the KissBox'es
exactly as they will be in your compiled application, ie often
some parts are obscured, and it might even be that a KissBox
is totally obscured by its only child (not that such a thing would
be useful..) or you can't figure how your layout is organized any more.
This is sort of a "panic button" that show all hidden boxen
by overriding their Label()s (only the NULL ones) and is non-destructive : as soon
as you unmark the menu item labels get back to what they were
previously.
You can then recover/correct their state before hiding them
again. => Very useful to debug.
The widget properties window
The "inspector window" purpose is to be more productive rather than
set properties of widgets by using the popupmenu.
The DnD window
You can drag'n'drop some of the supported widgets from this window to the edit
window to create new BButtons..etc
I did this to experiment.. it works, so look out for more widgets here in the next release.