[gtkada] how is the effort for porting gate to glade-3 gui?

[Dani]

hi! Arnaud and All.

2007/3/22, Arnaud Charlet <charlet at adacore.com>:
>
> >   I anexed a patch for gate.adb;  it add an option to make/create a
> > project-glade (.gladep)
> > for the glade-interface(.glade) and options modifiers for this option.
> The
>
> That does not seem the bst interface to me.
>
> Instead, I'd suggest having an option that tells gate to not require
> any .gladep file.
>
> We could possibly use some of the options you're proposing to replace
> the few (2 or 3) options in a .gladep file that are really relevant
> to gate.
>
> Arno


   The idea is create a gladep file _only one time_ and _only one time_ (for
provide a inexistent file if project was made with glade-3 gui). the only
option necessary is --create_gladep_file
 e.g.: gate  --create_gladep_file  projeto01.glade

   Indeed this option need run _only one time_ and _only one time_ . _after
this_,  run gate in normal way in any time/moment you want.

( note that the name provided is a file glade-interface (.glade) ! this file
exists in glade-2 and glade-3; this made a .gladep glade-project file with
same name and avoids one or two extra verification code)

  Initially I thinked in _not_ create a gladep file...neither even one time
and provide
in 'full' command line the options... but I collided with one or two
management difficults:
  1) the use of contents of gladep file pervades files as gtk_generates and
other files related
with glade.
  considerations: will be really nice substitute all legacy code to use
simple var names (string?) instead of convoluted code/artifacs just for
using two or tree options in gladep.
this will make more simple add support for more widgets supported in gtkada
but not yet
supported in gate.
 possible solutions: "hands on" and make new code to use the new scheme.
 possible problems: this will alter/modify large quantity of code
good/tested with introduction of (inevitable? :-)  possible bugs. this will
alter a significative bunch of code gate/glade-gui related. this will need
retest much code and it will take a variable (short or long) time.

 2) to use or not use a gladep file.
 2.1) in actual scheme.
     considerations: an option to  gate to  fully ignore gladep file will
need type (and retype) the
related options; these options will still need be formatted and build as a
fake gladep file, causing extra difficults needing alter the code of
"parser" to accept a string var (with gladep xml in) and/or to accept a
[Text_IO,...].File_Type from a created temp file (still with a gladep xml
in,too) and this build/create will happen _always_; and while necessary, the
gate will still need processing a "real" gladep file....;-) .Because this
(in atual scheme) why not just create a real gladep file? this will take
just one command, just one time.
   Other possible problem (or advantage)[implementation dependent] is that
the user need "retype" exactly the same options or [in teory] patch/merge
don't will work. for a fresh new project, no worries, but for projects in
proccess, mybe it can be a bad thing. (mybe advantage because, the user can
be have several `aliased' projects, were the "gui" created is more or less
equal (dependent of user will) But the hand written (or else) code can be
different in each 'aliased' projects...e.g.: internal code in
callbacks,...,etc
 2.1) in "hands on" scheme: the use of command line options don't create
extra difficults neither overhead. this will be the natural way[ assign
these options in variables(string?) and repasse this for processing].
While using a gladep file, just read the options and assign it to
variables,too.

Arno, Thanks for the patience:-) and Be Free to modify what you believe need
being modified:-)

[]'s of sevent rounds,Dani.









-- 
"There are many plans in the Human heart, But
is the Lord's Purpose that prevails"

  []'s Dani:-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/gtkada/attachments/20070322/b1ad56eb/attachment.htm