On 12.02.2008, at 22:44, imm wrote:
> On 12 Feb 2008, at 20:06, Michael Sweet wrote:
>>
>> If we did a simplified .fl parser that supported standard FLTK
>> widgets with no extra code and callbacks specified by name only, we
>> would have a (very) basic form of what you get with Cocoa. Adding
>> custom class support would require the application to register that
>> class with the parser. Similarly, widget pointers could be set by
>> name...
>
> So the C++ objects and the connections between them would be fixed at
> compile time, but their layout would be configured on a per-locale
> basis, applied at startup. So the widgets can be the correct size for
> their labels, and in the correct relative positions - e.g. we can
> flip the entire GUI over for R-to-L text, if needs be.
> Each locale-file would maybe be auto-generated from the default, but
> then tweaked by hand to be "correct", before being written to it's
> file - by some kind of tweaked fluid I suppose.
> Oh, that sounds a lot like gettext or etc., really... Only with
> widgets.
Since the GUI itself is still created with FLUID, I would only put the
changes into the resource file, using a unique ID for each possible
widget. This would all work without any ABI changes. Ideally, I would
give every widget a script name in ASCII, but that is a whole
different story ;-)
So for example, say an existing app ets a resource interface. The app
here is "Hello" in Fluid, so the C++ code would look something like
this:
Fl_Window *win = new Fl_Window(400, 200, "Hello World");
Fl_Button *btn = new Fl_Button(10, 10, 380, 180, "Hello");
win->end();
now, the simpelest resource-based version would look somewhat like this:
static ... resource_german[] = {
0x12345678, // unique ID to describe the window widget
0x02, 480, // override width t be 480 pixels instead of 400
0x04, "Hallo Welt", // override label string
0xff, // end of description
0x12345679, // unique ID for button
0x02, 460,
0x04, "Guten Tag",
0xff, 0xff
};
Fl_Resource rsrc = new Fl_Resource(full_path_to_this_app);
// read the new default values into rsrc->W, rsrc->H, etc.,
// then override them with whatever is in the rsrc file, if any.
rsrc->read(0x12345678, 400, 200, "Hello World");
Fl_Window *win = new Fl_Window(rsrc->W, rsrc->H, rsrc->L);
rsrc->read(0x12345679, 10, 10, 380, 180, "Hello");
Fl_Button *btn = new Fl_Button(rsrc->X, rsrc->Y, rsrc->W, rsrc->H,
rsrc->L);
win->end();
All code is generated by FLUID. The resource_german is stored as a
binary at some defined location. Its format could be very different of
course, but the ideas are:
- a unique ID that need not to be stored with the widget keeps the ABI
and space requirements little
- the ID also ensures that outdated resource files will not harm the app
- changes in the main file require only patches in the resource file
(which again should be possible within Fluid)
- all the above code is generated by Fluid, no changes to existing
code required
- resources in the rsrc file are stored in the same order as they are
generated in the C++ file for best GUI creation speed
If the ABI can be broken, a virtual function would allow for
- a virtual function to override more aspects of the widget, even
unknown aspects for custom widgets
- a script name that could be used in any external scriptin language
instead of the ID
- changing the language resource file at run-time using the unique-id
lookup for each widget
Anyway, 1.1.8 has priority. This was just a response to the Qt
comparison.
----
http://robowerk.com/
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
