[Gambas-devel] Gambas on Cygwin

[Benoit Minisini]

On Tuesday 18 January 2005 08:18, Ron Onstenk wrote:
> On Tuesday 18 January 2005 01:32, Brandon Bergren wrote:
>
>
> --8<---
>
> > We must make a gb.form component that will be parent of gb.form.qt and
> > gb.form.gtk. This gb.form component will include a API with all X11
> > dependent functions that will be used by gb.form.qt and gb.form.gtk. This
> > way, things will be clearer and porting easier!
>
> hu?????
> A gb.form component for X11 functions in form?
> The X11 functions are in the qt component used for gb.qt and gb.qt.form.
> The hierarchy is X11->qt->form and gb->X11->gtk->form
> How could gb.form in gb.form->gb.qt.form handle the X11 functions
> if qt talks direct to X11?
> OK, you say make new gb.form.qt and gb.form.gtk but read on....
>
> | shouldn't gb.form be where the abstract windowing stuff be put?
> | What about when there's a (gag) MFC gui component?  BeAPI?  Aqua?  Cairo?
> | Allegro? (anyone want a dos port?  ;P )
> | Think of how java.awt
> | works...  X11 is quite platform specific, really..
> | Really, shouldn't it be more like
> |
> | gb.form
> |   gb.form.x11
> |    gb.form.x11.qt
> |    gb.form.x11.kde
> |    gb.form.x11.gtk
> |    gb.form.x11.motif
> |    gb.form.x11.athena
> |   gb.form.fox
> |   gb.form.wx
> |   gb.form.fltk
> |   gb.form.be
> |   gb.form.aqua
> |   gb.form.mfc
> |   gb.form.aalib
> |
> | ?
> | (not like all of these components would ever get written)
>
> This make a little sense in first view but how about the widgets?
> These can be the x11-athena, x11-wx, x11-qt win-wx, win-qt or
> even the x11-ftkl things.
> Gambas can be a BASIC development environment to ftkl by using
> classes for every control that generate the ftkl scripts parts
> or as interface component. Nice job to invent :)
>
> A form is more or less also a widget, i.e. form in form, and in that way
> you must make the gb.button.qt and gb.button.gtk too with a gb.button or
> gb.<widget> and gb.<widget>.qt with gb.<widget>.gtk, easy porting ???
>
> In fact the hierarchy is just opposite !
>
> your suggestion         what it should be
>
> | gb.form.x11         <- gb.x11.form
> | gb.form.x11.qt      <- gb.x11.qt.form     <- gb.x11.qt.form
> | gb.form.x11.gtk     <- gb.x11.gtk.form    <- gb.x11.gtk.form
> | gb.button.x11.qt    <- gb.x11.qt.button   <- gb.x11.gtk.button
> | gb.listbox.x11.qt   <- gb.x11.qt.listbox  <- gb.x11.gtk.listbox
> | gb.<widget>.x11.qt  <- gb.x11.qt.<widget> <- gb.x11.gtk.<widget>
> | gb.<widget>.win.qt  <- gb.win.qt.<widget> <- gb.win.gtk.<widget>
>
> Here I add the x11. because it can be win. for windows and
> is the parent for the widgets, need for porting to i.e. windows.
>
> 'x11.qt' or 'x11.gtk'  can be also 'win.qt', 'x11.wx', 'x11.fltk',
> 'directfb' or 'ncurses'.
>
> | gb.form.directfb <- gb.directfb.form <- gb.directfb.form
> | gb.form.ncurses  <- gb.ncurses.form  <- gb.ncurses.form
> | gb.form.wx       <- gb.x11.wx.form   <- gb.win.wx.form
> | gb.form.fltk     <- gb.x11.fltk.form <- gb.win.fltk.form
>
> From last four lines you can see that gb.form.x11 just sounds
> stupid to me, icm the form can be any widget or simular ncurses
> construction to give a widget idea of it.
>
> Also it make nosense the have a 'gb.form.x11.gtk' without gb.button.x11.gtk
> or gb.button.x11.qt, is it ?
>
> The 'gb.qt/gtk' in fact is 'gb.x11.qt/gtk' or 'gb.ncurses'
> and gb.x11.qt/gtk.<widget> or gb.ncurses.<widget>
>
> This results in
>   'gb.<iface>.<widget>'
> where
>   '<iface>' is 'x11.qt', 'win.qt', 'x11.gtk' or 'ncurses' and
>   '<widget>' is 'form', 'button' or 'listbox'.
>
> The gtk component Daniel is making is already gb.x11.gtk.<widget> because
> it is in real life a x11.gtk component. Same for the gb.qt component.
>
> If there must be a split in the code for a form it should be a split
> between the x11.qt and the qt.form part in such way that the binding
> between these is universal and
>
>   gb.<x11.qt_interface_qt>.form
>   gb.<x11.gtk_interface_qt>.form
>
> can be changed to
>
>   gb.<x11.qt_form-interface>.form
>   gb.<x11.gtk_form-interface>.form
>   gb.<ncurses_form-interface>.form
>   gb.<win.qt_form-interface>.form
>   gb.<cygwin.qt_form-interface>.form
>   gb.<win_form-interface>.form
>
> and from your list the  gb.form.fltk
>   gb.<fltk_form-interface>.form
>           _<widget>-interface>.<widget>
>
> And that is in fact almost the current situation and
>
> >We must make a gb.form component that will be parent of gb.form.qt and
> > gb.form.gtk.
>
> is in my view a wrong statement. It works opposite.
>
> | How about having the gui compenent to use be specified on the command
> | line or as an env. var, instead of in the project file?
> |
> | like GAMBAS_USE_GUI=gb.gtk or something.
>
> And yes here you can tell to use x11.qt, x11.qt, directfb or ncurses.
> This make more sense to me, make the program code in x11.qt and run
> simple with x11.gtk or win.wx based system.
>
> Note:
> By looking in the proposal, I was had some strange feeling about it.
> I tried to forsee the impact it could have in the wx, gtk and win case and
> found the first problem with the widgets.
> Instead 1 component with a subclass for the widgets every widget was also
> divided in at least 2 subclasses for qt and gtk.
>
> The hierarchy gb.qt.widget to gb.widget and gb.widget.qt/gtk/wx/...
> does not look clearer to me.
> The way it works now with using gb.qt or gb.gtk it is.
> Using gb.ncurses, that will be missing some of the widgets from gb.qt,
> shows nice in the toolbox, I don't belive your proposal will do the
> same as easy it works now.
>
> This is my personal view, I did like the brainstorm about it and share
> my conclusion. Sorry if it is boring and to long.
> BTW, nice job to make it working with cygwin.
>
> Ron
>

Arrggh !? Do you want the user to become mad ? :-)

I will say one word: K.I.S.S - Keep It Simple & Stupid!

And so: gb.form, gb.form.qt and gb.form.gtk

Regards,

-- 
Benoit Minisini
mailto:gambas at ...1...