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

Dani listasdani at gmail.com
Sat Apr 21 18:12:48 CEST 2007


Hi. I need know you opinion about this comments; what you think about? I
need known what you think will be better?  for me take a "north" to
continue.

[]'s of seventy rounds, c.h. Dani



2007/3/22, Dani <listasdani at gmail.com>:
>
> 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/20070421/3a41c61d/attachment.htm 


More information about the gtkada mailing list